Note: This is part 3 of a 3 part series on security automation for dealing with account compromise. Part 1 covers detection, part 2 looks at enrichment and case management, while part 3 tackles protection and response including prompting the user to acknowledge the incident via a side-channel.

The 2020 Verizon Data Breach Investigations Report (DBIR) contains 157,525 incidents and 108,069 breaches. 100,000+ of those breaches were credentials of individual users having been compromised to target bank accounts and cloud services (amongst others). Closing the window on the efficacy of stolen credentials is paramount and with security automation we seek to do it faster. By having predefined workflows and automatic detection for breached accounts you can rest easier and assure yourself what's next. Breaches are inevitable but negative outcomes are not.

It is now time for our active automated response to the breach. We have seen how we broke our workflow into 3 distinct stages but we now move on to the final “Respond and Protect” phase.

We again make use of our “Send To Story” action to simplify our workflow and enable simple but powerful extensibility. From the previous phases we have all the details we need to take rapid action and pass them to our “Respond and Protect” sub-story. Let's dig into it to complete our automated user lockout, case updates, and interactive (yet automated) user communications which use the highly versatile and powerful prompt widget.

With the potential for many different response paths, we can only explore a few critical ones but note that the simple drag and drop approach allows you to quickly compose multiple linear or concurrent parallel workflows. These actions and workflows can be easily tailored to your specific processes or platforms by using prebuilt templates that cover hundreds of applications and platforms. Let’s take a deeper look at the account lockout, user notification prompts, and case updates. Then it's up to you what’s next!

Here we're using the Microsoft Graph (MSGraph) API to initiate a primary lockout of the user from email and other Office 365 / Microsoft 365 based accounts. This is done via OAuth2.0 authentication which only needs to be set up once as a credential. We use the least privilege scope we can to give our automation the ability to disable an account.

‍

Inside the template (below) the payload of "accountEnabled" is being set to “false” which also automatically logs the user out of all other dependent Microsoft services.

{
  "url": "https://graph.microsoft.com/v1.0/users/redacted@redacted.com",
  "method": "patch",
  "content_type": "json",
  "payload": {
    "accountEnabled": false
  },
  "headers": {
    "Authorization": "Bearer {% credential msgraph %}"
  }
}

Note: In this example, we are going to assume that Slack is not dependent on ADFS/Azure AD for SSO (Single Sign-On) as we will subsequently use Slack as a side-channel for communication.

‍

As you can see, we are now battening down the hatches...

Let’s move on to informing the user that there’s been an issue and then get their confirmation they understand what’s happening. We only do this once we’ve confirmed the account lockout has been successful by using a simple trigger/check.

First, we perform a simple user lookup (using the email address) in Slack and then send a message that contains a “prompt” button for confirmation of receipt of the message. This “prompt” widget creates a custom link that we embed in our message button below.

Once clicked it re-starts the automation workflow and emits an event we can wait for and/or match on. This is powerful as it means we can use human responses to gate our automation.

...
"type": "actions",
"elements": [
  {
    "type": "button",
    "text": {
      "type": "plain_text",
      "emoji": true,
      "text": "[Required] Yes, I understand ✅"
    },
    "style": "primary",
    "url": "{% prompt true %}"
  }
]
...

We then continue the automation and use the user response to trigger the next step. Once the user clicks this button, they have set the automated case management updates in motion.

The workflow automatically updates the original Hive case with the user acknowledgment as a completed task.

The workflow also automatically updates the original Jira case with the user acknowledgement as a comment.

‍

We also send a message to the Helpdesk team with pertinent details and include a direct link to the Jira case.

‍

Now that we have locked the primary account, informed the user, they have responded, both cases have been updated, and the Helpdesk team has been informed... we finalize the story workflow - but only once these events have come through to the "Wait For Completion" Event Transformation implode action.

Here we can “wait and gate” in the workflow again. It waits until it sees the right number of events from the preceding workflows (i.e. 3 x events; TheHive update, a Jira update, and a Helpdesk Slack message) before continuing. We have now closed the loop on our detect, enrich / record, and respond / protect automation.

We've completed in seconds and minutes what normally takes hours, days, or even weeks... thus reducing our organization's exposure window and leveraging automation to rapidly de-risk and improve our security posture in the face of an urgent and real threat.

You can download and try these automations in a Tines trial with these workflow files: Ingest, Check, Enrich, and Respond! What other steps or actions would you take, automate, or link? Maybe some follow-on automated insider threat hunting?

‍

*Please note we recently updated our terminology. Our "agents" are now known as "actions," but some visuals might not reflect this.*