Close
ACSC logo

ACSC - Cloud Computing Security for Cloud Service Providers - 2023 Guidance Review

Disclaimer

The guidance provided is solely for the purpose to address how cloud customers in the public sector as well as enterprise organisations that are deemed as a regulated entity by the Australian Cyber Security Center (ACSC) and whom are considering this guidance is in reference only to Atlassian Cloud products and it’s services provided.

This report is intended solely for the information and guidance provided by Atlassian to its cloud customers on how we align with the Cloud Computing Security for Cloud Service Providers. In parallel to this, we have a dedicated Shared Responsibilities whitepaper which discusses the different responsibilities both CSP and customers are advised. The shared responsibility model does not remove the accountability and risk from customers using Atlassian Cloud products, but it does help relieve the burden as we manage and control system components and physical control of facilities; it also shifts a portion of the cost of security and compliance onto Atlassian and away from our customers.

To learn more about our commitment to safeguard customer data, visit our Security Practices page.

Risk

Reference

Mitigations

Atlassian Response

Most Effective Risk Mitigations Generally Relevant to All Types of Cloud Services

Overarching failure to maintain the confidentiality, integrity and availability of the tenant’s data

Reference

1 - General

Mitigations

Assess the cloud service and underlying infrastructure (explicitly addressing mitigations in this publication) against the ISM [1] at the appropriate classification level required to handle the tenant’s data.

Atlassian Response

Atlassian has robust mechanisms in place for assuring compliance with the Data Privacy Framework Principles, recourse for individuals who are affected by non-compliance with these Principles, and consequences for when the Principles are not followed. We do this through periodic and ad hoc self-assessment, as well as external audits and compliance reviews from time to time as necessary. In particular, we work annually with TrustArc who are a third party provider whom certify that our privacy practices are compliant with the Data Privacy Framework Principles. They stand behind our self-certification and also provide independent dispute mediation services for privacy related customer complaints. We also track and monitor compliance with Jira tickets which can be used as an audit trail, along with our self-assessments, external audits/compliance reviews, and any remediation plans we may have from time to time. We monitor data handling practices and maintain a data privacy breach program to track data privacy incidents/breaches.

 

Reference

2 - General

Mitigations

Implement security governance involving senior management directing and coordinating security-related activities including robust change management, as well as having technically skilled staff in defined security roles.

Atlassian Response

Atlassian's CISO is Bala Sathiamurthy and is based at our San Francisco office, and our Security Team has over 230 team members across Product Security, Security Intelligence, Security Architecture, Trust, Risk and Compliance and a development and SRE team across our Sydney, Amsterdam, Austin, Bengarulu, Mountain View, San Francisco and New York offices as well as a number of remote team members.

 

Reference

3 - General

Mitigations

Implement and annually test a cyber security incident response plan providing the tenant with emergency contact details, the ability to access forensic evidence normally inaccessible to them and notification of incidents.

Atlassian Response

We have a documented Security Incident Response Policy and Plan, the key principles of which include:

  • Anticipate security incidents and prepare for incident response
  • Contain, eradicate and recover from incidents
  • Invest in our people, processes and technologies to ensure we have the capability to detect and analyze an security incident when it occurs
  • Make protection of Personal data and customer data the top priority during security incidents
  • Regularly exercise the the security incident response process
  • Learn from and improve the security incident management function
  • Communicate critical security incidents to the Atlassian Leadership Group
Under this policy, Atlassian maintains a Security Incident Response plan.  For more information about our Security Incident Response process, see: Security Incident Management Process

Tenant’s data compromised in transit by malicious third party

Reference

4 - General

Mitigations

Support and use ASD approved cryptographic controls to protect data in transit between the tenant and the CSP e.g. application layer TLS or IPsec VPN with approved algorithms, key length and key management.

Atlassian Response

All customer data stored within Atlassian cloud products and services is encrypted in transit over public networks using Transport Layer Security (TLS) 1.2+ with Perfect Forward Secrecy (PFS) to protect it from unauthorized disclosure or modification. Our implementation of TLS enforces the use of strong ciphers and key-lengths where supported by the browser.

Data drives on servers holding customer data and attachments in Jira Software Cloud, Jira Service Desk Cloud, Jira Core Cloud, Bitbucket Cloud, Confluence Cloud, Statuspage, OpsGenie, and Trello use full disk, industry-standard AES-256 encryption at rest.

