Just because the system was designed to be secure and
maybe even initially installed in a secure way doesn't
mean that it will remain secure.
This is why we need to have configuration management. We set out the
correct configuration for a system, a baseline configuration you can
say. That is the standard configuration,
whether or not it's for an application or a desktop,
for example.
And we want all of our devices to be configured in that way so we know
they're meeting that security baseline that we've set out.
We can put this into, for example, hardware,
software,
security tools, such as how often will we update our antivirus,
and, of course, the configuration of a firewall.
The idea is that this standard configuration ensures consistency between
different systems, and we can use this as the baseline for audit.
We can go and check to see whether or not,
say, for example on a desktop, all of the patches are up to date.
Has the operating system been patched properly?
Has the antivirus been updated properly?
So these are things that we check, and we can do an audit to ensure that
we are compliant with that required configuration.
But there are always going to be times we have to change the configuration.
There's fixes and upgrades to software,
for example. A patch comes out, well, we are going to change
that software, and we don't want to have a situation where we
catch the business by surprise.
We make a change, and they're looking around, and this isn't working.
It's not doing what it's supposed to do.
You've taken things out of operation at a critical time of the day.
So when we are going to make changes to configuration, we must have a process.
And whether or not this is a change to our network configuration,
a change to a project, or change to hardware, we want to make sure that
change control processes prevent things like scope creep.
You take a project where we add this, then we add that.
And before we know it, we have a totally unmanageable project.
We can't even do all of the things that need to be done.
And when patches have to be applied,
you don't want to do it on the busiest day of the year.
So this is why we have change control, and change control is a very
important principle in security operations and administration.
We want to make sure that any change we're going to make,
whether it's to software, hardware, a project,
network, firewall configuration, that change should be documented.
There should be a formal process to record who asked for this change
and why, and then that change would be reviewed.
Would it have an impact on risk. If I make this change,
would that maybe open a new attack vector?
And of course, a lot of what we're trying to do through the
documentation is keep a good record so that if we go back later,
we can see well why was this change made and who asked for it?
Then, the change should be tested. Make sure that we did not
introduce new problems or open new vulnerabilities and that we did
not overwrite previous changes.
This is something we often hear called regression where I go and I
make a change today that actually overwrites a change that was made
2 weeks ago. And the result of that is we actually have gone to a
less secure state again.
So we test thoroughly, including the regression testing, and then the
change is authorized. The change is authorized to be put in place, and we
have things like, of course, senior management support. We advise the
business when this is going to happen.
This is part of what we call change planning.
We communicate the change.
We then take images of the systems before because if something
goes wrong, we want to be able to roll back,
go back to that former configuration so that our systems can continue to work.
The key points review.
Configuration management ensures that all systems are deployed, or we could say
configured, in an approved secure manner and that we control changes because
change is a time of risk, and making a change to the configuration baseline
should be a very much controlled process.