“Interesting” historic changes in PCI DSS

In my previous post, I shared a few thoughts on what I thought was one of the most significant changes in PCI DSS v4.0. It was, of course, not the only one and not all of them were big changes.

On a slightly lighter note, I was rather amused by the minor change to requirement 9.4.4.b (v3.2.1)/9.3.4.b (v4.0) which now required that the visitor log be checked to ensure that it contained the date and time of visit. I was so surprised by this I had to check the previous versions to confirm that it had not been specified previously, not least because the visitor log would have been of little use without those details. Sure enough, they had not been previously specified.

It reminded me of a sign I saw at the at the departures security checkpoint in Atlanta Airport some years ago that said that “Firearms ARE NOT Permitted Through Security” and a comment a friend made that signs like that were invariably reactive (ones advising caution that floor is slippery when wet or that an iron is hot also sprang to mind) and, if there was a sign like that, someone almost certainly had tried it.

Both in turn reminded me of previous PCI DSS changes that had made me wonder if a change had been made because someone had tried to argue the point, however obvious the intent of the requirement had seemed (like the need to have date and time in a visitors log) so I have collated some of the more amusing changes I have encountered over the years. I have started at v1.2.1 simply because that is the earliest version with which I have worked.

V1.2.1 to v2.0

• Requirement 5.2 - requirement that “all anti-virus mechanisms are current, actively running, and capable of generating audit logs” updated to require they are also “generating audit logs” – had someone argued that PCI DSS v3.2.1 only required anti-virus software be capable of generating logs but not that it was actually doing so?
• Requirement 9.3.1 – “attempt to gain access to the data center” changed to only “observe the use of visitor ID badges to verify that a visitor ID badge does not permit unescorted access to physical areas that store cardholder data” – had v1.2.1 resulted in too many alarms during assessments?

V2.0 to v3.0

• Requirement 1.1 – firewall and router configuration standards were now required to be “complete and implemented,” rather than just “complete.” To me, it was obvious that that the documentation should accurately reflect actual implementation but, with hindsight, I could see how someone might argue that was not actually required!

V1.0 through to v4.0

And now, back to the change that started all this off. After a bit of checking back through older versions of PCI DSS, I realised that the requirements for the visitor logs had actually been evolving for a lot longer than I had realised:

• V1.0 requirement 9.4 merely specified “Use a visitor log to retain a physical audit trail of visitor activity. Retain this log for a minimum of three months, unless otherwise restricted by law.”
• V1.2 then added that the log should include the visitor’s name, the firm represented, and the employee authorising physical access.
• V3.0 split the log details and retention period into separate sub-requirements, but the actual details required remained unchanged until v4.0 which added the requirement that the log contain the date and time of the visit.

Summary

It was also interesting to see how the PCI DSS has grown since v1.0. Just looking at the raw page count:

• v1.0 – 12 pages
• v2.0 – 75 pages
• 3.0 – 112 pages (note: extensive guidance, previously in a separate document, was now included in the main document, significantly increasing its size)
• 3.2 – 139 pages
• 4.0 – 356 pages

That said, while I did find collating and looking over those changes amusing, it did spark a more serious thought on how important it was to understand the intent behind the requirements as well as the strict letter of the requirements themselves. Some of the above changes had surprised me but more because they were necessary rather than not actually meeting the revised requirements.

Staying with that last example, the guidance for requirement 9.4 has long stated “a visitor log documenting minimum information on the visitor is easy and inexpensive to maintain” and “will assist in identifying physical access to a building or room, and potential access to cardholder data” which would be difficult without the date and time of visits.

In other words, it is important to always keep security objectives as well as strict compliance requirements in mind.

This is, of course, very much my opinion and I would love to hear other views on this, especially if there are any other changes that amused you that I overlooked!