Attacker Friction Rating: A Better Question for Security Metrics
Your vulnerability backlog fell by 40% this quarter. Can an attacker still use a compromised employee account to reach your loan servicing system?
If the answer is yes, the backlog tells you work was completed. It doesn't tell you whether that route became harder.
CVSS communicates vulnerability severity, including adjustments for a particular environment. EPSS estimates the probability that a published CVE will be exploited in the wild in the next 30 days. SSVC supports contextual decisions about vulnerability response. Each contributes something useful to prioritization.
We also need evidence to answer another question: did our defensive investments make the routes to critical business outcomes harder to complete?
I'm proposing Attacker Friction Rating as a structured way to report those changes. This version is an experimental assessment method. Its value should come from the evidence behind each judgment. A numerical rating would need scoring anchors and calibration that this proposal does not yet have.
The reporting gap
Finding counts make patching activity easy to report. Other investments can be harder to explain through the same dashboard:
- Separating user networks from sensitive application tiers.
- Removing standing privilege and reusable credentials.
- Introducing phishing-resistant authentication.
- Detecting and interrupting an attack before it reaches its objective.
These changes may close findings, depending on what your program tracks. But the number closed doesn't describe their effect on an attack path. One change might eliminate a direct route to a critical system; hundreds of others might leave that route intact.
The useful question is what the attacker must now do differently, and how we know.
Define the scenario before assessing friction
AFR starts with a specific attacker objective and starting position. “Reach a server” is often too vague. “Use a compromised employee account to export loan records” gives the assessment a business consequence and a clear stopping condition.
For each scenario, record:
- Objective and target: the action that would constitute success and the business service affected.
- Starting access: for example, an external attacker with no account, a stolen employee session, or a compromised workload.
- Assumed capability: the tools, privileges, knowledge, and time available to the tester.
- Route: the actions and trust boundaries connecting that starting position to the objective.
- Test conditions: scope, date, exclusions, and any access granted to continue an exercise.
An external phishing attempt and an attacker who already controls an employee session are different starting positions. Keep them separate. Otherwise, a change in assumptions can look like an improvement in security.
AFR belongs alongside existing work in threat-informed defense. For example, MITRE's Center for Threat-Informed Defense offers Summiting the Pyramid to assess detection robustness. The contribution proposed here is a repeatable reporting format connecting path assessments to defensive investments.
Three questions to answer for each route
| Question | Evidence to collect | What does not establish improvement |
|---|---|---|
| What additional effort is required? | Observed extra actions, separate privilege acquisitions, preparation, and elapsed time under documented conditions | More network hops or more identities on a diagram |
| What can defenders prevent? | Tests showing a required action was denied, including checks of relevant exceptions and bypasses | A control appearing in an inventory |
| Can defenders interrupt the attempt in time? | Time to actionable alert, time to effective containment, and whether the objective was reached | A detection rule existing or an alert arriving after the objective |
These are separate observations, not independent quantities to add together. A credential control can both block an action and force a different approach. Record both effects, but don't award the same improvement multiple points in a total.
Detection can create friction when it forces evasion or enables intervention. An alert alone doesn't establish either result. If an attacker reaches the objective in twenty minutes and the first actionable alert arrives two hours later, faster detection may still be useful for investigation, but it hasn't demonstrated timely interruption.
Similarly, a longer route isn't necessarily harder. Several automated steps using the same privilege may require less effort than one independently enforced authorization boundary.
Report outcomes and evidence before numbers
For each test, use one outcome:
| Outcome | Meaning |
|---|---|
| Objective reached | The tested route succeeded under the stated conditions. Report any effort, prevention, or response observations alongside it. |
| Prevented | A control denied a required action, and the tested continuation or bypass attempts did not reach the objective. |
| Interrupted | Defender response stopped the attempt before the objective was reached. |
| Inconclusive | The test ended or encountered a limitation that prevents an outcome judgment. |
| Untested | No relevant execution test is available for the current conditions. |
These outcomes describe an exercise, not the probability that a real attacker will succeed. Record different results separately when repeated tests disagree.
Keep the evidence basis visible: tested, supported by configuration review, or hypothesized. Attach the test record or review, its date, and the assumptions it supports. Configuration review can support an expectation of prevention; it should not be reported as a successful prevention test.
This version deliberately leaves out a composite 0–100 score. Before introducing one, we would need explicit scoring anchors, evidence that analysts apply them consistently, and checks that weights don't reward the same control repeatedly. We'd also need to test whether the rating tracks observed attacker effort and defensive outcomes. A tidy number is not enough.
A worked example
The following is hypothetical. It illustrates how to report evidence; it is not a claim about results from a real environment.
The objective is to export records from a critical loan servicing application. In the baseline exercise, the tester obtains an employee password through phishing and an approved push prompt, accesses a file server, retrieves a reusable service credential, and uses its application permissions to export the records.
The quarter's changes introduce phishing-resistant MFA for remote access, restrict access between user and file tiers, rotate the exposed service credential, remove the stored copy, and restrict access to its replacement through workload identity and vault policies.
The report separates a repeat of the original route from exercises that begin with assumed access:
| Scenario | Illustrative result after the changes | What the result supports |
|---|---|---|
| Repeat the original external entry method | Prevented: the password and push-based method no longer completes remote authentication; tested fallback options do not restore access | This entry method was blocked under the test conditions |
| Start with a deliberately supplied employee session | Prevented: access from the user tier to the file server is denied | The tested internal transition was blocked; this exercise does not demonstrate an MFA bypass |
| Start with deliberately supplied access to the file server | Prevented: the former credential fails after rotation; the old stored copy is absent, and the tested identity cannot retrieve its replacement | The previously demonstrated credential route is unavailable under these conditions |
| Investigate a possible route through an application administrator's session | Untested | An alternative route remains an assessment priority |
Each result requires its own test record. For the credential change, the team must check how the application obtains its replacement credential and which identities can access it. Putting a secret in a vault alone does not answer those questions.
If detection fires during an exercise, report when it fired and what response followed. A prevention result does not establish that the SOC would have contained an otherwise successful attempt. Assess that separately if needed.
The defensible conclusion is narrower and more useful than “friction rose from 35 to 78”: the original route was prevented in the repeat test, two internal transitions were independently tested, and an alternative route remains untested.
Turn the assessment into a quarterly practice
Start with five to ten scenarios chosen for their business impact and plausible starting access. Keep a stable set for comparison, and add newly discovered routes as the environment changes. A small sample cannot establish that the entire environment became harder to attack.
Retest after relevant control changes. Preserve the prior conditions where possible; document changes in tooling, tester knowledge, time limits, and scope. When a route becomes unavailable, retain its history and investigate alternatives. Don't silently substitute a harder route and call the difference progress.
Report each scenario individually. Highlight the easiest known viable routes, critical objectives still reached in testing, and gaps in current evidence. Avoid an environment-wide average that lets strong results elsewhere hide one easy route to an important objective.
A leadership update for the hypothetical example could read:
The original route to loan-record export was blocked in this quarter's repeat exercise. Separate tests also denied the former file-server and service-credential transitions. These results support the value of the authentication, segmentation, and credential changes. A possible administrator-session route remains untested and is the next assessment priority.
That connects spending to observed behavior while preserving the unresolved question.
What would make AFR worth adopting?
The next step is to try the assessment with real teams. Have two analysts independently assess the same evidence, compare their conclusions, and investigate disagreements. Repeat exercises under documented conditions to see which judgments hold up.
Control changes, new routes, and incomplete visibility will keep moving the picture. A previous prevention result should be revisited when its assumptions change. No assessment should imply that an untested route is difficult or that an attacker will abandon a valuable target.
If you work in purple teaming, detection engineering, identity security, or security measurement, I'd welcome examples that challenge this approach: a route that became longer without becoming harder, a control that appeared effective until its exceptions were tested, or an alert that arrived too late to matter.
AFR should earn its usefulness by helping teams explain what changed, demonstrate the effect, and choose the next test. That's the evidence behind an answer to “are we harder to attack than last quarter?”