As a cybersecurity analyst, your bread and butter is what we call a seam,
a security information and event management system.
The seam really is the heart and soul of any regular sock that you should be aware of.
Now, cys A doesn't have you going into depth with a seam 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 seam is and how
it interacts with the different systems which we're gonna talk about.
Today.
We're,
we are going to talk about a security orchestration,
automation and response system and how that interplay with both our
seam 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 of episodes,
we're going to talk to a sock manager that really goes to
the different tools and utilization of those tools in a sock atmosphere.
We're gonna 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 sock 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, this taken 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 1000 clients,
the natural knee jerk reaction is to throw
1000 different client logs into that sea 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 seam gets its power.
A seam 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 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 of 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 gonna start at the client
and then I'm going to go to the switch. Wait a second. Did it come to my 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 the router,
it can be very confusing very quickly.
And so where it seams 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 seam 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 process of affecting other clients,
other endpoints, other network devices?
And if so how and when we are able to in a seam
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 does 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 us
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 the security analysts,
which is the role that you're trying to achieve or are already achieving.
And there's an aspect I've got a piece of m
there 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 IP S device.
But what happens if it took effect before the IP S 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 an ready to made script.
This is where the source really cuts his 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,
security analysts.
It also can prioritize different vulnerabilities that
are taking effect within our systems.
In this way,
you can identify 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 affects a client.
The client is now affected by that malware through the source system.
The V the antivirus program was unable to stop it.
But the network diffusion prevention system or the network detection system
within the system identified it as being malware.
Our source identified the malware through the
n.
So 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 properly acclimated to that source will then carry out the command.
Let's say that the antivirus program didn't do that.
It's not functional or it was the malware taken over it.
So it's not providing that claw
we had inserted as part of our security feature.
If the AB doesn't act responsibly that the
source 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 m
poses an issue to our network.
The source then goes through and isolates that system off of our
network through automated means this is where the source gains its power,
that automation process based on what it's seeing from the outputs of the network.
It's sort of like a I most people related 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 source 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 IO 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
running through isolation.
And so to re emphasize,
an EDR system is part of your sore 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 of 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 in 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 wall log is more often than not set 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 seam 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 Steve VBE.
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 that CYS A 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
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 timestamp code.
The second one is the actual time of 1222 03.
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,
but this is based on the local time associated with that machine.
Now, this could give us some clues if our log is for 1222 0 3 p.m.
and the date is 621 and somebody messed around with the 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
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 cys A 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 totalsem
0.001 dot 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 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 shows us as a Logoff.
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 S 15.18.
And then our account name,
the actual person associated with this Logoff activity was totalsem 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, totalsem
0.001 local could be different from our account name which is total sum 001.
In this case, it just happens to match. We can see the account domain is totalsem
the domain it's operating on.
And then the log on ID is this
specific hexadecile 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
log on which would be a logon type two.
This event is generated when a logon session is destroyed and may
be possibly correlated with a login event using the login id value.
Login I DS are only unique between R
boots on the same computer.
Meaning that the login 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 logoff log from a Windows environment.
But how can you utilize this in ac Ys a 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 logon type?
Well, if we see a Logoff and then a reset, well,
then it just told us right off the bat that log on
A DS 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 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 cys A but other
certification exams where they specifically denote,
hey, this event occurred and they give you the 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 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 titan 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 a basic form of logic.
A lot of people when they go for their exam, they don't take the uh the white board.
And a matter of fact, I did that on my last cys A 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
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 accurate,
depict what you're looking at.
In this episode,
we covered both the seam 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 sore environment
to provide us some endpoint detection and threat
analysis through monitoring and keeping our network safe.
Both the seam and the source 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 cys A you can expect to see different questions
attributed both to a seam environment as well as a source.
And specifically the EDR,
you need to memorize the different aspects of
the acronyms throughout the CYS A 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 cys a environment,
different questions that are scenario based relating back to
the seam environment as well as the soar environment
and the EDR as part of that.
So environment, remember when it talks about automation and response,
we're more attributed to the source environment.
If we're talking about logs and how to
utilize those logs in an easy trackable environment,
we're talking about the seam.
That is that clear delineation between the
two where we're talking specifically about endpoints,
then we go transverse over to that Edredr is
part of the overall so environment,
but the source 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 source 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 cys A exam.