Views: 22
Purpose of Threat Emulation
Threat emulation is meant to assist security teams and organisations, in general, in better understanding their security posture and their defence mechanisms and performing due diligence in their compliance.
- Are our people trained and alert?
- Are our internal processes effective?
- Has the technology in use properly configured and delivered value to the business?
These questions are addressed through cyber security assessments, mainly red team engagements, vulnerability assessments and penetration tests.
Vulnerability assessments are conducted to identify vulnerabilities in assets under a defined scope.
Penetration testing involves exploiting vulnerabilities within an organisation under strict control of the scope and rules of engagement.
Red teaming provides a means of looking at cyber security issues from an adversary’s perspective. This generates attacks on the organisation as though the actual adversary is attacking. This is done in the hope of making the defensive measures better and improving their detections.
The challenge of these assessments is that they do not represent real-world threats. Emulation is here to address these challenges and provide a holistic security evaluation.
Threat Emulation
Threat emulation is an intelligence-driven impersonation of real-world attack scenarios and TTPs in a controlled environment to test, assess and improve an organisation’s security defences and response capabilities. This means that you seek to behave as the adversary would. Threat emulation aims to identify and mitigate security gaps before attackers exploit them.
Core Concepts
Threat emulation would be seen to have several key characteristics which line up well with the Pyramid of Pain.
- Real-world threats: The MITRE ATT&CK framework and cyber threat intelligence are common information sources to ensure threat TTPs are based on actual breaches, APTs and campaigns.
- Behaviour-focused: The execution of TTPs during an emulation exercise aims to tune defences based on behaviours and not signatures, thus adapting to the elements of the Pyramid.
- Transparency: Disclosure of activities between the Red and Blue teams during execution ensures that the security posture is improved holistically.
- Collaborative: Due to the common goal of improving organisational security, threat emulation allows teams to collaborate in their efforts.
- Repeatable: Some emulation tasks would be done multiple times in the course on an exercise or numerous exercises. These tasks can be automated, creating a baseline of continuous practical security assessments and deployment.
Emulation Methodology
Threat emulation methodologies are strategies, plans and procedures used to simulate and test network defences and systems against adversaries.
MITRE ATT&CK
The MITRE ATT&CK Framework is an industry-known knowledge base that provides information about known adversarial TTPs observed in actual attacks and breaches. Threat emulation teams can extract many benefits from integrating ATT&CK with their engagements as it would make it efficient when writing reports and mitigations related to the behaviours experimented with.
Atomic Testing
The Atomic Red Team is a library of emulation tests developed and curated by Red Canary that can be executed to test security defences within an organisation. The atomics (individual tests) are mapped to the MITRE ATT&CK framework, providing a pivot between threat profiles and emulation. Atomic Red Team supports emulation on a wide range of platforms, not only on known Operating Systems but also in Cloud Environments.
TIBER-EU Framework
https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html
The Threat Intelligence-based Ethical Red Teaming (TIBER-EU) is the European framework developed to deliver controlled, bespoke, intelligence-led emulation testing on entities and organisations’ critical live production systems. It is meant to provide a guideline for stakeholders to test and improve cyber resilience through controlled adversary actions.
The TIBER_EU framework follows a three-phase process for end-to-end adversary testing:
Who is involved in a TIBER-EU test?
The main participants in a TIBER-EU test belong to one of five different teams, depending on their roles and responsibilities under the TIBER-EU framework:
- blue team – the people in the entity that is the subject of the test whose prevention, detection and response capabilities are being tested without their foreknowledge
- threat intelligence provider – the company that looks at the range of possible threats and carries out reconnaissance on the entity
- red-team provider – the company that carries out the simulated attack by attempting to compromise the critical functions of the entity, mimicking a cyberattacker
- white team – a small team within the target entity who are the only ones there who know a test is happening and lead and manage the test in collaboration with the TIBER cyber team
- TIBER cyber team – the team within the authority that is responsible for overseeing the test and making sure it meets the requirements of the TIBER-EU framework, thus enabling mutual recognition of the test by relevant authorities
CTID Adversary Emulation Library
The Center for Threat-Informed Defense is a non-profit research and development organisation operated by MITRE Engenuity. Its mission is to promote the practice of threat-informed defence. With this mission, they have curated an open-source adversary emulation plan library, allowing organisations to use the plans to evaluate their capabilities against real-world threats.
The library provides users with two approaches to their emulation:
- Full Emulation: This is a comprehensive approach to emulating a particular adversary, for example, APT29, typically from initial access to exfiltration. An example of this approach can be found in this APT29 Adversary Emulation repository.
- Micro Emulation: This approach is more focused, emulating behaviours across multiple adversaries, such as file access or process injection techniques. You can view existing emulation plans from CTID micro emulation plans on the linked repository.
The Adversary Emulation Process tasks will look at developing an emulation plan for an adversary in ways that will utilise some of the methodologies discussed here.
Threat Emulation Process
Defining Emulation Objectives
The objectives should be clearly defined, specific, and measurable. For example, the aim might be to identify how an attacker could gain access to sensitive data on a particular server; in case if we do TE for retail business, then we have to set our objective to identify areas of protection against credit card fraud and ransomware attacks.
Research Adversary TTPs
Information Gathering
- Avoid instances of selecting arbitrary and non-concerning adversaries
- Information can be gathered from various sources, including threat intelligence reports, previous attacks, and publicly available information
- For example; if we do this exercise for a financial institutions such as banks, retailers, insurance companies then concentrate more on financially motivated threat actors (APT groups such as FIN6, FIN7 and FIN8 ) that target retail businesses and utilise ransomware.
Select The Emulated Adversary
With our shortlist of adversaries, we must narrow it down to one we can emulate. This selection can be based on relevance to company’s goal, available CTI, TTP complexity and finally the available resources to run the emulation process.
Select The Emulated TTPs
This step aims to accurately model the behaviour of the target adversary so that the exercise can be conducted realistically and practically. The TTPs selected to emulate will drive the rules of engagement, implementations and operations flow of the emulation.
APT FIN7’s TTP is visualized here using the MITRE ATT&CK Navigator,
Construct TTP Outline
The outline aims to drive follow-up threat emulation activities, such as explaining the planned emulation activities, stating the scope and rules of engagement and how the TTPs will be implemented during the exercise.
TTP Outline for FIN7:
For continuous emulation exercises, it is worth noting that adversary TTPs can change over time, so staying up-to-date with the latest threat intelligence is essential.
Planning the Threat Emulation Engagement
Since threat emulation involves conducting and mimicking actual cyber attacks, significant problems may ensue if not properly planned and coordinated. The issues may include disclosure of private data, data loss and unplanned system downtime.
Planning the emulation activities through defining the rules of engagement for the exercise, including communication and approvals, is vital to avert these risks. Planning also involves determining the resources needed for the activity, such as personnel, time, and equipment.
Threat Emulation Plans
Primary components of a Threat Emulation plan are,
- Engagement Objectives: We have seen that the objectives are defined at the beginning of the process to understand the need for threat emulation.
- Scope: The departments, users and devices upon which emulation activities are permitted should be defined explicitly.
- Schedule: The dates and times when the activities should occur and when deliverables are due should be defined. This helps avoid conflicts between emulation activities and legitimate business operations.
- Rules of Engagement: The acceptable adversary behaviour to be emulated must be planned and discussed. This also includes mitigation actions for any high-risk TTPs used during the exercise.
- Permission to Execute: Explicit written consent to conduct the emulation activities must be provided by sufficient authority from the organisation. This helps avoid acting out independently and risking legal or criminal problems.
- Communication Plan: The emulation team and organisation stakeholders must have a plan to communicate information concerning the emulation activities. You need to define the timings, communication channels, and any collaboration efforts to be included.
Conducting the Emulation
This step involves carrying out the attack using the TTPs identified in the research phase. The exercise should be conducted controlled and safely, and any issues should be addressed immediately.
Planning the Deployment
We can use ATT&CK to understand the TTPs and map them out using the Navigator. This would be combined with CTI resources. For example, if we are emulating APT FIN7 then CTI resources, such as Mandiant’s FIN7 Evolution Report and ESentire FIN7 Report, help to outline how FIN7 used Windows document lures to execute their campaign.
Implementation of TTP
This is where the deployment of actual TTPs happens. In case of FIN7 APT, an Initial Access payload for FIN7 would be created and obfuscated using an RTF document, delivered through a spear phishing email. The lures used by attackers such as FIN7 tend to be convincing using DOCX and RTF files with malicious Windows Shortcut File (.LNK) embedded.
Detections & Mitigations
Since emulation is a cross-team and collaborative endeavour, the defence team must find ways to detect and mitigate against emulated TTPs. The SOC would use standard cyber security tools to collect, correlate and analyse TTP behaviour and logs for detection.
MITRE provides a list of mitigation efforts for the adversarial TTPs, and this can be provided as recommendations and implemented as part of the emulation. In FIN7 APT case, we can look at the Malicious File T1204.002 mitigations and detection strategies.
Observe Results
While going through the emulation engagement, the observing team (typically Blue Team) must identify artefacts that point to the emulation activity. This will be through the analysis of logs, evaluation of event logs and tracking of networking traffic.
Helpful adversary emulation library:
In collaboration with Center Participants, the Center for Threat-Informed Defense (Center) maintains a library of adversary emulation plans to allow organizations to evaluate their defensive capabilities against the real-world threats they face.
https://github.com/center-for-threat-informed-defense/adversary_emulation_library/tree/master
Document & Report Findings
Once results have been obtained, the teams must document and report the findings. Documentation provides empirical evidence to demonstrate the cyber security effectiveness of the process.