Gavin Watson, a penetration tester and senior security engineer at Accumuli Security company (www.accumuli.com) company, RandomStorm (www.randomstorm.com) writes after the Payment Card Industry Security Standards Council issued an update to PCI DSS. Version 3.1. That gives merchants 14 months to stop using SSL for securing online transactions. The earlier version, 3.0, also calls for regular penetration testing and segmentation of the card data environment. Gavin, pictured, provides his tips on complying with PCI DSS 3.0 and 3.1, with examples of how to conduct penetration tests that exploit vulnerabilities.
What’s new?
Version 3.1 is the second guidance published by the Payment Card Industry Security Standards Council (PCI SSC) in as many months. In March, PCI SSC advised merchants on how to comply with PCI DSS 3.0 section 11.3, which calls for regular testing of security controls used to separate and protect the payment card data environment and covers penetration testing. Penetration testing, involves hiring qualified security experts to seek various ways to access the card data environment (CDE). If a tester can break in, so can criminals.
Key requirements
PCI DSS 3.0 introduced a level of rigour to penetration testing including the following five key requirements:
· Penetration tests must be structured using an industry-accepted model, for example, using a framework such as NIST SP 800-115
· Both application-layer and network-layer vulnerabilities must be assessed
· Testing must be carried out internally and externally at least once a year, and more frequently following any significant change to the network infrastructure or applications
· Testing must cover the entire cardholder data environment, including the effectiveness of any controls designed to reduce the environment’s scope.
· Exploitable vulnerabilities discovered during the test must be addressed and retested.
Segmentation
Recent advice from PCI SSC particularly highlights the need to ensure that the CDE is adequately segmented from the rest of the network. Poor segmentation has been identified as a key factor in major payment card data breaches, where cyber criminals initially compromised networks that were considered to be out of scope, and were therefore less well protected, and then used these weak points to breach the CDE. Regular penetration testing helps merchant organisations to ensure that the CDE is adequately segmented and protected from internal and external attacks.
Test regularly
Because newly-discovered flaws in networked appliances, web services, applications and operating systems are published on an almost weekly basis, the new guidelines call for more regular penetration testing to maintain segmentation and security of the CDE in between quarterly and annual audits.
Who to call
In the latest guidance PCI SSC has explained what a penetration test involves; outlined the methodology that meets pre-test, test and post-test requirements; and shown how to create a penetration test report that complies with the latest guidance. PCI also advises merchants on how to select testers based on their qualifications and experience. A list of PCI Qualified Security Assessors can be found at: https://www.pcisecuritystandards.org/approved_companies_providers/qsa_companies.php
Proof of the pudding
It is no longer sufficient to theoretically find and fix a vulnerability. The latest PCI guidance clarifies the requirement that merchants must actually try to exploit vulnerabilities uncovered during the penetration test, so that the level of risk to card data can be adequately assessed.
Example of a pen test
As an example of the pen test methodology that can be employed, RandomStorm pen testers were recently called in by a merchant to test whether its CDE could be accessed. The test involved a combination of social engineering and wireless hacking. By posing as an engineer, our security expert was able to connect a Raspberry Pi device to the network point used by an employee’s computer. The Raspberry Pi had a 3G wireless transmitter that allowed an offsite tester to conduct network attacks from a nearby café. The penetration test enabled the merchant to immediately review its policies and procedures for escorting, challenging and reporting visitors to its facilities.
The human factor
The IBM Cyber Security Intelligence Index 2014
Depending on the scale and scope of the assessment, sometimes a number of scenarios, with varying degrees of sophistication, will be played out to test whether the penetration tester can breach a company’s defences. A phishing email test might deliberately include inconsistencies in the email signature, spelling mistakes, or a different domain name. This provides the merchant with the potential to see what proportion of its staff spot the spoof attack and report it. The client can use the test to see whether employees are looking out for phishing emails and reporting them and whether they are simply ignoring, or, worse, clicking on links in the emails. Varying degrees of attack can be launched simultaneously during the pen test, so that a structured assessment and report can be provided, with clear guidance on remediation.
Social engineering
In one phishing email test that we undertook, we sent a client’s employees an email advertising a new coffee shop opening nearby, with a money off voucher attached. Our client was astonished to find that 17% of the employees clicked on the link to receive the voucher, allowing us to demonstrate a potential route for keylogger spyware and other malware to be installed on the client’s network. Going by SmartInsights Marketing Email Statistics
Constructive criticism
It is important to remember that penetration tests need to be handled carefully, as some employees may react negatively to being phished by their own company. The objectives need to be communicated clearly, otherwise employees may feel that they have ‘failed’, leading to anger, a loss of trust, resentment and lowered morale. Pen tests that are conducted by an external organisation tend to be viewed as more of a procedural undertaking and less of a personal attack on individual employees. In our experience, employees’ perceptions are generally more positive and receptive when we undertake the tests because we come back with constructive pointers as to how the organisation can improve its security by tightening up procedures and processes, rather than pointing the finger of blame at individuals or departments.
Involving employees
When training, we get employees to work with us and, starting with the assets that they are responsible for protecting, we ask them to brainstorm how they might try to get to that asset. We teach them the basics of how to socially engineer. Then we get them involved in role play to see how they would challenge a real attacker who was trying to physically access their building, or get information over the phone. This then empowers them to think in terms of asset protection and consequences of a breach, and provides them with the skills to spot and thwart attacks.
Communicating results
A fundamental aspect of effective evaluation is to maintain a clear structure to the test. Presenting convoluted results to clients is rarely effective in helping them to improve their ongoing security. It is important to keep scenarios clear and consistent so that tests identify the vulnerabilities that they were designed to. Additionally, documentation of the process is crucial for helping merchants to understand which issues and procedural flaws were identified and to provide a reference for future tests. Pen test reports have to be delivered with tact. We always steer the debrief conversation in the direction of remediation and education. It is essential that for pen testers to be aware of the emotional state of people being debriefed. It is not uncommon for clients to be shocked and angry that they were breached during the evaluation and to react by blame-storming. Embarrassing employees, even unintentionally, is likely to cause resentment and resistance towards the assessor and the pent test findings.
Incorporating test results
We have found that splitting the penetration test deliverables between a debrief session and a written report works very well. The debrief allows the security consultant to frame the findings: explaining where the vulnerabilities identified are procedural and not the fault of individuals, so that the management team can see how to move forward and improve. By the time the report arrives, around a week later, the debrief and remediation advice is viewed in a more constructive manner, because the organisation has had time to think about the highlighted vulnerabilities and the consequences if they were exploited. The pen tester’s advice should ideally find its way into the next round of staff awareness training to enable the client organisation to make significant improvements in its security posture.
Conclusion
Version 3.0 of PCI DSS emphasises the need to segment the card data environment and conduct regular penetration tests to assess security controls, using a combination of application-layer, network-layer and social engineering testing. As threats to the CDE evolve, the guidelines for its protection must be updated and it was anticipated that PCI DSS 3.1 guidance would be published during April 2015 to address the POODLE bug SSL 3.0 encryption protocol vulnerability. It is only by regularly testing and responding to newly discovered vulnerabilities that merchants can manage the ongoing risk to their customers’ payment card data.”
References:
Payment Card Industry Data Security Standard documents library – https://www.pcisecuritystandards.org/security_standards/documents.php
