During the lifecycle of a security incident you are bound to require additional information from either; affected users, SOC and non SOC team members.
Although most organizations offer multiple communication technologies to do this, email is still the most common technology used. This is primarily because it remains the central communications channel within organizations and allows easy communication with external parties.
A few examples during which obtaining additional information can be beneficial, is when you need to:
• Confirm ownership of a system;
• Confirm a user clicked on a link, downloaded or installed something;
• Confirm a user submitted their credentials on a suspicious site;
• Request additional evidence in the form of screenshots etc.
In those cases, when leveraging email, you are likely to perform at least some of the steps outlined in below diagram:
As you can imagine, this process is not only inefficient and time consuming. It also increases the likelihood of analysts skipping this step and continuing their analysis whilst missing important information.
So how can Security Runbooks help?
In SecOps we leverage the power of Flow Designer to build and maintain low code, no code runbooks. When enabling the “Security Operations Spoke” in your instance, Flow Designer will include the following sub-flow & action step:
- Sub-flow: “Get User's Confirmation Email With Task V1.0”
- Action: “Parse Confirmation Email with Task V1”
In order to understand how runbooks can be leveraged to streamline the communication process, we will look into these in more detail.
The “Get User's Confirmation Email With Task V1.0” sub-flow is useful to send email notification containing confirmation options.
In below example, we call this sub-flow as part of a security runbook which triggers on the creation of “Failed login” categorized security incidents. When this occurs, we request the affected user for confirmation of issues with their account:
The configured components here are the following:
- Calling of sub-flow “Get User's Confirmation Email With Task V1.0”;
- Closure notes for the email body;
- Email body text with reference to the affected user’s first name;
- Relation to SIR record to track email response;
- Email subject text;
- Provided options as clickable response links;
- Email destination which gets auto populated from the affected user CMDB info.
Upon execution, the affected user “Nora” receives below email containing the response options:
When Nora clicks on one of the URL’s, a new email is formatted and ready for Nora send back.
The next step is to “catch” the reply and parse out the provided response. For that we use the “Parse Confirmation Email with Task V1” action in a runbook that monitors the inbound email queue.
The configured components here are:
- A inbound email queue trigger for messages with a subject that contain “Re:Failed Login”;
- A record lookup for the original SIR record for later use;
- The parsing of the user’s response using the “Parse Confirmation Email with Task V1” action;
- An if statement for when the response was “yes”. If true, the SIR work notes get updated with yes;
- An if statement for when the response was “no”. If true, the SIR work notes get updated with no;
- If neither are true, we create a response task requesting the analyst to contact the affected user for more details.
When Nora’s reply gets picked-up and processed by this runbook, the following updates appear in the security incident:
- Affected user info;
- Received response from Nora;
- Original Email body containing Nora’s reply.
This is great, but we can make it even more powerful when combining this with security response tasks! This time we will:
- Create a response task to automatically send out an email and set the security incident status to “Analysis”;
- Auto evaluate the reply in order to create new follow-up tasks;
- Auto update the parent security incident with provided evidence.
Before we can configure this though, we must first make sure the “Get User's Confirmation Email With Task V1.0” sub-flow no longer uses the hardcoded “Re:Failed Login” as the reply subject.
To do this, make a copy of the flow and call it “Get User's Confirmation Email With Task V2.0” and change line 39 in the scripted email body as shown below:
This small change will make sure the subject you provide as input is used in the reply email instead of the hardcoded “Re:Failed Login” value.
When that is done, let’s move on to create a new runbook that is triggered on the creation of security incidents with a category “Policy Violation”:
As you can see, this runbook contains below components:
- Runbook trigger on the creation of a policy violation SIR’s;
- Response task creation and reference to the related parent SIR record;
- Task description (this can also be used to reference runbook KB articles!);
- Configuration to modify the SIR state to Analysis.
The second section of this runbook contains:
- A call to the modified “Get User’s Confirmation Email” sub flow;
- Used closure note in the email body;
- Email body text with reference to the affected users first name;
- Relation to the response task record which is used to track the response;
- Email subject text (this is now also used as the subject in the reply email);
- Provided options in email body as clickable response links;
- Email destination which gets auto populated from the affected user CMDB info.
When this gets executed, the affected user receives another email containing two response options and a request to provide additional evidence:
At the same time, the related security incident gets updated with the following information and response task:
- Affected user
- Additional affected user information
- Affected configuration item information
- Auto created response task
In order to process Nora’s reply, we have to create another runbook which contains some additional steps compared to the previous one:
The used components here are:
- An inbound email queue trigger for messages with a subject that contain “Re: [Security Alert] Noticed suspicious file download”;
- A record lookup to the original security response task record for later use;
- An attachment copy action from the email record to the parent security incident;
- The parsing of the user’s response from the email subject field;
- An if statement for when the response was “yes”;
- If true, the response task is marked as completed after which a new one is created requesting the analyst to analyze of the provided evidence;
- An if statement for when the response was “no”;
- If true, the response task is marked as completed after which a new one is created requesting the analyst to obtain further information;
- Else – the response task is marked as incomplete after which a request is made to get in contact with affected user.
So now let’s look at the result when the response “Yes (I downloaded this file)” is selected and additional evidence is added to the reply email:
When the reply is processed by our runbook, we see the following updates appear in the security incident:
- Affected User’s reply;
- The auto close of the related response task;
- The creation of a new response task requesting analysis of the provided response;
- The population of all relevant information in the incident timeline.
Even better, the security incident timeline contains all relevant information in chronological order:
- The affected user’s reply;
- A preview of the provided evidence and a downloadable version as an attachment;
- Access to next response task.
Nice, so there you have it.
I hope this has proven how security runbooks can effectively transfer manual and time-consuming communication processes into a streamlined and far more efficient experience.
If you are still not convinced, have a look and compare below diagram with the one shown in the beginning of this article:
I hope this was useful and if you have any comments or suggestions do not hesitate to let me know.
