A ransomware group makes the news on a Tuesday. By Wednesday morning the question has reached your CISO from three directions: the board risk committee, the regulator’s relationship manager, and the group CEO who read the same article on a flight.
The question is simple. Are we protected against this?
The honest answer, in most organisations, is a list of purchases. We have modern endpoint protection deployed across nearly the whole estate. We have a SIEM with a managed detection service. We have email security, a web proxy, network segmentation, privileged access management, and a penetration test from four months ago with all high findings closed.
None of that answers the question. It describes what was bought, not what would happen. It is an inventory, not evidence.
Somebody assembles a slide anyway. It lists the controls that would theoretically stop each stage of the attack chain described in the news article. It is written from documentation and vendor datasheets, because nobody has actually run those techniques against the live environment and watched what the controls did.
The slide is accepted. Everyone moves on. And the gap between what the organisation believes about its defences and what its defences would actually do stays exactly where it was, unmeasured, for another quarter.
That gap is the subject of this post. It is not a tooling problem. It is a proof problem.
The gap between the security stack and the security outcome
Security budgets across South Asia, Singapore and the Gulf have grown steadily for a decade, and the growth has been easy to justify. A control maps to a requirement. The requirement comes from a regulator, an auditor, a cyber insurer or an incident at a peer institution. Buy the control, produce the invoice, close the finding.
What almost never gets built into that cycle is the step after deployment: demonstrating that the control does the thing it was bought to do, in your environment, with your configuration, against the techniques an actual adversary would use.
The assumption underneath is that a control works because it is licensed and installed. In practice a control’s effectiveness is a function of how it was configured, what exclusions were added under pressure, which policies were left in audit mode, whether its telemetry reaches the SIEM in a parseable form, whether a detection exists for the behaviour it emits, and whether an analyst on a night shift recognises that detection for what it is.
Every one of those variables drifts. Not dramatically, and never in a way that generates an alert. An exclusion is added during a go-live weekend. A policy stays in monitor-only after a printing application broke. A log source is migrated and its schema changes. An engineer who wrote thirty detections leaves, and nobody inherits them.
The controls remain deployed. The dashboards remain green. Effectiveness quietly declines, and there is no instrument in the environment measuring it.
Compliance frameworks have started asking about this directly. RBI’s cyber security expectations for banks and NBFCs, SEBI’s cyber security and cyber resilience framework, SAMA’s cyber security framework in Saudi Arabia, the NCA essential controls, central bank guidance in Sri Lanka and Bangladesh, and MAS technology risk management expectations in Singapore all move in the same direction. They talk about testing, effectiveness, resilience and assurance, not just presence.
An auditor who asks “do you have endpoint detection and response” is easy to satisfy. An auditor who asks “show me evidence that your endpoint detection and response actually detects credential dumping in your production environment, and show me the retest after you fixed it” is a different conversation entirely. Most security teams cannot have that second conversation without weeks of manual work.
Where the evidence actually breaks down
The gap is not one large hole. It is a set of small, specific, entirely reasonable operational decisions that each made sense at the time and were never revisited.
- The endpoint agent that is half in monitor-only
An EDR rollout hits resistance in week three. A line-of-business application, usually something old and load-bearing, breaks when a behavioural policy blocks its script activity. The application owner escalates. The security team, under pressure to complete the rollout, moves that policy group to monitor-only and adds a directory exclusion.
The rollout completes. The project closes. The exception was meant to be temporary, and nobody owns temporary.
Two years later a meaningful share of prevention policies are still in detect-only mode, and there are exclusions on paths that an attacker can write to. The console reports full coverage, because coverage means agents installed. Nobody has ever executed a credential access technique against a machine in that policy group to see whether it would be stopped, or merely noted.
- The SIEM ingesting forty sources and alerting on six
Log ingestion is measurable, so it becomes the metric. Sources onboarded, events per second, retention days. It is the number that goes to the steering committee.
Detection coverage is harder to measure, so it does not become a metric. Of forty ingested sources, a handful carry rules that fire on real adversary behaviour. The rest are there for forensics and for the auditor’s checklist.
The practical result is a SOC paying for a very large amount of storage and monitoring a very small amount of behaviour. Ask which ATT&CK techniques your SIEM would actually alert on, with evidence rather than a spreadsheet built from rule names, and the room goes quiet.
The same is true of the managed service sitting on top of it. The contract describes monitoring hours and response times. It rarely describes which adversary behaviours the service can see, and neither party has run a test that would establish it.
- Email security tuned until it stops complaining
Email gateways are tuned in one direction. Every false positive is a business complaint with a name attached. Every false negative is invisible until it is an incident.
So the macro policy gets relaxed for the finance team who exchange spreadsheets with vendors. Archive inspection depth gets reduced because a large partner sends nested archives. A sender domain gets allow-listed during an urgent deal, and stays listed.
Each change is defensible. Cumulatively, the gateway that was bought to stop weaponised attachments now has a documented path for one to arrive. The only reliable way to know is to send controlled, benign test payloads through the live mail flow and observe what lands where.
- The firewall rule base nobody has audited
Rule bases accumulate. A rule added for a migration in 2021 outlives the migration. A permissive any-any rule created for a proof of concept sits below a hundred more specific rules and never gets reviewed.
Segmentation is where this hurts most. The network diagram shows a card data environment, an OT zone or a core banking segment isolated from the user estate. Whether that isolation actually holds against lateral movement techniques is a question the diagram cannot answer. Only traffic can.
Most organisations have never tested segmentation as an adversary would, by attempting real lateral movement paths from a user subnet and recording which ones complete.
- Detections that stopped firing after a schema change
This is the failure mode that unsettles experienced SOC managers most, because it is silent by design.
A detection rule references a field name. The log source is upgraded, or moved to a new collector, or the vendor changes an event schema. The field is now named something else, or nested one level deeper. The rule does not error. It simply never matches again.
There is no alert for “this rule has stopped producing results”, because a quiet rule looks identical to a healthy environment. A detection written a year ago, tested once at authoring time, can be dead for eight months while appearing in every coverage report as active.
- The annual penetration test as a sampling exercise
Penetration testing is valuable and should continue. It is also structurally unable to answer the control effectiveness question.
A test runs for two weeks on a fixed date against an agreed scope, often with the SOC informed and sometimes with the testers allow-listed so the engagement can proceed. It produces findings against a slice of the estate at a moment in time. The report is issued, high findings are remediated, and the retest, if it happens at all, covers only the findings themselves.
Nothing in that cycle tells you whether your controls detected the tester, how quickly, or which stages passed unnoticed. Nothing tells you what changed in the eleven months between engagements.
- The board question nobody can answer with evidence
All of the above converges on the Wednesday morning scenario. The board asks about a named threat group or a named ransomware family, and the security team has no instrument that converts that question into a measured answer.
What exists is inference. The group is known to use a particular credential access technique, and we have an EDR that claims to cover that technique, therefore we are probably covered. That reasoning would not survive scrutiny in any other risk discipline. A treasury function does not tell its board that hedges are probably in place.
The cost of not having an answer is not only reputational. It shapes decisions. Without measured coverage, budget goes to whichever risk was most recently in the news rather than to the gap that is actually open, and the same technique stays unmonitored through three consecutive planning cycles.
- Lean teams and high turnover
Across the region, SOC teams run smaller than the tooling they operate assumes, and analyst attrition is high. Knowledge about why a particular exclusion exists lives in individuals rather than documentation. When they leave, the exceptions stay and the reasoning does not. Validation becomes the only mechanism that can reconstruct ground truth, because it asks the environment rather than the staff.
Why buying more tools makes this worse
The instinctive response to uncertainty about coverage is to add coverage. A new product, a new module, a new managed service layered over the existing ones.
Every addition widens the surface that has never been validated. A new control arrives with its own configuration decisions, its own exceptions, its own telemetry format and its own assumptions about what the neighbouring controls handle. It is deployed to a deadline, tuned to reduce noise, and added to the inventory.
It also creates overlap that nobody owns. Three products can each partially address a technique. Each team assumes one of the other two is authoritative. In an actual incident, all three produce partial signal and none produces a decisive block, because each was tuned on the assumption that it was the second line rather than the first.
More consultants do not fix this either. An assessment produces a maturity score and a roadmap. Both are opinions about design, delivered on a date. Neither is a measurement of what the running environment does under attack.
More headcount runs into the regional labour market. Hiring three analysts to manually test controls is expensive, slow, dependent on individual skill, and reversible the moment one of them resigns.
The common flaw is that all of these responses add capability without adding proof. The organisation ends up with more security and less certainty about it. What is missing is not another control. It is an instrument that continuously measures the controls already in place.
How FourCore approaches this differently
FourCore builds FourCore ATTACK, a platform the company describes as adversarial exposure validation, covering breach and attack simulation and continuous automated red teaming. Its purpose is narrow and useful: to establish, by running real adversary techniques against live defences, what is blocked, what is detected, what is only logged and what passes unnoticed.
The important word is emulation. FourCore states that its simulations are safe and non-destructive, emulating adversary techniques and behaviours without deploying real malware or disrupting target systems. That is what makes the exercise repeatable in production rather than confined to a lab.
1. Validation built as a loop, not a report
The platform is organised around three stages: assess, validate and improve. That structure matters more than any single feature, because it is what turns testing into a routine.
Assess is threat-informed rather than generic. FourCore maps relevant threats by industry, region and threat actor, turning intelligence into testable questions instead of a static inventory. For a bank in Colombo, Dhaka or Riyadh the question is not whether every technique in the framework is covered, but whether the kill chains used against financial institutions in that region complete or fail against the controls in place.
Validate executes those behaviours against live defences and correlates outcomes in real time. FourCore describes campaigns replicating adversary tactics, techniques, procedures and indicators across endpoint, email, web application firewall and segmentation, rather than testing products in isolation. An attack does not respect your product boundaries, so validation should not either.
Improve is where output becomes work rather than a document. FourCore delivers detection logic and mitigation guidance, feeds evidence into detection engineering including Sigma, YARA and Snort refinement, integrates remediation tracking with systems such as Jira and ServiceNow, and supports scheduled regression testing after vendor or configuration changes.
2. Outcomes with evidence, not pass and fail
A result in FourCore ATTACK is not a binary. It reports the technique attempted, whether the behaviour was blocked, detected, partially detected or missed, the supporting telemetry, a next action with an owner, and retest status once remediation is done.
That format changes conversations. “Our endpoint tooling covers credential access” becomes “this procedure ran on this host group, the agent produced telemetry, the SIEM received it, no rule matched, here is the detection logic that closes it, and here is the retest confirming it fires.”
Coverage is expressed against MITRE ATT&CK as an empirical view built from actual simulations rather than self-assessment, and exported for detection engineering, leadership reporting and governance.
3. Correlating what the whole stack did
FourCore maps each simulation step to the responses of your security tools, integrating with widely deployed endpoint, XDR and SIEM platforms to show which controls activated and where the evidence gaps between them sit. That resolves the overlap problem: when the endpoint agent produced telemetry, the network control saw nothing and the SIEM raised no alert, the ambiguity about who owns that technique disappears.
4. Continuous rather than annual
FourCore positions this as repeatable validation between periodic engagements and after changes to the environment, so teams measure control effectiveness instead of assuming it. Run the loop again after a fix, and measure whether the outcome improved.
This is what catches silent failures. A detection that stopped firing after a schema change is invisible to every dashboard, but immediately visible to a scheduled campaign that used to detect it and now does not.
Delivery is SaaS, with on-premises deployment available on request, which matters for government SOCs and regulated institutions under data residency constraints. FourCore also supports safe ransomware simulation on endpoints, emulating ransomware behaviour without destruction. That is usually the first thing a board asks to see tested, and the last thing anyone wants to test for real.
- 5. Evidence a regulator will accept
Because every result carries the technique, the outcome, the telemetry and the retest, audit-ready evidence becomes a by-product of normal operation rather than a project. FourCore references support for demonstrating control effectiveness under frameworks including SEBI’s cyber security and cyber resilience framework, and the same artefacts answer the RBI, SAMA, NCA and central bank style question: not what did you buy, but what did you prove.
The half of the gap that technology cannot close
A validated control still fails if the person watching it has never seen the scenario before. A detection fires correctly, lands in a queue, and is closed as benign by an analyst who has read about the technique but never worked an incident containing it. The control worked. The outcome was still a miss.
PurpleSynapz addresses this side of the problem. The company delivers hands-on cyber security training built on a cyber range, Purple Range, where practitioners are put through live-fire simulations rather than lectures, and where capability is demonstrated by what someone does in the exercise rather than by what they can recall.
A range works because it removes the two things that make production a poor classroom: consequence and rarity. An analyst can work a full intrusion chain, make wrong calls and see what a wrong call costs, without anything real breaking. Scenarios that occur once every few years can be run deliberately, by everyone who would be on shift. For teams with high turnover that also changes onboarding economics.
The two halves reinforce each other. Validation tells you which techniques your controls miss. Those same techniques are what your analysts should be practising.
What this looks like in practice
A regional bank with a nine-person SOC, an endpoint platform, a SIEM and an outsourced night shift moves from assumption to evidence.
- Scope a campaign around ransomware operators known to target financial services in the region, rather than testing the whole framework at once.
- Run the baseline safely against a representative host group across endpoint, email and segmentation, following the full kill chain.
- Read the correlated results: three techniques blocked, four detected, two logged with no alert, two unnoticed.
- Trace root cause. The unnoticed techniques come from a host group still in monitor-only from an old exception, and a detection that stopped matching after a schema change.
- Remediate with named owners, using detection logic from the platform and tracking it in the existing ticketing system.
- Retest, and watch outcomes move from missed to blocked and detected with evidence attached.
- Turn the techniques that were logged but never escalated into range scenarios, and schedule the campaign to recur.
Six weeks on, the board question has an answer with dates, outcomes and retests attached.
Where validation closes each gap
| Operational gap | How continuous validation addresses it |
|---|---|
| Prevention policies left in monitor-only after an exception | Techniques run against live policy groups expose detect-only behaviour as a measured outcome, not an assumption |
| Log sources ingested but never alerted on | Simulation steps correlated against SIEM and endpoint responses show which sources produce detection and which produce only storage |
| Email and web controls relaxed by accumulated tuning | Safe payload delivery across email and web vectors shows what reaches the mailbox under current configuration |
| Segmentation assumed from the network diagram | Attack path and lateral movement emulation tests whether isolation holds in traffic, not in documentation |
| Detections silently broken by a platform change | Scheduled re-runs surface a technique that used to be detected and no longer is |
| Analysts who have never handled the scenario | Range-based training on the exact techniques validation showed were missed |
Who this matters most to
Banks, insurers and capital market institutions under RBI, SEBI, SAMA, NCA, MAS and central bank supervision, asked to evidence control effectiveness rather than control presence.
Government and national SOCs in South Asia and the Gulf, operating under residency constraints and accountable for sector readiness.
MSSPs and managed detection providers who must show clients, objectively and repeatedly, that the service detects what the contract says it detects.
Enterprises with lean SOC teams and high turnover, where knowledge about control configuration keeps walking out of the door.
Validation is a routine, not an event
Security assurance is still treated as something that happens on a date: an audit, an annual test, a certification cycle. Everything between those dates is assumption. Control effectiveness does not work that way. It changes with every exception, every upgrade, every schema change, every resignation.
The organisations that get this right treat validation as a routine rather than a project, in the same category as backup restoration testing or disaster recovery drills. Something that runs on a schedule, produces evidence, creates work and closes with a retest. Once the routine exists, the Wednesday morning question stops being uncomfortable, because the answer is already written down.
EGUARDIAN distributes FourCore and PurpleSynapz across South Asia, Singapore and the Gulf, and works with channel partners to size validation programmes to the team that has to run them.
Talk to our experts at EGUARDIAN. If you are carrying a security stack you cannot yet prove works, let us look at your controls, your regulatory obligations and what an evidence-based validation routine would look like for your organisation. Reach out to us at hello@eguardian.com.
