The Brutalist Great Unveiling

Purpose: To systematically identify critical assets, expose the invisible, and build a foundational understanding for threat modeling and the implementation of a brutalist approach to security.

This is one approach to Phase 1 of the Runbook. Phase 1 can be achieved in various ways, depending on the size, needs, and context of each organization.

The approach: Start "top-down" (engage with leaders), then "bottom-up" (perform scans for discovery) and meet in the middle. Connect the dots and expose the invisible.

Guiding Principles

1. Visibility First: Focus relentlessly on making everything visible, even the forgotten and the unsanctioned.
2. Functionality Over Finesse: Prioritize identifying what keeps the business running above all else. Detailed technical specifications come later.
3. Directness and Honesty: No sugarcoating. If something is critical and undocumented, acknowledge the risk directly.
4. Iterative and Pragmatic: Start with broad scans and refine. Don't get bogged down in perfecting the details at the start.
5. Small Team Focus: Leverage the strengths of a small team for rapid communication and execution.

The Great Unveiling Method

1. Email blast to gather essentials: Directly query senior leaders on each department or business unit for their absolute must-have systems, data, and processes.
2. Technical sweep and scan: Scan networks and enumerate systems, users, and cloud assets to get a raw inventory of what's running.
3. Find the "Huh?": Compare business input with technical findings to expose undocumented or forgotten assets, the "invisible".
4. Deep dive on the critical: Investigate the function, basic connections, and data flow of systems deemed critical. Create a working graph and connect the dots.
5. Assess everything: Assign a simple criticality level (High, Medium, Low, Discard) to all identified assets.
6. Map key dependencies: For critical assets, identify the immediate technical components they rely on, who owns the systems, main function, and what would happen if any of the dependencies fail or crash.
7. Chart the backbone: Visually map the highest-criticality assets and their direct dependencies. Keep it simple, two levels of depth max.
8. Brainstorm obvious threats: Briefly identify the most likely ways critical assets could fail and the impact. Begin the threat model.
9. Act on the invisible: Decide whether to integrate, secure, or retire shadow IT and forgotten systems.

The Playbook

This is a simplified approach that provides clear, actionable steps for a small team to systematically identify critical assets, expose the invisible, and build a foundational understanding for threat modeling, leading to a completion of Phase 1 of the Runboook.

The timeframe is six-month or more depending on the organization and level of engagement.

Phase 0: The Buy-In

Objective: Obtain buy-in from Executive and Senior Leadership by providing a clear understanding of the target outcome: A more resilient organization with significant cost savings through this process.

Phase 1: The Great Unveiling

Objective: Broad discovery and initial criticality sweep via targeted emails and technical scans.

1. Run the "Business Essentials" email campaign.
• Action: Send the pre-defined "Business Essentials" email to the senior leaders of each major business unit.
• Responsible Team: Security.
• Timeline: Week 1-2.
• Output: Responses listing perceived critical systems, data, and processes.
• Documentation: Save all email responses in a designated shared folder or central location.
2. Execute initial technical visibility recon.
• Action: Run basic network scans (can use nmap or other discovery tools) across all internal IP ranges and cloud environments. Enumerate Active Directory users/devices. Manually list known cloud services per department that can’t be scanned and / or are already documented (initial assumptions).
• Responsible Team: Security, Network, Infrastructure, SRE, others.
• Timeline: Weeks 3-4 (maybe more).
• Output: Raw lists of IPs, hostnames, AD objects, and cloud services.
• Documentation: Save scan results and lists in designated files or the centralized location.
3. Perform "Huh?" analysis with the initial correlation.
• Action: Compare email responses with technical scan results. Identify systems mentioned as critical but not found, and systems found but not mentioned.
• Responsible Team: Security, Network, Infrastructure, SRE, others.
• Timeline: Week 5-6.
• Output: List of discrepancies (potential shadow IT/forgotten systems) - The Invisible.
• Documentation: Create a "Discrepancy Log" documenting each item and initial notes. Add ownership of the systems, if known.

Phase 2: Criticality Hardening and Dependency Mapping

