When the Security Control Plane Fails: Build a Minimum Viable Defensive System

Posted on August 31, 2026 by Brent Huston

At 2:13 a.m., the SOC receives an alert involving a cloud administrator.

At 2:16, analysts lose access to the SIEM because authentication depends on the identity provider now under investigation.

At 2:19, the incident collaboration channel disappears.

At 2:23, the on-call engineer discovers that the break-glass credentials are stored in the privileged-access platform—which also authenticates through the suspect identity provider.

At 2:27, the cloud console still shows green status indicators, but nobody can establish whether the logs are complete, delayed, or manipulated.

By 2:35, the organization has two incidents.

The first is the security event.

The second is the loss of its ability to respond to the security event.

That second incident is the one most response plans do not adequately address.

Incident Response Has a Hidden Assumption

Most incident-response plans assume the defensive machinery will survive the incident.

The identity provider will authenticate responders. The privileged-access system will issue administrative credentials. The cloud management plane will accept containment commands. The SIEM will provide reliable telemetry. The ticketing platform will maintain the timeline. Email, chat, conferencing, and document-sharing systems will allow the response team to coordinate.

Those systems are treated as infrastructure surrounding the incident rather than as potential components of the incident.

That is a dangerous assumption.

In a recent State of Security post, I argued that controls that look separate on an architecture diagram may actually be “branches of the same tree.” They may share an identity provider, administrative tenant, logging pipeline, automation layer, DNS infrastructure, certificate authority, or cloud control plane. When one of those shared foundations fails, several supposedly independent controls can fail with it. (State of Security)

The next question is harder:

What is the smallest defensive system the organization must be able to operate after that tree falls?

This is not conventional disaster recovery. It is not simply a matter of restoring the SIEM, activating a backup tenant, or retrieving an emergency password.

It is degraded-mode security operations.

The Control Plane Can Fail by Lying

Security teams usually test failures as availability problems.

The identity provider is down. The SIEM is unreachable. The ticketing platform will not load. The primary cloud region is unavailable.

Those are relatively clean failures. They are visible, bounded, and easy to describe during a tabletop exercise.

Adversarial failure is different.

A compromised identity provider may continue issuing tokens. A hostile administrator may alter conditional-access policies while leaving the service operational. A logging pipeline may continue displaying data while silently omitting selected events. A collaboration platform may preserve most messages while exposing the incident channel to the attacker. An automation platform may continue executing containment playbooks after its credentials or logic have been subverted.

The system is not down.

It is lying.

That distinction changes the recovery problem. An unavailable system can sometimes be restored. An untrustworthy system must first be excluded from the response path.

NIST’s cyber-resiliency work provides the right foundation for thinking about this. It frames resiliency around four outcomes: anticipating adverse conditions, withstanding them, recovering from them, and adapting afterward. It also applies that thinking to shared services, common infrastructure, and systems of systems—not merely individual applications. (NIST Computer Security Resource Center)

A resilient security program therefore cannot define success only as preventing compromise or restoring systems. It must be able to continue essential defensive operations while some of its own systems are unavailable, degraded, or hostile.

Start With Inversion

The normal planning question is:

How do we keep the security control plane available?

That is necessary, but incomplete.

Invert the problem:

Assume the primary security control plane is unavailable or cannot be trusted. How do we still defend the organization?

Assume that:

The primary identity provider cannot be trusted.
Existing administrative sessions may belong to the attacker.
The privileged-access platform is inaccessible.
Centralized telemetry is incomplete.
Normal collaboration and ticketing systems are exposed.
Managed responder workstations may be under hostile administrative control.
Cloud automation may be executing unauthorized changes.
DNS, certificate, key-management, or time services may be unreliable.
One or more key responders cannot be reached.

Now ask what responders must still be able to do.

Not which products must be restored.

Not which dashboards executives expect to see.

Not which recovery checklist should be opened first.

What capabilities must exist for the organization to remain defensible?

Define the Minimum Viable Defensive System

A Minimum Viable Defensive System is the smallest deliberately independent collection of people, authority, identities, devices, communications, telemetry, containment mechanisms, evidence storage, and recovery materials that allows the organization to continue defending itself when its normal security control plane is unavailable or untrusted.

It is not a second full-sized SOC.

It is not a duplicate of every production security tool.

It is not a collection of individually labeled “break-glass” features.

It is a composed operating system for degraded defense.

At minimum, it must provide six capabilities.

Capability	Minimum viable state	Evidence that it is independent
Authenticate	Authorized responders can establish identity and emergency authority using protected credentials and trusted administrative devices.	The path does not require the primary identity provider, PAM platform, corporate network, normal endpoint-management plane, or primary email account.
Communicate and coordinate	Responders can establish a secure command channel, assign roles, reach critical internal and external parties, and maintain a decision and action log.	Accounts, provider, authentication, network path, and recovery information do not depend on the primary collaboration environment.
Observe	Responders can obtain trustworthy information from critical systems and identify gaps, delay, or tampering in normal telemetry.	Collection, storage, access, keys, and administrative authority do not all share the suspected failure domain.
Contain	Responders can revoke access, disable identities, isolate assets, stop dangerous automation, alter routes or policies, and protect critical systems.	Emergency containment does not require normal SSO, normal PAM approval, the primary SOAR platform, or access to the normal ticketing workflow.
Preserve evidence	Responders can store relevant logs, configuration data, images, exports, notes, and decision records with integrity and provenance.	Primary administrators cannot silently alter or delete the evidence, and responders retain access to keys, timestamps, capacity, and custody procedures.
Reconstitute	Responders can rebuild roots of trust and restore defensive services from known-good materials in a defined order.	Configurations, credentials, keys, backups, tooling, and administrative access do not depend entirely on the environment being rebuilt.

These are capabilities, not products.

A security team may satisfy them through a mixture of cloud-native controls, offline materials, separate accounts, alternative providers, clean devices, manual procedures, direct system access, and preauthorized decision rights.

