Often we find a problem within our systems that the normal corrective standard just can't be applied.
This can happen because of a variety of issues, including how our enterprise environment is set up.
It could be because of a specific policy.
It could be for a variety of issues, but we refer to this as an inhibitor to remediation.
When we look at the dependency on IT systems as a whole, we often find that some IT systems are outdated.
They've got legacy components.
The specific software that we're utilizing doesn't work on updated systems.
I consulted for a tanning salon at one point, and the overriding POS system, or the point of sale
system, as well as the inventory system that the tanning salon used, was backdated to Windows 7.
So if you were using any type of windows product after Windows 7, the program specifically just didn't
work.
Now, we tried utilizing a Windows 10 system that you could then backdate to utilize Windows 7 settings.
That didn't work.
We tried it with Windows 8.
That didn't work.
There was specific program requirements or the way the program was originally designed, where it just
did not implement well with anything past Windows 7.
This obviously provided with a variety of issues because Windows 7 was no longer supported, but this
is an example of a dependency on IT systems or outdated systems.
There can be outdated policies in place where policies were in place 1015 years ago, and while they
made good use of the requirements or good use of the problems and technology 15 years ago, new technology
has arisen, new ways of doing things have arisen.
There's better way of doing things.
But those outdated policies came into play and are hampering our ability to remediate certain issues.
For instance, there was a password policy put into place that specifically said that it had to be eight
characters in length, with at least one uppercase, one lowercase, one number, and one special character
that is an incredibly outdated policy when it comes to passwords, but because of the way the policy
was written, it wasn't just cut and dry like that.
It actually came to hamper our remediation factors to provide multi-factor authentication, because
there was a line inside the policy that specifically said no technology could be added or deducted from
the current policy without director approval, and we couldn't get the director to sign off on it.
So it had to go through the entire remediation policy for a change.
That literally took months when there was a better way of doing things right off the get go.
There could be resource constraints where we want to go through.
We want to do it, but the backlog of supplies isn't available.
This happened quite often in Covid where we were trying to upgrade systems.
We were trying to upgrade technologies, but their resources just weren't available.
This could often pose problems within the infrastructure as a whole, where we're having to do compensating
controls because resource constraints are available.
The complexity of the issue, if you've got uh, IT professionals or cyber professionals.
And the issue is very complex, and you're having to add technology on top of technology in a specific
format that could pose issues.
We've all had problems where we've ran into technology and we wrote the code, or we did something on
the process, and it just didn't work because it was so complex.
The different systems that were interacting with it just made the the configuration that we were trying
to pull off within the system as a whole not work well together, and that fluidity just wasn't there.
So complexity can often pose different issues.
And that specific instance, we had to break down the different configuration and provide this system
with this configuration, this system with this configuration, which obviously opened up some vulnerabilities,
which then we had to mitigate in order to get the system to work functionally correct.
There could be also resistance to change.
This happens quite often with older employees or with management, where they see the act of doing something
and they're just very resistant to change.
With the password policy, for instance, getting three factor authentication actually go through,
uh through the process of change policy was a nightmare because for the specific company, anytime you
wanted to change a policy, it had to go through an entire council or a committee that voted on the
password changing policy.
And even though it made sense and it needed to be enacted and it should have been cut and dry, there
was a lot of resistance to that change because, hey, we've always done it this way.
Why do we need to change it now?
Uh, and you'd be surprised how many people were just resistant to the type of changes that can occur,
especially in technology.
We usually don't have that big of an issue within it and cyber because we're used to changing constantly,
but sometimes you just run into people that just do not want to change, and you have to provide a compelling
argument based on facts.
And even then, sometimes they're resistant to provide those different changes.
We could do a memorandum of understanding as well.
We talked about MoUs a little bit earlier in this course, but I wanted to reiterate it here in terms
of, uh, in terms of inhibitors to remediation, if I have a MoU in play with different departments
or between different organizations the way that we've been doing it could necessitate having a new MOU
written.
Well, the MOU was originally written and signed by people that aren't with the company anymore, or
for a project that was long term.
Maybe the project's getting ready to end in 3 or 4 months and they don't see the need to change the
MoU.
And so there's resistance to changing the MOU, which means there's resistance to way we can do technology,
then requiring us to hold two different systems in place to necessitate meeting that MOU requirement.
MOU can provide us with a great system and ability.
It can provide a great policy and a great working understanding between two departments or organizations.
But it can also be an inhibitor to change if we're required to meet specific guidelines or specific
functionality within systems that call for outdated or legacy systems that we want to upgrade.
There's also service level agreements.
We often talked about SLAs, meaning a specific requirement, and we said, hey, I want to have a 99.5%
uptime on this SLA.
Well, we may come up with a more secure system on that provides us better security, better encryption,
but it also brings down the download speed or the upload speed.
And yet our SLA dictates that we have to have this set of bandwidth or meet these specific requirements.
And by adding those encryption and adding that security, it actually drops that SLA.
Check down below what our SLA is required to be.
And so that can be an inhibitor to change.
When we have an SLA that says you will meet 99.5% of this data speed of, let's say, a gigabyte download
speed.
And that's great.
And all our bandwidth didn't change, but we started adding encryption.
We started adding more security on the system.
And now instead of getting that one gig, we're at 9.9.
Did it have a vastly different, changed approach to it?
No, but it now does not meet that SLA requirement.
We have to go back through and do a new SLA agreement based on the security needs and some businesses.
Again, resistance to change, resistance to that SLA benefit, they're not going to want to do it.
So SLA checklist SLAs could necessitate an inhibitor to change.
There's corporate governance or organizational governance, where it refers to a framework of processes
and regulations.
This is often employed by different organizations to provide a specific way of doing things or a specific
way.
Our, uh, our different departments interact with one another.
This often is transparent within it, and it provides corporate leadership to allow and assess ramifications
of actions within our business.
When it comes to decisions that they make, when this comes to remediation, if they go into effect
and they start saying, hey, we want to do this framework, this is what we employ, this is the relation
we're meeting.
This is how we do business.
And we want to come through and say, oh, we would like to increase our security or we'd like to do
this.
Uh, it may affect that regulation or it may affect that corporate compliance that thereafter, which
then says that we can't do it because we've dropped our download speeds or we've dropped our bandwidth,
or maybe we're employing new security, but the current compliance regulations say that you will do
des older encryption algorithm or Triple-des.
Right.
But we just came out with this new thing called.
TLS or SSL that's supposed to be bigger and better and all the way across the board.
But the compliance and regulations say that you will hold up to triple death.
This could be an issue because even though we know SSL is better, way better, the specific governance
comes into play and says we will do triple death.
This often times can be a problem when it comes to corporate governance by outlining specific technologies.
So a lot of times when we talk about specific technologies, we will say or better or better, so meet
the minimum requirements or better in our corporate compliance.
But if that little word isn't in there, it could affect our, uh, our problems with remediation of
moving forward.
And so that's an inhibitor to trying to fix a security vulnerability by upgrading to a new encryption
standard.
That's obviously better.
But because we didn't do that or better, it has to go through the entire framework, the entire governance
protocols, all that problems for going to a better, um, encryption standard that has little to no
effect on our overall infrastructure.
There's also business process interruption.
Anytime I want to change something within our enterprise environment, especially for security, ultimately
I'm most likely going to have to take a system down, or I may have to patch a system, or I may have
to upgrade that system, which may have an expanded lifetime or an expanded maintenance window within
the process.
This means that let's say I want to upgrade a router, and the normal maintenance window is only four
hours.
But because of the way our network is set up, maybe we anticipate the router being offline for six
hours.
This could provide an extended maintenance window or a system downtime that the company isn't willing
to accept, which means we can't upgrade the router because our maintenance window is only four hours.
But we need to do all the prep work.
This could pose some issues or problems to inhibitors, to remediation of fixing or replacing this router
where we have a router where the maintenance window should only take three hours, but the backup procedures
to get out of it and reconfigure the old router made the two hours.
If we have to back out this would override our maintenance window of only four hours to be five hours
and that may come into technical issues.
We've also seen technical issues where the original plan was to only take two hours.
We have a four hour maintenance window.
Everything's approved, but we got so, uh, streamlined, so focused on the issue that we looked up
and we saw this router that's down, but it's been almost three hours and 45 minutes, and we've exceeded
that maintenance window, because there's no way we can back out with the old router back in within
15 minutes to meet the maintenance window guidelines.
This could be technical issues that come into play.
It could also be technical issues in the fact that we wanted to go to a new encryption standard, but
the new encryption standard isn't taking place.
It's not doing hold properly.
Uh, we're having configuration issues or software issues with the system we're trying to deal with.
That could be a technical issue, and it's taking longer than expected.
We'd have system failures where again, the router just goes offline.
It takes the entire system offline.
We need to replace it.
And again it's going to take 4 or 5 hours to do that.
That could be a business process interruption where it's inhibiting our ability to remediate the overall
issue.
We could also see where we've got a problem with insecurity.
We will replace a system, but in order to replace this system, we have to replace this system as well.
Or we had a system fail the night we were supposed to replace something.
So that's a system failure.
Natural disasters come into play where we may have a tornado or a hurricane that comes into play, or
even an earthquake or another natural disaster fire, flood.
It doesn't matter.
That comes into play, and we can't readily replace that issue or fix that remediation process because
we had something unexpected come into play.
And of course, there's human error, which makes up a majority of our problems where originally we
were to replace this router.
It's going to take three hours, but all of a sudden we had somebody click on a phishing link.
Now we have an incident and it's all hands on deck to fix this incident because it's playing havoc with
our systems and we can't remediate the overall issue that can be modified.
We also have degrading functionality.
This could be from our malware infections.
It could be from any number of different aspects, but usually with malware infections coming into play,
we have the malware that's taken hold within our system.
We have to get out that malware.
And because of that, now we've degraded our functionality of our overall client base.
It's not uncommon for malware to spread, and when that spreading takes place, we no longer have access
to the systems or the degraded functionality of those systems because we have to go through and wipe
the program.
We have to wipe that malware from existence that poses issues, gives us degraded functionality, cache
management issues where we're trying to run into patches.
We want to streamline that patch management window within the maintenance window.
And because we're implementing patches, we have degraded functionality across our spectrum of our enterprise
environment, which means our help desk can't normally do what they would like to do.
It's not uncommon, especially in large environments where we're doing a major system overhaul or we're
doing a major patch and something that would normally wouldn't be an issue, like a password reset.
The help desk can no longer do because we're patching the different systems, and we told them not to
do anything.
So degraded functionality of that aspect, denial of service or distributed denial of service attacks
on our system.
Since our clients can access the overall system.
It's restricted because we're hitting too much traffic.
That could pose issues and of course, overly restrictive controls or misconfigurations where the client
or the people trying to get access to our systems can't meet all those problems or meet all the functionality
of those systems because we've made restrictive controls too much, and so they can't authenticate,
or they can do one thing like they can write in the Excel spreadsheet, but then they can't save to
it because they're restrictive controls don't allow them to, or they can read it, but they can't write
to it, or they can write to it, but they can't save to it.
These are all restrictive controls that I've seen in the past that just provide major issues within
an overall environment and degrades functionality across the board.
When we talk about legacy or proprietary systems, I've given numerous examples in the past where I've
got an older system that's no longer supported, but it contains a specific software or a specific data
that we can't easily translate over to a newer system.
This often relates to a major problem when we're trying to remediate an issue.
If Guy has got an older server and I've got newer technology that's coming out.
Not only do I have to protect that system that is out of state or at its end of life and no longer supported,
but I also have to remediate security around that specific legacy or proprietary system.
And this could easily come into different functionalities where we're trying to do something with our
network.
But I've got this older legacy system that just doesn't work into play.
This is a major issue, especially across larger environments where they may have 2 or 3 different legacy
or proprietary servers or even different systems that we have to hide behind firewalls, we have to
add additional security, but we still have to allow people to gain access to it, and we have to safeguard
those systems, and we want to remediate or we want to upgrade our servers, and we can't because of
this singular legacy system.
This often resolves into the fact that we segment that system into its own environment.
We virtualize it.
We do all kinds of different compliance issues or mitigation strategies to protect that system and lower
the impact of it.
But never underestimate legacy proprietary systems.
They're all over the place inside larger enterprise environments.