Intelligence-Led Security Testing

Introduction

Organizations perform security testing to identify vulnerabilities, evaluate security controls, and determine whether their systems can withstand cyberattacks. Traditional security testing often relies on predefined testing methodologies, vulnerability databases, known weaknesses, and established assessment procedures.

However, security testing becomes more meaningful when it is guided by an understanding of the threats an organization is likely to face. Different organizations have different business objectives, technology environments, critical assets, threat exposures, and risk profiles. A generic testing approach may identify technical weaknesses without adequately evaluating whether those weaknesses can be exploited by relevant threat actors.

Intelligence-Led Security Testing addresses this limitation by using cyber threat intelligence to guide the selection, prioritization, design, and execution of security tests. It focuses on realistic attack scenarios based on relevant adversaries, their intentions, capabilities, tactics, techniques, and procedures (TTPs).

The objective is to determine whether an organization’s security controls can prevent, detect, respond to, and recover from attacks that are relevant to its operating environment.

Fundamentals of Intelligence-Led Security Testing

Definition of Intelligence-Led Security Testing

Intelligence-Led Security Testing is a risk-driven security testing approach that uses relevant cyber threat intelligence to identify realistic attack scenarios and evaluate an organization’s ability to defend against them.

It combines threat intelligence, security assessment, penetration testing, adversary emulation, red teaming, and security control validation to assess how effectively an organization can withstand threats associated with its business environment.

Rather than testing only for known vulnerabilities, this approach considers the behavior, capabilities, techniques, and objectives of relevant threat actors.

Intelligence-Led Security Testing is an overarching approach rather than a single standardized testing methodology. It can incorporate different testing methodologies depending on the organization’s objectives, threat exposure, regulatory requirements, and security maturity.

Objectives of Intelligence-Led Security Testing

The primary objectives include:

• Identifying threats relevant to the organization’s business and technology environment
• Understanding the tactics, techniques, and procedures used by relevant threat actors
• Developing realistic attack scenarios based on threat intelligence
• Evaluating the effectiveness of preventive, detective, and corrective security controls
• Identifying security weaknesses that could be exploited by relevant adversaries
• Validating security monitoring, incident detection, and response capabilities
• Assessing the organization’s ability to contain and recover from simulated attacks
• Prioritizing remediation based on threat relevance and business risk

Importance of Intelligence-Led Security Testing

Traditional security assessments often identify vulnerabilities based on their technical severity. However, technical severity alone does not indicate how relevant those vulnerabilities are to actual adversary activities or the potential risks they pose.

Intelligence-Led Security Testing addresses this limitation by incorporating Cyber Threat Intelligence to identify relevant threat actors, understand their attack techniques, and assess potential attack paths. This enables security testing teams to prioritize testing activities based on threat relevance, evaluate security controls against realistic attack scenarios, and identify weaknesses that could be exploited by adversaries.

Its importance includes:

• Improving the relevance of security testing activities
• Aligning testing priorities with organizational risks
• Evaluating security controls against realistic attack techniques
• Identifying gaps between documented security controls and actual defensive capabilities
• Improving coordination between threat intelligence, security testing, and security operations teams
• Supporting security investment decisions through evidence-based findings

Principles of Intelligence-Led Security Testing

Intelligence-Led Security Testing follows several important principles.

Threat Relevance

Testing activities should be based on threats that are relevant to the organization’s industry, business operations, technology environment, and threat exposure.

Risk-Based Prioritization

Testing should prioritize critical business services, sensitive information, important infrastructure, and systems exposed to significant threats.

Adversary Behavior

Testing scenarios should reflect the behavior and techniques of relevant threat actors rather than relying exclusively on generic attack simulations.

Control Effectiveness

The objective is not limited to identifying vulnerabilities. Testing should evaluate whether security controls operate effectively when exposed to realistic attack techniques.

Business Context

Testing activities should consider business impact, operational dependencies, critical services, and the potential consequences of successful attacks.

Continuous Improvement

