Last month, the PCI Security Standards Council (PCI SSC) released its proposed changes for the Payment Card Industry Data Security Standard (PCI DSS) version 3.0. For security professionals it means that PCI compliance will become more of an everyday business practice, rather than an annual checklist obligation.
Looking ahead, here’s what you can expect from 3.0’s impact on your operations – and the steps you’ll need to take to stay compliant.
Vulnerability management
When it comes to managing system vulnerabilities, Requirement 11 mandates a methodology for penetration testing, including verification that segmentation methods are operational and effective. The reasoning here is that segmentation creates a smaller scope for cardholder data, which shrinks the organization’s attack surface and creates fewer points of entry for attackers. The best way to get there: conducting your own assessments to augment third-party assessments and using those results to reduce the scope of your cardholder data environments.
POS Terminals
When it comes to point-of-sale (POS) terminals, you might not dwell too much on the possibility of physical compromise. Yet many are accessible to the random public and all too often have exposed connections like a keyboard or USB port. All an attacker needs is a simple hardware keylogger or an auto-run USB and boom, they’re in. This is one reason skimming and other attacks are on the rise, and the main reason POS terminals and other payment-related devices must be secured from tampering or substitution. Another mandatory step: careful inventory management, as well as checking device serial numbers and stickers to verify that no one’s tampered with them. These practices might seem tedious, but they’ll go a long way to stopping any physical attacks before they escalate into serious disasters.
Strengthening Password Policies, Tokens and Certificates
Password protection is a major focus of 3.0. While the recommendations aren’t terribly new, they may still be fresh ground for some businesses. To start with, you’ll need to strengthen default passwords for application and service accounts, as well as user accounts. When it comes to user-created passwords, users must protect their credentials and change passwords upon suspicion of compromise. Again, most businesses should already be doing this.
While the minimum-criteria of alphanumeric seven-character passwords is still promoted, alternatives like longer passphrases are now permitted. This means you might consider requiring a relatively long passphrase with uppercase characters, lowercase characters, numbers and special characters. These can be especially secure and even easier to remember than traditional gibberish passwords.
Similarly, security must be tightened for physical security tokens, smart cards and certificates. If you’re not already conducting daily log reviews, now is the time to start. Also make sure that all authentic mechanisms are linked to individual accounts and then protect access to those accounts.
Defining in-scope Systems
In another move toward improved clarity, you’ll need a network diagram showing all connections to cardholder data, as well as an up-to-date diagram that details how cardholder data flows through your systems. 3.0 places more emphasis on defining the in-scope environment on a regular basis, and also emphasizes the application and data layers over the network and infrastructure layers. Ultimately these definitions benefit both auditors and the audited, by illuminating potential weaknesses in a comprehensive risk assessment.
Evolving Malware Threats
Because malware is still a major threat hovering over cloud environments, merchants must now include malware controls even on systems not commonly affected by malware. That includes systems like Linux, which you might (incorrectly) assume was safe. Malware can destroy files, servers and end users, which means that every aspect must be protected with anti-malware technology. Set up an alert system that detects the first sign of digital cancer and you’ll go a long way toward containing the damage and mitigate data loss.
Security and Compliance Responsibility
If your organization isn’t exactly clear on which PCI DSS requirements your group manages and which ones your providers handle, things are about to change. You’ll need to hammer out every detail of who’s responsible for what – and that can be a tall order with the explosion and diversity of SaaS, PaaS, and MssP offerings.
All of these changes might seem like a lot to undertake, but it’s important to remember what’s at stake. Getting compliant isn’t just about passing inspection; it’s about dealing as effectively as possible with the threats targeting applications every day, from XSS attacks to SQL injections.
Security teams have the next 12 months to tackle these operational changes, and whether you have considerable adjustments to make or very few, it’s a good opportunity for your security staff to analyze your programs, tighten up your processes and strengthen your provider relationship. Include compliance in your daily tasks and you’ll have less work to do in crunch time – and your critical business applications will be that much safer.
Related Reading: New Changes to PCI Data Security Standard 3.0 Published
Related News: Boston Restaurant Group Confirms Credit Card Data Theft
