Learn how to use the platform's security orchestration, automation, and response (SOAR) solution to quickly investigate and resolve security incidents. 

Exabeam enables security teams to automate their response to security incidents, dramatically reducing the time and resources required to mitigate active attacks. The platform's Incident Responder lets analysts automate time-consuming tasks when investigating incidents and neutralizing attacks, enabling organizations to immediately respond to threats in real time. 

Getting Started with Exabeam Incident Responder 

Preparedness is the key to operational security excellence, and Exbeam's Incident Responder allows organizations to prepare themselves for security incidents well in advance.  

It allows analysts to automatically execute pre-established actions according to specific threat scenarios using a variety of built-in and third-party services. Security professionals do this by creating and editing incident playbooks that run automatically when triggered by suspicious activities or conditions. 

Playbooks are a standardized sequence of actions designed to mitigate and neutralize specific threats. They automate the incident response workflow, allowing security analysts to identify and address incidents much faster than they could otherwise. 

Each playbook responds to a specific threat and executes actions to address it. This requires linking threat intelligence data like indicators of compromise (IOCs) with a concrete series of actions designed to mitigate that threat. The playbook itself runs according to a logic flow informed by the specifics of the threat in question – how it works, what actions it typically takes, and so on. 

Exabeam Incident Responder supports both automated and semi-automated workflows. The optimal security posture for your organization will include both workflows to some degree: 

• Automated Workflows 

Automated workflows run the instant they are triggered with no human intervention involved. If Exabeam detects activity that matches the conditions for triggering the playbook, it will immediately start running. There are six circumstances that can trigger a playbook: 

• Creating an Incident. You can set a playbook to trigger whenever Exabeam logs a new security incident. 
• Changing Incident Status. You can trigger playbooks to run whenever someone changes the status of an existing incident. 
• Changing Incident Priority. You can trigger playbooks whenever someone changes the priority of an existing incident. 
• Assigning a User to a New Queue. You can set playbooks to trigger when someone gets assigned to another queue. 

• Changing Incident Assignee. You can trigger playbooks to run whenever users are assigned to an incident. 
• Changing the Incident Type. You can set playbooks to run when an incident's type changes, whether that change happens automatically or manually. 

These are useful for establishing decisive response workflows to severe attacks and escalations. For example, you could program Exabeam' Incident Responder to pinpoint and block a user's account as soon as the system detects malware running on it. Automatic workflows are also great time-savers for repetitive but necessary tasks, like taking adding suspicious URLs from phishing messages and adding them to a blocklist. 

• Semi-Automated Workflows 

Semi-automated workflows only run once a security analyst launches them manually. This gives analysts time to analyze the situation and determine whether the playbook's response is appropriate.  

The playbook itself can still run from start to finish without additional intervention. The only manual element at play here is the decision to launch the playbook itself. 

To run a playbook manually, enter the incident's Workbench and click on RUN PLAYBOOK. Select the appropriate playbook from the list and click on LAUNCH. As each action in the playbook runs, you'll see them appear in the ACTIONS tab with green checkmarks next to each one. Once the whole playbook runs successfully, it will appear in the PLAYBOOKS tab with a green checkmark next to it. 

How to Create and Edit Playbooks in Incident Responder 

Exabeam Incident Responder lets users create playbooks from scratch, modify playbook templates, and run fully configured turnkey playbooks right out of the box. 

Note that only users assigned to an Incident Responder seat can create their own playbooks. Users that aren't assigned to a seat cannot create, edit, or launch custom playbooks – only the turnkey playbooks included with the software. 

To create a new playbook, open Incident Responder and click on PLAYBOOKS. Click on Add a New Playbook and enter information about the playbook you wish to create. From here, you can use a playbook template as a starting point or begin working from a blank slate. Give your playbook a name and a short description before hitting Create. 

If you chose a blank playbook, it will open with a default start node and an end node. If you are starting from a template, its nodes will vary depending on the template you chose. Exabeam includes 16 built-in templates to choose from, and you can create or import your own. 

Things to Keep in Mind When Creating and Editing Playbooks 

Now you're ready to define the logic of your playbook. Use compound, relational, and conditional operators to add nodes, configure actions, make decisions, or filter results.  

Exabeam's turnkey playbooks use free services that are immediately available out of the box. With custom playbooks, you can incorporate a wide variety of third-party services to your incident response workflows. Powerful technologies like Anomali ThreatStream can dramatically improve a playbook's capabilities and overall value in the incident response chain.  

To use these services, you must enter information about the service itself, including whatever permissions and credentials it needs to run. This process is unique for each service. 

Keep these important tips in mind when creating and modifying playbooks in Exabeam's Incident Responder: 

• Every node must ultimately connect to the start and end node in some way. Otherwise, the playbook cannot run. 
• Only the output of a previous node can act as input for another node. 
• To use the output of one node in another node, both nodes must ingest data of the same type. For example, you can't link a node that outputs a list of URLs to a node that ingests a list of IP addresses. 
• Every node must have fully configured input fields. If a node is missing one or more fields, it will be outlined in red.