Brutalist Security Architecture: Part 4 - Architecture Automation

(Part 4 of 4)

A high-level security brutalist approach to automating the initial security architecture review process. The goal is rapid, common-sense risk identification to filter out low-risk projects efficiently and flag high-risk ones for immediate architect attention. Again, this approach represents one possible implementation; there are many others. Finding what works for your specific organization is crucial.

Brutalist Automation Philosophy

• Minimal Input, Maximum Signal: Focus on extracting the most critical information with the least amount of manual effort.
• Binary or Clear Categorization: Avoid nuanced risk scoring in the initial phase. Instead, categorize as "Likely Low Risk" or "Requires further architect review."
• Actionable Insights: The output should immediately guide the next step – proceed or review.
• Automation First: Automate every possible step of the initial ingestion and analysis.
• Garbage In, Garbage Out: be willing to accept uncertainty in the face of unreliable or unavailable initial data.

Process Overview

1. Project onboarding / initial information ingestion: A standardized, automated mechanism for project teams to provide essential information.
2. Automated initial risk review: An automated script or tool analyzes the ingested data based on predefined, common-sense risk indicators.
3. Initial report output: A concise report summarizing the ingested information and the automated risk categorization.

(Possible) Automation Steps

1. Project Onboarding / Initial Information Ingestion:
• Mechanism: A simple web form or a structured data submission (maybe YAML or JSON file?) that project teams are required to complete.
• Key Data Points (Focus on what matters most for initial risk):
• Project Name/Description: Briefly describe the project's purpose.
• Data Sensitivity: Categorical selection (Public, Internal, Confidential, Highly Confidential - align with the organization's data classification).
• Internet Connectivity: Yes/No - Will any part of the system directly connect to the public internet?
• Data Storage Location(s): Where will the data be stored (specific cloud service, on-premise database)?
• Third-Party Integrations: Yes/No - Does the project integrate with any external third-party services? If yes, list them.
• Authentication/Authorization Mechanisms: Summarize how users/systems will be authenticated and authorized.
• Compliance Requirements: Checkboxes for relevant compliance standards (PCI, SOC2, etc).
• Encryption: Does the system depend on the use of encryption that may over time become obsolete.
• Secrets Management: does the system have provisions for the safe storage, use and management of secrets necessary for its operation.
• Automation:
• Form Submission Handling: Automate the ingestion of data from the web form or file into a centralized system (a ticketing system, or a dedicated risk review platform).
• Data Validation: Implement basic validation to ensure all required fields are completed and in the expected format.
2. Automated Initial Risk Review:
• Logic (common sense rules!): Implement a series of straightforward "if-then" rules based on the ingested data. Avoid complex scoring algorithms.
• High Risk Indicators (Triggers "Requires Architect Review"):
• Data Sensitivity is "Confidential" or "Highly Confidential."
• Internet Connectivity is "Yes." (but sometimes this doesn't mean high risk...)
• Integration with multiple or untrusted Third-Party Integrations.
• Specific high-impact Compliance Requirements are selected (PCI if handling payment data).
• Unclear or missing information for critical fields.
• Unmanaged secrets and credentials.
• Likely Low Risk Indicators (Triggers "Likely Low Risk"):
• Data Sensitivity is "Public" or "Internal."
• Internet Connectivity is "No." (however, it might not have internet connectivity, but if the new solution helps connect one system with internet, to another without internet, a sort of MiTM system, then this should be critical and it should be reviewed)
• No Third-Party Integrations.
• No high-impact Compliance Requirements.
• Automation:
• Scripting/Tooling: Use a scripting language (Python, Golang, etc) or a rules engine to automatically evaluate the ingested data against the defined risk indicators.
• Categorization: Based on the rule evaluation, automatically categorize the project as either "Likely Low Risk" or "Requires Architect Review."
3. Initial Report Output for Architects:
• Content: A concise report containing:
• Project Name/Description.
• Key Data Points: The information submitted by the project team.
• Automated Risk Categorization: "Likely Low Risk" or "Requires Architect Review."
• Reasoning (for "Requires Architect Review"): A brief explanation of which risk indicators triggered the review (e.g., "Identified as 'Highly Confidential' data," "Direct internet connectivity detected").
• Raw input from the ingestion form as an appendix for future reference.
• Format: A clear and easily digestible format (a simple PDF, Jira ticket, a notification in slack).
• Delivery: Automated delivery of the report to the security architecture team.
• Examples Report Snippet:

Project Name: New Internal Wiki
Data Sensitivity: Internal
Internet Connectivity: No
Third-Party Integrations: None
Compliance Requirements: None
Automated Risk Categorization: Likely Low Risk

Project Name: Customer Portal v2.0
Data Sensitivity: Confidential
Internet Connectivity: Yes
Third-Party Integrations: Stripe (Payment Processing)
Compliance Requirements: PCI DSS
Automated Risk Categorization: Requires Architect Review
Reasoning: Identified as 'Confidential' data, Direct internet connectivity detected, PCI DSS compliance requirement.

Brutalist Benefits of this Automation

• Rapid Initial Assessment: Architects can quickly see which projects require their immediate attention.
• Reduced Manual Effort: Automates the initial data ingestion and basic risk screening, freeing up architect time.
• Consistent Criteria: Ensures a consistent application of the initial risk review criteria.
• Clear Next Steps: Immediately indicates whether a project can proceed (with standard security practices) or needs deeper architectural review.
• Transparency: The decisions are based on a single customer-provided set of data that justifies the security decisions

Important Considerations

• Iterative Refinement: The risk indicators and automation logic should be reviewed and refined based on experience and evolving threats.
• Transparency: The logic behind the automated categorization should be transparent to the security architecture team.
• Escalation Path: Ensure a clear process for projects categorized as "Likely Low Risk" to be flagged for review if any red flags emerge later in the development lifecycle.