TABLE OF CONTENTS Dealing effectively with vulnerabilities in today s networks includes not only managing and dealing with the vulnerability process itself, but also integrating the previous approach toward vulnerability assessment (leveraging scanners to discovery vulnerabilities) into the correlative frameworks and processes of patch management, configuration management, and change control. This chapter focuses on these frameworks and processes. Understanding what these processes are, their similarities and differences, and how they integrate with the vulnerability life cycle is essential to pulling an effective vulnerability management program together.
Why patch a system? This question can seem rather remedial in nature, but it is certainly a valid question. Far too often our answer is, Because the vendor said to. You should never patch a system unless it is absolutely necessary; otherwise, causing system instability is well within the realm of possibility. Patching a system is as much an art as it is a science. There are numerous reasons why you may want to patch a system, but patches are generally applied to do the following:
Enable new functionality
Mitigate discovered vulnerabilities or security risks
Fix stability issues
Patches can be software or hardware related, and the results of one patch can often affect the operation of both the primary and secondary functions of another patch. One common example that is often overlooked is the upgrade of a system s BIOS. Functions or features enabled (or re-enabled) in the system BIOS can have widespread consequences from the operating system perspective. Let s look at the release notes...
