When I first started into cybersecurity for the first time ever, we went through this entire process
about learning through logs and going through that process at the very first time as a brand new person,
it looked incredibly confusing to me.
I was looking at all these little numbers in Wireshark.
It was talking about numbers over here for IP addresses and port numbers.
And then there's this little section talking about, well, this is the rudimentary of what it's supposed
to be.
And it's very easy to get very confused very, very quickly.
Cybersecurity is more than just talking about technology.
It's about the people involved.
It's about interfacing that technology with the different aspects of human life.
And it's about interfacing human life with technology.
Now, I know I just went three different routes about technology and human beings, but I really want
you to understand the perplexities that are involved with human beings and cybersecurity.
Cybersecurity has been blowing up from the get go from different avenues of job growth, from technology,
from all aspects of the life cycle that we as human beings not only record technology, but how we interface
with technology as a whole.
From the days when I actually had hair still on my head and we started talking about DSLRs, where we
literally sacrificed a computer to get online before we could even interface with America Online, a
tool that most of you probably never even used.
Um, you have to understand that logging in its simplistic nature, is where every cybersecurity analyst
begins with.
We need to understand how those logs interface with technology, where we're getting this information,
and how that interface is transitioned from the computer standpoint all the way to the pain point where
it goes to the SEM.
Cybersecurity is an intermix of understanding human beings.
How are human beings interfacing with that technology?
Are they clicking on a link?
Are they using it for gaming?
Are they using it for different programs?
How do we make technology useful not only in an ethical but a secure manner.
And that really encompasses cybersecurity as a whole.
And your job as an analyst to make sure that people are using it in a secure, ethical form.
But when it's not used in that outline, how do we correct it?
How do we identify the problems that are associated with technology and how people are using that technology,
whether from an evil standpoint, from a mistaken standpoint, or from the way they're supposed to be
utilizing it?
Not only that, but as a cybersecurity expert, you need to understand what does baseline traffic look
like in a day to day basis.
But how is that information utilized when something's not being used the way it's supposed to?
Oftentimes, brand new analysts come into the fact of logging and they go, oh, this looks like malicious
when it's really not.
And then we look at some traffic and we identify as malicious when again, it's really not.
And so your job with cybersecurity as an analyst really kind of begins here at that logging standpoint.
And how we utilize logs to identify malicious use versus real use.
As we go through, we're going to discuss logging software defined networks, operating system hardening,
public key encryption, and how encryption utilizes it.
We're going to go over data protection.
We're going to go over, uh, different aspects of technology and networking throughout this entire
course.
And it really begins here.
Logging really begins with detection and monitoring of systems.
How do we detect information that's going from one system to another?
Every system, whether it's an IoT device or a PC or a macintosh, a Linux, it doesn't matter what
it is.
It could even be your smart fridge that's on the line.
Any computer device, regardless if it's online or not, produces a log of some kind that can be utilized
by a cybersecurity analyst.
Your job as an analyst is to identify and monitor those different logs going into the system.
Now, that sounds a lot more perplexing than what it has to be, because if you think about it, and
I just told you that every network device on your entire system is producing a log, and that you have
to utilize that log to find out what's going on in your network, it can get overwhelming very, very
easily.
We're going to get into Sims and how Sims interact with our network a little bit later.
But for today, I just want you to understand that we can use logs to detect and monitor different outputs
within our system to define what's going on.
To do that, we can use those logs for incident investigation.
If something did happen, how do I find out what it was interfacing with?
How was it acting on our network as a whole?
We can use it for compliance and auditing standards to make sure that we're doing what.
Third party audits require of us.
Are there legal requirements that we need to interface with?
Are there auditing requirements that are internal to our own company that we have to utilize?
Logging provides that aspect as well.
We can use logging for alerts and notifications.
If something's going wrong with our system.
It produces alerts.
That alert is then confined to a log.
That log is then read by different aspects of our network that then produce alerts to us, and notifications
to tell us what's going on.
We can also use logs for preventive measures once something stopped.
If I have an antivirus program that stopped a virus, I want to know about it.
I don't want it to just go, Yeah, I stopped it and not tell me about it.
Think about a denial of service attack or distributed denial of service attack.
It's going through and reading our systems.
We need to know about that.
We don't want it to just correct it and then just not tell us about it, because it could be providing
or a precursor to a bigger attack.
This all provides us with a baseline establishment of logs.
What do I mean by that?
We have logs and day to day use of our computer systems, and we often talk about malware infecting
those logs or how those logs are used after an incident.
But what does normal traffic look like?
In order to provide in order to see malicious traffic, we need to first understand what a normal system
is operating on on a normal work day.
Now, baseline logging or baseline establishment should be on a day to day basis, a month to month
basis, as well as a yearly basis.
And what I mean by that is that Christmas traffic on December 25th, which is a Wednesday, is going
to be different than Christmas traffic.
Uh, on December 25th, on a Thursday it could differentiate between those two different days just because
one is on Wednesday versus Thursday.
But it could also be different because one is on Christmas Day versus Christmas Day, and how it falls
into the different aspects of what we're looking at.
What I mean is, what is Christmas Day on a Thursday in comparison to Valentine's Day on a Tuesday?
Does it have some interjections in there?
Does it have some differences?
We need to have a baseline assessment of our network on a given day.
We also need to be able to look at trends.
2023 could be vastly different from 2020, depending on the different network and what's going on in
our systems, even if the days are the same.
And that's where an annual baseline comes into play.
We want to continually update our baseline, but we also want to be able to use it for what's going
on in our systems.
We don't want to have this knee jerk reaction of, hey, my traffic just went up by a one gigabyte moving
out of our network on a Tuesday from week to week.
If that occurs, that could be establishment of a of a malware.
But it could also be a problem where we just developed a new product that's being sold online.
And now all of a sudden people are reading into our network a lot more than they were even a week ago.
This all provides that baseline of establishment and logging, and provides us cues in how we utilize
logging to prevent and detect different attacks throughout our network.
We often look at log ingestion as the collection of different logs.
We can do this through collecting different sources like we talked about before, from IoT devices to
smart refrigerators.
But more likely it's going to be from firewalls, IPS, IDs, different clients on our network as a
whole.
We can look at the collection methodology based on different aspects of technical infrastructure used
inside of our network.
But we can also import logs as well.
When we talk about importing logs, we're really referring to I've got logs on other systems.
How do I import them into the major system that I'm using to read all these logs?
I want you to picture yourself inside of a network infrastructure with a thousand different clients,
5000 different IoT devices, not counting the firewalls, the servers, the switches, the routers.
That's way too much for one person.
And so we can use something called a sim, uh, which is going to take all those logs and import them
into a central repository that allows us to not only automate them through AI and machine learning,
but allow you to go through and look at those logs in a more easily readable format to depreciate.
Hey, this system is connected to this system, which is connected to this system, and follow the logs
where you're supposed to.
This is where we import logs into a central repository.
We also are going to process those logs.
We don't want to do that manually because as I just said, going through five different logs is going
to make you pull your hair out and be bald like me.
That's not something we want.
We want to use analysis to go through those logs using automated processes that make it easier.
And then when we're done using analysis to go through those logs, we want to store them both in the
raw format, meaning how the logs were initially provided to us, but also in the format that has been
reframed for our SIM architecture, meaning that certain things have been moved or rerouted or even
removed, uh, configured in a different manner so that it's readable by that one central repository.
So in aspect we're actually having two logs, the raw format and the format that's been configured for
our SIM to read through.
There's also different logging levels.
Different logging levels are attributed to where I'm getting the logging from.
Is it a different source IP address?
Uh, a windows machine may be different from a mac machine, which would be different from a Linux machine,
which is also different from an IoT or a.
You get the point.
Different source IPS provide us with different logging levels.
And those operating systems, or those machines operating at those IP addresses may provide a bigger
log or a less intrinsic log, or less accurate log, or less detailed than a different machine.
Windows machines often provides a very detailed log of what's going on, where an IoT device may not
provide us all that much detailed information, so our IP addresses matter in that.
In that perplexity, we also have to look at destination IP addresses.
Where is the machine interacting with another machine.
Is it going from machine to machine or peer to peer?
Where I've got one client talking to another windows client, or is it going through a switch first?
Those matter and getting those logs from those different devices, playing a bigger picture.
And we need to be able to track those different pictures throughout our logging sphere.
We also need to understand different ports, protocols and services that are operating from those different
clients.
We want to be able to track usernames and domain names as they're going through, and where the logs
are going from to where they are going to, and the different domains in which they interact.
The nature of the event.
Do we have an alert?
Is it just a remedial log that's saying, hey, I did this, I just opened up communication protocol
or is there malware involved?
Whether I'm an IPS, the nature of the event matters.
We also want to be able to provide the event ID, and an event ID on a windows machine is going to be
different than an event ID on an IPS, which is going to be different from a different machine, and
so on and so forth.
And then we need to look at timestamps.
Timestamps are critical in identifying different logs because it's going to be able to interface properly.
I want you to imagine if you've got a log that's not timestamped, and it happened at 12:01 a.m. last
night, and then I've got another log at 12:01 p.m. today.
We may identify those different logs in the same complex algorithm and inadvertently combine them to
match each other, which just screws everything up.
So those timestamps need to be very detailed and very accurate, not only from Am to PM, but also from
day to day, year, month, date.
Those all need to be properly tracked in our logging levels.
When we talk about time synchronization, which I kind of hit on a little bit before, we have specific
protocols that introduce those.
The first one is the Network Time protocol.
This one is usually used within our logging algorithms to identify when something occurred across the
board.
We use this almost in every network that we utilize today.
But then we have something that's called Precision Time Protocol or PTP.
PTP is more utilized on satellite networks or and I don't mean satellite as in dishes, but satellite
as in different from our home network.
Let's say that I've got a piece of machinery or an IoT device that's off site operating somewhere else,
and I need very precise timing on it.
Maybe it's a temperature gauge or a SCADA that's associated with it.
Um, with precision time protocol, I went down to the 10th of a 10th of a second.
And so it needs to be very precise in nature, and it needs to be fluid within the entire network.
That's where PTP comes into play.
And then we have something where GPS like synchronization.
When I worked in telecommunications in the cellular network, we would use GPS time synchronization
because we had a lot of different satellite sites or sites that were off from the main server network,
those different cellular towers all over God's green creation.
Those all use GPS synchronization so that they could talk to one another and provide synchronization
in order to report back to the main server architecture.
And so we use GPS synchronization as comparison to network or PTP.
Throughout this entire episode we talked about the different logging mechanisms.
We talked about the importance of timing.
We talked about how the different logs interface with one another, and how we can use a SIM to digest
and import those logs to give us a bigger picture.
We really went through and identified logging at a baseline level versus logging at a level that may
indicate different compromises or indicators of compromise.
As we're going through the entire structure, logging really provides that forefront of where we are
versus where we are.
When an incident occurs or when increased traffic occurs.
It's important to realize that logging serves as a baseline indicator for our system as a whole, but
it takes human intelligence and you as a SOC analyst to identify the different logging levels and not
have a knee jerk reaction where, hey, I just went up by one megabyte.
Obviously, that's an incident.
Human intelligence interacting with logging is what cybersecurity is all about, and how you can be
a better analyst by understanding those different complexities of logging on your enterprise environment
as a whole.