Free community edition

Request a demo

IncMan SOAR Use Case: Insider Threat

Back to all articles

insider threat

This use case demonstrates how to use IncMan’s integrations and R3 Rapid Response Runbooks to quickly alert the security team to a potential insider threat, perform initial triage to determine the potential risk to the organization and create a helpdesk ticket to notify the team responsible for remediation.

Goals

  • Automatically receive alerts regarding large data transfers from an organization’s Web server to an internal host.
  • Perform initial triage of the destination host and associated user account to determine user’s risk score.
  • Automatically elevate the priority of the suspected incident based on the user’s risk score and/or the observation of additional security alerts for the user account within a specific timeframe.
  • Create a ticket to notify the teams responsible for vulnerability remediation.

Integrations Used

  • Securonix
  • Microsoft Active Directory
  • Carbon Black Response
  • IncMan SOAR
  • Email Notification

Implementation

Creating an R3 Rapid Response Runbook

The first step in creating an automated response to this type of event is to create an R3 Rapid Response Runbook which will perform Enrichment and Notification actions, as well as Containment actions if necessary. We will assume that the alert has provided the following information at a minimum:

  • Source IP address
  • Source name
  • Destination IP address
  • Destination name
  • User account

This R3 Runbook can be broken down into three main sections; information gathering and enrichment, escalation and containment. Figure 1 shows the entire runbook from beginning to end. Next, we will discuss the actions contained in each subsection in additional detail.

eZHik9ZR1vhvquyh2GsHbasVZ_zAnXPSNLaao4SYKcn1obU99s8PmKr1JA7Q7dHpcEbxZAS56CGRplR2mJtMuxwvo2Ha2RoHzs6u6Uljf1iat7IEUPiv-sngahOLjbl1jbN0aH6GOfA4f5R-qg

Figure 1 – Suspicious User Activity Runbook

Information Gathering and Enrichment

This R3 Runbook begins by performing basic information gathering and enrichment of information provided by the original alert from Securonix. The source and destination IP address are parsed out and checked against Securonix asset lists. This information is then passed to the organization’s Active Directory service to gather data on the user’s attributes, associated groups, and to obtain the user’s risk score from Securonix.

Once this information is gathered the R3 Rapid Response Runbook comes to its first conditional statement. This conditional statement is evaluating the user’s risk score. If the risk score is either medium or high, the runbook will move into the escalation phase by escalating the incident’s priority to high. If the user’s risk score is low, the runbook will then query Securonix for additional alerts and events where the user or their workstation were involved. If additional alerts or events have been observed, the R3 Rapid Response Runbook will move into the escalation phase by escalating the incident’s priority to high.

yV7okaxD2lmNnUkRsmPNwpZEW77YQ1N0ol7vM4Y0Qz9Pa78jNMFMbIyiI4MY8bhDCtGaOYLidHT3LvYmc3u20wxcqHVFNf8gGnEOPcDQyKWLKoOVJ8khNh_r_rF_nVHrlk9sS2v481YwTHK3cw

Figure 2 – Information Gathering and Enrichment

Escalation

Prior to the escalation phase the R3 Rapid Response Runbook evaluates the user’s risk score to determine if the incident should be upgraded in priority or if more information needs to be gathered to make the determination. If the user’s risk score is either medium or high, the priority is adjusted, and a query is issued to Securonix to gather historical event and alert data regarding the user and their workstation. If additional security alerts have been observed, the incident is upgraded to critical priority before moving to the containment phase of the suspicious user activity workflow.

If the user’s risk score is considered low, the same query is issued to Securonix to determine if the user’s account or their workstation had been observed in any security events or alerts over the last 30 days. If the account has been observed in additional security incidents, the incident’s priority is upgraded and automatically moves into the containment phase of the runbook. If there are no additional alerts for the user or their workstation a user choice selection is issued. This user choice entry temporarily pauses the runbook to allow an analyst to review the initial alert, the user involved, and the actions the user had taken to determine whether they would like to proceed in containing the user or to exit the runbook without taking further action.

C-AkD-TAsdiYoB1XDL2H4XrVYZlewSHoDUzakejYAOq_LqlRfWY9TnQ2rwVVynFG5BsFpZIGL9gNGkVsGE_Z5j-9NGEvonF-DoYe0wz7o0KYWg1FqrVgKRgkN-Dqsjr4DgKD_AezDZE1k58gcg

Figure 3 – Escalation

Containment

Once the R3 Rapid Response Runbook enters the containment phase of the workflow an additional conditional statement is evaluated to determine if containment actions are required. If it is found that containment actions are required, the runbook’s workflow follows four separate paths to determine what containment actions are appropriate.

The first path is executed if the initial user’s risk score was medium or high and additional security alerts were observed. After escalating the priority to critical, the host machine is quarantined by Carbon Black Protect, the user’s account is disabled in Microsoft Active Directory, and an email notification is sent out to the security team to follow up with the suspected user.

The second path is executed if the user account associated with the medium to high risk score has not been observed in any additional security alerts the R3 Rapid Response Runbook disables the user’s account in Active Directory and an email notification is sent out for the security team to investigate.

The third path is executed if the user’s risk score is low and they had been observed in additional security alerts over the last 30 days. After the priority of the incident is elevated to high, the user account is disabled in Active Directory and an email notification is sent out to the security team for further remediation efforts. The final path is followed if the user’s account has a low risk score and has not been involved with any additional se3curity alerts in the last 30 days. If this path is taken the R3 Rapid Response Runbook issues a user choice selection before a containment action is taken. The user choice selection temporarily pauses the runbook and allows an analyst to review all the evidence that has been collected for the potential incident. Depending on the findings the analyst will choice whether or not containment activities are warranted. If the analyst decides to take containment actions against the observed activity, the runbook will disable the user’s account and allow the security team to follow up with remediation activities. If the analyst decides that containment actions are not needed the runbook will be unpaused and exit.

rWpBHs4B1_Uscu0Ctxm_ZZc-VFxxIlW6mz430-FSowxQ_0o7Z3oOOK3j4xtWsXpoyBk__FnnZzd2An8wsXUMWXtJDN8M39kCnPFeJsDORtwhkZoJqMxOsazp0jJfN6-O28I2vGkq-nx2BdKuqA

Figure 4 – Containment

Utilizing the R3 Rapid Response Runbook

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 for a newly discovered vulnerability. 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 Suspicious User Activity 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 Suspicious User Activity Incident Template. In this use case, the Suspicious User Activity Incident Template will be used to create an incident each time an event is received from the organization’s endpoint detection system.

Summary

This use case allows the security team to be automatically notified each time an event is observed where a large data transfer has taken place. By automating this type of alert the will help to reduce the time between detection and response for this type of activity to help prevent a potentially serious data breach.

The automated portions of this R3 Runbook can be executed in less than 60 seconds, orders of magnitude less 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 large data transfer event and what criteria may be grounds for immediate isolation until mitigation can be completed. This allows for an effective, efficient and consistent security response to any new attempt to transfer data both internally and externally to the company.

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.

Request a demo