Monetary Authority of Singapore (MAS)

Introduction

1.1

The Monetary Authority of Singapore (MAS) is the central bank and financial regulatory authority of Singapore. MAS issued the Technology Risk Management (TRM) guidelines which set out risk management principles and best practices to guide financial institutions (FIs) to establish robust technology risk governance and oversight, as well as maintain IT and cyber resilience.

Your agreement with Atlassian governs the terms of use for Atlassian’s products and services, however, we have also provided guidance on how we assist MAS supervised financial institutions in considering the Technology Risk Management Guidelines. If you would like to understand how these guidelines apply to your specific agreement, please contact our Enterprise Sales Team at https://www.atlassian.com/enterprise/contact?formType=product-features.

Atlassian Cloud Security Shared Responsibilities

Security is a top priority and we must work together to protect your mission-critical applications and make informed decisions. Atlassian products are built with security at the core and our dedicated security teams safeguard your data by monitoring risk and responding quickly.

In Cloud, Atlassian focuses on the security, compliance, and reliability of the applications, the systems they run on, and the environment those systems are hosted within. We ensure your systems and environments are compliant with relevant standards, including ISO27001, SOC2, GDPR, and many others that live with our Trust Center.

You, our customers, manage the data within your accounts, the users and user accounts accessing your data, and control which Marketplace Apps (formerly called “add-ons”) you install and trust. When using our applications, you are responsible for ensuring your organization is using our products in a compliant way.

The guidance provided will articulate the responsibilities both shared between Atlassian and you, our customer. If you would like to learn more about Atlassian’s Shared Responsibility Model, please download our white paper.

Technology Risk Management (TRM) Guidelines

Technology Risk Governance and Oversight

Management of Third Party Services

3.4.2

The FI should assess and manage its exposure to technology risks that may affect the confidentiality, integrity and availability of the IT systems and data at the third party before entering into a contractual agreement or partnership.

To help you with compliance and reporting, we share information, best practices, and provide easy access to documentation around the functionality of our products. Our products regularly undergo independent verification of security, privacy, and compliance controls, achieving certifications against global standards to earn your trust.
 
In addition, Atlassian has well-defined and documented policies and procedures for ensuring the proper review and approval of new or updated ISMS documentation. Our Atlassian Trust Management System (ATMS) is defined and documented internally, and updated annually. Our Policy Management Program (PMP) has been defined and includes ownership, availability, review cycles and outlines our general objectives. Our policies are reviewed at least annually and approved by senior management. Document control procedure is established and currently being practiced under the Atlassian PMP. All documents are maintained in Confluence and version controlling, ownership, reviews & approvals are managed appropriately with the built in page history in Confluence and with Jira tracking. More information about our PMP can be found at: https://www.atlassian.com/trust/security/security-management-program. We have also published excerpts of each of our high level policies with tl;dr, which can be found at https://www.atlassian.com/trust/security/ismp-policies.

3.4.3

On an ongoing basis, the FI should ensure the third party employs a high standard of care and diligence in protecting data confidentiality and integrity as well as ensuring system resilience.

This is a customer consideration. Please also see row 7 (3.4.2), above.

Competency and Background Review

3.5.1

As the human element plays an important role in managing IT systems and processes in an IT environment, the FI should ensure personnel, including contractors and service providers, have the requisite level of competence and skills to perform the IT functions and manage technology risks.

Atlassian makes sure all stuff undergo security awareness training during the onboarding process and then on an ongoing basis so that security remains 'front of mind'. Topics addressed in our security awareness training program include current threats and scams, secure working practices, potentially risky behaviours that create security risks, and compliance and regulatory issues.
 
In addition to general information security training, more targeted training is available to our developers on secure coding. Development teams are also supported through both security champions or embedding a security engineer in those teams to help with security-related operational tasks.
 
Atlassian also maintains open channels of communication between our employees and the security team through instant messaging channels, blog posts, FAQs, etc., so that the security team is as accessible as possible to all Atlassian staff.
 
 For more information see: https://www.atlassian.com/trust/security/security-practices#security-awareness-training

3.5.2

Insider threat, which includes theft of confidential data, sabotage of IT systems and fraud by staff, contractors and service providers, is considered one of the risks to an organisation. A background check on personnel, who has access to the FI’s data and IT systems, should be performed to minimise this risk.

In accordance with the laws of their residence, new Atlassians are required to complete a background check. In accordance with the laws of their residence, 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, or credit checks are added in if the role or level of the position requires it. We perform full background checks for senior executives and accounting roles. (https://www.atlassian.com/trust/security/security-practices#securing-our-people)

Security Awareness and Training

3.6.1

A comprehensive IT security awareness training programme should be established to maintain a high level of awareness among all staff in the FI. The content of the training programme should minimally include information on the prevailing cyber threat landscape and its implications, the FI’s IT security policies and standards, as well as an individual’s responsibility to safeguard information assets. All personnel in the FI should be made aware of the applicable laws, regulations, and guidelines pertaining to the use of, and access to, information assets.

This is a customer consideration.

3.6.2

The training programme should be conducted at least annually for all staff, contractors and service providers who have access to the FI’s information assets.

This is a customer consideration. Please also see row 10 (3.5.1), above.

3.6.3

The board of directors should undergo training to raise their awareness on risks associated with the use of technology and enhance their understanding of technology risk management practices.

This is a customer consideration.

3.6.4

The training programme should be reviewed periodically to ensure its contents remain current and relevant. The review should take into consideration changes in the FI’s IT security policies, prevalent and emerging risks, and the evolving cyber threat landscape.

This is a customer consideration.

Technology Risk Management Framework

Risk Management Framework

4.1.1

The FI should establish a risk management framework to manage technology risks. Appropriate governance structures and processes should be established, with well defined roles, responsibilities, and clear reporting lines across the various organisational functions.

This is a customer consideration. However, we provide several resources to assist its customers in conducting the necessary risk assessments and due diligence they require. For more information on Atlassian's security and operational practices, visit Atlassian's Trust Center (https://www.atlassian.com/trust) where you will find:

• Security practices - https://www.atlassian.com/trust/security

• Compliance program - https://www.atlassian.com/trust/compliance

• Audit reports/security questionnaires - https://www.atlassian.com/trust/compliance/resources

4.1.2

Effective risk management practices and internal controls should be instituted to achieve data confidentiality and integrity, system security and reliability, as well as stability and resilience in its IT operating environment.

Our cloud products regularly undergo independent verification of their security, privacy, and compliance controls, achieving certifications, attestations of compliance, or audit reports against standards globally. You can review Atlassian's industry leading security, third party audits and certifications, documentations, and legal commitments that help support your compliance at our Compliance Resource Center (https://www.atlassian.com/trust/compliance/resources).

4.1.3

The risk owner, who is accountable for ensuring proper risk treatment measures are implemented and enforced for a specific technology risk, should be identified. The role of the risk owner may be assumed by a function or group of functions within the FI, who is given the authority to manage technology risks.

This is a customer consideration.

4.1.4

The framework should also encompass the following components:

4.1.4 (a)

a) risk identification – identify threats and vulnerabilities to the FI and information assets;

See row 20 (4.1.2), above.

4.1.4 (b)

b) risk assessment – assess the potential impact and likelihood of threats and vulnerabilities to the FI and information assets;

See row 20 (4.1.2), above.

4.1.4 (c)

c) risk treatment – implement processes and controls to manage technology risks posed to the FI and protect the confidentiality, integrity and availability of information assets; and

See row 20 (4.1.2), above.

4.1.4 (d)

d) risk monitoring, review and reporting – monitor and review technology risks, which include risks that customers are exposed to, changes in business strategy, IT systems, environmental or operating conditions; and report key risks to the board of directors and senior management.

See row 20 (4.1.2), above.

4.1.5

As business and IT environments, as well as the cyber threat landscape, tend to evolve over time, the FI should review the adequacy and effectiveness of its risk management framework regularly

To help you with compliance and reporting, we share information, best practices, and provide easy access to documentation around the functionality of our products. Our products regularly undergo independent verification of security, privacy, and compliance controls, achieving certifications against global standards to earn your trust.

Risk Identification

4.2.1

The FI should identify the threats and vulnerabilities applicable to its IT environment, including information assets that are maintained or supported by third party service providers. Examples of security threats that could have a severe impact on the FI and its stakeholders include internal sabotage, malware and data theft.

Our audit program is designed to allow qualifying customers and their supervisory authorities to audit the Covered Cloud Products effectively.
 
In addition, Atlassian offers customers the right to carry out penetration testing at any time without Atlassian’s prior approval: https://www.atlassian.com/trust/security/security-testing.
 
