Volumetric matrix

This material is a defensive specification and reference set. It is not an attack tool, a scanner, a certification, or evidence of a completed assessment. It does not automate exploitation; active or state-changing operations require a valid authorization manifest, an in-scope target, an allowed mode, verified preconditions and verified rollback.

2. Volumetric matrix

2.1 Five change levels

Level	Meaning	Security expression
Baseline	Establish visibility and minimum control	Know what exists, who owns it, what is exposed, and whether minimum controls work.
Minor change	Tune existing controls	Close ports, correct permissions, rotate keys, add alerts, tighten headers, shorten retention.
Major change	Replace or redesign components	Migrate auth, segment networks, change backup architecture, rebuild images, replace shared credentials.
Structural change	Alter trust boundaries and operating model	Immutable deployment, separate management plane, per-client runners, zero-trust access, isolated evidence stores.
Paradigm change	Make security adaptive and policy-driven	Continuous verification, signed policy-as-code, automated drift response, measured recovery, threat-informed control mutation.

2.2 Internal-variable matrix

Variable	Baseline	Minor change	Major change	Structural change	Paradigm change
Object	Enumerate drives, hosts, apps, identities, data, dependencies	Correct labels, owners, criticality, lifecycle	Split high-risk objects; replace unsupported assets	Rebuild boundaries around tenants and management planes	Treat every asset as an ephemeral, attestable security object
Conditions	Record environment, exposure, privilege, backup, maintenance state	Add missing context and exception expiry	Redesign operating conditions to remove unsafe assumptions	Make policy derive from environment and trust boundary	Continuously infer context and re-evaluate authorization
Actions	Inventory, audit, patch, back up	Tune, rotate, restrict, alert	Migrate, rebuild, segment, re-key	Orchestrate canaries, immutable changes, isolated recovery	Closed-loop plan-test-change-verify-learn
Tools	Basic OS tools and passive scanners	Centralize versions, configs, parsers	Replace manual scripts with controlled runners	Separate read-only, active-test, and change execution planes	Attested disposable workers selected by policy
Resources	Asset list, owner, credentials, backups	Better telemetry and runbooks	Dedicated security data store and staging clone	Per-client infrastructure and out-of-band recovery	Dynamically allocated evidence, models, and simulation environments
Outcomes	Minimum controls visible	Fewer gaps and faster detection	Reduced attack paths and blast radius	Failure contained by architecture	Measurable resilience and adaptive control effectiveness
Feedback	Tickets and periodic review	Automated retests and drift alerts	Architecture decisions informed by recurring findings	Control failures trigger safe isolation or rollback	Feedback changes profiles, priorities, and test selection continuously
Constraints	Legal scope, uptime, privacy, budget	Explicit rate, time, and change ceilings	Rework incompatible systems and contracts	Encode constraints as policy and tenant boundaries	Constraints become machine-verifiable preconditions
Value	Avoid preventable compromise	Reduce toil and client uncertainty	Protect revenue, data, and recovery capability	Make client security scalable and provable	Security becomes a continuously measured service quality
Failure mode	Unknown assets, missed patches, weak backups	False positives, alert fatigue, stale exceptions	Migration error, lockout, dependency breakage	Control-plane compromise, shared-tenant failure	Automation amplifies a bad policy unless governed and reversible

2.3 The 14 LAKA meta-variables applied to security

Magnitude — how much change or harm?

0 none
1 local configuration effect
2 single service or dataset effect
3 host/application effect
4 tenant/client effect
5 multi-client/platform effect

Measure both change magnitude and plausible incident magnitude. A one-line firewall change may have platform-scale impact.

Rate — how quickly?

Track:

patch latency
credential revocation latency
mean time to detect
mean time to acknowledge
mean time to contain
mean time to restore
control drift rate

Direction — moving toward what?

secure / insecure
known / unknown
isolated / connected
least privilege / privilege expansion
recoverable / unrecoverable
verified / assumed

Scope — how broadly?

file -> process -> container -> host -> network -> tenant -> client portfolio

Scope must distinguish intended coverage from actual coverage.

