Here is a question most security leaders cannot answer with evidence.
If a ransomware actor used the exact techniques from last quarter’s most active threat group against your environment today, which of your controls would fire, which would block, and which would miss entirely?
For most organisations, the honest answer is: we don’t know.
That is not a failure of intent. Security budgets have grown. EDR agents are deployed. SIEMs are ingesting logs. Firewalls are configured. Cloud security posture tools are running. On paper, the stack looks complete.
And yet, according to AttackIQ’s analysis of customer environments, EDR controls only blocked the seven most commonly tested adversary techniques 39% of the time. In 2024, 48% of ransomware attacks successfully disabled EDR or XDR tools, with only 4% of those removal attempts failing.
Deploying a security tool is not the same as validating that it works.
Security control validation is the practice that closes this gap. For organisations that cannot afford to discover their blind spots during an incident, it is no longer optional.
The False Assurance of Deployed Security Tools
The security industry has built its marketing language around deployment. Tools are sold on detection rates, coverage breadth, and threat library size. The implicit promise in every vendor demo: deploy this, and you will catch the attack.
That promise has a structural flaw.
A tool that is deployed is not necessarily a tool that is tuned, integrated, alerting, and actioned correctly in your environment.
The data is consistent on this point:
- The mean time to detect a breach in 2024 was 194 days, according to Mandiant’s M-Trends report. More than six months passed, on average, before an active intrusion was identified, despite organisations running detection tooling throughout.
- IBM’s 2025 Cost of a Data Breach Report found that after detection, the mean time to respond and contain was a further 73 days, creating a total exposure window of 267 days from initial compromise to containment.
- Barracuda’s 2025 Managed XDR analysis found that 90% of ransomware incidents exploited firewalls, and 96% of incidents that reached lateral movement ended with ransomware deployment.
These outcomes did not occur because organisations lacked security tools. They occurred because the tools organisations had were not validated against the techniques attackers actually use, in the configuration the organisation actually runs.
The gap between having a security control and having a control that works is exactly what threat actors probe for, systematically, before launching their primary attack.
What Detection Tells You, and What It Doesn’t
Detection is a measure of visibility. It answers: did your tools see that something happened?
That is a necessary question. But it is not a sufficient one.
Detection does not tell you whether the tool would have blocked the technique rather than just logging it. It does not tell you whether the alert that fired was routed to the right queue, at the right priority, with enough context for a human analyst to act on it in time. And it does not tell you whether a slightly different variant of the same technique, or a fileless execution method, would have been seen at all.
Detection-centric security thinking produces three specific failure modes:
Alert fatigue without validation. When SIEM tools are not tuned against real adversary behaviour, they generate high volumes of alerts without proportional signal. Analysts work through low-fidelity noise while meaningful indicators are buried in the queue.
Configuration drift. Security controls are not static. Every software update, policy change, new system integration, and cloud configuration adjustment can alter control behaviour. A firewall rule that was correct in January may have been overridden during a migration in March. Without regular testing, drift goes undetected until an incident reveals it.
Vendor-claimed coverage versus real-world coverage. When a vendor claims their EDR blocks a specific technique, that claim is based on a controlled laboratory environment. In your environment, with your configurations, exclusions, and OS builds, the outcome may be materially different.
Three Disciplines: Detection, Security Control Validation, and BAS
Security Detection The monitoring and alerting capability of a security control. It answers: did the tool observe this event? Detection is the foundation of security operations and remains essential. But detection is not validation.
Security Control Validation The process of actively testing whether a security control performs its intended function against a defined set of adversary techniques. It answers: does this control actually block, detect, alert, and respond in the way we expect, in our environment, against the attacks we face?
Validation moves from passive monitoring to active evidence. It does not assume that a deployed control is an effective control.
Breach and Attack Simulation (BAS) The automated technology category that makes security control validation continuous and scalable. BAS platforms safely execute real adversary techniques, drawn from MITRE ATT&CK and current threat intelligence, against production environments. They record which controls detected, blocked, and logged each technique, and which did not.
The critical word is “safely.” BAS simulations produce the behavioural signals that detection tooling should respond to, without actually compromising production data, stealing credentials, or causing disruption. This allows BAS to run continuously in live environments, not just in annual penetration test windows.
The unit of measurement in BAS is control efficacy: did the EDR fire when credential-harvesting behaviour ran? Did the firewall block the C2 callback? Did the SIEM alert route to a human with enough context to act on it? Most organisations are surprised by how many of these questions produce the wrong answer.
How to Validate Each Layer of Your Security Stack
1. Testing Your EDR
EDR tools are often the first control security teams point to when asked what would catch a ransomware attack. Confidence in EDR is frequently higher than the evidence for it.
Modern adversaries increasingly operate using legitimate operating system tools: PowerShell, WMI, PsExec, scheduled tasks, and built-in scripting frameworks. This approach, known as “living off the land,” leaves minimal malware footprint. According to CrowdStrike’s 2026 Global Threat Report, 82% of detected attacks were malware-free. If an EDR’s detection logic is oriented primarily toward known malware signatures, the majority of the current threat landscape passes through without a single alert.
Validation questions for EDR:
- Does the tool detect credential dumping techniques, including LSASS memory access?
- Does it alert when legitimate admin tools are used in sequences consistent with lateral movement?
- Does it block pre-encryption behaviours like shadow copy deletion, file enumeration, and rapid file modification?
- Is the agent running on every endpoint, including unmanaged devices, legacy systems, and newly provisioned machines?
- Are there exclusions that were added for operational convenience and never removed?
2. Testing Your SIEM
A SIEM that is not tuned to the current threat landscape generates two categories of failure: false positives that exhaust analyst attention, and false negatives where real attack techniques generate no alert at all.
SIEM validation tests whether log sources feeding the platform are complete, whether detection rules cover the techniques being simulated, and whether alerts are actionable with sufficient context and correct severity scoring.
Validation questions for SIEM:
- Are all critical log sources feeding data into the SIEM, including cloud platforms, SaaS applications, and remote endpoints?
- When a BAS simulation generates a known malicious behaviour, does the SIEM produce an alert, or is the event logged without triggering any rule?
- Are detection rules mapped to MITRE ATT&CK techniques, so coverage gaps can be identified systematically?
- How much latency exists between a simulated technique and the resulting alert? In environments where attacker breakout times are measured in minutes, latency matters.
3. Testing Your Firewall and Network Controls
Barracuda’s 2025 analysis found that 90% of ransomware incidents exploited firewalls as an entry or persistence vector. Firewalls are among the most mature security controls in enterprise environments, which makes them easy to underestimate as a validation priority.
In practice, firewall configurations accumulate technical debt over years of operational changes. Rules added for temporary access are never removed. Legacy rules from decommissioned systems stay active. Filtering policies that were correct when written may not reflect current application architectures.
Validation questions for firewall controls:
- Does the firewall block known command-and-control callback protocols when simulated by a BAS platform?
- Are outbound connections to malicious infrastructure blocked, or does the rule base only address inbound threats?
- Do lateral movement techniques, such as connections between internal segments that should not communicate, trigger alerts in network monitoring?
- When was the firewall rule base last audited against the current application and network architecture?
4. Testing Your Web Application Firewall (WAF)
For organisations running customer-facing applications, the WAF sits between the public internet and application logic. WAF bypass is a well-practised attacker technique, and WAF effectiveness varies significantly by configuration quality.
Validation questions for WAF controls:
- Does the WAF detect and block SQL injection and cross-site scripting attempts used in BAS simulations?
- Are OWASP Top 10 techniques covered in the current rule set, and when were rules last updated against current exploitation variants?
- Does the WAF correctly handle evasion techniques such as encoding variations and payload fragmentation?
- If the WAF is bypassed, is there a secondary control at the application or infrastructure layer that would detect the intrusion?
5. Testing Your Cloud Security Controls
Cloud environments introduce configuration complexity that creates exposure not present in on-premises environments: misconfigurations that are operationally valid but create significant security risk.
Cloud control validation tests whether cloud-native security services, IAM policies, storage permissions, and network segmentation controls behave as intended against adversary techniques specific to cloud platforms.
Validation questions for cloud controls:
- Do IAM policies correctly restrict privilege escalation paths that a compromised cloud identity could use to gain broader access?
- Are cloud storage assets configured with public access blocked, and is that configuration monitored for drift?
- Does cloud workload protection detect anomalous API calls consistent with reconnaissance or data exfiltration?
- If an attacker compromises a cloud-hosted workload, can they reach adjacent environments, or is segmentation enforced and validated?
A Practical Scenario: “Our EDR Blocks Ransomware.” Prove It.
This plays out in security reviews regularly. A CISO states, with genuine confidence, that their EDR provides ransomware protection. The vendor confirmed it. The policy is configured. The agent is deployed.
Here is what validating that claim actually requires.
Step 1: Define the specific technique. Ransomware is not a single technique. It is a chain: initial access, privilege escalation, lateral movement, persistence, pre-encryption preparation, and file encryption. The EDR’s ability to “block ransomware” depends entirely on which technique in that chain it is configured to intercept.
Step 2: Simulate the technique safely. A BAS platform executes a safe simulation of pre-encryption preparation: the tool attempts to delete volume shadow copies using vssadmin, a technique used in virtually every observed ransomware campaign, including LockBit, ALPHV/BlackCat, and Conti variants. No actual files are encrypted. No actual shadow copies are deleted. The simulation generates the system calls and process behaviours the EDR should detect.
Step 3: Observe the control outcome. Did the EDR alert? Did it block? Did the alert fire within seconds, or was there a multi-minute delay that in a real attack would mean encryption has already begun? Did the SIEM receive the event and correlate it with other indicators?
Step 4: Record and act on the result. If the EDR detected and blocked: validation passed for this technique in this configuration. Retest after the next EDR update or policy change.
If the EDR did not detect or block: the gap is documented, a remediation action is assigned, and the technique is retested after the fix is applied.
The organisation now knows the gap exists and can manage it. The alternative is discovering it during an actual ransomware event.
This loop, run continuously across the full MITRE ATT&CK framework, is the operating model of a mature security control validation programme.
Purple Teaming: When Validation Becomes Collaborative
Security control validation reveals gaps. Purple teaming closes them, and keeps them closed.
Purple teaming is the structured collaboration between offensive simulation (red team) and defensive detection and response (blue team), with the explicit goal of improving detection coverage in real time, rather than the traditional model where red teams hand findings to blue teams in a report weeks later.
In a purple team engagement, simulated attacks run while defenders observe. When a technique evades detection, both teams work together immediately to understand why, tune the detection rule or control configuration, and retest. The cycle continues until coverage improves measurably.
Mapped against MITRE ATT&CK, purple teaming gives organisations a structured view of which adversary techniques their controls reliably detect, which require tuning, and which are current blind spots. That view can be presented to security leadership and boards as evidence of programme effectiveness, not just a list of tools purchased.
This shift, from annual penetration testing to continuous validation via BAS combined with periodic purple team cycles, is what Gartner formalised in its Continuous Threat Exposure Management (CTEM) framework. By 2026, CTEM has moved from an analyst concept to an operational priority for security teams that want to get ahead of the question: how do we know our controls work?
How FourCore ATTACK and PurpleSynapz Enable Continuous Validation
For organisations across APAC and MEA looking to operationalise security control validation without building an in-house red team from scratch, FourCore ATTACK and PurpleSynapz represent a directly deployable path to continuous, evidence-based security validation.
FourCore ATTACK is an adversarial exposure validation platform that safely emulates adversary techniques against live security controls across endpoint, network, cloud, and application layers. Every simulation maps to the MITRE ATT&CK framework, so results are presented as control coverage across tactics and techniques rather than a raw pass/fail list.
Key capabilities:
- Automated, continuous BAS across EDR, SIEM, firewall, WAF, DLP, email security, and cloud controls, with safe execution in production environments
- MITRE ATT&CK-aligned reporting that translates technical outcomes into coverage maps usable by detection engineers, SOC analysts, and security leadership
- Retest capability after any control change, policy update, or environment modification, reducing configuration drift by continuously revalidating control effectiveness
- Threat-informed prioritisation using current threat intelligence to focus validation on techniques most relevant to the organisation’s industry and region
PurpleSynapz extends this into the collaborative purple team model. Where FourCore ATTACK automates the continuous validation baseline, PurpleSynapz supports the human-in-the-loop exercises where security teams tune detections, build new use cases, and work together to close the coverage gaps that automated simulation surfaces.
Together, these platforms address the full validation lifecycle: automated continuous testing, collaborative detection tuning, and evidence-based security posture reporting that answers the question every CISO needs to answer to their board: how do we know our controls work?
For organisations in India, GCC, and across APAC and MEA, FourCore and PurpleSynapz are available through EGUARDIAN with regional implementation support and security control assessment engagements designed to map control effectiveness against the specific threat actors most active in each market.
Start With a Security Control Validation Assessment
If your organisation cannot currently answer the question that opened this article, a structured security control validation assessment is the right starting point.
The assessment, delivered by EGUARDIAN in partnership with FourCore, evaluates your current security control stack against a defined set of adversary techniques drawn from MITRE ATT&CK. It produces a prioritised view of where your controls are working, where they require tuning, and where there are current blind spots that represent active risk.
The assessment covers:
- EDR effectiveness against credential theft, lateral movement, and pre-ransomware preparation techniques
- SIEM detection coverage and alert quality across the MITRE ATT&CK tactics most relevant to your environment
- Firewall and network control testing against command-and-control callbacks and lateral movement protocols
- Cloud control validation for IAM, storage, and workload protection configurations
- A MITRE ATT&CK coverage map showing current detection rate across the tactics and techniques tested
The outcome is not a vendor recommendation. It is an evidence-based view of your security posture: what is working, what is not, and what to fix first.
📧 hello@eguardian.com | 🌐 www.eguardian.com
Frequently Asked Questions About Security Control Validation and BAS
What is the difference between a penetration test and breach and attack simulation?
Penetration testing is a manual, point-in-time engagement where human testers attempt to exploit vulnerabilities in a defined scope, typically conducted annually or biannually. BAS is automated and continuous, running safely against production environments to validate control effectiveness against specific adversary techniques on a recurring basis.
The two are complementary. Penetration testing identifies exploitable vulnerabilities and attack paths. BAS validates whether detection and prevention controls respond correctly to known techniques. BAS runs between penetration test cycles and after any control or environment change.
What does “living off the land” mean and why does it challenge EDR?
“Living off the land” refers to attacker techniques that use built-in operating system tools, such as PowerShell, WMI, PsExec, and Windows Task Scheduler, rather than custom malware. Because these tools are legitimate and used routinely by IT administrators, many EDR configurations do not alert when they are used, even in sequences that clearly indicate malicious intent.
According to CrowdStrike’s 2026 Global Threat Report, 82% of detections involved malware-free techniques. BAS platforms simulate these techniques specifically to validate whether EDR is tuned to detect anomalous use of legitimate tools.
What is MITRE ATT&CK and why is it used in security validation?
MITRE ATT&CK is a publicly available knowledge base of adversary tactics, techniques, and procedures documented from real-world attack observations, maintained by the not-for-profit MITRE Corporation. Security control validation platforms use it to structure testing: rather than simulating random attacks, they test specific techniques mapped to the framework, enabling organisations to measure detection and prevention coverage across the full attack lifecycle and identify which tactics remain blind spots.
How is purple teaming different from red teaming?
Red teaming is an adversarial exercise where an offensive security team attempts to breach defences, typically without the blue team knowing the specific timing or scope. The goal is to reveal what a real attacker could achieve.
Purple teaming is collaborative. Offensive and defensive teams work together simultaneously: the red team executes techniques while the blue team monitors and responds in real time, immediately tuning detections when a technique evades alerting. Red teaming tests whether defences hold. Purple teaming builds and validates the defences themselves.
How often should security controls be validated?
Controls should be retested after any significant change: a new EDR policy deployed, a firewall rule modification, a cloud infrastructure migration, a new application added, or a new threat intelligence report identifying a technique now being used against organisations in your sector.
At minimum, comprehensive validation should occur quarterly. With BAS automation, the baseline can run continuously, with human review cycles structured around the findings.
What industries benefit most from security control validation?
Any organisation operating critical infrastructure, regulated data, or business-critical systems benefits from continuous security control validation. In the APAC and MEA context, the highest-priority sectors include financial services, healthcare, manufacturing, government-adjacent enterprises, and technology companies with significant customer data holdings.
For organisations in India operating under SEBI CSCRF, RBI guidelines, or the DPDPA, security control validation also provides the evidence base for demonstrating that technical safeguards are operational rather than just documented.
EGUARDIAN is a value-added distributor and technology enabler operating across APAC and MEA, representing leading cybersecurity vendors across India, GCC, Southeast Asia, and South Africa.
Enquiries: hello@eguardian.com | www.eguardian.com
