Security Cases and Playbooks (SOAR)

Security Events turns what your detection rules, threat intelligence and connected security products find into cases: one case for each thing worth looking into, with every detection about the same user, host or address grouped into it. Analysts work the cases in a queue, and playbooks respond to them, by themselves or at a click.

How it works#

Open Products → Security Events → Security Cases → Open Cases for the queue. Assigned to Me, Unassigned, Closed Cases and All Cases are pages of their own beside it, each listing the cases its name says.

Before you begin#

Cases and playbooks follow the three Security roles. Project Owner and Project Admin can do everything.

Each of these can also be granted on its own, from creating a case to approving a playbook's steps; see Permission Reference.

Where cases come from#

Every source is on by default. A connection opens cases for High and above unless you choose another level; the alerts below it are still imported as events.

How detections are grouped#

A detection is about an entity: the value its rule groups by, such as the IP address of a brute-force rule, or the indicator a threat intelligence match names. A detection without one stands alone.

• When an open case is already about that entity, the detection joins it. The case's entities and ATT&CK mapping grow, and its priority rises to the detection's, never down.
• When no open case is, a new case opens, named after the detection, at the detection's priority.
• A detection that fires again counts up on its row instead of adding one.

A case's priority comes from the detection's severity:

Work a case#

A case moves through four statuses. It can skip one, such as a false positive closed straight from New, and it can be reopened.

The case's page has everything to work it:

• At the top: Assign to Me, Run Playbook, Declare Incident and Close Case, the status steps, and the priority under the menu beside them.
• Status200 AI: what Status200 AI made of the case, the priority and playbook it suggests, and the evidence behind them. See Status200 AI in Security.
• Detections: what fired to open the case or join it, how often, and the latest matching event.
• Entities: the users, hosts and addresses the case is about, with their activity across all your security events in the last 7 days. Each opens in Correlate.
• MITRE ATT&CK: the tactics and techniques its detections map to, each linked to its page on attack.mitre.org.
• Playbook Runs: what each playbook did on the case, step by step, and the steps waiting for approval.
• Notes and Timeline: what the team wrote, and everything that happened, with who did it.

To work several cases at once, select them in the queue and use Assign to Me, Change Status or Change Priority.

Close a case#

Close Case asks for a verdict and an optional closing note:

The verdicts are counted on the overview. A rule whose cases keep closing as False Positive is a rule to tune.

A case opened from Google SecOps alerts closes them in Google SecOps too, with the verdict and the closing note, when its connection has Close alerts when their case closes on: see Google SecOps.

Declare an incident#

Declare Incident opens a Status200 incident for the case, at the severity you choose, and links the two both ways: the incident's description names the case, and the case's header links to the incident. On-call, status pages and the postmortem take over from there. It takes a role that can both work cases and create incidents.

Notifications#

Status200 tells people about three things on a case. Nobody has to set anything up: a project that only clicked Turn on recommended hears about its High and Critical cases by email and push.

• Only people who can see the case are told about it: Project Owners, Project Admins, and the Security Admin, Security Member and Security Viewer roles. A role limited to some labels is told only about the cases with those labels.
• Nobody is told about what they did: the person who opens a case by hand, assigns it or starts a run is not notified of it.
• Each person hears about a case once. A case that opens at Medium and later rises to Critical reaches the people who chose High or Critical when it rises, and not again the people who chose Medium, who heard about it when it opened.
• The test attack from Send a test attack opens a case that notifies nobody.
• A Critical case and a step waiting for approval are sent at once, never held back in an email rollup.
• The case's Timeline says who was told, and when.

Choose what you are told#

Each person chooses for themselves, under User Settings → Notification Settings → Security: the channels for each notification (email, SMS, call, push, Telegram, Slack, Microsoft Teams or webhook), and under New security case, the priority that notifies them:

WhatsApp messages are not sent for security cases. A push notification opens the Status200 app, and its link opens the case in the browser.

Post to Slack and Microsoft Teams channels#

To post to a channel, add a rule under Products → Security Events → Workspace → Slack (or Microsoft Teams). With neither connected, the section's one entry is Connect Slack or Teams. A rule names the channels to post to (and, in Microsoft Teams, the chats) and, if you want, the cases it is for:

The three notifications are each posted to the channels of every rule the case matches at that moment. A rule with Security Case Priority contains any of Critical and High posts High and Critical cases as they open, and a Medium case when it rises to High. A security case never gets a channel of its own.

Playbooks#

A playbook is a list of steps that run on a case. Create one under Products → Security Events → Playbooks, from a template or blank, and add its steps on its page.

When a playbook runs#

Any enabled playbook can also be run by hand, with Run Playbook on a case. A playbook that runs by itself can be narrowed:

• For Cases At Least: only cases of this priority or higher.
• Only For Detections From: only when the detection behind the case came from this source.
• Only For These Detection Rules: only when it came from one of these rules.

