Measuring Security Coverage

The Challenge

We had a legacy page that mapped the detection rules we offered against the MITRE ATT&CK framework. It was an interesting way to demonstrate the breadth of our detection capabilities, but there was very little a customer could actually learn or do from the experience.

In many ways, it was a marketing page that had become a product feature. The data wasn't personalised to the customer's environment, it didn't reflect their own security posture, and it gave them no meaningful next step.

The opportunity was to take the foundation that already existed and ask a much more useful question:

What if this could help customers understand their own security coverage and decide what to do next?

That shifted the focus from displaying MITRE coverage to making it personal, contextual and actionable.

Understanding the Problem

Cybersecurity teams are constantly trying to answer a deceptively simple question: are we protected against the ways attackers might target us?

MITRE ATT&CK provides a common framework for describing how real-world attackers operate. Rather than focusing on individual tools or products, it breaks an attack into recognised tactics and techniques, creating a shared language security teams can use to understand attacker behaviour.

Read more about MITRE →

Detection rules are one of the ways security products look for evidence of those behaviours. A rule might identify a particular technique being used and alert an analyst so they can investigate.

Mapping detection rules to MITRE therefore sounds useful: it can show which attack techniques a security product is capable of detecting.

But capability isn't the same as coverage.

A customer might technically have a detection available, but is it enabled in their environment? Do they have the right data sources connected for it to work? Are they vulnerable to the technique in the first place? Is it associated with threats that are relevant to their organisation? And if they discover a gap, what should they do about it?

Those were the questions the legacy experience couldn't answer.

Looking beyond detection rules

The project originated within a small detection rules team, with an initial goal of making the existing MITRE dashboard more relevant to the detections available within a customer's environment.

Rather than treating detection rules as the boundary of the problem, I used object modelling to understand the wider system. I mapped the objects and relationships within MITRE ATT&CK against the objects already available across our platform, looking for where existing security data could create a richer picture of coverage.

This gave us a way to solve the immediate problem while designing towards a broader security coverage experience.

Phase 1: Personalise detection coverage

The first release focused deliberately on the original need. Customers could see MITRE coverage based on the detections available in their own environment, filter the view using relevant context, and view or manage detection rules directly from the dashboard.

This turned the legacy experience from a generic representation of what we could detect into something that reflected the customer's actual detection coverage.

Designing for a broader security picture

The object model also exposed opportunities beyond detections. MITRE provided a common structure through which we could eventually connect other security objects, including vulnerabilities and CVEs, mitigations, and other capabilities available across the platform.

That created a longer-term direction where the experience could evolve with the capabilities a customer owned, bringing different signals together to help them understand their overall security posture.

Phase 1 has been released, while the broader model remains future-facing work. The additional connections identified through the original strategy are now being explored for further development.

My Role

As Principal Product Designer, I led the design strategy for evolving the MITRE experience from a detection-focused dashboard into a broader security coverage capability.

The initial brief came from the detection rules team, but I looked beyond that immediate scope to understand how MITRE connected to the wider platform. Using object modelling, I mapped relationships between MITRE and the security objects we already held, helping identify opportunities across detections, vulnerabilities, CVEs and mitigations.

I worked closely with Product, Engineering and security domain experts to translate that strategy into a phased experience. The first release remained deliberately focused on personalised detection coverage, while the broader model created a direction for how security coverage could evolve across the platform.

My role spanned both product strategy and detailed interaction design, connecting the immediate customer problem with a longer-term opportunity without allowing the size of that opportunity to overwhelm the first release.

Outcomes

The first phase successfully transformed the legacy MITRE view into a customer-specific experience. Instead of seeing a generic representation of available detections, customers could understand coverage within their own environment and move directly from identifying a gap to viewing or managing the relevant detection.

The work also created a broader product direction. Object modelling showed how MITRE could connect detections with vulnerabilities, CVEs, mitigations and other security data already available across the platform, creating a foundation for a more complete view of security coverage.

That broader vision was intentionally kept outside the initial release. The first phase shipped with a focused scope, while the additional opportunities remained documented for future development. Those concepts are now being revisited as the platform continues to explore expanding security coverage beyond detections.