As a cyber security expert, you'll often come into contact with different scanning or scanning principles
that you need to be aware of.
A lot of times we need to do vulnerability scanning as part of our compliance or regulatory contractual
obligations.
Whatever the case, you need to understand that special considerations need to be made in most cases
when it comes to scanning processes in place.
Now we're not just talking about scanning as a whole.
We're talking about scheduling.
And when scheduling occurs for any type of scanning on your network, it can have some unforeseen consequences
on that network in which you're scanning, whether it's the entire network or a single machine.
The fact is, is that sometimes we need to juggle what we're doing and how we're doing it.
We need to juggle risk within the process of scanning along with our impact.
How is it going to affect the profitability of our network or our company as a whole?
What resources are available and how it affects those assets as you're scanning for vulnerabilities.
Scheduling is obviously the first take that comes into mind.
Most of our vulnerability scanning or scanning in part, is going to be done during the maintenance
window.
Now every organization has their own maintenance window that they utilize.
Sometimes it's from 10:00 pm at night until 6 a.m. in the morning.
Sometimes you get lucky and that maintenance window is in the middle of the day.
Each organization is going to be different, and they're going to set aside their own maintenance window,
where we can do a lot of different things to our IT systems, that it's not going to cause a lot of
problems for our network as a whole.
Usually this is judged on two factors profitability of the organization as a whole.
Because if I'm scanning servers and they accidentally drop, then that could cause a loss in profitability.
It also has to do with workflow.
How are they people that are usually working during that time frame affected by the scanning that I'm
conducting?
This is a performance issue that you need to be aware of when you're scanning for vulnerabilities outside
of the maintenance window.
However, sometimes we have an incident that occurs within our organization that requires us to scan,
scan for vulnerabilities, or scan our network as a whole for rogue devices or other aspects within
our network.
When we take into account that aspect, we need to look at criticality of our systems as well as the
impact that it has.
Now, we're not just looking at the impact of our scanning.
We're looking at the impact of the network as a whole.
I can scan a single server, and if I have five servers all doing the same aspect or the same job function,
and there are only at a 40% load, it's really not going to affect the network as a whole if I send
that single server.
However, what else is attached to that piece of networking device?
Let's say that I have to scan multiple departments or a single department for a piece of malware, or
a vulnerability associated with it.
Could the impact cause a negative impact to the profitability or operations within our network as a
whole?
If the case is yes, then we have to do some special considerations in place.
How does that negative effect affect the entire action of our servers and our network and our security
within that network to the operations of our company as a whole.
When we're taking this into an aspect, we need to look at the whole picture.
We can't just look at it from a cybersecurity standpoint.
If we look at it purely from a cybersecurity standpoint, we go security.
Security.
And we don't pay any attention to availability.
The availability factor is what comes into play for the normal people that are coming into our business
on a day to day basis, whether it's employees or consumers, and we need to take that into account.
The second aspect that we need to be aware of is priority.
Priority takes place when maybe I have an incident or some type of environment that's taking place.
But I also have something big going on.
Maybe there's a giant product launch where we're expecting a lot of traffic on our networks, and by
scanning it, we could unintentionally provide a loss of profitability.
There's also resources that are coming into play.
If we're launching a new product and we're expecting a major traffic load on those servers that normally
operate at only a 40% capacity.
We expect an 80% capacity because we're going through a new product launch.
Then we have a problem with our resources.
However, sometimes I could have an incident that's affecting one network, and instead of scanning
the entire network, maybe I can segment it off.
Maybe in this terms I have a HR department where we're having a major product launch, and normally
I would have to scan the entire environment, but because it's regulated to a specific department or
departments that don't have a lot to do with that product launch, I can scan those specific segments
one at a time.
In this scenario, HR doesn't have a lot to do.
Let's segment it off and scan the HR department during the day to try and clear up that problem.
And then we'll come back to the servers at night during the maintenance window.
Whatever the case, when we go through priority, we need to look at the overall picture and how it
encompasses our profitability of our environment as a whole.
Sometimes the priority needs to be security.
However, sometimes it's not.
And that's something that we just need to be aware of.
As cyber security professionals, we can't always have our cake and eat it too.
Even though we'd really like to only work during the day.
Other considerations that need to come into place is our sensitivity levels.
And we're not talking about how sensitive the HR department is.
When we start scanning their services in the middle of the day, we're more talking about the data that's
secured on those levels.
So when we're talking about this, while we scan the HR level, there may be a server or servers that
have sensitive data associated with it.
We need to be aware of those sensitive data levels on those systems.
Let's take back our product launch example again I have a product launch.
We're expecting a lot of traffic going on there.
And our HR department has a server that may have some malware associated with it.
Because of an incident that's occurring, we could segment it off and go in and start scanning it,
and that would still fall within our priority list.
But let's take this into a different level.
Let's say that HR department is planning on onboarding a lot of brand new employees today because it's
Monday and they normally on board 50 new employees.
This ties up a lot of their resources.
However, we discover a piece of vulnerability or a piece of malware affecting a vulnerability of their
systems, and one of those malwares is affecting the sensitivity or the data associated with PII on
our systems, that PII has a high sensitivity level.
And because of that, we deem it to be very important, and we need to shore up that vulnerability as
soon as possible.
In this case, the sensitivity level of the data that they are securing takes context or priority over
the onboarding of new employees.
We need to secure that data because the data sensitivity level is high.
If the data sensitivity level was low, i.e. HR is just doing random stuff on their computers.
And it could be, you know, some basic, uh, word documents or Excel documents, and it's going to
interrupt their day.
Maybe it doesn't take priority, maybe because the impact or the level of the malware is only affecting
those levels, and they're doing a lot of onboarding.
we deem it to not be a higher priority.
This is where sensitivity levels really come into play.
Regulatory compliance is another factor.
We could have regulatory compliance based on HIPAA or PCI, DSS or any number of other factors that
come into play that require us to scan and immediately deal with that vulnerability, regardless of
what's going on within the systems, we could also have contractual obligations that state, hey, our
servers must be free of malware based on these delimiters that we need to be aware of.
Both regulatory compliance and contractual obligations will dictate a lot of times what we have to do
as cyber security professionals.
They will also dictate whether or not we can move forward based on the priority.
In this context, we're updating the priority to a higher level based on those compliance and contractual
obligations, and they take precedence.
However, sometimes regulatory compliances aren't a factor and we don't have to deal with them.
Throughout this episode, we talked about different special considerations in terms of both scheduling
and Sin City levels when it comes to different data sets.
We also talked about contractual and legal obligations that we may have based on what we're storing
within our systems.
Within the CSA exam, you can expect to see different levels or scenarios based on exactly what we talked
about today.
They may provide you a scenario based on different priorities, and they would go through and maybe
ask a question like you are tasked with doing a vulnerability scan based on an incident with a very
low priority that is affecting minimal systems throughout your environment.
When would be the best time to conduct a vulnerability scan and that feature?
The correct answer would be most likely in the maintenance window, as that's probably the best answer
for that scenario.
However, you might also have a question that talks about high priority or high sensitivity levels.
In this case, it really is a judgment call for most cases.
But use your common sense and understand that higher sensitivity levels and higher priority levels dictate
us to move forward with those vulnerability scans, regardless of the maintenance windows considerations.