With PCI DSS version 3.0 in full force, there's still a good bit of talk about enterprises struggling to implement...
the PCI penetration testing requirements outlined in section 11.3.
In an effort to help organizations fully understand what's expected, the PCI Security Standards Council published its PCI DSS Information Supplement: Penetration Testing Guidance, in March 2015. This document details the general methodologies of the penetration testing process from scoping to testing different network layers, to post-engagement steps such as reporting.
The good thing about the PCI penetration testing document -- and the approach required for PCI DSS compliance -- is that there's really nothing new. Outside of references to newer concepts involving cloud environments, phishing and narrowing the scope of the cardholder data environment, these penetration testing/security assessment practices have been around for years. When I wrote the first edition of my book, Hacking For Dummies, back in 2003, I recall researching some of these very topics and the resources being quite prevalent back then. From thinking like a hacker to unique exploits across different operating system platforms and specific methodology for carrying out penetration testing -- the information was there in the form of the Open Source Security Testing Methodology (OSSTMM), as well as numerous whitepapers, articles and the like.
Fast forward to 2015.
I don't know if you call it analysis paralysis, lack of budget or mere stalling tactics on the part of executive management, but it's as if many people have been waiting for the PCI Security Standards Council to tell them how to do something that's been well-documented for over a decade.
While organizations should read the new PCI Penetration Testing Guidance document in its entirety, here are some notable areas enterprises should focus on:
- What's required in terms of authenticated testing of application environments are discussed -- a component of penetration testing that's often overlooked, yet can be extremely valuable.
- What's considered a "significant change" to a system so that follow-up penetration testing can take place after code or related updates are made to any system in the cardholder data environment.
- Certifications and past experience of security professionals doing this work -- like any field, more experience is often best, but so is having good tools such as vulnerability scanners, network analyzers and exploit toolkits and knowing how to effectively use them.
- Specific rules of engagement that outline details that are often overlooked and can create problems during and after penetration testing, such as how far the exploitation needs to go and how to handle sensitive data that may be uncovered during the testing. I really like how the document addresses security controls that may block tests (e.g., WAFs and IPSes). Many people assume because they have such controls and no vulnerabilities can be discovered or exploited, that all is well. Regarding whitelisting or disabling these active protection measures, the Penetration Testing Guidance clearly states it "helps ensure that the services themselves are configured properly and have the minimal risk of being exploited in the event the active protection system fails or is somehow defeated or bypassed by an attacker."
- Recommendations around social engineering, including phishing tests, to see if any part of the cardholder data environment can be exploited from that angle.
- Retaining evidence of the testing details (including specific findings) so it's available upon request.
The next-generation security assessment is here. Well, sort of.
Outside of growing network complexity and other small nuances related to PCI DSS and general security testing best practices, it's actually not a lot different from what we've been doing in the past. Don't get off in the weeds looking for something new. In car racing, we are taught that if we focus our eyes in the direction we want to go, the car will follow. The same concept applies to information security and, in this case, the evolving PCI DSS penetration testing requirements. You now know what needs to be done. It's just a matter of immersing yourself and seeing it through -- or outsourcing the penetration testing function altogether.
Check out NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, the OSSTMM, and other resources on vulnerability scanning and penetration testing. If you stay on track with these general guidelines you should be fine.
Looking ahead, what if you get into a situation where you cannot fully implement the new PCI DSS rules? Whether you do -- or don't do -- something that's required of your organization, there are consequences for any decision you make. I think the most important thing is you get started today making reasonable and concerted efforts to improve your existing penetration testing and overall security program. I believe it's the people who continue down the path of basic vulnerability scans -- or no testing at all as I still sometimes see -- that will be the target of greatest scrutiny.
You don't necessarily have to be at the front of the pack with a flawless security testing program, but you definitely don't want to be bringing up the rear. Being in the middle of the pack with the goal of continuous improvement is just fine.
About the author:
Kevin Beaver is an information security consultant, writer, professional speaker and expert witness with Atlanta-based Principle Logic LLC. With over 26 years of experience in the industry, Beaver specializes in performing independent security vulnerability assessments and penetration tests of network systems, as well as Web and mobile applications. He has authored/co-authored 12 books on information security including the best-selling Hacking For Dummies and The Practical Guide to HIPAA Privacy and Security Compliance. In addition, he's the creator of the Security On Wheels information security audio books and blog providing security learning for IT professionals on the go. You can reach Beaver through his website and follow him on Twitter at @kevinbeaver.
PCI DSS 3.1 marks the end of SSL and early TLS. Learn how to create a PCI DSS 3.1 migration plan