For encryption at rest, specifically we encrypt customer data that is stored on a disk such as Jira issue data (details, comments, attachments) or Confluence page data (page content, comments, attachments). Data encryption at rest helps guard against unauthorized access and ensures that data can only be access by authorized roles and services with audited access to the encryption keys.

Atlassian uses the AWS Key Management Service (KMS) for key management. The encryption, decryption, and key management process is inspected and verified internally by AWS on a regular basis as part of their existing internal validation processes. An owner is assigned for each key and is responsible for ensuring the appropriate level of security controls is enforced on keys.

Reference

5 - General

Mitigations

Use ASD approved cryptographic controls to protect data in transit between the CSP’s data centres over insecure communication channels such as public internet infrastructure.

Atlassian Response

Atlassian maintains Encryption & Cryptography Policies and implementation guidelines. This policy is reviewed and updated annually in line with our Policy Management Program (PMP). For more information, see: Our Atlassian Trust Management System (ATMS)

Reference

6 - General

Mitigations

Support and use ASD approved cryptographic controls to protect data at rest on storage media in transit via post/courier between the tenant and the CSP when transferring data as part of on-boarding or off-boarding.

Atlassian Response

All customer data stored within Atlassian cloud products and services is encrypted in transit over public networks using Transport Layer Security (TLS) 1.2+ with Perfect Forward Secrecy (PFS) to protect it from unauthorized disclosure or modification. Our implementation of TLS enforces the use of strong ciphers and key-lengths where supported by the browser.

Data drives on servers holding customer data and attachments in Jira Software Cloud, Jira Service Desk Cloud, Jira Core Cloud, Bitbucket Cloud, Confluence Cloud, Statuspage, OpsGenie, and Trello use full disk, industry-standard AES-256 encryption at rest.

For encryption at rest, specifically we encrypt customer data that is stored on a disk such as Jira issue data (details, comments, attachments) or Confluence page data (page content, comments, attachments). Data encryption at rest helps guard against unauthorized access and ensures that data can only be access by authorized roles and services with audited access to the encryption keys.

Atlassian uses the AWS Key Management Service (KMS) for key management. The encryption, decryption, and key management process is inspected and verified internally by AWS on a regular basis as part of their existing internal validation processes. An owner is assigned for each key and is responsible for ensuring the appropriate level of security controls is enforced on keys.

Tenant’s cloud service account credentials compromised by malicious third party [2] [3] [4] [5]

Reference

7 - General

Mitigations

Provide Identity and Access Management e.g. multi-factor authentication and account roles with varying privileges [6] for the tenant to use and administer the cloud service via the CSP’s website control panel and API.

Atlassian Response

Yes. Regarding Confluence, Jira; multi-factor authentication is available for individual accounts. For more information on how to enable multi-factor authentication, see: Enforce two-step verification

BBC still supports 2FA as of Feb 2022 and, in general, is integrated with Atlassian Access and supports additional functionality offered through Access. Enforced multi-factor authentication can be set at the organization level with Atlassian Access. For more information, see: Enforce two-step verification

Regarding Specific ProductsBitbucket supports using MFA-based SSO options. For more information, see: Enforce two-step verification | Bitbucket Cloud

Halp uses SSO via Slack OAuth and MS Teams. Slack and MS Teams provide multiple Multi-factor authentication options. For more information please see: SAML single sign-on & Azure AD Connect: Seamless single sign-on
Opsgenie supports using MFA-based SSO options. For more information, see: Configure SSO for Opsgenie
Statuspage supports using MFA-based SSO options.
Trello supports Multi-factor authentication. For more information on how to enable multi-factor authentication, see: Enabling Two-Factor Authentication for your Trello accountJira Align supports using MFA-based SSO options.

Reference

8 - General

Mitigations

Support and use ASD approved cryptographic controls to protect credentials and administrative activity in transit when the tenant uses and administers the cloud service via the CSP’s website control panel and API.

Atlassian Response

All customer data stored within Atlassian cloud products and services is encrypted in transit over public networks using Transport Layer Security (TLS) 1.2+ with Perfect Forward Secrecy (PFS) to protect it from unauthorized disclosure or modification. Our implementation of TLS enforces the use of strong ciphers and key-lengths where supported by the browser.

