In this lesson
we'll explore the different technical implementations
of changes.
Now, when considering any change
in a technologically advanced environment
it is important to recognize the vast network
of systems, applications
and configurations that are interwoven
into a delicate balance
to create a given enterprise environment.
Now, a single alteration, however small it may seem
can actually send dangerous ripples out
across this intricate network of interconnected systems
which can then lead to unforeseen consequences.
So in this lesson
we're going to be exploring the technical implications
of changes, including some key elements
like the use of allow and deny lists, restricted activities
and the complex interplay
of applications and their dependencies.
First, we have allow and deny list.
Now allow lists and deny lists are going to be used
by routers and firewalls to
either allow or deny certain resources from being accessed.
An allow list is going to specify which entities
are permitted to access a given resource.
On the other hand, a deny list or a block list
will be able to tell which entities are prevented
from accessing a given resource.
Now, anytime a change is proposed, it's important to review
both the allow list and the deny list to determine
if you need to have them modified as well.
If you perform a simple action
like adding or removing an IP address, for example
this can actually inadvertently grant
or restrict access to certain critical services.
If you're upgrading a firewall, it's also
important to conduct a firewall rules review to ensure
that your existing rules will work
on your new firewall and that they'll properly migrate
into the new device as well.
If you do not have the proper allow list
or block list in place, then your system may not
function properly and your security will be compromised.
Second, we have restricted activities.
Now, some tasks or operations might be listed
as restricted due to their potential impact
on a system's health or security.
Before green-lighting a proposed change it's required
that you verify if the proposed changes could have
any restricted activities contained within them.
For example,
a change might involve accessing a protected database
or shutting down a server
that is considered too sensitive to reboot
or to take offline during regular business operations.
By knowing these restrictions ahead of time
you could prevent data breaches
and operational hiccups from occurring.
Third, we have downtime.
Any proposed change, no matter how small does run the risk
of causing downtime to your systems.
Therefore, it's important
that you take the time to estimate the potential downtime
and weigh its negative effects
against the potential benefits of the proposed change.
Will the downtime cause any issues
for your end users during peak business hours?
How will it impact your users or customers?
It's important that you understand the impacts
of any downtime, and that way the change can be scheduled
during a scheduled maintenance window
to minimize the negative impacts
of the changes related downtime if there is any.
Fourth, we have service restarts and application restarts.
Now, many of our proposed changes
like installing a critical piece
of security software will require
that services or applications are being restarted
for that change to be applied.
Now, while this might seem pretty straightforward
when you're installing a security patch or other piece
of software in your home computer, a simple restart
like these can especially be disruptive when
they're being applied to a domain controller
or other server that is actively being used
by all of your end users.
Remember, it's not just
about the time it takes for the service to be restarted
and to come back online.
It's also about the potential data that might be lost
in transit, or the backlog that could be created
during the associated downtime
while you're implementing a given change.
So you have to keep this in mind too.
Fifth, we have legacy applications that we need to consider.
Now, legacy applications are older pieces of software
or systems that continue to be used often
because they still function and meet the needs
of their users, even though newer technology
or updated versions may be available.
Now, these legacy applications may still be robust
and reliable, but they're particularly sensitive
to changes because they're generally less supported
than our modern applications.
These legacy applications might not be as flexible
or adaptable as their modern counterparts.
So even a minor update in one part of the system
could lead to malfunctions or crashes
of these older applications.
For these reasons
it's important to understand which legacy
applications may be existing inside of your environment
and how they might be affected by a given proposed change.
Sixth, we have dependencies.
Now in today's interconnected systems
everything is linked together
which creates these dependencies.
For example, an application might rely
on a specific database to provide the underlying data
for a particular service.
A change in one area, therefore might have cascading effects
throughout all of your systems, your networks
and even across your partner's architecture too.
Before implementing any proposed changes
you should map out any of your dependencies that exist.
Otherwise, a minor tweak
in one area could lead to a major outage
in another area without you even realizing it.
So remember, the technical implications
of a change are multifaceted and they're interwoven
throughout all of our systems and networks.
Technical implications of proposed changes are not simply
about understanding the change itself
but also involves grasping the change's potential impact
on a broader scale across your enterprise network.
By taking into account elements
like allow and deny list,
the nuances of downtime
and the intricacies of application dependencies,
cybersecurity professionals like you can ensure
that the changes are not just effective
but they're also efficient at minimizing disruptions
and maximizing your potential benefits.