NIST makes a similar architectural point in its resiliency guidance: survivability comes from combinations of technology, architectural choices, engineering practices, operational procedures, and people—not from one product or control.

Break Glass Is Not an Account

Organizations often point to an emergency administrative account as proof that degraded-mode access has been addressed.

That is only one link in the chain.

Consider an emergency account that:

Is stored in the normal PAM platform.
Uses the normal identity provider for authentication.
Requires a managed laptop that cannot be unlocked without normal SSO.
Can be used only from the corporate network.
Depends on the normal DNS and certificate infrastructure.
Requires an approval recorded in the normal ticketing system.
Sends its alerts to the normal SOC mailbox.

The account exists.

The emergency capability does not.

Break glass is not an account. It is an end-to-end operating path.

Microsoft’s emergency-access guidance recommends multiple cloud-only accounts, authentication methods that differ from normal administrative authentication, secure storage, monitoring, and recurring validation. AWS similarly describes pre-created emergency identities and roles, dedicated emergency access arrangements, hardware authentication, and periodic testing for situations in which the centralized identity provider is unavailable or compromised. (Microsoft Learn)

Those are valuable design ingredients. The security program still has to compose them into a functioning response system.

The responder must be able to retrieve the credential, authenticate, use a trusted device, reach the management interface, execute an authorized action, record that action, observe its effect, and preserve the resulting evidence.

Testing only the login proves only the login.

Independence Is a Property of the Whole Path

Two tools can be different and still fail together.

A secondary messaging platform is not independent if it uses the same identity provider.

A backup SIEM is not independent if it receives data through the same collectors.

A separate cloud account is not independent if the compromised organization administrator can assume control over it.

An immutable log store is not useful during the incident if access to its decryption keys depends on the failed key-management plane.

A responder laptop is not clean if it must contact the suspect device-management service before allowing an administrator to sign in.

An alternate network path is not alternate if it converges on the same DNS, certificate, firewall-management, or telecommunications dependency.

This is why fallback design must be scenario-specific. Nothing is universally independent. It is independent only relative to a defined failure.

NIST’s guidance on diversity and redundancy warns that apparent alternatives can converge on the same underlying foundation. It specifically treats diversity of command, control, and communications paths—including out-of-band paths—as a resiliency technique, and notes that redundancy can be undermined when duplicated capabilities share common resources or homogeneous components.

CISA guidance has likewise emphasized out-of-band incident communications, separate management paths, and logging aggregated into protected out-of-band locations. These practices reduce the chance that the compromised environment can blind or isolate the response team. (CISA)

Again, those mechanisms are necessary.

They are not sufficient until they work together.

Restore Capabilities, Not Products

During a compound failure, organizations tend to restore whatever system has the most visible outage, the loudest executive sponsor, or the clearest recovery runbook.

That can produce the wrong order.

The goal is not to make the security stack look normal as quickly as possible. The goal is to restore trustworthy defensive agency.

A practical priority sequence looks like this.

1. Establish trusted command

The organization needs an incident commander, an emergency authority model, authenticated responders, a protected communications channel, and a functioning decision record.

Without trusted command, every subsequent action is debatable. Responders do not know who is authorized, which instructions are legitimate, or whether the attacker is participating in the response.

This layer should also provide access to an offline or separately protected contact roster covering executives, legal counsel, insurers, outside responders, critical vendors, law enforcement contacts, and communications personnel.

2. Establish a trustworthy view

Responders must determine what they can still observe and which sources remain credible.

This does not require immediately rebuilding the entire SIEM. It may involve direct access to native audit sources, an independently protected log archive, network telemetry, cloud snapshots, system exports, or read-only queries through emergency accounts.

The first question is not, “Are logs arriving?”

It is, “What evidence do we have that these logs are complete, current, and resistant to alteration by the suspected adversary?”

Evidence preservation begins here. Observation and preservation should not be separated into distant phases. The data available during the first hour may not remain available later.

3. Regain safe containment capability

Once responders have enough confidence to act, they need a limited but reliable way to constrain the event.

That may include:

Revoking sessions and tokens.
Disabling identities.
Isolating accounts, workloads, subscriptions, or network segments.
Blocking known infrastructure.
Suspending compromised automation.
Protecting backups and logging repositories.
Restricting administrative paths.
Moving critical services into a predefined defensive posture.

Containment paths should be narrow, preauthorized, observable, and reversible where practical.

They should not depend on the same orchestration layer whose trust is in question.

4. Reconstitute roots of trust

Only after responders have trusted command, sufficient visibility, and safe agency should they begin rebuilding the normal control plane.

Reconstitution must follow dependency order.

Identity may need to be restored before PAM. Key management may need to be restored before protected logging. Trusted administrative endpoints may need to be rebuilt before cloud policy is changed. Logging may need to be reestablished before production workloads are reconnected.

Restoring dependent tools before their foundations are trustworthy creates the appearance of recovery without its substance.

This is a priority model, not a waterfall. Observation, evidence preservation, and containment will often proceed in parallel. The point is to prevent teams from restoring familiar products while critical defensive capabilities remain absent.

Measure Time to Defensible State

Traditional recovery planning uses recovery-time objectives to express how long a system can remain in recovery before unacceptable harm occurs. That is useful for determining when an identity platform, logging service, or collaboration system must return. (NIST Computer Security Resource Center)

It does not answer what defenders can do while those systems remain unavailable.

A security program should add another measure:

Time to Defensible State

Time to Defensible State is the elapsed time between declaring the primary defensive control plane unavailable or untrustworthy and validating that the Minimum Viable Defensive System is operating through independent paths.

A defensible state might require proof that:

Emergency authority has been invoked.
Required responders have authenticated independently.
A secure command channel is operating.
A decision and action record is being maintained.
At least one trustworthy telemetry path is available.
Responders can execute and verify an emergency containment action.
Evidence can be deposited into an independently protected repository.
The team understands which normal services remain prohibited.

