Protecting identities with the Sumo Logic platform

Today’s cyber threat landscape necessitates that we, as defenders of the enterprise, place identities at the center of our detection, prevention and response efforts. Indeed, threat actor tactics and techniques observed in the wild demonstrate that credential theft presents a large risk to the confidentiality, integrity and availability of our systems - be they on premises or in the cloud. 

This blog will demonstrate the powerful features of the Sumo Logic platform - namely Cloud SIEM and Cloud SOAR and how they can be used to protect identities and make life easier for those who are responsible for the investigation of various identity-themed alerts and incidents. 

Setting the stage

Examining a recent CISA report regarding the LAPSU$ threat actor group, the critical role of identity-based attacks is evident, particularly when looking closely at the persistence methods used by this particular set of threat actors: 

We see three very distinct persistence methods. 

Of particular interest here is the fact that the three techniques mentioned span both cloud and on premises systems. 

Sumo Logics’ Cloud SIEM contains out-of-the-box content for these three persistence methods and analysts are able to gain insight into all methods outlined above: a user being added to a local administrators group, an MFA device being registered, and a user account being created

This is a fantastic starting point. Analysts and users of Cloud SIEM are able to understand what is happening within their environment. However, what makes identity-related alerts particularly tricky to wrangle from an analyst or engineer point of view is that the telemetry alone cannot convey intent. 

Let’s unpack this dynamic a little bit more and look at one of these alerts through the eyes of a SOC analyst.

Through a SOC analyst lens

Let’s imagine we’re a SOC analyst who receives an alert that a user has added another user to a sensitive group in the cloud.

If we compare this type of alert to something like a “Malware detected on host” alert, the stark difference is clear. 

With a “Malware detected on host” type alert, the analyst knows that this activity is at least somewhat suspicious, as the endpoint product or telemetry found something that is potentially malicious on the host. Of course, this type of alert may turn out to be a false positive upon further investigation, but the analyst has a solid foundation to work from.

Contrasting this dynamic with an alert for a user adding another user to a sensitive group in the cloud, the analysis dynamic becomes a little bit more murky. 

This operation may be part of normal business operations, or part of a system change that is documented and approved. 

The analyst has a few choices here when investigating this type of alert:

• Look for indicators within the telemetry that this action was suspicious, such as an odd IP or User Agent
• Look for previous actions undertaken by the user that is performing the group addition
• Cross-reference tickets or change requests to determine whether this activity was expected
• Reach out to users manually in order to confirm the group addition 

All these actions are perfectly valid and there may be additional playbooks and standard operating procedures that the analyst can follow. 

A common thread among these avenues, however, is that they are time-consuming and require the analyst to context switch, potentially digging through events from various systems. 

What if we can automate this process, reduce analyst toil and automatically reach out to the user that performed a sensitive administrative action through an out-of-band medium – if the user confirms the action was indeed performed by them, no further action is required. However, if the user confirms that the action was not taken by them, an additional high severity alert or insight is raised. All without the analyst having to perform these manual steps. 

The confirmation workflow

As outlined above, our goal is to reduce the time it takes for an analyst to review an alert, and reduce the mean time to respond. 

To do so, we want to automate the process of confirming a “sensitive administrative action”. 

What constitutes such an action will vary depending on the environment, risk tolerances and telemetry sources. 

Cloud SIEM provides tagging functionality that allows users to tag either existing out-of-the-box rules or any custom-developed rules. We can then use our Cloud SOAR product to read these tags and perform an array of powerful and infinitely customizable actions.

When we put all these features and pieces together, we have all the necessary components to build a playbook that automatically confirms sensitive administrative actions with the user who performed them. 

Let’s outline what this playbook will look like step by step:

• A Cloud SIEM built-in or custom rule that looks for any type of sensitive administrative actions is tagged with a “SensitiveAdminAction” tag
• The Cloud SIEM signal is triggered by activity occurring within the enterprise (A user being added to a specific group, an MFA device being registered etc ) 
• A SOAR playbook kicks in upon the signal trigger 
• The SOAR playbook utilizes Cloud SIEMs’ inventory to look up contact details of the user who performed the sensitive admin action
• A communication is sent to the user (a Slack message, for example) giving the user details of the signal and asking the user to confirm this action
• If the user confirms the action, no further action is taken
• If the user does not confirm the action, a high severity insight within Cloud SIEM is generated automatically 

For those who are more visually inclined, this flow is represented by the below MermaidJS chart: 

If you wish to document your own flow, please feel free to use and modify the code that generated the above diagram: 

