Identity-Aware UEBA Demo: Catch Insider Threats Before They Become Incidents

As we discussed, insider risk remains one
of the biggest threats that face companies today.
Unfortunately, most tools that claim
to address it overwhelm security teams with low value alerts
and bury the signals that really matter.
Imagine a scenario where I'm planning
to leave the organization and I suddenly start downloading
far more files than usual.
That's a clear insider threat scenario.
But even in small organizations, tracking the activity
of every user manually is impossible.
So with Lightbeam Yuba,
we build a comprehensive behavioral baseline for each user.
We fine tune to the individual their role
and their work style, and then these baselines continuously
adapt to the natural ebbs
and flows of the business, ensuring
that security teams only get the alerts
that matter without the distraction of false positives.
If we're looking here, we've got a number
of alerts over here on the right hand side.
So I'm just gonna go ahead and click on the alert section
and I'm gonna filter by user activity.
So that's the alert we're looking for.
So you can see here we have an anomalous behavior sensitive
files, LB SharePoint rule set configured.
That rule set is built specifically
for SharePoint in these two sites, and it marks
or it follows conditions such as delete, download,
or read and the schedule.
So this is where I was talking about we,
we monitor the baselines for hourly, daily, and monthly,
and whether it's sensitive data or all data.
And there's a, there's a, an important distinction here.
If a user starts mass downloading files
but they're not sensitive,
then is it really a problem to investigate?
Right? So we give you enough context to be able to make
that determination and move forward with your analysis.
We send out alerts to the data source owners,
which are defined when you add the data
sources into the platform.
You can add other members here
and base it on the alert severity
and even particular regulations.
So all of that is built in.
This particular one does not have an automation configured,
but I do have it set up in the ransomware environment.
So you'll see that here shortly.
But imagine that you hit a trigger
where a user is downloading three times, four times
what they normally would during a period of time.
We can go ahead and create an automation
that would pause the session or stop the session
and flag it for further review.
So that's how the rule set is configured.
But let's dive into the actual incidents themselves
and see what are going on.
So we have six incidents that happened in this rule set
and two users as a part of it.
So if we go in, it just so happens to be me and my boss.
If we look here, we've got incident five West Kennedy
hourly threshold exceeded.
I hit 11 unique objects.
I wrote, I had 381 reads
and the state of the incident is open
because it hasn't been looked at yet.
And when I open this incident,
I get very pretty chart showing
very obviously when this occurred.
But what's more important is looking at the baseline.
So if you see here, my baseline is pretty steady,
apparently I read 50 files every hour all day long,
and then it pops up a little bit around three o'clock
where I apparently have a burst of energy
and then it goes back to the baseline again.
But what happened today
At three o'clock, I must have had an extra coffee.
I read 381 documents instead. Triggered an alert.
I look, start looking through here.
There's some interesting files in here.
These are all the files I touched during that period
of time that caused the alert.
This looks like it could be a driver's
license employee info.
That's interesting. So there's,
there's some interesting data here
that we should probably dive into
and see what else is happening.
So let's, let's dive into my user specifically.
So if I look, I definitely got into some funny things.
So there's a, a, a tax freedom doc, uh, pay stub.
Yeah, we've got somebody's pay stub here for Donald Duck.
Apparently he's not diving in his big pile of coins.
Oh, that wasn't Donald, was it?
Anyways, um, so I'm looking at pay stubs.
I know I'm marked in here as sales,
but I'm technically in the marketing department.
Either way, sales or marketing
shouldn't be seeing pay stubs.
So that's a problem. So I can close that out.
See, okay, yeah, this is definitely a problem.
What else am I seeing here?
Or I can skip by going through each
and every single piece of data
and I can go over to attributes
and see what types of attributes I have access to.
I'm gonna focus on the high sensitivity ones.
Why on earth would a contractor employee working in sales,
I think is what this one said I was working in, have access
to credit card ID number, proprietary
and internal data, US driver's license,
social security number, and a passport.
Probably not something I should have access to.
What we can do is either drive straight into individual
objects where those are owned or we can go back
because in the case here,
we're actually looking at an incident
of that anomalous behavior.
So we just want to go back and we
say, yep, this was a problem.
Uh, and I can either decide right now to suspend the user,
which is likely what would happen if this was in production,
or I can, you know, put it on hold or detection confirmed,
and then write a note
and that would be logged in the audit log of what happened.
Pretty powerful, and it gives us a lot
of contextual information to make our decisions.
That's Yuba in a nutshell.