Testing findings should contribute to remediation, security control improvements, threat intelligence refinement, and subsequent validation activities.

Intelligence-Led Security Testing vs. Traditional Security Testing

Traditional Security Testing primarily focuses on identifying vulnerabilities, misconfigurations, and security weaknesses through predefined assessment methodologies and testing procedures. Intelligence-Led Security Testing takes a more targeted and risk-driven approach by using cyber threat intelligence to understand relevant threat actors, their objectives, and their Tactics, Techniques, and Procedures (TTPs). While traditional testing evaluates an organization’s security posture against known vulnerabilities and established testing criteria, intelligence-led testing assesses how effectively its security controls can prevent, detect, and respond to realistic attack scenarios associated with relevant threats. Both approaches complement each other, but Intelligence-Led Security Testing provides greater context by aligning testing activities with the organization’s threat exposure, critical assets, and business risks.

The following table highlights the key differences between Traditional Security Testing and Intelligence-Led Security Testing across various aspects:

Aspect	Traditional Security Testing	Intelligence-Led Security Testing
Testing approach	Uses predefined testing procedures and assessment methodologies	Uses threat intelligence to guide testing activities
Testing focus	Identifies vulnerabilities and technical weaknesses	Evaluates exposure to relevant adversaries and attack techniques
Threat consideration	May use generic threat assumptions	Considers relevant threat actors, capabilities, and attack behavior
Attack scenarios	Often based on known vulnerabilities and standard test cases	Based on intelligence-derived attack scenarios
Prioritization	Commonly influenced by vulnerability severity and assessment scope	Considers threat relevance, business risk, and asset criticality
Security controls	Tests whether controls and configurations meet requirements	Evaluates how controls perform against realistic attack techniques
Detection and response	May be outside the primary testing scope	Can explicitly validate detection, response, and recovery capabilities
Outcome	Identifies vulnerabilities and compliance gaps	Provides evidence of defensive effectiveness against relevant threats

Threat Intelligence in Security Testing

Cyber threat intelligence provides the information required to understand adversaries, their capabilities, intentions, infrastructure, and attack methods. It helps security teams determine which threats should influence testing priorities and how realistic attack scenarios should be developed.

Role of Cyber Threat Intelligence

Cyber Threat Intelligence (CTI) supports Intelligence-Led Security Testing by converting threat-related information into actionable knowledge that can guide security assessments.

Threat intelligence helps testing teams understand:

• Which threat actors are targeting the organization’s industry
• What business objectives or information those actors may pursue
• Which attack techniques are commonly associated with those actors
• What vulnerabilities and technologies are being targeted
• Which indicators and attack patterns may be relevant
• How adversaries gain initial access, establish persistence, and move through environments

Threat intelligence should be evaluated for relevance, reliability, timeliness, and applicability before it is used to develop testing scenarios.

Identifying Relevant Threat Actors

Threat actors are individuals, groups, or organizations that conduct activities capable of causing harm to an organization’s systems, information, or business operations.

Threat intelligence helps identify threat actors whose intentions and capabilities are relevant to an organization’s operating environment.

Examples include:

• Nation-state actors targeting government organizations and critical infrastructure
• Cybercriminal groups conducting ransomware and financial attacks
• Hacktivist groups targeting organizations for ideological or political reasons
• Insider threats involving employees, contractors, or other trusted individuals
• Advanced Persistent Threat (APT) groups conducting targeted and sustained operations

Threat actor selection should consider the organization’s industry, geographical exposure, business activities, technology environment, and known targeting patterns.

Understanding Adversary Tactics, Techniques, and Procedures (TTPs)

Tactics, Techniques, and Procedures describe how adversaries conduct cyber operations.

• Tactics describe the adversary’s technical objectives, such as initial access, persistence, privilege escalation, and data exfiltration
• Techniques describe the methods used to achieve those objectives, such as phishing, credential dumping, or exploitation of public-facing applications
• Procedures describe how an adversary implements specific techniques in an actual operation, including the tools, commands, infrastructure, and sequence of activities used