For all our products and service offerings, we have an extensive bug remediation process (utilising our own product Jira which captures issues and helps us to manage resolving requests). Underpinning this are numerous security bug fix policies, advisories services and SLOs that we adhere to. We take in bug reports via our Support Channel, our Bug Bounty program, and security@atlassian.com. Further information is available on our Trust Center (https://www.atlassian.com/trust) about our Security Bug Fix SLOs (https://www.atlassian.com/trust/security/bug-fix-policy).

Risk Assessment

4.3.1

The FI should perform an analysis of the potential impact and consequences of the threats and vulnerabilities on the overall business and operations. The FI should take into consideration financial, operational, legal, reputational and regulatory factors in assessing technology risks.

This is a customer consideration. Please also see row 29 (4.2.1), above.

4.3.2

To facilitate the prioritisation of technology risks, a set of criteria measuring and determining the likelihood and impact of the risk scenarios should be established.

This is a customer consideration.

Risk Treatment

4.4.1

The FI should develop and implement risk mitigation and control measures that are consistent with the criticality of the information assets and the level of risk tolerance. The IT control and risk mitigation approach should be subject to regular review and update, taking into account the changing threat landscape and variations in the FI’s risk profile.

This is a customer consideration.

4.4.2

As there are residual risks from threats and vulnerabilities which cannot be fully eliminated, the FI should assess whether risks have been reduced to an acceptable level after applying the mitigating measures. The criteria and approving authorities for risk acceptance should be clearly defined and it should be commensurate with the FI’s risk tolerance.

This is a customer consideration.

4.4.3

The FI should take insurance cover for various insurable technology risks to reduce financial impact such as recovery and restitution costs.

This is a customer consideration.

Risk Monitoring, Review and Reporting

4.5.1

The FI should institute a process for assessing and monitoring the design and operating effectiveness of IT controls against identified risks.

This is a customer consideration. Please also see row 20 (4.1.2) and 29 (4.2.1), above.

4.5.2

A risk register should be maintained to facilitate the monitoring and reporting of technology risks. Significant risks should be monitored closely and reported to the board of directors and senior management. The frequency of monitoring and reporting should be commensurate with the level of risk.

This is a customer consideration. Please also see row 20 (4.1.2), above.

4.5.3

To facilitate risk reporting to management, technology risk metrics should be developed to highlight information assets that have the highest risk exposure. In determining the technology risk metrics, the FI should take into account risk events and audit observations, as well as applicable regulatory requirements.

This is a customer consideration. Please also see row 20 (4.1.2), above.

IT Project Management and Security-by-Design

Project Management Framework

5.1.1

A project management framework should be established to ensure consistency in project management practices, and delivery of outcomes that meets project objectives and requirements. The framework should cover the policies, standards, procedures, processes and activities to manage projects from initiation to closure.

This is a customer consideration.

5.1.2

Detailed IT project plans should be established for all IT projects. An IT project plan should set out the scope of the project, as well as the activities, milestones and the deliverables to be realised at each phase of the project. The roles and responsibilities of staff involved in the project should be clearly defined in the plan.

This is a customer consideration.

5.1.3

Key documentation in the IT project life cycle, including the feasibility analysis, cost-benefit analysis, business case analysis, project plan, as well as the implementation plan, should be maintained and approved by the relevant business and IT management.

This is a customer consideration.

5.1.4

As project risks can adversely impact the IT project delivery timeline, budget and quality of the project deliverables, a risk management process should be established to identify, assess, treat and monitor the attendant risks throughout the project life cycle.

This is a customer consideration.

Project Steering Committee

5.2.1

For large and complex projects that impact the business, a project steering committee consisting of key stakeholders, including business owners and IT, should be formed to provide direction, guidance and oversight to ensure milestones are reached, and deliverables are realised in a timely manner.

This is a customer consideration.

5.2.2

Risks and issues for large and complex projects, which cannot be resolved at the project management level, should be escalated to the project steering committee and senior management.

This is a customer consideration.

System Acquisition

5.3.1

The FI should establish standards and procedures for vendor evaluation and selection to ensure the selected vendor is qualified and able to meet its project requirements and deliverables. The level of assessment and due diligence performed should be commensurate with the criticality of the project deliverables to the FI.

See row 19 (4.1.1), above.

5.3.2

It is important that the FI assesses the robustness of the vendor’s software development and quality assurance practices, and ensures stringent security practices are in place to safeguard and protect any sensitive data the vendor has access to over the course of the project. Any vendor access to the FI’s IT systems should be controlled and monitored.

See row 19 (4.1.1), above.

5.3.3

If a project involves a commercial off-the-shelf (COTS) solution that does not meet the FI’s security requirements, the FI should assess the risks and ensure adequate mitigating controls are implemented to address the risks before the solution is deployed.

This is a customer consideration.

5.3.4

The FI should assess if a source code escrow agreement should be in place, based on the criticality of the acquired software to the FI’s business, so that the FI can have access to the source code in the event that the vendor is unable to support the FI. Suitable alternatives to replace the software should be identified if an escrow agreement could not be implemented.

This is a customer consideration.
 
However, access to our application, program or object source code is restricted to our developer teams. At Atlassian, we have robust open peer review system to ensure changes to source code are reviewed by multiple Senior or Lead Developers.

System Development Life Cycle and Security-By-Design

5.4.1

The FI should establish a framework to manage its system development life cycle (SDLC). The framework should clearly define the processes, procedures and controls in each phase of the life cycle, such as initiation/planning, requirements analysis, design, implementation, testing and acceptance. Standards and procedures for the different phases of the SDLC should be maintained.

This is a customer consideration.

5.4.2

The security-by-design approach refers to building security in every phase of the SDLC in order to minimise system vulnerabilities and reduce the attack surface. The FI should incorporate security specifications in the system design, perform continuous security evaluation, and adhere to security practices throughout the SDLC.

This is a customer consideration.

5.4.3

Security requirements should minimally cover key control areas such as access control, authentication, authorisation, data integrity and confidentiality, system activity logging, security event tracking and exception handling.

This is a customer consideration.

5.4.4

The SDLC should, where relevant, involve the IT security function in each phase of the life cycle.

This is a customer consideration.

System Requirements Analysis

5.5.1

The FI should identify, define and document the functional requirements for the IT system. In addition to functional requirements, key requirements such as system performance, resilience and security controls, should also be established and documented.

This is a customer consideration.

5.5.2

In establishing the security requirements, the FI should assess the potential threats and risks related to the IT system, and determine the acceptable level of security required to meet its business needs.

See row 19 (4.1.1), above.

System Design and Implementation

5.6.1

As part of the design phase, the FI should review the proposed architecture and design of the IT system, including the IT controls to be built into the system, to ensure they meet the defined requirements, before implementation.

This is a customer consideration.

5.6.2

The FI should verify that system requirements are met by the current system design and implementation. Any changes to, or deviations from, the defined requirements should be endorsed by relevant stakeholders.

This is a customer consideration.

5.6.3

Relevant domain experts should be engaged to participate in the design review. For example, the security design and architecture of the IT system should be reviewed by IT security specialists or qualified security consultants.

This is a customer consideration.

System Testing and Acceptance

5.7.1

A methodology for system testing should be established. The scope of testing should cover business logic, system function, security controls and system performance under various load and stress conditions. A test plan should be established and approved before testing.

This is a customer consideration.

5.7.2

The FI should trace the requirements during the testing phase, and ensure each requirement is covered by appropriate test cases.

This is a customer consideration.

5.7.3

The FI should maintain separate physical or logical environments for unit, system integration and user acceptance testing, and restrict access to each environment on a need-to basis.

This is a customer consideration.

5.7.4

The FI should perform regression testing for changes (e.g. enhancement, rectification, etc.) to an existing IT system to validate that it continues to function properly after the changes have been implemented.

This is a customer consideration.

5.7.5

Issues identified from testing, including system defects or software bugs, should be properly tracked and addressed. Major issues that could have an adverse impact on the FI’s operations or delivery of service to customers should be reported to the project steering committee and addressed prior to deployment to the production environment.

This is a customer consideration.

5.7.6

The FI should ensure the results of all testing that was conducted are documented in the test report, and signed off by the relevant stakeholders.

This is a customer consideration.

Quality Management

5.8.1

During project planning, the FI should define the expected quality attributes and the assessment metrics for the project deliverables based on its quality control standards.

This is a customer consideration.

5.8.2

Quality assurance should be performed by an independent quality assurance function to ensure project activities and deliverables comply with the FI’s policies, procedures and standards.

This is a customer consideration.

Software Application Development and Management

Secure Coding, Source Code Review and Application Security Testing

6.1.1

Software bugs or vulnerabilities are typically targeted and exploited by threat actors to compromise an IT system, and they often occur because of poor software development practices. To minimise the bugs and vulnerabilities in its software, the FI should adopt standards on secure coding, source code review and application security testing.

This is a customer consideration.

6.1.2

The secure coding and source code review standards should cover areas such as secure programming practices, input validation, output encoding, access controls, authentication, cryptographic practices, and error and exception handling.

This is a customer consideration.

6.1.3

A policy and procedure on the use of third party and open-source software codes should be established to ensure these codes are subject to review and testing before they are integrated into the FI’s software.

This is a customer consideration. Please also see row 29 (4.2.1), above.

6.1.4

To facilitate the remediation of vulnerabilities in a timely manner, the FI should keep track of updates and reported vulnerabilities for third party and open-source software codes that are incorporated in the FI’s software.

This is a customer consideration. Please also see row 29 (4.2.1), above.

6.1.5

The FI should ensure its software developers are trained or have the necessary knowledge and skills to apply the secure coding and application security standards when developing applications.

This is a customer consideration.

6.1.6

It is essential for the FI to establish a comprehensive strategy to perform application security validation and testing. The FI may use a mixture of static, dynamic and interactive application security testing methods (refer to Annex A on Application Security Testing) to validate the security of the software application. The software validation and testing rules should be reviewed periodically and kept current.

This is a customer consideration. Please also see row 29 (4.2.1), above.

6.1.7

All issues and software defects discovered from the source code review and application security testing should be tracked. Major issues and software defects should be remediated before production deployment.

This is a customer consideration.

Agile Software Development

6.2.1

Agile software development is based on an iterative and incremental development model to accelerate software development and delivery to respond to business and customer needs. When adopting Agile software development methods, the FI should continue to incorporate the necessary SDLC and security-by-design principles throughout its Agile process.

This is a customer consideration.

6.2.2

The FI should ensure secure coding, source code review and application security testing standards are applied during Agile software development.

This is a customer consideration.

DevSecOps Management

6.3.1

DevSecOps is the practice of automating and integrating IT operations, quality assurance and security practices in the software development process. It constitutes continuous integration, continuous delivery and IT security practices for frequent, efficient, reliable and secure development, testing and release of software products. The FI should ensure its DevSecOps activities and processes are aligned with its SDLC framework and IT service management processes (e.g. configuration management, change management, software release management).

This is a customer consideration.

6.3.2

The FI should implement adequate security measures and enforce segregation of duties for the software development, testing and release functions in its DevSecOps processes.

This is a customer consideration.

Application Programming Interface Development

6.4.1

Application programming interfaces (APIs) enable various software applications to communicate and interact with each other and exchange data. Open APIs are publicly available APIs that provide developers with programmatic access to a software application or web service. FIs may collaborate with FinTech companies and develop open APIs, which are used by third parties to implement products and services for customers and the marketplace. Hence, it is important for the FI to establish adequate safeguards to manage the development and provisioning of APIs for secure delivery of such services.

This is a customer consideration.

6.4.2

A well-defined vetting process should be implemented for assessing third parties’ suitability in connecting to the FI via APIs, as well as governing third party API access. The vetting criteria should take into account factors such as the third party’s nature of business, cyber security posture, industry reputation and track record.

This is a customer consideration.
 
However, Atlassian documents details on our Cloud APIs, which can be found at: https://developer.atlassian.com/explore-the-apis/
 
 Specific Product API details:

• - Trello: API documentation is available at: https://developer.atlassian.com/cloud/trello

• - Jira Align: API can be found at: https://help.jiraalign.com/hc/en-us/articles/360045371954-Getting-started-with-the-REST-API-2-0

• - Statuspage: API can be found at: https://doers.statuspage.io/api/v1

• - Opsgenie: API can be found at: https://docs.opsgenie.com/docs/api-overview

• Halp: does not have a public API at this time.

6.4.3

The FI should perform a risk assessment before allowing third parties to connect to its IT systems via APIs, and ensure the implementation for each API is commensurate with the sensitivity and business criticality of the data being exchanged, and the confidentiality and integrity requirements of the data.

This is a customer consideration.

6.4.4

Security standards for designing and developing secure APIs should be established. The standards should include the measures to protect the API keys or access tokens, which are used to authorise access to APIs to exchange confidential data. A reasonable timeframe should be defined and enforced for access token expiry to reduce the risk of unauthorised access.

This is a customer consideration.

6.4.5

Strong encryption standards and key management controls should be adopted to secure transmission of sensitive data through APIs.

This is a customer consideration.
 
However, at Atlassian, secrets are managed using Vault. Vault features the secure storage of credentials using Transparent Data Encryption. Atlassian also maintains encryption keys in AWS KMS. See the Vault whitepaper at https://www.hashicorp.com/resources/unlocking-the-cloud-operating-model-security/ for more information.

6.4.6

A robust security screening and testing of the API should be performed between the FI and its third parties before it is deployed into production. The FI should log the access sessions by third parties, such as the identity of the party making the API connections, date and time, as well as the data being accessed.

This is a customer consideration. Please also see row 29 (4.2.1), above.

6.4.7

Detective measures, such as technologies that provide real-time monitoring and alerting, should be instituted to provide visibility of the usage and performance of APIs, and detect suspicious activities. Robust measures should be established to promptly revoke the API keys or access token in the event of a breach.

This is a customer consideration.

6.4.8

The FI should ensure adequate system capacity is in place to handle high volumes of API call requests, and implement measures to mitigate cyber threats such as denial of service (DoS) attacks.

This is a customer consideration.

Management of End User Computing and Applications

6.5.1

The prevalence of business application tools and software on the Internet has enabled end user computing, where business users develop or use simple applications to automate their operations, such as performing data analysis and generating reports. IT hardware, software and services that are not managed by the IT department (shadow IT) increase the FI’s exposure to risks such as leakage of sensitive data or malware infection. Shadow IT should be managed as part of the FI’s information assets.

This is a customer consideration.

6.5.2

The FI should establish measures to control and monitor the use of shadow IT in its environment.

This is a customer consideration.

6.5.3

A process should be established to assess the risk of end user developed or acquired applications to the FI, and ensure appropriate controls and security measures are implemented to address the identified risks, and approval is obtained before being used. The FI should ensure proper testing before the applications are deployed.

This is a customer consideration. Please also see row 29 (4.2.1), above.

IT Service Management

IT Service Management Framework

7.1.1

A robust IT service management framework is essential for supporting IT services and operations, tracking information assets, managing changes, responding to incidents, as well as ensuring the stability of the production IT environment. The framework should comprise the governance structure, processes and procedures for IT service management activities including configuration management, technology refresh management, patch management, change management, software release management, incident management and problem management.

This is a customer consideration.

Configuration Management

7.2.1

Configuration management is the process of maintaining key information (e.g. model, version, specifications, etc.) about the configuration of the hardware and software that makes up each IT system. The FI should implement a configuration management process to maintain accurate information of its hardware and software to have visibility and effective control of its IT systems.

This is a customer consideration.

7.2.2

The FI should review and verify the configuration information of its hardware and software on a regular basis to ensure it is accurate and up-to-date.

This is a customer consideration.

Technology Refresh Management

7.3.1

The FI should avoid using outdated and unsupported hardware or software, which could increase its exposure to security and stability risks. The FI should closely monitor the hardware’s or software’s end-of-support (EOS) dates as service providers would typically cease the provision of patches, including those relating to security vulnerabilities that are found after the EOS date.

This is a customer consideration.

7.3.2

A technology refresh plan for the replacement of hardware and software should be developed before they reach EOS. A risk assessment for hardware and software approaching EOS date should be conducted to evaluate the risks of their continued use, and effective risk mitigation measures should be implemented.

This is a customer consideration.

7.3.3

The FI should obtain dispensation from its management for the continued use of outdated and unsupported hardware and software. The dispensation should be assigned a validity period that is commensurate with the identified risks and risk mitigation measures. The dispensation should be reviewed periodically to ensure the attendant risks remain at an acceptable level.

This is a customer consideration.

Patch Management

7.4.1

A patch management process should be established to ensure applicable functional and non-functional patches (e.g. fixes for security vulnerabilities and software bugs) are implemented within a timeframe that is commensurate with the criticality of the patches and the FI’s IT systems.

This is a customer consideration.

7.4.2

Patches should be tested before they are applied to the FI’s IT systems in the production environment to ensure compatibility with existing IT systems or they do not introduce problems to the IT environment.

This is a customer consideration.

Change Management

7.5.1

The FI should establish a change management process to ensure changes to information assets are assessed, tested, reviewed and approved before implementation.

Our Atlassian Change Management process is slightly different than traditional change processes. We rely on a Peer Review and Green Build (PRGB) control on all changes, whether to code, application or infrastructure changes. Peer Review is configured in our CD tool, where critical branches must be designated to have multiple reviewers for each Pull Request. Commonly this is two developers and the Team Lead. The Green Build portion of the control means that the integration during the CI phase must pass all integration, functional, security and other tests that have been developed. If these tests fail (a Red Build), the code will not be merged and must be reviewed again and address the failures. Once a Green Build is successful, the binary is cryptographically signed and our production environment only runs binaries that are signed with our key. Our testing process includes both automated and manual assessment components. We love to blog about what we do well. Our approach to using 'Quality Assistance' (rather than traditional 'Quality Assurance') is something we are passionate about: https://www.atlassian.com/inside-atlassian/quality-assurance-vs-quality-assistance.

7.5.2

A risk and impact analysis of the change to an information asset should be conducted before implementing the change. The analysis should cover factors such as security and implications of the change in relation to other information assets.

This is a customer consideration. Please also see row 119 (7.5.1), above.

7.5.3

The FI should ensure all changes are adequately tested in the test environment. Test plans for changes should be developed and approved by the relevant business and IT management. Test results should be accepted and signed off before the changes are deployed to the production environment.

This is a customer consideration. Please also see row 119 (7.5.1), above.

7.5.4

A change advisory board, comprising key stakeholders including business and IT management, should be formed to approve and prioritise the changes after considering the stability and security implications of the changes to the production environment.

This is a customer consideration. Please also see row 119 (7.5.1), above.

7.5.5

The FI should perform a backup of the information asset prior to the change implementation, and establish a rollback plan to revert the information asset to the previous state if a problem arises during or after the change implementation.

This is a customer consideration. Please also see row 119 (7.5.1), above.

7.5.6

Urgent or emergency changes, such as a high priority security patch for an IT system, are changes that need to be implemented expeditiously and may not be able to follow the standard change management process. To reduce the risk to the security and stability of the production environment, the FI should clearly define the procedures for assessing, approving and implementing emergency changes, as well as identify the authorisers or approvers for the changes.

This is a customer consideration. Please also see row 119 (7.5.1), above.

7.5.7

Logs contain useful information which facilitates investigations and troubleshooting. As such, the FI should ensure the logging facility is enabled to record activities that are performed during the change process.

This is a customer consideration. Please also see row 119 (7.5.1), above.

Software Release Management

7.6.1

Segregation of duties in the software release process should be practised to ensure no single individual has the ability to develop, compile and move software codes from one environment to another.

Atlassian published Release Notes for our Cloud Products at: https://confluence.atlassian.com/cloud/blog.
 
 See row 119 (7.5.1), above.

7.6.2

It is important that controls are implemented to maintain traceability and integrity for all software codes that are moved between IT environments.

This is a customer consideration. Please also see row 119 (7.5.1), above.

Incident Management

7.7.1

An IT incident occurs when there is an unexpected disruption to the delivery of IT services or a security breach of an IT system, which compromises the confidentiality, integrity and availability of data or the IT system. The FI should establish an incident management framework with the objective of restoring an affected IT service or system to a secure and stable state, as quickly as possible, so as to minimise impact to the FI’s business and customers.

This is a customer consideration.
 
 At Atlassian, 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 a security incident when it occurs

• - Make protection of Personal data and customer data the top priority during security incidents

• - Regularly exercise the security incident response process

• - Learn from and improve the security incident management function

• - Communicate critical security incidents to the Atlassian Leadership Group

 
We have a classification process for incidents in which we triage them based on severity. Depending on classification, incidents are escalated to the appropriate Product Team, with our highest severity incidents reported to CTO management and Execops.
 
Under this policy, Atlassian maintains a Security Incident Response plan. For more information about our Security Incident Response process, see: https://www.atlassian.com/trust/security/security-incident-management.

7.7.2

The FI should ensure sufficient resources are available to facilitate and support incident response and recovery. The FI may engage external assistance to augment its resources to facilitate and support incident response and recovery. For example, the FI can engage an incident response and security forensic company to support cyber attack investigation, and provide 24 by 7 incident response capability.

See row 130 (7.7.1), above.

7.7.3

The incident management framework should minimally cover:

7.7.3 (a)

a) the process and procedure for handling IT incidents, including cyber related incidents;

