Brutalist Security Meets Team of Teams: Part 1 - Introduction

(Part 1 of 5)

The power of Security Brutalism, as we've observed, comes from its strict adherence to core security principles to create a solid foundation. This approach doesn't rely on flashy features, but on the essentials that form the backbone of modern security. Fundamental practices—such as properly configured and hardened systems, regular patching, enforced multi-factor authentication, and a zero trust model—serve as the concrete barriers that make common exploits and opportunistic attacks far more difficult to carry out.

However, without the right culture—one that fosters adaptability, collaboration, and continuous learning—a Brutalist Security program is difficult to implement effectively. This is where Gen. McChrystal’s Team of Teams approach becomes essential. Instead of a rigid hierarchy, you have smaller, empowered units focused on specific security functions (threat intelligence, incident response, vulnerability management, security awareness) but connected all along. These security teams aren't isolated; they are linked to other parts of the business, technical or otherwise, through shared consciousness and a common purpose, much like the interconnected cells in an organism.

Gen. McChrystal’s model focuses on information sharing and collective awareness. Applied to security, it means all teams—including leadership, IT and technical teams—regularly share findings, threats, and vulnerabilities. This creates a shared understanding, allowing quicker detection and coordinated response. For example, if threat intel spots a new tactic, vulnerability management can scan for exposures, incident response can prepare playbooks, and IT can rapidly deploy fixes or adjust controls. This distributed, real-time collaboration leads to faster, more effective defense.

When you combine a brutalist approach to security with a Team of Teams model, you begin to build better redundancy and resilience. If one part of the "team of teams" is compromised or overwhelmed, the others can step in and provide support. This inherent redundancy makes the overall security posture more resilient to disruptions. It's not a single point of failure but a network of interconnected capabilities. It also provides, as we will see in following posts, continuous improvement: The constant feedback loops and collaboration within the "team of teams" foster a culture of continuous improvement and security awareness. Lessons learned from incidents or threat intelligence are quickly disseminated and used to strengthen both the fundamental controls and the teams' processes. The program isn't static, it's constantly being reinforced and adapted based on real-world threats.

Finally, one of the key elements of this method is, if done in a transparent and open way, organizational buy-in. When security isn't just the responsibility of a siloed security department but is integrated into the fabric of the entire organization (as the "Team of Teams" concept encourages), you achieve broader buy-in and participation. Developers writing secure code, HR conducting security awareness training, and IT operations following secure configurations become integral parts of the overall security posture. This turns the entire organization into a layer of defense, reinforcing the core security fundamentals.

In short, Security Brutalism and a Team of Teams model compliment each other to create a strong and more resilient security foundation:

• Function Over Frills: Security takes precedence over convenience or aesthetics, favoring clear, effective controls—delivered through lean, empowered teams that prioritize action over bureaucracy.
• Layered and Distributed Defense: Just as Security Brutalism builds security in distinct, robust layers, the Team of Teams approach spreads these responsibilities across autonomous, specialized teams—each managing a different aspect of the security stack.
• Foundational and Adaptive: While Security Brutalism is rooted in proven fundamentals (e.g., hardening, patching, MFA, zero trust), the Team of Teams model ensures these foundations evolve through continuous feedback, shared learning, and rapid adaptation.
• Shared Awareness, Local Autonomy: Brutalist security demands discipline and precision; Team of Teams supports this with a shared understanding across all groups—threat intel, incident response, IT, engineering—so everyone operates with context and clarity.
• Fast, Informed Action: Security incidents often require speed. Team of Teams enables quick, decentralized decision-making, empowering each security function to act immediately within its domain without waiting for top-down directives.
• Resilient by Design: Just as brutalist structures are built to withstand external pressure, this combined approach creates a resilient organization—structurally secure, yet agile enough to respond to evolving threats.

Implementing a "Security Brutalism" philosophy within a "Team of Teams" structure

There’s no one-size-fits-all way to implement this. It must be adapted to fit the unique culture and environment of each organization. That said, here are some potential ways it might take shape:

• Decentralized Security Ownership: Each autonomous team within the "Team of Teams" structure could be responsible for implementing and maintaining a baseline of "brutalist" security controls relevant to their specific domain. This could involve mandatory secure coding practices, strict access controls for their systems, and rigorous testing protocols.
• Security Councils or Communities of Practice: To ensure consistency and the sharing of security knowledge, security professionals embedded within different teams could form guilds or communities of practice. These groups would be responsible for defining and enforcing the "brutalist" security standards across the organization.
• Central Security "Architecture" Team: A smaller, central security team could act as the architects of the overall "brutalist" security framework. They would define the foundational security principles, select core security technologies, and provide guidance and tooling to the individual teams.
• "Security Liaison" Roles: Individuals with a strong security focus could act as liaisons between different teams, ensuring that security considerations are integrated into their workflows and that information about threats and vulnerabilities is shared effectively.
• Automated and Enforced Controls: To minimize friction and ensure consistent application of "brutalist" security measures, automation would likely be heavily utilized. This could involve automated code scanning, infrastructure-as-code with built-in security configurations, and automated compliance checks.
• "Security by Default": The underlying infrastructure and tooling provided to the teams will have strong security defaults baked in, reflecting the "brutalist" philosophy. This could include secure operating system configurations, network segmentation, and robust authentication mechanisms that are difficult for individual teams to weaken.
• Blunt but Clear Security Feedback: Security feedback provided to teams will be direct and unambiguous, highlighting vulnerabilities and non-compliance without sugarcoating, aligning with the "uncompromising" aspect of Security Brutalism.

Potential Benefits

Enhanced Security Posture. The layered and uncompromising nature of "Security Brutalism," combined with the distributed ownership of a "Team of Teams" model, could lead to a more resilient and robust security posture.

Faster Response Times. Empowered teams can react more quickly to security incidents within their domain.

Improved Security Awareness. Embedding security responsibilities within each team can foster a stronger security culture across the organization.

Scalability: The "Team of Teams" model is inherently scalable, and a distributed security approach can scale with it.

Potential Challenges

Maintaining Consistency. Ensuring consistent application of "brutalist" security standards across a large number of autonomous teams can be challenging.

Potential for Friction. The uncompromising nature of "Security Brutalism" might create friction with development teams focused on speed and agility.

Complexity of Coordination. Coordinating security efforts across a decentralized network of teams requires effective communication and clear responsibilities. We will see in the next posts how to solve this problem.

Risk of Silos. While aiming for distributed ownership, there's a risk of security knowledge becoming siloed within individual teams if communication and collaboration aren't actively fostered. We will see in the next posts how to solve this problem.

In Short

Implementing a "Security Brutalism" approach with a "Team of Teams" structure could be a powerful way to build a strong and resilient security foundation while leveraging the agility and scalability of empowered, autonomous teams. However, careful planning, clear communication, and a strong emphasis on collaboration is crucial to overcome the potential challenges.

Next Part 2.