nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Can external access compromise internal information?

Jeremy West

We have JIRA Software and ServiceDesk running in one instance, we use Software heavily for internal projects which has a considerable amount of sensitive information related to our business, products and services. Our Service & Support team want to open ServiceDesk to allow external customers access to log and monitor their cases/requests including access to Confluence for a Knowledge Base which we use for internal documentation as well.

I was wondering if anyone else has a similar scenario and what the risks of an external customer gaining access to internal data would be using this method or are we better off separating the two services and having a dedicated JIRA ServiceDesk instance for our external customers?

Accepted answers

All comments

noamdah

You can run JIRA and Confluence on ssl.

Nic Brough -Adaptavist-

As long as you think through your access permissions properly, then you should be fine. Although the defaults for JIRA are quite open, it is still designed to enable you to separate out information and only allow people to see what they should. Service Desk is explicitly designed to do that too, and does it by default - it was effectively built for the obvious case of "Internal users see JIRA, Customers only see what they need".

I'd agree 100% with @Noam Dahan on the SSL, (but I instinctively wouldn't run anything other than a read-only public knowledge/information system without SSL nowadays)

Jeremy West

Thanks - we are already on SSL. I personally think this goes without saying now days, there is no excuse.

The current permissions is what concerns me, they imported contacts using a third party plugin which has little to no integrity or structure in the data, it created circa 800 groups on the import and all sorts of nastiness hence the concerns over our security on the instance with people potentially getting access to internal information.

Nic Brough -Adaptavist-

Ugh, that's a horrid place to land in. I would indeed be worried about the usage of the groups and what they allow access to, but I'd have a look at what the add-on does with them. If it's just creating the groups, then there's little to worry about, but if it plonks them into permissions or roles, you're really going to have to slog through all of the projects to check and remove them.

Adam Sterrie

Short answer is "Yes, big time".

Once you expose Service Desk to the outside world, your entire Jira installation is also exposed and all you have to rely on is Atlassian for information security. SSL isn't going to protect you in the slightest from cyber attack or even curious customers who would like to know more. If you had any information security certification (e.g. ISO 27001) you are going to lose it overnight.

Any Information Security professional will tell you that the biggest risk to your organisation is internal (or recently departed). By exposing Jira (when you allow external access to Service Desk), you are giving any of your users or past users the ability to log in with someone else's credentials (that they may have discovered) and wreak havoc.

Sadly, Atlassian are not interested in allowing Jira to have a different base url to Service Desk so we (me included) have a stark choice between massively degrading our organisation's information security or keeping Service Desk and Jira totally separate and synchronising issues manually which others are doing.

Nic Brough -Adaptavist-

The short version of this response is "it is not safe to put any system on the internet if it allows people to log into it". I'm afraid it's not been thought through and is quite simply inaccurate.

Atlassian security have the same problems and solutions as any other web-application.

Adam Sterrie

Hi Nic,

I’m sorry you think my reply was not thought through and inaccurate. Please can you elaborate?

I was answering from the perspective of an Information Security person as well as a Jira Admin. Actually you could shorten my response even further to just “it is not safe to put any system on the internet” because of the information security risks that are introduced. “Allowing people to log into it” is just one risk scenario. From an information security perspective there are many more risks that are introduced and nowadays Jira Admins have to address these according to their organisation’s Information Security Management System (ISMS). As cyber crime grows, organisations are becoming more aware of the need to have an ISMS to protect the data they hold or face the consequences (e.g. Equifax). Hence my response. I don’t think I was inaccurate – I was just answering from an information security perspective as well as a Jira Admins. I probably did not think through too much because it was immediately obvious from an information security perspective what the answer was.

Since the question was asked two years ago, I don’t think our answers will help questioner, but hopefully will be of use to others who are in the same position today. The difference is that cyber crime and Information Security are much bigger issues now and are part of the Jira Admins job. I don’t get the impression that Atlassian appreciate this very much. With your connections to Atlassian, would you agree with this impression? Could you influence them to take information security more seriously?

Regards,

Adam

Nic Brough -Adaptavist-

There's not much more to add really. Your posting was wrong about SSL (you should always use SSL as it prevents eavesdropping) and the rest of it was about systems being compromised by existing users was irrelevant because you can't do anything about that in the software.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-software

jira-administration