When I first started into cybersecurity for the first time ever.
Uh 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 the diary of what it's supposed to be.
It is 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
uh DSL S where we literally sacrificed a computer to get online
before we get an interface with America online.
A tool that most of you probably never even used.
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 pinpoint where it goes to the stem
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
as it will 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 this baseline traffic look like on a day to day basis.
But how is that information utilized
uh when something's not being used, the way it's supposed to,
oftentimes a 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 and we're going to go over
different aspects of technology and networking throughout this entire course.
And it really begins here,
login 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 A Macintosh A Linux,
it doesn't matter what it is, it can 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 gonna 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 alert,
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 notification to tell us what's going on.
We can also use logs for preventive measures was 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 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 can differentiate between those 200 days
just because one's on Wednesday versus Thurs.
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 establishment 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 the 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
a
sting and provides us cues and 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 idss, 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 1000 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 A I 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 the way 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 we, 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 RSI architecture,
meaning that certain things have been move or rerouted or even re
uh 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 wall 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?
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 F you get the point,
different source IP S 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
log
or less detailed than a different machine.
Windows machines often provides a very detailed log of what's going on
where IoT device may not provide us all that much detailed information.
So our
IP addresses matter 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?
Pay 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 user names and domain names as they're going through
and where the logs are going from to where they were going to and the different
domains in which they interact, the nature of the event. Uh Do we have an alert?
Is it just a remedial log?
That's saying, hey, I did this,
I just opened up a communication protocol or is there malware involved
whether I'm an IP S the nature of the event matters?
We also want to be able to write the,
the event ID and an event ID on a Windows
machine is going to be different than an event ID
on an IP S which is going to be different
from a different machine and so on and so forth.
And then we need to look at time stamps,
time stamps 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 time stamped 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
uh and
inadvertently combine them to match each other which just screws everything up.
So those time stamps need to be very detailed and very accurate,
not only from AM and 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 PTPPTP 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 offsite
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 1/10 of a second.
And so it needs to be very precise in nature
and it needs to be floated 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 and 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 can talk to one another
and provide synchronization in order to report
back to the main server architecture.
And so we use GPS
asynchronization 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 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 G jerk reaction where A 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.