Threat Informed Defence: Play the Metagame

STRIDE is a widely used threat modelling framework for identifying potential security threats by categorising them into six types:

• Spoofing: Risks of attackers impersonating users or systems to gain unauthorised access.
• Tampering: Possibility of attackers modifying data or communications.
• Repudiation: Threat of users or systems denying actions or transactions, often due to missing audit trails.
• Information Disclosure: Risk of sensitive data exposure to unauthorised parties.
• Denial of Service (DoS): Potential for services or resources to be unavailable to legitimate users.
• Elevation of Privilege: Risk of users or attackers gaining higher permissions, enabling unauthorised access or control.

In STRIDE, each threat type is analysed by reviewing system components (e.g., users, processes, data flows) and the security risks associated with each. This structured approach allows development teams to address vulnerabilities, prioritise risks, and tailor mitigations for specific threats.

STRIDE is highly effective during development, as it provides a comprehensive view of potential threats. However, once a system is operational, real-world threats become a priority. This is where Threat Informed Defence steps in, enabling teams to align defences against actual tactics used by adversaries, transforming a broad threat model into targeted protection.

Threat Informed Defence systematically applies an understanding of adversary tactics to strengthen defences. Unlike traditional threat modelling, which primarily identifies vulnerabilities, Threat Informed Defence focuses on how real-world attackers operate. By integrating insights on adversary tactics, techniques, and procedures (TTPs) into security strategies, organisations can proactively anticipate and counter actual threats. This approach uses threat intelligence, frameworks like MITRE ATT&CK®, and other insights into adversarial behaviour.

Key steps in Threat Informed Defence:

• Mapping Adversary TTPs: Using frameworks such as MITRE ATT&CK to identify the specific tactics attackers may employ.
• Testing and Evaluation: Using simulated attacks or red teaming to validate defences against known threats.
• Defensive Measures: Focusing on defences that best counter the most likely TTPs based on risk.
• Continuous Adaptation: Regularly updating defences and threat models based on new intelligence about adversary techniques.

In a full Threat Informed Defence strategy, testing defences through simulated attacks and adapting defences based on evolving intelligence are essential. However, for this discussion, we’ll focus on mapping adversary TTPs and prioritising defences.

The above diagram is dense and highly tool-specific, which obscures the bigger picture. Security professionals don’t need specific tools for each step; the goal is a tool-agnostic, adaptable framework.

This brings us back to the concept of a metagame. Just as players in a game use a deeper understanding of opponents’ strategies to outmanoeuvre them, Threat Informed Defence lets organisations anticipate and mitigate real-world threats based on adversary behaviour.

A metagame is a layer of strategy beyond a game’s basic rules, where players adapt to trends, known strategies, and opponents’ behaviours to gain an edge. In competitive settings, the metagame evolves as players adjust their approaches based on the most effective or popular tactics, creating a cycle of adaptation and counter-strategies. For instance, in a card game, players might adopt decks that are popular because they win often, shaping the “meta.” Other players then develop counter-decks, further shifting the metagame. This concept applies in many contexts, from gaming and sports to business and cybersecurity, capturing the “game within the game.”

To illustrate this, I played rock-paper-scissors with two audience members. For the first person, I said, “You represent STRIDE. STRIDE looks at all the possible things that can go wrong, so I’ll tell you up front: I might use rock, scissors, or paper. Use that knowledge to your advantage.” I then played paper repeatedly to simulate an adversary using a fixed playbook. Ironically, I still won more rounds than I lost.

For the next person, I said, “You represent Threat Informed Defence. You’ve seen how I operate; use that knowledge to your advantage.” After a few rounds, they realised I was using only paper and started winning every time.

This simplified metagame illustrates the core of Threat Informed Defence. The “meta” was my predictable use of paper, allowing the second participant to counter it. In Threat Informed Defence, we apply a deep understanding of adversary strategies and our own weaknesses to adjust defences. Simply put, it means figuring out adversaries’ moves and addressing our vulnerabilities to effectively counter them.

Threat Informed Defence is about applying a deep understanding of adversary tactics and technology to strengthen defences. We begin with understanding adversary tradecraft, which means gathering intelligence on our adversaries.

The Intelligence Cycle is a structured, five-stage process used to gather, analyse, and deliver intelligence that supports decision-making:

• Planning and Direction: Define intelligence needs, set objectives, and prioritise tasks to identify required information.
• Collection: Gather raw data from various sources, such as human intelligence, signals, or open-source data.
• Processing and Exploitation: Convert collected data into usable information through translation, decryption, and organisation.
• Analysis and Production: Interpret and synthesise processed information to produce actionable insights and intelligence reports.
• Dissemination: Share final intelligence products with stakeholders, enabling informed decisions and actions.

This cycle is iterative, with feedback continually refining priorities and aligning intelligence activities to address evolving threats.

In intelligence work, data, information, and intelligence represent stages of processing and contextual value:

• Data: Raw, unprocessed material — facts, figures, or signals — without inherent meaning. It serves as the building blocks of intelligence.
• Information: Organised and processed data. This stage involves translation, categorisation, and decryption, making it accessible yet still lacking specific context for decision-making.
• Intelligence: The outcome of analysing information. In this phase, analysts interpret and synthesise information to create actionable insights, enabling strategic, operational, or tactical decisions.

This progression ensures decision-makers receive relevant, actionable intelligence rather than isolated data points.

Theory is essential, but real-world collection is where the challenge begins. Moving from data to actionable intelligence means navigating a complex landscape — translating raw signals into clear insights on adversary behaviours and using this intelligence to anticipate and counter their next moves.

Collection can range from a simple Google search for adversaries targeting your industry and region to a fully automated collection pipeline.

A basic example of a collection pipeline is described here, which demonstrates how to monitor keywords using Python and an open-source metasearch engine called Searx. This pipeline automates keyword searches across multiple sources and saves relevant results for further analysis. Key steps include:

• Setting Up Keywords: Users define specific keywords related to sensitive topics, cybersecurity terms, or potential data leaks.
• Automating Searches with Searx: The pipeline uses Searx to conduct regular, multi-source searches, retrieving any results with the specified keywords.
• Extracting and Storing Data: Relevant results are saved in a local database or file, making them accessible for review.
• Alerting and Review: Alerts notify users of results found, allowing for timely analysis.

This automated approach enables continuous monitoring without the need for manual searching, streamlining the collection and initial processing of relevant information.

While Searx is no longer maintained, Arachne Digital offers a fork called Tracery. Tracery is open-source and free, providing a reliable metasearch engine.

Now that we’ve collected data — likely news articles on hacks targeting similar organisations — we need to turn this data into actionable intelligence focused on adversary tradecraft. This is where MITRE ATT&CK comes in.

MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) is a well-established framework for understanding and categorising cyber threats. It maps out adversaries’ tactics (attack goals) and techniques (methods to achieve those goals) across various attack phases, such as initial access, persistence, and exfiltration. Each technique is documented with real-world examples, making ATT&CK a powerful resource for threat modelling, detection, and response. By aligning defences with ATT&CK, organisations can better anticipate, detect, and counter known adversary behaviours.

The value for us is that each ATT&CK technique maps to specific mitigations and detections. When we know which adversaries target our industry, we can track their TTPs, identify corresponding controls, and align defences accordingly — that’s our “metagame.”

Mapping large amounts of free-text data to ATT&CK, however, is challenging. MITRE offers a best practices guide for ATT&CK mapping (see here), but training remains limited. A straightforward approach is to start with ATT&CK’s own mappings of cyber threat actors, available here. However, this dataset lacks multiple relevant groups and the information is lagging behind current-year threat data.

This is where a custom collection pipeline becomes essential for gathering fresh intelligence. For those seeking an automated solution, tools like TRAM (available here) provide some mapping capabilities. However, TRAM has experienced periods of inactivity and limited updates. To address this, Arachne Digital maintains a regularly updated fork called Thread, which is designed for more accurate and ongoing ATT&CK mapping.

If building and managing your own threat intelligence collection seems daunting, purchasing threat intelligence feeds is an option. However, choose feeds carefully — many only provide indicators of compromise (IOCs), which don’t reveal the TTPs crucial for building a threat informed defence. Instead, look for feeds that enable you to understand your threat model, detailing active cyber threat actors targeting your industry and their current TTPs. This approach enables you to stay updated and adapt your defences based on relevant, timely intelligence.

With a clear picture of the adversaries and their TTPs, our next step in threat informed defence is understanding our own technology environment. This requires knowledge across three key areas: business, technical, and risk contexts.

Business Context: Understanding an asset’s role in the organisation, the data it handles, and its operational importance. This context identifies the criticality of an asset and its potential impact on the business if compromised.

• Example: An application managing sensitive financial data is a high-value target due to the nature of the information it handles.
• Detection Use Case: Monitor for unauthorised access attempts, as this application’s data makes it an attractive target.

Technical Context: The technical configuration of assets, including user roles, access controls, and system integrations. This context helps identify vulnerabilities and dependencies within the system.

• Example: A change in server configurations might disable essential security controls.
• Detection Use Case: Track configuration changes to ensure security controls remain active.

Risk Context: Reviewing existing risk assessments for documented threats like system vulnerabilities. This helps define what could go wrong and informs controls.

• Example: If a web server is at end-of-life and vulnerable, it is at risk of exploitation.
• Detection Use Case: Monitor traffic for attempts to exploit known vulnerabilities.

With these contexts in place, we can implement both mitigative and detective controls tailored to each asset’s specific needs.

As the tired but applicable quote from Sun Tzu goes,

“If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.”

This wisdom captures the essence of threat informed defence — by knowing both our adversaries and ourselves, we can anticipate and counter threats with confidence.

Now it’s time to implement controls for each use case identified. These controls should address both the adversary tradecraft and specifics of the application to either mitigate or monitor potential issues.