Understanding TTPs helps security testing teams reproduce relevant adversary behavior and evaluate whether organizational controls can identify and prevent those activities.

The MITRE ATT&CK framework provides a structured knowledge base of adversary tactics and techniques that can support this analysis and the development of testing scenarios.

Identifying Threat Indicators and Attack Patterns

Threat intelligence includes technical indicators and behavioral information that can help security teams understand and identify malicious activity.

Indicators of Compromise (IOCs) are observable artifacts that may indicate a system or environment has been compromised.

Examples include:

• Malicious IP addresses and domain names
• File hashes associated with malicious software
• Suspicious URLs and email addresses
• Malicious files and executable artifacts
• Known command-and-control infrastructure

Attack patterns provide additional context about how adversaries conduct their activities. They may include suspicious authentication sequences, unusual network connections, privilege escalation behavior, lateral movement, and data transfer patterns.

Testing teams can use these indicators and patterns to develop scenarios that evaluate security monitoring and detection capabilities. However, testing should not rely exclusively on static IOCs because they can change rapidly and may not represent the full range of adversary behavior.

Mapping Threat Intelligence to Risks

Threat intelligence becomes more useful when it is mapped to assets, business services, vulnerabilities, and security controls. This mapping helps security teams understand how identified threats could affect different technology environments, business operations, and critical information resources.

For example, threats such as credential theft, exploitation of internet-facing applications, privilege escalation, and unauthorized data access can be mapped to relevant assets and security controls across different IT infrastructure and business environments.

The testing team can map these threats to:

• Internet-facing applications
• Identity and authentication systems
• Privileged accounts
• Critical business applications
• Sensitive information and data repositories
• Network and cloud infrastructure
• Security monitoring and incident response controls

This mapping helps identify potential attack paths, evaluate security control effectiveness, and prioritize testing activities based on the relevance of identified threats and their potential impact.

Prioritizing Security Testing Based on Threat Intelligence

Not every vulnerability or attack technique requires the same level of testing priority. Testing teams should consider threat relevance alongside asset criticality, vulnerability exposure, business impact, and existing security controls.

Prioritization may consider:

• Threat actor interest in the organization or industry
• Evidence of active exploitation
• Exposure of critical systems and services
• Sensitivity and value of the information involved
• Potential operational and financial impact
• Existing security control effectiveness
• Regulatory and contractual requirements

This approach helps organizations allocate testing resources to areas where successful attacks could create the greatest business risk.

Intelligence-Led Security Testing Methodologies

Intelligence-Led Security Testing can incorporate different security testing methodologies. The selection depends on testing objectives, threat intelligence, organizational risk, and the level of adversary simulation required.

Threat-Led Penetration Testing

Threat-Led Penetration Testing (TLPT) is a structured testing approach that uses threat intelligence to simulate realistic attacks against an organization’s critical functions and systems.

It involves identifying relevant threat actors, developing threat scenarios, and conducting controlled penetration testing to evaluate defensive capabilities.

TLPT typically involves:

• Identifying critical business functions and assets
• Conducting threat intelligence assessments
• Selecting relevant threat scenarios
• Developing testing plans and rules of engagement
• Executing controlled attack simulations
• Evaluating detection and response capabilities
• Reporting findings and remediation recommendations

TLPT is particularly relevant in regulated environments where threat-led testing is required or prescribed. For example, the Digital Operational Resilience Act (DORA) establishes threat-led penetration testing requirements for certain financial entities within its scope.

Adversary Emulation

Adversary Emulation is a testing approach in which security teams reproduce the known tactics, techniques, and procedures of selected threat actors.

The objective is to evaluate how effectively an organization’s security controls detect and respond to the activities associated with a particular adversary.

Adversary emulation commonly uses:

• Threat actor profiles
• MITRE ATT&CK techniques
• Documented adversary procedures
• Relevant attack tools and infrastructure
• Controlled attack scenarios

