A Tale of Two SOCs: What Happened When the Government Hacked Two Companies at Once

This week, CISA published one of the most useful documents a board member will read all year, and almost no board member will read it.

The advisory, released August 25 and titled "A Tale of Two SOCs," describes two red team assessments the agency ran simultaneously against two critical infrastructure organizations. Same playbook, same tradecraft, same class of attacker. Both organizations volunteered for the exercise. Both were fully compromised at the domain level.

Here is where the stories diverge. At the second organization, a water and wastewater utility, the security operations center caught the initial phishing payloads as they executed and isolated the affected workstations within 2 to 20 minutes, cutting off the attackers' communications before the intrusion could spread. CISA's team had to switch to an "assume breach" model just to continue the exercise.

At the first organization, a government services entity, the red team gained access to multiple workstations, took elevated privileges over the entire domain, moved laterally into sensitive business systems and cloud resources, and even read the security team's email to check whether anyone had noticed them.

No one had. The organization never detected the intrusion at all.

The Uncomfortable Part: Both Organizations Had the Tools

If your instinct is that the first organization must have underinvested in security, the advisory will disappoint you. Organization A ran multiple security operations centers and multiple endpoint security tools. It had alerts firing constantly. That was precisely the problem.

CISA found that thousands of false-positive alerts from normal business operations, many rated at high severity, buried the real alerts the red team generated. The multiple SOCs had no shared visibility between them. Analysts lacked escalation procedures and had limited authority to act. In the advisory's most painful detail, a real alert tied to red team activity on a server was dismissed as a false positive because defenders could not figure out who owned the system.

CISA's conclusion was blunt: "Detection tools are only as effective as the people, processes, and procedures supporting them."

I have been making a version of this argument for years, and it rarely lands in the budget conversation. Boards approve security spending because spending feels like action. But Organization A did not fail for lack of spending. It failed because nobody had answered the operational questions that money cannot answer on its own: Who watches which alerts? Who has authority to isolate a machine at 2 a.m.? Who owns that server?

Both Had the Same Weaknesses. Only One Had the Response.

The technical findings at the two organizations were remarkably similar. At both, the red team found credentials stored in cleartext. At Organization A, the list also included default passwords on a web application, cloud access keys set never to expire, and misconfigured Active Directory certificate templates. At Organization B, the team found a service account password sitting in a configuration file with rights over a domain controller.

In other words, the utility that performed well was not clean. Its vulnerabilities looked a lot like its counterpart's. What separated the two outcomes was not the presence of weaknesses but the presence of people who noticed an intruder and acted within minutes.

That distinction is the whole story, and it maps directly onto a point I make in Cyber Risk Is Business Risk: prevention will eventually fail, so the questions that matter most are about detection and response. In the Three Questions framework, the second question is not "can we be breached?" It is "how quickly would we know?" Organization B could answer it in minutes. Organization A could not answer it at all, and did not know that it could not answer it.

Why This Belongs in Your Boardroom

There is a reason I think this advisory deserves board attention rather than just SOC attention. Every failure CISA documented at Organization A was organizational, not technical. Fragmented teams with no shared visibility. Analysts without authority. No asset ownership records. Alert volumes no human could triage. These are governance and management failures wearing a technology costume, and they are invisible in every dashboard your CISO presents, because dashboards report on tools, and the tools were all present and running.

The only way to find these failures before an attacker does is to test the way CISA tested: simulate a real intrusion and watch what the organization actually does. Not a penetration test that produces a list of vulnerabilities, but an exercise that answers the question the advisory poses: what happens after somebody gets in?

What to Ask Your CISO This Week

"If an attacker executed malware on an employee workstation right now, how long until we isolate that machine?" Organization B's answer was 2 to 20 minutes. If your CISO cannot give you a number backed by a tested procedure, you have Organization A's problem.

"How many of our alerts are false positives, and who has the authority to act on a real one?" Alert volume is not a capability. Ask specifically whether frontline analysts can isolate systems without waiting for approvals.

"Do we have a current inventory of who owns each system?" An alert on an unowned server is an alert that gets dismissed. This is unglamorous work, and it decided the outcome at Organization A.

"When did we last run an assume-breach exercise, and what changed afterward?" Not a compliance audit. Not a vulnerability scan. An exercise where someone plays the intruder and the organization has to notice.

Two organizations. Same attacker, same techniques, similar weaknesses. One contained the intrusion in minutes; the other never knew it happened. The difference was not in what they bought. It was in how they operated, and that is a matter squarely within the board's oversight.