Jira Attachment Security is often overlooked
Jira attachments are a large and mostly overlooked data security risk that deserve a careful review based on the data each team in your organization works with. By their nature, attachments are a sort of invitation to attach a large volume of sensitive information in a single click. This makes them a gold mine for would-be malicious actors. There’s no time like now to set up clear policies and address the long term security of your attachments with the right tools and processes. In our experience, almost every company using Jira has at least some projects and tickets with attachments that need to be treated with extra care. In this article, we’ll help you understand the risks, identify sensitive data and pick the best path forward.
How Jira Attachments are putting your organization at risk
By design, Jira Data Center and Jira Cloud support data security in a way that is sufficient for day-to-day tasks but quite insufficient for other data such as attachments that puts your organization at risk.
As a security exercise, it is valuable to ascertain risk by first considering two main categories: customer and corporate. Any leak of customer data can lead to liability and a major PR issue. With a leak of company data:
- The exposure of anything that touches on a trade secret can lead to a financial and competitive loss.
- A leak of information about your system’s architecture or corporate processes can open the door to more impactful breaches.
- A breach related to financial information can result in direct theft or competitive loss.
Some of our most security conscious customers have told us they even consider publicly revealing their use of Jira or other tools to be an unnecessary risk. A piece of information this simple can be a piece of the puzzle for someone looking to break into your systems or take advantage of other attack vectors such as social engineering. It’s not always obvious why certain data is useful to an attacker, so it’s important to err on the side of caution. Take a moment to review the data different teams in your organization deal with and the frequency of that interaction.
Why you’re over-sharing by default
| Don’t overlook… | |
|---|---|
Customer Issues | ID card scans, laboratory reports, contracts, or log files (which often inadvertently contain personal information or hints which may even put your customers’ IT systems at risk) |
Internal Projects | Server certificates, legal documents, credit card information, sensitive financial summaries, and anything that could help someone compromise your networks or applications. |
Jira Service Management | External customers often attach files in the portal that should be secured. It behoves your organization to ensure the secure handling of data that customers share. |
One way to think about the security of data in Jira is by contrasting it to the model represented by data shared over email or chat tools like Slack or Microsoft Teams. All four platforms have the same risk of an employee’s machine being compromised or their login being hacked. But with email or chat, an attacker gains access only to data shared with one specific individual.
With Jira, ticket access isn’t granted on a need-to-access basis. Any medium to large size organization grants access to projects one team at a time.This means many people in your organization have had data “shared” with them that they have no need or authorization to access or use.
Security considerations dictate a simple principle: sensitive data should be shared intentionally with only the specific audience that needs access. Ideally, the really sensitive files could also be protected with an active authentication step (MFA). But, we have to acknowledge security is a balancing act. A sane security policy shouldn’t stop one from gaining the tremendous benefit of having tickets as an expedient central store of issue-specific data.
There is a solution to over-sharing:
- Review and tighten up project access permissions with a pre-defined cadence.
- Make attachment sharing more intentional by restricting the audience to only specific individuals and/or groups.
- Secure attachments with encryption.
- Identify especially sensitive fields on a project-by-project basis. Don’t overlook custom fields. Either restrict the audience with access in the same way or move the field data into file attachments that are encrypted and restricted.
- Use a Jira add-on that uses pattern matching to actively identify Personal Identifiable Information (PII) that was input by employees in fields where it doesn’t belong (for example, comment), sometimes inadvertently and in violation of company policies.
Of the steps above, only the first can be directly addressed with Jira’s permission settings.
Since bullets 2-5 aren’t addressed by built-in Jira functionality, we’ll share some approaches to address this functionality gap later on.
Aren’t Jira attachments already encrypted?
Yes, typically they are! But since the goal is to reduce the risk of a data breach as much as possible, the specifics matter. Logically, data must be decrypted sooner or later so users can work with it. Because of this, there is a lot of variance in the handling of encryption/decryption steps and we have to consider all points in the remote access lifecycle to understand exactly when there is a risk of unauthorized access to mitigate it accordingly.
You’ll want to consider:
- encryption-at-rest (on the server)
- encryption-in-transit
- end-to-end encryption
Below are the platform-specific details of encryption supported by Jira out-of-the-box:
| Cloud | |
|---|---|
Transit | “Any customer data in Atlassian cloud products is encrypted in transit over public networks using TLS 1.2+ with Perfect Forward Secrecy (PFS) to protect it from unauthorized disclosure or modification. “
“Data drives on servers holding customer data and attachments in Jira Software Cloud, Jira Service Desk Cloud, Jira Core Cloud,” ... “use full disk, industry-standard AES-256 encryption at rest.” (Source) |
Rest | “By encryption at rest we mean that we encrypt customer data that is stored on a disk such as Jira issue data (details, comments, attachments)” (Source) |
End-to-end | Not Supported |
| Data Center | |
|---|---|
Transit | Yes, for organizations that follow Atlassian’s best practices for a reverse-proxy with SSL. |
Rest | Yes, for organizations that follow general security best practices and use one or more of:
There is no application-level encryption. |
End-to-end | Not supported |
What sort of attachments need to be encrypted?
So the only thing you’re missing is end-to-end encryption? If you can just somehow add that to the mix, all is well, right? Well, not quite.
Security discussions at the highest level end here, but the reality is more nuanced and can be considered from the perspective of attack vectors. Consider:
- What exact attacks do these levels of encryption prevent?
- Out of those attacks, which can still be achieved by some other approach?
- What types of attacks are not prevented at all?
While the depth of considerations here is too much for the scope of the article, it is worth mentioning the most relevant concerns for each type of encryption:
- Encryption-at-rest happens at one of 4 layers: Full-Disk, File-Level, Database, and Application-layer. As an example, with “just” database level encryption, anyone who gains access to your database can access the data in plain text. So, security all the way down to the application-layer is preferable.
- Encryption-in-transit isn’t necessarily all-encompassing. There still exists the possibility of a man-in-the-middle attack. And, for example, consider that communication between nodes in a cluster is done through unencrypted ehcache RMI. Failure to follow Atlassian best practices presents a level of risk here.
- End-to-end encryption isn’t a be-all / end-all solution if that means neglecting other important security concerns. User accounts are always susceptible to being compromised. This can be as obvious as an Atlassian admin using the Jira impersonate feature or a thief yanking a laptop out of your employee’s hands while it is logged in.
Strategically, adding an end-to-end encryption solution for your most sensitive data should be a high priority. Nothing is 100% foolproof, but, if it is properly implemented, end-to-end eliminates several attack vectors thereby immediately reducing your exposure.
It’s best to consider the types of information you expect to be associated with tickets on a project-by-project basis. Feel free to review the table in the 2nd section at the top of this article once more considering each project/team individually.
Based on our company’s Jira usage and feedback from customers, we believe sensitive data is only sometimes part of an internal team’s daily workflow. Don’t overlook the importance of securing data for the infrequent use case. For example, financial services users may need to apply encryption every day. But development teams may only occasionally set up new servers and domains with keys or credentials that must not be misplaced or leaked to unauthorized persons.
How can we address the shortcoming in Jira data security?
To summarize the shortcomings Jira doesn’t address with built-in functionality listed above, we need:
- Audience-specific attachment sharing
- Encryption of attachments
- Similar steps to address sensitive fields
- Automatic identification of unsecured PII
You may consider a variety of options to address each. Certain technologies your organization already has in place may be leveraged with minimal effort to help (e.g. password manager with sharing capabilities):
| Data security requirements for Jira | |
|---|---|
Audience-specific attachment sharing |
|
Encryption of attachments |
|
Encryption of sensitive field data |
|
Automatic identification of unsecured PII |
|
How can we encrypt Jira attachments right now?
Team Secrets is a Jira add-on that allows you to encrypt files end-to-end with multi-factor authentication. It provides the highest level of security available as an add-on for Jira due to the end-to-end encryption, application-layer encryption, customization options such as custom S3 storage, and administrator options to enforce multi-factor authentication at the moment data is accessed.
- Each secret is dependent on a pair of keys to decrypt. The keys are encrypted and stored separately so even with a rogue admin or compromised Jira instance, an attacker won’t be able to obtain both keys.
- Most security add-ons rely only on your existing Jira login. This defeats the purpose since a single compromised login allows access to everything.
Team Secrets also supports text with secure fields and custom fields for cases in which you don’t want to create a separate file. This approach is also lower risk, as your users will use it on-screen instead of letting a copy sit around in their Downloads directory.
It only takes a few clicks to install a trial (Data Center or Cloud) immediately giving you the ability to add encrypted content on all Jira tickets. (This can be turned on/off for each project.)
Additional Information:
Guest Author: Justin Wilson
Justin is Product Manager at Kickdrum Technology, where he leads the Team Secrets team, including developing and driving the product roadmap, addressing customer security requirements, and maintaining the integrity of the product.
