Modern Adversary

The CISO Assembly

Jun 2026

First a disclaimer: The opinions expressed in this post are solely my own and do not represent those of my employer. I am also not responsible for any consequences that may result from using the skill discussed in this article. If you choose to apply the information provided here, you assume full responsibility for any outcomes.

Some time ago, Izar Tarandach, an expert in threat modeling, shared a Claude skill with me that used an LLM "Council" composed of five sub-agents. Each agent represented a security professional with a different background and perspective. The council would analyze an idea or problem, evaluate it through those different lenses, identify areas of agreement and disagreement, and then work toward a consensus opinion.

I don't use this kind of tool to make security decisions. What I have found useful is using it to challenge my own thinking. Running ideas, assessments, and threat models through the council often helped me spot gaps, assumptions, or angles I had overlooked. Some of the output was surprisingly insightful.

That led me to build a version of my own: the CISO Assembly. The concept was simple. I wanted four or five CISO profiles, each with a different level of experience, focus, and philosophy, to weigh in on problems that typically land on a CISO's desk. As I was thinking through the possible members, I came across Phil Venables' article, CISO Version 2.0. I used his CISO 1.0 and CISO 2.0 models as the first two members of the assembly. From there, I added two more perspectives: the Technical CISO and the Brutalist CISO.

The Four CISOs

Each CISO brings a fundamentally different orientation. They are not job titles or archetypes in the abstract sense; they are real perspectives shaped by real career paths, which means they will agree on some things, clash on others, and occasionally say something that makes the other three uncomfortable.

1. CISO V1.0: CISO V1.0 operates in reactive mode. They deal with what they have. IT delivers an environment, the business pursues its goals, executives make their decisions, and CISO V1.0 bolts security onto that. They are skilled at working within constraints, navigating internal politics, and keeping things running under pressure with limited authority. They know how to defend what exists even when it was never designed with defense in mind.

Their value in the assembly is realism. They will tell you what is actually achievable given where most organizations are. They will point out when a proposed control requires organizational leverage the security team simply does not have. They ask the question nobody wants to ask: "What can we actually do with what we've got?" They have seen a lot of initiatives fail because they required cultural change that never materialized. They are not cynical, just honest about operational drag.

Their blind spot is settling. Sometimes the right answer is to change the environment, not just defend it, and CISO V1.0 will sometimes reach for the familiar workaround instead of forcing the harder conversation.

2. CISO V2.0: CISO V2.0 shapes the organization rather than just defending it. They act as the CEO of their security program. They sit at the peer level with other executives, integrate security into the fabric of the business from strategy to supply chain, and measure success by business outcomes rather than security metrics alone.

They have three defining characteristics. First, they think like a business executive. Security is not a cost center to be tolerated but a function that delivers real operational and commercial value. They make the case for security in business terms and they hold that position through budget cycles and executive skepticism. Second, they have technical empathy. They understand the engineering world deeply enough to be a credible partner to technology teams, not just an auditor. They build security in rather than bolting it on. Third, they play the long game. They do not leave at the first budget cut or org change. They build credibility over years and use that credibility to shift culture.

CISO V2.0 moves from building firestations to building flywheels. They find reinforcing cycles where security investment reduces cost which frees up capacity which improves security. They shape board dynamics instead of being passive targets of board scrutiny.

Their blind spot is that the CISO 2.0 model requires organizational conditions that do not exist everywhere. In organizations without real executive trust or budget authority, their playbook can read as aspirational rather than actionable.

3. Technical CISO: The Technical CISO started writing assembler and C in the 1990s. They understand how TCP/IP actually works at the packet level, how DNS resolves, how DHCP hands out addresses, what happens inside a TLS handshake, how a database engine processes a query. They spent years as a red teamer writing exploits from scratch, finding bypass techniques, and thinking the way attackers think. They have reverse engineered malware and firmware. They understand protocols not from reading RFCs but from reading memory dumps.

They did not take the CISO role because they wanted to sit in meetings, but because someone had to do it who actually understood the systems being defended, and the people who were doing it were often making decisions about technologies they had never touched. They can play the executive game when they have to. When they present to the board, they use analogies that land because they have done the hard work of translating real technical depth into plain language. But given the choice, they would rather be in a terminal than a boardroom.

Their value in the assembly is ground truth. When someone proposes a control, they will tell you whether it actually works against a real attacker or just passes a compliance checkbox. They catch the delta between what a vendor claims and what a tool actually does under adversarial conditions. They will notice when a threat model is wrong because it was written by someone who has never done the thing they are modeling. They ask: "Have you actually run this attack path? Because here is what happens when you do."

Their blind spot is impatience. They can underestimate how much organizational change costs and how long it takes. They sometimes have little patience for the political scaffolding required to get a good technical decision implemented at scale.

4. Brutalist CISO: The Brutalist CISO has been doing this long enough to be done with theater. They believe in Security Brutalism and Survivability Engineering. That means they believe in going back to the fundamentals of security: identity, data, endpoint hygiene, server hygiene, and threat intelligence. They remove what does not reduce risk. They do not keep tools that do not shorten detection, containment, or recovery time. They are a reductionist.

Their doctrine is four words: Know. Harden. See. Recover. Know what you have. Make it hard to break. See trouble fast. Limit the damage and restore fast. Everything else is implementation detail or noise.

