Support Resources for Users & Admins

Our Approach to Security

In this section, we discuss Atlassian’s approach to security. It covers the key steps we take and controls we implement across a number of security domains, both in securing our own environments (including our cloud-based platforms), and the processes we have in place to ensure we create products that are secure as possible for our customers and users.

Our security philosophy

Our approach to security is based around a couple of core themes:

• We want to lead our peers in cloud and product security
• Meet all customer requirements for cloud security and exceed requirements for industry security standards and certifications
• Being open and transparent about our programs, processes, and metrics. This includes sharing our journey and encouraging other cloud providers to do the same, and setting new standards for customers

In this section we highlight the range of measures and initiatives we have in place to fulfill this philosophy as covered by these key themes.

We’re also proud of the fact that many of our flagship products underpin and form a critical part of our internal day-to-day processes and workflows at Atlassian. For example, our Jira and Confluence applications form key pillars of our approach to incident management and vulnerability management programs. That means we’re invested in securing our products not only because one of our key values is we “don’t #@!% our customers”, but because we use those same products ourselves.

Our team

We know most companies would say this, but we’re extremely proud of our security team. We believe we have recruited and grown a team that consists of some of the best and brightest in the industry. Our Security Team is headed up by our San Francisco based CISO and includes over 100 people based across our Sydney, Amsterdam, Bengaluru, Austin, Mountain View, San Francisco and New York offices with some remote team members. The team is continually growing in recognition of the priority Atlassian places on security. We have multiple sub-teams, including:

• Product security – responsible for the security of our products and platforms
• Ecosystem security – responsible for the security of our Marketplace and add-ons
• Security intelligence – responsible for detecting and responding to security incidents
• Red team - responsible for adversary emulation and exercising Security Intelligence
• Security architecture – responsible for defining the security requirements of our products and platforms
• Corporate security – responsible for our internal security with respect to our corporate network and applications
• Trust - responsible for tracking and responding to customer expectations and provide transparency into our processes and practices
• Development and SRE – responsible for building and running tooling for the security team
• Awareness and training - responsible for ensuring our employees and partners know how to work securely

While our security team continues to expand, everyone at Atlassian is part of our mission to achieve better security and this is made clear to all of our staff throughout their time with us. We want have a goal to lead our peers in cloud security, meet all customer requirements for cloud security, exceed requirements for all industry security standards and certifications and be proud to publish details about how we protect customer data. Our goals and vision are made clear to all of our staff throughout their time here at Atlassian.

Additional programs we use to support security

While we focus on the fundamentals of security , we also have a range of programs in place to ensure our approach to security remains wide-reaching,  and proactive. These include:

‍

Security Champions Program
We have security leads within all of our product and service teams who assume responsibility for delivering on key security initiatives among their peers on an ongoing basis and keeping communication with our central security team as open as possible. In this way, we keep security front and center of mind across our organization.

‍

‍

Security Detections Program
Our security detections program compliments Atlassian’s incident response processes. Embedded within our standard incident management process, we have a separate program to proactively create searches and alerts for not only the incident types we face today, but those we will face in the threat landscape of the future.

‍

‍

Bug Bounty Program
Our Bug Bounty Program has consistently been recognized as one of the best in the industry, and enables us to leverage a trusted community of tens of thousands of researchers to test our products constantly and report any vulnerabilities they find.

Continually improving our security program

We are intent on ensuring our security program remains cutting edge and leading peers in the industry. We know to do that, we need to continually evaluate our current approach to security (including in comparison to our industry peers) identify opportunities for improvement.

To this end, we have undertaken (and will continue to undertake) numerous maturity assessments of our security program, using independent security consulting companies. In 2020, we also performed a peer assessment of our overall Trust and Security Program. We take the outputs from these processes, including key recommendations, and use them to address any gaps and opportunities for improvement.

We have also defined a series of programs across our various security – such as Product Security and Security Intelligence – to guide our internal improvement. We have defined metrics to support each of these programs which we review through our Security Management Team. We use these metrics to identify and target areas for improvement across each of our core capabilities.