Mitigating controls are generally straightforward. For example, if you have an internet-facing login portal, implementing two-factor authentication reduces the risk of unauthorised access. The risk has been mitigated to a degree.

Detection, however, is more involved. Effective detection requires several key elements, including:

• The Right Logs: Collect logs that provide relevant information for your use cases.
• Log Aggregation and Storage: A central place to store and manage logs.
• SIEM Tool: A platform to analyse logs for security events.
• Defined Queries and Alerts: Specific rules for detecting suspicious activity.
• 24/7 Monitoring: A team available to respond to alerts around the clock.
• Incident Response Team and Plan: A structured response plan, tested and backed by organisational buy-in.

Even with these resources in place — which is rare — detection requires careful setup.

The below examples are just pseudocode to get you thinking in the right direction. They would also need tuning based on your specific environment. The examples assume that you’re collecting logs from Linux devices, but the overall idea is the same no matter what is generating your logs.

An adversary in your threat model frequently uses scheduled tasks. To detect this, your queries or alerts might include the following:

RULE “Detect Suspicious Scheduled Task Activity”

Condition 1: Monitor task-scheduling processes.

IF process_name IN ["cron", "atd", "systemd-timer"] AND
   command_line CONTAINS ["/bin/bash", "/usr/bin/python", "/usr/bin/perl", "/bin/sh"]
THEN
    SET priority = HIGH
    SET alert_message = "Suspicious task scheduling process execution detected"

This condition tracks the execution of task-scheduling processes — like cron, atd, and systemd-timer — that are often used to automate recurring tasks. By monitoring these processes, we can detect when an attacker may be trying to schedule malicious tasks, such as automated scripts or commands that run without user oversight. This rule adds an extra layer of scrutiny to these scheduled processes, especially if they invoke common shell or script interpreters (e.g., /bin/bash, /usr/bin/python), which can indicate an attempt to maintain persistence or execute unauthorised commands on the system.

Condition 2: Monitor for unusual processes spawned by scheduled tasks.

IF parent_process_name IN ["cron", "atd", "systemd-timer"] AND
   child_process_name IN ["<suspicious_process>"] AND
   command_line CONTAINS ["<suspicious_argument>"]
THEN
    SET priority = HIGH
    SET alert_message = "Suspicious process spawned from scheduled task"

This condition watches for suspicious processes that start under the task-scheduling processes cron, atd, or systemd-timer. By tracking the “parent” (scheduling process) and the “child” (spawned process), it helps identify when attackers may be using scheduled tasks to execute unauthorised or unusual programs. For this condition to function, you would need to baseline your environment to see what child processes cron, atd, and systemd-timer usually spawn and what command line arguments normally kick all this off. Suspicious processes or arguments would be any you’ve not seen before.

Condition 3: Monitor for changes in critical directories related to scheduled tasks.

IF file_path IN ["/etc/cron.d/", "/etc/cron.daily/", "/etc/systemd/system/", "/var/spool/cron/crontabs/"] AND
   (file_action == "CREATE" OR file_action == "MODIFY")
THEN
    SET priority = MEDIUM
    SET alert_message = "File creation/modification in scheduled task directory"

This condition keeps track of any file creation or modification within directories critical to scheduled tasks, such as /etc/cron.d/, /etc/cron.daily/, and /etc/systemd/system/. These directories control which tasks run on a schedule, so unauthorised changes here can indicate an attempt to inject or alter scheduled jobs for malicious purposes. By monitoring these directories, this rule helps detect potential tampering with scheduled tasks that could be used to establish persistence or run unauthorised commands at regular intervals.

With these conditions in place, we know which logs to capture:

Logs Required:

• Parent and child process names
• Command-line arguments
• File paths and actions (creation, modification)

Log Configuration:

• Use Auditd Logs to capture required information.
• Log File: /var/log/audit/audit.log
• Use Syslog to capture and forward logs.
• Log File: /var/log/syslog or /var/log/messages

By configuring these logs and forwarding them to your SIEM, you’ve created a detection pipeline that aligns precisely with the threat model.

Starting with adversary tactics and ending with specific fields in specific logs, you’ve taken intelligence from the threat landscape all the way to targeted detection — transforming insights into actionable defences. How cool is that?

Threat Informed Defence is about systematically applying a deep understanding of adversary tradecraft and your own technology to enhance defences.

• Threat Landscape: Defines the cyber threat actors to focus on.
• Cyber Threat Actors: Determine the tactics, techniques, and procedures (TTPs) to address.
• Adversary Tradecraft: TTPs drive detection use cases — the “adversary” side of Threat Informed Defence.
• Business, Technical, and Risk Context: These define additional detection use cases — the “technology” side of Threat Informed Defence.
• Detection Use Cases: Guide the specific log fields to onboard into detection tools.

In short, understand the metagame — align both your intelligence on adversaries and insights on your own assets — and configure defences that directly counter real-world threats.