Welcome Guest. | Log In | Register | Membership Benefits

Top 10 PCI Compliance Mistakes

Configuration mistakes, access control gaffes, and scoping issues top the list of common PCI errors

Jan 16, 2012 | 06:19 PM | 

By Ericka Chickowski, Contributing Editor
Dark Reading


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.

1 |  2 |  Next Page » 



Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dark Reading encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dark Reading moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. Dark Reading further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
Subscribe to RSS



Compliance Reports

report How To Boost Security Via FFIEC Compliance
With just a smartphone, users can conduct nearly all their banking business at any time of the day or night. However, all this flexibility and convenience opens up new avenues for fraud and cybercrime. Guidelines laid out by the FFIEC several years ago predate many of the capabilities-and vulnerabilities-that are in place today. In this report, we examine the latest guidelines and provide advice on how you can extend the work done to comply with FFIEC guidelines to strengthen your organization's overall security posture and keep customers and their data safe.

report Keeping Compliance In Check
Configuration mistakes, access control gaffes, poor documentation--it doesn?t take much for a compliance audit to go all wrong. In this special retrospective of recent news coverage, Dark Reading takes a look at the costs, common missteps and best practices for compliance, as well as the day the Internet nearly went dark due to the threat of new regulations.

report FISMA Lifts All Compliance Boats
FISMA may not be on your radar now, but it likely will be at some point. Geared specifically toward the federal government and its affiliate agencies and third parties, FISMA is a very specific set of requirements aimed at establishing and maintaining at least a baseline level of computer and network security. FISMA requires unique categorization and classification of information assets, not to mention a boatload of documentation to prove compliance. But once your organization achieves FISMA compliance, it will likely be compliant with just about every security mandate out there.

Other reports from the Compliance Tech Center:

Related Content

Log Management in 2012 and Beyond
2012 brings interesting changes to the log management world. Now, more than ever, it is critical to understand the impact to your log infrastructure and the solutions that will better prepare you to manage your security posture.

SANS Log Management Survey Report
Organizations are increasingly dependent on log management to support core business functions, including cost management, service level and line-of-business application monitoring, as well as traditional IT- and security-focused activities.

Cut the Time and Effort of Troubleshooting and Reporting
Organizations generate millions of logs a day and struggle with centralized collection, storage and analysis of those logs. ArcSight Logger is a universal log management solution that unifies searching, reporting, alerting and analysis across any type of IT data. It consolidates silos of logs into a single indexed repository for fast detection and mitigation of operational issues.

Get Turnkey and Automated PCI Compliance
PCI compliance monitoring is seamless with the self-contained ArcSight PCI Logger solution for log collection, storage and analysis. No database administration expertise is required and a web-based interface simplifies deployment and ongoing management.

Swiss Bank Meets Compliance Requirements and Protects Customer Data
Due to long-term data retention requirements, Swiss bank EFG needed a cost-effective way to collect, secure and store audit-quality log data in an easily accessible log repository. ArcSight Logger helps EFG meet key requirements of Switzerland?s banking laws fast and cost-effectively.




Featured Webcasts
Featured Whitepapers
Featured Reports