Get Started with a One-to-One Personalized Demo
Dramatically reduce the mean time to detection, response and remediation of all potential security incidents, ensuring no alert goes untouched.
See IncMan SOAR in Action.
This use case will demonstrate how to use IncMan SOAR’s integrations and R3 Rapid Response Runbooks to quickly gather incident data from across diverse hybrid-cloud environments to provide incident responders with the evidence necessary to rapidly prioritize and respond to a potential incident.
The first step in creating an automated response to this type of event is to create an R3 Rapid Response Runbook within the IncMan SOAR platform which will perform Enrichment actions, as well as Containment actions if necessary. We will assume that the alert has provided the following information at minimum:
This R3 Runbook can be broken down into two main sections; information gathering and enrichment, and escalation and containment. Figure 1 below shows the entire Runbook from beginning to end. Next, we will discuss the actions contained in each subsection in additional detail.
This R3 Runbook begins by simultaneously gathering enrichment data from across the AWS cloud environment, the internal environment via the SIEM architecture, and from the internal endpoint solution. IncMan first queries AWS for all findings where the destination IP address has been observed within the last month. At the same time, the SIEM and endpoint solution is queried for internal activity towards the victim IP. Additional security events involving the user account, and the system settings which include running processes are also gathered for investigation.
After enriching the initial information, this R3 Runbook comes to a series of conditional statements which will dictate how the Runbook will finish its sequence. The first set of conditional statements looks for additional security alerts involving either the source of the incident, or the victim machine housed in the AWS cloud. The second conditional statement looks for additional security alerts involving the potentially compromised user account. Upon evaluation of these statements IncMan will begin to initiate additional actions based off their findings.
If the first conditional statement finds that additional alerts involving the source are found, IncMan will gather details on the system’s settings and its running processes. After this information is gathered, the R3 Runbook is paused and issues a User Choice action. A User Choice action is used when information is gathered that cannot be automatically verified and requires an analyst to review before continuing its execution.
Once the incident data is reviewed, the analysts will have to decide whether the data gathered presents enough evidence to determine whether an incident has occurred. If the evidence proves that further response efforts are necessary, the analysts will select to proceed and the R3 Runbook will upgrade the incident priority to high, quarantine the potentially infected internal host, and send an email notification to the response teams to let them know that a potential incident has occurred.
Simultaneously the second conditional statement is evaluated, and if there are additional security events revolving around the user’s account, the R3 Runbook executes an additional Runbook to disable the account and reset its password. This nested Runbook will gather user account details from Active Directory, execute a custom script to generate a random password, reset the user’s password, and send an email notification to the security team to inform them of the potentially compromised credentials.
Once the new R3 Runbook is created, IncMan must be told how and when to automate the use of this Runbook. This is achieved by creating an Incident Template, which will be used any time an incident is generated that matches the incident condition. Through this incident template, critical pieces of information such as Type, Summary, Category can be automatically applied to the newly created incident.
In addition to incident information, the Incident Template also allows R3 Runbooks to be automatically assigned and executed each time the Incident Template is used. Assigning the previous R3 Runbook to the Compromised Host Incident Template will cause the R3 Runbook to be automatically run for each matching incident.
Finally, conditions must be set to indicate when IncMan should utilize the Compromised Host Incident Template. In this use case, the Compromised Host Incident Template will be used to create an incident each time a syslog message is received from the organization’s endpoint detection system.
This use case allows the security team to be automatically notified each time an alert is triggered indicating a potentially compromised host.
The automated portions of this R3 Runbook can be executed in less than 60 seconds, which is far less time than it would take an analyst to manually query all of these information sources. In addition, this R3 Runbook allows security managers to codify what criteria is indicative of a potential high priority incident which must be addressed immediately, and what criteria may be grounds for false positive notification and can be discarded. This allows for an effective, efficient and consistent security response to each newly identified security incident.
Heather Hixon / 25 Apr 2019
This use case allows the security team to be automatically notified once an incident has been confirmed as valid, preventing valuable time from being wasted by analysts triaging an event.
Heather Hixon / 17 Apr 2019
Learn how to use IncMan SOAR’s integrations and R3 Rapid Response Runbooks to quickly gather incident data from across diverse hybrid-cloud environments.
Cody Mercer / 4 Mar 2019
For threat intelligence to be effective it has to meet 3 tenants which are actionable, timely and confirmed. The acronym that we like to use is ‘ACT’.
See IncMan SOAR in Action.