I am starting to see more and more instances where QSAs and acquiring banks are blindly enforcing PCI requirements without thinking about the intent of the requirements and how they should be applied to the organization being assessed. It is not like the intent of requirements has been hidden by the PCI SSC as the intent of every requirement is published in “Navigating PCI DSS: Understanding the Intent of the Requirements” which is available from their Web site.
The base problem with the PCI DSS is that it was written for a multitude of situations. While the PCI DSS is a reasonable standard, there are portions of it that are written for small merchants that know little to nothing of technology. This is where we see hard and fast metrics applied. Then there are portions that are vague, written for extremely large organizations so they have the flexibility of solutions. And we have a few requirements that are written for organizations in between these two extremes. Unfortunately, the next release, the PCI SSC does not address these shortcomings any better than the current release. However, the PCI DSS, in its Navigation Guide and the Glossary do give a clue as to the intent of the requirements and it is that intent that QSAs and others should work to enforce. Too often people focus only on the contents of the PCI DSS and do not use the other reference materials provided by the PCI SSC. As a result, people end up with a skewed vision of what the PCI DSS is all about.
The problem is no more pronounced than with those requirements that have hard metrics such as with requirements 6.1. The enforcement of the metric related to this requirement can be difficult to achieve as well as misleading. Therefore, a QSA needs to look at the intent of this requirement and enforce the intent rather than the bare metric. I know why the PCI SSC did what it did in setting hard and fast metrics. They set them so that the organizations being assessed understood the importance that these requirements be followed, particularly Level 2, 3 and 4 merchants. However, while hard and fast metrics work well with manufacturing standards, they do not work as well when a wide variety of hardware, software and human elements are required to obtain a given result.
The intent of requirement 6.1 is to ensure that organizations manage their infrastructure and applications to ensure that they are as secure as they can be. It is intended to ensure that there is management visibility to the risks presented by not maintaining software and to better ensure that software is not allowed to just run without attention and maintenance. Requirement 6.1 is in response to the fact that the majority of retail organizations do not keep their point of sale (POS) hardware and software current. It is common for merchants to install a POS solution and then never really touch it for years, if ever at all. After all, as one executive pointed out to me, “If it isn’t broke, why bother? Maintenance costs money that I would rather invest that money somewhere else.” Can you really blame anyone for this view? Security is like insurance, it costs you money until you need it and then it is invaluable. Unlike the insurance industry which has done a very good job of educating management on its value, the security industry has done a very poor job educating management on the value of security and what really needs to be done to secure the organization.
In practice, patching of infrastructure and applications can be daunting for any organization whether they have only a few IT resources or in big organizations with large numbers of servers and applications. While there are numerous automated solutions available to managing patching, in practice even with all of the automation that is available, patching is not as simple as it appears. In addition, depending on the applications involved, the application vendor may only issue patches or updates quarterly, semi-annually or annually and contained in those updates are also approved updates to the operating system and its services.
In my opinion, what organizations need to prove for compliance with requirement 6.1 is that the organization has a documented and working process for ensuring that infrastructure and applications are patched and kept current. Whether or not patches or updates are applied in 30 days or less is not as relevant as ensuring their infrastructure and applications are not left to run without attention to their security and maintenance.
I am not saying or even implying that organizations can avoid regularly patching. What I am saying is that QSAs need to understand the environment of the organization and then apply the intent of the requirement to the organization’s situation. 30 days is a nice ideal and probably practical for your typical small and possibly mid-sized retailer. But in practice, this requirement is not always achievable, particularly in large organizations or organizations that rely heavily on packaged software solutions. These organizations may come close to the 30 day timeframe, but hitting that timeframe with their testing, QA and production implementation processes just does not typically hit the magic 30 day mark. Therefore, QSAs need to prove that the patching process is reliable and works not that it works in some arbitrary timeframe.
PCI Guru 