More information

While this paper will provide a broad overview of our approach to security, more detail regarding our security program is available on our Atlassian Trust Center. There’s also a range of dedicated web pages and whitepapers detailing different areas of our security program available, including:

• How Atlassian Manages Customer Data
• Our Approach to External Security Testing
• Our Approach to Managing Security Incidents
• Our Approach to Vulnerability Management
• Cloud Security Shared Responsibilities
• Our Atlassian Trust Management System
• Our Atlassian Security & Technology Policies

Securing our internal environment

An effective approach to security starts with getting our own house in order – specifically by keeping our own internal environments secure. There are a number of steps we take to achieve this.

Building security into our network architecture

Atlassian practices a layered approach to security for our networks. We implement controls at each layer of our cloud environments, dividing our infrastructure by zones, environments, and services. We have zone restrictions in place that include limiting office/staff, customer data, CI/CD and DMZ network traffic. We also have environment separation to limit connectivity between production and non-production environments, and production data is not replicated outside of production environments. Access into production networks and services is only possible from within those same networks – e.g. only a production service can access another production service.

Services must be explicitly authorized to communicate with other services through an authentication allowlist. We control access to our sensitive networks through the use of virtual private cloud (VPC) routing, firewall rules, and software defined networking, with all connections into those networks encrypted. We’ve also implemented intrusion detection in both our office and production networks to detect potential compromises.

Securing access to our networks through ZeroTrust

Atlassian secures access to its corporate network, internal applications and cloud environments through a concept called ZeroTrust. Simply stated, the core tenet of ZeroTrust is: “never trust, always verify.”

ZeroTrust moves away from traditional approaches for network security that rely solely on authentication of a user to determine whether a user can access resources on our network. Such an approach introduces the risk of an untrusted and insecure device potentially compromising security. As a result, many organizations have begun moving to a model in which only trusted devices are able to access their network using approaches such as mobile device management technologies or restricting access at a network level to a list of known devices.

While useful, these approaches lack granularity. Atlassian’s approach to ZeroTrust effectively ensures that whether users are able to access resources and services on our networks is a decision based on not only their authentication credentials, but also involves a dynamic policy decision that takes into account a range of factors to deny or allow access at a per-resource level based on the security posture of the user’s device (regardless of their location).

In simple terms, we have created three tiers of resources (based on their relative criticality and sensitivity) on our network around which ZeroTrust works:

• Open tier – Any corporate user who successfully authenticates into our network can access these services
• Low tier – Access to these resources is available to an authenticated corporate user only if they are accessing our network from a trusted corporate device (devices that Atlassian owns and manages) or a managed BYOD (this is a personal device that has been enrolled into Atlassian’s MDM program)
• High tier – These resources are only available when accessed by an authenticated corporate user from an Atlassian issued corporate device. Access into our production services from our corporate network is only possible via a high-tier device and SAML authentication

Atlassian’s implementation of ZeroTrust works using a range of automated processes, services and components. At a high level:

• Authenticated users on corporate or managed BYOD devices are granted a certificate by our Trust Engine service. The certificate includes metadata that marks whether it is for a BYOD or corporate device. These are deployed onto devices using our endpoint management solutions and reissued (or revoked) on a regular basis
• When a user authenticates, their certificate is requested and presented to our infrastructure. The information from the certificate is used to verify the user’s account is valid and what type of device they have. Based on this information, the user is pushed either into our low tier network where their network and application access is restricted, or they are granted access to our high tier · Devices connected to Atlassian’s network are polled on an hourly basis and cross-referenced with our endpoint management solutions to determine ownership, device security and posture information. This includes ensuring devices meet minimum requirements including for antimalware, encryption, OS versions etc
• A central database is updated with information regarding the compliance of user devices. This is used to determine whether users will be allowed or denied access to resources on our network. Devices marked as non-compliant will have their connection to our network terminated.

Atlassian has written a separate paper describing our philosophy and implementation of a ZeroTrust architecture.

