Account compromise (Part 2): Enrich alerts, avoid toil, and regain control during incidents

Note: This is part 2 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) categorizes one of the consistently growing threat actions that contribute to breaches as being “errors” and specifically misconfigurations. It is human to err, but it is more important how well we fail, react, and then regain control of a situation. As we battle complexity there will inevitably be an increasing number of errors but any potential exploitation window should be kept as narrow and brief as possible. We can offset these vulnerabilities and mitigate threats by how quickly we identify and respond to incidents. Having the right data is important for decision making but it’s crucial to be able to respond in “Internet time”. This is where defensive security automation really shines and strengthens our defenses across the board.

In Part 1, we looked at how to use the HaveIBeenPwned (HIBP) Domain Search service as a trigger to initiate our automation (with an additional and optional webhook approach). Now, in part 2 we will again use the HIBP API but also other services to enrich our understanding of the impact. We then go on to automate case creation for both Helpdesk and Infosec or SecOps teams. As a reminder, we are now on the “Enrich Alert and Create Case” stage of the below parent automation. We’re also using the modular “Send To Story” Action to simplify our workflow and enable simple extensibility. For any other use cases or steps you’d like to see, why not ask us in chat!

From the main automation workflow we now pass any breached emails found (and related breach names) to our sub-Story “Enrich Alert and Create Case” for further enrichment and action.

Enrichment‍

Here, we will gather more information about the specific breaches for our compromised email accounts. We will also check if those emails have been used elsewhere using services like Sublime Security’s emailrep.io before auto-creating our incident cases.

First off we want to get more breach specifics for any breached email account. We pass our breach names list into the HIBP API one by one for the current email. In this scenario, the email was found in multiple breaches.

So we request more details on each of the breaches from HIBP by iterating through the list behind the scenes. This is done by exploding the list and then using the normal HTTP Request Action.

"get_breach_details_in_have_i_been_pwned": {
    "body": {
      "Name": "Adobe",
      "Title": "Adobe",
      "Domain": "adobe.com",
      "BreachDate": "2013-10-04",
      "AddedDate": "2013-12-04T00:00:00Z",
      "ModifiedDate": "2013-12-04T00:00:00Z",
      "PwnCount": 152445165,
      "Description": "In October 2013, 153 million 
      Adobe accounts were breached with each 
      containing an internal ID, username, email, 
      encrypted password and a 
      password hint in plain text. The password 
      cryptography was poorly done and 
      many were quickly resolved 
      back to plain text. The unencrypted 
      hints also disclosed 
      much about the passwords adding further to 
      the risk that hundreds of millions of Adobe 
      customers already faced.",
      "LogoPath": "https://haveibeenpwned.com/Content/Images/PwnedLogos/Adobe.png",
      "DataClasses": [
        "Email addresses",
        "Password hints",
        "Passwords",
        "Usernames"
      ],
      "IsVerified": true,
      "IsFabricated": false,
      "IsSensitive": false,
      "IsRetired": false,
      "IsSpamList": false
    },
    ...
  }...

We then summarize the main points including the DataClasses involved. Additionally, we check if the breached email has been seen or used elsewhere on the Internet by using the emailrep.io service. All this is then also neatly packaged up into our case creation.

 "check_email_reputation_in_emailrep_io": {
    "body": {
      "email": "redacted@redacted.com",
      "reputation": "high",
      "suspicious": false,
      "references": 13,
      "details": {
        ...
        "malicious_activity": false,
        "malicious_activity_recent": false,
        ...        
        "spam": false,
        ....
      }
    }...
  }

Case Creation
Our Infosec/SecOps team may require different classes or types of data than our Helpdesk team so we maintain separation of duty between them though initially both cases will contain much the same data. The separation means we can choose what sensitive information to include based upon sensitivity or any ongoing change in investigation status.

Every organization also has its own preferred business processes and workflows around case management. Here we will create an individual case per compromised account rather than batching accounts per breach and then including them in a single case. This approach is also possible but would require a few amendments to the current workflow. Here we are assuming a low number of breached accounts with each being treated as its own incident, especially for allocating and tracking Helpdesk tasks.

We will also want to record any subsequent operational actions that we initiate in Part 3, so teams are kept apprised of the situation including actions such as:

• locking out user accounts

• terminating any active system sessions or connections

• containing any endpoints that the user may have had access to (such as their laptop or phone) until we understand the full scope of the breach

• any additional threat hunting or investigation steps

‍Tip: If you want a good primer on what to consider when investing in Infosec Case Management we’ve covered this recently. It explains why you would choose to “skate to where the puck is” and integrate with different case management systems to accelerate tasks and reduce overall Mean Time to Respond (MTTR).

As we are going to create 2 cases i.e. 1 in TheHive and 1 in Jira Service Desk, we also generate a global identifier but additionally record TheHive case ID and Jira IDs in each respective platform for cross-referencing.

TheHive Case

Here we create a case with the relevant TLP classifications and also add a task note which details the Jira Service Desk ID, key, and link for easy access.

We include the Jira details both for oversight and the ability to track which tasks we’ve requested of other operational teams in their own native workflow platforms.

Jira Service Desk Case‍

We have created the Jira Service Desk case so all operational teams can easily collaborate. It also makes it easy to record and communicate any user-impacting steps taken to teams like Helpdesk while also an opportunity to shape any communications to the end-user. As we initially generated the Jira case it’s now easy to keep everyone, who needs to be, in the loop.

We now move on to the active response in Part 3 where we automatically initiate defenses to protect the organization and eliminate ongoing risk. We will also prompt the user to acknowledge the incident. This helps them to understand why they may have limited access and to check in with the Helpdesk for updates until all remediation has been completed. Read on…

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