Whitepaper 01 · Enterprise Security
Why organisations with twenty security tools still don't know where their real risk lies.
This paper is deliberately vendor-neutral until its final section. The model it describes — Enterprise Security Correlation — can be implemented with a data warehouse, a graph database and a determined team. We think it should be implemented; whether you buy it or build it is a separate decision, and one you are better placed to make than we are.
Security budgets are rising. Tool counts are rising. Breach counts are not falling. The industry usually explains this gap by arguing that attackers are improving faster than defenders. There is a simpler and more uncomfortable explanation: most enterprises cannot answer basic questions about their own risk, and no additional tool will change that, because the problem is not detection.
A large enterprise today runs somewhere between fifteen and forty security products. Each is competent. A SAST tool finds injection flaws in source code. A cloud posture tool finds a public storage bucket. An EDR agent finds a suspicious process. Each produces findings, and each finding is true.
None of them can tell you which finding matters most, because none of them knows what your business does. A tool that scans code does not know that this repository is the payment authorisation service, that it processes cardholder data, that it is internet-facing through a gateway with no rate limiting, that the team who owns it has two open engineering vacancies, and that the compensating control everyone assumes exists was disabled during an incident four months ago and never re-enabled.
That knowledge exists in the enterprise. It is simply distributed across eight systems that have never been introduced to each other.
The central claim of this paper. Enterprise security has a correlation problem, not a detection problem. The findings you need have already been found. What is missing is the connective tissue that turns a finding into a decision: which asset, which business service, which owner, which control, which exposure, which consequence.
| If you are | Start at | Because |
|---|---|---|
| A CISO preparing a board narrative | Sections 1, 3, 6 | The cost argument and the maturity model are what translate into budget |
| A security architect | Sections 5, 6, 7 | The correlation chain and the worked example are the design content |
| A vulnerability management lead | Sections 4, 7, 8 | Prioritisation mechanics and what to change first |
| Evaluating platforms | Section 6, then 9 | Use the maturity tests as evaluation criteria — on any vendor, including us |
Consider a composite enterprise. It is not a real customer, but every element below is drawn from real estates: a financial services organisation, roughly 4,000 employees, 180 applications, two cloud providers, one data centre it is still trying to exit.
| Tool | What it genuinely knows | What it cannot know |
|---|---|---|
| Coverity | This function concatenates untrusted input into a query | Whether that function is reachable from the internet |
| Black Duck | This service depends on a library with a known CVE | Whether the vulnerable code path is ever called |
| Rapid7 | This host exposes an unpatched service on port 443 | Which business service that host supports |
| Wiz | This storage bucket is public and holds 40GB | Whether the 40GB is marketing assets or cardholder data |
| Azure Defender | This subscription has 14 misconfigurations | Which application owner is accountable for them |
| AWS Security Hub | This role has wildcard permissions | Whether an internet-facing workload assumes that role |
| CrowdStrike | This endpoint ran an unusual PowerShell command | Whether that endpoint is a developer laptop or a jump host into production |
| Splunk | These 4,000 events correlate into one suspicious sequence | Whether the affected asset had an open critical finding last week |
| Jira / ServiceNow | This ticket has been open for 94 days | Whether closing it reduces risk more than the ticket next to it |
Every entry in the middle column is real intelligence. Every entry in the right column is the reason the middle column cannot be acted on with confidence. The right column is not a criticism of these products; it is a description of their scope. A code scanner that claimed to know your business criticality would be lying.
The shape of the problem
Twenty sources of truth is another way of saying no source of truth. The failure is not at the top of this diagram. It is at the bottom.
A useful test of any security programme is whether it can answer four questions without a project. Not without effort — without a project, meaning without assembling a working group, exporting spreadsheets and reconciling them by hand over two weeks.
In our experience the honest answer for most enterprises is: question one takes a fortnight, question two produces disagreement, question three has a 30–60% miss rate, and question four cannot be answered at all because no comparable measurement exists from the previous quarter.
Fragmentation is usually discussed as an inconvenience. It is more accurate to treat it as an expense with five line items, four of which you can measure this month.
The same weakness is reported by multiple tools. A vulnerable library appears in the SCA tool, the container scanner, the cloud workload scanner, and — if the service is internet-facing — the DAST tool. Four findings, one fix.
Duplication does more than inflate counts. It distorts every metric derived from those counts: severity distribution, mean time to remediate, and team-level scorecards. A team that owns a widely-used shared library will look systematically worse than a team that owns a bespoke service with the same underlying risk.
Measure it
Take last quarter's findings. Group by (CVE or rule identifier, asset). Count groups with more than one member. Duplication rates between 25% and 60% are normal. Anything above 40% means your remediation metrics are not measuring remediation.
Each console requires a login, a mental model, a query language and someone who remembers its quirks. The cost is not the licence. It is that no individual holds the whole picture, so every cross-cutting question becomes a meeting.
Measure it
For your last three significant security questions — a board question, an auditor question, an incident question — record elapsed time from question to defensible answer, and the number of people involved. Multiply by loaded cost. Most organisations find the annual figure exceeds the licence cost of the tools being reconciled.
A finding with no owner is not a finding; it is a note. Ownership fails in three specific ways, and it is worth distinguishing them because they have different fixes:
Measure it
Sample fifty open findings at random. For each, can you name the individual who would do the work, in under sixty seconds, without asking anyone? The percentage where the answer is no is your ownership gap. Under 10% is good. Above 30% is common.
Evidence exists but is not addressable. Demonstrating a single control across PCI-DSS, ISO 27001, SOC 2 and an internal standard means four extractions from the same underlying facts, performed by hand, each formatted differently, each going stale the day after it is produced.
The compounding effect is subtler: because evidence collection is expensive, it happens annually. Because it happens annually, controls drift for eleven months unobserved, and the audit measures a state that was manufactured for the audit.
This is the expensive one, and the only one you cannot measure directly — you can only measure it after an incident, by asking whether the exploited weakness was already known. Industry data consistently puts that figure high; our own experience with post-incident reviews is that the finding was almost always present in some tool, usually ranked below dozens of items that mattered less.
The uncomfortable version: most organisations do not get breached through unknown vulnerabilities. They get breached through known vulnerabilities that were ranked 47th.
CVSS is a good standard being used for a purpose it explicitly disclaims. Its base score describes intrinsic, environment-independent characteristics of a vulnerability. The specification provides temporal and environmental metrics for exactly the adjustments discussed below — and almost nobody populates them, because doing so requires the correlated context this paper is about.
So the industry ships a base score into a work queue, and the queue inherits three defects.
A CVSS 9.8 in a library function your code never calls is not a 9.8 to you. A CVSS 6.5 in the authentication path of your internet-facing payment gateway may be the most urgent item you have. Base score is blind to both facts.
The same vulnerability on a developer's test container and on the host processing cardholder data scores identically. Every experienced practitioner knows this and compensates informally — which means prioritisation quality depends on who is holding the spreadsheet that week.
A WAF rule, a network segment, an authentication requirement, a feature flag that disables the affected path — each materially changes real risk and none changes the base score. Worse, these controls are usually recorded nowhere the vulnerability process can see, so the same argument is re-litigated at every triage meeting.
From score to risk
Each row is a join against a different system. That is precisely why this is a correlation problem: no scanner can perform these joins, because no scanner holds the other side of them.
| Finding | CVSS | Reachable | Internet-facing | KEV | Data | Correlated rank |
|---|---|---|---|---|---|---|
| Deserialisation flaw, batch worker | 9.8 | No | No | No | Internal | #31 |
| Auth bypass, payment gateway | 6.5 | Yes | Yes | Yes | Cardholder | #1 |
| XSS, internal admin tool | 7.4 | Yes | No | No | Internal | #18 |
| Public bucket, marketing assets | 7.5 | Yes | Yes | — | Public by design | #44 |
A CVSS-ordered queue works this list top to bottom in the order 9.8, 7.5, 7.4, 6.5 — and reaches the only item that can cost the company money fourth. Note also the fourth row: a genuine 7.5 that deserves to be near the bottom, because the bucket is public deliberately. Correlation removes noise as well as promoting signal, and the noise removal is what earns you credibility with engineering.
If the previous section is accepted, the requirement follows: an explicit, maintained model that connects a finding to everything needed to judge it. Not a report. A model, queryable, updated continuously, owned by someone.
The correlation chain
Two properties of this chain matter more than its shape.
It must be traversable in both directions. Downward, so an executive number can be decomposed into the findings that produced it — a number nobody can drill into is a number nobody believes twice. Upward, so an engineer looking at a ticket can see why it outranks the ticket beside it.
The joins must be maintained, not derived on demand. Asset to service, service to owner, owner to authority: these are slow-moving facts that rot silently. An organisation that reconstructs them at audit time is measuring its reconstruction ability, not its risk.
| Category | What it does well | Why it is not correlation |
|---|---|---|
| SIEM | Correlates events in time | Models activity, not the estate; a SIEM rarely knows which assets exist but are silent |
| Vulnerability management | Aggregates findings, deduplicates within its own scope | Inherits its own scanner's view of assets; usually no service or ownership model |
| CMDB | Holds assets and relationships | Has no concept of findings, exploitability or exposure; often accurate for servers, blind to cloud and code |
| CSPM / CNAPP | Deep correlation within cloud | Stops at the cloud boundary — your on-premise estate, source code and endpoints are outside it |
| GRC | Maps controls to frameworks | Evidence is entered, not derived, so it describes intention rather than state |
| BI on a warehouse | Any query you can write | No semantics: nothing enforces that "critical" means the same thing across two source systems |
Each of these is a legitimate component of the answer. None is the answer, and assembling them without an explicit model produces the twenty-dashboard estate described in section 2 — with an additional dashboard.
ESCM is a maturity model for one specific capability: the ability to turn security findings into decisions. It is not a product, a framework to be certified against, or a competitor to CTEM. CTEM describes a loop an organisation should run; ESCM describes the data foundation without which that loop runs on guesses.
Six levels. Each has a stated capability, a specific test, and the symptom that gives away an organisation which believes it is higher than it is.
Level 0
Findings live in the tool that produced them.
You can answer: what did this scanner find?
You cannot answer: anything spanning two tools.
Test: ask for a total count of open critical findings across the estate. If the answer requires opening more than one console, you are at level 0.
Level 1
Findings are collected into one place, unchanged.
You can answer: how many findings do we have, in total.
You cannot answer: how many distinct problems we have.
Test: count findings for one widely-used vulnerable library. If the number is larger than the number of places you would fix it, duplication is still in your data.
Tell-tale: the finding count is quoted in thousands and nobody argues about it, because nobody believes it.
Level 2
One schema, one severity vocabulary, duplicates collapsed.
You can answer: what distinct problems exist, and where.
You cannot answer: which ones matter.
Test: take one finding and ask what business service it affects. If the answer comes from a person rather than the system, you are at level 2.
Tell-tale: this is where most organisations that describe themselves as mature actually sit. The dashboard is clean, the ranking is still CVSS.
Level 3
Findings are joined to assets, services, owners and controls.
You can answer: who owns this, and what does it support.
You cannot answer: what it would cost us if it were exploited.
Test: pick fifty findings at random. What percentage resolve to a named owner and a named service without human intervention? Below 90% and the correlation is decorative — teams will keep their own spreadsheets, which is the true measure of whether they trust it.
Level 4
Risk is computed from exploitability, exposure, criticality and controls.
You can answer: what to fix first, defensibly.
You cannot answer: whether the programme is improving.
Test: show the ranked queue to the engineer who owns items 1 and 8. Can they see why 1 outranks 8, and do they agree? Prioritisation that cannot survive that conversation does not survive contact with delivery pressure either.
Level 5
One model serves remediation, executive reporting and compliance evidence.
You can answer: all four questions from section 2, on demand, including direction of travel.
Test: the same underlying model produces the engineer's queue, the board's number and the auditor's evidence, and the three reconcile without manual adjustment. If the board pack is assembled separately, you are at level 4 with a reporting process attached.
Not as a scorecard. Its value is diagnostic: it tells you which capability to build next, and it prevents the most common expensive mistake, which is buying a level 4 capability while sitting at level 1. Risk scoring applied to duplicated, unowned findings produces confident nonsense, and confident nonsense is harder to recover from than an obvious gap — people act on it.
The levels are also strictly ordered. There is no path to defensible prioritisation that skips ownership, because "what to fix first" is meaningless without "who fixes it".
On naming. We are naming this model because the industry currently discusses the symptom (too many alerts) and the ritual (a CTEM loop) without naming the missing capability. Our claim to it is limited: use it, argue with it, publish a better version. It is a lens, not a licence.
Abstract models persuade nobody. Here is one finding, traced through the chain, in the composite enterprise from section 2.
One finding, fully correlated
pay-authz, 14 services depend on it| Join | Source system | Effect on the decision |
|---|---|---|
| Finding → repository | SAST | Establishes the technical fact |
| Repository → service | Service catalogue / deployment metadata | Turns a code defect into a business concern |
| Service → data classification | Data inventory | Moves this into regulated scope; changes the deadline |
| Service → exposure | Gateway config, cloud topology | Reachability: the single biggest multiplier |
| Service → control state | WAF configuration | Removes the mitigation everyone assumed |
| Repository → threat model | Threat modelling repository | Confirms this was a predicted attack path, not a surprise |
| Service → owner | Ownership registry | Makes the finding actionable at all |
The fifth row is the one worth dwelling on. The WAF rule existed. Everyone referred to it in triage. It had been switched to detection mode during a performance incident and never switched back. No scanner reports that, because no scanner is asked to compare an assumed control against its live configuration. Correlation surfaced it as a side effect of asking the question mechanically rather than socially.
In post-incident reviews, this pattern — a control that was believed to be active and was not — appears more often than a genuinely unknown vulnerability. It is a correlation failure, not a detection failure.
CVSS 8.1. Ranked eleventh in a queue of 340 open highs. Assigned to a team alias inherited from a 2023 reorganisation. Closed 71 days later as "cannot reproduce", because the engineer who picked it up tested the authenticated path.
None of this requires a platform to begin. Four steps, in this order, each valuable alone.
One query against last quarter's findings, grouped by rule and asset. The number is usually between 25% and 60%, and it immediately reframes every metric derived from finding counts. It also tends to end the argument about whether this work is necessary.
Asset → application → business unit → named individual. This is unglamorous data work and it is the load-bearing wall. Every capability above level 3 depends on it, and no scoring model compensates for its absence. Target 90% coverage; accept that the last 10% will expose organisational questions that are not yours to solve alone.
Reachability is the largest single multiplier on real risk and usually the cheapest context to obtain — gateway configuration, load balancer rules, cloud topology. Ranking by "internet-facing and reachable" alone beats CVSS ordering by a wide margin, before any model is built.
Which compensating controls exist, on what, in which mode, verified when. The payment API example turned on exactly this. If it lives only in the heads of the triage group, it will be wrong within a quarter.
Deliberately absent from this list: buying anything, and adding AI. Both can help later. Neither substitutes for the ownership join, and an AI layer over uncorrelated data produces fluent, confident, unfounded conclusions — which is worse than no layer at all.
Everything above stands without us. This section exists because we built a product around the model and it would be coy not to say so.
Klair Vu is an implementation of levels 1 through 5. Connectors ingest findings from scanners, cloud providers, identity systems and trackers; they are normalised into one schema and deduplicated by rule and asset. Each finding is joined to an application and a business unit, and unmapped findings are flagged rather than hidden — a mapping gap is a finding about your programme. Risk is computed from exploitability, exposure, criticality and control state, and the resulting rank is explainable down to the contributing factors. The same model serves the engineer's queue, the executive score and framework evidence, so the three cannot disagree.
AI-Interceptor extends the asset model to AI infrastructure — agents, models, gateways, vector stores — because that estate is currently growing faster than any inventory process and is largely invisible to the tools listed in section 2.
The same twenty tools, correlated
We would rather you used the maturity tests in section 6 on us than take this section on trust. The most useful question to ask any vendor, including this one: show me a finding, and walk up the chain to the owner and down from the board number to this finding. A platform that cannot do both directions is a dashboard.
Stop managing findings. Start managing risk.
Book a walkthrough and bring your hardest question — ideally one your current tooling answers badly.
Book a demo Other whitepapers