As a cyber security analyst, we may sometimes be looking at ourselves from a psychological point of
view.
What do I mean by that?
I really mean that we look at people and we people watch.
We get to see what they do, how they interact with different items, and how they cope with different
mechanisms.
In an electronic environment, this is often referred to as user behavior analysis.
And that's what we're going to cover today.
In this episode, we're really going to go over what constitutes user behavior analysis.
And then by extension entity behavior analysis.
Well it's a short episode.
I would caution you to pay attention to it, because it really does play into the fact that we need
to understand what our users are doing on our networks as we're moving forward with technology.
So user behavior analysis is really the idea that we're looking at different perspectives of a specific
user or user organization.
This means that we need to identify what is the standard that our users interact with the different
programs or technologies that are associated with each of the departments.
Sometimes that's an individual, sometimes it's an entire department, regardless of which aspect you're
looking at.
We need to understand that I have a certain amount of users that are using a certain activity on technology
on an everyday basis.
What do I mean by that?
If I've got a lot of different users, say, in the HR department, and they typically use windows based
machines and Microsoft Office, along with Microsoft Edge as their primary forms of communication and
work styles throughout the day.
Then I know that that baseline behavior is normal for them.
And if I have a subset or a single person within that group that suddenly starting to use Firefox,
or maybe they're starting to use different software programs associated with their job function, then
that would be constitute abnormal activity for that user group.
Now, that's not necessarily bad.
It could just be that that user prefers Firefox over, say, Microsoft Edge.
However, what if they start accessing different folders or servers that that group doesn't normally
access?
This could constitute an objectionable abnormal activity.
And this is where using user behaviour analysis comes into play.
What are those users actively doing on a normal basis.
And when I constitute an individual user, it might be okay because that one user is using Firefox all
the time as comparison to Microsoft Edge.
It's perfectly legitimate.
That's just their prescribed or preferred browser that they normally utilize.
Let's say that I've got that one user that normally uses Firefox after week two of on the job.
That's fine, but now they started accessing web servers that aren't necessarily something that they
would normally access on a day to day basis.
That could be abnormal behavior, or it could just be a term in which case the user suddenly decided
to use different aspects, methods for that prescribed activity.
Maybe they're moving through research, through the HR Air Department.
Maybe their job or their, uh, duties and responsibilities reflect that change from the average normal
behavior for that department.
That's quite possible, let's say, and turn this around and say, now, that user, after three years
suddenly starts using or starts going to specific websites that are somewhat questionable.
Is that a retraining methodology that we need to utilize, or is that abnormal behavior something that
they're not aware of?
By tracking the user's normal behavior, we could identify if malicious activities are imposed on that
user account.
Let's say that abnormal behavior is 2 a.m. in the morning.
I quite honestly, I like to use 2 a.m. in the morning, but they start going to websites at 2 a.m.
in the morning, but their normal work hours are literally from 8 to 5 p.m. again, abnormal activity
on the network using that specific user.
However, what if I've got an entire department that starts accessing that website?
Is that abnormal behavior, or is the HR department moving in a new direction.
If they're moving in a new direction, that's fine.
We just need to be aware of that, to associate that new behavior as part of their baseline activity
within that department.
Abnormal behavior really provides us with an analysis that relates back to a malicious activity or possible
malicious activity.
Then there's something called impossible travel.
Impossible travel is where I've got a user that normally works in, say, Seattle, and now all of a
sudden they're in New York and then back in Seattle within a two hour time frame, that's impossible
to happen.
There is no way that a user can move literally from Seattle to New York within two hours and start communicating.
Teleportation doesn't exist yet, and so that's not a feasible recommendation of that travel perspective.
If you think about it, it takes the average user about seven hours from fly from Seattle to New York.
Now, that's not counting wait times in the airport.
That's not counting car taxi travel from the airport to the hotel.
That's just air travel.
And while that may be possible, two hours is improbable.
And so if we detect where the location has changed theoretically in a major way between one point to
another, we refer to that as impossible travel, and we can thereby lock down those accounts.
We can automate that process through our Soar and Siem environment, to where something like that is
impossible to interact.
And if we identify and detect that problems, we can quickly lock down accounts, thereby reflecting
malicious activity, and stop hacking it before it actually takes hold of our network.
By extension, we have something that's called entity behavior analysis.
Now, unlike user behavior analysis, we're looking at the organization as a whole, and we're scrutinizing
the behavior of specific entities within our network.
And Indy is a specific machine or a specific department within the environment as a whole.
Now, we talked about departments as part of user behavior analysis.
When we say the average of all the users say in the HR department, interact with a specific server,
but we can also look at it from an entity perspective, where the behavior within a specific server
or a specific HTTP request, or the different locking mechanisms within a physical environment are affected.
Let's take this in a scenario based if I've got a specific server, i.e. an entity that normally is
interacted with on a daily basis between, let's say 6 a.m. and 3 p.m., however, traffic quickly curtails
or drops off after 330.
Then that entity's behavior is, uh, the traffic goes from very early in the morning, 6 a.m. spikes
up, say about 9 a.m., kind of stays at that high point till about 12 and then steadily curtails or
drops off till by 330.
I shouldn't have access to that environment on a regular basis after 330.
This is entity behavior analysis as compared to user behavior analysis.
We're looking at the actual item, not the user itself.
In this case, I've got a server where the, traffic on corresponding on it drops after 3 p.m. or 3:30
p.m., in which case I can see that if I've got a shunt in traffic curtailing up or at about 6 p.m.,
that goes against that.
Any behaviour I may have a early threat detection process through malicious use.
This can also reduce false positives.
If we go through and we identify that normal traffic is between 6 a.m. and 330, and we're detecting
a lot of malware perspective to that specific device, but that device provides specific proprietary
software on it.
We scan it.
We know that that stuff is on there already because we've run scans on the past.
That's part of that entity's behavior.
Meaning when I scan it, we already know those vulnerabilities are there.
We already know and annotate those different vulnerabilities.
And so we can identify if there's a false positive associated with it, or if, in fact, those vulnerabilities
have already been written off because we're aware that they exist.
It can reduce those false positives because we know they're already there.
We can also improve our incident response because if we're not subjecting our entities to specific problems
on that specific piece of equipment because we already know they're there, then that entity's behavior
is associated with it.
This improves incident response because we're not going into the process.
However, we let's flip this around.
If I've got a environment or an entity that's behaving in a specific manner on a day to day basis,
a, i.e. from 6 a.m. to 3:30 p.m., and then all of a sudden we see that upward traffic at, say, 7
p.m. or even 9:30 p.m. that could pose a problem.
We can improve our incident response because we shouldn't see traffic on that specific device.
After 3:30 p.m., we can quickly analyze that and lock that device down.
This is a way that any behavior analysis works in comparison to user behavior analysis.
Remember, entity is specific hardware or physical devices on our network, entire departments or segments
of our network.
That's the entity in which we're referring to user behavior analysis.
That's people, places, that type of thing where we have physical assets in relation to our people,
not the actual equipment that's come into play.
User behavior.
User entity behavior.
That's the entity or the physical device.
Throughout this episode, we talked about the psychological conditions of people and why the user behavior
analysis is important.
But we also talked about the different mechanisms or hardware that's associated with it, including
software that we can go into practice with.
Both of those play an important role as a cybersecurity analyst to identify and understand which one
is which and how they interact with our company or organization as a whole.
And your Cisa exam, I would take in perspective those specific different determinations between the
two.
You might see a scenario based question dependent upon identifying the difference between a user behavior
analysis versus an entity behavior analysis, and understand the acronyms opposed between the two UVA
versus EBA.
If you can do that, this is a very high level purpose of the exam.
You shouldn't have any troubles with this little section.