Written by Jaiz Anuar

The SOC Detected the Attack. The Organisation Still Lost the Domain.

Detection matters only when it changes the outcome. An endpoint may be isolated in minutes while compromised identities, excessive permissions and hybrid trust paths still carry the attacker toward the domain.

A security alert is not the same as a security outcome.

A Security Operations Centre may detect suspicious activity, isolate an endpoint and close an incident within minutes. Its dashboard may show that the alert was handled successfully.

Yet the attacker may still find another route, compromise the domain and reach sensitive business systems.

This is the uncomfortable lesson from the US Cybersecurity and Infrastructure Security Agency’s recent advisory, A Tale of Two SOCs: Insights From Two Red Team Assessments.

CISA conducted similar red-team exercises against two critical infrastructure organisations. Their SOCs responded differently, but both organisations eventually suffered full domain compromise. The red team also reached sensitive business systems and cloud resources.

One SOC failed to recognise the attack. The other detected and contained parts of it quickly.

The final technical outcome was still the same.

That should make every security leader pause.

Detection Is Only One Part of Defence

Organisations have invested heavily in visibility.

Endpoint telemetry, authentication events, network traffic, cloud activity and vulnerability findings are collected by SIEM, EDR, NDR, XDR and SOAR platforms.

The assumption is simple: if we can see the attacker, we can stop the attacker.

But visibility does not automatically produce containment.

An alert must be understood. Someone must decide whether it is serious. That person must have the authority to act. The response must happen quickly enough to change the attacker’s options.

If any part of that chain fails, detection becomes little more than documentation of a compromise.

A SOC can be technically correct and still be operationally ineffective.

Similar Attacks, Different Responses

In one CISA assessment, the red team gained initial access through default credentials on an internet-facing application. That access was used to send phishing emails from an internal address, making the messages appear more trustworthy.

Security alerts were generated, but they were not handled effectively.

The organisation had multiple security tools and monitoring teams, but visibility was fragmented. Analysts faced excessive false positives, unclear escalation procedures and limited authority to respond.

The problem was not the complete absence of detection technology. The problem was that signals could not become coordinated action.

At the second organisation, the SOC detected compromised workstations and isolated them within minutes. It disrupted the initial command-and-control channel and later identified further activity near sensitive environments.

This was clearly the stronger response.

However, the assessment continued under an assume-breach scenario. The red team discovered other weaknesses, including excessive cloud permissions and paths through hybrid identity infrastructure. It eventually achieved domain-level compromise and accessed sensitive resources.

Rapid endpoint containment was valuable, but it could not compensate for weaknesses elsewhere in the architecture.

The SOC Secures What It Can See

Many organisations still manage security through separate technology domains.

The endpoint team monitors devices. The identity team manages Active Directory. The cloud team controls cloud permissions. The network team operates firewalls. Application teams manage their platforms.

Attackers do not respect these organisational boundaries.

They move from a compromised user to an endpoint, from the endpoint to Active Directory, from Active Directory to privileged identities and from on-premises infrastructure into cloud services.

To the attacker, this is one connected trust path.

To the organisation, it may involve several teams, different tools and multiple approval processes.

This is why an alert can be closed successfully while the wider attack continues.

The SOC may isolate the device it can see. But the compromised identity may remain active, an authentication token may still be valid or a cloud permission may provide another route.

Containment must follow the attacker’s trust path, not the organisation’s reporting structure.

Domain Compromise Is Often an Architecture Failure

Full domain compromise is sometimes associated with sophisticated attack techniques.

But many attack paths begin with ordinary weaknesses:

• Default credentials
• Excessive privileges
• Misconfigured certificate templates
• Unmanaged machine and service accounts
• Weak network segmentation
• Cloud permissions that are broader than necessary
• Security teams operating without shared context

Individually, each weakness may appear manageable. Together, they create a path.

This is where vulnerability management frequently falls short. Organisations evaluate findings individually, assign severity scores and create remediation tickets.

Attackers evaluate relationships.

A medium-risk configuration weakness connected to another identity weakness may create a critical attack path. The real risk is not always within one vulnerability. It exists in the trust between systems.

As discussed in Security Architecture Protects the Business; Security Controls Protect the Technology, individual controls may work correctly while the wider architecture still exposes the business.

Security architecture must therefore ask a different question.

Not simply, “What vulnerabilities do we have?”

But, “What can an attacker reach if this control fails?”

More Tools Do Not Guarantee Better Defence

Having more security products does not necessarily create a stronger SOC.

Security operations may become weaker when too many tools generate overlapping alerts without common context, ownership or prioritisation.

More telemetry creates visibility, but it also creates noise.

When normal business activity produces thousands of alerts, a genuine attack may appear less important than a noisy but harmless event. Analysts gradually learn to trust severity ratings rather than investigate behaviour and context.

Dashboards remain busy. Tickets continue to close. Monthly reports show that alerts are being processed.

But processing alerts is not the purpose of a SOC.

The purpose is to prevent an attacker from achieving an objective.

Metrics such as mean time to acknowledge, number of alerts reviewed and percentage of tickets closed may demonstrate efficiency. They do not necessarily demonstrate defensive effectiveness.

A better measure is whether the SOC can understand where the attacker is heading and intervene before something critical is reached.

Authority Is a Security Control

Technology may detect suspicious activity in seconds. Human approval may take hours.

An analyst may identify lateral movement but lack the authority to isolate a critical server. The system owner must be contacted. The application owner may be unavailable. Management may want more evidence before accepting the operational impact.

Meanwhile, the attacker continues moving.

This creates an important governance question:

How much certainty does the SOC require before it is allowed to act?

Immediate containment may disrupt business operations. Delayed containment may allow a domain-wide compromise. There is no completely risk-free decision.

Response authority must therefore be designed before an incident occurs.

Organisations should define which actions analysts may perform immediately, which require human confirmation and which demand senior approval. These decisions should consider asset criticality, attack confidence, potential blast radius and the consequences of waiting.

Authority, escalation and decision rights are not administrative details.

They are security controls.

Assume Breach Must Change the Architecture

“Assume breach” becomes meaningless if the architecture still assumes that preventing initial access is enough.

Users will click convincing messages. Credentials will be exposed. Applications will contain vulnerabilities. Configurations will drift.

The important question is what happens next.

Can the attacker move laterally? Can a normal account create another trusted identity? Can an on-premises compromise reach cloud administration? Can the SOC correlate endpoint, identity, network and cloud activity? Can sessions, tokens and certificates be revoked quickly?

An assume-breach architecture does not accept compromise passively. It limits how far the compromise can travel.

The future SOC does not merely need more alerts. It needs stronger context and faster decisions.

A mature SOC should be able to answer four questions quickly:

1. What is happening?
2. What can the attacker reach next?
3. What action will reduce the attacker’s options?
4. Who has the authority to take that action now?

If the organisation can only answer the first question, it has detection capability, not effective defence.

Final Thought

The CISA assessment does not show that detection is unimportant.

It shows that detection is only valuable when it changes the outcome.

A SOC may identify malicious activity, isolate an endpoint and meet its response target. But if the compromised identity remains trusted, the cloud remains exposed and the attacker can continue through another path, the organisation has treated the alert without containing the attack.

Security success should not be measured by whether an alert was detected or a ticket was closed.

It should be measured by whether the attacker was prevented from reaching what matters.

The SOC detected the attack.

The organisation still lost the domain.

Between those two statements lies the real measure of cybersecurity maturity.

Question assumptions. Share knowledge. Build trust.