|
---|
Table of Contents |
---|
outline | true |
---|
style | none |
---|
type | list |
---|
|
|
Overview A process should be established for the deployment of system and software patches which includes: - Creation of an asset inventory
- Defining roles and responsibility
- Determining importance of systems and patch rankings
- A documented patch management process
Asset Inventory Defining roles and responsibility Systems and Patch Rankings Critical Security Threats Center |
---|
Patch Risk Analysis |
Patching definition | High | Medium | Low |
---|
Vendor Patches and security updates defined as "high," "critical" or "urgent" for all system components and other IT resources affected by threat | X | | | Vendor Patches and security updates with remote exploits actively spreading in the wild | X | | | Vendor Patches and security updates defined as "medium," "moderate" or "important" for all system components and other IT resources affected by threat | | X | | Vendor Patches and security updates with remote exploits possible, but not actively in the wild | | X | | Vendor Patches and security updates defined as "low," "non-essential" or "non-urgent" for all system components and other IT resources affected by threat | | | X |
Center |
---|
Patch Risk Definitions |
Ranking | Definition | Time To Patch requirement | Unscheduled Downtime Allowed |
---|
High | The threat source is highly motivated and sufficiently capable; controls to prevent the vulnerability from being exercised are ineffective. | Patches must be tested and applied as soon as possible | Yes, if necessary create emergency patch windows and may impact SLA | Medium | The threat source is motivated and capable, but controls are in place that may impede successful exercise of the vulnerability. | Patches must be tested and applied as soon as reasonable | Yes, but only if regular maintenance windows do not occur within a reasonable time frame | Low | The threat source lacks motivation or capability, or controls are in place to prevent, or at least significantly impede, the vulnerability from being exercised. | Patches may be deferred | No, apply during regular maintenance windows |
Patch Management Process The patch management process should: a) determine methods of obtaining patches b) specify methods of validating patches (e.g., ensuring that the patch is from an authorized source) c) identify vulnerabilities that are applicable to the installation d) assess the business impact of implementing patches (or not implementing a particular patch) e) ensure patches are tested against known criteria f) describe methods of deploying patches (e.g., using software distribution tools) g) report on the status of patch deployment within the installation h) include methods of dealing with the failed deployment of a patch (e.g., redeployment of the patch). |