This is a customer consideration.

7.7.3 (b)

b) maintenance and protection of supporting evidence for the investigation and diagnosis of incidents; and

This is a customer consideration.

7.7.3 (c)

c) the roles and responsibilities of staff and external parties involved in recording, analysis, escalation, decision-making, resolution and monitoring of incidents.

This is a customer consideration.

7.7.4

The FI should configure system events or alerts to provide an early indication of issues that may affect its IT systems’ performance and security. System events or alerts should be actively monitored so that prompt measures can be taken to address the issues early.

This is a customer consideration.
 
At Atlassian, we have a strong track record of timely and proactive notification of incidents, and working with our customers on any necessary mitigations.
 
Incidents can range from simple to incredibly complex, so while we can offer what is necessary under the law we cannot agree to a 'one-size fits all' timeline.

7.7.5

In some situations, a major incident may develop unfavourably into a crisis. The FI should regularly apprise its senior management of the status of major incidents so that decisions to mitigate the impact of the crisis can be made in a timely manner, such as activation of IT disaster recovery.

This is a customer consideration.
 
 Atlassian uses multiple methods to keep customers up to date with the latest news regarding CVEs and security incidents here:

1. We post regular blogs here on the Trust & Security Community Page: https://community.atlassian.com/t5/Trust-Security/gh-p/TrustandSecurity