Depth — how fundamentally?

surface observation
configuration verification
authenticated control test
business-logic test
architecture/trust-boundary test
recovery and adversarial resilience test

Greater depth requires stronger authorization and safety controls.

Duration — for how long?

Track control lifetime, authorization lifetime, exception lifetime, credential lifetime, evidence retention, outage duration, and exposure duration.

Frequency — how often?

Use event-driven checks where possible:

on commit
on image build
on deployment
on DNS/certificate change
on package advisory
on new KEV signal
on privilege change
on backup completion
on incident state change

Periodic scans remain useful for blind spots but should not be the only feedback loop.

Acceleration — is the rate increasing or decreasing?

Examples:

findings accumulating faster than remediation;
login failures accelerating;
disk errors increasing;
patch latency worsening;
certificate expiry risk approaching nonlinearly;
repeated drift after each deployment.

Acceleration is often a better early-warning signal than absolute count.

Variability — how consistent or unpredictable?

Measure variability of deployment configuration, restore time, log volume, vulnerability count, performance under tests, and administrative behavior. High variability may indicate unmanaged snowflake systems or unstable controls.

Detectability — how visible and measurable?

0 no telemetry
1 indirect symptom
2 periodic visibility
3 near-real-time event
4 attributed, correlated, and reproducible evidence
5 pre-impact warning with tested response

A preventive control with no failure signal is incomplete.

Reversibility — can it be undone?

fully reversible by config rollback
reversible by snapshot or restore
reversible with data loss
not safely reversible
time-sensitive reversibility

Encryption, key deletion, storage reformatting, firewall changes, and account revocation require explicit reversibility analysis.

Propagation — how does it spread?

Map:

credential reuse
shared images
CI/CD artifacts
network trust
DNS delegation
package dependencies
backup replication
administrative automation
multi-tenant control planes

Amplification — what makes the effect larger?

Common amplifiers:

root or cloud-owner privilege;
public exposure;
shared secrets;
wildcard credentials;
centralized automation;
unbounded concurrency;
write access to backups;
lack of segmentation;
a trusted signed but compromised artifact.

Accumulation — what builds up over time?

Track technical debt, stale accounts, exceptions, unsupported packages, unused firewall rules, untested backups, orphaned DNS, vulnerable images, secrets in history, and unresolved low-severity findings that form an attack chain.

2.4 Volumetric vector

Represent every control, finding, or change as a vector rather than a binary:

volume:
  magnitude: 3
  rate: "2 affected hosts/hour"
  direction: "toward least privilege"
  scope: [client-acme, production, web-tier]
  depth: "authenticated configuration verification"
  duration: "permanent control; quarterly review"
  frequency: "on deployment + daily"
  acceleration: "stable"
  variability: "one host differs from image baseline"
  detectability: 4
  reversibility: "snapshot + configuration rollback"
  propagation: [golden-image, ansible-role]
  amplification: [public-exposure, privileged-service]
  accumulation: "three unresolved drift events in 30 days"

2.5 Security maturity is not one number

Maintain a profile with separate axes:

GOVERNANCE
ASSET KNOWLEDGE
IDENTITY
HOST
NETWORK
APPLICATION
DATA
DETECTION
RESPONSE
RECOVERY
EVIDENCE QUALITY
AUTOMATION SAFETY

A system can be strong in patching and weak in recovery. Averaging those into one score can hide a fatal gap. Dashboards should show the shape of the security volume, not only its mean.

2.6 Five-state measurement for each control

UNKNOWN     no current evidence
ABSENT      evidence shows the control is not implemented
PARTIAL     some objects or conditions are covered
VERIFIED    current evidence satisfies the objective
RESILIENT   failure is detected, contained, and recovery is tested

An exception is not a sixth “safe” state. It is a treatment record attached to an absent or partial control, with owner and expiry.

The five change levels

The 14 meta-variables

Magnitude

Rate

Direction

Scope

Depth

Duration

Frequency

Acceleration

Variability

Detectability

Reversibility

Propagation

Amplification

Accumulation

The chapter in full