Patching policy

DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT

Patching Policy

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.

Patching Priority

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
Remote root	Critical	Urgent
Local root	Critical	Less Urgent
Remote DoS	Critical	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.

Mitigation

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.