2. We have a dedicated Security Advisories page where we keep CVEs and other incidents up to date: https://www.atlassian.com/trust/security/advisories

3. Please subscribe to: https://my.atlassian.com/email

4. Regarding Atlassian Cloud uptime, use this link: https://status.atlassian.com/

7.7.6

A communications plan that covers the process and procedures to apprise customers of impact on services, and to handle media or public queries should be maintained. The plan should also include identifying the spokespersons and subject matter experts to address the media or public queries as well as the communication channels to disseminate information.

See row 137 (7.7.5), above.

7.7.7

It would be useful for the FI to provide timely updates to its customers on the progress of its incident management and the measures the FI is implementing to protect its customers and continue delivery of financial services. Where appropriate, the FI should advise its customers on actions that they should take to protect themselves.

See row 137 (7.7.5), above.

Problem Management

7.8.1

The FI should establish problem management process and procedures to determine and resolve the root cause of incidents to prevent the recurrence of similar incidents.

See row 130 (7.7.1), above.

7.8.2

The FI should maintain a record of past incidents which include lessons learnt to facilitate the diagnosis and resolution of future incidents with similar characteristics.

See row 137 (7.7.5), above.

7.8.3

A trend analysis of past incidents should be performed by the FI to identify commonalities and patterns in the incidents, and verify if the root causes to the problems had been properly identified and resolved. The FI should also use the analysis to determine if further corrective or preventive measures are necessary.

See row 137 (7.7.5), above.

IT Resilience

System Availability

8.1.1

Maintaining system availability is crucial in achieving confidence and trust in the FI’s operational capabilities. IT systems should be designed and implemented to achieve the level of system availability that is commensurate with its business needs.

For Atlassian Cloud, we are currently hosted within redundant AWS Availability Zones (AZ). For information on specific regions, see: https://www.atlassian.com/trust/reliability/infrastructure.
 
Each AZ is designed to be isolated from failures in other AZs, and to provide inexpensive, low-latency network connectivity to other AZs in the same region. The multi-zone high availability is the first line of defence and means that services running in multi-AZ deployments should be able to withstand AZ failure.
 
 In the unlikely event that two AZs have long-term service interruptions, Atlassian Cloud has been designed to recover with limited service interruption and a maximum of 1 hour of data loss. For more information on AZs, see: https://www.atlassian.com/trust/reliability/cloud-architecture-and-operational-practices#availability-zones.
 
During the Subscription Term for which you have purchased an applicable Covered Cloud Product, we will use commercially reasonable efforts to provide a Monthly Uptime Percentage to you as defined below (“Service Level Commitment”):
 

• - Premium Cloud Products - 99.9% Monthly uptime percentage; and

• - Enterprise Cloud Products - 99.95% Monthly uptime percentage.

 
The corresponding service level terms, as well as the remedies for not meeting service levels, for the Covered Cloud Products are provided for in our Service Level Agreement (https://www.atlassian.com/legal/sla) and the corresponding Product Specific Terms (https://www.atlassian.com/legal/product-specific-terms#trello-specific-terms).

8.1.2

Redundancy or fault-tolerant solutions should be implemented for IT systems which require high system availability. The FI should perform a periodic review of its IT system and network architecture design to identify weaknesses in the existing design. The review should include a mapping of internal and external dependencies of the FI’s IT systems to determine any single point of failure. It is important that the FI conducts regular testing to ascertain that the level of resilience continues to meet its business requirements.

This is a customer consideration. Please also see row 146 (8.1.1), above.

8.1.3

The FI should continuously monitor the utilisation of its system resources against a set of pre-defined thresholds. Such monitoring could facilitate the FI in carrying out capacity management to ensure IT resources are adequate to meet current and future business needs.

This is a customer consideration. Please also see row 146 (8.1.1), above.

8.1.4

Procedures should be established to respond to situations when pre-defined thresholds for system resources and system performance have been breached.

See row 137 (7.7.5), above.

System Recoverability

8.2.1

The FI should establish systems’ recovery time objectives (RTO) and recovery point objectives (RPO) that are aligned to its business resumption and system recovery priorities.

This is a customer consideration.
 
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: https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management and https://www.atlassian.com/trust/security/data-management.

8.2.2

The FI’s disaster recovery plan should include procedures to recover systems from various disaster scenarios, as well as the roles and responsibilities of relevant personnel in the recovery process. The disaster recovery plan should be reviewed at least annually and updated when there are material changes to business operations,
information assets or environmental factors. 

See row 151 (8.2.1), above.

8.2.3

During the recovery process, the FI should follow the established disaster recovery plan that has been tested and approved by management. The FI should avoid deviating from the plan as untested recovery measures could exacerbate the incident and prolong the recovery process. In exceptional circumstances where untested recovery measures need to be used, the FI should perform a risk assessment and ensure adequate controls are in place, as well as obtain approval from senior management.

See row 151 (8.2.1), above.

8.2.4

The FI should endeavour to operate from its recovery, secondary or alternate site periodically so as to have the assurance that its infrastructure and systems at these sites are able to support business needs for an extended period of time when production systems failover from the primary or production site.

See row 151 (8.2.1), above.

Testing of Disaster Recovery Plan

8.3.1

The FI should perform regular testing of its disaster recovery plan to validate the effectiveness of the plan and ensure its systems are able to meet the defined recovery objectives. Relevant stakeholders, including those in business and IT functions, should participate in the disaster recovery test to familiarise themselves with the recovery processes and ascertain if the systems are performing as expected.

This is a customer consideration.
 
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.
 
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.

8.3.2

A disaster recovery test plan should include the test objectives and scope, test scenarios, test scripts with details of the activities to be performed during and after testing, system recovery procedures, and the criteria for measuring the success of the test.

See row 156 (8.3.1), above.

8.3.3

The testing of disaster recovery plan should comprise:

8.3.3 (a)

a) various plausible disruption scenarios, including full and partial incapacitation of the primary or production site and major system failures; and

See row 156 (8.3.1), above.

8.3.3 (b)

b) recovery dependencies between information assets, including those managed by third parties

See row 156 (8.3.1), above.

8.3.4

Where information assets are managed by service providers, the FI should assess the service provider’s disaster recovery capability and ensure disaster recovery arrangements for these information assets are established, tested and verified to meet its business needs. The FI should engage its service provider to test the recovery steps that
require coordinated actions between the service provider and the FI.

See row 156 (8.3.1), above.

System Backup and Recovery

8.4.1

The FI should establish a system and data backup strategy, and develop a plan to perform regular backups so that systems and data can be recovered in the event of a system disruption or when data is corrupted or deleted.

This is customer consideration.
 
Atlassian tests our backup and restoration capabilities at least quarterly. Any identified issues will be tracked in internal Jira tickets for resolution. Atlassian also has documented and tested controls related to backup and redundancy as part of our SOC2 and IS2700x certificates.
 
For more information about our backup process, see: https://www.atlassian.com/trust/security/security-practices#backups. For more information about SOC2 and ISO2700x certificates, see: https://www.atlassian.com/trust/compliance.

8.4.2

To ensure data availability is aligned with the FI’s business requirements, the FI should institute a policy to manage the backup data life cycle, which includes the establishment of the frequency of data backup and data retention period, management of data storage mechanisms, and secure destruction of backup data.

See row 163 (8.4.1), above.

8.4.3

The FI should periodically test the restoration of its system and data backups to validate the effectiveness of its backup restoration procedures.

See row 163 (8.4.1), above.

8.4.4

To protect data in backup from unauthorised access and modification, the FI should ensure any confidential data stored in the backup media is secured (e.g. encrypted). Backup media should be stored offline or at an offsite location.

This is a customer consideration.
 
Atlassian backups are within AWS S3 and Glacier Services, and we rely on the AWS SOC2 certification for validation. For details on AWS Compliance, please see: https://aws.amazon.com/compliance/programs/. Backups are not taken offsite and stay within the AWS environment.

Data Centre Resilience

8.5.1

The FI should conduct a Threat and Vulnerability Risk Assessment (TVRA) for its data centres(DCs) to identify potential vulnerabilities and weaknesses, and the protection that should be established to safeguard the DCs against physical and environmental threats. In addition, the TVRA should consider the political and economic climate of the country in which the DCs are located. The TVRA should be reviewed whenever there is a significant change in the threat landscape or when there is a material change in the DC’s environment.

This is a customer consideration.
 
All production Atlassian Cloud systems reside in US-East and US-West regions of Amazon AWS, the AWS Ireland region, the AWS Frankfurt region, the AWS Sydney region and the AWS Signapore region.
 
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 centre 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. For more information about AWS Physical Controls, see: https://aws.amazon.com/compliance/data-center/controls/. AWS assurance information can be found at: https://aws.amazon.com/compliance/.

8.5.2

The FI should ensure adequate redundancy for the power, network connectivity, and cooling, electrical and mechanical systems of the DC to eliminate any single point of failure. Consideration should be given to the following:

8.5.2 (a)

