AI readiness

You Can't Eat the Sacred Cow

We love telling each other not to eat the elephant all at once. Good advice, mostly useless, because it assumes you're allowed to take a bite.

We love telling each other not to eat the elephant all at once. Good advice, mostly useless, because it assumes you're allowed to take a bite.

Most organizations treat cyber like the enemy. They don't listen to it, don't fund it, and don't give it priority. That's not an elephant. That's a sacred, golden cow. You can't even get near it with a fork. And every piece of advice we hand CISOs assumes a table, a plate, and permission, none of which they have.

So let's start where they actually are.

CISA just published the control group

On August 25, CISA released advisory AA26-237A, "A Tale of Two SOCs." It documents two red team assessments run at the same time, against two critical infrastructure organizations, using similar tradecraft. One in government services and facilities. One in water and wastewater.

Organization A never detected them. The team found a web application running default credentials on built-in accounts, used it to send phishing from an internal address, landed on four workstations, escalated to domain level through default Machine Account Quota settings and misconfigured Active Directory Certificate Services templates, and moved laterally into sensitive business systems and cloud resources. All of it invisible.

Organization B caught the initial access and quarantined it. The red team had to fall back to an assumed breach model just to keep working, and Organization B caught some of that too.

Same attacker. Same techniques. Same week. Opposite outcomes.

We almost never get this. Security is an industry of anecdotes and vendor case studies, and here is something close to a controlled experiment with the results published. So it's worth being precise about what actually separated the two, because the wrong lesson is sitting right there waiting to be picked up.

CISA points at triage speed, custom detections, quarantine action, and analysts trained to act on what fires. And it points at something more uncomfortable: Organization A was buried under thousands of false positives generated by normal business operations, many of them rated higher severity than the actual intrusion. The alerts fired. Nobody could find them.

Organization A had tools. Organization B had a practice.

Practice is not the same thing as solution

I've been hard on exposure management hype for years, and it gets misread, so let me put it plainly.

Continuous threat exposure management is real. It's needed. Organizations should invest in it.

What I won't stand behind is vendors selling an easy button for something that requires operational discipline. That's the distinction, and it's not semantics:

A solution is a technology product that addresses a specific problem you can solve with a tool.

A practice is people, process, and tools coming together to solve problems.

CTEM is a practice. So is detection and response. So is recovery. When you buy a practice as though it were a solution, you get Organization A: a full toolbox, a clean architecture diagram, and an attacker with domain admin who nobody noticed for the length of the engagement.

The tools weren't the variable. Both organizations had tools.

Quantify it before you ask for anything

Here's the part CISOs skip, and it's the reason the sacred cow stays untouched.

The message to leadership can't be technical. It has to arrive as risk in dollars and cents. To do that you have to quantify the problem and the solution, and most security leaders have only ever quantified the problem, in a language nobody upstairs speaks.

Start with honest questions. Which systems do you personally believe are most vulnerable? What does your real recovery time look like, not the number in the BCP binder? What breaks if you're down? Billing? Production? Shipping?

Then do the arithmetic. There are roughly 250 working days in a year. Divide annual turnover by 250 and you have a rough cost per day of downtime. Add legal fees for preparing material breach reporting and disclosures. I use $500 an hour as a floor, deliberately, because published rates for breach counsel run $650 to $2,100 an hour for partners and $525 to $950 for senior associates. A conservative floor you can defend beats an aggressive number you have to argue about. Add the cost of disclosure and anything you owe customers or employees directly. Add reputation repair.

If leadership wants an outside benchmark, IBM's 2026 Cost of a Data Breach puts the global average at $4.99 million, up 12 percent, and the US average at $11.5 million. The component breakdown maps almost exactly onto the worksheet above: $1.64 million in detection and escalation, $1.54 million in lost business and downtime, $1.36 million in post-breach response including legal, and $0.45 million in notification. Mean time to identify and contain is 247 days.

And the reputation piece isn't a clean 18-month heal, whatever you've been told. Churn rises 3 to 5 percent after a high-profile incident and compounds year over year. Seventy-six percent of consumers stop sharing personal data with a breached company. The one variable you control is how you communicate, and transparent breach communication cuts churn by as much as 30 percent.

