PCI DSS 3.0 Updates and Ramifications for Network and Application Security

Druckfreundlich, PDF & E-Mail

The PCI DSS 3.0 is here. Since Jan 1, 2015 organizations under its purview are required to comply with the updated standard. Many of the changes stem from the recent high profile breaches, despite being compliant. In this post we will concern ourselves mainly with the impact that 3.0 poses to application and network security.

Certain requirements in sections 6 and 11 have an extended deadline of June 30, 2015. The amount of effort needed to meet the updated standard could be substantial and should not be underestimated.

For context, PCI DSS compliance is becoming increasingly important, as losses due to global card fraud continue to escalate:

Philosophically, the updates and new requirements stem from the following observations:
  • Vulnerabilities in third party software, as well as in service providers or contractors pose significant risk to the cardholder environment
  • Perimeter breaches are common and securing within the perimeter is as important as the perimeter itself
  • Pentests need to meet industry-standard methodology
  • Attackers are succeeding due to a lack of proper network segmentation and access controls

Below is a section-wise discussion on the relevant changes.

6.3 Secure development guidelines are applicable to internal as well as bespoke software

Bespoke software refers to all the custom software built by yourselves or a third party. You might be adhering to a secure development process for your own code, but if you source some of it from outside, and if they are not threading security into their SDLC, then they become the weakest links. While this one makes sense, the challenging part is fixing issues in outsourced code, especially when the contract has ended or expertise is lost.

6.5 Updated developer training around common coding vulnerabilities, and to understand how sensitive data is handled in memory

The motivation for doing this is easily traced back to all the POS memory scraping attacks which have hogged the news of late (e.g. Target). While this is a great guideline for software being developed, it could be challenging to review and fix the software programs in production.

6.5.10 Broken authentication and session management

Examples include flagging cookies as secure, not exposing session IDs in URLs and ensuring session IDs are not predictable and time out. The Barracuda Web Application Firewall secures session IDs and cookies by default (using signing or encryption) as well as against session riding and CSRF attacks.

Session IDs in URLs can be hard to fix within the code, but are easily secured using URL Encryption with the Barracuda Web Application Firewall.

While section 6.6 remains largely unchanged, it adds a minor clause to allow for WAFs in monitoring mode. As Gartner’s Anton Chuvakin points out, this is not good, and we agree. This is probably borne out of a desire to avoid false positives, but this effectively prioritizes convenience over security. As anyone who has dealt with a production WAF would know, a WAF sees a lot of attacks. Manual processing of such alerts can introduce delays that can be easily exploited by advanced attackers. The industry best practice is to deploy the WAF in active protection mode and we recommend this.

11.3 Penetration testing should be based on industry-accepted approaches (for example, NIST SP800-115)

Section 11 deals with scanning and penetration testing to evaluate the efficacy of security controls. According to the Verizon PCI Compliance Report 2014, section 11 remains the least met requirement. Just 13.2% of organizations were compliant with it in the last year. One of the reasons for this was that definition and scope of pentesting had been left open to interpretation. This was exploited by shoddy pentesting firms that passed off scanner reports as final pen tester’s report to fill in a check box.

Not so in 3.0. 11.3 provides several updates that are a best practice until June 30, 2015, after which they become a requirement. The first one of these ensures that pen testing confirms to an industry standard and is not a check box formality.

11.3: Pentests should include the CDE perimeter and testing from both inside and outside the network. Application layer pentests must include requirements in 6.5 (e.g. OWASP Top 10).

From an application security perspective, the ramifications are significant. Earlier, you could get away by pentesting your public facing applications only. But now, the scope of the testing explicitly calls out testing within the perimeter.

While this may sound onerous (especially to SMEs), it does make sense. Perimeter breaches are common. Be it an attacker, insider or a contractor, once they are inside, internal applications that have access to cardholder data are prime targets. Their attack surface needs to be as secure as public-facing applications, if not more.

11.3.1/11.3.2 Internal and External pentests need to be done at least annually, and after any significant infrastructure or application upgrade or modification

So, for example, if this was applicable in 2014, you could be redoing the pentests after each of the heartbleed, shellshock, winshock, and poodle attacks which involved substantial patching activity, apart from other significant changes to your our applications.

11.3.4: Includes testing to validate any segmentation and scope-reduction Controls

In the past, attacks on retailers have been succeeding because the networks weren’t segmented properly, so for example the attackers were able to get from HVAC to the POS networks and exfiltrate data out to the Internet.

Having strong segmentation, strict host access controls and application-aware network controls are a logical guidance. If you have not explored the Barracuda NG Firewall features, now is the time to do so.

SMEs under the Gun

Large organizations have dedicated information and application security teams and to some extent they have always been pentesting within the perimeter, often adhering to an industry-specific pentesting methodology such as Penetration Testing Execution Standard. Network segmentation and host access control is also a common architecture found in enterprises. So they will get to 3.0 compliance faster, despite being larger.

However, the brunt of this will be on the SMEs, with their limited budgets and information security staff. They will need help in identifying the CDE, assessing the scope, possibly hiring new QSAs and updating their security solutions and posture across the board – including within the perimeter. Re-architecting their network environment to adhere to the new guidelines also entails significant investments.

The worst thing an SMB can do is to underestimate the scope and challenge of these new directives. The directives make sense from a security perspective, but will require significant investments of time and resources for them to be put in place.

SMEs would also do well by being wary of traditional large security providers who really do not focus on their niche needs and show an inconsistent interest in their markets. They would do well to seek out vendors that provide differentiated, turnkey security solutions that are architected from the ground-up with the midmarket in mind, solutions that are cost-effective, easy to use and administer without requiring an army of professional support personnel and provide a quick time to value.

Nach oben scrollen