In the newsletter #15 I addressed the problem of flaws in our working environments. As a follow up I'm covering here the topic of patch management and its applicability within the context of PCI, a domain of 49,5% compliance rate as per the Verizon 2014 PCI Compliance report.
What's a patch?
In the same way a needlewoman would apply a piece of cloth to repair a hole in your favorite coat, a patch or fix is a piece of software that can be applied to correct an issue in our software/operating systems.
Why is it important?
Like we lock our home doors and windows to prevent unauthorized accesses, patching is necessary to prevent individuals or malware intruding into our systems by exploiting the associated flaws/vulnerabilities.
How to identify applicable patches?
The most trustworthy source of information related to patches releases are the vendor bulletins or announcements to which the organization should subscribe for each type of system components and softwares owned.
Vulnerability scan reports are another source that is frequently used. In addition to the list of vulnerabilities they provide a list of missing patches as part of the consolidated solution correction plan for each IP scanned. However, using it as unique source of information is not recommended as it will put the organization in a never-ending catching-up mode and create noticeable delays in the implementation of patches. Having said that vulnerability scans are however recommended to:
- Validate the presence of vulnerabilities and therefore applicability of patches
- Confirm the level of criticality of patches
- Validate implementation of patches.
What are the associated PCI requirements?
PCI DSS V3.0 - 6.2 requires that you ensure that all system components and software have applicable vendor-supplied patches installed within an appropriate timescale according to prioritized risk with critical patches installed one month of release.
The application and validation of 6.2 requirement is closely associated to 6.1and 6.4.5
6.1 Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as “high,” “medium,” or “low”) to newly discovered security vulnerabilities.
6.4.5 Document and apply change control procedures for the implementation of security patches and software modifications. Procedures must include the following:
18.104.22.168 Documentation of impact.
22.214.171.124 Documented change approval by authorized parties.
126.96.36.199 Functionality testing to verify that the change does not adversely impact the security of the system.
188.8.131.52 Back-out procedures.
What is meant by « critical »?
According to PCI DSS V3 6.1 A patch should be considered “critical” if it addresses vulnerabilities that pose an imminent threat to the environment, impact critical systems, and/or would result in a potential compromise if not addressed.
How to assess the criticality of a patch?
The best source for the determination of the level of criticality of a security related patch is probably the vendor itself. They will likely know the severity of the vulnerability addressed. However, the criticality analysis of a patch should also consider the criticality of the systems impacted, the business risk associated to the implementation of the patches (Patches are also a threat agent) as well as the level of security measures in place that could reduce the probability of exploitation.
Which systems must be patched?
PCI requires that all system components and all applications in the card data environment must be patches.
Should all patches be implemented?
PCI requires one to install ALL vendor-supplied patches applicable to the environment. However blindly deploying all patches could be the source of system corruption or unavailability - foundation of the following caution principle « Never touch a running system". For this reason the go/no go decision for the implementation should be based on the outcome of a risk analysis balancing the criticality of associated vulnerabilities, the potential side effects on the assets and implemented mitigation measures.
It must be noted that PCI doesn't let the door open for waivers in this matter. ALL patches must be applied. Meaning that the non-installation per se of a patch would lead to a non-compliance. Hopefully, PCI lets organizations defining their appropriate installation timescale (based on the risk analysis). So one should prefer delaying installation than officially deciding to not implement it. Of course the rational behind any decision must be documented and validated by the management.
When should a patch be deployed?
As mentioned above PCI requires installation of patched within an appropriate timescale according to prioritized risk, with critical patches installed one month of release.
This is real challenges for IT that should perform the associated activities within the usual well known constraints - limited resources, budget and time. The complexity of patching is narrowly linked to the size of the environment. In some organization the 30 days timescale applicable to critical patches is just not doable. To stay in compliance, organizations could be tempted to downgrade a critical patch to a "high risk » patch.
What are the QSA checks?
To assess your compliance with this control QSA's will verify that you have documented and applied processes covering:
- Installation of applicable critical vendor-supplied security patches within one month of release.
- Installation of all applicable vendor-supplied security patches within an appropriate time frame (for example, within three months)
For this purpose QSA's will:
- Examine your policies and procedures related to security-patch installation, the identification and ranking of vulnerabilities and change control.
- Select a sample of system components and softwares in scope
- Compare the list of security patches installed on the sample system components with the most recent vendor security-patches
To support their assessment QSA's must report
- The list of documents reviewed
- The contain of the selected sample set
- Their findings for each component of the sample sets
How to be prepared?
Make sure to:
- Have a general policy covering the need for patch management as per PCI rules
- Have a documented procedure for the identification of new vulnerabilities including using reputable outside sources
- Have a documented procedure for the risk ranking of the new vulnerabilities
- Have a documented procedure covering the change control in case of patching.
- Have documented procedures (for each type of system components in scope) defining who is involved in patching activities, what need to be done, when should it be done, and How. The following processes should be addressed:
- Patches Identification (i.e. list of Vendor bulletins)
- Validation of their applicability (i.e. Cross-check with scan report)
- Determination of the criticality levels (Based on risk analysis)
- Compatibility testing with systems and controls already in place
- Roll-out plan definition (taking into account potential releases roadmaps)
- Exception Handling for patches that could not be installed as per policy (for whatever reasons).
- Roll-out execution (hopefully through an automated solution)
- Installation validation (I.e scan) and documentation (Logs, rationals for exception)
- Have a list of patches sources
- Have a log of applied patches (date, systems, patches Id, criticality level, approval)
- Have a documentation of rationals for non-applied patches.
- Make sure systems and softwares in scope have the latest patches installed.
Note: Verizon 2014 PCI Compliance report mentions the poor or lack of documented patch management processes as the biggest pitfalls of patch management
- What's your experience with complying with 6.2?
- How do you manage to keep up with patches?
Read our previous newsletter: PCI 30 seconds newsletter #34 - PCI DSS V3 Changes and Impacts