Month: August 2023

You Still Need UEBA

After spending significant time and money implementing a SIEM, the last thing anyone wants to hear is that you need to spend even more time and money on something called a UEBA (User and Entity Behavior Analytics) in order to get value out of your SIEM. But the good news is that many UEBAs are now add-ons to your SIEM that can be deployed quickly, instead of being an expensive multi-year project.

When UEBAs were first introduced, they were typically stand-alone applications that worked separately from your SIEM, and could be as challenging to implement and maintain. This meant additional skillsets, staff, data parsers, and more for a similar application. They required a separate feed of security and application log data, often being the same data you sent to your SIEM.

UEBAs differ by vendor, but regardless can provide value whether they’re a stand-alone or add-on application. As the name implies, the application focuses on the “user” or “entity” (e.g. system) instead of individual alerts that SIEMs were traditionally designed to work with. The applications can provide various analytics on what’s going on in your environment, such as rarities, outliers, and more, and can consolidate all of it by the user or system performing the actions. Common use cases include:

  • Unknown file executed for the first time in your environment.
  • User visited a newly created domain.
  • User visited an uncommon domain.
  • User connected from a new country for the first time.
  • User connected with a new user agent.

While those are all interesting scenarios and potentially suspicious, it’s simply not possible for most companies to review all of this activity in their environment. The unknown file executed that hasn’t run before in your network could be ransomware, but it’s likely just an update for one of the hundreds of applications you have. The user connecting from a different country for the first time using a new user agent could be indicative of a compromised account, but it’s likely someone logging in from their phone while on vacation.

You could technically do all of the above in a SIEM, but you’re going to need a team of data scientists to create and maintain the queries. UEBAs typically do all of this out-of-the-box, lifting this burden from the security team.

Again, rarities and outliers do not necessarily warrant an investigation, but they can help you identify the riskier behaviour in your environment. SIEM alerts on the other hand are typically designed to look for specific suspicious activity, for example:

  • Single failed pass the hash attempt.
  • Multiple RDP login failures.
  • Running something from the /tmp folder.
  • User clicked on a blocked link.
  • User attempted to execute a file that was blocked by the EDR.

Those above scenarios can be suspicious, but like UEBA analytics, they can be common in large environments. Sending each of these to the SOC for an investigation may not be a good use of their time.

But combining both SIEM and UEBA analytics, you start to get a much better picture of who are the riskiest users and entities in your environment and how to prioritize investigations. It may be hard to justify an investigation for one of the above alerts, especially in large environments. But it may be risky to ignore a user who has triggered many of them.

Since you’re not triggering an investigation for each use case, many “useless” use cases that would never get the approval of the SOC, can now become feasible and useful since they don’t trigger an investigation but increase a user’s or entity’s risk score. Large organizations for example may not review each successfully blocked or quarantined antivirus or EDR event, which may not be feasible as an individual alert due to the volume, but one of those events could be the start of a greater attack. That activity alone may not trigger a UEBA user investigation, but it can put the user or system on the security team’s radar.

Depending on your environment, you may want to weigh certain analytics over others when scoring the top users and entities. You can weigh by user severity (e.g. privileged users, executives), Mitre Att&ck Framework stage (e.g. scoring Execution use cases higher than Reconnaissance), and more.

As mentioned, many UEBA applications are no longer an exotic, risky security tool implementation. Some of them are simple add-ons to your SIEM and can be setup and configured quickly. For example, the Sentinel UEBA is a simple add-on to the Sentinel SIEM.

Some UEBAs are stand-alone applications that require a separate copy of the log data that feeds into your SIEM. The Splunk UEBA is a stand-alone application that works separately from the SIEM. While it may not be as simple as an add-on, stand-alone UEBAs can still provide valuable analytics.

There are also some simple apps that act like a UEBA. The Splunk Risk Analysis Framework in Enterprise Security is a valuable tool that gives you UEBA-like analytics with your SIEM rules.

Regardless of the UEBA, when combined with your SIEM and other security analytics, it can further highlight high-risk users and systems in your network. Which UEBA is best for your organization depends on many factors, such your environment, provider, systems, line of business, and more. But if you have a SIEM, you should definitely consider using a UEBA to add value to your environment. It can be a quick, inexpensive, and valuable addition to your cyber security team.

