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.
Note: After the publication of this story, we added a more comprehensive look at the PCI DSS Penetration Testing Requirements to the site.
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 on 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 on 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.
November 4th, 2011 on 1:33 am
India has called for global coordination to ensure that internet continues to thrive without the fear of its misuse at the London Internatinal Cyber Conference that give the nature of the task and the fact that IT networks can be attacked from anywhere in the world.
November 18th, 2011 on 2:06 pm
Your definition of the scope is incorrect.
The scope of penetration testing is the Cardholder Data Environment (CDE) and all systems and networks connected to it. The PCI Security Standards Council defines the CDE as “The people, processes and technology that store, process or transmit cardholder data or sensitive authentication data, including any connected system components.”
As recommended by the PCI Security Standards Council’s Information Supplement: Requirement 11.3 Penetration Testing dated April 2008, testing should include locations of cardholder data, key applications that store, process, or transmit cardholder data, key network connections, key access points and other targets appropriate for the complexity and size of the organization.
Testing should not be performed inside the CDE.