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.