Document Version: 1.0.1
Status: Open Engineering Specification
Classification: Deterministic System Geometry & Capability Reduction Standard
Modern enterprise security architectures suffer from an overreliance on additive controls, continuous alert generation, and observational path validation such as Breach & Attack Simulation (BAS), Continuous Threat Exposure Management (CTEM), adversarial emulation, exposure validation, and attack path management platforms. While these diagnostic approaches can identify and validate path existence, they do not inherently reduce system conductivity.
This specification establishes Subtractive Security as a formal engineering discipline and defines the Path Erasure Rate (PER) as the quantitative, unweighted benchmark for attack surface elimination.
PER-1.0 provides the mathematical, topological, and operational requirements for measuring and executing the persistent, binary removal of capability edges from system execution graphs.
The purpose of PER-1.0 is to distinguish between:
- discovering attack paths,
- validating attack paths,
- prioritizing attack paths,
- monitoring attack paths,
and the higher-order engineering activity of:
structurally erasing attack paths so they cannot be traversed.
Under this specification, systems or programs that only perform discovery, scoring, emulation, alerting, exposure validation, path visualization, or prioritization operate within the observational layer. They may support PER measurement by helping define the path inventory, but they do not themselves constitute path erasure unless structural edge removal occurs.
An enterprise execution surface is modeled as a directed graph:
G = (V, E)
Where:
Vrepresents system nodes, including identities, hosts, microservices, container runtimes, API endpoints, SaaS applications, administrative planes, and other executable or addressable system elements.Erepresents execution capability edges, including network adjacencies, administrative privileges, credential access, token inheritance, exposed APIs, unparsed protocols, exposed binary interfaces, script execution capabilities, and other paths that permit system state transition.
An Attack Path P_i is defined as a contiguous ordered sequence of directed edges:
P_i = (e_1, e_2, ..., e_k), where each e_n is in E
allowing an unauthorized, undesired, or adversary-useful state transition from an ingress boundary v_in to a target asset v_target.
An attack path exists when system geometry permits a sequence of capabilities to compose into control, movement, privilege escalation, data access, system disruption, or other material impact.
Because complete enterprise graph enumeration is not mathematically provable in a dynamic environment, PER measurements SHALL be performed against a declared assessment scope.
A conforming implementation SHALL document:
- assessment boundaries,
- enumeration methodology,
- asset inclusion criteria,
- TTP coverage model,
- graph construction methodology,
- validation method,
- measurement period or engineering epoch,
- known exclusions or limitations.
Accordingly, P_total is defined as:
the set of structurally viable attack paths identified within the declared assessment scope, graph model, and enumeration methodology.
This requirement ensures reproducibility while preventing unverifiable claims of universal path completeness.
A PER score SHALL NOT be represented as an absolute measure of all possible enterprise risk unless the declared scope supports that claim. PER is a scoped engineering measurement of structural path erasure within a stated model.
PER measures erasure of non-essential, unauthorized, undesired, or adversary-useful paths within the declared scope. It does not require removal of business-required paths that must remain available for legitimate operation.
Let P_eligible be the subset of P_total consisting of identified paths that are eligible for structural elimination because they are unnecessary, unsafe, unauthorized, excessive, or not justified by explicit business or operational requirements.
P_eligible is a subset of P_total
Business-required paths that cannot be eliminated SHALL be documented as residual constrained paths. These paths MAY be subject to additional constraints, monitoring, compensating architecture, or exception debt accounting, but they SHALL NOT be counted as erased unless at least one necessary execution edge is structurally removed.
Unless otherwise stated, PER calculations in this specification use P_eligible as the denominator.
Let P_eligible be the set of structurally viable, non-essential, unauthorized, undesired, or adversary-useful attack paths identified within the declared assessment scope, graph model, and enumeration methodology.
Let P_erased be the subset of P_eligible where at least one necessary execution edge:
edge e is in P_i
has been structurally removed, rendering P_i non-executable without reliance on real-time detection, alert triage, analyst response, or post-execution containment.
PER = |P_erased| / |P_eligible|
Where:
- PER = 0.0: Pure Observational State. Eligible attack paths exist and rely entirely on reactive controls such as EDR, SIEM, CTEM alerts, BAS findings, or exposure validation outputs.
- PER = 1.0: Non-Conductive Boundary State. All identified eligible execution paths within the declared scope are structurally eliminated; system geometry prevents traversal deterministically.
A path is considered erased only when at least one necessary edge in the path has been removed or rendered non-traversable as an architectural condition.
For purposes of PER-1.0, an erased edge SHALL remain non-traversable as the default architectural state.
An erased edge MAY be reintroduced only through an authorized architectural, operational, exception, deployment, or configuration change.
An edge SHALL NOT qualify as erased if:
- it can be routinely re-enabled through normal runtime activity,
- it can be re-enabled by an adversary operating within the permitted security model,
- it depends on analyst review,
- it depends on alert triage,
- it depends on post-execution response,
- it depends solely on detection logic that does not prevent the prohibited state transition.
This requirement differentiates structural elimination from temporary operational mitigation.
For purposes of this specification, persistent means the edge remains non-traversable by default and cannot be restored by adversary action or normal runtime behavior. It may only be reintroduced through an authorized configuration, deployment, exception, or architectural change.
To represent complex execution graphs where ordered path enumeration may be difficult at enterprise scale, PER may also be measured using a capability-target surface model.
The TTP x Asset model is a surface-expansion approximation used for scalable counting of executable capability-target combinations. It does not replace ordered path modeling where sequence, dependency, or reachability chaining is required.
For a given path P_i, define the set of discrete capability-target pairs as:
P_i_surface = { (TTP_j, Asset_k) | TTP_j is an adversary capability and Asset_k is in V }
Let S_total be the total set of all unique (TTP, Asset) execution combinations allowed by system geometry across the declared scope:
S_total = union of all P_i_surface sets
Let S_eligible be the subset of S_total consisting of non-essential, unauthorized, undesired, or adversary-useful (TTP, Asset) combinations eligible for structural elimination.
Let S_erased be the subset of S_eligible rendered unexecutable through structural capability removal.
PER_TTPxAsset = |S_erased| / |S_eligible|
PER_TTPxAsset remains strictly unweighted and counting-based.
It measures the cardinal reduction of the execution surface without introducing subjective asset criticality scales, risk multipliers, likelihood scores, threat intelligence weighting, business impact multipliers, exploitability scores, or severity smoothing.
An exposed execution pair is evaluated purely on its topological existence:
| State | Meaning |
|---|---|
1 |
executable |
0 |
erased |
Weighted risk models MAY be layered on top of PER for business prioritization, but such weighting SHALL NOT alter the core PER calculation.
PER measures architectural efficacy, not subjective risk preference.
To evaluate architectural progress over an engineering epoch t_0 -> t_1, the Path Erasure Delta is computed as:
Delta PER = PER(t_1) - PER(t_0)
PER-1.0 supports two delta modes.
Fixed-Baseline Delta measures path erasure against the original declared baseline denominator.
For generic path counts:
Delta PER_fixed = ( |P_erased(t_1)| - |P_erased(t_0)| ) / |P_eligible(t_0)|
For TTP x Asset surface counts:
Delta PER_TTPxAsset_fixed = ( |S_erased(t_1)| - |S_erased(t_0)| ) / |S_eligible(t_0)|
Fixed-Baseline Delta is useful for measuring progress against a defined engineering backlog or initial baseline inventory.
Dynamic-Scope Delta recalculates PER using the current denominator when new paths, assets, TTPs, integrations, identities, workloads, or execution surfaces are introduced.
For generic path counts:
PER_dynamic(t) = |P_erased(t)| / |P_eligible(t)|
Delta PER_dynamic = PER_dynamic(t_1) - PER_dynamic(t_0)
For TTP x Asset surface counts:
PER_TTPxAsset_dynamic(t) = |S_erased(t)| / |S_eligible(t)|
Delta PER_TTPxAsset_dynamic = PER_TTPxAsset_dynamic(t_1) - PER_TTPxAsset_dynamic(t_0)
Dynamic-Scope Delta is useful for measuring architectural regression, scope expansion, newly introduced attack paths, and environmental drift.
Reports SHALL identify which delta mode is being used.
A positive Delta PER indicates structural improvement.
A negative Delta PER indicates architectural regression, reintroduced execution paths, expanded capability surface, exception-driven debt, or new attack paths introduced through environmental change.
This specification explicitly delineates diagnostic mapping from structural engineering.
Conformance to PER-1.0 requires adherence to the following two-stage hierarchy:
+------------------------------------------------------------------------+
| STAGE 1: Path Discovery & Validation (Observational Layer) |
| |
| - Enumerates system graph G = (V, E) |
| - Identifies TTP x Asset execution surface |
| - Validates reachability via simulation, emulation, BAS, CTEM, |
| exposure validation, red team testing, attack path management, |
| or equivalent methods |
| |
| Output: P_total / S_total and supporting telemetry |
+-----------------------------------+------------------------------------+
|
v
Passes P_total / S_total to
+------------------------------------------------------------------------+
| STAGE 2: Path Erasure & Capability Stripping (Deterministic Layer) |
| |
| - Removes execution edges via capability revocation |
| - Enforces non-conductive system geometry through segmentation, |
| capability boundaries, protocol removal, execution denial, |
| identity path severing, privilege reduction, or equivalent |
| structural controls |
| |
| Output: Structural Edge Elimination |
| P_erased / S_erased -> PER measurement |
+------------------------------------------------------------------------+
Systems or tools that solely perform emulation, alert generation, exposure discovery, path scoring, threat prioritization, attack graph visualization, or control validation operate strictly within Stage 1.
Stage 1 platforms do not calculate or fulfill PER compliance unless they are paired with Stage 2 structural edge removal and deterministic verification.
Discovery is not erasure.
Validation is not subtraction.
Prioritization is not architectural risk reduction.
Subtraction begins when the path ceases to exist.
To qualify as an Erased Path:
P_i is in P_erased
or as an erased surface element:
(TTP_j, Asset_k) is in S_erased
an execution edge must be eliminated through one or more deterministic mechanisms.
Boundary Non-Conductivity is the removal of physical or logical routability required for attack-path traversal.
Examples include:
- removal of unnecessary network adjacency,
- microsegmentation,
- firewall rule elimination,
- enclave isolation,
- protocol removal,
- ingress or egress path removal,
- elimination of unnecessary east-west traffic.
A boundary control qualifies only when the prohibited traversal cannot complete.
Monitoring traffic without blocking traversal does not qualify.
Capability Deprivileging is the removal of system capabilities required for attack progression.
Examples include:
- removal or blocking of unnecessary administrative tools,
- removal or blocking of script interpreters,
- removal or blocking of Living off the Land binaries where not operationally required,
- prevention of browser-to-shell execution,
- prevention of productivity application child-process spawning,
- restriction of command interpreters,
- application control or allow-listing.
A capability is considered erased when the relevant execution function is unavailable to the attacker, user process, compromised workload, or autonomous system operating within the declared model.
Identity Path Severing is the deterministic removal of privilege, trust, or token pathways that permit unauthorized state transition.
Examples include:
- revocation of cross-domain trust relationships,
- removal of standing administrative privilege,
- elimination of token inheritance paths,
- removal of excessive service account privilege,
- elimination of unnecessary OAuth grants,
- removal of unused federation paths,
- privilege boundary enforcement.
An identity path is considered erased when the privilege chain cannot be traversed even if an adversary possesses valid low-privilege access within the declared scope.
Runtime Capability Denial consists of deterministic prevention controls that block execution of a prohibited edge prior to successful state transition completion.
Examples include:
- application control policies,
- child-process prevention,
- runtime execution denial,
- capability allow-listing,
- protocol invocation blocking,
- script execution prevention,
- process-level policy enforcement,
- execution boundary enforcement.
A runtime prevention mechanism qualifies for PER credit only if the prohibited state transition cannot complete.
Runtime Capability Denial controls SHALL fail closed and resist bypass by users, workloads, or adversaries operating within the declared threat model.
The following do not qualify as path erasure:
- alert generation,
- telemetry creation,
- SIEM correlation,
- EDR detection without prevention,
- analyst workflow creation,
- post-execution containment,
- detection rule tuning,
- alert suppression.
The test is binary:
Did the prohibited edge complete?
If yes, the edge was not erased.
If no, and the denial is deterministic, persistent, policy-enforced, and fail-closed, the edge may qualify as erased.
Security exceptions SHALL NOT contribute positively to PER measurements.
Risk acceptance, policy exemptions, compensating monitoring controls, governance approvals, audit sign-offs, or ticket-based waivers do not constitute path erasure.
An exception SHALL NOT increase PER unless one or more specific executable edges are actually removed.
Partial mitigation MAY be reported separately as exception-risk reduction, but it SHALL NOT be counted as erased-path credit unless the relevant edge is non-traversable.
Examples of architectural constraints that may reduce exception-related path exposure include:
- asset isolation,
- identity trust reduction,
- restricted network adjacency,
- capability stripping,
- execution boundary enforcement,
- protocol restriction,
- compensating segmentation,
- limited-scope access enforcement.
Exception records represent documented security debt and SHALL be tracked separately from PER achievements.
A conforming implementation SHOULD maintain an Exception Debt Register that includes:
- exception owner,
- affected asset or capability,
- related path or surface element,
- architectural constraint applied,
- expiration date,
- compensating control type,
- residual executable edges,
- resulting Delta PER impact.
Documentation is not subtraction.
Only architectural constraint changes system geometry.
For a software solution, security program, or enterprise architecture to claim compliance with the PER-1.0.1 standard, it must demonstrate the following.
The implementation SHALL define:
P_total and P_eligible
or:
S_total and S_eligible
using graph-based topological modeling rather than raw vulnerability counts.
The model SHALL identify capability edges and executable paths, not merely isolated nodes, findings, alerts, or CVEs.
The implementation SHALL document the assessment scope, including:
- graph boundaries,
- asset inclusion logic,
- TTP model,
- path enumeration methodology,
- validation method,
- known exclusions.
The implementation SHALL distinguish between:
- all identified paths or surface elements,
- eligible paths or surface elements,
- business-required residual constrained paths,
- erased paths or surface elements.
The implementation SHALL explain why any path is excluded from P_eligible or S_eligible.
The implementation SHALL adhere to binary path or surface evaluation without subjective risk weighting or score smoothing.
An edge, path, or (TTP, Asset) pair is either executable or erased.
The implementation SHALL provide proof that erased edges cannot be traversed even if an adversary possesses valid low-privilege access within the declared model.
Valid verification methods MAY include:
- adversary emulation,
- BAS testing,
- red team validation,
- automated path testing,
- policy simulation with enforcement evidence,
- configuration proof combined with traversal testing.
Detection-only evidence is insufficient.
The implementation SHALL programmatically track and output Delta PER as a formal engineering metric for technical and executive stakeholders.
Reports SHALL distinguish between fixed-baseline Delta PER and dynamic-scope Delta PER.
Reports SHOULD distinguish between:
- newly erased paths,
- reintroduced paths,
- exception debt,
- newly discovered paths,
- scope expansion,
- denominator changes,
- architectural regression,
- net Delta PER.
The implementation SHALL distinguish between:
- Stage 1 path discovery and validation,
- Stage 2 path erasure and capability stripping.
A tool or program SHALL NOT claim PER conformance based solely on discovery, prioritization, exposure validation, path visualization, control validation, emulation, or detection.
The following maturity classification defines progressive conformance states.
The organization performs vulnerability, exposure, or alert monitoring.
Characteristics:
- node-centric visibility,
- vulnerability counts,
- alert counts,
- asset inventories,
- no graph modeling,
- no path-level analysis.
Typical outputs include:
- CVE lists,
- vulnerability dashboards,
- EDR alerts,
- SIEM detections,
- compliance findings.
PER-0 does not represent path erasure.
The organization models attack paths or TTP x Asset execution surfaces.
Characteristics:
- graph construction exists,
- attack paths are represented,
- capability chains are identified,
- reachability may be assumed but not empirically validated.
Typical outputs include:
- attack graph visualizations,
- path inventories,
- exposure maps,
- theoretical path models.
PER-1 establishes path awareness but does not prove reachability or erasure.
The organization validates attack path reachability through emulation, BAS, CTEM, adversarial simulation, red team activity, exposure validation, or equivalent testing.
Characteristics:
- reachability is empirically verified,
- path inventory exists,
- exploitable chains are validated,
- defensive controls may be tested.
Output:
P_total / P_eligible
or:
S_total / S_eligible
PER-2 is the highest maturity level available to systems that validate attack paths but do not structurally remove them.
PER-2 supports PER measurement by defining the denominator.
It does not, by itself, increase the numerator.
The organization performs deterministic execution-edge elimination.
Characteristics:
- structural removal exists,
- capability edges are stripped,
- paths become non-traversable,
- reachability reduction is measurable.
Output:
P_erased
or:
S_erased
PER-3 represents actual subtractive security engineering.
At this level, the organization is no longer merely observing or validating paths. It is changing system geometry.
The organization continuously measures Delta PER across engineering epochs and tracks:
- architectural regressions,
- reintroduced paths,
- exception debt,
- newly created execution surfaces,
- newly erased paths,
- scope expansion,
- control drift,
- capability reintroduction,
- compensating architecture.
Characteristics:
- path elimination becomes an ongoing engineering discipline,
- architectural efficacy is treated as a primary security program metric,
- regression is monitored,
- exception debt is quantified,
- system conductivity is continuously reduced.
PER-4 represents a continuously subtractive security architecture.
The Law of Subtractive Risk states:
Structural security risk decreases as executable attack paths are removed from the system graph.
PER-1.0 expresses this as a monotonic relationship rather than a literal reciprocal formula.
Conceptually:
R_s = f(1 - PER)
Where:
R_s= Structural RiskPER= Path Erasure Ratefis a monotonically increasing function of residual executable path surface
As PER increases, residual executable path surface decreases.
As PER approaches 1.0:
- attacker optionality decreases,
- reachable state transitions decrease,
- environmental conductivity decreases,
- system traversal becomes less feasible,
- exploit chaining opportunities collapse,
- defensive workload associated with erased paths decreases.
As PER approaches 0.0:
- attacker optionality increases,
- reachable state transitions increase,
- environmental conductivity increases,
- exploit chaining opportunities increase,
- defensive workload shifts toward detection and response,
- architecture remains dependent on reactive controls.
The Law makes no assumptions regarding:
- specific technologies,
- specific vendors,
- specific attack tools,
- detection capability,
- vulnerability volume,
- CVE severity,
- regulatory framework,
- maturity model,
- security product category.
The relationship is defined solely by system topology and reachable execution paths.
Subtractive Security therefore treats risk as a function of executable system geometry rather than as a direct function of vulnerability count, alert volume, or control inventory.
PER-1.0 does not reject observational security tools.
BAS, CTEM, attack path management, red teaming, vulnerability management, exposure validation, SIEM, EDR, and telemetry platforms may all provide useful inputs into path discovery and validation.
However, such technologies operate primarily in the observational layer unless they directly cause or verify structural edge elimination.
The following distinctions SHALL apply:
| Activity | PER Classification |
|---|---|
| Vulnerability scanning | PER-0 / node discovery |
| Alerting | PER-0 / observational |
| SIEM correlation | PER-0 / observational |
| Attack surface management | PER-1 / path awareness when graph-based |
| Attack path visualization | PER-1 / path awareness |
| BAS | PER-2 / path validation |
| CTEM | PER-2 / path validation and prioritization |
| Red teaming | PER-2 / path validation |
| Exposure validation | PER-2 / path validation |
| Attack path management | PER-2 unless paired with structural edge removal |
| Microsegmentation | PER-3 if edges are actually removed |
| Application control | PER-3 if execution paths are actually removed |
| Identity trust removal | PER-3 if privilege paths are actually severed |
| Protocol removal | PER-3 if traversal paths are actually eliminated |
| Runtime prevention | PER-3 if state transitions cannot complete |
| Continuous Delta PER tracking | PER-4 |
| Risk acceptance | Not PER |
| Policy waiver | Not PER |
| Alert suppression | Not PER |
| Detection tuning | Not PER |
| Compensating monitoring | Not PER unless paired with structural edge reduction |
This classification prevents the conflation of visibility with security improvement.
A system is not more subtractive because it sees more paths.
A system is more subtractive when fewer paths remain executable.
A conforming PER-1.0 reporting model SHOULD provide both technical and executive views.
Technical reporting SHOULD include:
- graph scope,
- path inventory,
- eligible path denominator,
- erased paths,
- residual paths,
- business-required constrained paths,
- affected assets,
- affected TTPs,
- edge removal method,
- validation evidence,
- exception debt,
- reintroduced paths,
- newly introduced paths,
- path regression causes,
- fixed-baseline Delta PER,
- dynamic-scope Delta PER.
Executive reporting SHOULD include:
- current PER,
- fixed-baseline Delta PER over the reporting period,
- dynamic-scope Delta PER over the reporting period,
- top categories of erased paths,
- top categories of residual paths,
- exception debt trend,
- architectural regression trend,
- business areas with highest residual conductivity,
- planned path-erasure initiatives.
Executive reporting SHALL avoid representing PER as a generic risk score.
PER is an architectural efficacy metric.
It answers the question:
How much of the executable attack surface has been structurally removed?
It does not answer, by itself:
What is the total business risk of the organization?
Business risk models MAY consume PER as an input, but they SHALL NOT redefine PER.
A system, tool, program, or architecture SHALL NOT claim PER-1.0.1 conformance if it:
- relies solely on vulnerability counts,
- relies solely on CVSS or severity scoring,
- relies solely on detection,
- relies solely on alert triage,
- relies solely on governance approvals,
- treats risk acceptance as path erasure,
- treats compensating monitoring as path erasure,
- does not define an assessment scope,
- does not define
P_totalorS_total, - does not define
P_eligibleorS_eligible, - does not distinguish eligible paths from business-required constrained paths,
- does not distinguish
P_totalfromP_erased, - does not distinguish discovery from erasure,
- cannot verify that an erased path is non-traversable,
- uses subjective weighting inside the core PER calculation,
- claims universal enterprise completeness without declared scope and methodology,
- uses path visualization or attack graph awareness as a substitute for edge elimination,
- reports partial mitigation as erased-path credit without proving non-traversability.
PER-1.0 formalizes the following engineering principle:
Security improves fastest when unnecessary executable paths are removed from system geometry.
The objective of Subtractive Security is not to detect every malicious action, nor to continuously score every exposure.
The objective is to reduce the number of executable paths through which adverse events can compose into material impact.
In this model:
- vulnerabilities are potential inputs,
- alerts are observations,
- controls are mechanisms,
- paths are the unit of analysis,
- path erasure is the engineering outcome,
- PER is the measurement standard.
Subtractive Security begins where observational security ends:
when the path no longer exists.