Use case · SOC automation
SOC automation that asks before it acts.
ThreatBreaker automates the repetitive half of incident response: matching each detection to a playbook, collecting evidence and preparing the containment. Anything destructive waits for one click from a person, unless you have chosen otherwise.
Four response modes. Approval by default. Every action on the record.
What a SOC can safely automate
Alert fatigue is rarely about detection; it is the same handful of steps repeated by hand on every alert. Most of those steps are safe to automate. A few are not, and should never run without a person.
Runs automatically
Nothing on the endpoint changes.
- Match the detection to a playbook
- Collect forensic evidence on a critical detection
- Build the incident timeline and MITRE ATT&CK mapping
- Alert the on-call team, forward to SIEM or a webhook
Proposed, waits for Approve
The default for anything that touches a host.
- Isolate the host from the network
- Kill the malicious process
- Block an external IP address
- Quarantine the file
Auto, only where you opt in
Per playbook, for threats you have seen before.
- A well-understood playbook a person has promoted
- Everything else keeps waiting for approval
Four response modes, chosen per playbook
Security playbook automation in ThreatBreaker matches each detection by severity, category, MITRE tactic and rule name, then applies the playbook's mode. Pick a mode to see what happens to the same incident.
Ransomware behaviour · FIN-WS-07 · Windows 11
Incident response automation, step by step
From the moment the agent reports a detection to the audit record, this is what runs and where a person comes in.
What the investigation step produces →- 01DetectThe agent reports a detection from the endpoint, online or offline.
- 02MatchEnabled playbooks are matched by severity, category, MITRE tactic and rule name.
- 03CollectOn a critical detection, evidence is collected without touching the host.
- 04ProposeThe response is prepared: isolate, kill, block or quarantine.
- 05Approve · youOne click from your analyst. Or Auto, if you opted in.
- 06ActThe action runs on the online agent. An offline agent is recorded as skipped.
- 07RecordEvery automated execution is logged on the server.
Guardrails that limit the blast radius
Automation is only useful if you can trust it at 2am. These rules are built into the engine, not left to playbook authors.
Playbooks ship disabled
Built-in playbooks do nothing until a person turns them on.
No silent failures
If the agent is offline, the action is recorded as skipped, never failed quietly.
No guessing at targets
Kill and block only fire when a concrete process ID or IP address resolves from the alert.
Internal networks are off limits
Blocking private, loopback and link-local addresses is refused, so a host is never cut off from its own infrastructure.
$ block 185.220.101.4Blocked
$ block 10.0.4.12Refused · private address
Notify-only means notify only
In Notify-only mode, isolate, kill and block are stripped out automatically.
Evidence first, hands off
On a critical detection the engine can collect forensic evidence without changing anything on the host.
Example: contain ransomware without pulling the plug
When ransomware activity trips the protection policy, ThreatBreaker restricts the host's network access instead of shutting it down. You can set a save-your-work countdown before isolation, on Windows, Linux and macOS. Attacker persistence is removed while the evidence stays available for the investigation.
Every automated action, on the record
Every automated execution is recorded on the server. AI and forensic decisions are also written to an append-only trail that stores a SHA-256 hash of each decision's input and output, so a reviewer can show later that a record has not been altered.
SOC automation questions
- What is SOC automation?
- SOC automation runs the repetitive steps of security operations without a person: matching alerts to playbooks, collecting evidence, notifying the team and, where allowed, containing a threat. ThreatBreaker keeps a person in the loop for anything destructive by default.
- What can a SOC safely automate?
- Steps that change nothing on the endpoint: evidence collection, timelines, MITRE ATT&CK mapping, notifications and forwarding. Isolation, process kills and IP blocks should wait for approval unless a playbook is well understood.
- What is the difference between automated and assisted response?
- Automated response acts on its own. Assisted response prepares the action and waits for a person to approve it. ThreatBreaker is assisted by default (Require-approval) and fully automated only for playbooks you promote to Auto.
- Can automation cut a host off from its own network by mistake?
- IP blocks on private, loopback and link-local addresses are refused, and kill or block actions only fire when a concrete process ID or IP address resolves from the alert.
- What happens if the endpoint is offline?
- The action is recorded as skipped, never failed silently, so your team sees exactly what did not run. Detection on the endpoint itself keeps working offline.
- Is ThreatBreaker a SOAR platform?
- No. It is not a general security automation platform; it is endpoint security with response automation built in, so playbooks act directly on your endpoints. It forwards incidents to your SIEM and other tools through webhooks.
- How does automation reduce mean time to respond?
- With incident response automation, the evidence is collected and the response already prepared by the time an analyst opens the incident, so responding is one decision and one click rather than a manual investigation.
- Can a quarantined file be restored?
- Yes. Quarantined files are encrypted on the host and an operator can restore one later. ThreatBreaker's response actions are containment: isolation, process kill, IP block and quarantine.
See a playbook run on a real incident.
A 30-minute walk through the console: the four modes, an approval, and the audit record it leaves behind.