As a cyber security analyst, you should understand the different vulnerabilities associated with your
network, whether it's from a perspective of email or different systems, different operating systems,
even your servers, or even your basic infrastructure including your switches, routers and other items
on your network.
Believe it or not, IoT devices are considered to be part of your network as well if your organization
uses them.
Vulnerability identification and scanning is one of those things that you should really understand how
to do.
And there's two basic platforms that we're going to discuss in chapter ten, Openvas and Nessus, as
the biggest ones out there today.
Right now we're going to go over what those actually include, and then we'll highlight those videos
and understanding of how to actually run those scans and install them on your systems.
In chapter ten, before you get started and actually scanning a system, we need to go through the process
of understanding what a baseline scan really entails.
A baseline scan is a standardized baseline for your network operating on a standard day at a given hour.
We want to understand what is my system doing on a day to day basis, on an hourly basis, at different
times throughout the day.
I need to understand as an analyst, if my system is pushing out one gigabytes of traffic every second
on a Wednesday afternoon at 2:00 pm, because if that's my standardized traffic patterns throughout
every Wednesday, and all of a sudden now I'm pushing out 350GB of traffic every hour, then that could
pose a problem.
That's an indicator of compromise.
We need to understand that baseline scanning is something that goes into play at different levels.
It's not just about tracking the data, it's also about tracking the utilization of different ports,
protocols and what's available on our systems when we bring in vulnerability scanning into the fray,
we're also looking at different vulnerabilities associated with the different items on my network.
I need to understand if this port is open on a network and we have it unsecure.
Why do we have it under secure?
If that scan provides that as a critical component or a vulnerability within my network, I want to
know about it before something actually happens.
This poses two big reasons why.
The first one being if my standard operating procedure on my network is to say, have port 20 open.
I don't want to have everybody jumping up and down two weeks from now when they rerun that scan.
And now port 20 is open and it causes a lot of mess because people are saying that's unsecure.
And then we're devoting manpower, energy and money to fixing that issue when it was already a known
issue that we already documented.
And so why are we fixing it?
It's already been authorized to be on our network.
A standardized baseline for compliance on our network is more than just understanding the different
vulnerabilities.
It's also understanding the vulnerabilities associated with it.
From a compliance standpoint, if I'm using Pci-dss or HIPAA as my compliance protocol within my network,
I need to understand what those different compliances have, based on the vulnerabilities associated
with my individual network or systems associated with that compliance requirement.
A lot of times, we'll see a compliance requirement in one section or one isolated network within our
system, but not throughout the entire network as a whole.
We often do this because compliance is required for a specific system, and it costs more money to do
it across the entire system as a whole.
Whereas if I could just do one segment of my network for compliance, I'm usually going to go down a
pathway.
We need to verify our automated configuration standards.
If I have a router or a switch or even a server that I'm bringing online and something breaks, I want
to automate that configuration as much as possible.
If you have a tedious task that you need to do over and over and over again, we as human beings tend
to wonder.
We tend to go through our minds and start thinking about what I'm going to do after work, or what I'm
going to have for lunch or something other than the fact of what I'm actually doing.
Human beings suck at tedious things, and we know we do.
So what's the best way to do that?
Let's do a script and automate that process.
If I can automate the process to tediously go through a thousand different routers and change one setting,
then that's an automated verification of the process that's going to not only provide my workload a
little bit better for my employees, but their minds aren't going to be wondering and making human errors
throughout the process.
We also need to highlight inadequate scans.
What I mean by that is, if I scan a system and I'm only scanning to make sure there's a ping on each
one of those items, that really doesn't tell me anything other than what is out there at the current
time.
It doesn't tell me what the operating system is.
It doesn't tell me what the vulnerabilities are associated with it.
It just tells me that I have items on my network that use an IP address that's not very good as a cybersecurity
professional.
As such, we want to do more scanning a lot of times than less.
It's not enough just to do an IP scan.
Sometimes we might do an IP scan just to go through the process and see if there's a machine or a new
IP address that's popping up.
But for a baseline scan And for a regular intermittent scan, we want to do something that's a little
more hefty to it.
We want to understand not only what the operating systems are, what the ports are open, but we also
want to understand those vulnerabilities associated with it.
We go through this process.
We're going to show you the different scans that you can do and conduct as a vulnerability scanner.
The first thing I want to talk about is the difference between a passive versus an active scan.
A passive scan is simply a scan that we let go in the background of our systems.
A lot of times our SIM takes care of this, or our SIM takes care of this, and our saw automates this
process, and we're just listening to what's going on within our network.
We're really not pushing a button to make the system do anything.
We're just listening to the traffic as it goes from point A to point B.
Sometimes this will tell us if a new port opens.
Maybe.
I don't normally use a port 21 on my system, but all of a sudden one pops up and now it's processing
communication protocols on that port.
I didn't tell the machine that's operating on port 21 to tell me what ports is operating on.
It just started reporting that it's talking on port 21, and our automated systems picked it up through
a passive communication channel that points out an alarm that tells us there's a problem within our
systems, because I have communication that's unsecure, operating on a port that we didn't authorize.
Going through our systems, this is a good example of a passive scan that we might see on our systems.
In comparison, an active scan is me literally going to the system and telling me, hey, I want you
to report out to me what every port you have open that you're currently communicating on.
I also want you to provide the logs for all the different ports that you've communicated on the last
24 hours.
This is what's considered an active scan.
I send a command forward and the machine responds.
I'm actively asking for information, or I'm actively scanning that machine for different ports that
are available and open.
This is an example between an active scan versus a passive scan and the world of vulnerability scanning.
We take the same similarities to a new level on a passive scan.
I'm looking for different things like, I don't know, malware or ransomware that might be going through.
Maybe somebody's doing something they're not supposed to.
On my network, I'm not actively searching for it, but I am listening to the network to see what's
going on.
Again, if I have port 21 suddenly open and processing communication, that would be a vulnerability
that's introduced to my network, even though it's just a simple port.
And because my scene picked it up, I'm able to then grab that information and understand what's going
on from a passive standpoint.
On an active standpoint, I scan the machine, I'm looking at the software configurations, I'm looking
at the software versions, and it's reporting back to me via Nessus or Openvas, that it's not the most
up to date version of software available on that system.
Maybe there's a reason for it, maybe there isn't.
But the machine is actively providing me information because I'm scanning that machine with a third
party software that's looking for vulnerabilities.
This is the big difference between active scanning versus passive scanning.
From a vulnerability standpoint, there's two major points of scanning.
When it comes to vulnerability scanning, one is external scanning.
This is from an outside perspective.
Sometimes I want to know what the outsider sees.
If they're looking at my organization or my infrastructure from outside the internet, this would mean
that maybe a malware user or a malicious user is looking at my network, trying to gain information,
and sometimes it's a good idea to know exactly what they can see, because it could provide me a little
bit of security through obscurity.
And what I mean by that is that if the outsider cannot see the different communication protocols that
I'm using inside my internal network, maybe it's not a priority to fix those.
If I only have a limited budget or limited manpower in order to deal with that.
This is that public facing vulnerability that most malicious actors are searching for.
It's important to me, as a cybersecurity professional to understand what's going on from my network,
from the outside view, so I can properly delineate between real vulnerabilities that I'm afraid could
be taken advantage of versus those hidden vulnerabilities that maybe, yeah, they're are vulnerabilities,
but do I really want to spend the time and money to have them fixed?
Remember, as a cybersecurity professional, it's bang for your buck.
How much time, how much money do I need to spend fixing all these vulnerabilities?
Throughout your career, there's always going to be too many vulnerabilities, and we can't constantly
fix every last one of them.
So we must prioritize which ones we're going to pick.
Having that external viewpoint of what's going on from a malicious actor's eyes can help us determine
what vulnerabilities we need to fix right away, versus which ones can fix.
Then we have internal scanning.
Internal scanning is a comprehensive review of all of our systems with credentials, or from the perspective
of a security administrator.
I know that I'm operating on port 21 between two servers because it's a legacy system.
Maybe that legacy system doesn't have the capability of operating at a more secure channel.
From that perspective, it's a vulnerability.
We know it's a vulnerability, but can an external viewer see it?
And so the priority of that fix may be different based on an internal versus an external scan.
An internal scan is really going to provide us with a lot more leverage or a lot more visibility of
our internal workings of our network.
After all, I can see all the traffic and have full permission to access all the systems on my network.
Because of that, I can actively scan and I can go through all the processes associated with it to get
a good picture of every vulnerability on this network without this fear of being discovered.
Unlike a malicious actor where they're constantly trying to hide their footprints, as a cybersecurity
professional conducting an internal scan, I can blast through and I really don't care how much noise
it makes, as long as it's not interfering with my systems.
Agent versus Agentless scanning comes into play when we're looking at an agent scan or a local data
collection standpoint.
This means that we collect all the data, and we put it through a centralized server to store that data
within an agent environment, I can run different scans that go through the process and then store them
in a centralized point.
This allows me to identify the different vulnerabilities and the interconnected vulnerabilities associated
with it, meaning that I can look at a server that's connected to a switch and literally get a bigger
picture of what's going on between both those systems.
I can compare and contrast and actually see the pipelines and physical connections between them, because
it's an agent scanned.
I have a much more comprehensive review of all the vulnerabilities associated with it.
In comparison with an agent list standpoint.
This is via the network communication protocol, meaning I'm hitting it from a different perspective.
I'm hitting it from a machine outside the environment, whereas Agent Viewpoint is on the machine itself.
An agent list is on a separate machine looking at the systems and going, oh, this is going through
this communication and I need to see it on an agent list point of view.
I'm looking at it maybe even from Seattle or Georgia, where my network is actually in Florida.
This can provide some distilled point of view.
It doesn't provide as much coverage or detailed coverage, but it does provide me a broader overlook
of the network as a whole.
We can also see an agentless viewpoint where we're talking about different segmentations that are implemented
in our network or isolated networks, where we're doing a little bit here and a little bit there, and
a little bit over here to get a bigger overall picture.
Again, not as detailed, but does have its benefits in the fact that it's providing me a broader coverage
of what's going on across my network.
Then we have credentialed versus non credentialed.
Credentialed means that I log into the system.
I'm able to see the internal workings of that software.
I want you to imagine that you own a web page.
On this web page, you have full administrative rights, and you log into that system and program that
web configuration the way that you want.
Then you have somebody that's not configured to that they don't have administrator privileges, but
they can still scan the web page because they own part of that server.
This is the difference between a credentialed versus a non credentialed viewpoint.
Obviously if I log into the system, it gives me access to all the different viewpoints within it.
I can see the different configurations that you modified.
I can even in some cases see the code that you provided in order to provide that web page web access
with a credentials scan, I can go through and actually provide a detailed vulnerability scan of everything
that you see on the different web pages, because I have full access to them.
This meets most of our compliance standards with different regulations associated with it.
It's more detailed and it's more accurate with a non credentialed scan.
I'm not actually logging in as an admin user.
I can't see all those different perspectives of that web server, but I can still see the web server
as a whole.
This is a non credentialed scan where I'm able to go from an outsider point of view and go through the
process and scan the website.
It's usually quicker and it's not as detailed, but it's faster as well.
I want you to look at it from a non credentialed versus a credentialed status, much like we see from
an internal versus external process, they're typically the same even though a credentialed versus non
credentialed scan are usually both performed from inside the network.
It's just one has administrative privileges and one M1 doesn't.
Throughout this episode, we talked about the different vulnerability scans that you can conduct as
a cybersecurity professional.
It's important to understand the different aspects from a Cisa perspective, because you may be asked
specific questions as opposed to what is a credential scan versus a Non-credentialed scan.
But remember, it's all going to be scenario based.
It's going to come at you and from a perspective of you want to conduct a scan and have credentials
for the administrative privileges of this web server.
Based on that, what type of scan would you run?
And you might possess credentialed versus non credential agent versus agentless.
The whole gambit may be available to you, but the key words associated with it are usually the login
information thereby being a credentialed scan.
However, don't be surprised if Cisa tries to trick you by saying a question that says you have credentials,
but you don't want to run it as a logged in user.
In this case, it would actually be a non credentialed scan.
Be aware that Cisa will try to trick you on some of these questions throughout your entire exam.