Security Brutalism Presentations

I recently introduced the Security Brutalism approach to a larger audience. The presentations I prepared, as you'd assume, were done in a very Brutalist style. Here are the slides I used. To provide context, I'll also include some of the key talking points I used during the presentation.

Contents

Presentation 1: The Brutalist Security Way
Presentation 2: 3-Year Security Brutalism Plan
Security Brutalism 3-Year Implementation - Booklet
Security Brutalism Runbook

Presentation 1: The Brutalist Security Way

Today I want to talk about something most security programs are afraid to admit:
That we’ve lost our footing.

In a sea of dashboards, compliance rituals, and frameworks...
We’ve forgotten the mission.
Security isn’t a control set.
It isn’t a program.
Security is war.
Not metaphorically. Not figuratively.
War.
We face real adversaries, with real objectives, who are faster and leaner.
And often better funded than we are.
And how do we respond?
With quarterly audits.
With policy binders.
With tools nobody uses.
That’s not warfighting.
That’s theater.
Brutalist Security throws that away.
It’s not pretty. It’s not polished.
But it works.
It's a way to fight back.
The right way.

Brutalism starts with this: Doctrine. Not decoration.
Everything in your program must trace back to a principle.
Does this reduce risk?
Does this accelerate response?
If not, burn it.
You don’t need 400 controls. You need 12 that matter.
You don’t need perfect coverage. You need speed and clarity.
Stop buying complexity to impress auditors.
Start building muscle to survive chaos.

Brutalist security is built on three things:
Small teams. Fast tempo. Aggressive defense.
You don’t need more people, you need more authority.
Train your team like they’re a special operations team.
Drill incident response until it’s muscle memory.
Stress inoculation is your friend.
And when the breach comes?
You don’t wait for permission.
You move.
We don’t defend by hiding.
We defend by attacking the problem faster than the attacker can move.

Most security leaders I know (myself included)
Have dreamed of a clean, well-architected, risk-mapped enterprise.
Let it go.
The terrain is messy, and it always will be.
You’ve got legacy systems,
Third-party junk,
Shadow IT,
And a thousand political constraints.
So what?
Brutalist Security doesn’t whine about it.
It adapts to it.
The faster you stop fantasizing about perfect security,
The sooner you can build real security.

There is no such thing as a perfectly secure environment.
Your goal is not to prevent all breaches.
That’s a lie.
Your goal is to survive them.
To detect fast,
Respond hard,
And recover stronger.
You build that capability not through rigid structure
But through discipline, training, and grit. Chaos is coming.
You don’t have to be unbreakable.
You just have to bend better than the attacker can break.

This is Security Brutalism:
Hard. Fast. Real.
No buzzwords.
No theater.
Just security that can take a hit... And hit back harder.
Don’t build a program that looks secure.
Build one that survives the fight.
If this resonates with you, tear down what’s an act.
Audit for fluff.
Empower your team.
And above all,
Fight like it matters.

Presentation 2: 3-Year Security Brutalism Plan

Note: Attendees were given a booklet for this presentation, which I've included as text below the slide deck, and you can also download as a PDF.

Let's jump on it. We're going to outline the program.
How we will implement Security Brutalism.
An approach for a stronger, simpler, and more cost-effective defense.
A 3-year plan to transform our security strategy.
And go back to common sense.

Year 1 is about understanding where we are and setting the stage.
We'll assess our current security, define our Brutalism principles,
And run a pilot project.
First, a thorough security audit to identify weaknesses and complexity.
We'll analyze tools, processes, and risks to find quick wins.
Then, we'll define our Security Brutalism policy and standards.
A working group will guide implementation and ensure alignment.

Year 2 is about rolling out Brutalism across the organization.
We'll prioritize systems based on risk and business impact.
We decide which systems/processes get the Brutalist treatment first (based on risk).
We begin to apply the principles across more of the organization.
We pause and check if it's working as expected.
Loop as needed here, it is important!
Adjust the Security Brutalism guidelines based on experience.
Not all orgs are the same. You ahve to adapt and keep on adapting.
Keep people informed. Transparency and communication are key.

Year 3 focuses on making Security Brutalism a long-term success.
We'll optimize processes, automate where possible, and track our progress.
We'll fine-tune the Brutalist Security measures already in place to make them even better.
Use technology to handle repetitive security tasks, making things more efficient.
Use Brutalist Metrics to see how well the Security Brutalism approach is working.
Keep looking for ways to make the security posture stronger
And more aligned with Security Brutalism.
And we'll reinforce the culture.
We'll make security a natural part of how everyone in the organization thinks and acts.

