Skip to content

Latest commit

 

History

History
73 lines (57 loc) · 3.17 KB

File metadata and controls

73 lines (57 loc) · 3.17 KB

Methodology

Two working methods carried the engagement: a disciplined change registry, and a fixed structure for documenting every remediation. Both are simple. Both mattered more than any single technical control.

1. Append-only change management

Every modification to the estate - a firewall rule, a password rotation, a registry key, a service disable - was recorded as one atomic row in an append-only registry before or immediately after it was applied. Existing rows were never edited; a reversal was recorded as a new row referencing the prior one.

Each row carried:

Field Purpose
ID A unique, stable identifier (referenced from the report)
Timestamp UTC, for correlation with SIEM events
Host What was touched
Change What was done
Rationale Why, mapped to a control framework
Rollback command How to undo it
Re-apply command How to reproduce it from scratch
Verification How the change was confirmed effective

The rollback and re-apply commands are the point. A change you cannot undo is a liability under time pressure, and a change you cannot reproduce is lost the moment the host is reset.

Where it paid off. Mid-engagement the domain controller was accidentally reverted to an old VM snapshot, wiping every hardening change on it. Because each change had a re-apply command, the full hardening set was reproduced on the host in about seven minutes - from a registry, not from memory.

2. Structured remediation

Every finding that was acted on - a SIEM alert, a misconfiguration, a vulnerability - was documented in the same four-part structure:

  1. Detection - what fired, where, when, and the raw indicator. A specific rule, a specific log line, a specific source.
  2. Triage - what the finding means and what the realistic impact is. This is where a critical-severity signature gets separated from a critical-severity outcome; they are not the same thing.
  3. Fix - the action taken, with the exact command or setting.
  4. Verification - the evidence that the fix worked. A re-run command, a changed registry value, a query returning zero results.

The structure forces honesty. "Detection" without "Verification" is an alert nobody closed. A signature that fired (true positive for attempt) but changed nothing (null outcome for impact) gets recorded as exactly that, rather than inflated into a breach.

The same structure was applied to the hardening work - five high-value configuration settings and five vulnerabilities were each taken through detection, triage, fix, and verification, with the before-and-after evidence attached.

Why these two, specifically

Under a live attack with no preparation window, the constraints are time and trust. The change registry buys back time - recovery becomes a replay, not a re-investigation. The remediation structure buys back trust - the final report can be checked line by line against its own evidence, and nothing in it is louder than what actually happened.


Part of the engagement report. The change registry in action - the seven-minute domain-controller recovery - is in the Engagement Timeline.