Incident response

Automate every step except the one with consequences.

ARRTECH SOAR and ARRTECH SIEM

Much of an incident is repetitive: indicators extracted, reputations checked, an owner assigned, then the same steps again on the next alert. ARRTECH SOAR runs the repetition, holds at the decision for a named person, and records the choice. NIST SP 800-61 Rev. 3 asks that lessons learned from every function feed Improvement, and that record is where this page ends.

Incidents

ARRTECH SOAR detects nothing on its own. It opens an incident from four routes, and each incident carries a severity, a priority and an owner, a named person or an automation.

This page covers NIST’s Detect and Respond functions only. Recover is your backup and restore plan, which neither product supplies.

SIEM alert

An ARRTECH SIEM alert action creates the incident or runs an automation directly. The alert limiter and group columns suppress duplicates, so one attack does not open many incidents, and every alert keeps a one-click pivot to the search that fired it.

Mailbox

A monitored IMAP or Exchange mailbox, filtered by folder, sender and domain, turns reported mail into incidents.

API

A REST API call from any tool that can make one.

Analyst

An analyst enters the incident in the console.

Indicators

An analyst who reads raw fields spends the first minutes of every incident on the same lookups.

IPs, hashes and other indicators are extracted from incident fields automatically, using artifact-type mappings you configure, including your own types. The Artifact Analyzer grades each one Good, Suspicious or Bad, and the reputation updates as playbooks work. The analyst reads verdicts, not raw fields.

Playbooks

Workflows define the process and call playbooks; playbooks take the actions through integration nodes over each tool's API, mainly REST. A tool without an API is reached by a Python script. Standard nodes cover decisions, filters, list lookups, mail and up to five parallel branches.

Simulate a playbook with sample data before it runs for real: action nodes are validated without executing and analysis nodes run, so testing is safe against live integrations. Each run is kept in an execution history with errors highlighted.

Response

The step that blocks a user, isolates a host or cuts a connection is the one that costs most when wrong, so it belongs to a named person.

An Operator node emails that person with up to five color-coded options and waits. Nothing below it runs until the reply arrives. An Operator Requests page lists every decision still pending, so approval is visible, assigned and recorded, not buried in a chat.

After the choice, the playbook updates the incident, reassigns it, creates a Jira ticket or creates a new incident, and continues. The history shows who chose which option and when.

Record

Afterwards, three questions remain: how long each step took, where it stalled, and who approved what.

ARRTECH SOAR's five predefined dashboards, including SLA and Playbooks, show response times and where runs stall. Reports export to PDF, Word, CSV and HTML on demand or on a schedule.

In ARRTECH SIEM, each case carries severity, assignee, expected finish time with reminder emails, SLA tracking and its MITRE ATT&CK tactic, plus sub-cases, history and a downloadable case report, next to the signed logs.

Evaluation

In the first meeting, you bring one recent incident. Together we map it onto the steps on this page, from the alert that opened it to the record it left, and end with which steps a playbook carries and which stay with a named person.

Schedule a meeting