| Info |
|---|
This is a draft page. |
|
|---|
| 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
Risk Assessment Threat | Likelihood | Impact | Risk |
|---|
Unpatched workstation remotely compromised | Low | Low | LOW | Unpatched workstation compromised from browsing inappropriate websites | High | Low | MEDIUM | Unpatched workstation compromised from browsing appropriate websites | Medium | Low | LOW | Unpatched workstation unavailable for extended period of time because of compromise | Low | Medium | LOW | Unpatched workstation with restricted data compromised | Low | High | MEDIUM | Unpatched workstation compromised and used to pivot into more secure networks | Low | Medium | LOW |
Asset Inventory
Comprehensive inventory of all system components, including: - Network devices and all supporting hardware and protocols
- Operating systems within the development and production environments
- Applications within the development and production environments
- Any other mission-critical resources within the system environment that require patches and security updates for daily operations
The inventory should include supported versions of software, hardware, and third-party applications. Applications installed for an individual person or project should be included in the inventory. Roles and responsibility
An individual should be identified to develop and oversee the patch and vulnerability management program in a department or unit. This individual will be responsible for coordinating, facilitating and undertaking all necessary activities regarding security patch management policies and procedures. Additionally, this individual will have the necessary information technology and security expertise to successfully execute all steps as required, including: - Being aware of all known threats or vulnerabilities that could significantly impact system components within the system environment and any other IT resources.
- Having a strong technical and business understanding of all critical systems within the unit's IT infrastructure, as well as knowing which systems are essential for day-to-day operations
Systems and Patch Rankings
| 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. With approval, may be implemented with limited notification. | 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. Must be sufficiently communicated first. | 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). |