As a cybersecurity 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 similar 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 allows with our impact.
How is it going to affect the profitability of our network or our company as a whole?
What resource is 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 p.m. 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.
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 the 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 it single server.
And if I have five servers all doing the same aspect or the same job function
and they're only at a 40% load,
it's really not going to affect the network as a whole if I sign 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 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,
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 are
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 will 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 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 cybersecurity 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.
Uh 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 the HR department is planned on onboarding a lot of brand
new employees today because it's Monday and
they normally onboard 15 new employees.
This ties up a lot of their resources.
However, we discover a piece of vulnerability or
some malware affecting the vulnerability of their systems.
And one of those malwares is affecting the sensitivity or the data associated with
PI I on our systems that pi I 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,
ie hr is just doing random stuff on their computers and it could be, you know,
some basic uh 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 ma
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 sensitive
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
an immediate 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 eliminators that we need to be aware.
Both
regulatory compliance and contractual obligations will dictate a lot of
times what we have to do as cybersecurity 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 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 cys A 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.