Managing access to our systems and services securely

Atlassian has a well-defined process for provisioning (assigning or revoking) user access for all systems and services. We have an established workflow (8-hour sync) linking our HR management system and our access provisioning system. We use role-based access control based on predefined user profiles to ensure staff only have access appropriate to their job role. All user accounts must be approved by management prior to having access to data, applications, infrastructure or network components.

Supporting our ZeroTrust architecture, we control access to our corporate applications through a single-sign on platform. To access any of our applications, staff need to authenticate via this platform, including through the use of a second factor of authentication. Users need to authenticate either through U2F keys or via a mobile application authenticator provisioned to Atlassian employees – we have removed less secure authentication methods such as SMS and phone-based OTPs. Atlassian has adopted this approach to ensure our authentication process is highly resistant to phishing-based and man-in-the-middle attacks - any system that sends codes in a text message can be compromised by a skilled attacker.

Securing our endpoint devices

Atlassian uses a combination of endpoint management to deploy updates and patches to operating systems and key applications across our endpoint fleet. We have also implemented multiple endpoint protection solutions to protect against threats such as malware.

As part of our ZeroTrust approach, Atlassian staff who wish to access most of our services via their personal mobile devices need to enrol into our Mobile Device Management (MDM) Program. This enables us to make sure all mobile devices connecting to our network meet our minimum security requirements, covering aspects such as encryption, device locking, anti-malware software and OS versions.

All eligible staff who enrol in and maintain compliance with our MDM program receive a monthly allowance from Atlassian for their participation.

Any device identified as being not compliant will result in that staff member receiving an email notifying them of the non-compliance. Staff are given a 24- hour grace period to remediate the non-compliance before their access from that device is removed.

Security in our day-to-day operations

We strive hard to build security into all aspects of our day-to-day operational processes. We want security to be an inherent part of how we do things so that we minimise the need to ‘retrofit’ or ‘bolton’ security after-the-fact.

Keeping track of our information assets

Our production systems are located in infrastructure obtained through cloud service providers. These systems are not tracked at a hardware level due to the nature of the service. The underlying microservices that our products run on are tracked in a custom-built ‘Service’ database. This database is updated automatically when a service is deployed.

Our Workplace technology team maintains an asset inventory of all endpoints using our own Jira software for tracking purposes.

Managing changes in our environment

Our change management process is slightly different from a traditional one. Traditional change management processes rely on a pyramid-style change control hierarchy. That is, when someone wants to make a change, it has to be presented to a board that eventually approves or denies it.

We have embraced an open source style approach we call “Peer Review, Green Build” (PRGB). In contrast to a traditional change management process the PRGB approach requires that each change – be it a code change or an infrastructure change – is reviewed by one or more peers to identify any issues the change may potentially cause. We increase the number of reviewers based on the criticality of the change or the criticality of the systems that the change is going to impact, trusting our engineers to identify issues and then flag them before the change can go through. This process works well to provide a dynamic and adaptable way of managing changes in our environment. The green build portion of this control refers to a successful or clean build in our CI/ CD with the new changes included. If the change introduces components that do not successfully pass any of the integration, function, unit or security tests, the build is rejected and returns to the original change request to address any issues.

Managing configurations in our systems

We have a limited set of engineers and architects who are allowed to install software in our production environment. In most cases, software installation is not possible. Configuration management tools are utilised in our production environments to manage configurations and changes to servers. Direct changes made to those systems are set to be overwritten by the approved configuration pushed through those configuration management tools ensuring consistency. We rely on standard Amazon Machine Images (AMIs), all changes to either our AMIs or operating systems must be made via our standard change management process, we track and report on exception configurations, and we have implemented resource isolation so issues with services don’t impact other services. We also rely on our Peer Review / Green Build (PRGB) process to ensure multiple reviewers approve configuration changes pushed through configuration management tools. All builds are cryptographically signed and only signed builds are allowed to run in our production environment.

Making use of logs

