II.C.10(d) Patch Management

Frequently, security vulnerabilities are discovered in operating systems and other software after deployment. Hackers often will attempt to exploit these known vulnerabilities to try to gain access to the institution's systems. Third parties issue patches to address vulnerabilities found on institution systems and applications.If an institution develops or maintains software in-house, management should have a process to update the software with appropriate patches. Management should implement automated patch management systems and software to ensure all network components (virtual machines, routers, switches, mobile devices, firewalls, etc.) are appropriately updated. In addition, management should use vulnerability scanners periodically to identify vulnerabilities in a timely manner.

As part of the institution's patch management process, management should establish and implement the following:

  • A monitoring process that identifies the availability of software patches.
  • A process to evaluate the patches against the threat and network environment.
  • A prioritization process to determine which patches to apply across classes of computers and applications.
  • A process for obtaining, testing, and securely installing patches, including in the institution's virtual environments.
  • An exception process, with appropriate documentation, for patches that management decides to delay or not apply.
  • A process to ensure that all patches installed in the production environment are also installed in the disaster recovery environment in a timely manner.
  • A documentation process to ensure the institution's information assets and technology inventory and disaster recovery plans are updated as appropriate when patches are applied.

The institution should have procedures that include how to implement patches to mitigate risks of changing systems and address systems with unique configurations. Before applying a patch, management should back up the production system. Additionally, management should define appropriate patch windows and, whenever possible, restrict the implementation of patches to defined time frames to minimize business impact or potential down time.

Patches make direct changes to the software and configuration of each system to which they are applied. While patches are necessary and useful, they may have unintended negative consequences, such as introducing new vulnerabilities, reintroducing old vulnerabilities, or degrading system performance. The following actions can help ensure patches do not compromise the security of the institution's systems:

  • Obtain the patch from a known, trusted source.
  • Verify the integrity of the patch through comparisons of cryptographic hashes to ensure the patch obtained is correct and unaltered.
  • Protect and monitor the systems used to distribute patches to ensure only authorized patches are distributed.
  • Apply the patch to an isolated test system before installing on the production system to ensure the patch is compatible with other software used on systems, does not alter the system's security posture in unexpected ways (such as altering log settings), and corrects the pertinent vulnerability.
  • Test the resulting system to validate the effectiveness of the applied patch.

 

Previous Section
II.C.10(c) Standard Builds
Next Section
II.C.11 End-of-Life Management