Top SOAR Use Cases

If you’re not familiar with SOARs, they’re one of the newer tools used by cyber security teams to consolidate all of your various alerts, automate common SOC tasks, improve incident response times, optimize data extraction, and reduce the amount of administrative work done by SOC analysts. The larger your organization, the more value and efficiencies they can provide to your already stretched cyber security team.

Here are some of the top ways SOARs can help your organization.

Automatic Intel Lookups and Alert Enrichment

Security analysts spend a significant portion of their day performing lookups in various applications. When a SIEM alert generates, they’ll likely perform a lookup in VirusTotal, detonate a suspicious file in a malware sandbox, get domain info from a Whois service, lookup the user in an identity management application, and more. While doing this for a single alert may only take 15 minutes, doing it several times per day can take up most of an analyst’s time. While collecting this data is required to perform an investigation, pulling it repetitively can become burdensome administrative work.

Most SOARs integrate with many of the popular intelligence services and can obtain the majority of data required before the analyst even opens the alert. Instead of spending twenty minutes running reports, analysts can jump right into the investigation, having the SIEM, firewall, Active Directory, and asset management reports right in front of them.

Case Management Application

Not only can SOARs collect most of the data required for an investigation, they can consolidate it into a single pane of glass. If you take a look at your analysts’ screens, you’ll likely see multiple monitors with several tabs open on each. And they’ll likely have to log into each of them several times per day due to session timeouts on each of them.

SOARs can consolidate all of the data they collect into a single ticket that analysts can work off of. SIEM and firewall reports, lookup results, and more can be attached directly to the ticket to be used in the investigation and retained as evidence. Most SOARs can also create alert metrics quickly, allowing organizations to produce lists of SIEM and other alerts along with their true and false positive rates, giving security teams insight into their high-value content.

Escalations

One of the perennial challenges of security operations teams is determining which alerts to prioritize. Many vendors set priorities of their IPS signatures and SIEM rules, but these are often too general to be used effectively. Running something from the /tmp folder may be significant at one organization, but not at another.

SOARs can perform a lookup in most identity management applications, and then change the severity based on the user’s role, line of business, and other factors. A generic alert all of a sudden becomes useful when it’s the CEO, an executive, or privileged user triggering it. Login failures are likely happening right now at any large organization, but if it’s the CEO’s user account, that should take priority over any other brute force rule. Is a customer-facing bank branch staff member trying to RDP into other servers on the network? Since that’s not something a branch employee would (or should) do, it should take a higher priority over other alerts.

Email

SOARs can integrate with common email services, including Exchange and Gmail. Before a user opens his or her email after a meeting, your SOAR could have already uploaded the URL or suspicious attachment in VirusTotal or Wildfire, and deleted the email before the user had a chance to click on the link or open the file flagged as malicious.

Email is also an excellent way to “talk” to a SOAR and perform ad-hoc requests. Many SOARs can be configured to monitor an email inbox, and PlayBooks can be setup to run based on certain text values found in selected emails. Want a bunch of IP addresses or domains looked up but don’t know how to search for them in the SIEM, or don’t have access to the SIEM? Not a problem. The SOAR can be configured to parse out IPs, domains, and other text from the email, look up the values in the SIEM, firewall, or other security application, and return the results as a CSV attachment in an email.

SOARs can also use email to perform surveys, collect data from users, and take action based on the responses. They can take a vulnerability management report, lookup the system owner in an asset management system, and then send an email to the owner asking if they are aware of the vulnerability and if it has been remediated. This may not seem like much, but depending on the size of your organization, this could significantly reduce the amount of notifications your SOC needs to send. Chasing thirty system owners around is much easier than one hundred. Chasing system owners around is also another example of administrative work that can be done by a SOAR instead of a security analyst.


SOARs of course need to be configured, maintained, and updated regularly. Automating a task performed a couple of times per year may not be a good automation investment, but reducing the amount of day-to-day administrative work performed by SOC analysts is a great investment and allows staff to focus more on analyzing threats to your organization.