PCI DSS 11.3: Penetration Testing Requirements Clarified
There’s a lot of talk about section 11.3 of the Payment Card Industry Data Security Standard (PCI DSS), requiring organizations to conduct penetration tests. The language in this section of the standard reads:
11.3 Perform penetration testing at least once a year and after any significant infrastructure or
application upgrade or modification (such as an operating system upgrade, a sub-network added
to the environment, or a web server added to the environment). These penetration tests must
include the following:
11.3.1 Network-layer penetration tests
11.3.2 Application-layer penetration tests
When the standard first came out, the vagueness of this requirement caused quite a bit of confusion among compliance professionals attempting to understand how they’ll be held accountable by their merchant banks.
Hearing this confusion from the industry, the PCI Council recently released an information supplement providing additional information on the penetration testing requirement. This supplement clarifies requirement 11.3 in a number of important areas.
Technical Requirements
PCI DSS Requirement 11.3 requires that organizations perform annual penetration tests that:
- Evaluate both the network and application layers
- Include both internal and external testing
What’s Included in the penetration test’s scope?
The scope of PCI-required penetration tests includes all systems and networks within the cardholder data environment. This is where network segmentation is key. If you’ve followed the advice of PCI DSS experts and narrowly defined the scope of your cardholder data environment, you’re going to be in good shape when it comes time to perform your penetration test.
Who can perform the penetration test?
Contrary to popular belief, you do not need to use a Qualified Security Assessor (QSA) or Approved Scanning Vendor (ASV) to perform your penetration tests. In fact, you don’t even need to hire someone to perform the tests — it’s perfectly acceptable to use internal resources. The key is that you must use experienced penetration testers (i.e. someone who has performed penetration tests professionally in the past). Furthermore, they must be organizationally separate from those individuals managing the cardholder environment.
What’s the bottom line here? If your information security staff is actively invovled in the management of the cardholder network (e.g. managing the firewall, intrusion detection system, or participating in the design of the architecture), they’re disqualified from performing the penetration tests. If your organization has an internal audit staff that is qualified and willing to take on the assignment, they’re a great place to turn, as they naturally have the required independence.
How often should penetration tests be performed?
PCI DSS requires that you perform penetration tests on at least an annual basis. You also must perform tests anytime you make a “significant” change to the environment. The definition of “significant” is left up to the discretion of the individual interpreting the standard. For example, it’s a safe bet that adding a user account is not a “significant” change, while adding a new web server would clearly merit penetration testing. This is still one of the grey areas of PCI DSS and it’s always safe to err on the side of performing additional tests.
Good luck with your penetration tests!
August 6th, 2008 at 2:26 pm
What are your thoughts on situations where Operational Security and other areas of Information Security have separate reporting lines - i.e. they may have separate line management but report into the same CSO or head of security? Would it still be feasible to have non-ops infosec conducting penetration testing in your opinion?
May 18th, 2009 at 12:45 pm
Regarding the external pen test - the pen tester will evaluate the Scope from the Internet or through any Public Connection …
What about the Internal Pen Testing - Will it be evaluated from the DMZ towards the Scope ( Live Production ) ? or internally from the Scope Directly ?
My Concern is Evaluating it from inside is ignoring the Firewalls and the Access-lists around the scope - and also it will give a lot of false positives which are already protected using the boundary security products.