We use a SIEM platform to aggregate logs from various sources, apply monitoring rules to those aggregated logs, and then flag any suspicious activity. Our internal processes define how these alerts are triaged, investigated further, and escalated appropriately. Key system logs are forwarded from each system where logs are read-only. The Atlassian Security Team creates alerts on our security analytics platform and monitors for indicators of compromise. Our SRE teams use this platform to monitor for availability or performance issues. Logs are retained for 30 days in hot backup, and 365 days in cold backup.

Key system logs are combined into both an internal log analysis system and an Intrusion Detection System.

Logs are a key component of our overall incident detection and response strategy which is covered in detail in ‘How we identify, protect against and respond to security threats’ section.

Business continuity and disaster recovery management

We care deeply about the resiliency of our products, not least because we – internally, in Atlassian – rely on the very same products. We appreciate that disruptions can happen. So we are determined to build-in processes to plan for disruptions, and handle disruption with minimal impact to our customers when they do occur. Our business continuity (BC) and disaster recovery (DR) programs capture the various activities done to meet those objectives.

Leadership involvement in BC and DR planning activities ensures the oversight required to make sure accountability for resiliency reaches all teams. Our BC and DR planning activities strive to achieve the right balance between cost, benefits and risk through an analysis of ‘recovery time objectives’ (RTO) and ‘recovery point objectives’ (RPO) of services. This analysis has led to us establishing a simple 4-tier system to help group services based on their respective recovery requirements – details of this approach can be found on our page on How Atlassian Manages Customer Data.

Our BC and (DR) programs involve the following activities:

1.   building-in redundancy measures to meet resiliency requirements

2.   testing and verifying those redundancy measures

3.   learning from tests to continuously keep improving BC and DR measures

We build our products to best utilise redundancy capabilities, such as availability zones and regions, offered by our cloud service providers.

We continuously monitor a wide range of metrics with the aim of detecting potential issues early. Based on those matrices, alerts are configured to notify site reliability engineers (SREs) or the relevant product engineering teams when thresholds are breached so that prompt action can be taken through our incident response process. SREs also play a key role in identifying gaps in the DR program, and work with our risk and compliance team to close those gaps. Each of our teams also include a DR champion to oversee and help manage disaster recovery aspects related to that team.

Our DR tests cover process and technology aspects, including relevant process documentation. The frequency of DR tests are done in line with the criticality tier of each service – for example, backup and recovery processes for key customer facing systems are tested quarterly. We conduct manual and ad-hoc failover tests on our systems. These tests range from less complicated tabletop simulation exercises to more complicated availability zone or regional failover tests. Regardless of the complexity of the test, we are diligent in capturing and documenting test results, analysing and identifying possible improvements or gaps, and then driving them to closure with the help of Jira tickets to ensure continuous improvement of the overall process.

We conduct annual Business Impact Assessments (BIAs) to assess the risks associated with critical services. The output of these BIAs assist in driving the strategy for DR and BC efforts. As a result, critical services are able to develop effective DR and BC plans.

Service availability

In addition to the above measures, we also publish our service availability status in real-time for our customers using our own Statuspage product. If there are any issues with any of our products, our customers will know as soon as we do.

Backups

We operate a comprehensive backup program at Atlassian. This includes our internal systems, where our backup measures are designed in line with system recovery requirements. With respect to our Atlassian Cloud offerings, and specifically referring to customer and application data, we also have extensive backup measures in place. Atlassian uses the snapshot feature of Amazon RDS (Relational database service) to create automated daily backups of each RDS instance.

Amazon RDS snapshots are retained for 30 days with support for point-in time recovery and are encrypted using AES-256 encryption. Backup data is not stored offsite but is replicated to multiple data centers within a particular AWS region. We also perform quarterly testing of our backups.

For Bitbucket, data is replicated to a different AWS region, and independent backups are taken daily within each region.

We do not use these backups to revert customer-initiated destructive changes, such as fields overwritten using scripts, or deleted issues, projects, or sites. To avoid data loss, we recommend making regular backups. Learn more about creating backups in the support documentation for your product.

‍