Playbook: Malicious Insider Containment

This post is part of an ongoing series on Phantom Playbooks; which the platform uses to automate and orchestrate your security operations plan. This example examines one of the playbooks included with the Phantom 2.1 Platform.

Insider threats commonly present themselves as coming from one of two high-level categories. The first are privileged insiders that are unaware that their actions have resulted in an organization’s compromise. The second, and more worrisome, are insiders that are malicious in nature and have consciously worked to exfiltrate data, sabotage an organization’s systems, or perhaps manipulate either data or systems.

This example Phantom Playbook below provides an automated response plan to the malicious insider. Acting swiftly to gather data, disable the user, and alert the proper people within the organization is key to reducing risk and avoiding greater loss.

Playbook_Malicious_Insider_Containment
Malicious Insider Containment Playbook Diagram from the Phantom 2.1 Platform

Understanding the Playbook

When the Phantom Platform ingests a malicious insider event, as with all events the platform ingests, it creates a container to store the event and all of the event’s data. Each element of the event data is stored in the container as an artifact. This allows the data to be retrieved during a playbook’s execution and used for decision making and subsequent execution of actions.

In this playbook, a manual task is first created and assigned to an analyst to notify the Human Resources department that an insider threat event has occurred. Then, the playbook uses the artifact sourceUserName, a standard field in a Common Event Format (CEF) object, to identify the malicious insider. Next, the Phantom Platform attempts to obtain the user attributes from the Lightweight Directory Access Protocol (LDAP) system. These additional details will be used later when a ticket is created. The format block following the get_user_attributes action formats the returning LDAP results. The next step is to prompt the Phantom admin or analyst whether the pre-defined containment actions should be carried out to disable the user’s account. If the response is positive (e.g. Yes), then the disable_user and reset_password actions are executed using LDAP. In all cases, a ticket is created on the organization’s ticketing system for documentation. If the prompt comes back with a negative response (e.g. No), then the ticket is created and a note is made that no containment actions were taken. The event is closed at the end of the playbook run.

By default this sample playbook is configured to use two Phantom Apps:

  1. LDAP (domainctrl1)
  2. ServiceNow (servicenow)

Note that this is an example. Playbooks are customizable for your particular Standard Operating Procedures (SOPs). You can also reconfigure the playbook to match the Phantom Apps and Assets that your organization uses.

You can get this playbook from either the Phantom Community or directly from the Phantom Platform. If you don’t currently use the Phantom Platform, we invite you download the free Community Edition today.

View other articles in this Playbook series here.