The PCI SSC have just released the first supporting document for the new v3.0 standard to curiously very little fanfare. The lack of announcement and coverage for this may be because it is only the glossary, but as I will explain this is actually a crucial supporting document and deserves a bit of dissecting in relation to what effect it will have on compliance.
The first thing to understand about the importance of the glossary is that this is how the PCI SSC defines the various terms and acronyms that litter the PCI DSS, and whilst in many cases these are commonly known concepts or acronyms the PCI SSC do take some terms and define them in relation to the PCI DSS, i.e. this is what they expect people to do to be compliant.
Having poured over the new glossary I have found that there are a very large number of new additions in v3.0 (44 to be precise), a few changes to existing definitions (7 by my count) and interestingly 2 removals. Looking first at the additions, there are a number of acronyms that the PCI have been using for a long time such as AOC, MO/TO, Track Data, etc.
Another significant proportion of the additions are for commonly known IT security concepts or technologies like: ‘Cross-Site Scripting XSS’, IMAP, URL, ‘Least Privilege’, NAC, S-FTP, POP3, ‘Proxy Server’ etc. Many people tasked with implementing a PCI DSS compliance project are not ‘techies’ and so to include the definitions here is a good move in my opinion as it makes the standard more accessible to those with less technical acumen.
The rest of the additions relate to specific PCI DSS terms that were either missing from the v2.0 glossary or are new to the v3.0 standard and whilst some are fairly simple such as ‘Data-Flow Diagram: A diagram showing how data flows through an application, system, or network’ there are two that stand out as being quite important for compliance.
The first of these is “Virtual Payment Terminal – A virtual payment terminal is a web-based access to an acquirer, processor or third party service provider website to authorize payment card transactions, where the merchant manually enters payment card data via a securely connected web browser. Unlike physical terminals, virtual payment terminals do not read data directly from a payment card. Because payment card transactions are entered manually, virtual payment terminals are typically used instead of physical terminals in merchant environments with low transaction volumes.” VPT’s were mentioned when it came to completing an SAQ-C-VT but had never been clearly defined as to what the PCI SSC considered them to be so this definition will help a great deal of merchants in deciding which SAQ is correct for them, which as many of you will know is one of the big problems facing SME’s as they don’t have the technical knowledge to be able to properly select the right SAQ.
The second important addition is “Security Event – An occurrence considered by an organization to have potential security implications to a system or its environment. In the context of PCI DSS, security events identify suspicious or anomalous activity.” This is a new term that has been used in Requirement 10.6.1 (Review the following at least daily) and is the first item on the list of daily reviews ‘All security events’. Unfortunately the definition of what the PCI SSC consider a ‘security event’ is rather vague, in fact it leaves the decision completely up to the organisation and their opinion of their systems and environments, I can see this becoming a point of major discussion between the organisations and their respective QSA’s as to what qualifies. But hopefully pragmatic QSA’s will mean that this doesn’t become a stumbling block to compliance for organisations.
The two removals are interesting but not particularly significant, they are “RBAC: Role Based Access Control” which was probably removed due to confusion with Rule Based Access Control (although they could have put that in and differentiated between them RoBAC/RuBAC) and the other is “Salt: Random string that is concatenated with other data prior to being operated on by a hash function” as this is already included in the definition of Hash and so was probably considered redundant.
The seven changes are almost all simple clarifications, such as adding biometric data to the examples of PII, but one of them is very crucial and will affect all PCI DSS compliant organisations and in some cases may need a lot of work to implement. This is the change to the definition of ‘Strong Cryptography’ in which they still refer to the NIST Special Publication 800-57 part 1, but have updated the minimum key lengths to:
- AES (128 bit)
- TDES (triple length)
- RSA (2048 bit)
- ECC (160 bit)
- ElGamal (2048 bit)
This means that in order for organisations to transition to V3.0 they are going to have to update their cryptographic keys to the new minimum standards before the end of 2014. For some this will be relatively easy, but for medium to larger organisations this could be quite a large project. This will also require a robust key management system and policy as the old keys will need to be retired but probably stored in for a certain amount of time in case of legacy issues, so managing the process of retiring and replacing the keys in line with the other PCI DSS requirements could prove tricky for some.
In short, the new glossary may not be considered an important document by many but the changes it makes to the new standard could be quite significant for some. Of course many organisations may already be compliant with these changes but many more won’t be.