It helps organizations assess their defensive capabilities against specific adversary behaviors rather than generic attack patterns.

Red Teaming

Red Teaming is an offensive security assessment in which a team simulates the activities of an adversary to evaluate an organization’s ability to defend against realistic attacks.

Red Team exercises may target people, processes, applications, infrastructure, and physical security, depending on the agreed scope.

Activities may include:

• Reconnaissance and information gathering
• Initial access attempts
• Credential compromise
• Privilege escalation
• Lateral movement
• Persistence establishment
• Access to critical systems and information
• Simulated data exfiltration

Red Teaming evaluates the organization’s overall defensive capabilities and helps identify weaknesses across people, processes, and technology.

Purple Teaming

Purple Teaming is a collaborative security testing approach in which offensive security teams and defensive security teams work together to improve detection and response capabilities.

The Red Team performs controlled attack activities, while the Blue Team monitors, detects, investigates, and responds to those activities.

The collaboration helps teams understand whether specific attack techniques are visible to security monitoring systems and whether appropriate response procedures are followed.

Purple Teaming may involve:

• Executing selected adversary techniques
• Observing security alerts and telemetry
• Validating detection rules and monitoring logic
• Identifying visibility and detection gaps
• Improving security analytics and response procedures
• Retesting modified detection capabilities

Attack Simulation

Attack Simulation involves reproducing selected attack techniques or scenarios in a controlled environment to evaluate the effectiveness of security controls.

It can be used to test specific attack paths, security configurations, endpoint protections, email security controls, network defenses, and cloud security mechanisms.

Examples include:

• Simulating phishing and credential theft
• Testing endpoint protection against controlled malicious activity
• Simulating lateral movement
• Testing network segmentation
• Evaluating access control enforcement
• Simulating command-and-control communication

Attack simulation may be performed using automated tools, manual testing procedures, or a combination of both.

Security Control Validation

Security Control Validation evaluates whether implemented security controls operate as intended when exposed to relevant attack techniques.

It focuses on verifying the effectiveness of controls rather than relying only on documentation, configuration reviews, or compliance assessments.

Examples include:

• Validating whether endpoint protection detects malicious execution
• Testing whether firewalls block unauthorized network communication
• Evaluating whether multi-factor authentication prevents unauthorized access
• Validating whether SIEM correlation rules detect suspicious activity
• Testing whether incident response procedures are activated appropriately
• Evaluating whether backup and recovery controls support restoration

Security control validation can be performed independently or as part of broader adversary emulation and Red Team exercises.

Intelligence-Led Security Testing Lifecycle

Intelligence-Led Security Testing follows a structured lifecycle that connects threat intelligence, organizational risk, testing activities, security control evaluation, and remediation.

Define Testing Objectives and Scope

The first step is to establish the purpose and boundaries of the testing exercise.

Testing objectives should define what the organization intends to evaluate, such as its ability to prevent unauthorized access, detect adversary activity, protect critical assets, or respond to targeted attacks.

The scope should identify:

• Systems, applications, and infrastructure included in testing
• Critical business services and supporting dependencies
• Network, cloud, endpoint, and identity environments
• Testing locations and operating environments
• Excluded systems and restricted activities
• Business owners and technical stakeholders
• Testing limitations and safety requirements

Identify Critical Assets and Business Services

The organization should identify the assets and business services that require protection.

Asset identification helps testing teams understand where successful attacks could create significant business impact.

Examples include:

• Customer-facing applications
• Financial and transaction processing systems
• Identity and access management platforms
• Enterprise databases
• Critical network infrastructure
• Cloud workloads and services
• Operational technology systems
• Sensitive business and customer information

Asset criticality should be evaluated based on business importance, confidentiality, integrity, availability, operational dependency, and regulatory obligations.

Gather and Analyze Relevant Threat Intelligence

The testing team gathers threat intelligence from internal and external sources to understand the threats relevant to the organization.

Sources may include:

