DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT
Patching of systems in a timely manner is a vital component of maintaining system security. Security patches should, in general, be applied as soon as possible upon availability. Responsibility
The system administrator responsible for managing the system is responsible for testing, applying, and verifying patches. The admin is also responsible for being aware of vulnerabilities and patches as they are announced. Should there be a question as to whether a security patch is to be applied, the SDSC Information Security Officer, in consultation with the relevant SDSC Division Director or SDSC Department Manager, will have the final decision.
However, applying patches includes a risk of breaking functionality of the system, so it is desirable to test patches on non-production systems before applying to production. But the testing process may need to be bypassed if risk to the security of system requires that the patch(es) be applied as soon as possible. In order to assess the criticality of a patch, it can be prioritized in two dimenions: remote v.s. local vulnerability, exploit available v.s. not available:
|Type||Exploit Available||Exploit Not Available|
|Local root||Critical||Less Urgent|
|Local DoS||Urgent||Less Urgent|
|Remote non-root||Urgent||Less Urgent|
|Local non-root||Less Urgent||Less Urgent|
Vulnerabilities for which an exploit is in use must be patched immediately, regardless of whether the patch causes other system problems. Ultimately the cost of lost functionality is more acceptable that the cost of a security compromise. Local vulnerabilities should be considered equally as critical as remote vulnerabilities. If no exploit is known for a vulnerability, there may be some breathing room that allows time for testing the patch. However, should an exploit become available in the meantime, the patch must then be considered critical and applied immediately. Additionally, security patches may have to be applied ahead of other patches that have already been scheduled for testing and installation, as determined by the criticality of the vulnerability.
In cases where a patch affects functionality, or there are other legimate reasond for not applying a patch immediately, the patch installation may be delayed if the risk of exposure can be mitigated. Examples of mitigation might be restricting a network service to a particular network or set of hosts, restricting use of a service to a particular set of users, changing or removing permissions temporarily, or application of other recommended workarounds.