“Someone successfully logged in” is not a defensible state.

“We opened the backup chat room” is not a defensible state.

The state is reached only when the capabilities operate together.

Organizations should measure the component times as well:

Time to recognize and declare control-plane degradation.
Time to establish trusted responder identity.
Time to establish out-of-band command.
Time to obtain the first trustworthy telemetry.
Time to execute the first validated containment action.
Time to preserve the first evidentiary artifact.
Time to begin controlled reconstitution.
Maximum duration the degraded system can operate.

That last measure matters.

A fallback that works for 20 minutes but cannot support a twelve-hour investigation is not sufficient. Capacity, credential lifetime, battery life, communications access, evidence-storage volume, staffing, vendor support, and shift turnover are all part of the design.

Test Compound Failure, Not Components

Most organizations test their emergency mechanisms one at a time.

The emergency administrator logs in.

The backup conference bridge works.

The log archive accepts a test event.

The incident-response binder opens.

The cloud backup restores.

Every component passes.

Then the system fails during the exercise because nobody can retrieve the emergency credential without the PAM system, the clean laptop requires the unavailable identity provider, and the alternate communications channel does not include legal counsel or the cloud team.

Component success is not system success.

A meaningful exercise should begin with a compound condition such as:

The identity provider is suspected of compromise. Existing administrative sessions cannot be trusted. The centralized logging query plane is unavailable, although some collection continues. Normal email, chat, ticketing, and PAM systems are prohibited. The cloud management environment may contain unauthorized policy changes.

Then make the team perform the work.

Retrieve the emergency materials using the real custody process.

Start the designated administrative devices.

Use the actual alternate network path.

Authenticate to the necessary systems.

Generate a known event and prove it appears in the independent telemetry path.

Contain a sacrificial asset.

Preserve an artifact and validate its integrity.

Reach an external participant.

Maintain the incident log.

Operate long enough to perform a shift handoff.

Exit degraded mode, reconcile all emergency actions, rotate credentials, and restore monitoring.

Do not allow the exercise controller to hand the team imaginary access, pretend that a credential was retrieved, or declare a containment action successful without executing a safe equivalent.

Every simulated shortcut conceals a dependency.

NIST’s current incident-response guidance treats preparation, response, and recovery as integrated parts of cybersecurity risk management rather than as a separate binder activated after detection. Compound-failure testing is one way to turn that integration into operational evidence. (NIST Computer Security Resource Center)

The Fallback Creates Its Own Risk

An independent defensive system is powerful.

That also makes it dangerous.

Emergency identities may hold standing privilege. Alternative communications channels may escape normal monitoring. Offline credentials can become stale or be mishandled. Direct administrative paths can bypass approval systems. Separate evidence stores may contain highly sensitive information. Dormant devices may miss critical patches.

The fallback cannot simply be hidden and forgotten.

It requires its own controls:

Dual custody for the most powerful emergency materials.
Tamper-evident storage and access records.
Narrowly scoped emergency roles.
Independent monitoring of every activation.
Regular credential, key, and device validation.
Immediate review and rotation after use.
Defined activation and termination authority.
Reconciliation of emergency actions into normal records.
Periodic review for new shared dependencies.

This is a second-order tradeoff.

The organization creates exceptional access to survive the loss of normal access controls. It must then protect that exceptional access without reconnecting it to the same control plane it was designed to bypass.

There is no product setting that resolves that tension. It must be engineered and governed.

A Practical Design Standard

A security program should not claim degraded-mode readiness until it can produce six things.

1. A declared defensive minimum

The organization has explicitly defined what authentication, communication, observation, containment, evidence preservation, and reconstitution mean in its environment.

2. A dependency topology

Each capability has been traced through its identities, devices, networks, providers, administrators, keys, data sources, and human custodians.

Shared failure domains are visible.

3. Independence claims tied to scenarios

The organization does not say that a system is simply “independent.” It states which failures it is independent from and provides evidence supporting that claim.

4. Activation and exit criteria

Responders know who can declare the primary control plane untrusted, what changes when that declaration occurs, and what evidence is required before normal systems can be used again.

5. Measured recovery of defensive capability

The organization has established a target Time to Defensible State and measured it during an end-to-end exercise.

6. Evidence of sustained operation

The fallback has demonstrated that it can support a realistic incident duration, including staffing changes, evidence growth, credential use, containment actions, external coordination, and eventual reconciliation.

This turns degraded-mode response from a collection of reassuring statements into a testable design standard.

Small. Separate. Boring. Measured.

The Minimum Viable Defensive System should be small enough to understand.

It should be separate enough to survive the named failure.

It should be boring enough to operate under stress.

It should be measured often enough that leadership knows whether it is real.

Centralization is not inherently bad. Modern security programs need centralized identity, logging, administration, orchestration, and collaboration.

But centralized efficiency creates concentrated dependency.

A mature program does not pretend those dependencies will always survive. It plans for the moment when the normal tools are unavailable, the dashboards are questionable, and the attacker may be using the same administrative machinery as the defenders.

The question is no longer:

Do we have break-glass accounts?

The question is:

Can we prove that authorized responders can authenticate, communicate, observe, contain, preserve evidence, and begin reconstitution when the primary security control plane is unavailable or hostile—and can they do it within a measured period?

Until the answer is yes, the organization is resilient only while its assumptions hold.

Security programs must do more than defend the business.

They must remain capable of defending it while their own machinery is failing.

More Information and Assistance

MicroSolved, Inc. can help organizations:

Map security-control dependencies and shared failure domains.
Define a Minimum Viable Defensive System.
Design independent emergency identity, communications, administrative, logging, and evidence paths.
Establish degraded-mode activation and recovery procedures.
Run compound-failure tabletop and live validation exercises.
Define and measure Time to Defensible State.