a) diversification of data communications and network paths;

See row 168 (8.5.1), above.

8.5.2 (b)

b) deployment of power equipment, such as uninterruptable power sources, backup diesel generators with fuel tanks; and

See row 168 (8.5.1), above.

8.5.2 (c)

c) implementation of redundant cooling equipment (e.g. cooling towers, chilled water supply and computer room air conditioning units) to control the temperature and humidity levels in the DC and prevent fluctuations potentially harmful to systems.

See row 168 (8.5.1), above.

8.5.3

As part of the DC’s environmental controls, the FI should implement fire detection and suppression devices or systems, such as smoke or heat detectors, inert gas suppression systems, and wet or dry sprinkler systems.

See row 168 (8.5.1), above.

8.5.4

The FI’s secondary or disaster recovery DC should be geographically separated from its primary or production DC so that both sites will not be impacted by a disruption to the underlying infrastructure (e.g. telecommunications and power) in a particular location.

This is a customer consideration.

8.5.5

The DC’s physical security and environmental controls should be monitored on a 24 by 7 basis. Appropriate escalation, response plans and procedures for physical and environmental incidents at DCs should be established and tested.

See row 168 (8.5.1), above.

8.5.6

The DC should have adequate physical access controls including:

8.5.6 (a)

a) access granted to staff should be on a need-to-have basis, and revoked promptly if access is no longer required;

See row 168 (8.5.1), above.

8.5.6 (b)

b) proper notification and approval for visitors to the DC. All visitors should be escorted by authorised staff at all times while in the DC;

See row 168 (8.5.1), above.

8.5.6 (c)

c) physical access points in the DC should be secured and monitored at all times;

See row 168 (8.5.1), above.

8.5.6 (d)

d) access to equipment racks should be restricted to authorised staff and monitored;

See row 168 (8.5.1), above.

8.5.6 (e)

e) access to keys and other physical access devices should be restricted to authorised staff, and replaced or changed promptly if they have been misplaced, lost or stolen; and

See row 168 (8.5.1), above.

8.5.6 (f)

f) segregation of delivery and common areas from security sensitive areas should be enforced.

See row 168 (8.5.1), above.

Access Control

User Access Management

9.1.1

The principles of ‘never alone’, ‘segregation of duties’, and ‘least privilege’ should be applied when granting staff access to information assets so that no one person has access to perform sensitive system functions. Access rights and system privileges should be granted according to the roles and responsibilities of the staff, contractors and service providers.

We offer a Data Processing Addendum that provides detailed commitments regarding the processing and security of customer personal data. Details of this addendum is available at https://www.atlassian.com/legal/data-processing-addendum.
 
Atlassian maintains restriction on the personnel that need access to our systems, applications and infrastructure for their job role and responsibilities on the basis of least privilege and this is enforced through our authentication processes. All access is through authenticated sessions, and based on established permissions.
 
Our global support team maintains an account on all hosted systems and applications for the purposes of maintenance and support. This support team accesses hosted applications and data only for purposes of application health monitoring and performing system or application maintenance, and upon customer request via our support system.

9.1.2

The FI should establish a user access management process to provision, change and revoke access rights to information assets. Access rights should be authorised and approved by appropriate parties, such as the information asset owner.

This is a customer consideration. Please also see row 185 (9.1.1), above.
 
Customers of our Enterprise and Premium Cloud offerings have access to a centralized administration control panel. Your organization's admins can manage user access and permissions across all your product instances. See our blog post here: https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls.
 
Atlassian provides customers with the role of 'Organization Admin' who administers users and groups for the customer's products. For more information see: https://support.atlassian.com/user-management/docs/give-users-admin-permissions/.
 
Atlassian enables our customers to manage access by service users under the service customer’s control, such as by providing administrative rights to manage or terminate access. Atlassian also checks customers’ credentials against leaked credentials databases, and force users to update their password.
 
Further, Atlassian customers can use their chosen third party identity provider if supported by Atlassian. An Atlassian Support page details these features and how to connect your chosen identity provider, see: https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/.

9.1.3

For proper accountability, the FI should ensure records of user access and user management activities are uniquely identified and logged for audit and investigation purposes.

This is a customer consideration.
 
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: https://www.atlassian.com/trust/security/security-practices#tenant-separation.
 
For Atlassian Cloud customers, audit logs for changes to the organization are available as part of Atlassian Access. With audit logs, you have visibility into admin actions to users, groups, permissions etc. More information can be found here: https://support.atlassian.com/security-and-access-policies/docs/track-organization-activities-from-the-audit-log/.
 
For Atlassian personnel, all user accounts must be approved by management prior to their access to data, applications, infrastructure or network components. Our SRE team maintains an account on all hosted systems and applications for the purpose of maintenance and support. This support team accesses hosted applications and data only for purposes of application health monitoring and performing system or application maintenance, and upon customer request via our support system.

9.1.4

The FI should establish a password policy and a process to enforce strong password controls for users’ access to IT systems.

This is a customer consideration.
 
Atlassian Cloud users are required to set passwords of at least eight characters in length. Atlassian Cloud platform also supports the enforcement of password complexity requirements, as well as the ability to define the password expiry via Atlassian Access. For more information, see: https://www.atlassian.com/enterprise/cloud/access. Administrators are also able to enforce SSO via Atlassian Access which is a paid service.
 
Atlassian customers can use their chosen third party identity provider if supported by Atlassian. An Atlassian Support page details these features and how to connect your chosen identity provider, see: https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/

9.1.5

Multi-factor authentication should be implemented for users with access to sensitive system functions to safeguard the systems and data from unauthorised access.

This is a customer consideration.
 
Regarding Confluence and Jira, multi-factor authentication is available for individual accounts. For more information on how to enable multi-factor authentication, see: https://confluence.atlassian.com/cloud/enforced-tw-step-verification-938859738.html.
 
 Regarding Specific Products:

• Bitbucket support using MFA-based SSO options. For more information, see: https://confluence.atlassian.com/bitbucket/two-step-verification-777023203.html.

• Halp uses SSO via Slack OAuth and MS Teams. Slack and MS Teams provide multiple multi-factor authentication options. For more information please see: https://slack.com/intl/en-au/help/articles/203772216-SAML-single-sign-on & https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso.

• Opsgenie supports using MFA-based SSO options. For more information, see: https://support.atlassian.com/opsgenie/docs/configure-sso-for-opsgenie/.

• Statuspage supports using MFA-based SSO options.

• Trello support multi-factor authentication. For more information on how to enable multi-factor authentication, see: https://help.trello.com/article/993-enabling-two-factor-authentication-for-your-trello-account.

• Jira Align supports using MFA-based SSO options.

 
Atlassian maintains restrictions on the personnel that need this access for their job role and responsibilities. Our Access Management Policies designate all internal services by criticality tiers, which include requirements for multi-factor authentication on higher-tier services. We have enable two-factor authentication for our remote access and to our back-end platform.

9.1.6

The FI should ensure appropriate parties such as information asset owners perform periodic user access review to verify the appropriateness of privileges that are granted to users. The user access review should be used to identify dormant and redundant user accounts, as well as inappropriate access rights. Exceptions noted from the user access review should be resolved as soon as practicable.

This is a customer consideration. Please also see row 20 (4.1.2), above.
 
Validation of user access occurs regularly with System Owners for internal corporate user accounts. We have a quarterly review cycle for critical services in our entitlement review process. Access also expires if not renewed through our request for access policy on a quarterly or yearly basis depending on the access type or service.

9.1.7

Users should only be granted access rights on a need-to-use basis. Access rights that are no longer needed, as a result of a change in a user’s job responsibilities or employment status (e.g. transfer or termination of employment), should be revoked or disabled promptly.

See row 185 (9.1.1), above.
 
In addition, our de-provisioning process currently incorporates termination of employment, contract or agreement. Users who transfer internally will generally retain their access rights in order to enable ongoing engagement and support. Our HR application is synced with out internal Identity Store every 8 hours, removing any accounts for employees or contractors who are no longer employed.
 
In order to provide a highly responsive and flexible customer focused team, in line with our company values, our focus is on detecting unauthorized use of access rather than on restricting access which may slow down our responsiveness.

9.1.8

The FI should subject its service providers, who are given access to the FI’s information assets, to the same monitoring and access restrictions on the FI’s personnel.

See row 185 (9.1.1) and 187 (9.1.3), above.

Privileged Access Management

9.2.1

Users granted privileged system access have the ability to inflict severe damage on the stability and security of the FI’s IT environment. Access to privileged accounts should only be granted on a need-to-use basis; activities of these accounts should be logged and reviewed as part of the FI’s ongoing monitoring.

See row 185 (9.1.1) and 187 (9.1.3), above.

9.2.2

System and service accounts are used by operating systems, applications and databases to interact or access other systems’ resources. The FI should establish a process to manage and monitor the use of system and service accounts for suspicious or unauthorised activities.

This is a customer consideration.

Remote Access Management

9.3.1

Remote access allows users to connect to the FI’s internal network via an external network to access the FI’s data and systems, such as emails and business applications. Remote connections should be encrypted to prevent data leakage through network sniffing and eavesdropping. Strong authentication, such as multi-factor authentication, should be implemented for users performing remote access to safeguard against unauthorised access to the FI’s IT environment.

This is a customer consideration.
 
At Atlassian, remote access requirements are defined in the Access Management Policy and associated Standards. Customer data may be replicated onto employee workstations for support or migration purposes and with an active Customer Support Ticket. Strict firewall rules are in place thus limiting access to the production environment to our VPN network and authorized systems. Our VPN access requires multi-factor authentication.

9.3.2

The FI should ensure remote access to the FI’s information assets is only allowed from devices that have been secured according to the FI’s security standards.

This is a customer consideration. Please also see row 197 (9.3.1), above.

Cryptography

Cryptographic Algorithm and Protocol

10.1.1

The primary applications of cryptography are to protect data confidentiality, and maintain data integrity and authenticity. For example, cryptography is used in data encryption to protect sensitive data; cryptographic digital signatures can be used to verify the authenticity of the data origin and check if the data has been altered. Besides these applications, cryptography is also commonly used in authentication protocols.