Now you have a number. Now you can have the conversation.

The five day sprint, and what it's actually for

Next you need five steps and the cost of those steps. Foundational ones. Maybe a single significant tool if you're truly behind. Five columns:

Identity. Protect. Detect. Respond. Recover.

You have five business days. Total. For all five.

Every CISO reading that just objected, and the objection is correct. You cannot materially improve five domains in a week. Anyone who tells you otherwise has never carried the pager.

So here's what the sprint is actually for. You're not remediating. You're documenting current state and quantifying risk posture, honestly, in writing. It reads like this:

"Our identity system is Microsoft Active Directory. We do not have modern standards for password complexity, our MFA is not consistently deployed, and we do not audit access and permissions regularly. We back up Active Directory but could not confirm our ability to reset all the accounts, and we do not have clear mapping of non-human identity accounts to the applications and services that use them. The recommended next actions are:"

That, for each of the five. In five days. That's achievable, and it's more valuable than any control you could half-install in the same window.

If you've already done that work, then you're holding a list of things you've never been able to fix. Pick one. And here's the counterintuitive part: it matters less whether you pick the highest-impact item or the purest Zero Trust principle. What matters is showing leadership you can move the needle inside a short window and keep your promise.

The output of the sprint isn't a safer network. It's credibility. You're building the trust that lets you ask for larger things later and get a yes.

Identity, not Identify

You'll notice I wrote Identity where the framework says Identify. That's deliberate.

Identify is an inventory exercise. Identity is the thing the attacker actually takes, and it's the one system almost nobody can restore to a trusted state.

Look at how Organization A fell: default Machine Account Quota, misconfigured ADCS templates, excessive permissions, exposed credentials. That's an identity failure end to end. And recovery is genuinely brutal. Microsoft's own forest recovery guidance requires rotating the krbtgt password twice in rapid succession, roughly 10 to 12 hours of replication across domain controllers, every authentication session dropped, and a restart of every computer on the domain. That's the documented happy path, and most organizations have never rehearsed it.

We back it up. We can't prove we can bring it back clean. Those are different sentences and only one of them is in your board deck.

Keep every promise, and keep the receipts

When the five are signed off, complete them. No matter what. Then report completion and include the next five, with this attached:

"We are working in sprints to close the low hanging fruit that is quick, valuable, and where we are capable today. Next week I will present a strategy and budget to take this seriously and provide the protection the business needs to reach the industry standard. I am not trying to make us the most protected enterprise in our industry. That is not reasonable today. I will present a pragmatic plan to get us to the industry average, so we are at least as good as most of our neighbors and no longer at the bottom."

Three rules around that. Every promise you make, you keep. The operations leader signs off before you agree to anything. The board gets informed, and if you can't reach the board, then the CIO, the CFO, and the CEO, in that order.

Inform in writing. Keep the receipts and store them offline, because the blame game arrives after you've been told no, not before.

Don't sell your team down the river to look good in a meeting. And don't go big. If you reach for the sun you'll be denied, and it will be your fault.

What to do

TO CISOs: Quantify the exposure in dollars before you ask for a dollar. Run one five day sprint that documents honest current state across all five columns. Deliver it, on time, complete. Ask for the real budget in week two, framed as reaching industry average.

TO BOARDS: Ask for the dollar-denominated exposure number and the honest recovery time, in writing, and read both. A CISO who only brings you green dashboards is managing you, not the risk.

TO CEOs AND CFOs: If your security leader has never brought you a number, that's a reporting structure you own. If they brought you one and you didn't fund it, put that decision in writing, because it's yours now.

TO VENDORS: Sell the practice. Selling an easy button to an organization that hasn't documented its current state takes money from people who needed process first.

Be pragmatic. Work fast. Aim small, miss small.

Aim big, miss big, get fired. We don't want that.


← All positions Work with Phronia →

Found an error? Write to corrections@phronia.co - we read every report and note material corrections at the foot of the piece. How corrections work.