Contact MicroSolved at info@microsolved.com or +1.614.351.1237. Relax. We’re on watch.

* AI tools were used as a research assistant for this content, but human moderation and writing are also included. The included images are AI-generated.

Stop Measuring Security Controls. Measure Decision Latency.

Posted on August 10, 2026 by Brent Huston

The attacker already made a decision.

Your organization is still scheduling the meeting.

For years, security programs have measured the presence and performance of controls. We count vulnerabilities, patching percentages, phishing failures, endpoint coverage, open findings, audit exceptions, and incident response times.

These metrics can be useful.

They can also create the illusion that security outcomes are primarily determined by control quality.

In many consequential events, the organization does not fail because it lacks information or technology.

It fails because it cannot make a confident decision quickly enough.

Cyberleader

Continue reading →

Vendor Evidence Is Now a Cyber Materiality Risk

Posted on June 29, 2026 by Brent Huston

A cybersecurity incident does not care where your data lives.

It does not care that the affected application is vendor-managed. It does not care that the logs are in a SaaS console your team cannot access. It does not care that the data-flow diagram is maintained by procurement, that customer-impact details live with a managed service provider, or that the outage timeline depends on a third-party support ticket.

But your materiality decision may care very much.

Public companies must disclose material cybersecurity incidents on Form 8-K within four business days after determining that the incident is material. The SEC’s rule also requires disclosure of the material aspects of the incident’s nature, scope, timing, and impact or reasonably likely impact, and the materiality determination must be made without unreasonable delay after discovery.

That creates a practical problem many organizations have not fully internalized:

The disclosure clock may be yours, but the evidence may belong to someone else.

That is not just a legal nuance.

It is an operational design problem.

It is a governance problem.

Continue reading →

Rational Security in the AI Era: How Attackers Are Evolving and How We Must Respond

Posted on June 3, 2026 by Brent Huston

The weaponization of artificial intelligence by cybercriminals and nation-state actors has crossed a critical inflection point. We no longer live in a world where we can rely solely on traditional perimeters; the threat landscape has fundamentally shifted into what we might call “Extremistan,” where the speed and scale of attacks demand a completely new level of resilience.

SadKitty

At MicroSolved, our mission is to provide rational cybersecurity for an irrational world. To do that effectively, we must look unflinchingly at the data.

The Problem and the Metrics

The numbers tell a stark story of industrialization at machine speed. According to recent threat reports, AI-enabled adversaries increased their attack volume by 89% year-over-year. More concerning is the velocity: the average eCrime breakout time has collapsed to just 29 minutes, with the fastest recorded intrusion moving from initial access to lateral movement in a staggering 27 seconds.

The financial impact is equally severe. The FBI IC3 recorded over 22,000 AI-related complaints with adjusted losses exceeding $893 million in 2025 alone, including tens of millions lost to AI-enabled Business Email Compromise (BEC). AI is accelerating attack speeds by 4x, making human-speed incident response no longer viable.

Continue reading →

The Evidence Supply Chain: How CISOs Build a Cyber Materiality Data Plane Before the Incident

Posted on May 26, 2026 by Brent Huston

A ransomware incident does not wait for the organization chart to catch up.

At 8:17 a.m., the SOC sees encryption activity on a file server. At 8:31, operations says the plant is still running. At 8:44, finance says revenue recognition may be affected if order processing stays down past noon. At 9:02, legal asks whether customer data was accessed. At 9:18, the forensic team says it is too early to tell. At 9:23, a vendor says the outage may have started in their environment. At 9:41, communications asks whether they should prepare a holding statement.

By hour two, everyone is working hard.

But they are not necessarily working from the same reality.

That is the problem.

Cyber materiality is often discussed as a decision problem. When does a cyber event become a board-level business event? When does it become reportable? When does it become material to investors, customers, regulators, lenders, or strategic partners?

Those are important questions. Public companies, for example, must disclose material cybersecurity incidents on Form 8-K within four business days after determining materiality, including the material aspects of the incident’s nature, scope, timing, and impact or reasonably likely impact.

But underneath that decision sits a deeper problem:

Continue reading →

Cyber Materiality Engineering: How CISOs Pre-Decide When Risk Becomes a Board Event

Posted on May 18, 2026 by Brent Huston

A ransomware incident does not stay technical for very long.

For about the first fifteen minutes, it may look like a security operations problem. A strange alert. A locked server. A suspicious authentication chain. A vendor portal behaving badly. A handful of systems no longer responding the way they should.

Then the blast radius starts to widen.

Operations wants to know whether they can keep running. Finance wants to know whether revenue recognition, cash movement, reserves, or forecasts are exposed. Legal wants to know whether notification clocks have started. The CEO wants to know what can be said, to whom, and when. The board wants to know whether this is “material.” Investors may eventually ask the same thing, only with less patience and more lawyers.

This is where many organizations discover that their cyber incident response plan is not really an enterprise decision plan. It tells people who to call. It tells the SOC how to preserve evidence. It may even have a communications tree and a sample press statement.

But it often does not answer the question that matters most in the first few hours:

Continue reading →

From Alert Volume to Signal Yield: An Economic Framework for Measuring SOC Effectiveness

Posted on March 2, 2026 by Brent Huston

Six months after a major alert-reduction initiative, a SOC director proudly reports a 42% decrease in daily alerts. The dashboards look cleaner. The queue is shorter. Analysts are no longer drowning.

Leadership applauds the efficiency gains.

Then reality intervenes.

A lateral movement campaign goes undetected for weeks. Analyst burnout hasn’t meaningfully declined. The cost per incident response remains stubbornly flat. And when the board asks a simple question — “Are we more secure now?” — the answer becomes uncomfortable.

Because while alert volume decreased, risk exposure may not have.

This is the uncomfortable truth: alert volume is a throughput metric. It tells you how much work flows through the system. It does not tell you how much value the system produces.

