Now we move into the implementation and supporting of patch and vulnerability management. In this section, we're going to talk about patch management systems and vulnerability management systems. Patch and vulnerability management is a key part of configuration in change management, involving the deployment of software updates, which is also known as patch management. Flaws in vendor products are continuously being discovered. The development and distribution of vendor patches results in a never-ending cycle of required updates to production systems, having taken on the name of Black Tuesday with Microsoft's program of releasing patches. Managing these updates is not, however, a trivial task for any organization; the patch management process must be formalized through change and configuration management to ensure that changes to existing configurations are carefully controlled, and continued system reliability and availability has greater assurance.

Now, the main objective of the patch management program is to create a consistently configured environment that is secure against known vulnerabilities in operating systems and application software. Unfortunately, as with many technology-based problems, good practical solutions are not as apparent. So the questions we have to ask about whether or not a patch is necessary, what is the risk if the flaw is not patched? Always a question, what happens if we do? What happens if we don't? Is the system likely to be exposed to threats that might exploit the vulnerability? Will special privileges be required for the vulnerability to be exploited? Always an important question, because it means that if it is going to be exploited, an attacker who's seeking to do so may have to eventually escalate his privileges to the point of being a sysadmin. Can the vulnerability be used to gain administrative privileges to the target? If that were the case, then exploiting the patch might help them in that escalation process.

How easy is it to exploit the vulnerability? And will the vulnerability require physical access to the system or can it be exploited remotely? This is a very significant point. Physical security to prevent the asset from physical access by the assaulter may be something relatively easy to do. But as is often the case, remote access is rather more difficult to defend against, and we have to look at the process from start to finish. Having the patch, we need to think through the process of, how do we take it apart? How do we examine what it's going to do, determine the necessity for having it in the first place, whether or not we need it at all, and then going through the process of programming a proper well-controlled process of deployment, release, and actualization?

We should establish a schedule that can be published, so that users can plan their work accordingly. We have to be sure that they're always notified whenever a patch is going to be done, whether it's a scheduled one or an unscheduled, say, an emergency type. Updates should, as best we can, be scheduled during periods of low activity or even in the overnight period. We need to make certain that a full system backup is conducted prior to deploying patches. It is not uncommon that whenever a patch has been put in place, things do not go exactly as planned. It is better to practice caution and make sure that we have a backup of the system in its completeness before the patch is applied to ensure that if something does go wrong, we'll be able to restore the operation in a relatively short time, and if nothing goes wrong and everything goes as planned, then we'll be able to carry on, make a copy after the now properly working patch is in place and we baseline the system.

Whenever possible, an update should be deployed in stages. That depends on how complex and how many components are going to be affected by the change. We always need to apply these things, and then confirm that the updates are deployed to all the appropriate machines and that they have installed correctly, and that they're doing what and only what they're supposed to. Take nothing for granted. And then, once we've established definitively that everything has gone according to plan, we document the changes and put in place the new documented baseline of the system.

We do something a little different with our vulnerability management system. We first must recognize that vulnerabilities will arise from a variety of sources. They can be system flaws or failures in policies, or the failure of a user to perform a procedure correctly. The most common type of flaw in software is the buffer overflow. Now, flaws are generally fixed by a patch, by new code, or by a hardware change in some cases, and misconfigurations are implementation errors that can expose a system to an attack. Policy violations are found with a comprehensive network scanning tool. All of these different things must be done on a routine basis to ensure that we're keeping vigilance over the system, and managing our vulnerabilities. Because that is us managing and controlling the attack surface we present to potential attackers.