Brutalist Security Architecture: Part 3 - The Program

(Part 3 of 4)

This program is built on the core tenets of brutalist security and the fundamentals of security in general: Fundamentals Controls, Automation-First, Transparency, Assume Breach, Continuous Validation, Minimalist Tooling, and Focus on Outcomes.

The aim is to make security architecture a non-negotiable part of how the company operates, not a suggestion, essentially become part of the integral fabric of a company, one that is unambiguous and actionable. This approach represents one possible implementation; there are many others. Finding what works for your specific organization is crucial.

Establish the "Security Architecture Mandate" (the brutalist policy)

1. Formal Document: Create a concise, one-page document titled "Security Architecture Mandate." This is the company's official position on security architecture. Needs the signature and OK from all executive leadership.
2. Core Principles (unambiguous language is a must):
• Primacy of Fundamentals: All systems must be built upon a foundation of strong identity management, secure configurations, and network segmentation. Deviation requires explicit, documented, and leadership-approved exception. Security controls are part of a system basic features, not extras.
• Automation-First: Security controls, reviews, and monitoring will be automated wherever technically feasible. Manual processes are exceptions, not the rule.
• Transparency: Security architecture decisions and rationale will be documented clearly and made accessible to relevant teams. Obscurity is a vulnerability.
• Assume Breach: All systems will be designed with the assumption that a breach is possible. Blast radius reduction and rapid recovery are design requirements.
• Continuous Validation: Security controls will be regularly tested and validated for effectiveness. Compliance is not a substitute for demonstrable security.
• Minimalist Tooling: Security tools will be selected based on clear need and demonstrable value. Tool sprawl is unacceptable. Preference is given to simple, well-understood solutions.
• Focus on Outcomes: Security architecture success is measured by reduction in risk and improvement in incident response capabilities, not by the number of controls deployed.
3. Leadership Endorsement: This mandate must be signed by the CEO or equivalent top-level executive to signify its authority.
4. Distribution: The mandate is distributed to all employees, especially those in engineering, development, and product management, and is a required reading for new technical hires. Functions that develop business processes that manipulate or distribute sensitive information are also expected to know and abide by the mandate.

Mandatory Security Architecture Integration Points

1. Project Inception (The Security Architecture Gate):
• Automated Initial Review (as defined): Every new project must complete the automated initial security review. Projects categorized as "Requires Architect Review" cannot proceed to development without formal architect approval. This is enforced through project management systems (Jira, etc) or development workflows.
• Security Architecture Sign-Off: For projects requiring architect review, sign-off is mandatory at the design phase. Architects provide a clear list of required security controls and design changes.
2. Software Development Lifecycle (SDLC) Enforcement:
• Security in CI/CD (Automated): Security checks (SAST, DAST, vulnerability scanning, AI tests) are mandatory and automated within the CI/CD pipeline. Builds fail if critical vulnerabilities are detected. This is enforced through the CI/CD system itself.
• Immutable Infrastructure (Mandatory): All production deployments must use immutable infrastructure. Configuration drift is prohibited and automatically flagged.
3. Vendor and Third-Party Onboarding (The Security Vetting Process):
• Security Architecture Review: Any new vendor or third-party solution that handles company data or impacts security must undergo a security architecture review, using the brutalist review criteria. A standardized template for this review is provided.
• Approved Vendor List (Minimalist Approach): The company maintains a curated list of "approved" vendors that meet security architecture requirements. Preference is given to using vendors on this list. Adding a new vendor requires a strong justification and a rigorous security review.

Empowerment and Accountability

1. Security Architecture Team Authority: The security architecture team has the authority to enforce the Security Architecture Mandate. They are not advisors; they are enforcers of the company's security principles.
2. Developer and Engineer Responsibility: Developers and engineers are accountable for implementing security controls as defined by the security architects. This is part of their performance evaluation.
3. Leadership Accountability: Project managers and product owners are accountable for ensuring that projects adhere to the Security Architecture Mandate. They cannot bypass the security architecture gate.

Continuous Improvement and Brutalist Metrics

1. Regular Audits (Automated): Automate regular audits of security controls to ensure compliance with the Security Architecture Mandate.
2. Brutalist Security Metrics: Track metrics that align with the brutalist principles, for example:
• Percentage of projects that pass the initial automated review (high percentage is good).
• Number of security vulnerabilities detected in production (decreasing trend is good).
• Percentage of security controls that are automated (increasing trend is good).
3. Mandate Review: The Security Architecture Mandate is reviewed and updated at least annually to ensure it remains relevant and effective.

In Short

This approach makes security architecture a fundamental, unavoidable, and clearly defined aspect of the company's operations. It's designed to be simple enough for everyone to understand and too important to ignore.