If we want to mature security operations beyond operational tuning, we need to move from counting alerts to measuring signal yield. And to do that, we need to treat detection engineering not as a technical discipline — but as an economic system.

AppSec

The Core Problem: Alert Volume Is a Misleading Metric

At its core, an alert is three things:

A probabilistic signal.
A consumption of analyst time.
A capital allocation decision.

Every alert consumes finite investigative capacity. That capacity is a constrained resource. When you generate an alert, you are implicitly allocating analyst capital to investigate it.

And yet, most SOCs measure success by reducing the number of alerts generated.

The second-order consequence? You optimize for less work, not more value.

When organizations focus on alert reduction alone, they may unintentionally optimize for:

Lower detection sensitivity
Reduced telemetry coverage
Suppressed edge-case detection
Hidden risk accumulation

Alert reduction is not inherently wrong. But it exists on a tradeoff curve. Lower volume can mean higher efficiency — or it can mean blind spots.

The mistake is treating volume reduction as an unqualified win.

If alerts are investments of investigative time, then the right question isn’t “How many alerts do we have?”

It’s:

What is the return on investigative time (ROIT)?

That is the shift from operations to economics.

Introducing Signal Yield: A Pareto Model of Detection Value

In most mature SOCs, alert value follows a Pareto distribution.

Roughly 20% of alert types generate 80% of confirmed incidents.
A small subset of detections produce nearly all high-severity findings.
Entire alert families generate near-zero confirmed outcomes.

Yet we often treat every alert as operationally equivalent.

They are not.

To move forward, we introduce a new measurement model: Signal Yield.

1. Signal Yield Rate (SYR)

SYR = Confirmed Incidents / Total Alerts (per detection family)

This measures the percentage of alerts that produce validated findings.

A detection with a 12% SYR is fundamentally different from one with 0.3%.

2. High-Severity Yield

Critical incidents / Alert type

This isolates which detection logic produces material risk reduction — not just activity.

3. Signal-to-Time Ratio

Confirmed impact per analyst hour consumed.

This reframes alerts in terms of labor economics.

4. Marginal Yield

Additional confirmed incidents per incremental alert volume.

This helps determine where the yield curve flattens.

The Signal Yield Curve

Imagine a curve:

X-axis: Alert volume
Y-axis: Confirmed incident value

At first, as coverage expands, yield increases sharply. Then it begins to flatten. Eventually, additional alerts add minimal incremental value.

Most SOCs operate blindly on this curve.

Signal yield modeling reveals where that flattening begins — and where engineering effort should be concentrated.

This is not theoretical. It is portfolio optimization.

The Economic Layer: Cost Per Confirmed Incident

Operational metrics tell you activity.

Economic metrics tell you efficiency.

Consider:

Cost per Validated Incident (CVI)
Total SOC operating cost / Confirmed incidents

This introduces a critical reframing: security operations produce validated outcomes.

But CVI alone is incomplete. Not all incidents are equal.

So we introduce:

Weighted CVI
Total SOC operating cost / Severity-weighted incidents

Now the system reflects actual risk reduction.

At this point, detection engineering becomes capital allocation.

Each detection family resembles a financial asset:

Some generate consistent high returns.
Some generate noise.
Some consume disproportionate capital for negligible yield.

If a detection consumes 30% of investigative time but produces 2% of validated findings, it is an underperforming asset.

Yet many SOCs retain such detections indefinitely.

Not because they produce value — but because no one measures them economically.

The Detection Portfolio Matrix

To operationalize this, we introduce a 2×2 model:

	High Yield	Low Yield
High Volume	Core Assets	Noise Risk
Low Volume	Precision Signals	Monitoring Candidates

Core Assets

High-volume, high-yield detections. These are foundational. Optimize, maintain, and defend them.

Noise Risk

High-volume, low-yield detections. These are capital drains. Redesign or retire.

Precision Signals

Low-volume, high-yield detections. These are strategic. Stress test for blind spots and ensure telemetry quality.

Monitoring Candidates

Low-volume, low-yield. Watch for drift or evolving relevance.

This model forces discipline.

Before building a new detection, ask:

What detection cluster does this belong to?
What is its expected yield?
What is its expected investigation cost?
What is its marginal ROI?

Detection engineering becomes intentional investment, not reactive expansion.

Implementation: Transitioning from Volume to Yield

This transformation does not require new tooling. It requires new categorization and measurement discipline.

Step 1 – Categorize Detection Families

Group alerts by logical family (identity misuse, endpoint anomaly, privilege escalation, etc.). Avoid measuring at individual rule granularity — measure at strategic clusters.

Step 2 – Attach Investigation Cost

Estimate average analyst time per alert category. Even approximations create clarity.

Time is the true currency of the SOC.

Step 3 – Calculate Yield

For each family:

Signal Yield Rate
Severity-weighted yield
Time-adjusted yield

Step 4 – Plot the Yield Curve

Identify:

Where volume produces diminishing returns
Which families dominate investigative capacity
Where engineering effort should concentrate

Step 5 – Reallocate Engineering Investment

Focus on:

Improving high-impact detections
Eliminating flat-return clusters
Re-tuning threshold-heavy anomaly models
Investing in telemetry that increases high-yield signal density

This is not about eliminating alerts.

It is about increasing return per alert.

A Real-World Application Example

Consider a SOC performing yield analysis.

They discover:

Credential misuse detection: 18% yield
Endpoint anomaly detection: 0.4% yield
Endpoint anomaly consumes 40% of analyst time

Under a volume-centric model, anomaly detection appears productive because it generates activity.

Under a yield model, it is a capital drain.

The decision:

Re-engineer anomaly thresholds
Improve identity telemetry depth
Increase focus on high-yield credential signals

Six months later:

Confirmed incident discovery increases
Analyst workload becomes strategically focused
Weighted CVI decreases
Burnout declines

The SOC didn’t reduce alerts blindly.

It increased signal density.

Third-Order Consequences

