Three chapters cover the continuous loops: telemetry, evidence handling and drift detection; the containment-and-recovery grammar for incidents; and deterministic, rule-based prioritization that keeps CVSS, EPSS and KEV as separate signals instead of multiplying them into a single laundered score.
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.
Logging everything is not a detection strategy. Every high-value signal should map to a hypothesis and response.
7.2 Minimum signal families
Identity
login success/failure;
MFA, recovery, token, key, and password changes;
new account, role, group, or privilege;
sudo/elevation;
impossible or anomalous administrative access where context supports it;
stale and dormant privileged identities.
Host
boot/reboot/shutdown;
package, kernel, service, scheduled-task, and user changes;
unexpected process, listener, module, mount, or device;
critical file changes;
security-control failure;
resource anomalies;
time synchronization failure.
Application
authentication/authorization failures;
administrative actions;
sensitive data export;
schema/migration changes;
unexpected error patterns;
web application firewall/security middleware events;
unusual webhook/API usage;
mass object access or modification;
security setting changes.
Storage and recovery
backup success/failure/age;
repository deletion or retention change;
restoration test result;
mass file change;
disk-health degradation;
snapshot or encryption-key changes.
7.3 File integrity monitoring
FIM should focus on high-value paths, not every volatile file.
Recommended classes:
/etc/ssh
/etc/sudoers and sudoers.d
/etc/systemd/system
firewall configuration
reverse-proxy configuration
application deployment manifests
authorized_keys
service binaries and entrypoints
client website code where runtime writes are not expected
backup configuration
security-agent configuration
Exclude or tune highly volatile caches, logs, temporary files, package databases, and application upload directories unless a specific detection hypothesis requires them.
IF drift is read-only observable AND low impact
THEN ticket + scheduled remediation
IF drift creates public exposure, privileged access, disabled logging,
or loss of backup protection
THEN urgent alert + approved automated containment where pre-authorized
IF automatic remediation could lock out operators or interrupt service
THEN plan-only + human approval + canary
7.8 Detection quality measurements
Track:
coverage: assets/conditions visible
precision: validated alerts / total investigated alerts
recall proxy: incidents or findings that had no prior signal
latency: event to alert to acknowledgement to containment
attribution: ability to identify actor/object/change
reproducibility: can the detection be safely tested?
resilience: does detection survive target compromise?
Every high-priority detection should have a safe test event and a runbook. A rule that has never fired and cannot be tested is an assumption.
Use Wazuh, osquery, native audit/journald, cloud audit logs, or another suitable stack. Avoid writing a new privileged host agent until existing maintained agents cannot meet a defined requirement.
State transitions require evidence. “Contained” means the attacker’s ability to continue the harmful path is reduced and verified, not merely that a firewall rule was entered.
8.2 Incident sentence
[INCIDENT COMMANDER] declares [INCIDENT TYPE]
AFFECTING [OBJECTS / CLIENTS / DATA]
BASED ON [EVIDENCE + CONFIDENCE]
WITH [CURRENT ATTACK PATH]
AND [BUSINESS IMPACT]
THEREFORE [CONTAINMENT ACTIONS]
UNDER [EMERGENCY AUTHORIZATION]
WHILE [PRESERVING EVIDENCE]
UNTIL [VERIFIED EXIT CONDITIONS]
THEN [ERADICATION + RECOVERY + MONITORING + LEARNING].
One person can fill multiple roles for a small incident, but the responsibilities remain explicit.
8.4 Triage grammar
TRIAGE :=
what happened?
when did it begin?
is it still happening?
which clients/tenants/assets are affected?
what privileges and data are reachable?
what evidence is trustworthy?
what action reduces harm fastest?
what action could destroy evidence or recovery options?
8.5 Containment tiers
Tier 1 — reversible access restriction
revoke session/token/key;
disable affected account;
block a specific indicator;
remove a public route;
isolate a single container;
switch a feature to read-only;
rotate a scoped secret.
Tier 2 — service or host isolation
remove host from load balancer;
quarantine network interface;
disable deployment credential;
stop a compromised service;
fail over to clean capacity.
Tier 3 — broad emergency action
provider-account lock/recovery;
tenant-wide credential reset;
DNS cutover;
platform-wide deployment freeze;
backup repository protection;
multi-host isolation.
Higher tiers require higher authority unless delay would clearly increase harm and an emergency path was pre-authorized.
8.6 Evidence preservation
Before destructive eradication, collect what is practical and safe:
system time and time source
processes and network connections
logged-in users and sessions
relevant logs
service/container state
configuration and package state
file metadata and hashes
cloud/provider audit logs
identity-provider events
backup and snapshot state
Do not run untrusted binaries or “cleanup” scripts from the affected host. Preserve chain-of-custody metadata and avoid exposing client data in reports.
8.7 Credential-compromise grammar
IF credential is suspected compromised
THEN identify scope + privileges + use history + dependent secrets
AND revoke/disable
AND rotate downstream credentials
AND inspect persistence paths
AND verify old credential rejection
AND monitor attempted reuse
Rotation is incomplete when the old credential remains in images, CI variables, .env files, backups, shell history, or third-party integrations.
8.8 Web compromise grammar
IF website code or admin access is compromised
THEN preserve evidence
AND isolate affected instance/content
AND revoke deployment/admin/session credentials
AND compare against known-good artifact
AND inspect database and storage effects
AND rebuild from trusted source
AND patch root cause
AND restore data as required
AND validate externally and internally
Prefer rebuilding from a trusted image/artifact over cleaning an unknown compromised host in place.
A recovered service must not reintroduce the original weakness, compromised credential, malicious artifact, or unsafe configuration.
8.10 Recovery exit criteria
root cause addressed or safely compensated
known persistence removed
critical credentials rotated
restored data integrity checked
security controls functioning
public exposure matches policy
logs and detections functioning
backup protection restored
client functionality validated
heightened monitoring active
residual risk owned
8.11 Learning loop
After closure:
update asset/dependency map;
add or improve preventive control;
add detection and a safe validation test;
revise authorization or emergency permissions;
improve backup/recovery procedure;
update hardening profile and CI gate;
measure what delayed detection, containment, or restoration;
remove temporary emergency access and rules;
communicate client-facing facts without unsupported certainty.
9. Risk prioritization grammar
9.1 Keep different signals separate
Do not multiply CVSS and EPSS and label the result “risk.” They represent different kinds of information. Preserve:
CVSS vector and score technical vulnerability characteristics
EPSS probability population-level probability of exploitation activity
CISA KEV evidence of exploitation in the wild
local reachability whether an attack path exists in this environment
asset criticality business/client importance
impact plausible local harm
control state prevention/detection/containment currently present
confidence evidence quality and reproducibility
exposure duration how long the condition has existed
recovery readiness effect on total incident loss
9.2 Priority rules
P0 — active emergency
active compromise
OR known exploited vulnerability + affected + reachable
OR confirmed cross-tenant/data-exfiltration path on production
OR backup/identity/provider control compromise with broad blast radius
critical asset + reachable + absent compensating control
+ very high technical severity or strong exploitation-likelihood signal
P2 — high
reachable + material severity/likelihood/impact signal
OR high technical/KEV signal whose current reachability is unconfirmed
P3 — planned remediation
moderate control gap, technical severity, or exploitation likelihood
without a strong current attack path
P4 — monitor/maintain
low current signals, defense in depth, informational drift,
or accepted issue with current evidence and expiry
9.3 Priority modifiers
Move urgency upward when:
production internet exposure;
privilege boundary crossing;
tenant escape;
sensitive data;
weak or absent detection;
long exposure duration;
repeated exploitation attempts;
shared dependency across many clients;
unreliable backups;
exploit chain with other findings;
control bypass confirmed.
Move urgency downward only with evidence of:
not affected;
unreachable component/path;
strong enforced compensating control;
non-production isolated environment;
feature disabled and unloadable;
vendor analysis that applies to the exact build;
false positive reproduced and explained.
Never lower merely because a scanner labels confidence “low”; validate first.
9.4 SLA grammar
Avoid universal calendar SLAs disconnected from risk. Use response classes:
P0: emergency containment/mitigation process
P1: urgent change window
P2: normal high-priority remediation queue
P3: scheduled maintenance with monitoring
P4: routine improvement or time-bounded acceptance
Client contracts can attach explicit time limits, but the system should still retain context and permit escalation as threat signals change.
9.5 Risk acceptance
ACCEPTANCE :=
finding
+ business rationale
+ compensating controls
+ residual impact
+ owner with authority
+ approved scope
+ start date
+ expiry date
+ monitoring
+ trigger for early review
No permanent, ownerless, or scope-ambiguous acceptance.
9.6 Portfolio sorting
The CLI returns a lexicographic sort key:
priority
-> KEV first
-> reachable first
-> higher EPSS
-> higher CVSS
-> higher asset criticality
This preserves signal semantics while giving operators a deterministic work queue.
9.7 Attack-path aggregation
Individual “medium” findings can form a critical path:
public admin panel
+ weak recovery flow
+ shared service credential
+ production database write privilege
+ backup deletion permission
= account takeover + data loss path
The system should create an attack_path object that references component findings and calculates the path’s maximum plausible impact and minimum attacker preconditions.