This approach will make us more secure, more resilient, and more efficient.
Security Brutalism is not just a strategy, it's a commitment to a stronger future.

Security Brutalism 3-Year Implementation - Booklet

This plan outlines a 3-year strategy for implementing Security Brutalism within an organization, built around survivability engineering. The goal isn't to prevent every breach, but to build systems that survive contact with reality. Compromise happens and what matters is how fast you see it, how contained the damage stays, and how quickly you recover.

Vision: A security posture that's robust, resilient, and cost-effective, where every control justifies itself against three questions: does it reduce susceptibility, does it limit damage, does it speed up recovery. If it doesn't do one of those things, it's attack surface.

Note: Timelines below assume an ideal scenario. Adjust them based on your organization's size, team resources, and leadership support.

Year 1: Assessment and Foundation

The first three months go to a full security assessment. Audit existing tools, technologies, and processes. Map critical assets and data flows, and trace susceptibility for each one: how does an attacker realistically reach this system, what identities touch it, where do trust boundaries exist in theory but not in practice. This produces a gap analysis and a prioritized list of where Brutalism principles can cut the most risk fastest.

The next three months go to governance. Write a Security Brutalism policy that defines your organization's standards, sets up a working group to approve and review security projects, and build training material so the principles spread past the security team. Every new control proposed from here forward has to answer the same question: what does this do for susceptibility, damage, or recovery time.

The final six months of year one are a pilot. Pick one system or department and apply the model directly. Assume it gets compromised. Trace how it would. Define what damage follows, specifically, not in vague categories. Measure how long recovery actually takes if you test it under real conditions. Document what you learn and use it to refine the approach before scaling.

Year 2: Broadening Implementation

Year two extends the same model across the organization, prioritized by risk and business impact. For each system, ask the same three questions used in the pilot. What happens if this gets compromised, how far does the damage spread, and how fast can it be contained and restored. Systems where recovery has never been tested under stress get treated as still theoretical, no matter how solid the plan looks on paper.

As this rolls out, expect entropy to keep working against you. Access expands because people need to get things done. Systems connect because the business demands it. Controls drift because nobody maintains perfect alignment between design and operation. Year two isn't just about adding coverage, but actively pushing back against that drift through regular review and removal of anything that doesn't earn its place.

Year 3: Optimization and Refinement

By year three, the focus shifts to maturity. Automate what can be automated, particularly monitoring, log review, and patch management, since manual processes are where recovery time quietly stretches out. Set concrete metrics: time to detect, time to contain, time to restore. Run regular chaos and adversarial simulations so recovery plans get tested before a real incident forces the issue. The program should be self-sustaining by the end of this year, with the working group reviewing systems on a cycle rather than in response to crises.

Security Brutalism Runbook

This is a living reference for applying the model day to day. For any system, system, the process is the same. Anchor on consequence first: why does this system exist, and what actually stops if it fails. That sets the boundary for how much attention it deserves.

From there, trace susceptibility. Walk the path an attacker would realistically take, step by step, and show how something small turns into something significant. Modern systems make this harder than it used to be. AI agents, automation, and integrations act with speed and scope that older controls never accounted for, and influence over what they do becomes its own attack vector.

Assume the attacker succeeds, then get specific about damage. Can they move money? Can they access sensitive data? Can they create persistence? Can they disrupt operations? Vague answers hide real risk, so push past the categories and describe what actually happens.

Then measure recovery time honestly. How long does the system stay degraded. How quickly does anyone notice. How fast can access be revoked, systems isolated, and operations restored. This is usually where assumptions fall apart. Backups exist but nobody has tested restoring from them. Logs exist but nobody watches them in time. Access controls exist but exceptions quietly override them. If it hasn't been exercised under real pressure, treat it as unproven.

Run this loop for every system, every control, every integration. Start with consequence, trace susceptibility, define damage, measure recovery, test the assumptions, and remove anything that doesn't reduce risk. Repeat as systems change, because they always do.

Closing

This plan and runbook give you a framework, not a finish line. Strong security is security that survives contact with reality. Build for the breach. Build for recovery. Everything else is attack surface.