When SOCs optimize for signal yield instead of alert volume, several systemic changes occur:

Board reporting becomes defensible.
You can quantify risk reduction efficiency.
Budget conversations mature.
Funding becomes tied to economic return, not fear narratives.
“Alert theater” declines.
Activity is no longer mistaken for effectiveness.
Detection quality compounds.
Engineering effort concentrates where marginal ROI is highest.

Over time, this shifts the SOC from reactive operations to disciplined capital allocation.

Security becomes measurable in economic terms.

And that changes everything.

The Larger Shift

We are entering an era where AI will dramatically expand alert generation capacity. Detection logic will become cheaper to create. Telemetry will grow.

If we continue to measure success by volume reduction alone, we will drown more efficiently.

Signal yield is the architectural evolution.

It creates a common language between:

SOC leaders
CISOs
Finance
Boards

And it elevates detection engineering from operational tuning to strategic asset management.

Alert reduction was Phase One.

Signal economics is Phase Two.

The SOC of the future will not be measured by how quiet it is.

It will be measured by how much validated risk reduction it produces per unit of capital consumed.

That is the metric that survives scrutiny.

And it is the metric worth building toward.

* AI tools were used as a research assistant for this content, but human moderation and writing are also included. The included images are AI-generated.

Methodology: MailItemsAccessed-Based Investigation for BEC in Microsoft 365

Posted on November 3, 2025 by Brent Huston

When your organization faces a business-email compromise (BEC) incident, one of the hardest questions is: “What did the attacker actually read or export?” Conventional logs often show only sign-ins or outbound sends, but not the depth of mailbox item access. The MailItemsAccessed audit event in Microsoft 365 Unified Audit Log (UAL) brings far more visibility — if configured correctly. This article outlines a repeatable, defensible process for investigation using that event, from readiness verification to scoping and reporting.

Objective

Provide a repeatable, defensible process to identify, scope, and validate email exposure in BEC investigations using the MailItemsAccessed audit event.

Phase 1 — Readiness Verification (Pre-Incident)

Before an incident hits, you must validate your logging and audit posture. These steps ensure you’ll have usable data.

1. Confirm Licensing

Verify your tenant’s audit plan under Microsoft Purview Audit (Standard or Premium).
- Audit (Standard): default retention 180 days (previously 90).
- Audit (Premium): longer retention (e.g., 365 days or more), enriched logs.
Confirm that your license level supports the MailItemsAccessed event. Many sources state this requires Audit Premium or an E5-level compliance add-on.

2. Validate Coverage

Confirm mailbox auditing is on by default for user mailboxes. Microsoft states this for Exchange Online.
Confirm that MailItemsAccessed is part of the default audit set (or if custom audit sets exist, that it’s included). According to Microsoft documentation: the MailItemsAccessed action “covers all mail protocols … and is enabled by default for users assigned an Office 365 E3/E5 or Microsoft 365 E3/E5 licence.”
For tenants with customised audit sets, ensure the Microsoft defaults are re-applied so that MailItemsAccessedisn’t inadvertently removed.

3. Retention & Baseline

Record what your current audit-log retention policy is (e.g., 180 days vs 365 days) so you know how far back you can search.
Establish a baseline volume of MailItemsAccessed events—how many are generated from normal activity. That helps define thresholds for abnormal behaviour during investigation.

Phase 2 — Investigation Workflow (During Incident)

Once an incident is underway and you have suspected mailboxes, follow structured investigation steps.

1. Identify Affected Accounts

From your alarm sources (e.g., anomalous sign-in alerts, inbound or outbound rule creation, unusual inbox rules, compromised credentials) compile a list of mailboxes that might have been accessed.

2. Extract Evidence

In the Purview portal → Audit → filter for Activity = MailItemsAccessed, specifying the time range that covers suspected attacker dwell time.
Export the results to CSV via the Unified Audit Log.

3. Correlate Access Sessions

Group the MailItemsAccessed results by key session indicators:

ClientIP
SessionId
UserAgent / ClientInfoString

Flag sessions that show:

Unknown or non-corporate IP addresses (e.g., external ASN)
Legacy protocols (IMAP, POP, ActiveSync) or bulk-sync behaviour
User agents indicating automated tooling or scripting

4. Quantify Exposure

Count distinct ItemIds and FolderPaths to determine how many items and which folders were accessed.
Look for throttling indicators (for example more than ~1,000 MailItemsAccessed events in 24 h for a single user may indicate scripted or bulk access).
Use the example KQL queries below (see Section “KQL Example Snippets”).

5. Cross-Correlate with Other Events

Overlay these results with Send audit events and InboxRule/New-InboxRule events to detect lateral-phish, rule-based fraud or data-staging behaviour.
For example, access events followed by mass sends indicate attacker may have read and then exfiltrated or used the account for fraud.

6. Validate Exfil Path

Check the client protocol used by the session. If the client is REST API, bulk sync or legacy protocol, that may indicate the attacker is exfiltrating rather than simply reading.
If MailItemsAccessed shows items accessed using a legacy IMAP/POP or ActiveSync session — that is a red flag for mass download.

Phase 3 — Analysis & Scoping

Once raw data is collected, move into analysis to scope the incident.

1. Establish Attack Session Timeline

Combine sign-in logs (from Microsoft Entra ID Sign‑in Logs) with MailItemsAccessed events to reconstruct dwell time and sequence.
Determine when attacker first gained access, how long they stayed, and when they left.

2. Define Affected Items

Deliver an itemised summary (folder path, count of items, timestamps) of mailbox items accessed.
Limit exposure claims to the items you have logged evidence for — do not assume access of the entire mailbox unless logs show it (or you have other forensic evidence).

3. Corroborate with Throttling and Send Events

If you see unusual high-volume access plus spike in Send events or inbox rule changes, you can conclude automated or bulk access occurred.
Document IOCs (client IPs, session IDs, user-agent strings) tied to the malicious session.

