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.

"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. 6. Using Compensating Controls As A Crutch
According to Bower of Voltage, if you think that compensating controls are a way to skirt around compliance burdens, you're probably tackling this PCI business the wrong way.

"Compensating controls are used when there is no means of directly meeting the requirement. For example, some organizations will assume that because they have legacy systems they cannot encrypt or tokenize stored card data in a database or application," he says. "Today, it's entirely possible to do that -- even on legacy systems like Mainframe and HP Nonstop to reduce the risk of a breach whist meeting the compliance need."

Besides that, he warns that compensating controls can cost the organization a lot in paper audits and additional investments in business processes and tools.

7. Bringing PA DSS-Certified Software Out Of Compliance
Just because you've bought some PA DSS certified software to process credit cards doesn't mean you're off the hook just yet, warns Marc Gaffan, co-founder of Incapsula.

"Software that is PA DSS certified must be run and operated in a PCI compliant environment in order to suffice the PCI DSS regulations," he says. "This means that you need to ensure that your IT environment and all related service providers are also PCI compliant in order to uphold the overall compliance of your certified software or e-commerce platform."

8. Failing To Separate Duties
Both PCI DSS Requirements 3.4.1 and 3.5 mention separation of duties as an obligation for organizations, and yet many still do not do it right, says Todd Thiemann, senior director of product marketing for Vormetric.

"In order to properly implement separation of duties, enterprises need adequate staffing," Thiemann says. "One common mistake is allowing developers or DBAs to see production data. This usually occurs due to understaffing in IT departments."

9. Poorly Managing Encryption Keys
PCI Requirement 3.5.1 states that organizations need to store cryptographic keys securely in the fewest possible locations and forms. Problem is, most organizations are terrible about key management.

"Enterprises should never store encryption keys alongside encrypted data. It doesn’t help if you lock the door with the key taped to the doorknob," Thiemann says. "Too many encryption solutions do not include proper key management and enterprises are prone to cutting corners when it comes to properly managing encryption keys."

10. Failing To Track Cardholder Data Flows
According to John Nicholson, counsel for the global sourcing practice at the Washington, D.C.-based law firm of Pillsbury Winthrop Shaw Pittman, organizations don't do enough to map their data flows for cardholder data to find out the whats, wheres, hows and whys of what's stored.

"Through that process, organizations can identify collections of cardholder data -- and other data that could be subject to a data breach -- and either get rid of it or encrypt it at rest," Nicholson says. "A lot of times companies discover that they are storing cardholder data in Excel spreadsheets or other formats that are difficult to control and protect. By doing the kind of data flow analysis I've mentioned, companies can identify these practices and deal with them."

Think that nobody still actually stores cardholder data in spreadsheet? It really does happen, says Ken Menken, CEO of Capalon Communications, Inc.

"True story: A medium-sized business came to us because they needed a better and more convenient solution for online registrations. Their then-current solution was their hosting provider e-mailing them a daily Excel spreadsheet, including all credit card information -- complete with CVV codes," Menken says. "And that didn't happen in 2009 -- it just happened now, in 2012. I cringe just thinking about it."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.