A Security Brutalist Guide to Documentation

Brutalist security documentation, much like brutalist architecture, favors functionality, clarity, and essential structure over excessive ornamentation or unnecessary detail. No fluff. It's about providing the vital information needed for understanding, implementing, and maintaining security controls, systems, and processes without getting lost in lengthy prose or superfluous diagrams. Here's a guide to what brutalist security documentation should be like.

Core Principles

• Concise and Direct Language: Avoid jargon, ambiguity, and overly technical terms where simpler language can do. Get straight to the point.
• Focus on the "What" and "Why": Clearly state what a security [control/system/process/etc] is, what it aims to achieve (the security principle it enforces), and the rationale behind its implementation.
• Actionable Information: Documentation should directly enable understanding and action. Procedures should be step-by-step and easy to follow.
• Minimalism in Design: Favor simple formatting, clear headings, and bullet points over elaborate layouts or excessive graphics.
• Living Documents: Brutalist documentation is meant to be actively maintained and reflect the current state of the security architecture. Outdated information is worse than no information.
• Targeted Audience: Tailor the level of detail to the intended reader (a high-level overview for leadership, detailed implementation steps for engineers). However, even technical documentation should strive for clarity.
• Centralized and Accessible: Documentation should be easily findable and accessible to those who need it. A well-organized repository is crucial.

Key Elements

For Security Principles and Policies

High-Level Statements: Concise declarations of core security principles (Least Privilege, Defense in Depth) and overarching security policies.

Rationale: A brief explanation of why each principle and policy is important to the organization.

No Fluff: Avoid lengthy preambles or legalistic jargon.

For System Security Architecture or General Guidelines

System Overview: A brief, clear description of the system's purpose and critical components.

Security Controls: A straightforward list of implemented security controls, referencing specific standards or policies where applicable.

Implementation Details (Concise): Essential configuration details or implementation steps, focusing on the "how-to" without unnecessary background.

Diagrams (Functional, Not Decorative): Simple network or system diagrams that clearly illustrate security zones and data flow, avoiding overly complex or artistic renderings.

For Standard Operating Procedures (SOPs)

Step-by-Step Instructions: Numbered or bulleted lists of clear, sequential actions.

Roles and Responsibilities: Clearly defined roles for each step.

Expected Outcomes: What should be achieved after completing the procedure.

Troubleshooting (Brief): Common issues and their resolutions, kept concise.

For Incident Response Plans

Clear Roles and Contact Information: Immediately identifiable responsibilities and communication pathways.

Phased Approach: Simple, sequential steps for incident handling (Detection, Analysis, Containment, Eradication, Recovery, Lessons Learned).

Decision Flowcharts (Simple): Basic diagrams to guide the response process for common incident types.

For Threat Models

Identified Threats: A clear list of potential threats relevant to the system or application.

Mitigating Controls: The specific security controls in place to address each identified threat, with direct references to SSPs or policies.

Likelihood and Impact (Categorical): Simple categorizations (e.g., High/Medium/Low) rather than complex scoring.

For Vulnerability Management Documentation

Scanning Procedures: Clear steps for running and interpreting vulnerability scans.

Severity Levels: Simple definitions of vulnerability severity.

Remediation Guidelines: General timelines and expectations for addressing vulnerabilities based on severity.

For Change Management Documentation

Request Process: Simple steps for submitting and approving changes.

Rollback Procedures (Clear): Concise instructions for reverting changes if necessary.

Things to Avoid

• Excessive Length: Documentation should be as brief as possible while still conveying necessary information.
• Redundancy: Avoid repeating information across multiple documents. Use cross-referencing effectively.
• Ambiguous Language: Precision and clarity are paramount.
• Overly Technical Jargon Without Explanation: Assume a baseline understanding but define specialized terms when necessary.
• Decorative Elements: Focus on conveying information efficiently, not on aesthetic design. DO NOT USE EMOJIS OR OTHER FLUFF ORNAMENTS.
• Outdated Information: Regularly review and update documentation to reflect the current security landscape.

To Close

Brutalist security documentation prioritizes utility and clarity above all else. The purpose is functionality, nothing else. It's the essential blueprint for your security defenses, presented in a straightforward and actionable manner, ensuring everyone understands their role and how the security mechanisms function.