Phase 4 — Reporting & Validation

After investigation you report findings and validate control-gaps.

1. Evidence Summary

Your report should document:

Tenant license type and retention (Audit Standard vs Premium)
Audit coverage verification (mailbox auditing enabled, MailItemsAccessed present)
Affected item count, folder paths, session data (IPs, protocol, timeframe)
Indicators of compromise (IOCs) and signs of mass or scripted access

2. Limitations

Be transparent about limitations:

Upgrading to Audit Premium mid-incident will not backfill missing MailItemsAccessed data for the earlier period. Sources note this gap.
If mailbox auditing or default audit-sets were customised (and MailItemsAccessed omitted), you may lack full visibility. Example commentary notes this risk.

3. Recommendations

Maintain Audit Premium licensing for at-risk tenants (e.g., high-value executive mailboxes or those handling sensitive data).
Pre-stage KQL dashboards to detect anomalies (e.g., bursts of MailItemsAccessed, high counts per hour or per day) so you don’t rely solely on ad-hoc searches.
Include audit-configuration verification (licensing, mail-audit audit-set, retention) in your regular vCISO or governance audit cadence.

KQL Example Snippets

MITRE ATT&CK Mapping

Tactic	Technique	ID
Collection	Email Collection	T1114.002
Exfiltration	Exfiltration Over Web Services	T1567.002
Discovery	Cloud Service Discovery	T1087.004
Defense Evasion	Valid Accounts (Cloud)	T1078.004

These mappings illustrate how MailItemsAccessed visibility ties directly into attacker-behaviour frameworks in cloud email contexts.

Minimal Control Checklist

Verify Purview Audit plan and retention
Validate MailItemsAccessed events present/searchable for a sample of users
Ensure mailbox auditing defaults (default audit-set) restored and active
Pre-stage anomaly detection queries / dashboards for mailbox-access bursts

Conclusion

When investigating a BEC incident, possession of high-fidelity audit data like MailItemsAccessed transforms your investigation from guesswork into evidence-driven clarity. The key is readiness: licence appropriately, validate your coverage, establish baselines, and when a breach occurs follow a structured workflow from extraction to scoping to reporting. Without that groundwork your post-incident forensics may hit blind spots. But with it you increase your odds of confidently quantifying exposure, attributing access and closing the loop.

Prepare, detect, dissect—repeatably.

References

Microsoft Learn: Manage mailbox auditing – “Mailbox audit logging is turned on by default in all organizations.”
Microsoft Learn: Use MailItemsAccessed to investigate compromised accounts – “The MailItemsAccessed action … is enabled by default for users that are assigned an Office 365 E3/E5 or Microsoft 365 E3/E5 license.”
Microsoft Learn: Auditing solutions in Microsoft Purview – licensing and search prerequisites.
Office365ITPros: Enable MailItemsAccessed event for Exchange Online – “Purview Audit Premium is included in Office 365 E5 and … Audit (Standard) is available to E3 customers.”
TrustedSec blog: MailItemsAccessed woes – “According to Microsoft, this event is only accessible if you have the Microsoft Purview Audit (Premium) functionality.”
Practical365: Microsoft’s slow delivery of MailItemsAccessed audit event – retention commentary.
O365Info: Manage audit log retention policies – up to 10 years for Premium.
Office365ITPros: Mailbox audit event ingestion issues for E3 users.
RedCanary blog: Entra ID service principals and BEC – “MailItemsAccessed is a very high volume record …”

* AI tools were used as a research assistant for this content, but human moderation and writing are also included. The included images are AI-generated.

Distracted Minds, Not Sophisticated Cyber Threats — Why Human Factors Now Reign Supreme

Posted on August 25, 2025 by Brent Huston

Problem Statement: In cybersecurity, we’ve long feared the specter of advanced malware and AI-enabled attacks. Yet today’s frontline is far more mundane—and far more human. Distraction, fatigue, and lack of awareness among employees now outweigh technical threats as the root cause of security incidents.

A woman standing in a room lit by bright fluorescent lights surrounded by whiteboards and sticky notes filled with ideas sketching out concepts and plans 5728491

A KnowBe4 study released in August 2025 sets off alarm bells: 43 % of security incidents stem from employee distraction—while only 17 % involve sophisticated attacks.

1. Distraction vs. Technical Threats — A Face-off

The numbers are telling:

Distraction: 43 %
Lack of awareness training: 41 %
Fatigue or burnout: 31 %
Pressure to act quickly: 33 %
Sophisticated attack (the myths we fear): just 17 %

What explains the gap between perceived threat and actual risk? The answer lies in human bandwidth—our cognitive load, overload, and vulnerability under distraction. Cyber risk is no longer about perimeter defense—it’s about human cognitive limits.

Meanwhile, phishing remains the dominant attack vector—74 % of incidents—often via impersonation of executives or trusted colleagues.

2. Reviving Security Culture: Avoid “Engagement Fatigue”

Many organizations rely on awareness training and phishing simulations, but repetition without innovation breeds fatigue.

Here’s how to refresh your security culture:

Contextualized, role-based training – tailor scenarios to daily workflows (e.g., finance staff vs. HR) so the relevance isn’t lost.
Micro-learning and practice nudges – short, timely prompts that reinforce good security behavior (e.g., reminders before onboarding tasks or during common high-risk activities).
Leadership modeling – when leadership visibly practices security—verifying emails, using MFA—it normalizes behavior across the organization.
Peer discussions and storytelling – real incident debriefs (anonymized, of course) often land harder than scripted scenarios.

Behavioral analytics can drive these nudges. For example: detect when sensitive emails are opened, when copy-paste occurs from external sources, or when MFA overrides happen unusually. Then trigger a gentle “Did you mean to do this?” prompt.

3. Emerging Risk: AI-Generated Social Engineering

Though only about 11 % of respondents have encountered AI threats so far, 60 % fear AI-generated phishing and deepfakes in the near future.