Data drives on servers holding customer data and attachments in Jira Software Cloud, Jira Service Desk Cloud, Jira Core Cloud, Bitbucket Cloud, Confluence Cloud, Statuspage, OpsGenie, and Trello use full disk, industry-standard AES-256 encryption at rest.

For encryption at rest, specifically we encrypt customer data that is stored on a disk such as Jira issue data (details, comments, attachments) or Confluence page data (page content, comments, attachments). Data encryption at rest helps guard against unauthorized access and ensures that data can only be access by authorized roles and services with audited access to the encryption keys.

Atlassian uses the AWS Key Management Service (KMS) for key management. The encryption, decryption, and key management process is inspected and verified internally by AWS on a regular basis as part of their existing internal validation processes. An owner is assigned for each key and is responsible for ensuring the appropriate level of security controls is enforced on keys.

Reference

9 - General

Mitigations

Enable the tenant to download detailed time-synchronised logs and obtain real-time alerts generated for the tenant’s cloud service accounts used to access, and especially to administer, the cloud service.

Atlassian Response

Key system logs are forwarded from each system to a centralized log platform, where logs are read-only. The Atlassian Security Team creates alerts on our Security Analytics Platform (Splunk) and monitors for indicators of compromise. Our SRE teams use the Platform to monitor for availability or performance issues. Logs are retained for 30 days in hot backup, and 365 days in cold backup.

Detailed key logs: Track organization activities from the audit log

Tenant’s data compromised by malicious CSP staff or malicious third party

Reference

10 - General

Mitigations

Enable the tenant to download detailed time-synchronised logs and obtain real-time alerts generated by the cloud service used by the tenant e.g. operating system, web server and application logs.

Atlassian Response

