Top 10 PCI Compliance Mistakes
Configuration mistakes, access control gaffes, and scoping issues top the list of common PCI errors
As organizations continue to work hard on their PCI compliance efforts in 2012, security experts warn that in order to cost-effectively achieve compliance and security goals, they'll need to avoid these common mistakes along the way.
1. Not Following Rule Of Least Privilege
According to Leonid Shtilman, CEO of Viewfinity, organizations play fast and loose with their interpretations of PCI 2.2.3, which says they should "Configure system security parameters to prevent misuse.” As he puts it, organizations have to drill down into user roles in order to ensure that they're following the rule of least privilege wherever PCI regulations apply.
More Security Insights
- Remote Data Replication: Combat Disasters And Optimize Business Operations
- Taneja Group: Overview of Virtualization and Cloud Market Vendor Landscape for SMBs
- Strengthening Enterprise Defenses With Threat Intelligence
- Strategy: Advanced Persistent Threats: The New Reality
"It is not acceptable to allow any privileged user to have access to all data, rather permissions for server administrators should be granted and/or dropped based upon specific role and responsibility tied directly to the applications and processes for which they require authority in order to fulfill their job requirements," he says. "No more, no less -- only the least privileges required.”
And yet, that isn't really what's happening at most organizations, says Eric Chiu, president and founder of HyTrust..
"It is not uncommon for many employees at an organization to have access to the data, including those who don't require it to fulfill their job functions," he says.
2. Ignoring Virtualization Compliance
Vidyadhar Phalke, CTO of MetricStream says that many organizations tend to overlook virtualization compliance, a fact that can cause auditors to see red.
"PCI DSS 2.0 mandates that even if one VM deals with cardholder data, your entire virtual infrastructure must comply with the standard. The challenge is -- the wording in PCI DSS on virtualization is vague and it all depends on the interpretation of the auditors," he says. "So organizations need to ensure that they comply with this early on and completely understand the risk and controls in place to avoid last-minute surprises."
3. Failing To Change Vendor Default Configurations
Virtualization particularly throws organizations for a loop when it comes to complying to PCI DSS 2.0 Requirement 2.1, which requires that vendor defaults passwords and configurations are changed.
"A virtual machine can easily be duplicated and deployed using vendor-supplied defaults," says Chiu of HyTrust. "Controls to prevent this in a traditional IT environment, such as scanning the network for new systems, become less effective in a virtual environment, so an auditor may easily fail to notice defaults, as an entity has to manage virtual machines from within the virtual environment itself."
4. Failing To Properly Define Scope
Network segmentation to tighten the security compliance lens on a smaller scope is an essential part of smart PCI compliance.
"While technically not a PCI requirement, anyone that has worked with PCI knows that it is all about scope," says Tom McAndrew, executive vice president of professional services at Coalfire Systems. "Scope is the definition of what is in and out of PCI requirements."
However, many organizations fail to determine scope properly.
"The most common mistakes are missing systems which are “connected to” in-scope systems," McAndrew says. "The basic way to determine if a system is “in-scope” is to ask yourself “is there any way that this ‘out of scope system’ could possibly impact the security of cardholder data.” If the answer is yes, then consider it in-scope.
5. Fixating On Putting Things Out Of Scope
While it is important to get things out of scope, organizations do themselves a great disservice if they make the process of getting things out of scope more important than addressing real risks.
"Many merchants try to put systems out of scope, but forget to then manage risk which can bring them down moments later. For example, a merchant using a page redirect on an e-commerce site for payment captured to reduce scope," says Mark Bower, data protection expert and vice president at Voltage Security. "The merchant's e-commerce server could be compromised, and a fake redirect page put in place to steal cardholder data. Out of scope does not mean out of mind, and hackers don't care -- if systems or data can be compromised, they will be. Risk mitigation should come first. That's the whole point of PCI in the first place."
Next Page: The cost of compensating controls.