View by Author

Most Recent Articles

Padlock on top of a keyboard

A systematic approach to detection engineering with MITRE ATT&CK

By Published On: 23 October 2024Categories: Defence, Security, Tech & Data

Introduction What is detection engineering? Detection engineering is a specialisation […]

Share This Article:

Introduction

What is detection engineering? Detection engineering is a specialisation in cyber operations focused on the development of continuous monitoring and monitoring rules on systems in an organisations environment. These monitoring rules are typically developed from use-cases for data in the environment and enriched from various sources to provide further context. The monitoring rules generally live in a Security Information and Event Management (SIEM) platform with a correlation engine powering them.

My name is Kaden Butt and I’m a Manager in the Anchoram Consulting Security Testing practice. I’m here to provide guidance on what you can detect based on Data Sources in your environment through a systematic approach with the MITRE ATT&CK framework. This approach can be applied to a green fields environment or to uplift an existing detection engineering capability.

What is MITRE ATT&CK?

The MITRE ATT&CK framework is a repository of data based on real-world techniques employed by adversaries. It’s in the acronym, Adversarial Tactics, Techniques and Common Knowledge (ATT&CK). The framework is organised into matrices of collected data as an easy to view format for users of the framework. These matrices consist of columns based on the Tactics and rows that are named Techniques. Many Techniques and Sub-Techniques sit under a Tactic demonstrating the almost methodical approach taken by adversaries with the Tactic being the overarching objective of the Technique. Typical usage of the framework involves security readiness evaluations of an organisation based on gap analysis of the techniques and sub-techniques covered in the relevant matrices. This is derived from the existing alerts in your environment.

Security Readiness Evaluations

Security readiness evaluations using the MITRE ATT&CK framework provide an organisation with a view of their preparation to detect one, or many, of the Techniques in the framework. This can be done by mapping your current detections to the Techniques and Sub-Techniques they would trigger on. This feeds into your gap analysis.

Gap Analysis

With the information of a security readiness evaluation done with the MITRE ATT&CK framework, an organisation can uplift a specific Tactic that they may have less visibility on. For instance, your organisation may have plenty of data being monitored based on website traffic, but little to no data of internal information of the website’s server. You may have plenty of information aligned with the Reconnaissance, Resource Development, and Initial Access Tactics, but little to no visibility of the Execution and Privilege Escalation Tactics, revealing the gaps in your monitoring to target.

There are different sets of matrices to ensure relevance to your organisation. At a high level they include:

  • Enterprise
    • Enterprise Preparatory Techniques (PRE)
    • Windows
    • macOS
    • Linux
    • Cloud
      • Office 365
      • Azure Active Directory (AD)
      • Google Workspace
      • Software as a Service (SaaS)
      • Infrastructure as a Service (IaaS)
    • Network
    • Containers
  • Mobile
    • Android
    • iOS
  • Industrial Control Systems (ICS)

With the different matrices listed above, I’ll leave it to your discretion as to which matrices to refer to for your environment.

Green Field Approach

A green field approach implies that you are starting with a clean slate – ie, there is no current cyber security monitoring in place. I’ll break up the green field approach into four different stages to enable appropriate progress tracking and milestones:

  1. Scoping
  2. Discovery
  3. Build and Test
  4. Continuous Improvement

Small disclaimer before getting into scoping: while numerous detections can be created based on what data sources are available to you, this does not necessarily mean all detections should be created. In detection engineering a general rule of thumb to follow is quality over quantity. Aiming for a higher percentile and a generally high rate of true positive is the goal (whilst not always achievable, it is something to keep in mind). Another thing to mention is alignment with your organisational objectives and enterprise risks. Priority for detections should be fed from your businesses concerns and be used in conjunction with MITRE.

Scoping

