Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

8/20/2008
01:24 PM
George V. Hulme
George V. Hulme
Commentary
50%
50%

Sneak Peek: New PCI DSS Rules

Updates to the Payment Card Industry Data Security Standard (PCI DSS) have been released by the PCI Security Standards Council. The updates, hopefully, will bring some clarity to a number of areas which retailers, merchants, and auditors say are foggy.

Updates to the Payment Card Industry Data Security Standard (PCI DSS) have been released by the PCI Security Standards Council. The updates, hopefully, will bring some clarity to a number of areas which retailers, merchants, and auditors say are foggy.Come this October, the current PCI DSS Standard 1.1 will become 1.2, and to help retailers that accept credit card payments prepare for the changes, the PCI Security Standards Council released a summary of the anticipated changes coming this fall. In its announcement, the PCI DSS summed it up this way:

Changes to the PCI DSS include clarifications and explanations to the requirements, with these clarifications offering improved flexibility to address today's security challenges in the payment card transaction environment. The new summary document on these changes highlights the key clarifications by requirement. These clarifications will also eliminate existing redundant sub-requirements while improving scoping and reporting requirements.

Quite the bureaucratic mouthful, isn't it? That's a lot of words to say: We're clearing some things up for you. And after a superfluous, yada-yada sounding quote (every press release needs one, don't you know), the release went on to say:

With the summary of changes to the revision of the PCI DSS, the Council is giving stakeholders guidance on what to expect when version 1.2 is publicly available. The Council is finalizing the changes to the standard and will be providing its Participating Organizations with version 1.2 in early September.

Until September, we have the new PCI DSS Summary of Changes document to work from.

While there are too many updates in this document to list in a blog post, many of the changes are minor tweaks to legalese verbiage, such as clarifying that the requirement for antivirus software applies to all operating systems, and using consistent terms for encryption. Other changes will be more profound to retailer security practitioners and PCI DSS assessors.

One such change comes to PCI DSS Requirement 6, which calls for the development and maintenance of secure systems and applications. Like this needs to be a formalized requirement, but in the world we live in -- where expediency and cost-cutting rule over the responsibility to protect your information -- apparently so. Requirement 6 will be updated to allow a risk-based approach to prioritize patch updates. This is, overall, good news. No one needs to feel the pressure to patch "highly critical" print-server vulnerabilities buried 10 firewalls deep and three network segments from the Internet the same day "Intermediate-level" risks are on servers in the DMZ. From a risk-based perspective, it just makes zero sense to treat all patches equally. Trouble comes into paradise for those retailers whose eyes glaze when you ask them to actually implement a risk-based vulnerability management program. Oh, my!

The other clarification in the document regarding Requirement 6 is a restatement to what I thought already had been clarified. Maybe not, but here it is:

Requirement 6.6 is now mandatory. All public-facing Web applications are subject to either 1) reviews of applications via manual or automated vulnerability assessment tools or methods, or 2) installing an application-layer firewall in front of public-facing Web applications.

Considering how many, many attacks are now going straight down the throats of Web applications, any additional security attention here is a good thing. But this reads as if installing a Web Application Firewall (WAF) negates the need for any code review. That's not true, as section 6.5 clearly states that secure coding is the order of the day:

Develop all Web applications based on secure coding guidelines such as the Open Web Application Security Project guidelines. Review custom application code to identify coding vulnerabilities. Cover prevention of common coding vulnerabilities in software development processes, to include the following:

6.5.1 Unvalidated input 6.5.2 Broken access control (for example, malicious use of user IDs) 6.5.3 Broken authentication and session management (use of account credentials and session cookies) 6.5.4 Cross-site scripting (XSS) attacks 6.5.5 Buffer overflows 6.5.6 Injection flaws (for example, structured query language (SQL) injection) 6.5.7 Improper error handling 6.5.8 Insecure storage 6.5.9 Denial of service 6.5.10 Insecure configuration management

Good security problems to eradicate, all. And whether you have a WAF installed or not, periodic application assessments are the way to go. Any retailers relying on WAF need to make sure they're set to actually block attacks. Otherwise, you get this dangerous false sense of security going on. Just monitoring Web application traffic as retailers get pwned doesn't get them past Go. Yet, monitor mode is the way many of these WAFs are configured (you know it's true).

Actually setting them to Block malicious traffic is a clarification I'd like to see in big, bold font in section 6.6.

 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/3/2020
Pen Testers Who Got Arrested Doing Their Jobs Tell All
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/5/2020
New 'Nanodegree' Program Provides Hands-On Cybersecurity Training
Nicole Ferraro, Contributing Writer,  8/3/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-12777
PUBLISHED: 2020-08-10
A function in Combodo iTop contains a vulnerability of Broken Access Control, which allows unauthorized attacker to inject command and disclose system information.
CVE-2020-12778
PUBLISHED: 2020-08-10
Combodo iTop does not validate inputted parameters, attackers can inject malicious commands and launch XSS attack.
CVE-2020-12779
PUBLISHED: 2020-08-10
Combodo iTop contains a stored Cross-site Scripting vulnerability, which can be attacked by uploading file with malicious script.
CVE-2020-12780
PUBLISHED: 2020-08-10
A security misconfiguration exists in Combodo iTop, which can expose sensitive information.
CVE-2020-12781
PUBLISHED: 2020-08-10
Combodo iTop contains a cross-site request forgery (CSRF) vulnerability, attackers can execute specific commands via malicious site request forgery.