This article is a part of a series describing the essential criteria of a Security Automation and Orchestration platform.
One of the most important functions of a Security Automation and Orchestration (SA&O) platform is to reduce the need to manually triage low priority and false positive alerts. Just after data ingestion, an alert management capability in an SA&O platform should queue and prioritize inbound alerts to help analysts perform triage more efficiently. Alert investigations might be performed manually, but ideally they are triaged automatically using automated actions, via playbooks, to yield the highest levels of operations productivity and accuracy.
When it becomes necessary for an analyst to review an incident, the alert management module should be built in a way that enables all aspects of a security alert to be rapidly consumed and efficiently acted upon. The interface should arrange information in a way that surfaces the right information at the right time, avoiding extensive searching or switching between contexts to gather all needed information.
The Phantom platform differentiates between alerts and incidents. In the Phantom model, alerts are triaged and, if warranted, escalated to an incident (i.e. a case in the Phantom platform). This model allows low-priority and false positives alerts to be eliminated before escalation, reducing the extensive procedural steps that are often prescribed for incidents or cases.
Below are some additional criteria to consider as you evaluate SA&O platforms.
The technical attributes of a security alert should be organized in a way that allows an analyst to quickly digest them to understand the security scenario. This includes an organized view of data like: IP addresses, domain names, file hashes, user names, email addresses, and all other relevant data fields. Use of a standard format such as Common Event Format (CEF) or an equivalent is highly beneficial for data exchange.
When investigating an alert, a security analyst should be able to issue manual actions to the platform that make use of the alert data. This includes investigative, containment, corrective, or generic actions. The interface should allow a user to execute an action by selecting the data to operate on. This behavior is sometimes called contextual action execution and enables pivoting analysis around newly discovered information.
Like manual action execution, an analyst should also be able to issue a collection of actions against an alert. This collection of actions is commonly referred to as a playbook.
When manual or automated actions are taken against an alert, the results should not only be viewable and make sense to an analyst, but also make sense to the SA&O platform. The platform should ideally be able to use action results to make an automated decision. Action results should be available in a summary format (e.g. table, custom view) as well as in a more comprehensive format (e.g. JSON).
The platform should provide a comprehensive activity log that displays a record of all actions that have executed against an alert, whether they were initiated manually or via an automation playbook. Each action should display its results, including an indicator of action success or failure, making it clear whether the action fully executed.
Alert Status, Severity, and Sensitivity
Every alert managed by the platform should include a status indicator (e.g. new, open, or closed), a severity indicator, and a sensitivity indicator (e.g. Traffic Light Protocol or TLP designations). Each indicator should be modifiable within the alert management interface, as well as from within a playbook.
The interface should provide an area where analysts can collaborate, comment, and provide miscellaneous information about an alert. It’s ideal for the record of this collaboration to be captured and organized along with all other alert data.