As a cybersecurity analyst.
You're bread and butter is what we call a Siem, a security information and event management system.
The Siem really is the heart and soul of any regular SoC that you should be aware of.
Now, Cisa doesn't have you going into depth with a Siem system.
They don't require you to understand how to read one or all the perplexities of it.
You just need to know what a Siem is and how it interacts with the different systems, which we're going
to talk about today.
We're also going to talk about a security orchestration, automation and response system, and how that
interplays with both our Siem system as well as our infrastructure as a whole.
This episode is going to be quite quick.
But the great news is in the next couple episodes, we're going to talk to a SOC manager that really
goes through the different tools and utilization of those tools in a SoC atmosphere.
We're going to do a slight Q and A, and then we're going to follow along with the different tools that
you could expect to see in a SOC environment, a security information and event management system is
exactly like we're showing here.
It represents a centralized approach to security management.
We get the different logs that are accessible throughout our entire infrastructure.
Now let's take it with a grain of salt.
When you're setting up a scene for the first time, it's natural that we want to provide that scene
with as much logs as humanly possible.
If I have a thousand clients, the natural knee jerk reaction is to throw a thousand different client
logs into that same system.
However, this is often a mistake.
What we really want to do and how most professionals set it up is we take the hierarchy into play.
If I've got a switch that serves those clients, then I'll pull the logs off the switch as opposed to
the endpoint clients.
And this is really where the Siem gets its power.
A Siem system operates by grabbing the logs from the routers, the switches and the different network
available systems in our enterprise environment and puts them together in an easily readable and trackable
format.
Now, I want you to think about this as a security analyst in your own home network.
If I've got a computer which is connected to a switch, which then is connected to a router, and then
if you're in my house, I have all these IoT devices that are associated with it as well, then it wouldn't
take much to be overridden.
If I have a piece of malware that comes into play at my endpoint client, the natural reaction is to
go, oh, I've got this client, I need to find out where it came from.
So I'm going to start at the client and then I'm going to go to the switch.
Wait a second.
Did it come from IoT devices.
Let's go and inspect all my IoT devices.
And then.
Oh, I found this IoT device.
We have to go back to the switch and then over to the router.
It can be very confusing very quickly.
And so where it seems power come from is that I can put all those logs into a centralized service that
allows me to track it very easily.
So instead of examining the logs from each individual system, I can go through the Siem and say, oh,
there's a piece of malware that started here, let's track it.
Through that tracking process, I can identify every network piece of equipment that interacted with
that same packet as it was going through the process.
I can also identify if that same packet or that piece of malware intersected within my other devices.
Did it expand?
Did it go through the different processes of affecting other clients, other endpoints, other network
devices, and if so, how and when we are able to end a Siem environment?
To see all of that in an easy to use interface.
It also provides different interactions through reporting structures.
It also provides edrs.
It can really kind of signify a central standpoint where we get a lot of information and one heads up
display that makes cybersecurity so useful and so much easier to utilize.
The second thing I wanted to talk about was security, orchestration, automation, and response.
This is an integrated tool structure where we provide different automated tools into an easy to use
profile, meaning that I can have one tool that scans, I can have another tool that looks for maybe
web application interfaces.
I can look at another tool that just basic scripting, and I can put them all into one easy to use foundation
for my security orchestration.
This really goes hand in hand with a Siem device where we're going through, and we're able to automate
a lot of responses into play for different incidents.
So I want you to think about it from the perspective of a security analyst, which is the role that
you're trying to achieve or are already achieving.
And this aspect, I've got a piece of malware that's gone through my system, and it was stopped by
the intrusion prevention system through that intrusion prevention system.
It's identified the problem and it's immediately stopped it at that IPS device.
But what happens if it took effect before the IPS?
Or maybe we only have an IDs?
That source system could provide an immediate response.
That immediate response could be to prevent the system from moving forward.
Maybe the immediate response is to purge that system off that that file using a ready made script.
This is where the saw really gets its power.
It provides an automated response based on the input that we provided based on an event or an alert
occurring.
This can come into play on different factors and really streamline and make more efficient our jobs
as security analysts.
It also can prioritize different vulnerabilities that are taking effect within our systems.
And this way, you can identify a different vulnerability through the vulnerability assessment process
and then provide an automated response based on that priority.
So let's break this down a little bit.
I have a piece of malware.
It comes in and it infects a client.
The client is now affected by that malware through the source system the AV.
The antivirus program was unable to stop it, but the Network Intrusion Prevention system or the network
detection system within the system identified it as being malware or Saw identified the malware through
the Nids through the Network Intrusion Detection System provided that alert.
That alert then goes through the system and identifies it and says, hey, antivirus program, you need
to do this.
The antivirus program, if it's a properly acclimated to that store, will then carry out the commands.
Let's say that the antivirus program didn't do that.
It's not functional or it was.
The malware had taken over it.
So it's not providing that clause we had inserted as part of our security feature.
If the AB doesn't act responsibly, that the store will then conduct the next process, in this case
to delete the system or segment or isolate that system off of our network as a whole, because that
malware poses an issue to our network.
The sword then goes through and isolates that system off of our network through automated means.
This is where the sword gains its power.
That automation process, based on what it's seeing from the outputs of the network.
It's sort of like the AI.
Most people relate it to that, but not really.
We're going through and we're telling this system, if this happens, then do this.
If this happens, then do this.
It's run.
It's like running a basic script, but it's overall the entire network as a whole.
It provides an orchestration of different features across different subsets of our network.
It automates the process and then responds to alerts and activities or events on our system through
the enterprise environment.
As part of your Soar automation response, we commonly use something called endpoint detection and Response,
or EDR, sometimes referred to as endpoint threat detection and response.
Through endpoint detection and response, we can monitor different aspects of our network at the endpoint.
This would be your clients, maybe your IoT devices, basically anything on your network that's considered
an endpoint.
The great part about a good EDR system is that it can respond to malicious activity very quickly, and
stop that activity from progressing or spreading across your network.
It often removes the offending asset from the network, if needed, to stop it from spreading through
isolation.
And so to reemphasize, an EDR system is part of your store environment that really provides us the
ability to not only monitor and analyze the traffic that's going back and forth from our endpoint devices,
but provide an automated response back to it.
Our last couple videos have gone into somewhat of detail on how we utilize logs for both the security
environment as well as a data or information technology environment to figure out the health of our
system within a security environment.
More often than not, those logs are then detailed and both a raw format or in an environment where
we curtail those logs so that it matches with each and every other log that it's in our system.
You need to understand that not all systems or network devices produce the logs in the same way, and
so we need to break down those logs and then provide them into our seal environment.
And a standardized format.
That standardized format is then read by the scene, which then we utilize to track down what's going
on.
The raw log is more often than not sent back to a central repository in the cloud environment, where
it just sits there until we don't need it anymore.
Usually a year, sometimes three, depending on your individual network's needs.
Now we've gone into these logs, and we've stated repeatedly that you can use a Siem system to read
logs and then go through and identify what's going on within your network.
We can see that if malicious activity is going through our network, we can somehow track it.
and then correlate those different log items with one another within that same environment.
But we never really went into detail on how to read those logs.
And that's what we're going to do today.
Before you in the screen you can see a standardized log from a windows environment.
The good news is, is that Sisa does not expect you to understand every event, code, or event type
ID associated with the log.
You need to have a basic, high level understanding of what's going on within the system, and then
how to correlate that information back to other logs or other events that are happening on your network.
We'll go into a little bit more about that later.
Let's read the log first.
This log started on 621 of 2024.
It's pretty easy to read because it's right up there and gives us the date time stamp code.
The second one is the actual time of 1220 203.
Now, it doesn't tell us whether it's Pacific Time or Eastern time, which is pretty standard for most
logs on a windows environment.
But we have to take into account that this is based on the local time associated with that machine.
Now, this could give us some clues if our log is for 1220 2:03 p.m. and the date is 621, and somebody
messed around with that date timestamp, we should be able to go back to that domain system and find
out if the timestamp has been changed.
That would lead us to some basic information on our event log information or our log information.
We can see the login name is a security, meaning it's a security event.
For a log name.
We can see the event code, which we really don't need to know.
For Sisa as well as the event type, they're not really going to quiz you on this basic information.
Again, think high level.
We can see the computer name in this case is total SIM 001. local.
Now this is important because if we're looking at specific logs associated with this machine, then
we would need to know exactly where this computer name is associated with.
Our source name is Microsoft Windows Security Auditing, meaning that it's a security auditing log From
this specific computer name We can see the type.
It's for informational purposes only.
It also gives us a nice little record number, and it tells us that it's an audit.
We can see that its success is a task category of logoff, meaning that somebody logged off this computer
system.
The operational code is informational only, which we see again is right up here with the type of information
we can see a message.
An account was logged off.
This is what the log tells us when somebody logs off the computer system.
So now we have basic information that corresponds with another meaning that the message tells us as
a log off.
And we can see the task category was log off.
So those two match which is good.
We can see the subject and the security ID is S1 5.18.
And then our account name.
The actual person associated with this log off activity was total SIM 001.
This means that the account associated with it and the computer match up, which may or may not be important.
Remember that the computer name wallets total sim .001 One local could be different from our account
name, which is toll sum 001.
In this case it just happens to match.
We can see the account domain is toll SEM, meaning the domain it's operating on.
And then the logon ID is this specific hexadecimal format associated with the login name.
Finally we see the login type is level three, meaning it's a network logon as opposed to a local logon,
which would be a logon type two.
This event is generated when a logon session is destroyed, and may be positively correlated with the
long end event using the login ID value.
Logon IDs are only unique between reboots on the same computer, meaning that the logon ID could be
changed based on the specific reboot on the same computer, which means it could be different based
on what happened with the computer.
And that's important information that the windows is giving us.
So this is a basic log off log from a windows environment.
But how can you utilize this in a CSR environment.
And what kind of exam questions Can you see now that we've learned how to read this log?
Well, you might see cross coordinated questions where it's asking you specific questions on, hey,
based on this computer name, we saw these other events occur.
Now can we contribute that to this specific log on type.
Well, if we see a log off and then a reset, well then it just told us right off the bat that log on
IDs are only unique between reboots on the same computer.
So that can give us a hint into what's going on with the specific system.
It also tells us that somebody logged off onto the system.
If we see somebody else log on within, that's a timestamp period, or within the next log associated
with it, within the firewall or within a key information, then that would take place to notify us
that, hey, it could be a different account type or a different account ID associated with this same
log on.
And that's important information to take place.
Now I'm going to tell you I've seen some questions on different exams.
Not necessarily Sisa but other certification exams where they specifically denote, hey, this event
occurred and they give you this snippet of a log, and then they provide you with some more logging
information that you need to read and ask you to find the specific information.
Maybe they're asking you to find the malware or the user that associated to downloading a specific executable
or even an email, and this could provide us some key information.
However, I want you to pay very close attention to the date timestamp associated with the login they
gave you.
A lot of times they'll try to trick you and they'll change the login date.
And so you need to correspond the specific login date and timestamp associated with the information
that they're giving you within the question.
Make sure that when you're doing this cross formation or cross coordination between the different logs,
that you pay attention not only to the user ID, but also to the machine name or the computer name and
the type and timestamp, because they like to mess around with those as they're going through.
It's expected that you understand those different complexities and are able to sift through that environment
to answer the basic question.
Now, a lot of the questions they ask you honestly are very common sense based with the basic form of
logic.
A lot of people, when they go for their exam, they don't take the the whiteboard.
And a matter of fact, I did that on my last Sisa.
They asked me, do you want a piece of paper and a pencil?
And I said, no, I'm good.
Because based on my experience, I never really needed it.
However, with this new exam type, with the one I just took for CS 003, I would definitely take it
because it's nothing like one and two, where honestly, the logs and the information really wasn't
that difficult to comprehend.
So as you're going through that exam, make sure you take that whiteboard with you or that scratch paper
so that you can actually make notes, because you will be popping between screens on some of the questions
that aren't multiple choice.
And that could really be beneficial to you, so that you can go through and more accurately depict what
you're looking at.
In this episode, we covered both the Siem and the Soar environment and how to utilize those different
environments as part of our holistic viewpoint for security on our network.
We also talked about endpoint detection and response, and how that's part of our store environment
to provide us some endpoint detection and threat analysis through monitoring and keeping our network
safe, both the Siem and the store work together to provide us a holistic security environment in which
to operate from.
This is going to provide us a more efficient and robust security environment in which our infrastructure
can be more secure across the board.
In the Sisa, you can expect to see different questions attributed both to a Siem environment as well
as a store and specifically the EDR.
You need to memorize the different aspects of the acronyms throughout the Sisa exam.
I know I haven't said this before, but acronyms in my opinion, literally make up about 30% of the
exam.
If you literally just know what the acronyms are, a lot of the questions will actually answer themselves.
For instance, you may see an exam question talking about endpoint detection response that literally
says something like EDR you should expect to see within the scisa environment different questions that
are scenario based, relating back to the same environment as well as the Saw environment and the EDR
as part of that saw environment.
Remember when it talks about automation and response, we're more attributed to the Saw environment.
If we're talking about logs and how to utilize those logs in an easy trackable environment, we're talking
about the Siem.
That is that clear delineation between the two.
When we're talking specifically about endpoints, then we go traverse over to that EDR.
EDR is part of the overall saw environment.
But the saw environment doesn't necessarily have to include an EDR environment.
So if you get a question that's talking about automated response and it specifically references EDR
or endpoints, and it gives you both an answer from a Saw and an EDR, you want to go with the EDR.
It's the more relevant or the better answer because it's more attributed specifically to the EDR.
As part of our question, this should prepare you for your Cisa exam.