Scoping is the act of defining the specific objectives, boundaries and deliverables of any project. Initial scoping of this activity is necessary as it allows you to ensure adequate resources are allocated to the activity. If you under-scope the activity, sub-par monitoring may be the result.
Good scoping for this activity should include the following:

  1. Business concerns: Monitoring should be implemented with the reasoning behind it. Addressing business concerns is a key driver to this and they should all be aligned.
  2. Technology Stack: What technology is implemented and in your environment? Knowing this ensures you’re well versed with your environment and what data types to expect.
  3. Product and/or Service Offering: Your product or service offering is synonymous with your crown jewels. Your crown jewels are your most valuable asset. Without it, your organisation wouldn’t exist.

Business Concerns

Scoping of business concerns involves meeting with key stakeholders of the organisation to determine their worries for the environment. This could be as simple and high level, for example: “As a CISO, I want to ensure detections are in place to monitor for ransomware entering our network” or very specific such as: “As a Security Operations Center Analyst, I want to ensure there are detections in place to monitor for unauthorised external traffic through SMB”. These stories give us insight as detection engineers into the concerns of the organisation allowing us to map detections directly to them to monitor security gaps or help executive staff sleep better at night. We’ll categorise these in a central repository as user stories. Addressing business concerns is not only practical, but it supports your work by addressing them, giving justification for funding for more resources, better technology and ongoing training and development.

Technology Stack

Effective detections require comprehensive documentation of technology in your environment. This can be done through effective communication to branch, sector or division Subject Matter Experts (SMEs), providing you with insight into areas that may be siloed. When collecting this information, it should be catalogued into a central repository as systems. The technology stack feeds directly into our next step, which is Discovery.

Product and/or Service Offering

The product or service that is offered by your organisation should be incorporated into your detections. As previously mentioned, they’re the organisation’s crown jewels in a sense, and typically the highest of priorities. Without the product/service offering, there would be no business. This should be very familiar to the detection engineers and catalogued in your repository. Information on the product/service can also be used to focus on quality threat intelligence to enrich your detections.

Discovery

With your scoping completed and a repository started to provide insight on what we’re working with in the environment, we can start the discovery phase of the process. This involves determining what sort of Data Sources are currently available or not currently available to you. If a Data Source is available to you, there is an established pattern in place to centralise any relevant logging for a system and can be stood up quickly, or it is already stood up and can be redirected. If a Data Source is not available to us, there is no pattern in place, and/or a data pipeline will need to be developed and stood up for the system. Available and not available Data Sources should be added to your repository with their availability status included to provide a fuller picture of the organisation.

The discovery process should include cross-team communications. This will help find subject matter experts (SMEs), providing deeper insight into select systems. The system SMEs can assist in understanding any proprietary logging formats or event names. With no SME available for niche systems and little to no documentation online, the build phase can be slowed significantly. Vendor contact should be made through the appropriate communications channel to start understanding the data further. Vendors are there to help!

All this information should be catalogued in your repository for this exercise with a consistent naming convention for quick access and minimal confusion.

Build and Test

Now that Scoping and Discovery have been completed, we can move on to the fun part – Building and Testing our detections. Based on the information we’ve gathered already, we should have knowledge of what systems are in our environment, what data is available to us, and what the business at a high and low level is concerned about. I’ll provide an example of the use case development process with MITRE for a commonly found Data Source in most enterprise level environments. This will establish a pattern of work, then we can touch on alert development and look at unit testing for alerts.

Use case development

With Data Sources catalogued, we can establish use cases for them by leveraging MITRE ATT&CK. This is due to the breakdown of Data Components in Data Sources and information provided on said components in the framework, making it highly effective in establishing foundational use cases for your environment from a well-known framework.

We will look at Active Directory logging as the common Data Source to play with initially and establish our pattern.

Figure 1 – Data Sources, Active Directory

All the Data Sources have an identifier attached to them to allow for traceability when looking at coverage. The ID for Active Directory is DS0026, and it includes the following Data Components:

  • Active Directory: Active Directory Credential Request
  • Active Directory: Active Directory Object Access
  • Active Directory: Active Directory Object Creation
  • Active Directory: Active Directory Object Deletion
  • Active Directory: Active Directory Object Modification