Atlassian uses industry standard Transport Layer Security ("TLS") version 1.2 to create a secure connection using 256 bit Advanced Encryption Standard ("AES") encryption. Servers holding user data will use full disk, industry-standard AES encryption. Tenant data is encrypted within the AWS RDS or RDS backups, and is also encrypted in long term storage (S3) as well as all attachments. For more information, see: https://www.atlassian.com/trust/security/security-practices#keeping-data-secure.

10.1.2

The FI should adopt cryptographic algorithms from well-established international standards. The FI should also select an appropriate algorithm and encryption key length that meet its security objectives and requirements.

This is a customer consideration. Please also see row 201 (10.1.1), above.

10.1.3

Where the security of the cryptographic algorithm depends on the unpredictability of a random seed or number, the FI should ensure the seed or random number is of sufficient length and randomness.

This is a customer consideration. Please also see row 201 (10.1.1), above.

10.1.4

The FI should ensure all cryptographic algorithms used have been subject to rigorous testing or vetting to meet the identified security objectives and requirements.

This is a customer consideration. Please also see row 201 (10.1.1), above.

10.1.5

The FI should monitor developments in the area of cryptanalysis and, where necessary, update or change the cryptographic algorithms or increase the key lengths to ensure they remain resilient against evolving threats.

This is a customer consideration. Please also see row 201 (10.1.1), above.

Cryptographic Key Management

10.2.1

Cryptographic key management policy, standards and procedures covering key generation, distribution, installation, renewal, revocation, recovery and expiry should be established.

Atlassian maintains documented Key Management procedures for our Cloud Infrastructure. Encryption keys for Amazon attachments, stored in S3, are managed by Amazon KMS. The encryption, key management, and decryption process is inspected and verified internally by Amazon on a regular basis as part of their existing auditing process. Master Keys within KMS, upon creation, enable an auto-rotation to generate Master Key Material every 365 days (annually).

10.2.2

The FI should ensure cryptographic keys are securely generated and protected from unauthorised disclosure. Any cryptographic key or sensitive data used to generate or derive the keys should be also be protected or securely destroyed after the key is generated.

This is a customer consideration. Please also see row 207 (10.2.1), above.

10.2.3

The FI should determine the appropriate lifespan of each cryptographic key based on factors, such as the sensitivity of the data, the criticality of the system to be protected, and the threats and risks that the data or system may be exposed to. The
cryptographic key should be securely replaced, before it expires at the end of its lifespan. 

This is a customer consideration. Please also see row 207 (10.2.1), above.

10.2.4

To protect sensitive cryptographic keys, the FI should manage, process and store such keys in hardened and tamper resistant systems, e.g. by using a hardware security module.

This is a customer consideration. Please also see row 207 (10.2.1), above.

10.2.5

Where sensitive cryptographic keys need to be transmitted, the FI should ensure these keys are not exposed during transmission. The keys should be distributed to the intended recipient via an out-of-band channel or other secure means to minimise the risk of interception.

This is a customer consideration. Please also see row 207 (10.2.1), above.

10.2.6

Diversification of cryptographic keys can limit the impact of key exposure. Cryptographic keys should be used for a single purpose. For instance, the cryptographic key for data encryption should be different from the one that is used to generate cryptographic digital signatures.

This is a customer consideration. Please also see row 207 (10.2.1), above.

10.2.7

If a cryptographic key is found to be compromised, the FI should revoke and replace the key and all other keys whose security could also be compromised as a result of the exposed key.

This is a customer consideration. Please also see row 207 (10.2.1), above.

10.2.8

When cryptographic keys have expired or have been revoked, the FI should use a secure key destruction method to ensure the keys are not recoverable.

This is a customer consideration. Please also see row 207 (10.2.1), above.

10.2.9

When replacing or renewing a compromised or expiring cryptographic key, the FI should generate the new key in a manner such that any adversary who has knowledge of part or whole of the previous key will not be able to derive the new key from it.

This is a customer consideration. Please also see row 207 (10.2.1), above.

10.2.10

Cryptographic keys can be corrupted or unintentionally deleted. As such, the FI should maintain backups of cryptographic keys for recovery purposes and accord them a high level of protection.

This is a customer consideration. Please also see row 207 (10.2.1), above.

Data and Infrastructure Security

Data Security

11.1.1

The FI should develop comprehensive data loss prevention policies and adopt measures to detect and prevent unauthorised access, modification, copying, or transmission of its confidential data, taking into consideration the following:

11.1.1 (a)

a) data in motion - data that traverses a network or that is transported between sites;

This is customer consideration.
 
At Atlassian, all data for our services is encrypted in transit using TLS 1.2+ to protect it from unauthorised disclosure or modification, whether over HTTPS or SMTPS. The Atlassian implementation of TLS enforce the use of strong ciphers.

11.1.1 (b)

b) data at rest - data in endpoint devices such as notebooks, personal computers, portable storage devices and mobile devices, as well as data in systems such as files stored on servers, databases, backup media and storage platforms (e.g. cloud); and

This is a customer consideration.
 
Data drivers 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 accessed by authorized roles and services with audited access to the encryption keys.

11.1.1 (c)

c) data in use - data that is being used or processed by a system.

This is a customer consideration.
 
Atlassian does not provide Data Loss Prevention (DLP) directly as part of Cloud deployments. However, there are vendors in the Atlassian Marketplace, such as Nightfall that Atlassian recommends for customers desiring this DLP capability. See the Marketplace product page for Nightfall here: https://marketplace.atlassian.com/vendors/1217783/nightfall.
 
Atlassian has launched Beacon, which is in Beta and adds DLP features. Until Beacon is launched out of Beta, Atlassian still recommends Nightfall. See more information about Atlassian Beacon: https://www.atlassian.com/software/beacon.

11.1.2

The FI should implement appropriate measures to prevent and detect data theft, as well as unauthorised modification in systems and endpoint devices. The FI should ensure systems managed by the FI’s service providers are accorded the same level of protection and subject to the same security standards.

This is a customer consideration. Please also see row 7 (3.4.2), above.

11.1.3

Systems and endpoint devices are often targeted by cyber criminals to gain access or exfiltrate confidential data within an organisation. As such, confidential data stored in systems and endpoint devices should be encrypted and protected by strong access controls.

