Documenting Without Creating a Security Liability

Chapters 2 through 5 pushed toward documentation that's more complete, more detailed, and captures more of what an experienced person actually knows. That same completeness has a real cost: the more thoroughly useful a document is to a legitimate technician resolving an incident quickly, the more useful it can potentially be to someone who shouldn't have it at all. This chapter is about writing genuinely useful documentation without it becoming an attack tool sitting in plain sight.

The Core Rule: Never Embed Real Sensitive Values

Never write an actual password, a real API key, or a genuine sensitive configuration value directly into a runbook or KB article — even an internal one, even one you trust everyone currently reading it. Use a clear placeholder instead (<YOUR_API_KEY>), and reference a proper secrets vault or access-management process rather than the literal value.

Why "It's Internal Only" Isn't a Sufficient Excuse

This is `secsupport1`'s own least-exposure principle, applied specifically to documentation content itself, not just live data handling during a ticket. Internal documentation systems get compromised too — an insider misusing legitimate access (`secsupport1`'s own curiosity-access material), or a single compromised account with ordinary read access to the internal wiki. Documentation systems are frequently subject to less scrutiny than production systems themselves — the same reasoning `backup1` applied to backup infrastructure being an attractive, under-monitored target applies directly here.

Beyond Credentials: Attack-Blueprint-Level Detail

Some non-credential detail is still risky to document in full — exact firewall rule logic, or specific detection thresholds precise enough to let someone deliberately stay just under an alert threshold. A runbook can be specific enough to be genuinely useful to a legitimate reader without functioning as a literal blueprint for anyone else who happens to get hold of it.

Access Control on the Documentation Itself

Not every runbook needs to be visible to the entire organization. Documentation covering security-incident handling or disaster-recovery procedures deserves the same least-exposure access thinking `secsupport1` and `backup1` already applied to systems and backups — restrict access to whoever genuinely needs it, rather than defaulting to "everyone can see everything" purely because that's the more convenient default.

Reference, Don't Reveal

Both right-hand versions give a legitimate reader exactly what they need to proceed, without the document itself ever holding the actual sensitive value.

Hands-On Exercises