%%{
 init: {
   'theme': 'base',
   'themeVariables': {
     'primaryColor': '#1623b5',
     'primaryTextColor': '#fff',
     'primaryBorderColor': '#000000',
     'lineColor': '#b5ad16'
    }
  }
 }%%
 flowchart TD
   A[CSE Signal] .-> B{"Sensitive Admin Action Tag?"}
   B .-> No .-> D[/No Action\]
   B .-> Yes .-> C(Initiate SOAR Playbook\nSend User Out of Bound Confirmation
 Request\nSMS/Slack/Signal/Secondary Email)
   C .-> E{User Confirms Action?}
   E .-> Confirmed .-> D[/No Action - End Flow\]
   E .-> NotConfirmed .-> F(((Raise High Severity Insight)))    

It should be noted that all the various options outlined in the flow above are fully configurable by the user, the tag name can be changed, the rule logic tweaked and the method of confirmation swapped. 

Workflow Example

Let’s take a look at a practical example of this workflow. 

The security team gets together and decides that they would like to generate a signal when an Azure user is added to a global administrator role. 

This role is obviously extremely sensitive so the team would like to get visibility into this kind of activity. 

The team crafts a rule:

The rule is tagged with MITRE ATT&CK mappings and is also tagged with a “SensitiveAdminAction” tag.

A Cloud SOAR playbook is then created. Because Cloud SOAR integrates with various cloud providers like Azure and AWS, we can pass parameters from our Cloud SIEM-generated signal to our Cloud SOAR platform:

With these integrations set and configured, the team can go ahead and craft the playbook:

This playbook receives the information found in the Cloud SIEM signal and performs a lookup for the source users’ contact information in Azure Active Directory / Entra ID.

In this case, the team has a secondary and out of band Slack channel set up for these kinds of notifications. 

The user that performed the sensitive administrative action is then located in Slack and a message is sent to the user, asking them to confirm or not confirm the action.

At this point, if the user confirms the action, no further steps are performed. 

However, if the user does not confirm the action, a high severity Cloud SIEM insight is generated, with the proper tags and a critical severity.

All these actions are performed in an automated fashion and are made possible by the wide array of powerful features available in both the Cloud SIEM and Cloud SOAR platforms. 

The ability to ingest both cloud-based and on-premises telemetry, combined with a powerful real-time rules engine with tagging and inventory support all complement the incredibly powerful Cloud SOAR platform. 

How much time do we have?

If we return back to our SOC analyst context and break the above workflow into manual steps: 

• View Signal information and determine who performed the sensitive administrative action
• Locate the users’ contact information 
• Find a medium to contact user through
• Send user a message with signal details
• Wait for confirmation while attempting to not get sidetracked with additional incoming alerts
• Check the confirmation message and take appropriate action(s) 

In best case scenarios, we can easily imagine this flow taking up at least 20-30 minutes of a SOC analyst's time and if we multiply that by potentially multiple alerts per day, we can see their time fading away.

Security leadership is on the constant lookout for time optimization strategies and “doing more with less”. This dynamic represents such an optimization, and not only provides organizations with additional protections and assurance against critical activity within the enterprise, but can also save analysts hours of time per day. 

A call to action

The workflow illustrated in this blog requires a few pieces in order to be made operational.

First, security teams need to understand the identity flows within their environments. What systems handle authentication, how are credentials stored and provided to users, how do users interact with multi-factor authentication systems are all areas that should be well understood.

Once the general identity flows are understood, security teams need to ensure that the relevant telemetry is being collected and that analysts within the enterprise have the necessary visibility into identity and authentication actions. 

Then, security teams can identify what constitutes “sensitive administrative actions” in their particular environments. Some examples of these are: 

• Adding a user to Domain Administrators group in an Active Directory environment
• A login to a sensitive database server
• A broad or overly permissive IAM role being applied
• A root console login 
• A change of MFA device, particularly for administrative users
• A login to a “Tier 0” server or device
• A creation of a “super user” account on Linux hosts

Once the telemetry is in place and operational, and security teams have a grasp of what sensitive administrative actions occur within their environment, then rules can be crafted and SOAR playbooks built out.

Throughout, it is important to always keep the person that is responsible for monitoring and responding to these types of alerts in mind. The more that we can remove guesswork and manual steps, the more time analysts will have to focus on what counts: protecting their respective enterprise. 

In this blog post, we outlined how the Sumo Logic platform - namely Cloud SIEM and Cloud SOAR work in tandem in order to not only provide additional coverage and protection for sensitive administrative actions, protecting key identity theft avenues within the enterprise, but also save your analysts and engineers potentially hundreds of hours in manual toil. 

Learn more about Cloud SIEM in this solution brief.

If you are interested in building out this type of SOAR action in your environment, or are interested in seeing Cloud SIEM and Cloud SOAR in action, please do not hesitate to get in touch.