• Internal security incidents and investigations
• Threat intelligence platforms
• Government and industry threat advisories
• Information-sharing communities
• Security research publications
• Vulnerability disclosures
• MITRE ATT&CK
• Commercial and open-source intelligence feeds

The collected information should be analyzed to identify relevant threat actors, attack methods, targeting patterns, exploited vulnerabilities, and potential attack paths.

Identify Relevant Threat Actors and Attack Techniques

Based on the intelligence assessment, the testing team identifies threat actors and their associated attack techniques.

The selection should consider the likelihood of targeting, adversary capabilities, industry relevance, and potential business impact.

The team can use MITRE ATT&CK to organize relevant techniques across the different stages of an attack.

This step provides the foundation for developing realistic attack scenarios.

Map Threats to Organizational Assets and Security Controls

Relevant threats and attack techniques should be mapped to the organization’s critical assets and existing security controls.

For example, credential theft may be mapped to identity platforms, privileged accounts, authentication controls, endpoint monitoring, and SIEM detection rules.

This mapping helps identify:

• Assets exposed to relevant attack techniques
• Security controls expected to prevent the attack
• Monitoring mechanisms expected to detect the activity
• Response procedures expected to contain the attack
• Existing control gaps and security dependencies

Develop Intelligence-Based Attack Scenarios

The testing team develops realistic attack scenarios using the selected threat intelligence and organizational context.

Each scenario should define the attack objective, targeted assets, relevant adversary techniques, expected security control responses, and testing conditions.

Examples include:

• Compromising user credentials through phishing
• Exploiting an internet-facing application
• Gaining unauthorized access to privileged accounts
• Moving laterally between network segments
• Accessing sensitive business information
• Establishing simulated command-and-control communication
• Attempting unauthorized data transfer

Scenarios should be realistic but controlled to avoid unintended disruption to business operations.

Define Testing Rules of Engagement

Rules of Engagement (RoE) establish the conditions under which security testing can be conducted.

They provide the authorization, boundaries, responsibilities, and operational safeguards required for the exercise.

Rules of Engagement should define:

• Testing authorization and approvals
• Scope and excluded systems
• Testing dates and permitted time windows
• Approved tools and techniques
• Testing source addresses and infrastructure
• Communication and escalation procedures
• Emergency stop conditions
• Data handling and evidence protection requirements
• Restrictions on destructive or disruptive activities

Prepare the Testing Plan and Environment

The testing team prepares the operational plan before executing the exercise.

Preparation includes confirming the testing scope, validating tools, coordinating with stakeholders, and ensuring that appropriate safeguards are in place.

Key activities include:

• Finalizing attack scenarios and test cases
• Preparing testing infrastructure and tools
• Confirming access and connectivity requirements
• Coordinating with SOC and IT teams
• Establishing baseline monitoring and logging
• Confirming backup and recovery arrangements where required
• Validating emergency communication channels
• Establishing evidence collection procedures

Execute Intelligence-Led Security Tests

The testing team executes the approved attack scenarios in accordance with the testing plan and Rules of Engagement.

The objective is to evaluate how security controls perform during simulated adversary activity.

Simulating Relevant Attack Techniques

The team performs selected attack techniques based on the intelligence assessment and approved scenarios.

Activities may include initial access simulation, credential abuse, privilege escalation, lateral movement, persistence testing, and controlled attempts to access sensitive information.

Evaluating Security Control Effectiveness

The team evaluates whether preventive controls block or restrict the simulated attack activities.

It also assesses whether detective controls generate appropriate alerts and whether corrective controls support containment and remediation.

Validating Attack Detection and Response

The testing team observes how the SOC and other security stakeholders detect, investigate, escalate, and respond to simulated attack activities.

This helps determine whether monitoring systems, incident response procedures, and communication processes operate effectively.

Analyze Testing Results

After execution, the testing team analyzes the collected evidence and evaluates the results against the original testing objectives.

Analysis should consider:

