Our Security Detections Program

Our Security Detections Program @ Atlassian

At Atlassian, we’re very mindful that we can’t rest on our laurels when it comes to security. One of our core values is to “Be the Change You Seek”, and we’re intent on living this value by continuously improving our approach to security as the cyber threat landscape continues to evolve.

An example of how we are continuously improving is by doing this through our Security Detections Program.

What is the Security Detections Program?

Detections are primarily searches that run proactively on a scheduled basis on Atlassian's Security Incident and Event Management platform. These searches are designed to detect malicious activity targeting Atlassian and its customers. For example, detections built to analyze incoming e-mail headers, detect malicious browser extensions behavior, or looking for a suspicious pattern of DNS traffic.

Near the end of 2018, Atlassian introduced a formal Security Detections Program and made it the primary approach of our Detection and Response team. The Detections Program focuses on decreasing the time to detect malicious activity. This is achieved through the regular creation of new detections, tuning and improving existing detections, and automating detection responses.

The Detections Program uplifts on Atlassian’s existing Security Incident Management processes.  While Atlassian Security have confidence in those processes, the program was established out of a recognition that as Atlassian continues to grow and serve more customers globally, we need to:

Improve our ability to detect incidents more rapidly in an increasingly complex threat landscape; and

Make sure our approach to incident management accounts not only for the threats we have faced, but sufficiently anticipates and prepares for the threat landscape we will face in future.

The Goals of the Detections Program

The key objectives in introducing the Detections Program from Atlassian’s point of view were to:

Increase the proportion of security incidents that are identified as a result of alerts from detections Security have created, and reduce those that could have been but instead came to our attention from another source (e.g. external reports / notifications);

Understand and improve our detection coverage across a number of dimensions, including products, attack types, and log sources, with the ultimate goal being to get our coverage as close to 100% as possible; and

Have a clear way of measuring and validating our team’s approach to detecting security incidents so as a team, we can be confident we are moving in the right direction and improve our incident detection and response capabilities over time.

The program has also enabled our Detection and Response teams to refine their skills both in Splunk and in writing detections more generally, since Atlassian security analysts now have dedicated time to discuss and develop detection ideas.

How the program works

As part of the program, each analyst within the Detection and Response team focuses on writing at least one new security detection each month.

When an analyst writes a new detection, they also produce:

• Detailed documentation describing how the detection works and what its security implications are;
• A run-book on how to respond to a detection when it generates an alert. These run-books are accessible from Jira tickets that are created for detection alerts, so analysts have all the information required to quickly action those alerts.
• A documented analysis of the detection's true positive and false positive ratios over time;
• Classification of the detection to its associated Atlassian product, service and log source, as well as the attack vector or technique it is covering (which helps us have a good overall view of detection coverage).

Each detection is also subject to a peer review process to provide a level of assurance around the quality of the detections we write and enable knowledge sharing amongst our entire team.

When a detection finds something that may be malicious, an alert is fired and responded to by the Detection and Response team. The outcome of the alert can range from being acknowledged as minor or false positive to the kickoff of an investigation or the creation of a security incident.

Standardising our Detections

Atlassian Security realised early on the need to have a method for achieving a high level of consistency and quality amongst the detections written by analysts. Without a process for standardisation, the team ran the risk of having detections with inconsistent naming, rudimentary source control processes, incomplete historical data and no ability to understand the coverage of our detections across our various products and services.

To help achieve this, the team created a standard schema for classifying detections. When an analyst writes a new detection, it is put through an automated process to ensure it meets the requirements of the schema. The workflow, broadly speaking, is as follows:

• A detection and response analyst creates a Jira issue for any new detection plays they write. Jira effectively serves as the single source of truth for all our detections.
• They have a custom issue type we’ve created that has a core set of data the analyst fills out to create a new detection, including in-scope products, services and infrastructure, attack types, and text fields for Splunk search logic.
• Once the detection is created, we standardize it by running a command-line interface tool, custom-built by our automation team.This tool helps validate the detection and propagate it throughout the various systems and components that comprise our alerting pipeline. Specifically, it:
  • reads the Jira issue into a Jira object;
  • validates fields in the issue and adds key labels;
  • generates a standard name for the detection and creates pull requests (PRs) for it. The PR contains the Splunk stanza, keys, and parameters necessary for detections to run scheduled searches and propagate alerts to Jira; and
  • creates and populates a Confluence page that analysts can add to as they respond to the alert and links this to the corresponding Jira issue. This helps create further visibility and captures historical information around our detections. It also provides an ‘exec level view’ of the most critical information that is needed for reporting.

The standardisation process also allows the team to classify each detection according to attack type and the Atlassian product, service or infrastructure it pertains to, providing a single ‘pane of glass’ view of the detection and response teams overall coverage, and in particular highlighting areas where there might be gaps that need to be addressed.

The detection and response team currently use the MITRE ATT&CK framework as a starting point for classifying their detections based on attack type. This is supplemented Atlassian’s security red team operations, past incidents, and the team’s understanding of emerging threats and attack methods to help identify areas of priority the teams should focus on when writing new detections.  

In summary

Our Security Detections Program is an important part of Atlassian’s proactive approach to incident detection and response. We also believe that the approach we’ve taken to standardisation is something that security teams across many organisations could benefit from. If you’d like to learn more, get in contact with our Support Team. 

Want to dig deeper?

We have published a number of other resources you can access to learn about our approach to handling security incidents, and our general approach to security.  

• Trust @ Atlassian
• Security @ Atlassian
• Atlassian Security Practices
• Atlassian Security Incident Management Program
• Atlassian Security Incident Responsibilities
• Atlassian’s CSA STAR entry