Detection coverage: follow one attack path from event to response

Before adding another detection platform, choose one incident your security operations team must be able to handle and follow it through the current estate. Where does the first useful event appear? Which rule sees it? Who receives the alert, and what can that person do?

The answer may justify a purchase. It may also reveal an expired connector credential, an unsuitable rule or an overnight handover that nobody owns. Those problems require different investments. A coverage review is valuable when it distinguishes them.

Choose an attack path with a business consequence

Start with a service the organisation depends on, then describe an unwanted sequence affecting it. “A compromised administrator grants persistent access to the customer platform” is more useful than “improve identity coverage”. It tells the team what to look for and why a missed event matters.

MITRE ATT&CK’s Account Manipulation technique, T1098, describes changes to credentials and permissions that preserve or increase an adversary’s access. Its sub-techniques distinguish actions such as adding cloud credentials and adding cloud roles. Use that vocabulary to locate the relevant behaviours in your environment. A coloured ATT&CK cell is a statement about a mapping; it is not a demonstration that your organisation can detect every implementation of that behaviour.

Select a small set of paths that reflect the service’s actual identities, applications and administration routes. Include the route that avoids the most familiar endpoint sensor, such as an administrative change made through a cloud API. The review should expose dependence on particular signals, rather than reward a large collection of overlapping rules.

Find the first unproven step

For each path, work through four questions: can the activity be observed; does the required event arrive; does the detection logic produce a useful result; and can a responder investigate and act? Stop calling the whole path covered when one answer is unknown.

Consider a hypothetical customer platform whose SOC has a rule for unexpected privileged-role assignments. The rule remains enabled, but its identity event feed has stopped. The green rule status describes configuration, not a working detection. The immediate investment is restoration of the collection path and a way to notice future failure.

Even when events arrive, inspect their contents. An event without the target account, changed role or usable timestamp may be insufficient for the intended correlation. Confirm that the analyst can distinguish the identity making the change from the identity receiving the permission. Then follow a representative event through parsing, enrichment and the rule’s time window.

A quiet event source needs particular care. No events might mean no relevant activity, a filter that excludes the event or a failed collection path. Establish what a safe, expected event would look like and whether it can be generated in a controlled test. Silence alone cannot choose between those explanations.

Monitor the monitoring, within its actual scope

Microsoft Sentinel provides a concrete example of the distinction. Its connector-health documentation describes an ingestion-monitoring workbook and the SentinelHealth table. The table requires the health feature to be enabled and supports selected connectors, rather than every possible feed.

The same documentation says potentially transient errors are logged after they have persisted for more than 60 minutes, while errors considered definitely non-transient are logged immediately. That behaviour matters when deciding how quickly the team expects to learn about a blind spot. Check the connector and failure type before treating a health indicator as an immediate warning.

In the review, pair connector status with evidence about the event you need: last expected arrival, usable fields and elapsed time from source to investigation. A successful connection is helpful, but the decision depends on whether the required signal reaches the detector soon enough for the response being promised.

Test detection and the handover separately

Choose the exercise for the question you need answered. Penetration testing, red teaming and control validation provide different evidence; a successful test of one control does not establish how a complete attack path would be handled.

Agree controlled validation conditions with the service owner. Use a test tenant, account or approved simulation where appropriate, and define the expected event and action in advance. Replaying a known event can test parsing and logic; it does not establish that the live collection path will deliver that event. A live authorised action can exercise more of the chain, but may still cover only one variation.

After the alert appears, ask the receiving analyst to investigate it through the normal route. Can they retrieve the supporting activity, identify the responsible service owner and reach someone authorised to contain the problem? A detection that waits in an unmonitored queue has passed a rule test and failed the operational test.

Keep the findings separate:

• Signal absent or unusable: fix collection, permissions, parsing or retention before evaluating another detector.
• Signal present, logic unproven: develop or tune the analytic and validate representative variations.
• Alert useful, response unavailable: resolve staffing, access or authority before claiming an effective service.

Retest the repaired path and keep the evidence attached to the exact configuration and scenario. Report the paths demonstrated, the conditions tested and the gaps left open. That is more actionable than a percentage of the ATT&CK matrix with an undefined denominator.

Use the result to fund the missing capability. If the gap is sustained investigation and response capacity, it becomes a concrete requirement when evaluating an MDR service against your operating needs.