Objective: Assign clear criticality and map basic dependencies.

1. Conduct focused system deep dives.
• Action: For each system identified as critical in the email responses. Perform basic configuration review (function, owner - if known, immediate connections). This is the beginning of the architecture diagram. Trace basic data flow (source and destination for critical data). Attempt to determine age/last update.
• Responsible Team: Leaders and Security Architecture.
• Timeline: Weeks 7-14.
• Output: The beginning of the architecture diagram with a collection of basic profiles for each critical system.
• Documentation: Update the "Critical System Profiles" document with findings.
2. Investigate "Huh?" systems.
• Action: For each item in the "Discrepancy Log": Attempt to identify the owner/purpose, quickly assess potential business value or whether it can be marked for decommission, and perform a basic security posture check (obvious vulnerabilities and configurations).
• Responsible Team: Security Engineering and IT.
• Timeline: Weeks 7-14 (in parallel with deep dives).
• Output: Assessment of each "huh?" system (value, risk, unknowns).
• Documentation: Update the "Discrepancy Log" with findings and recommendations (integrate, secure, retire).
3. Assign brutal criticality levels (bring in the sledgehammer!).
• Action: Assign a criticality level (High, Medium, Low, Discard) to each identified system based on business impact (from emails and deep dives). Document the rationale.
• Responsible Team: TBD but maybe Security Architecture with Sr. Leadership from each business units.
• Timeline: Week 15-16.
• Output: Criticality assigned to all identified assets in the "Critical System Profiles" and "Discrepancy Log".
• Documentation: Clearly note the criticality level and justification for each asset.
4. Map basic system dependencies.
• Action: For each Critical and High criticality asset, identify the immediate technical components required for it to function (servers, networks, authentication, data type).
• Responsible Team: Security Engineering, IT, Infrastructure.
• Timeline: Weeks 17-18.
• Output: List of direct dependencies for critical assets.
• Documentation: Add a "Dependencies" section to the "Critical System Profiles".

Phase 3: Charting and Initial Threat Vectors

Objective: Visualize critical paths and identify obvious threats - the Brutal Threat Model!

1. Construct a "Business Continuity Backbone" chart.
• Action: Create a simple visual chart (node-and-line) of all High-criticality assets and their direct dependencies. Color-code by criticality because why not.
• Responsible Team: IT and security architecture?
• Timeline: Week 19-20.
• Output: "Business Continuity Backbone" chart.
• Documentation: Save the chart file and a brief explanation of its components.
2. Conduct a brutalist threat model. *
• Action: For each High-criticality asset on the chart, brainstorm 1-2 obvious failure/compromise scenarios and their direct business impact.
• Responsible Team: Entire security team, with the leadership of Security Architecture providing direction, and maybe with some members of each department or business unit.
• Timeline: Week 21-22.
• Output: Initial list of threats and their potential impact on critical assets, and potential controls needed.
• Documentation: Add a "Initial Threat Vectors" section to the "Critical System Profiles".
3. Execute the Brutalist “Shadow IT/Forgotten System” action plan (need a cool name).
• Action: Based on the "Discrepancy Log" recommendations (integrate, secure, retire), begin implementing the necessary actions for each identified system. Be brutally honest and focus on reduction. Only leave the key systems if possible.
• Responsible Team: TBD.
• Timeline: Weeks 23-33 (ongoing beyond the initial possible six months, but initial actions started).
• Output: Progress on integrating, securing, or retiring shadow IT/forgotten systems.
• Documentation: Update the "Discrepancy Log" with the status of each item.

Brutalist Documentation Principles

• Keep it simple: Concise, action-oriented steps, minimal fluff.
• Clearly assign responsibility: One or two team members accountable for each playbook/documentation effort.
• Define realisting outputs: What should be produced at the end of each step. Focus on the goal.
• Specify timeline: Rough estimate of how long each step should take.
• Centralized storage: Keep all documentation (playbooks, logs, charts, profiles) in a shared, easily accessible location.

* Here's an example of a Brutalist Threat Model approach.