A disabled playbook runs neither by itself nor by hand.

Steps#

A playbook has at most 25 steps. They run in order, each once the one before it is done. Every step can also:

• Needs Approval: stop the run before the step until someone approves it on the case. The four steps that cut someone off always do, unless a Security Admin turns it off.
• Only If Threat Intel Matched: skip the step unless an earlier Check entities against threat intel step of the run found a known indicator.
• Carry On If It Fails: run the next step even if this one fails. Off, a failed step stops the run.

Containment#

The Contain steps act through a security event connection to the product, which needs more than read access:

A Contain step acts only on the users or hosts the case is about, never on every one it names:

• The value a detection of the case is grouped on, such as the account an impossible-travel rule groups by, or the host a connected product's alert names.
• A user or host of the case that your threat intelligence knows as an indicator.

A case grouped on an address, such as a brute force against your VPN, is about neither: its Contain steps are skipped, and the account it tried and the gateway it hit are left alone. A step acts on at most 10 users or hosts. It finds each in the product by name, and says on the run what it did with each one: done, already done, not found, refused, or protected.

Protected entities#

Protected Entities, under Playbooks in the menu, lists the users and hosts no playbook contains, such as break-glass accounts, domain controllers and VPN gateways. A value matches whatever its case, and * stands for any run of characters: svc-* protects every service account. A step reports a protected user or host as protected and leaves it alone. Security Admins keep the list.

Approval#

The four steps that cut someone off wait for approval. Only a Security Admin can turn Needs Approval off for one, and Status200 records who did. The approval lists the users or hosts the step would act on under Act On, every one ticked: untick any it should leave alone. Protected ones are not offered. Whoever started a run cannot approve its steps: someone else does, though they can still reject it.

Undo#

The undo steps act on the users or hosts the case is about, like the steps they undo. Once the run has stopped, a contained user or host also has a button of its own on its step: Unsuspend, Lift Containment or Release. An ended Okta session cannot be undone. Every undo is kept on the case's timeline and in the project's audit log.

Messages#

A note, an email, a Slack post and a Teams post can use the case's values:

An email or a post with no message of its own sends a summary of the case.

Runs and approvals#

Every run is listed on its case and under Products → Security Events → Playbooks → Playbook Runs, step by step:

A step waiting for approval shows Approve and Reject on the run, with an optional comment. Approving carries the run on from that step; rejecting ends it. The decision, who made it and their comment are kept on the step, on the case's timeline and in the project's audit log. Waiting for Approval, under Playbooks in the menu, lists the runs held for a decision and counts them; Playbook Runs lists every run.

A run that stops hearing from its worker, after a restart for example, is picked up again: a queued run is queued again after 2 minutes, and a run that has said nothing for 30 minutes is failed.

The overview#

Products → Security Events → Overview is where the product opens:

• The open cases assigned to you, the open cases nobody has picked up, and the playbook steps waiting for approval, each opening the page that lists them.
• Mean Time to Acknowledge, Mean Time to Contain and Mean Time to Close, over the cases opened in the last 30 days: from a case opening to someone taking it on (assigning a person, or moving it out of New), to Contained, and to Closed. A case still waiting is not counted in a mean.
• The cases opened each day for 30 days, by priority, and the detections raised each day for 14 days, by source.
• The open cases by priority and by status, the verdicts of the last 30 days, the ATT&CK tactics behind the cases, the detections that fired most, and the entities named by the most findings.

Above them, a strip shows how Security is set up: its sources, detections, cases and playbooks, each with its figures. A project that has not set it up yet sees Turn on recommended and Send a test attack there; see Get Started with Security. When nothing needs anybody, the page says All quiet, and the charts show once there is something to chart.

Find threats#

• Entities ranks the users, hosts, addresses and hashes that your findings name most, over the last day, week or month, and looks any value up across 30 days of events.
• Rule Library has ready-made detection rules, for identity, endpoint, cloud, network, web and Kubernetes threats. Each is a Sigma rule written for the fields every connected source is normalized to. Add Rule creates it as a detection rule of yours, on, and opening cases rather than alerts; change it under Detection Rules like any other. The rules marked Recommended find threats in data Status200 already has, and one button adds the ones you do not have yet.
• ATT&CK Coverage draws the MITRE ATT&CK matrix with the techniques your enabled rules cover lit, and outlines the ones a library rule would cover.

Automate#

• Workflows: a case or a note can start a workflow when it is created, updated or deleted. A Run a workflow step starts a workflow whose trigger is a webhook.
• API: cases, notes, detections, playbooks, runs and protected entities have the same REST API as the rest of Status200, under /security-case, /security-case-note, /security-detection, /security-playbook, /security-playbook-run and /security-protected-entity. See API Reference.
• AI agents: the MCP server has tools for cases, notes, detections and playbooks. See MCP Server.

Troubleshooting#

Next steps#