• Attack techniques successfully executed
• Attack techniques blocked by security controls
• Activities detected by monitoring systems
• Activities that were not detected
• Response and escalation effectiveness
• Security control weaknesses
• Potential business impact
• Gaps between expected and observed defensive behavior

Document Findings and Recommendations

The testing team documents the results in a structured report.

Findings should explain the attack scenario, evidence, affected assets, security control performance, business impact, and recommended corrective actions.

Recommendations should be practical, prioritized, and aligned with the organization’s risk management process.

Remediation and Retesting

Identified weaknesses should be assigned to the appropriate control owners for remediation.

Remediation activities may include:

• Correcting vulnerable configurations
• Strengthening identity and access controls
• Improving network segmentation
• Updating endpoint and application protections
• Improving security monitoring and detection rules
• Updating incident response procedures
• Improving security awareness and operational processes

Retesting should be performed to verify whether the identified weaknesses have been addressed and whether the relevant security controls operate effectively.

Security Control Validation Through Intelligence-Led Testing

A central objective of Intelligence-Led Security Testing is to determine whether organizational security controls can withstand relevant adversary techniques.

Security controls can be evaluated across preventive, detective, and corrective control categories.

Preventive Security Control Validation

Preventive controls are designed to stop or reduce the likelihood of unauthorized activities and security incidents.

Testing evaluates whether these controls prevent the selected attack techniques from succeeding.

Examples include:

• Firewall rules and network access controls
• Multi-factor authentication
• Privileged access restrictions
• Endpoint protection and application controls
• Network segmentation
• Secure configuration and hardening
• Email and web security controls

Detective Security Control Validation

Detective controls identify suspicious activities, security violations, and potential incidents.

Testing evaluates whether these controls generate appropriate alerts and provide sufficient visibility into simulated adversary activity.

Examples include:

• Security Information and Event Management (SIEM)
• Endpoint Detection and Response (EDR)
• Network Detection and Response (NDR)
• Intrusion Detection Systems (IDS)
• User and Entity Behavior Analytics (UEBA)
• Cloud security monitoring
• Database activity monitoring

Corrective Security Control Validation

Corrective controls support the containment, remediation, and recovery of systems affected by security incidents.

Testing evaluates whether the organization can take appropriate action after an attack has been detected.

Examples include:

• Endpoint isolation
• Account disabling and credential resets
• Malware removal and system remediation
• Firewall rule changes
• Incident containment procedures
• Backup restoration
• Disaster recovery procedures

Security Monitoring and Detection Validation

Security monitoring and detection validation evaluates whether the organization’s monitoring capabilities can identify the techniques used during simulated attacks.

The testing team should examine whether relevant activities generate alerts, whether logs contain sufficient information, and whether detection rules identify suspicious behavior.

The assessment may include:

• Log collection and event visibility
• Detection rule coverage
• Alert generation and prioritization
• Correlation of security events
• Detection of lateral movement and privilege escalation
• Identification of suspicious outbound communication
• Monitoring of privileged and sensitive activities

Incident Response Capability Validation

Incident response validation evaluates whether the organization can investigate, contain, eradicate, and recover from simulated security incidents.

The exercise should assess the coordination between SOC, incident response, IT Security, infrastructure teams, application owners, and business stakeholders.

Key areas include:

• Incident identification and classification
• Investigation and evidence collection
• Escalation and stakeholder communication
• Containment and eradication
• Recovery and service restoration
• Incident documentation and reporting
• Lessons learned and corrective actions

Roles and Responsibilities

Intelligence-Led Security Testing requires coordination between multiple teams. Each team contributes information, technical capabilities, operational support, or governance oversight.

Cyber Threat Intelligence Team

The Cyber Threat Intelligence team provides threat information and analysis to guide security testing activities.

Responsibilities include:

• Identifying relevant threat actors and campaigns
• Analyzing adversary TTPs
• Providing threat indicators and attack patterns
• Mapping intelligence to organizational risks
• Supporting the development of intelligence-based attack scenarios
• Updating threat assessments based on testing findings

Security Testing and Red Team

