The big news today is that version 2.0 of the Payment Card Industry Data Security Standard (PCI DSS) has been released in final format. It replaces version 1.2.1.
Version 2.0 does not introduce any new major requirements. The majority of changes are modifications to the language, which clarify the meaning of the requirements and make understanding and adoption easier for merchants.
Although this is great news it still begs the question of why it is designated a major release (e.g. 2.0 instead of 1.3).
The major changes, as opposed to new major requirements, include the following:
- More formal Cardholder Data Environment (CDE) scope exercise before an assessment
- Centralized logging of application data as well as all systems
- Incorporation of the risk-based approach for vulnerability management
This is said to be the start of a three year lifecycle but validation for version 1.2.1 is allowed through the end of 2011. The overlap allows either version 2.0 and 1.2.1 for the entire next year; organizations are only encouraged to use 2.0 in 2011.
Perhaps most important of all is this new item that addresses virtualization:
2.2.1.b If virtualization technologies are used, verify that only one primary function is implemented per virtual system component or device.
It is not allowed to run multiple primary functions on a virtual system — one primary function per system component or device, even when running a virtual system.
This should be interpreted as enabling multiple virtual systems to run on shared physical hardware as long as each virtual system has just one primary function:
2.2.1 Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.) Note: Where virtualization technologies are in use, implement only one primary function per virtual system component
A hypervisor is a virtual system component. It’s primary function is to support multiple hosts. Each host is a virtual system component. They have to have only one primary function each.
I’ve been told that you aren’t allowed to have your encryption keys stored on the same server as your database and that a device is required for key management. Is that true because I can’t find anything on the PCI website that says a device must be used. If you can point me to some documentation on this that I can provide to an auditor, that would be great. Thanks!
George, I do not have enough information on your system to say whether I agree with your assessor. In the meantime the test for Requirement 3.4.1.b is where I would start:
Storing keys on the same server as a database is not prohibited. Does that answer your question? There still is a burden of proof to show they are “stored securely”. That has a lot to do with the fact that the Requirements apply to a broad range of environments so removable media is not always an option or the best option.
Another way to look at it is from the breach or attack vector perspective. A key that can be stolen easily with the encrypted data is definitely not what you want to happen. I just reviewed a breach case the other day where the key was stored in the same directory as the database with the same permissions. That is an example that would not pass Requirement 3.