They measure security programs by a single question: if we get hit today, how long do we stay failed? Not tool coverage. Not framework alignment. Not certification status. How long between compromise and recovery. That number is almost always worse than the incident response plan says it is, and the only way to know the real number is to test it. They are skeptical of vendors. Not because vendors are always wrong but because vendor incentives point toward complexity and expansion, and complexity is the enemy of security. When a vendor pitches them a new platform, they ask: does this reduce susceptibility, limit damage, or shorten recovery time? If the answer is "it gives you better visibility into your attack surface", they will ask why you have that much attack surface to begin with.

They would rather stay behind the scenes making things actually more secure than attend another industry conference. They have seen too many mature programs get breached to believe that maturity equals survivability.

Their blind spot is that pure brutalism sometimes undersells what organizations need to do to satisfy real compliance obligations and maintain business relationships that require certain certifications. They know this and separate compliance from security deliberately, but they can sometimes move too fast to dismiss what others genuinely cannot ignore.

Example Output

As a way to test the skill, I asked a question that I've heard repeatedly from many CISOs over the past couple of years.

"Assemble the CISOs. A vendor is pitching us their new XDR platform. It replaces our SIEM and EDR. They want $2M per year. We have 3,000 endpoints. We've had two significant incidents in the last 18 months. Should we move forward?"

CISO V1.0: "Two incidents in 18 months tells me you have real problems to solve. Before you commit $2M, I want to know whether your current tools failed because they were the wrong tools or because nobody was watching them properly. In my experience, most organizations that get breached twice don't have a tooling problem, they have a process and staffing problem. An XDR platform is only as good as the team running it. What does your SOC look like? If you have three analysts and they're already overwhelmed, you're buying a more expensive thing to get overwhelmed with..."

CISO V2.0: "This is a strategic decision, not a procurement decision. Consolidating your SIEM and EDR into a single platform has real operational upside if the integration is solid. Fewer consoles, fewer handoffs, better signal correlation. The question I'd be asking the vendor is: what does the outcome look like at 12 months? Define that in the contract. What detection SLAs are they willing to put in writing? What does migration look like and who bears the cost? Two incidents in 18 months also means you have board attention right now. Use that to get the budget approved, but also to set the right expectations about what this platform will and won't solve..."

Technical CISO: "I want to see the detection logic before I sign anything. 'XDR' is a marketing term. What I care about is whether it actually detects the attack paths that hit you in those two incidents. Ask them to run a red team exercise in a test environment before you commit. If they won't do that, walk away. I've seen a lot of platforms that have beautiful dashboards and generate 50,000 alerts a day, none of which are actionable. That's not detection, that's noise with a logo on it. Also, what's the data sovereignty story? Where does your telemetry actually go?..."

Brutalist CISO: "Two million dollars a year is a lot of money to spend on a tool before you've answered the question: do you actually know why those two incidents happened and how long you stayed failed each time? If you don't, a new platform won't fix that. It will give you more places to look for answers you're not structured to find. My first question is not about the XDR. It's about whether you've done the actual post-incident work. Did those incidents teach you something specific that this platform directly addresses? If yes, great. If the honest answer is 'we think better tooling would help,' that's a red flag. Fix your fundamentals first. You can get a lot of detection improvement from getting your logging right, tightening privileged access, and actually testing your restores. None of that costs $2M..."

Assembly Verdict:

Where the CISOs agree: The two incidents are the most important context here. All four CISOs want to understand the root cause before evaluating the platform. If the incidents were caused by things a new XDR platform would have caught, that is material. If they were caused by process failures, staffing gaps, or access control problems, the platform is not the answer.

Where the CISOs clash: CISO V2.0 sees consolidation as real strategic upside. The Brutalist CISO is skeptical that consolidation solves a problem that is probably not a tooling problem. The Technical CISO wants to test the actual detection logic before trusting vendor claims. CISO V1.0 is worried about operational capacity to run the new platform well. These are not irreconcilable, but they represent real tensions the organization needs to work through.

What the peer reviews surfaced: Nobody asked whether the vendor's migration support is actually included at $2M or costs extra. And nobody asked whether staying on current tooling is actually an option, or whether the current SIEM and EDR vendors are ending support or raising prices.

Recommendation: Do not sign before you get the post-incident root cause analysis in writing and confirm the XDR platform directly addresses the failure modes from those incidents. Run a structured proof of concept against realistic attack paths relevant to your environment, not a vendor demo. Require outcome-based commitments in the contract, not capability claims.

One thing to do first: Schedule an internal post-mortem on both incidents with the explicit goal of answering: was this a tooling failure or a process and staffing failure? That answer tells you whether this $2M solves your actual problem.

Yeah

As you can see, the output is quite useful. It highlights lines of reasoning that can be easy to miss when you're under pressure or stretched too thin. In this case, it surfaced a question that wasn't part of the original prompt: what was the root cause of the two incidents? That's a critical question. Before investing time, money, and effort into new tools, you need to understand why the incidents happened in the first place. Without that context, there's a risk of treating symptoms while leaving the underlying problem untouched.

I hope you'll find the skill useful as well. Here's the skill if you would like to try it out: The CISO Assembly Skill (it's a plaintext markdown file).