The Payment Card Industry Data Security Standard (PCI DSS) was designed to protect cardholder data, and usually gets updated once every three years. Auditors test credit card companies’ PCI DSS compliance even more often than that — once a year. Couple that with the fact that the more rigorous version 3.1 is now in effect, and it’s no surprise that the pressure is greater than ever on these organizations to constantly have PCI regulations top of mind when it comes to their everyday compliance operations.Staying compliant with the requirements of the

Payment Card Industry Data Security Standard (PCI DSS) in a
cloud computing environment can be challenging for
organizations.But, it’s important for security professionals to
understand that there is no one-size-fits-all approach to
compliance in the cloud.

1. Determine Your True Business Requirements

It’s important to keep in mind that PCI DSS compliance is not a one-time event, but an ongoing process and, ultimately, a change to the way you do business.

2. Inventory Assets and Locations

What business processes use credit card data?
Where is the cardholder data (CHD) stored?
How is the cardholder data (CHD) accessed?
What are the ports and protocols used when transmitting cardholder data (CHD)?
What technology assets are involved in the data flow?

3. Segment the Environment:

Segment the technologies and, in some cases, the business processes that store, process, or transmit cardholder dataTo ensure that this doesn’t happen at your organization, make sure that you segment your processing environment and implement inventory processes described above to validate whether cardholder data is flowing into environments that it shouldn’t. Lastly, implement strong governance (e.g. change management) practices to ensure systems are located in the correct network zones prior to being moved into production.

4. Operationalize Controls/Maintain Compliance

A plan should be put into place to address how PCI DSS controls will be affected when employee turnover, employee promotion and changing priorities occur.The intent to be PCI compliant is there, but the willingness or ability to keep up, (change management)

5. Control Monitoring and Automate Controls

In order to ensure PCI compliance in the long-term, you must automate control activities. The primary reason for this is that no matter how hard we try, we humans are fallible.

PCI DSS 3.1:

The Secure Sockets Layer (SSL) and Transport Layer Security (TLS) encryption protocols that can put payment data at risk.

Updates the three key requirements that specifically mention SSL — 2.2.3 (encryption for VPNs, NetBIOS, file sharing, Telnet, FTP and similar services), 2.3 (encryption for Web-based management and other non-console administrative access) and 4.1 (encryption of cardholder data during transmission over open, public networks) — to eliminate SSL and “early TLS” as examples of strong cryptography. The SSC defines “early TLS” as TLS version 1.0 and in some cases 1.1, depending on where it’s used and how it’s implemented.

Effective immediately, merchants are prohibited from implementing new technology that relies on SSL and early TLS; as of June 30, 2016, merchants will no longer allowed to use SSL and early TLS in any way as standalone security controls to protect payment data.

The move was precipitated by last year’s update to National Institute for Standards and Technology (NIST) Special Publication 800-52. In that document, NIST stated that only TLS 1.1 and 1.2 are secure enough for government use, signaling that SSL 2.0, SSL 3.0 and TLS 1.0 are no longer acceptable as strong encryption standards. However, many merchants still use the first version of TLS and in some cases even SSL in their cardholder data environments.