Understanding SOAR Workflow
SOAR receives alerts from different sources. These alerts are processed to form cases. The newly created case are dispatched to SOCs. Most of the cases can be resolved automatically by executing associated playbooks, however, at times human interventions are needed for decision making.
Following figure presents a general workflow of ArcSight SOAR:
ESM Sending Alerts to SOAR
The ArcSight ESM forwards alerts and their respective correlated events to SOAR to identify, analyze and resolve a probable attack. To send alerts to SOAR, ESM must be integrated and configured as an alert source on the SOAR platform. SOAR receives alerts with rule names that were defined at the ESM. The rule names are used for alert classifications during case creation.
When an alert is created, the ArcSght ESM stores various base events that produced that alert. For example, if a Remote Port Scan Detected alert is created, the ESM will store a number of events, each with a separate log entry received from systems under attack or probe. SOAR gets these base events since they contain useful information (for example time of each event, attacker username and attacker remote address) through correlated events. These information are displayed on the case page, created and bound with the respective alert. The correlated events are also helpful during defining the scope items for the alert analysis.
Processing Alerts
After integrating with ESM, SOAR follows a set of procedures for alerts processing as follows:
Receiving Alerts through ArcSight Listener
After configuring ESM as an alert source, the ArcSight Listeners starts listening to the configured ports and get alert messages. These alert messages are usually brief including useful information, for example the type of alert, time of event, count of base events that produced the alert, and the severity of the alert. Context of the alert messages depends on the alert source and the rules configured.
Defining Action Plans by Rule Names
A rule name is configured as pre-processor rules in the ESM for tagging and forwarding the base events to SOAR. These rule decides the action plans for the alerts. Based on the directions imposed by rules an alert can be considered as a threat alert or a normal event.
Depending upon the conditions directed by rules, a label is added to the alerts. The labeling helps in selecting the appropriate playbook/s for the case handling and response.
Consolidating Alerts to form cases
Depending upon the configuration settings, different correlated alerts are consolidated to form cases. At this point, the ArcSight SOAR decides to consolidate alerts to form a new case or the respective alert can be added to a pre-existing case.
Dispatching cases
When a new case is created, a case severity is assigned to the case, based on the severity mapping of the alert source. After the severity assignment, the case is assigned to a user or a user group. The dispatching of the case is done by running case Dispatch Playbook. If the playbooks cannot find an assignee, SOAR leaves the case as unassigned. Running these playbooks may find more than one assignee, but SOAR only selects the first one.
Dispatch playbooks might also change case’s severity or add watchers or labels to the case.
Automating case Handling by Playbooks
After a case is created and dispatched, SOAR runs a playbook/s with matching conditions as defined during alert consolidation. All matching playbooks are executed sequentially and in their rank order. Higher rank playbooks are executed earlier.
Each executed playbook can run a number of enrichment operations and queue actions in an arbitrary order. Enrichments are synchronous, that is, playbook execution waits for their completion before continuing with the next operation.
Actions are always asynchronous. There is a separate queue of actions, manageable in the Action and Rollback Queue tab. Completed actions are moved from the queue to the Alerts tab of Status menu.
A completed action can be either automatically or manually rolled back, if the action’s capability supports rollback operation.
If playbook contains a case close element, SOAR automatically closes the case, otherwise, case remains open after all the tasks are completed.