Hey there, welcome back! We now proceed with the third installment of our four-part blog series. If this is the first time you’re joining us, here’s a quick recap of what we’ve talked about so far.



Automated Security Playbooks

In our first post, we discussed how security automation can be applied to the process of managing, investigating, and responding to phishing alerts.

We followed that up with a step-by-step guide to automating response processes for malware alerts. Today, we tackle yet another common SOC process, this time focusing on the type of alerts feared by most CISOs – DLP (data loss prevention) alerts.


Why DLP? End user involvement Rapid response
DLP alert processing is a prime candidate for security automation because these alerts require fast response and entail a considerable degree of user involvement. Immediate response is critical because, once your SOC team receives a DLP alert, it could mean data exfiltration is likely already underway. If the exfiltration succeeds and your organization loses sensitive data, your company could face lawsuits and/or heavy penalties, particularly if you’re caught violating data protection laws and regulations like PCI DSS, HIPAA, or GDPR.


Let’s go over a typical DLP alert process flow or playbook and see which areas can be improved through security automation.


Security automationData Gathering/Enrichment

As soon as a DLP alert is raised, SOC team members scramble to gather as much relevant information as they can to build a richer context of the incident. Some of the information an analyst will typically gather includes:

  • Network privileges of the users involved in the incident – the greater the privileges, (e.g. administrator level), the greater the potential risk. Cases involving users with high privileges require a more thorough investigation.
  • Whether the users involved are on a tracking list – some SOC teams keep track of users who, in one way or another, have raised a security alert. So, if any user found in that tracking list raises more alerts in the future, it could mean either that user is an insider threat or one being targeted by external threat actors.
  • Running processes – the processes running around the time the alert was triggered could enlighten analysts of potential risks or provide contextual clues on whether the incident warrants further investigation.
  • External IPs and hosts – these are checked against existing threat intelligence to determine whether they are known malicious C&C servers or other similar threats.
  • Hashes and files – these are likewise checked against threat intelligence for known malware and other threats.

All this information can be collected by a fully automated system and brought to an analyst’s screen, who can then make informed decisions more quickly based on the data provided.


Security AutomationFirst-Level Determination

There may be some cases when you’ll want to verify initial findings with a manager or an employee. In such cases, you will likely need to send an email to these people to seek verification. Some of these emails can be automatically generated.


Security AutomationDeeper Investigation

As you conduct a deeper investigation on the DLP event, there are a number of tasks you would normally do that can be automated. For instance, you might need to fetch certain data pertaining to the end user in question.

  • Employee data from HR records
  • Event data from the DLP system
  • Login events from Active Directory
  • File/directory activity
  • Host activity

All this data, which clearly come from various sources, can be fetched and aggregated through a security automation solution to save you and your team precious time.


Security Analyst-Driven TasksEscalation/Response Path

After an analyst reviews all the information gathered, he or she can then make decisions based on the available evidence. Depending on the findings, there is a range of actions the security analyst may need to take.

  • Block, suspend, or impose restrictions on users involved in the incident
  • Send awareness content to the users involved
  • Generate and send a report to the CISO or SOC Manager
  • Notify the HR Department
  • Isolate the hosts involved
  • Obtain approvals for handling a specific user as the incident is escalated to a Tier 2 or Tier 3 case

Although the majority of these actions will be performed by an analyst, security automation can help expedite certain parts of the process.


Security Analyst-Driven TasksFeedback/Remediation

Finally, your SOC team will leverage whatever knowledge has been gained from the incident to carry out appropriate remediation and establish preventative measures to ensure that the risk of future data loss is further reduced. Usually, they’ll want to update certain security policies or add the users involved to the kind of tracking list we mentioned earlier. Some of these actions, which contribute to your organization’s improved resilience to data loss, can be automated.

A wide variety of corporate data – from trade secrets and financial data to personal information – is regularly targeted by cybercriminals. And losing sensitive data is costly for organizations in both financial impact and reputation damage. That’s why it’s important for SOC teams to process DLP alerts as quickly, efficiently and effectively as possible.

But as the number of breaches continues to proliferate, it’s clear that security operations teams won’t win the war by relying on the way things have always been done. Security automation is poised to give SOC teams the time advantage they need to stay ahead of threat actors and prevent data loss.

Next week, we’ll tackle the last use case in our four-part security automation playbook series – account misuse. We’ll see you then.