Principal Security Consultant
Jeff Hall is a principal consultant in Optiv’s advisory services practice on the Payment Card Industry (PCI) compliance team. Jeff’s role is to provide post-sales support and consulting to Optiv’s clients as well as providing support and mentoring to other Optiv team members. He has more than 30 years of experience in project management, information security, information security strategic planning, software evaluation, selection and implementation, voice and data networking, systems analysis and design, information system audit, systems programming, and data center operations.
PCI DSS: The 30-Day Patch Rule
Requirement 6.2 of the PCI DSS (6.1 in v2) has always created a lot of consternation and discussion. For those of you that have forgotten, requirement 6.2 states:
“Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor supplied security patches. Install critical security patches within one month of release.”
For all but the smallest of organizations, applying patches within a 30-day period is virtually impossible even with automated patching tools. However, the Council felt it was necessary to proscribe a deadline on patching because of the lax patching practices that were endemic in most organizations.
When the PCI DSS was first released, this was one of the first requirements that Participating Organizations (PO) fought about with the Council. Most of the POs are large corporations and patching must go through rigorous testing and quality assurance processes that just do not allow for a patch being released within 30 days unless there are extremely exceptional circumstances. For most of these POs, a 60 to 90-day timeframe was more likely. And it got worse for retailers who only have a few times during the year when they allow their IT departments to make changes. As a result, there was always a compensating control put together to comply with the 30-day rule. Not all POs liked having compensating controls, so that added to the issue.
Then there were the merchants that were using packaged solutions such as MICROS POS, IBM Websphere or Oracle eCommerce. These packaged software vendors provide not only updates to their application software, but they also provide the compatible patches to the operating system that runs their application. These packages are tested to ensure reliability and compatibility to minimize customer operational issues. However because of this, these vendors may only release their updates quarterly, semi-annually or even less often. To further mess things up, patching of the underlying operating system by the customer is not allowed and violates the vendor’s application support agreement. And if that weren’t enough, the vendor update may leave some operating system patches out of the update due to compatibility or timing issues. Again, compensating controls were the only way to comply with the patching requirement.
Because of all of the compensating controls and complaints from POs and the acquiring banks, the PCI SSC came back and trained QSAs to look at the vulnerability management process of the organization. The Council taught us that if the QSA was comfortable that the vulnerability management process was properly managed; that vulnerabilities were not being swept under the rug; and that they were applied in as timely a manner as possible, then the organization would be compliant with the requirement regardless of the timeframe.
HALT! Before you all go off and tell your QSA, ISA or whomever leading your PCI compliance efforts to take a hike on the 30-day rule, stop, take a deep breath and listen to the rest of the story.
The Council also taught us that while an organization might not meet the 30-day patching rule, the organization is required to mitigate the risks created by not being able to apply patches within 30 days. That is the huge part of managing vulnerabilities that most organizations miss.
A vulnerability management program typically consists of the following steps.
- Identify vulnerabilities through vulnerability scanning and penetration testing.
- Identify patches for vulnerabilities from vendor announcements.
- If a patch is not available, develop mitigation plan to mitigate the risk of not having a patch.
- Review vulnerabilities and adjust CVSS scores based on applicability to organization’s environment.
- Test patches.
- If a patch fails testing, develop mitigation plan to mitigate the risk of not being able to apply the patch.
- Patch systems with compatible patches and implement mitigation plans for patches that cannot be applied.
It is the mitigation part that typically stymies organizations. First and foremost, once a mitigation strategy has been developed, it should be implemented as soon as possible. The most common question we get is what can I do to mitigate vulnerabilities?
The following are some of the mitigation strategies that organizations use to mitigate vulnerabilities. This is not a complete list, but is meant to give ideas as to approaches to mitigation. These can be used alone or together in various combinations.
- Create or tweak your log analysis rules to look for any indications that the risk is being exploited.
- Use a white or blacklisting application to monitor for any changes to the device.
- Use host intrusion detection system (HIDS) to monitor for exploits.
- Further lock down firewall rules to restrict access to suspect IP addresses used by exploits.
Make sure that your detection processes function in near real time so that you are getting notification as soon as possible. Waiting for a daily or even weekly review of information generated by these mitigation techniques is just too late since the compromise will likely be long over by that time.
Hopefully, this brings some clarity to the 30-day rule and how it applies to your organization’s environment.