TRAC: C1.10: Patching and risk-benefit assessment

C1.10 Repository has a process to react to the availability of new software security updates based on a risk-benefit assessment.

Decisions to apply security updates are likely to be the outcome of a risk-benefit assessment; security patches are frequently responsible for upsetting alternative aspects of system functionality or performance. It may not be necessary for a repository to implement all software patches, and the application of any must be carefully considered. Each security update implemented by the repository must be documented with details was about how it is completed; both automated and manual updates are acceptable. Significant security updates might pertain to software other than core operating systems, such as database applications and Web servers, and these should also be documented.

Evidence: Risk register (list of all patches available and risk documentation analysis); evidence of update processes (e.g., server update manager daemon); documentation related to the update installations.

---

Like many organizations ICPSR uses an automated system for basic security patching, both on the Windows platform and on the Linux platform. In this context there is absolutely no risk assessment for an individual patch; they flow from a trusted source, and are installed automatically.

For our most sensitive components, such as the Apache web server, Oracle, and the kernel we run on our Linux systems, we install patches and/or upgrade versions manually. These changes take place less often, and at a minimum are announced well ahead of time to the entire group. For example, a systems administrator would announce an intention to upgrade to the newest release of the Apache web server on our staging server, see how things work for a week, and then announce the same upgrade on our production web server. This isn't captured in anything as formal as a risk register, but there is clear and frequent communication about the change.