Securing your on-Prem Jira

5 augustus 2020
Secure
This time TMC ALM is looking into how to secure your on premises Jira, Server and DataCenter, instance to ensure your data is kept safe. The goal of this article is to create a starting point for securing the data in your Atlassian instance. For this we compiled a list of check points that our professionals use. We think this is good starting point to improve the security of your Atlassian instance.

Securing your on-Prem Atlassian setup

With data breaches becoming more and more common it’s important to secure your companies intellectual property from prying eyes and hackers.

This time TMC ALM is looking into how to secure your on premise Jira, Server and DataCenter, instance to ensure your data is kept safe.

The goal of this article is to create a starting point for securing the data in your Atlassian instance. For this we compiled a list of check points that our professionals use. We think this is good starting point to improve the security of your Atlassian instance.

Depending on your risk profile and the data that is stored you might want to opt for more security. Contact us for a more detailed health- or security check on your Atlassian toolset.

Getting informed

A good first start is getting informed on possible security details. Atlassian is providing different channels to stay informed.

  • The first is : https://www.atlassian.com/trust/security/advisories that gives a chronologically overview of security issues. In case you want to get pro-actively informed there is the possibility to subscribe to Atlassian product updates.
  • Register with your Atlassian account as they will actively inform you on security details by storing your email preferences at : https://my.atlassian.com/email. With this you will stay informed on any security advisories for your registered products
  • Follow our monthly Atlassian blog with monthly (security) updates on Jira/Confluence/Bitbucket and Bamboo.

General Recommendations

We have compiled a list of settings which can easily be tuned by the system administrator to make your instance more secure. Depending on your needs you can apply or fine-tune your settings.

Connect Jira to external user directory, not the internal (use organization wide policies)

  • External user directories implementations can allow for added security like Microsofts Multi Factor Authentication (MFA). So no need to implement this in the application itself.
  • By using an external directory the separation of authority also helps preventing setting up malicious accounts
  • External user directories can allow for more complex passwords and enforcements
  • Users leaving the organization are automatically disabled in the application
  • Use the Secure (Ldap) option for you external user directory since it is encrypted thereby making it impossible to listen for usernames and passwords.

Password Strength

  • Increasing password strength or policy disallows the user use easy to guess passwords. Make it easier for hackers or automated bots to guess the password. Typically it is recommended to go for a long password (min. 8 characters) and a combination of letters and special characters. Latest insights conclude that the longer the password the stronger it is. Replacing a character, for example ‘e’ with ‘3’, does not make it stronger. You can check this on websites like:

Disguising user names

  • Disguising user names – or user anonymization – makes it difficult to relate to persons or a specific person in an organization. This prevents targeting specific users in your organizations (i.e. Spear Fishing) but is also a feature to comply with the recent GDPR regulations in the EU. With this feature usernames are translated into unrelated names (e.g. “John Doe” could be translated into “userca048“. More details can be found on Atlassian page : https://confluence.atlassian.com/adminjiraserver/anonymizing-users-992677655.html

Encrypted Connections

Use personalized users accounts, prevent using team accounts

  • With team accounts there is no control or traceability on who is executing actions through the account. The risk is also that credentials for these accounts becoming a ‘public secret’. Specially after a long time these password will be shared among multiple users are employees come and go and eventually become a public secret.

Use a limited set of permission scheme(s)

  • Reduce the number of permission schemas and try to apply re-use. It greatly improves the way you can review and control the access schemes.
  • Avoid Permissions given to “Anyone”. This basically opens up data to the outside world.
  • Use, if available, an existing, IdM (Identity Access Management) systems to reduce management and (optionally) introduce separation of responsibilities
  • Set your permissions on a need to know basis.

System Settings

Set Private sign-up

  • First, ideally users should ideally be managed in an externally IdP (see General Recommendations above on user management)
  • By setting private sign-up the addition of users is managed by the administrator, preventing users to apply for a new account.

Set Captcha to avoid bot users trying to login, automated login attempts

  • Setting up a Captcha mechanism prevents users from brute-forcing or guessing password quickly in succession. Setting a number after an amounts of failed logins drastically reduced the speeds at which passwords can be guessed. Typically this can be set to 3 to 5 tries before a Captcha is applied.

Disable Email visibility to prevent spamming (only applicable for public instances)

  • Setting this option is to prevent web ‘crawlers’ to harvest emails from your instance and use them for advertisement or worse: targeted e-mails attacks (so called Spear Fishing)

Prevent use of HTML code in project description and custom fields (javascript injection)

  • Using HTML code in project descriptions and or custom fields is rarely used and can lead to code injection. Where extra code are inserted in the HTML code which can perform unwanted function.

Whitelisting, restricting in and outgoing connection

  • Probably limited use as it will probably only see the proxy, This can be found in Jira > System WhiteList

Permissions for authenticated users only

  • Prevent using permission set to “Anyone” or “Anonymous” as this opens up information for the public.

Prevent sharing dashboards with web-users / public users

  • Enabling this option allows a dashboard to be made publicly to unauthenticated or users outside of your organisation. Thereby potentially disclosing confidential information.

Auditing

Set Jira/Confluence audit log to sufficient timeframe to log configuration changes

  • Ideally set to a long timeframe to monitor changes to your system configuration. The logging is not taking up to much space so it advised to take a long timespan: i.e. 365 days.

Perform regular security audits

( Tip: Jira v8.8+ has improved security audit. Data center option to log to external syslog )

Add external safety

Besides configuring your Atlassian product for optimal safety an extra layer of security can be added by adding a WAF (Web Application Firewall).

Companies like Cloudflare have different service packages that can cater for your needs. They offer excellent services for improving the speed of your websites, handling DDOS attacks, packet injects and analytics.

Add 2FA or MFA to your instance

Another feature, not available out of the box on server, is adding 2FA (two Factor Authentication) or MFA (Multi Factor Authentication) to your Atlassian stack.

With this feature an extra layer of security is added to your instance as users have to authenticate with another device, typically a mobile phone, to authenticate their access. We at TMC have expertise in setting this up from the Atlassian side and this can be combined with SSO (Single Sign On) so users are automatically authenticated and logged into their Atlassian products. Contact up for setting up such an implementation.

3rd Party Application Access

Some clients like to interface with Atlassian applications using the REST interface. It allows using Basic Authentication, with plain username and password, but even better is to use specific and dedicated API tokens.

Basic Auth for Cloud is already deprecated because of not being secure enough.

Other Sources and Guidelines

Below is a list of website with more information on generally securing your software for on-line use

Contact

We hope these tips and tricks can be of help for securing your Atlassian data. Remember to contact us if you have any (support) questions. Based on your wishes and needs we perform a health-check and tooling upgrade one or more times per year. Of course we also pro-actively inform you of any security critical updates.  Please feel free to reach out to us if you want to receive more information about our services.