Patch Management Policy

The KX Patch Management Policy is derived from recognized best practices for Security Advisory Patch Management.

Scope

This policy is focused on KX specific systems

High Business Value (HBV) systems are defined as all multi-user KX systems, Software as a Service (SaaS), Infrastructure as a Service (IaaS), Platform as a Service (PaaS), cloud environments, middleware and network infrastructure devices supporting KX production business services and / or providing Inter-Enterprise services between KX and external enterprises.  In addition, all KX business applications and data repositories which contain, process or access KX Confidential Information, directly execute a vital business process, or which are subject to ASCA certification.

Low Business Value (LBV) systems are other multi-user KX systems such as those providing local or departmental services and those supporting development processes.  Network infrastructure devices supporting non-production development environments may be included in this group classification provided the following criteria is met:

• The network devices are managed to the highest security control level of the systems being supported
• The network devices are located behind a HBV network device configured to protect the integrity of the production network
• The network devices are only allowed to exchange information with HBV network devices via static routing
• Specific requirements in the network infrastructure technical specifications are followed

Remediation of system security vulnerabilities, either detected via vulnerability scans or reported vulnerabilities by software vendors, is the goal of patching.  Vulnerabilities are defects that, if left unfixed, may allow an intruder to gain unauthorized access to a system and initiate several types of attacks.

Refer to the Application Vulnerability Management Standard and Infrastructure Vulnerability Management Standard for details on remediation of vulnerabilities.

Patches to be installed and their due dates are planned and published.  Each patch is published in terms of a patch advisory, a description of the patch and its severity.

NOTE: (HBV) Systems require a change management record every time a patch is applied.  The Change Record (CR) for a production system guarantees the following points of control:

• Every modification to the OS level must be tracked in order to be certain it was not done in a fraudulent way as part of a security attack
• According to the impact of the required patch, an adequate level of pre-analysis must be conducted and approvals obtained
• Patches often imply downtime, either “planned” like a reboot or “unplanned” like a malfunction with the related back out.  Therefore, affected people must be involved.

KX leverages tooling to perform periodic vulnerability scans and to install missing patches on all the production systems.

Automated patching may be applied when the advisory indicates that there is low risk to deploy and there is no disruption to service.  If these criteria can be met, automated push of patching is acceptable and recorded.

The following policy statements are appropriate to the patch management operational cycles:

Establishment of Service

• As part of the Establishment of Services (EoS) for a system, the responsible party is required to address all relevant security advisories or patches for the current classification of the system unless otherwise exempted from this policy as documented in the scope statement above.

Monitoring for Advisory Alerts

• Security advisory websites must be monitored to ensure that alerts are received in a timely manner.  For products not covered on security advisory websites, the responsible party must monitor the relevant advisory sources on a monthly basis.  The responsible party must assess the risk and severity of any security advisory, and classify it as high, medium, or low.
  • NOTE: For internet facing systems, monitoring will be required to ensure compliance with the Infrastructure Vulnerability Management Standard.

Reviewing Advisory Alerts for Applicability

• The responsible party must receive the security advisory alerts.  The alert needs to be reviewed and a determination of applicability must be made by testing the patch on a test environment, tracking patch version baselines as required.

Patching Schedule and Installation

• All applicable security advisory patches or circumventions (for example, emergency fixes) are to be installed within the timeframes published in the Infrastructure Vulnerability Management Standard
• For applicable security advisory alerts:
  • Acquire the patch
  • Installation of the patch prior to the published patch due date (governed by the Infrastructure Vulnerability Management Standard).
  • Install the patch
• For failed patch installation, the responsible party must follow the Incident Management Process in effect for the classification of system to resolve the issue.  If the issue cannot be resolved and the patch cannot be applied, the system is to be isolated.

Tracking and Recording of Patches

• Evidence that the security advisory alert has been addressed must be retained to demonstrate compliance with this requirement via formal change controls.
  • NOTE: A security advisory alert is considered to be addressed when of or more of the following conditions are met:
    • The advisory has been installed
    • A determination has been made that the advisory is not exploitable on the system or service.  The responsible party may be required to provide an explanation of why the vulnerability was not exploitable during validation testing.
    • A risk evaluation has been performed as per the Risk Management Policy and a deviation document or equivalent covering security advisory patch management is in place.
    • An approved Risk Acceptance covering security advisory patch management is in place for the system or application.
    • The system or application has been removed from service.  Reactivation of the system or service would require that the advisory be addressed as part of the Establishment of Service Process

Preventing and Managing Overdue Patches

• Our goal is to be compliant with the Security advisory patch time limits described in the Infrastructure Vulnerability Management Standard.  In particular, we need to manage special cases where additional systems could be created or re-connected to KX infrastructure after a baseline has been applied.  Any emergency change request should be completed within 48 hours.

Security Overrides

The Security or Compliance leader may at any time implement a Security Override action for one or more security advisories.  These are advisories which warrant accelerated actions to reduce immediate risks to the stability of the KX infrastructure and operation of the business.

The patching process in this case does not differ in terms of policy from the one described above.  The only main difference is the time, meaning that the Security Override must be applied almost immediately, so there might be the need of requesting a special change request outside of the standard maintenance windows, and specific for the Security Override (not related to an advisory baseline).