The Security Testing and Red Team functions plan and execute the testing activities.

Responsibilities include:

• Developing the testing methodology and plan
• Designing attack scenarios based on threat intelligence
• Conducting penetration testing and adversary emulation
• Executing approved attack techniques
• Evaluating security control effectiveness
• Collecting evidence and documenting findings
• Recommending remediation activities
• Performing retesting after corrective actions

Security Operations Center (SOC)

The SOC monitors the organization’s technology environment and investigates security events generated during testing.

Responsibilities include:

• Monitoring security events and alerts
• Detecting simulated adversary activities
• Investigating suspicious events
• Validating detection and correlation rules
• Following incident escalation procedures
• Coordinating with incident response teams
• Providing detection and response evidence

IT Security and Infrastructure Teams

IT Security and Infrastructure teams support the testing activities and address technical weaknesses identified during the exercise.

Responsibilities include:

• Supporting the testing of security technologies
• Reviewing firewall, endpoint, network, and infrastructure controls
• Investigating technical findings
• Implementing approved security improvements
• Remediating identified vulnerabilities and configuration weaknesses
• Supporting recovery and restoration activities
• Participating in retesting and validation

Governance, Risk, and Compliance (GRC)

The GRC function provides governance oversight and ensures that testing activities align with organizational risk management and compliance requirements.

Responsibilities include:

• Establishing security testing governance requirements
• Ensuring appropriate approvals and authorization
• Aligning testing with organizational risk assessments
• Reviewing findings and associated business risks
• Tracking remediation through risk management processes
• Monitoring compliance and reporting requirements
• Reporting significant risks and unresolved findings to appropriate governance forums

Intelligence-Led Security Testing Deliverables

Testing activities should produce documented outputs that support security improvement, risk management, and management decision-making.

Threat Intelligence Assessment

The Threat Intelligence Assessment documents relevant threat actors, campaigns, attack techniques, indicators, and threat patterns identified during the intelligence analysis.

It provides the basis for selecting testing scenarios.

Intelligence-Based Test Plan

The test plan defines the testing objectives, scope, methodology, schedule, resources, tools, and execution procedures.

It also establishes the expected outcomes and evidence requirements.

Threat-Based Attack Scenarios

Attack scenarios describe the simulated adversary activities, targeted assets, techniques, attack objectives, and expected security control responses.

They provide the operational basis for testing execution.

Security Testing Report

The Security Testing Report documents the testing activities, execution results, vulnerabilities, weaknesses, evidence, and recommendations.

It provides a consolidated view of the organization’s security exposure identified during the exercise.

Security Control Validation Report

The Security Control Validation Report evaluates the effectiveness of preventive, detective, and corrective controls against the selected attack techniques.

It identifies controls that performed as expected and those requiring improvement.

Remediation and Retesting Report

The Remediation and Retesting Report records corrective actions, responsible teams, remediation status, and retesting results.

It provides evidence that identified weaknesses have been addressed or remain open for further action.

Measuring the Effectiveness of Intelligence-Led Security Testing

Organizations should measure the effectiveness of Intelligence-Led Security Testing using defined metrics and performance indicators.

Measurement should consider both the quality of testing activities and the resulting improvement in defensive capabilities.

Adversary Technique Coverage

This metric evaluates the extent to which relevant adversary techniques have been tested against the organization’s environment.

It can be measured by comparing selected threat techniques with the techniques successfully tested during the exercise.

Security Control Effectiveness

This metric evaluates whether security controls successfully prevent, detect, or support the correction of simulated attack activities.

It helps identify controls that require configuration improvements, additional monitoring, or operational changes.

Attack Detection and Response Effectiveness

This metric evaluates how effectively the organization identifies and responds to simulated attack activities.

It may consider:

• Percentage of simulated attack activities detected
• Number of undetected attack techniques
• Time taken to identify suspicious activities
• Time taken to escalate and investigate alerts
• Effectiveness of incident containment
• Accuracy of incident classification

Identified Security Gaps and Weaknesses

