Understanding User Threat Detection With Wine

Step 1: Implement user threat detection. Step 2: Have a glass of wine.

In my previous blog posts, I talked about pattern-based vs. rules-based user behavior analytics (UEBA), modeling user activity to build behavioral baselines, and the advantages of an embedded UEBA solution.

Now let’s use a relatable example that to illustrate how these concepts actually work in practice. When I’m not helping organizations improve their Active Directory (AD) security posture, I’m studying as a sommelier — so wine is clearly near and dear to my heart.

Rule #1 – there are no rules

As I discussed in the first post of this series, the big difference between pattern-based user behavior analytics and rules-based detection is that pattern-based user behavior entity analytics (UEBA) models user behavior baselines for every user and detects anomalies in the context of what is considered typical for that specific user. Pattern-based UEBA, however, models all aspects of a user’s behavior in order to detect any anomaly:

Continuous modeling

• Shawn drinks three glasses of wine a day on average, but only on the weekends. His baseline of wine enjoyment ranges from two to four glasses a day, on weekends only. One day Shawn enjoys two bottles of wine (clearly, he was celebrating). That represents a significant deviation from his regular behavior and triggers an indicator.
• In IT terms: Shawn accesses an average of 40 files a day, and then one day he suddenly accesses 800 files in a single hour.

Time-based modeling

• Shawn typically enjoys his wine between 6:00 p.m. and 11:00 p.m. However, one day Shawn drinks two glasses of wine between 1:00 and 2:00 p.m. (we don’t judge), and that triggers an indicator.
• In IT terms: Shawn typically logs in to AD between 8:00 a.m. and 6:00 p.m., and then one day he logs in at 3:00 a.m.

Categorical modeling

• Shawn typically drinks red or white wine. One day he drinks gin for the first time, and that triggers an indicator.
• In IT terms: Shawn typically accesses folders from the Sales and Marketing shares, and then one day he accesses files from a corporate Mergers & Acquisitions folder.

Shawn’s behaviors are specific to him — every user has a different profile of activity and, therefore, their own unique baseline of normal behavior.

Alexa’s behavior baseline is completely different — she typically enjoys beer, usually one or two drinks, but only right after work. So if Alexa were to indulge any of Shawn’s activities (drink red wine, have a drink on the weekend), it would generate higher scoring indicators because these are both abnormal behaviors for Alexa. Alexa’s ongoing activities are being compared to her own typical behavior.

In IT terms: if a floor worker, who doesn’t frequently log into AD, is more likely to forget their password than office workers, the analytics system will establish a higher baseline of failed logins for the floor worker than for the office worker. The threshold for the floor worker is higher, but it’s not really a threshold. If it were a threshold, then it would trigger an alert the moment it was exceeded — and that would be a rule. However, in order to trigger an indicator (pattern-based approach), the number of failed logons would need to be a significant enough deviation from the user’s normal baseline. This reduces a great deal of the noise that is inherent in a rules-based approach.

Reducing the noise from false positive alerts

Reducing the number of false positive alerts is a big consideration — as they can often account for hundreds, if not thousands, of alerts each day. This is far more alerts than you can reasonably investigate, and, as a result, most get ignored. In fact, the Cisco 2017 Annual Cybersecurity Report found that 44 percent of all alerts go unexplored. Reducing alert noise requires a few different approaches.

• Multi-variant risk scoring

One approach that reduces noisy alerts is scoring risks at multiple levels, as we discussed in the second article. Each indicator above would be scored based on its uniqueness for that user as well as its global significance. The continuous indicator will likely get scored higher than the time-based indicator — it’s far more concerning that Shawn had two bottles of wine than the fact that he had a drink in the early afternoon. 

• Alerting on patterns, not individual indicators

Alerts aren’t raised unless a pattern of high scoring indicators are detected for the same user within a short period of time. If only a single indicator is discovered, it will likely be discarded. However, if all three indicators occur in a short period of time, they will be correlated into an alert, which is scored again and surfaced to the security team for review.

• Global modeling

Another approach to reducing noise is global modeling — comparing an anomaly indicator against other users’ behaviors. If an action is anomalous for a particular user, but that same behavior turns out to be popular amongst the global population and is not very unique, then it won’t be scored high and it won’t raise an alert. 

For example: Shawn has three shots of tequila. Normally, this would trigger an indicator based on the categorical model, but, as it turns out, dozens of Shawn’s peers also had shots of tequila around the same time (they were all at a company party), and so this activity wouldn’t rate as an indicator.  Likewise, if a number of users all begin to access a new Windows server for the first time, this isn’t a unique action and, therefore, not highly suspicious.

As you can see, pattern-based UEBA involves sophisticated machine learning and algorithms — but it pays off in terms of producing far fewer alerts with much better accuracy.

I’m just thankful there’s no product out there monitoring my wine drinking patterns!

Change Auditor Threat Detection employs pattern-based UEBA to model individual user behavior and detect anomalous activity that could be indicative of suspicious or compromised users. Change Auditor Threat Detection will be generally available September 2018.

Ready to Learn More?