# The Alert Queue Needs Authority, Not More Noise

> CISA used similar red-team methods against two critical-infrastructure organisations. One security team acted within minutes while another lost the real warnings among routine noise.

- **Author:** Kubilay Tunca
- **Published:** 2026-08-31
- **Category:** For Developers
- **Tags:** Incident Response, Cloud Security, Identity Security, Security Operations
- **Canonical URL:** https://cyber-security-in-plain-english.com/post/developers/news/alert-queue-needs-authority

---

Three people clicked a hostile link. The security team isolated their computers in 10, 2, and 20 minutes. Each alert was only medium severity, but an analyst read it, understood it, and had permission to act.

At another organisation, a similar exercise generated alerts too. Those warnings sank beneath thousands of false positives, while separate security teams and system owners struggled to identify who could make a decision. The testers eventually reached business systems, cloud resources, and even the security team's own messages without an effective response.

Those two outcomes appear in [CISA's 25 August 2026 report on simultaneous red-team assessments](https://www.cisa.gov/news-events/cybersecurity-advisories/aa26-237a). Both organisations had security products. Both contained serious identity and configuration weaknesses. The useful difference was much less glamorous: one team could recognise an unusual event and close a door before discussing it to death.

This matters far beyond a security operations centre. Developers build the services that emit alerts. Platform teams decide where logs travel. Identity teams decide how much authority an application receives. Managers decide whether an analyst may isolate a host at 2 a.m. The alert queue is the point where all those choices become visible, usually during the worst possible hour.

## What CISA Actually Tested

CISA published "A Tale of Two SOCs" on 25 August 2026 after running red-team assessments at two critical-infrastructure organisations at the same time. A red team behaves like an intruder under agreed rules so that the organisation can test detection and response without waiting for a real breach. CISA identified one participant as a government services and facilities organisation, called Organisation A, and the other as a water and wastewater organisation, called Organisation B.

The report says the testers used similar methods in both environments. They sought an initial foothold, mapped the Windows domain, raised their privileges, moved toward sensitive business systems, and tested routes into cloud services. CISA says the team achieved full domain compromise in both assessments and accessed sensitive systems and cloud resources, although Organisation B's early detection forced the exercise into an "assume breach" phase with a supplied internal foothold rather than an undetected live foothold.

That distinction deserves care. [The Hacker News also reported on 26 August](https://thehackernews.com/2026/08/cisa-red-team-compromised-two-critical.html) that both domains were compromised, but a headline can flatten the exercise design. Organisation B's analysts removed the original access. Trusted staff then placed the red team on an internal host so CISA could continue testing what would happen after an attacker got inside. The later domain compromise shows that dangerous internal paths existed. It does not erase the fact that the live response had already broken the attacker's first connection.

Organisation A offered the opposite lesson. CISA found a web application whose built-in accounts still used default credentials. The red team used an internal email address from that application to send phishing messages and gained access to four workstations. From there, certificate and machine-account settings in Active Directory helped the testers gain wider authority.

The technical chain continued through credentials stored in files, powerful endpoint-management infrastructure, and applications with broad cloud permissions. The testers reached three sensitive business systems. They found static Amazon Web Services credentials configured without expiry, added a secret to a Microsoft Entra application, and used its permissions to read security staff email. [Security Affairs independently summarised the same contrast on 26 August](https://securityaffairs.com/197901/hacking/cisa-red-team-fully-compromised-two-critical-infrastructure-orgs.html): one team isolated systems quickly, while the other failed to detect the developing compromise.

CISA did not present a contest between a weak organisation and a flawless one. Organisation B also had cleartext credentials, excessive directory permissions, service accounts without multifactor authentication, and an application able to read, write, and send email for every user. The report's value comes from that uncomfortable symmetry. Prevention weaknesses existed on both sides, yet detection and containment still changed what happened in the live portion of the test.

## A Medium Alert Can Carry a Major Decision

Security tools assign severity because queues need sorting. The label helps, but it cannot know the full meaning of an event inside your organisation. A process loading an unexpected software library might be harmless on one machine and the first visible sign of remote control on another.

At Organisation B, each hostile payload caused the same medium-severity alert: an executable had loaded an unexpected DLL file. Staff did not wait for a red banner marked critical. They investigated and manually isolated all three workstations. CISA recorded response times of 10 minutes, 2 minutes, and 20 minutes, which severed the red team's command channel.

The lesson is easy to state and hard to install: severity ranks evidence, while context decides action. A medium alert on a receptionist's laptop immediately after an unusual email can deserve faster attention than a recurring high alert from a noisy administrative tool. Teams that treat the vendor's score as a complete decision have outsourced knowledge of their own environment to a generic rule.

Organisation A's tools also noticed pieces of the activity. CISA says the security team received medium and low alerts connected to the exercise. Thousands of false positives from ordinary business operations, some carrying higher severity, obscured them. The queue technically contained the truth. Operationally, the truth was unavailable.

Imagine a smoke alarm that sounds every time someone makes toast. The alarm still works in a laboratory sense. After the fiftieth interruption, the household learns to wait for visible smoke. Security queues create the same conditioning when routine administration, known scanners, deployment tools, and harmless policy exceptions keep producing unactionable warnings.

Buying another detection product can make this worse. Each new sensor adds observations, and its default rules arrive without a working model of your normal business. Unless somebody owns tuning, suppression, and retirement, more coverage becomes more competition for the same human attention. The expensive product produces a cheaper queue.

Alert quality therefore belongs on an engineering backlog. A noisy rule needs a named owner, sample cases, a known response, and a review date. If nobody can explain what an analyst should do when the rule fires, the rule is unfinished work. Leaving it active does not create coverage. It creates camouflage for the next real event.

## The Queue Failed Before the Phishing Email Arrived

Organisation A's missed response was not one analyst making one bad choice. CISA describes multiple security operations centres, multiple endpoint tools, limited shared visibility, weak communication with system owners, and no dependable escalation procedure. Those conditions existed before the exercise began.

One episode in the report captures the failure. Analysts saw an alert involving a System Center Configuration Manager server, a system with broad reach across managed computers. They tried to identify its owner and normal purpose but could not. The team eventually marked the alert as a false positive. The absence of ownership became evidence of safety.

That reversal happens in many companies. An unfamiliar service appears in a log, nobody in the incident channel recognises it, and the investigation stalls because the security team cannot assess business impact. A developer assumes the platform team owns it. The platform team remembers a migration project. The service owner left six months ago. Silence slowly turns into permission to close the ticket.

The correct default for an unidentified powerful system is closer scrutiny, paired with a fast route to the person who can explain it. That requires an inventory tied to people rather than a spreadsheet full of hostnames. For each high-authority service, responders need an owner, an on-call contact, the expected administrative pattern, its reachable systems, and the safe containment options.

Authority matters just as much as knowledge. CISA says Organisation A's analysts lacked clear procedures for escalation and had limited authority, so staff drifted toward a "wait and see" response. Organisation B empowered staff to quarantine affected computers. A two-minute response is possible only when the approval has been designed before the incident.

Containment authority should have limits, of course. An analyst should not casually stop a life-safety system because one signal looks odd. The answer is a pre-agreed decision table. A user workstation can usually be isolated immediately. A production database may need an incident commander and service owner on the same call. An operational-technology jump server needs a tested route that accounts for physical operations.

This is ordinary interface design applied to people. Inputs arrive from tools. Decisions depend on context. Actions have side effects. A procedure should define the permitted transitions before stress, incomplete information, and executive attention arrive together.

## The First Containment Was Valuable, but Incomplete

Organisation B gives us a strong response example without offering a comfortable ending. Its analysts removed the three live footholds, then later detected and isolated activity on a bastion host near the operational-technology network. An outbound network block prevented the red-team payload on that host from calling home. Microsoft also generated an alert when a synchronisation account logged into the Azure portal, and staff blocked the suspicious activity.

Those controls worked. Yet the assume-breach portion exposed several paths that would matter after a different initial intrusion. A service account had extensive rights over almost 1,000 domain accounts and a domain controller. Credentials appeared in clear text. The testers found a route from the company directory into cloud identity and encountered applications with excessive email permissions.

Detection bought time; architecture decided how much damage that time could prevent. If every internal identity can reach a wide set of systems, one missed signal still carries a large consequence. If network boundaries, short-lived credentials, narrow application permissions, and outbound controls restrict movement, a delayed response has fewer fires to contain.

This is why a successful alert should create two workstreams. The incident team contains the immediate event and investigates scope. The engineering team removes the path that made the event dangerous. Reimaging a laptop is sensible, but the same service-account permission, plaintext credential, or application secret can remain available to the next route in.

The report also shows why teams must rehearse a cloud eviction, not just an endpoint rebuild. Access tokens and refresh tokens can keep cloud sessions alive after an on-premises password changes. Application identities may authenticate without a person present. CISA found that both organisations lacked mature procedures for revoking compromised cloud tokens.

A responder who isolates a laptop may feel the incident contract around one device. Meanwhile, a copied token can still open mail or files from somewhere else. The old mental picture, an attacker living on a box, no longer describes the whole problem. Modern incidents often live across devices, directory identities, application identities, sessions, secrets, and network routes.

The containment checklist has to follow that shape. Ask which identities were present, which tokens they could mint, which applications they owned, which secrets were readable, and which destinations accepted those credentials. Then revoke and rebuild trust in that order. Closing one process on one computer is only the visible start.

## Cloud Applications Are Identities With Hands

Most employees know that an administrator account is powerful. Application identities receive less scrutiny because they do not have a face, inbox signature, or manager. They still read files, send messages, change settings, and create credentials according to the permissions assigned to them.

In Organisation A, the red team targeted Microsoft Entra applications with elevated application permissions. These permissions let software act without a user approving each request. After compromising an application owner, the testers added a client secret and requested an access token as the application. CISA says they used that authority to read target email, including messages that revealed whether the security team had noticed the exercise.

Organisation B contained several visible events but shared the cloud-permission problem. The testers found an application that could read, write, and send email for every user. Its owner was a disabled directory account, which sounds reassuring until one part of the environment can enable that account again. The assessment used that path to add an application secret and gain broad email access.

A disabled human login and a live application permission are different controls. Teams often review the employee account while leaving software authority attached to old owners, old projects, and old integrations. The result is a ghost org chart inside the identity platform: applications still work, but no current team can explain why they need their full reach.

Treat each application identity like a production service account with a budget. Its budget is the data it may read, the actions it may take, the networks it may use, and the lifetime of its credentials. Any increase should pass review. Any unused permission should expire. An application that needs to send one class of notification should not quietly inherit the ability to read every mailbox.

CISA recommends conditional-access policies for workload identities, monitoring for unusual application behaviour, shorter credential lifetimes, and regular permission reviews. Those are useful controls, but the operating model comes first. Someone must own every application identity. That owner needs a recurring review and an incident contact. An orphaned integration should lose authority before it becomes an emergency archaeology project.

The same principle applies outside Microsoft products. AWS access keys, GitHub applications, continuous-integration tokens, Kubernetes service accounts, and API clients all represent software authority. Product names change. The question stays stable: what can this non-human identity cause, and how quickly can we stop it?

## What Developers and Platform Teams Own

Security operations cannot tune a queue alone. The alerts depend on telemetry emitted by applications, identity systems, build platforms, endpoints, and cloud services. Developers decide whether a sensitive action produces a useful record or a vague line that says "request failed."

A good security event answers several concrete questions. Which identity acted? What object changed? Which source device or workload made the request? What was the old state? What became the new state? Which request or trace identifier connects this event to the rest of the system? Without those fields, an analyst spends the first minutes reconstructing facts the application already knew.

Do not solve this by logging every input. Excess detail can expose secrets and generate more noise. Capture decision-grade facts. A password-reset event needs the account, method, outcome, source context, and correlation identifier. It should not contain the password, full recovery token, or a dumped request body.

Platform teams own another part of the path. Logs must arrive quickly enough to support the response, use consistent time, preserve identity context, and survive the compromise of the system that produced them. An alert about a cloud application is much stronger when the analyst can move from application ID to owner, recent permission changes, new secrets, sign-in history, and outbound destinations without opening six consoles and three access tickets.

Service ownership is also security telemetry. Put the owner, repository, deployment environment, data class, and on-call route in a catalogue that responders can query. Keep it current through deployment metadata rather than a yearly spreadsheet campaign. When an alert names an unfamiliar system, the security team should find a human and an approved containment action in seconds.

Developers also need to test the response side of a new alert. Create a harmless simulation, verify the expected event appears, and watch where it goes. Does the queue deduplicate it? Does enrichment find the right owner? Can an analyst distinguish the test from normal administration? Does the runbook point to an action that still works?

This resembles a production readiness review because it is one. Monitoring that has never reached a person under realistic conditions is an assumption. A runbook that depends on revoked permissions is historical fiction. An isolation command that breaks the wrong dependency can turn a contained incident into an outage.

The Secure Harness focuses on coding agents, but its central model applies here too: capability needs a boundary, evidence, and a stop control. A security tool without a usable response path has evidence without a stop control. A powerful application identity without narrow permissions has capability without a boundary. Both fail at the handoff.

## A Practical Test for the Next Thirty Days

You do not need a full red-team engagement to learn whether your queue can support a decision. Start with one important, plausible event and follow it from generation to containment. Choose something your organisation already claims it can detect, such as an unusual application-secret creation, a new privileged group member, or a suspicious process on a standard workstation.

The sequence below is deliberately small. Its purpose is to expose broken ownership and authority while the test is harmless. Run it with the relevant service owners and incident responders present, then keep the evidence as engineering work rather than a presentation score.

1. **Generate one safe event.** Use an approved test identity and a documented simulation that cannot affect customers. Record the exact time, asset, identity, and expected signal before you begin.

2. **Measure arrival and recognition.** Note when the raw event appears, when the alert enters the queue, and when a person identifies it as requiring action. Separate transport delay from human queue delay, since they need different fixes.

3. **Ask for the owner.** Give the responder only what a real alert would contain. Can they identify the system owner, business purpose, expected behaviour, and reachable services without relying on personal memory?

4. **Attempt the approved containment.** The responder should use the actual tool and authority available during an incident. Record access failures, approval waits, technical errors, and uncertainty about side effects.

5. **Follow the identity into the cloud.** Check active sessions, refresh tokens, application secrets, owned integrations, and recent permission changes. Verify that the team can revoke access without guessing which console contains the control.

6. **Review what remained trusted.** After containment, ask whether copied credentials, other hosts, scheduled jobs, cloud applications, or deployment systems could preserve access. This turns a device response into an incident-scope decision.

7. **Retire noise while the evidence is fresh.** Examine the alerts that surrounded the test. Suppress known-safe duplicates, improve context, or remove rules that have no response. Assign every change an owner and a deadline.

8. **Repeat without the test team in the room.** A second shift should run the same scenario from the queue and runbook. If success depends on the author explaining the procedure, the procedure has not shipped.

Measure a few useful outcomes: time to first human review, time to correct owner, time to containment, number of access handoffs, and whether cloud sessions were revoked. Avoid turning the exercise into a leaderboard. The aim is to find delay built into the system, then remove it.

One exercise will usually produce a modest list of repairs. Perhaps the alert needs the application owner attached. Perhaps the responder role cannot isolate a workstation. Perhaps an integration still uses a static key. Fix those items, rerun the same scenario, and only then add a second one.

A giant catalogue of untested playbooks creates the same false comfort as a giant queue of untuned alerts. Depth on a small number of consequential scenarios beats decorative coverage. Build the muscle where your systems hold the most authority.

## Better Security Is a Shorter Distance to Action

CISA's two assessments resist a simple hero story. Organisation B's analysts acted well, yet the environment still contained dangerous identity paths. Organisation A had sensors, yet the organisation around those sensors could not turn warnings into containment. Both needed architecture work. Only one demonstrated that a live signal could become a timely decision.

That difference is measurable. Count the minutes between an event and a person understanding it. Count the handoffs before somebody may isolate a host. Count the consoles needed to revoke a cloud identity. Count the alerts that have no owner or response. Those numbers describe security more honestly than the number of products in the stack.

The practical position is clear: stop treating alert volume as evidence of coverage. Tune aggressively. Remove rules that nobody can act on. Attach service ownership and business context before an incident. Give responders bounded authority, rehearse the action, and make cloud identity part of every serious containment.

An alert earns its place in the queue when it helps a person decide. Everything else spends attention that a real incident may soon need.

If you want one calm, practical security email per month, the signup is on this site.

## Sources

- [CISA: A Tale of Two SOCs: Insights From Two Red Team Assessments](https://www.cisa.gov/news-events/cybersecurity-advisories/aa26-237a), accessed 2026-08-31
- [CISA: AA26-237A advisory PDF](https://www.cisa.gov/sites/default/files/2026-08/aa26-237a-tale-of-two-SOCs-insights-two-red-team-assessments-508c.pdf), accessed 2026-08-31
- [The Hacker News: CISA Red Team Compromised Two Critical Infrastructure Orgs, One Detected Nothing](https://thehackernews.com/2026/08/cisa-red-team-compromised-two-critical.html), accessed 2026-08-31
- [Security Affairs: CISA Red Team Fully Compromised Two Critical Infrastructure Orgs](https://securityaffairs.com/197901/hacking/cisa-red-team-fully-compromised-two-critical-infrastructure-orgs.html), accessed 2026-08-31

---

## About the author

Kubilay Tunca — Senior Full Stack Developer and Author. Founded Cyber Security in Plain English to translate complex security concepts into clear, practical advice, and writes the accompanying books on security, privacy, secure development, and AI systems.

## Books by this author

- **The Digital Fortress** — Your Everyday Guide to a Safer Digital Life. A warm, plain-English guide for people with real lives and finite patience. Learn the handful of habits that genuinely protect your money, accounts, and family, and get honest permission to ignore the rest. [Amazon](https://buy.cyber-security-in-plain-english.com/digital-fortress) · [Details](https://cyber-security-in-plain-english.com/books/the-digital-fortress)
- **The Anonymity Playbook** — Digital Survival for Whistleblowers, Journalists, Activists, and Everyone Else. A practitioner’s field manual for journalists protecting sources, whistleblowers, and activists. It explains how the surveillance actually works, what each technique costs you, and exactly where it fails. [Amazon](https://buy.cyber-security-in-plain-english.com/anonymity-playbook) · [Details](https://cyber-security-in-plain-english.com/books/the-anonymity-playbook)
- **Secure Software Development** — Practical patterns for building secure software. A hands-on security guide for developers and IT professionals who ship real software. Build, deploy, and maintain secure systems without slowing down or drowning in theory. [Amazon](https://buy.cyber-security-in-plain-english.com/secure-software-development) · [Details](https://cyber-security-in-plain-english.com/books/secure-software-development)
- **The Secure Harness** — Shipping Production Code with AI Coding Agents. A calm, practical guide to letting agents do useful work inside boundaries you set, enforce, and audit. Ships with 15 copy-pasteable artifacts: hook scripts, permission configs, release gates, and MCP templates. [Amazon](https://buy.cyber-security-in-plain-english.com/secure-harness) · [Details](https://cyber-security-in-plain-english.com/books/the-secure-harness)
- **The AI Native Engineer** — Build, Evaluate, and Ship AI Systems That Work in Production. Sixteen hands-on chapters, one real product. Grow it from a single model call into a retrieved, tool-using, observable, production-grade system, with evaluation treated as a habit from the first feature. [Amazon](https://buy.cyber-security-in-plain-english.com/ai-native-engineer) · [Details](https://cyber-security-in-plain-english.com/books/the-ai-native-engineer)

Full catalogue with contents and intended audience: https://cyber-security-in-plain-english.com/books

_As an Amazon Associate I earn from qualifying purchases. Buying through these links costs you nothing extra and helps pay for the blog._