This fear is well-placed. A deepfake voice or video “CEO” request is far more convincing—and dangerous.

Preparedness strategies include:

Red teaming AI threats — simulate deepfake or AI-generated social engineering in safe environments.
Multi-factor and human challenge points — require confirmations via secondary channels (e.g., “Call the sender” rule).
Employee resilience training — teach detection cues (synthetic audio artifacts, uncanny timing, off-script wording).
AI citizenship policies — proactively define what’s allowed in internal tools, communication, and collaboration platforms.

4. The Confidence Paradox

Nearly 90 % of security leaders feel confident in their cyber-resilience—yet the data tells us otherwise.

Overconfidence can blind us: we might under-invest in human risk management while trusting tech to cover all our bases.

5. A Blueprint for Human-Centric Defense

Problem	Actionable Solution
Engagement fatigue with awareness training	Use micro-learning, role-based scenarios, and frequent but brief content
Lack of behavior change	Employ real-time nudges and behavioral analytics to catch risky actions before harm
Distraction, fatigue	Promote wellness, reduce task overload, implement focus-support scheduling
AI-driven social engineering	Test with red teams, enforce cross-channel verification, build detection literacy
Overconfidence	Benchmark human risk metrics (click rates, incident reports); tie performance to behavior outcomes

Final Thoughts

At its heart, cybersecurity remains a human endeavor. We chase the perfect firewall, but our biggest vulnerabilities lie in our own cognitive gaps. The KnowBe4 study shows that distraction—not hacker sophistication—is the dominant risk in 2025. It’s time to adapt.

We must refresh how we engage our people—not just with better tools, but with better empathy, smarter training design, and the foresight to counter AI-powered con games.

This is the human-centered security shift Brent Huston has championed. Let’s own it.

Help and More Information

If your organization is struggling to combat distraction, engagement fatigue, or the evolving risk of AI-powered social engineering, MicroSolved can help.

Our team specializes in behavioral analytics, adaptive awareness programs, and human-focused red teaming. Let’s build a more resilient, human-aware security culture—together.

👉 Reach out to MicroSolved today to schedule a consultation or request more information. (info@microsolved.com or +1.614.351.1237)

References

KnowBe4. Infosecurity Europe 2025: Human Error & Cognitive Risk Findings. knowbe4.com
ITPro. Employee distraction is now your biggest cybersecurity risk. itpro.com
Sprinto. Trends in 2025 Cybersecurity Culture and Controls.
Deloitte Insights. Behavioral Nudges in Security Awareness Programs.
Axios & Wikipedia. AI-Generated Deepfakes and Psychological Manipulation Trends.
TechRadar. The Growing Threat of AI in Phishing & Vishing.
MSI :: State of Security. Human Behavior Modeling in Red Teaming Environments.

* AI tools were used as a research assistant for this content, but human moderation and writing are also included. The included images are AI-generated.

The New Golden Hour in Ransomware Defense

Posted on August 19, 2025 by Brent Huston

Organizations today face a dire reality: ransomware campaigns—often orchestrated as Ransomware‑as‑a‑Service (RaaS)—are engineered for speed. Leveraging automation and affiliate models, attackers breach, spread, and encrypt entire networks in well under 60 minutes. The traditional incident response window has all but vanished.

This shrinking breach-to-impact interval—what we now call the ransomware golden hour—demands a dramatic reframing of how security teams think, plan, and respond.

Why It Matters

Attackers now move faster than ever. A rising number of campaigns are orchestrated through RaaS platforms, democratizing highly sophisticated tools and lowering the technical barrier for attackers^[1]. When speed is baked into the attack lifecycle, traditional defense mechanisms struggle to keep pace.

Analysts warn that these hyper‑automated intrusions are leaving security teams in a race against time—with breach response windows shrinking inexorably, and full network encryption occurring in under an hour^[2].

The Implications

Delayed detection equals catastrophic failure. Every second counts: if detection slips beyond the first minute, containment may already be too late.
Manual response no longer cuts it. Threat hunting, playbook activation, and triage require automation and proactive orchestration.
Preparedness becomes survival. Only by rehearsing and refining the first 60 minutes can teams hope to blunt the attack’s impact.

What Automation Can—and Can’t—Do

What It Can Do

Accelerate detection with AI‑powered anomaly detection and behavior analysis.
Trigger automatic containment via EDR/XDR systems.
Enforce execution of playbooks with automation^[3].

What It Can’t Do

Replace human judgment.
Compensate for lack of preparation.
Eliminate all dwell time.

Elements SOCs Must Pre‑Build for “First 60 Minutes” Response

Clear detection triggers and alert criteria.
Pre‑defined milestone checkpoints:
- T+0 to T+15: Detection and immediate isolation.
- T+15 to T+30: Network-wide containment.
- T+30 to T+45: Damage assessment.
- T+45 to T+60: Launch recovery protocols^[4].
Automated containment workflows^[5].
Clean, tested backups^[6].
Chain-of-command communication plans^[7].
Simulations and playbook rehearsals^[8].

When Speed Makes the Difference: Real‑World Flash Points

Only 17% of enterprises paid ransoms in 2025. Rapid containment was key^[6].
Disrupted ransomware gangs quickly rebrand and return^[9].
St. Paul cyberattack: swift containment, no ransom paid^[10].

Conclusion: Speed Is the New Defense

Ransomware has evolved into an operational race—powered by automation, fortified by crime‑as‑a‑service economics, and executed at breakneck pace. In this world, the golden hour isn’t a theory—it’s a mandate.

Design and rehearse a first‑60‑minute response playbook.
Automate containment while aligning with legal, PR, and executive workflows.
Ensure backups are clean and recovery-ready.
Stay agile—because attackers aren’t stuck on yesterday’s playbook.

References

* AI tools were used as a research assistant for this content, but human moderation and writing are also included. The included images are AI-generated.