Patching and PCI Compliance
- by Joel Weise
One of my friends and master of the security universe, Darren Moffat, pointed me to Dan Anderson's blog the other day. Dan went to Toorcon which is a security conference where he went to a talk on security patching titled, "Stop Patching, for Stronger PCI Compliance". I realize that often times speakers will use a headline grabbing title to create interest in their talk and this one certainly got my attention. I did not go to the conference and did not see the presentation, so I can only go by what is in the Toorcon agenda summary and on Dan's blog, but the general statement to stop patching for stronger PCI compliance seems a bit misleading to me. Clearly patching is important to all systems management and should be a part of any organization's security hygiene. Further, PCI does require the patching of systems to maintain compliance. So it's important to mention that organizations should not simply stop patching their systems; and I want to believe that was not the speakers intent.
So let's look at PCI requirement 6:
"Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed by vendor-
provided security patches, which must be installed by the entities that manage the systems. All critical systems must have the most recently
released, appropriate software patches to protect against exploitation and compromise of cardholder data by malicious individuals and malicious
software."
Notice the word "appropriate" in the requirement. This is stated to give organizations some latitude and apply patches that make sense in their environment and that target the vulnerabilities in question. Haven't we all seen a vulnerability scanner throw a false positive and flag some module and point to a recommended patch, only to realize that the module doesn't exist on our system? Applying such a patch would obviously not be appropriate. This does not mean an organization can ignore the fact they need to apply security patches. It's pretty clear they must. Of course, organizations have other options in terms of compliance when it comes to patching. For example, they could remove a system from scope and make sure that system does not process or contain cardholder data. [This may or may not be a significant undertaking. I just wanted to point out that there are always options available.]
PCI DSS requirement 6.1 also includes the following note:
"Note: An organization may consider
applying a risk-based approach to
prioritize their patch installations. For
example, by prioritizing critical
infrastructure (for example, public-facing
devices and systems, databases) higher
than less-critical internal devices, to
ensure high-priority systems and devices
are addressed within one month, and
addressing less critical devices and
systems within three months."
Notice there is no mention to stop patching one's systems. And the note also states organization may apply a risk based approach. [A smart approach but also not mandated]. Such a risk based approach is not intended to remove the requirement to patch one's systems. It is meant, as stated, to allow one to prioritize their patch installations.
So what does this mean to an organization that must comply with PCI DSS and maintain some sanity around their patch management and overall operational readiness? I for one like to think that most organizations take a common sense and balanced approach to their business and security posture. If patching is becoming an unbearable task, review why that is the case and possibly look for means to improve operational efficiencies; but also recognize that security is important to maintaining the availability and integrity of one's systems. Likewise, whether we like it or not, the cyber-world we live in is getting more complex and threatening - and I dont think it's going to get better any time soon.