Atlassian has implemented a centralised system management solution (https://www.jamf.com/lp/apple-mobile-device-management-mdm-jamf/) for our Mac laptop fleet. We have implemented a mobile device management solution for out Windows endpoints and smartphones (https://www.vmware.com/products/workspace-one.html).
 
Atlassian has policies in place to ensure that sensitive or private data is not stored on endpoint devices.

11.1.4

The FI should ensure only authorised data storage media, systems and endpoint devices are used to communicate, transfer, or store confidential data.

This is a customer consideration. Please also see row 7 (3.4.2), above.

11.1.5

Security measures should be implemented to prevent and detect the use of unauthorised internet services which allow users to communicate or store confidential data. Examples of such services include social media, cloud storage and file sharing, emails, and messaging applications.

This is a customer consideration. Please also see row 7 (3.4.2), above.

11.1.6

The use of sensitive production data in non-production environments should be restricted. In exceptional situations where such data needs to be used in non-production environments, proper approval has to be obtained from senior management. The FI should ensure appropriate controls are implemented in non-production environments to manage the access and removal of such data to prevent data leakage. Where possible, such data should be masked in the non-production environments.

This is a customer consideration.
 
Atlassian has information security policies prohibiting data in non-production environments, and any attempted data migration between the environments would be identified through the change management process.

11.1.7

The FI should ensure confidential data is irrevocably deleted from storage media, systems and endpoint devices before they are disposed of or redeployed.

This is a customer consideration.
 
Atlassian maintains a Data Retention and Destruction Standard, which designates how long we need to maintain data of different types.
 
Further, Bring Your Own Device (BYOD) cannot access High Tier level services that include any customer data. All devices are required to use VPN regardless if at home or at the office. See how we handle a ZeroTrust security model and BYOD in this public Whitepaper: https://www.atlassian.com/trust/security/security-practices#securing-access-through-zerotrust.

Network Security

11.2.1

The FI should install network security devices such as firewalls to secure the network between the FI and the Internet, as well as connections with third parties.

This is a customer consideration.
 
Our cloud products are provided in a SaaS delivery model. There is a clear delineation between the administrative responsibilities of Atlassian (in providing the platform) and our tenants (in using the platform, including administering their organizational users and data). For more information, have a look at our Shared Responsibility Security Whitepaper: https://www.atlassian.com/whitepapers/cloud-security-shared-responsibilities.
 
Atlassian Cloud utilizes AWS RDS databases, which are segregated from our application servers. See our Cloud Architecture diagram at: https://www.atlassian.com/trust/reliability/cloud-architecture-and-operational-practices#cloud-platform-architecture.
 
Further, Atlassian has deployed IDS/IPS at our office sites and our cloud hosting environment. For the Atlassian Cloud Platform, log forwarding integrated with a Security Analytics Platform. At the Cloud Platform container level, file integrity is maintained as the instances are non-modifiable.

11.2.2

To minimise the risk of cyber threats, such as lateral movement and insider threat, the FI should deploy effective security mechanisms to protect information assets. Information assets could be grouped into network segments based on the criticality of systems, the system’s functional role (e.g. database and application) or the sensitivity of the data.

See row 7 (3.4.2), above and row 251 (11.5.1), below.

11.2.3

Network intrusion prevention systems should be deployed in the FI’s network to detect and block malicious network traffic.

See row 230 (11.2.1), above.

11.2.4

The FI should implement network access controls to detect and prevent unauthorised devices from connecting to its network.

See row 230 (11.2.1), above.

11.2.5

Network access control rules in network devices such as firewalls, routers, switches and access points should be reviewed on a regular basis to ensure they are kept up-to-date. Obsolete rules and insecure network protocols should be removed promptly as these can be exploited to gain unauthorised access to the FI’s network and systems.

This is a customer consideration. Please also see row 7 (3.4.2), above.

11.2.6

Internet web browsing provides a conduit for cyber criminals to access the FI’s IT systems. In this regard, the FI should consider isolating internet web browsing activities from its endpoint devices through the use of physical or logical controls, or implement equivalent controls, so as to reduce exposure of its IT systems to cyber attacks.

This is a customer consideration. Please also see row 7 (3.4.2), above.

11.2.7

An effective DoS protection should be implemented to detect and respond to various types of DoS attacks. The FI could engage DoS mitigation service providers to filter potential DoS traffic before it reaches the FI’s network infrastructure.

See row 230 (11.2.1), above.

11.2.8

A review of the FI’s network architecture, including the network security design, as well as system and network interconnections, should be conducted on a periodic basis to identify potential cyber security vulnerabilities.

See row 230 (11.2.1), above.

System Security

11.3.1

The security standards for the FI’s hardware and software (e.g. operating systems, databases, network devices and endpoint devices) should outline the configurations that will minimise their exposure to cyber threats. The standards should be reviewed periodically for relevance and effectiveness.

This is a customer consideration. Please also see row 20 (4.1.2), above.

11.3.2

The FI should establish a process to verify that the standards are applied uniformly on systems and to identify deviations from the standards. Risks arising from deviations should be addressed in a timely manner.

This is a customer consideration. Please also see row 20 (4.1.2), above.

11.3.3

Endpoint protection, which includes but is not limited to behavioural-based and signature-based solutions, should be implemented to protect the FI from malware infection and address common delivery channels of malware, such as malicious links, websites, email attachments or infected removable storage media.

This is a customer consideration.
 
Atlassian has implemented Crowdstrike Falcon (https://www.crowdstrike.com/falcon-platform/) for our Windows and Mac fleet. We do not use anti-malware on our Linux machines. Anti-malware is included in our vulnerability management policy. We have published excerpts of each of our high level policies with the tl:dr, which can be found at: https://www.atlassian.com/trust/security/ismp-policies.
 
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.
 
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.

11.3.4

The FI should ensure that anti-malware signatures are kept up-to-date and the systems are regularly scanned for malicious files or anomalous activities.

See row 241 (11.3.3), above.

11.3.5

To facilitate early detection and prompt remediation of suspicious or malicious systems activities, the FI should implement detection and response mechanisms to perform scanning of indicators of compromise (IOCs) in a timely manner, and proactively monitor systems’, including endpoint systems’, processes for anomalies and suspicious activities.

See row 241 (11.3.3), above.

11.3.6

Security measures, such as application white-listing, should be implemented to ensure only authorised software is allowed to be installed on the FI’s systems.

This is a customer consideration.

11.3.7

When implementing Bring Your Own Device (BYOD), the FI should conduct a comprehensive risk assessment and implement appropriate measures to secure its BYOD environment before allowing staff to use their personal devices to access the corporate network. Refer to Annex B on the security measures for BYOD.

This is a customer consideration.

Virtualisation Security

11.4.1

Virtualisation is used by organisations to optimise the use of computing resources and to enhance resilience. The technology allows several virtual machines (VMs) that support different business applications to be hosted on a physical system. A system failure or security breach in one of the VMs could have contagion impact on other VMs. The FI should ensure security standards are established for all components of a virtualisation solution.

See row 7 (3.4.2), above.

11.4.2

Strong access controls should be implemented to restrict administrative access to the hypervisor and host operating system as both control the guest operating systems and other components in the virtual environment.

See row 185 (9.1.1), above.

11.4.3

The FI should establish policies and standards to manage virtual images and snapshots. The standards should include details that govern the security, creation, distribution, storage, use, retirement and destruction of virtual images and snapshots so as to protect these assets against unauthorised access or modification.

This is a customer consideration.
 
Atlassian provides Software as a Service (SaaS) offering. Our customers do not have the capability to provide their own virtual machine image.

Internet of Things

11.5.1

Internet of Things (IoT) includes any electronic devices, such as smart phones, multi-function printers, security cameras and smart televisions, which can be connected to the FI’s network or the Internet. As with all information assets, the FI should maintain an inventory of all its IoT devices, including information such as the networks which they are connected to and their physical locations.

This is a customer consideration.
 
All Atlassian Workplace Tech computer and system assets are maintained in an inventory. The asset inventory is maintained, up to date, and aligned with other inventories. All assets that are accounted for in the inventory must have a designated specific owner. The asset inventory is reviewed annually as part of the annual ISO audit. All Atlassian-owned hardware assets are tracked with asset tags and are managed in the Asset Tracking project in Jira. For compliance, see SOC2: https://www.atlassian.com/trust/compliance/resources/soc2.

11.5.2

Many IoT devices are designed without or with minimal security controls. If compromised, these devices can be commandeered and used to gain unauthorised access to the FI’s network and systems or as a launch pad for cyber attacks on the FI. The FI should assess and implement processes and controls to mitigate risks arising from IoT.

See row 251 (11.5.1), above.

11.5.3

The network that hosts IoT devices should be secured. For instance, network access controls can be implemented to restrict network traffic to and from an IoT device to prevent a cyber threat actor from accessing the FI’s network and launching malware or DoS attacks. To further reduce IoT risks, the FI should host IoT devices in a separate network segment from the network that hosts the FI’s systems and confidential data.

See row 251 (11.5.1), above.

11.5.4

The FI should implement controls to prevent unauthorised access to IoT devices.

See row 251 (11.5.1), above.

11.5.5

Similar to other systems, the FI should monitor IoT devices for suspicious or anomalous system activities so that prompt actions can be taken to isolate compromised devices.

See row 251 (11.5.1), above.

Cyber Security Operations

Cyber Threat Intelligence and Information Sharing

12.1.1

To maintain good cyber situational awareness, the FI should establish a process to collect, process and analyse cyber-related information for its relevance and potential impact to the FI’s business and IT environment. Cyber-related information would include cyber events, cyber threat intelligence and information on system vulnerabilities.

This is a customer consideration. Please also see row 7 (3.4.2), above.

12.1.2

The FI should procure cyber intelligence monitoring services. As cyber threat information sharing is an important component of cyber resilience within the financial ecosystem, the FI should actively participate in cyber threat information-sharing arrangements with trusted parties to share and receive timely and actionable cyber threat information.

This is a customer consideration. Please also see row 7 (3.4.2), above.

12.1.3

At the same time, the FI should establish a process to detect and respond to misinformation related to the FI that are propagated via the Internet. The FI should consider engaging external media monitoring services to facilitate the evaluation and identification of online misinformation.

This is a customer consideration.

Cyber Event Monitoring and Detection

12.2.1

To facilitate continuous monitoring and analysis of cyber events; as well as prompt detection and response to cyber incidents, the FI should establish a security operations centre or acquire managed security services. The processes, roles and responsibilities for security operations should be defined.

See rows 130 (7.7.1) & 137 (7.7.5), above.

12.2.2

A process to collect, process, review and retain system logs should be established to facilitate the FI’s security monitoring operations. These logs should be protected against unauthorised access.

See rows 130 (7.7.1) & 137 (7.7.5), above.

12.2.3

To facilitate identification of anomalies, the FI should establish a baseline profile of each IT system’s routine activities and analyse the system activities against the baseline profiles. The profiles should be regularly reviewed and updated.

See row 187 (9.1.3), above.

12.2.4

The FI should consider applying user behavioural analytics to enhance the effectiveness of security monitoring. User behavioural analytics might include the use of machine learning algorithms in real time to analyse system logs, establish a baseline of normal user activities and identify suspicious or anomalous behaviours.

See row 187 (9.1.3), above.

12.2.5

Correlation of multiple events registered on system logs should be performed to identify suspicious or anomalous system activity patterns.

See row 187 (9.1.3), above.

12.2.6

A process should be established to ensure timely escalation to relevant stakeholders regarding suspicious or anomalous system activities or user behaviour.

See rows 130 (7.7.1) & 137 (7.7.5), above.

Cyber Incident Response and Management

12.3.1

The FI should establish a cyber incident response and management plan to swiftly isolate and neutralise a cyber threat and to securely resume affected services. The plan should describe communication, coordination and response procedures to address plausible cyber threat scenarios.

See row 130 (7.7.1), above.

12.3.2

As part of the plan, the FI should establish a process to investigate and identify the security or control deficiencies that resulted in the security breach. The investigation should also evaluate the full extent of the impact to the FI.

See row 130 (7.7.1), above.

12.3.3

Information from cyber intelligence and lessons learnt from cyber incidents should be used to enhance the existing controls or improve the cyber incident management plan.

See row 130 (7.7.1), above.

Cyber Security Assessment

Vulnerability Assessment

13.1.1

The FI should establish a process to conduct regular vulnerability assessment (VA) on their IT systems to identify security vulnerabilities and ensure risk arising from these gaps are addressed in a timely manner. The frequency of VA should be commensurate with the criticality of the IT system and the security risk to which it is exposed.

This is a customer consideration.
 
Atlassian use a range of industry-standard vulnerability detection tools that are run regularly across our products and infrastructure to automatically scan for and identify vulnerabilities. This includes Atlassian Cloud & Server products. Docker application images, internal, mobile, and third-party applications, as well as our infrastructure both on-premises and in our cloud. Details on our Vulnerability Management program can be found at: https://www.atlassian.com/trust/security/vulnerability-management.
 
Jira tickets are created for tracking remediation purposes, and due dates are assigned according to our SLO based on both severity and the source of the vulnerability. We have an on-going process to issue tickets for identified vulnerabilities to system owners, and our Security Management Team reviews any reported vulnerabilities and ensures action is taken against them.

13.1.2

When performing VA, the scope should minimally include vulnerability discovery, identification of weak security configurations, and open network ports, as well as application vulnerabilities. For web-based systems, the scope of VA should include checks on common web-based vulnerabilities.

See row 274 (13.1.1), above.

Penetration Testing

13.2.1

The FI should carry out penetration testing (PT) to obtain an in-depth evaluation of its cyber security defences. A combination of blackbox and greybox testing should be conducted for online financial services.

This is a customer consideration.
 
Atlassian offers customers the right to carry out penetration testing at any time without Atlassian’s prior approval: https://www.atlassian.com/trust/security/security-testing.
 
We also maintain an internal Red Team that conducts ongoing penetration test operations of all our infrastructure, cloud services and people. For more information on our Vulnerability Management program, see: https://www.atlassian.com/trust/security/vulnerability-management.

13.2.2

A bug bounty programme is another means by which an FI could discover vulnerabilities in their IT systems by inviting and incentivising ethical or “white hat” hackers to conduct PT on their systems. The FI may consider conducting a bug bounty programme to test the security of its IT infrastructure to complement its PT.

This is a customer consideration.
 
We engage with BugCrowd to maintain a Bug Bounty program, to conduct ongoing vulnerability assessments of our publicly available Applications and Services; the program is available at: https://bugcrowd.com/atlassian. We do share ongoing pen testing results from our Bug Bounty program at: https://www.atlassian.com/trust/security/security-testing.

13.2.3

To obtain a more accurate assessment of the robustness of the FI’s security measures, PT should be conducted on the production environment. Proper safeguards should be implemented when PT is conducted on the production environment.

See row 277 (13.2.1), above.

13.2.4

The frequency of PT should be determined based on factors such as system criticality and the system’s exposure to cyber risks. For systems that are directly accessible from the Internet, the FI is expected to conduct PT to validate the adequacy of the security controls at least once annually or whenever these systems undergo major changes or updates. 

See row 277 (13.2.1), above.

Cyber Exercises

13.3.1

The FI should carry out regular scenario-based cyber exercises to validate its response and recovery, as well as communication plans against cyber threats. These exercises could include social engineering, table-top, or cyber range exercises.

This is a customer consideration.
 
Atlassian provides information security training as an element of onboarding training ('Day 1') for new starters, and on an ongoing basis to all staff. 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. We also provide ongoing topical training related to malware, phishing, and other security concerns. https://www.atlassian.com/trust/security/security-practices#security-awareness-training

13.3.2

Depending on the exercise objectives, the FI should involve relevant stakeholders, including senior management, business functions, corporate communications, crisis management team, service providers, and technical staff responsible for cyber threat detection, response and recovery.

This is a customer consideration.

Adversarial Attack Simulation Exercise

13.4.1

The FI should perform an adversarial attack simulation exercise to test and validate the effectiveness of its cyber defence and response plan against prevalent cyber threats.

This is a customer consideration.

13.4.2

The objectives, scope and rules of engagement should be defined before the commencement of the exercise, and the exercise should be conducted in a controlled manner under close supervision to ensure the activities carried out by the red team do not disrupt the FI’s production systems.

This is a customer consideration.

Intelligence-Based Scenario Design

13.5.1

To simulate realistic adversarial attacks during any cyber security assessment, the threat scenario should be designed and based on challenging but plausible cyber threats.

This is a customer consideration.

13.5.2

The FI could also design the exercise scenario by using threat intelligence that is relevant to their IT environment to identify threat actors who are most likely to pose a threat to the FI; and identify the tactics, techniques and procedures most likely to be used in such attacks.

This is a customer consideration.

Remediation Management

13.6.1

A comprehensive remediation process should be established to track and resolve issues identified from the cyber security assessments or exercises. The process should minimally include the following:

13.6.1 (a)

a) severity assessment and classification of an issue;

See row 130 (7.7.1), above.

13.6.1 (b)

b) timeframe to remediate issues of different severity; and

