First published in Computing Security magazine
By Ian Whiting (CEO, Titania)
About the Author
Ian has been working with leading global organizations and government agencies to help improve computer security for more than a decade. He has previously been accredited by CESG for his security and team leading expertise for over 5 years. In 2009 Ian Whiting founded Titania with the aim of producing security auditing software products that can be used by non-security specialists and provide the detailed analysis that traditionally only an experienced penetration tester could achieve.
Non-compliance is no longer an option, yet conflicting views still exist upon compliance and security, and what they mean for an organisation. After numerous high-profile breaches (Target, Neiman Marcus), PCI DSS has come heavily under the spotlight. The full extent of these attacks is yet to be revealed, but the compliance industry is already changing to cater to the ever-increasing threats and vulnerabilities that affect the card payment protection industry.
PCI DSS 3.0, which was announced in November 2013, will remain under 'best practice' guidelines until 30 December 2014. The new version addresses some of the issues reported by the industry, such as education, awareness, securing cardholder data and inconsistency in assessments, which have led to poor security practices and compliance failures.
CHANGES TO PENETRATION TEST REQUIREMENTS
According to Verizon's 2014 PCI Compliance Report, Requirement 11 'was the least complied-with requirement […]. Just 23.8% of companies met all the controls between 2011 and 2013'. Requirement 11 concerns vulnerability scanning and penetration testing, and 11.3 in particular specifically deals with the demands of penetration testing. Outlined below are three major changes to Requirement 11:
1. External and internal penetration testing is to be carried out at least annually. This also requires tests to be performed after significant infrastructure or application upgrades. Recommendations include the tests to be performed by a qualified internal resource or a qualified external third-party, according to a defined methodology. In this case, the tester is not required to be a QSA or ASV (Approved Scanning Vendor).
2. Fix exploitable vulnerabilities found during penetration testing and repeat testing to verify corrections. The tests should be undertaken at least annually and after significant changes to the environment - eg, an operating system upgrade or web server additions.
3. Annual penetration tests that verify segmentation is used to isolate the Cardholder Data Environment (CDE). PCI DSS 3.0 guidance advises that penetration testing is to be used to assess how effective the segmentation that isolates CDE from other networks is. It specifies that the testing methodology should be reviewed to ensure all segmentation methods are covered, as well as verifying there is no connectivity between in-scope and out-of-scope networks. The tests should be performed annually and in light of any changes to segmentation controls or methods. These changes outline that, in order to combat the increasing threat, the detail and frequency of internal and external audits needs to increase (especially after system upgrades).
Although some worry that this will put extra time and financial pressures on companies meeting the PCI DSS standard, the reality is that the quality and frequency of tests is often sacrificed by companies for the sake of 'ticking the box'. The refined recommendations for defined methodologies and specified frequency should, in fact, help level the market and provide a fair deal to organisations shopping around for the best pen testing solutions.
Although some PCI requirements are such that no tool can truly perform a fully automated assessment, there is a plethora of cost-effective auditing tools that can help increase speed and accuracy of PCI audits. These can not only be used to ease the cost of internal audits, but also by pen testers to offer more thorough assessments without significantly impacting costs.
.jpg)
.jpg)
