Get Your Money’s Worth PCI Pen Testing:
Richard Hollis B
y now, we all know about the cost and complexity of PCI DSS compliance. Business professionals everywhere have been struggling in the current market climate to meet PCI program implementation challenges, with little or no qualifi ed staff or fi nancial resources. Every line item activity must be confi rmed as being required, and its purchase must guarantee that it will bring the organization one step closer to compliance. Given that network and application security penetration testing are such large- ticket items, you would think that CIOs would scrutinize them to ascertain their scope and applicability to compliance objectives. If you thought so, then you’d be wrong. In general, pen testing is often seen as a service best delivered by the ‘experts’. Testing companies, while often very good at their craft, do not automatically understand your specifi c business drivers and objectives. They believe that their job is to answer the question: ‘Can someone get unauthorized access to my system?’ While the answer to this question may be very important, it has little or no relevance to achieving PCI compliance, and a CIO paying for a pen test without establishing the right objectives wastes both time and money.
The purpose of conducting a pen test of a network or application that processes, stores
50
or transmits card holder data is to discover if it’s possible to get unauthorized access to this data. This is not only the right objective, it’s the only objective. The question that should drive all your PCI pen testing is: Can someone get unauthorized access to the cardholder data on my system? Nothing else matters. This objective must be made clear to the testing company from the outset for two reasons. The fi rst is to ensure the security integrity of the card data environment (CDE) to meet the intent of PCI DSS, and the second is to be able to produce evidence that you did.
In the world of PCI compliance, if you
can’t produce evidence associated with implementing the control, then you can’t verify compliance. Hence, if the report from the pen test you’ve commissioned makes no mention of testing the systems for unauthorized access to cardholder data, then you have no actual proof that this was done. Never assume that the testing company understands your PCI objectives or burden of proof – spell it out for them. It will set the right tone for the engagement and result in a bigger return on your investment. Do not even consider conducting PCI- required pen testing without having your CDE documented. A current and comprehensive network diagram depicting all components, operating systems and applications in your CDE is essential in meeting your PCI testing requirements. The diagram should also show all third-party suppliers, virtual private networks (VPN) and remote connections, in addition to any wireless subnets to the CDE. Finally, make sure that your company’s card data security policies are included in the testing scope: specifi cally your ‘need to know’ principle, access control mechanisms, password policies and end-user acceptability
agreements. As you go through the two hundred and some odd PCI DSS controls, you should be asking yourself: ‘What else can I include in the testing scope?’ Your pen test report must detail the methodology that was used. Ensure the methodology corresponds to the DSS. Network testing should include port scanning, TCP fi ngerprinting and email routing, and web application testing should include OWASP issues: buffer overfl ow attempts, cross site scripting and SQL injections. If possible, have the testing company address each of the stated controls in the report. This will provide evidence that the network or application was in fact tested for a PCI-stated vulnerability. The assumption is that if you hire an external professional to conduct the tests, the tester will possess the appropriate qualifi cations. This is usually not a problem. The problem is once again a question of evidence. Can you prove that the resources you used to conduct the testing were qualifi ed to do so? You are required to provide this evidence. A good report addresses the results of testing all the network and procedural controls associated with the CDE and provides evidence that the controls are in place and correctly tested. It should provide one-stop shopping for your QSA or internal auditor to validate your compliance program. The more evidence your testing report can provide, the greater the value you’ll get for your compliance money. Worthless or priceless? The choice is yours.
AUTHOR PROFILE
Richard Hollis is the chief executive officer for Orthus Ltd., a European information security risk management consulting firm specializing in information risk management services.
January/February 2012
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56 |
Page 57 |
Page 58 |
Page 59 |
Page 60