See row 130 (7.7.1), above.

13.6.1 (c)

c) risk assessment and mitigation strategies to manage deviations from the framework.

See row 130 (7.7.1), above.

Online Financial Services

Security of Online Financial Services

14.1.1

Online financial services include banking, trading, insurance, or other financial and payment services that are provisioned via the Internet. In delivering online financial services, the FI should implement security and control measures which are commensurate with the risk involved to ensure the security of data and online services.

This is a customer consideration.

14.1.2

The FI should secure its communications channels to protect customer data. This can be achieved through data encryption and digital signatures.

This is a customer consideration.

14.1.3

Adequate measures should also be taken to minimise exposure of the FI’s online financial services to common attack vectors such as code injection attack, cross-site scripting, man-in-the-middle attack (MITMA), domain name system (DNS) hijacking, distributed denial of service (DDoS), malware and spoofing attacks.

This is a customer consideration.

14.1.4

An FI offering online financial services access via a mobile device should be aware of the risks unique to mobile applications. Specific measures aimed at addressing the risks of mobile applications should be put in place. Refer to Annex C for guidance on Mobile Application Security.

This is a customer consideration.

14.1.5

The FI should only make available mobile applications or software to customers through official mobile application stores, or other secure delivery channels.

This is a customer consideration.

14.1.6

The FI should actively monitor for phishing campaigns targeting the FI and its customers. Immediate action should be taken to report phishing attempts to service providers to facilitate the removal of malicious content. The FI should alert its customers of such campaigns and advise them of security measures to adopt to protect against phishing.

This is a customer consideration.

14.1.7

Rooted or jailbroken mobile devices, which are more susceptible to malware and may have more security vulnerabilities, should be disallowed from accessing the FI’s mobile applications to perform financial transactions unless the application has been secured within a sandbox or container that insulates the application from tampering and interception by malware.

This is a customer consideration.

Customer Authentication and Transaction Signing

14.2.1

Multi-factor authentication should be deployed at login for online financial services to secure the customer authentication process. Multi-factor authentication can be based on two or more of the following factors, i.e. what you know (e.g. personal identification number or password), what you have (e.g. one-time password (OTP) generator) and who you are (e.g. biometrics).

This is a customer consideration.

14.2.2

End-to-end encryption should be implemented for the transmission of customer passwords so that they are not exposed at any intermediate nodes between the customer mobile application or browser and the IT system where passwords are verified. To safeguard the confidentiality of customer passwords, the passwords should only be verified in a hardened or tamper resistant system.

This is a customer consideration.

14.2.3

The FI should implement transaction-signing (e.g. digital signatures) for authorising high-risk activities to protect the integrity of customer accounts’ data and transaction details. High-risk activities include changes to sensitive customer data (e.g. customer office and home address, email and telephone contact details), registration of third party payee details, high value funds transfers and revision of funds transfer limits.

This is a customer consideration.

14.2.4

Besides login and transaction-signing for high-risk activities, the FI may implement appropriate risk-based or adaptive authentication that presents customers with authentication options that are commensurate with the risk level of the transaction and sensitivity of the data.

This is a customer consideration.

14.2.5

When implementing time-based OTPs, the FI should establish a validity period that is as short as practicable to lower the risk of a stolen OTP being used for fraudulent transactions.

This is a customer consideration.

14.2.6

Where biometric technologies and customer passwords are used for customer authentication, the FI should ensure the biometrics-related data and authentication credentials are encrypted in storage and during transmission.

This is a customer consideration.

14.2.7

The performance of the biometric solution, based on false acceptance rate (FAR) and false rejection rate (FRR), should be calibrated to be commensurate with the risk associated with the online activity.

This is a customer consideration.

14.2.8

A soft token is a software-based two-factor authentication mechanism installed on a general-purpose device. Appropriate measures, such as verifying the identity of the customer, detecting and blocking rooted or jailbroken devices, and performing device binding, should be implemented during soft token provisioning.

This is a customer consideration.

14.2.9

The FI should ensure the authenticated session, together with its encryption protocol, remains intact throughout the interaction with the customer. Measures to detect and terminate hijacked sessions should be implemented. To reduce the risk of an attacker from maintaining a hijacked session indefinitely, an online session should be automatically terminated after inactivity for a pre-defined time.

This is a customer consideration.

14.2.10

Where alternate controls and processes (e.g. maker-checker function) are implemented for corporate or institutional customers to authorise transactions, the FI should perform a security risk assessment of controls or processes to ensure they are commensurate with the risk of the activities that are being carried out.

This is a customer consideration.

14.2.11

To safeguard the confidentiality of authentication credentials, such as biometric templates and passwords, the FI should store these credentials in a form that is resistant to reverse engineering. A process and procedure should also be implemented to revoke and replace authentication credentials and mechanisms that have been compromised. 

This is a customer consideration.

Fraud Monitoring

14.3.1

The FI should implement real-time fraud monitoring systems to identify and block suspicious or fraudulent online transactions.

This is a customer consideration.

14.3.2

A process should be established to investigate suspicious transactions or payments and to ensure issues are adequately and promptly addressed.

This is a customer consideration.

14.3.3

The FI should notify customers of suspicious activities or funds transfers above a threshold that is defined by the FI or customers. The notification should contain meaningful information such as type of transaction and payment amount, as well as instructions to report suspicious activities or unauthorised transactions.

This is a customer consideration.

Customer Education and Communication

14.4.1

Customers should be informed of the security best practices that they should adopt when using online financial services. This includes the measures to take to secure their electronic devices that are used to access online financial services.

This is a customer consideration.

14.4.2

The FI should alert its customers on a timely basis to new cyber threats so that they can take precautionary measures.

This is a customer consideration.

14.4.3

The FI should advise their customers on the means to detect unauthorised transactions and to report promptly security issues, suspicious activities or suspected fraud to the FI.

This is a customer consideration.

IT Audit

Audit Function

15.1.1

Audit plays an important role to assess the effectiveness of the controls, risk management and governance process in the FI. The FI should ensure IT audit is performed to provide the board of directors and senior management an independent and objective opinion of the adequacy and effectiveness of the FI’s risk management, governance and internal controls relative to its existing and emerging technology risks.

Atlassian grants certain audit, access and information rights to such regulated entities and their supervisory authorities in compliance with applicable laws. Regulated entities may access their data on the services at any time and may provide their supervisory authority with access.

15.1.2

A comprehensive set of auditable areas for technology risk should be identified so that an effective risk assessment could be performed during audit planning. Auditable areas should include all IT operations, functions and processes.

See row 326 (15.1.1), above.

15.1.3

The frequency of IT audits should be commensurate with the criticality of and risk posed by the IT information asset, function or process.

See row 7 (3.4.2), above.

15.1.4

The FI should ensure its IT auditors have the requisite level of competency and skills to effectively assess and evaluate the adequacy of IT policies, procedures, processes and controls implemented.

This is a customer consideration.