Each of these Data Components is derived from the Active Directory Data Source. The components provide insight into which Techniques can be monitored. MITRE have done this already for you, allowing you to quickly discover use cases for the Active Directory Data Source.

Here is an example use case for the data in the Active Directory Credential Request component:

Figure 2 – Active Directory Data Component, Active Directory Credential Request

 

The Detects column gives us a solution agnostic use case on how to monitor for the theft or forgery of authentication certificates in Active Directory. By monitoring Active Directory Certificate Service certificate requests (Event ID 4886) and issued certificates (Event ID 4887) for abnormal activity. This includes unexpected certificate enrollments and signs of abuse within certificate attributes (such as abusable Extended Key Usages (EKUs)).

This is just one of the many Techniques and Sub-Techniques available to you under the Data Source. With your first use case defined (and without knowing your tech stack), I’ll leave the alert creation up to you. You can use things like SIGMA rules (https://github.com/SigmaHQ/sigma) to generate solution specific versions of these alerts with a SIGMA rule converter. I like to use Uncoder.io (https://uncoder.io/).

Assuming the alert has been created, we’ll move to the test portion.

Test

There are multiple ways to perform unit testing on your detections to ensure they do what they are meant to. The Continuous Improvement section addresses things like alert tuning, but we want to do our best to ensure minimal false positives to start with. Things to assist with testing can include a testing environment for your detection stack and the use of a Breach Attack Simulator (BAS). An open-source attack simulator I’ve used in the past that has default attacks to simulate, and allows for custom tests and MITRE coverage mapping, is Atomic Red team (https://github.com/redcanaryco/atomic-red-team).

If you have the capacity to do so, setting up an atomic red team environment for testing your detections is a fantastic way to ensure they’re working as intended and to minimise false positives. If you’ve created custom detections that deviate from the MITRE ATT&CK framework, Atomic Red Team allows you to create custom atomics (tests) to simulate attacks to be caught by your custom detections.

Continuous Improvement

Good detection engineering is a cycle. As systems are patched, new techniques arise, and incidents occur. Detections should stay cutting-edge also. After arriving at this stage, a review point should be established based on your organisation’s capacity to do so, I’d say at a maximum of annually. This is to clean up any changes in solutions and active log sources etc. Tuning of alerts may or may not occur for detections, but if the need arises, it is best to workshop the alert with the team to determine a course of action for it. This may include further enrichment from high confidence intelligence or organisational data. Turning it into a component in a risk-based alert or disabling it all together.

While MITRE ATT&CK is a great baseline for organisations, it is not a be-all and end-all. Relevance plays a large part in detection engineering and other inputs should be utilised also to feed the input for detection use cases. These should include:

  • Hunting
  • Intelligence
  • Incident Response
  • Business units

Custom use cases are a sign of maturity in your detection engineering capability and can be a great benefit to your organisation.

Uplift an Existing Detection Capability

The approach to uplifting an existing detection capability follows a lot of the same principles of the green field approach. There are three key differences between the green field approach, and uplifting an existing detection capability:

  1. Knowledge of the systems is established, and Data Sources are being ingested into your SIEM (Security Information and Event Management) platform. The Data Sources available to you already will just need to be catalogued.
  2. Existing detections need to be mapped to the MITRE Techniques, demonstrating that the coverage already exists, giving you a head start.
  3. A pattern for data ingestion already exists, allowing you to onboard new Data Sources quickly.

Summary

A green field approach incorporating MITRE to establish baseline detections in your environment from the ground up is a fantastic idea. Using MITRE to further uplift and fill in any gaps is extremely effective also. I have often read and found that MITRE ATT&CK coverage is the primary use-case for the framework. It’s also quite effective as an input into your detection engineering capability and should not be dismissed. As MITRE is updated, this should be reflected during the reviews of your detection capability.

Introduction What is detection engineering? Detection engineering is a specialisation […]

By Published On: 23 October 2024Categories: Defence, Security, Tech & Data

Share This Article:

Categories

Subscribe

Subscribe to our newsletter and get the latest news and information from Anchoram.

View by Author

Most Recent Articles

Author Profiles