We utilize Casper (https://www.jamf.com) and OSQuery (https://osquery.io/) to manage what is logged and how long logs are retained. Logs are stored in a logically separate system and write-access to the logs is restricted to members of the Security Team. Alerts are sent to the Security Team or Service Desk when specific actions or events are identified within the logs. Our centralized logging Service (Splunk) is integrated with our security analytics infrastructure for automated analysis, and alerts are created to identify potential issues.

Our internal and external vulnerability scanners include alerting on any unexpected ports being open or other configuration changes (e.g., TLS profiles of listening servers). Alerts are sent to the Security Team or Service Desk when specific actions or events are identified within the logs.

Reference

11 - General

Mitigations

Disclose the countries and legal jurisdictions where tenant data is (or will be in the coming months) stored, backed up, processed and accessed by CSP staff for troubleshooting, remote administration and customer support.

Atlassian Response

Atlassian uses Amazon Web Services (AWS) in the US-East, US-West, Ireland, Frankfurt, Singapore, and Sydney regions (Confluence & Jira). For more information, see: Cloud Hosting Infrastructure

Regarding Specific ProductsTrello is available in AWS US-East (Ohio).Jira Align: physical location of customer data can be requested via support ticket request. See: Jira Align support

Statuspage is available in AWS US-West (Oregon, California) US-East (Ohio) regions.Opsgenie has AWS accounts in both the US and Europe. Customers shall opt-in for AWS US (Oregon, California) or EU (Frankfurt) on sign-up.

Halp is hosted at AWS in US-East-2 and US-West 2 regions.Bitbucket repositories and core application features are hosted with AWS in US-East and US-West.

Reference

12 - General

Mitigations

Perform background checks of CSP staff commensurate with their level of access to systems and data. Maintain security clearances for staff with access to highly sensitive data [7].

Atlassian Response

Yes. New Atlassians globally are required to complete a background check. Newly hired employees as a result of an acquisition have a background check performed after the acquisition date. A criminal check is run on all new hires and independent contractors - education verification, employment verification, or credit checks are added in if the role or level of the position requires it. We perform full background checks for senior executive and accounting roles.

Reference

13 - General

Mitigations

Use physically secure data centres and offices that store tenant data or that can access tenant data [8]. Verify and record the identity of all staff and visitors. Escort visitors to mitigate them accessing data without authorisation.

Atlassian Response

Our Atlassian offices are guided by our internal Physical and Environmental Security Policy including monitoring physical ingress and egress points.Our partner data centers maintain multiple compliance certifications. These certifications address physical security, system availability, network and IP backbone access, customer provisioning and problem management. Access to the data centers is limited to authorized personnel only, as verified by biometric identity verification measures. Physical security measures include: on-premises security guards, closed circuit video monitoring, man traps, and additional intrusion protection measures.AWS maintains multiple certifications for the protection of their data centers. AWS physical protection assurance information can be found at: http://aws.amazon.com/compliance/

Reference

14 - General

Mitigations

Restrict CSP staff privileged access to systems and data based on their job tasks [9]. Require re-approval every three months for CSP staff requiring privileged access. Revoke access upon termination of CSP staff employment.

Atlassian Response

Atlassian maintains restriction on the personnel that need this access for their job role and responsibilities. All tier 1 systems are managed via Atlassian centralized single sing-on (SSO) and directory solution. Users are given appropriate access rights based upon these profiles, driven via workflow from our HR management system. Atlassian utilizes MFA to access all tier 1 systems. We have enabled two-factor authentication to the hypervisor management console and AWS API and a daily audit report on all access to the hypervisor management functions. Access lists to the hypervisor management console and AWS API are reviewed quarterly. We also maintain an 8-hour sync between our HR System and our Identity store.

Reference

15 - General

Mitigations

Promptly analyse logs of CSP staff actions that are logged to a secured and isolated log server. Implement separation of duties by requiring log analysis to be performed by CSP staff who have no other privileges or job roles.

Atlassian Response

Segregation of duties controls are in place for Atlassian core products and include, but are not limited to:

  • Access controls reviews
  • HR application managed security groups
  • Change Approval/peer review/implementation (PRGB)
  • Workflow controls
SOC2 and ISO 27001 certifications are available for download at: Comprehensive Data Protection

Reference

16 - General

Mitigations

Perform a due diligence review of suppliers before obtaining software, hardware or services, to assess the potential increase to the CSP’s security risk profile.

Atlassian Response

New vendors to Atlassian are required to agree to our privacy and security addendum and policies in our contracts. The Atlassian legal and procurement departments review contracts, SLAs, and vendor internal policies to determine whether the vendor meets requirements for security, availability, and confidentiality. Atlassian maintains this public page: List of Data Subprocessors

Reference

17 - General

Mitigations

Use ASD approved cryptographic controls to protect highly sensitive data at rest. Sanitise storage media prior to repair, disposal, and tenant off-boarding with a non-disclosure agreement for data in residual backups.

Atlassian Response

Workplace Technology handles this process, equipment is sanitized and degaussed appropriately. Atlassian does not manage any physical media that supports our cloud products and services.

Data drives on servers holding customer data and attachments in Jira Software Cloud, Jira Service Desk Cloud, Jira Core Cloud, Confluence Cloud, Bitbucket Cloud, Statuspage, Opsgenie, and Trello use full disk, industry-standard AES-256 encryption at rest.

Tenant’s data compromised by another malicious/compromised tenant [10] [11] [12] [13] [14] [15] [16] [17] [18]

Reference

18 - General

Mitigations

Implement multi-tenancy mechanisms to prevent the tenant’s data being accessed by other tenants. Isolate network traffic, storage, memory and computer processing. Sanitise storage media prior to its reuse.

Atlassian Response

Atlassian is a multi-tenant SaaS application. Multi-tenancy is a key feature of Atlassian Cloud that enables multiple customers to share one instance of the Jira or Confluence application layer, while isolating each customer tenant’s application data. Atlassian Cloud accomplishes this through the Tenant Context Service (TCS). Every user ID is associated with exactly one tenant, which is then used to access the Atlassian Cloud applications. For more information, see: Security Practices
We maintain logical and physical separation of production and non-production (development) environments and methods are used to isolate these environments.
Our staging environment is logically separated (but not physically separated) but is managed under production-grade change control and access processes.

Tenant’s data unavailable due to corruption, deletion [19], or CSP terminating the account/service

Reference

19 - General

Mitigations

Enable the tenant to perform up-to-date backups in a format that avoids CSP lock-in. If an account or cloud service is terminated, immediately notify the tenant and provide them with at least a month to download their data.

Atlassian Response

Atlassian maintains a Data Retention and Destruction Standard, which designates how long we need to maintain data of different types. Data is classified in line with our Atlassian Data Security & Information Lifecycle Policy, and controls implemented based on that.For customer data on termination of an Atlassian contract, the data belonging to a customer team will be removed from the live production database and all file attachments uploaded directly to Atlassian will be removed within 14 days. The team’s data will remain in encrypted backups until those backups fall out of the 60-day backup retention window and are destroyed in accordance with our Atlassian data retention policy. In the event that a database restore is necessary within 60 days of a requested data deletion, the operations team will re-delete the data as soon as reasonably possible after the live production system is fully restored. For more information, see: Track storage and move data across products

Tenant’s data unavailable or compromised due to CSP bankruptcy or other legal action

Reference

20 - General

Mitigations

Contractually ensure that the tenant retains legal ownership of their data.

Atlassian Response

Atlassian customers retain the responsibility to ensure their use of our service is within compliance of applicable laws and regulations. More details on our specific legal agreements and policies are available at our legal resources page: https://www.atlassian.com/legal

Cloud service unavailable due to CSP’s inadequate network connectivity

Reference

21 - General

Mitigations

Support adequately high bandwidth, low latency, reliable network connectivity between the tenant and the cloud service to meet the claimed level of availability as required by the tenant.

Atlassian Response

We monitor all Cloud instances for performance and availability, but we do not currently offer a formal application availability SLA. Our support team provides an initial response time SLA, and while we have no official support resolution SLA our internal goal is to resolve all assigned cases within 48 hours. Atlassian displays statistics of our latest Cloud system status here: https://status.atlassian.com

If you elect to use our Premium or Enterprise offerings, yes, we offer SLA guarantees.

Cloud service unavailable due to CSP error, planned outage, failed hardware or act of nature

Reference

22 - General

Mitigations

Architect to meet the claimed level of availability as required by the tenant e.g. minimal single points of failure, clustering and load balancing, data replication, automated failover and real-time availability monitoring.

Atlassian Response

For our Atlassian Cloud services, Business Continuity and Disaster Recovery plans are tested at least quarterly. Multiple region availability is monitored in real time. Automated region failover tests are performed each week on pre-production environment. Automated configuration data restoration tests are performed daily on Production.

All Atlassian services perform Availability Zone resiliency tests on pre-production environment every quarter. For more information on our Business Continuity program, see: https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e.

Our Disaster Recovery plans are tested and validated by our external auditors as part of our Compliance Program. For more information, see: https://www.atlassian.com/trust/compliance/resources.

Reference

23 - General

Mitigations

Develop and annually test a disaster recovery and business continuity plan to meet the claimed level of availability as required by the tenant, e.g. enacted for incidents that cause enduring loss of CSP staff or infrastructure.

Atlassian Response

A Business Continuity and Disaster Recovery Policy and Business Continuity and Disaster Recovery Plan are in place and are reviewed annually by the Business Continuity / Disaster Recovery steering committee. All mission-critical systems, processes, or services owners ensure proper business continuity and/or disaster recovery that aligns with the tolerance for disruption in case of a disaster. BCDR plans are tested quarterly and any issues identified are addressed. For more information, see Security Practices and Atlassian's approach to resilience.

Cloud service unavailable due to genuine spike in demand or bandwidth/CPU denial of service

Reference

24 - General

Mitigations

Implement denial of service mitigations to meet the claimed level of availability as required by the tenant e.g. redundant high bandwidth external and internal network connectivity with traffic throttling and filtering.

Atlassian Response

Atlassian Security Engineering uses IPS technologies that are implemented in our office environments. Network threat protection is performed by AWS, including DDoS protection and some Web Application Firewall features.

Regarding Specific ProductsJira Align uses Cloudflare for WAF, DDOS, DNS-SEC. We use Alert Logic IDS, log analysis, and cloudtrail. We use Nexpose for scanning shared network components with Atlassian Cloud stack. We use custom Splunk log analysis.

Reference

25 - General

Mitigations

Provide infrastructure capacity and responsive automated scaling to meet the claimed level of availability as required by the tenant.

Atlassian Response

Atlassian plans capacity 6-12 months ahead, with high level strategic planning going out 36 months.

SLA/SLOs: Atlassian systems have agreed on objectives for their operational characteristics
(1) all systems have a set of SLOs that are tied to the core capabilities of those systems
(2) those SLOs are regularly reviewed on a quarterly basis (or more frequently)
(3) some Atlassian customers are provided SLAs for services provided by Atlassian. These SLAs must be backed by internal SLOs.
(4) a team that does not achieve one or more SLOs must prioritize the effort to restore the metric before any other work.

Financial consequences of a genuine spike in demand or bandwidth/CPU denial of service

Reference

26 - General

Mitigations

Enable the tenant to manage the cost of a genuine spike in demand or denial of service via contractual spending limits, real-time alerts, and configurable maximum limits for their use of the CSP’s infrastructure capacity.

Atlassian Response

For our SaaS offerings, we do not bill customers according to usage. We do not currently share capacity or user reports with tenants.

CSP’s infrastructure compromised by malicious tenant or malicious third party

Reference

27 - General

Mitigations

Use corporately approved and secured computers, jump servers, dedicated accounts, strong passphrases and multi-factor authentication, to provide customer support and administer cloud services and infrastructure.

Atlassian Response

Employees are required to enforce 2FA when available and use a password manager with random, secure passwords. Authorized employees access the production environment by authenticating to the VPN using unique strong passwords and TOTP based 2FA and then only via ssh terminal connections using passphrase protected personal RSA certificates. SSO, SSH 2FA VPN all required.

Reference

28 - General

Mitigations

Use ASD approved cryptographic controls to protect credentials and administrative activity in transit over insecure communication channels between the CSP’s data centre and CSP administrator / customer support staff.

Atlassian Response

All customer data stored within Atlassian cloud products and services is encrypted in transit over public networks using Transport Layer Security (TLS) 1.2+ with Perfect Forward Secrecy (PFS) to protect it from unauthorized disclosure or modification. Our implementation of TLS enforces the use of strong ciphers and key-lengths where supported by the browser.

Data drives on servers holding customer data and attachments in Jira Software Cloud, Jira Service Desk Cloud, Jira Core Cloud, Bitbucket Cloud, Confluence Cloud, Statuspage, OpsGenie, and Trello use full disk, industry-standard AES-256 encryption at rest.

For encryption at rest, specifically we encrypt customer data that is stored on a disk such as Jira issue data (details, comments, attachments) or Confluence page data (page content, comments, attachments). Data encryption at rest helps guard against unauthorized access and ensures that data can only be access by authorized roles and services with audited access to the encryption keys.

Atlassian uses the AWS Key Management Service (KMS) for key management. The encryption, decryption, and key management process is inspected and verified internally by AWS on a regular basis as part of their existing internal validation processes. An owner is assigned for each key and ensures the appropriate level of security controls is enforced on keys.

Reference

29 - General

Mitigations

Implement network segmentation and segregation [20] between the internet, CSP infrastructure used by tenants, the network that the CSP uses to administer cloud services and infrastructure, and the CSP’s corporate LAN.

Atlassian Response

Customer data is never to be replicated outside of the production environment, which is stored within AWS' secure servers. Strict firewall rules are in place thus limiting access to the production environment to our VPN network and authorized systems. VPN requires multi-factor authentication. Segregation of duties controls are in place for Atlassian core products and include, but are not limited to:

  • Access controls reviews
  • HR application managed security groups
  • Change Approval/peer review/implementation (PRGB)
  • Workflow controls
SOC2 and ISO 27001 certifications are available for download at: Comprehensive Data Protection

Reference

30 - General

Mitigations

Utilise secure programming practices for software developed by the CSP [21] [22] [23].

Atlassian Response

Atlassian performs secure development practices across all the phases of the development lifecycle. Please See: Security in Software Development at Atlassian for more information.

At the design phase, practices including threat modeling, design review, and our regularly updated library of security standards ensure security requirements are considered.

During development, we rely on a mandatory peer review process as the first line of security review. This is supported by automated static analysis checks (SAST) and manual security testing (both by internal teams and 3rd-party experts as dictated by our risk assessment process). Development is also supported by application security training programs and a security knowledge-base maintained by the security team.

Formal operational readiness and change control processes then ensure that only approved changes are deployed to production. Post-deployment we employ regular automated vulnerability scanning and an industry-leading bug bounty program (https://bugcrowd.com/atlassian) to provide continuous assurance of our applications.

Reference

31 - General

Mitigations

Perform secure configuration, ongoing vulnerability management, prompt patching, annual third party security reviews and penetration testing of cloud services and underlying infrastructure.

Atlassian Response

We engage third-party consultancies to perform annual penetration tests on externally facing applications. We also supplement these tests with smaller, ongoing security testing engagements performed by our internal security testing team. The Letters of Assessment for these penetration tests can be found here, along with more information about our testing process: Approach to External Security Testing

In addition, we engage with BugCrowd to maintain a Bug Bounty program, to conduct ongoing vulnerability assessments of our publicly available products and services; the program is available at: https://bugcrowd.com/atlassian. We do share ongoing pen testing results from our Bug Bounty program at: Approach to External Security Testing

All vulnerabilities found are subject to our security bug fix policy, which defines Service Level Objectives (SLOs), calculated based on the severity levels for each security issue. The resolution timeframes for this, and more details about the policy can be found at: Security Bugfix Policy Details on our Vulnerability Management program can be found at: Atlassian Vulnerability Management

For more information on how we incorporate security into our development practices, please see: Security in Software Development at Atlassian

Reference

32 - General

Mitigations

Train all CSP staff, especially administrators, on commencement of employment and annually, to protect tenant data, maintain cloud service availability, and proactively identify security incidents e.g. via prompt log analysis.

Atlassian Response

Atlassian provides information security training as an element of onboarding training ('Rocketfuel') for new starters, and on an ongoing basis to all staff. Candidates and contractors are required to sign a confidentiality agreement prior to starting with the company. In the event of a technology change or other major shift, courses are made available and announced to existing employees through our intranet.

In addition to this general information security training, more targeted training is provided for our developers on secure coding, and is supported through our embedded security engineers program. Atlassian also provides ongoing topical training related to malware, phishing, and other security concerns. Atlassian staff and contractors are subject to identification and worker eligibility verification.

Most Effective Risk Mitigations Particularly Relevant to IaaS

Tenant’s Virtual Machine (VM) compromised by malicious third party [24]

Reference

1 - IaaS

Mitigations

Provide network access controls enabling the tenant to implement network segmentation and segregation [25], including a network filtering capability to disallow remote administration of their VMs except from their IP address.

Atlassian Response

This is not applicable. Atlassian is a SaaS provider.

Reference

2 - IaaS

Mitigations

Provide the tenant with securely configured and patched VM template images. Avoid assigning a weak administrative passphrase to newly provisioned VMs.

Atlassian Response

This is not applicable. Atlassian is a SaaS provider.

Most Effective Risk Mitigations Particularly Relevant to PaaS

Tenant’s data compromised by malicious third party

Reference

1 - PaaS

Mitigations

Harden and securely configure operating system, web server and platform software. Limit inbound and outbound network connectivity to only required ports/protocols. Promptly perform patching and log analysis.

Atlassian Response

This is not applicable. Atlassian is a SaaS provider.

Most Effective Risk Mitigations Particularly Relevant to SaaS

Tenant’s data compromised by malicious third party

Reference

1 - SaaS

Mitigations

Implement controls specific to the cloud service e.g. for email delivered as a service, provide features including content filtering with automated dynamic analysis of emails and email attachments.

Atlassian Response

We provide this within our products. Atlassian utilizes Proofpoint (https://www.proofpoint.com/au/products/email-protection) to scan attachments and rewrites URLs to block phishing attempts. Atlassian also utilizes email protections that are built into Google G-Suite (Cloud security and data protection services)

Reference

2 - SaaS

Mitigations

Implement general controls [26] e.g. limited inbound and outbound network connectivity to only required ports/protocols, antivirus software updated daily, intrusion prevention systems and prompt log analysis.

Atlassian Response

Not Applicable. Atlassian does not have anti-malware on our Production Servers as they are not writable by anything except our CI/CD pipeline. The Atlassian application services that host Jira Cloud or Confluence Cloud only host the application code and nothing else. The Jira & Confluence Cloud servers are not writable by anything except the Atlassian deployment pipeline / CI/CD pipeline.

Any customer-generated content lives in the database servers / RDS, and any attachments or other items are saved in a common Media Services service, which is basically just a front-end for an S3 bucket. The Atlassian anti-Abuse team can remove attachments in Media Services that are identified as malware or other abhorrent material but don’t actively scan for malware. We rely on our own endpoint detection capabilities, as well as customer malware detection.

Atlassian uses Crowdstrike Falcon on all Windows Servers. Atlassian updates signatures from Crowdstrike daily, which includes any malware that the vendor Crowdstrike is aware of.