This metric measures the security weaknesses identified during testing.

Findings may be categorized based on severity, business impact, affected assets, threat relevance, and security control deficiencies.

Remediation Effectiveness

This metric evaluates whether corrective actions successfully address the identified weaknesses.

It may consider:

• Percentage of findings remediated
• Number of findings remaining open
• Remediation completion time
• Number of recurring findings
• Retesting success rate
• Residual risk after remediation

Key Performance Indicators (KPIs)

Key Performance Indicators (KPIs) provide measurable criteria for evaluating the effectiveness of Intelligence-Led Security Testing. They help assess how well testing activities cover relevant adversary techniques, how effectively security controls prevent and detect simulated attacks, and how efficiently security teams respond to identified threats. KPIs also help measure remediation progress, validate improvements in defensive capabilities, and identify areas requiring further attention. By establishing measurable indicators, testing outcomes can be evaluated consistently, compared across testing exercises, and used to drive continuous improvement in security testing and defensive operations.

The following table presents the key performance indicators used to measure the effectiveness of Intelligence-Led Security Testing and their respective measurement objectives:

KPI	Measurement	Purpose
Adversary Technique Coverage	Percentage of selected techniques tested	Measures coverage of relevant adversary behavior
Attack Detection Rate	Percentage of simulated attack activities detected	Evaluates detection capability
Undetected Attack Techniques	Number of simulated techniques not detected	Identifies monitoring and visibility gaps
Mean Time to Respond (MTTR)	Average time taken to respond to identified simulated security incidents	Evaluates response efficiency
Security Control Effectiveness	Percentage of tested controls performing as expected	Measures defensive control performance
Remediation Completion Rate	Percentage of findings remediated within the agreed timeframe	Evaluates remediation progress
Retesting Success Rate	Percentage of remediated findings successfully validated	Measures the effectiveness of corrective actions

Note: MTTR can have different expansions across organizations. In this article, it refers specifically to Mean Time to Respond and should be defined consistently in the organization’s measurement framework.

Best Practices for Intelligence-Led Security Testing

Organizations should establish a structured and repeatable approach to ensure that testing activities provide meaningful security improvements.

Recommended practices include:

• Aligning testing objectives with business risks and critical assets
• Using relevant and reliable cyber threat intelligence
• Selecting threat actors and attack techniques based on organizational exposure
• Maintaining a mapping between threat intelligence, attack scenarios, and security controls
• Using recognized frameworks such as MITRE ATT&CK to organize adversary techniques
• Defining clear testing authorization and Rules of Engagement
• Coordinating testing activities with SOC, IT Security, infrastructure, and business teams
• Ensuring testing activities do not create unintended business disruption
• Evaluating preventive, detective, and corrective security controls
• Documenting evidence and maintaining traceability between findings and attack scenarios
• Prioritizing remediation based on threat relevance and business impact
• Conducting retesting to validate corrective actions
• Using testing outcomes to improve threat intelligence, security monitoring, and incident response
• Establishing KPIs to measure testing coverage and defensive improvements
• Performing testing periodically and when significant changes occur in the threat environment or organizational technology landscape

References

Online Sources

MITRE – MITRE ATT&CK
Provides a comprehensive knowledge base of adversary tactics and techniques used to understand threat actor behavior, support adversary emulation, and validate security controls

National Institute of Standards and Technology (NIST) – Technical Guide to Information Security Testing and Assessment (SP 800-115)
Provides guidance on planning, conducting, and evaluating technical information security testing and assessments

National Institute of Standards and Technology (NIST) – The NIST Cybersecurity Framework (CSF) 2.0
Provides a framework for managing cybersecurity risks through governance, identification, protection, detection, response, and recovery

MITRE – Cyber Analytics Repository (CAR)
Provides a knowledge base of defensive analytics and detection strategies based on adversary behaviors and MITRE ATT&CK techniques\

CREST – CREST
Provides industry guidance, professional standards, and accreditation information for cybersecurity testing and assessment services