PCI Requirement 11.3.2 – Penetration Testing

Tod raised a question in response to the PCI 6.6 Information Supplement Released post, a question heard by many QSAs (and several other email responses to that post.) These concerns were echoed by Rory on his blog.

First, we need to be current with the ‘Information Supplement: Requirement 11.3 Penetration Testing‘ on the PCI SSC’s website. I will also be paraphrasing Michael Dahn’s post over at pcianswers.com, and related posts in that forum. I will compare/contrast the implications of application testing in 6.6 and penetration testing in 11.3(.2) tomorrow.

Requirement 11 is titled, “Regularly test security systems and processes,” while Requirement 11.3 states, “Peform penetration testing at least once a year, and after any significant infrastructure or application upgrade or modification…”

From the supplement, “The scope of penetration testing is the cardholder data environment and all systems and networks connected to it. If network segmentation is in place such that the cardholder data environment is isolated from other systems, and such segmentation has been verified as part of the PCI DSS assessment, the scope of the penetration test can be limited to the cardholder data environment.

Comprehensive penetration testing is intended to efficiently uncover flaws, mistakes, deviation and weakness in “secured” environments and processes. Testing should not be limited to applications and systems involved, but anything that would serve a ‘jumping off point’ (jargon- a base of operations for an attack) on the network segment where sensitive data resides. Any system, platform, or process be it technical or human driven; that is in any way involved with the data set in question (cardholder data) should be probed for weakness, and that weakness should be explored in the penetration testing exercise.

PLEASE- do not get distracted by correcting exploited vulnerabilities, focus on flawed processes or procedures that created… find the root cause.

Ever heard of ‘vulnerability whack-a-mole’? Vulnerability and Penetration testing exercises often incite the reflexive corporate ‘to-do’ response correcting the problem identified. The whole point of the exercise isn’t to find a single deficiency, but to find flaws in the process. (I’m going to skip the anecdotal reference to an ISO 9001 audit… precision in process is NOT doing what you say you will do, but doing it absolutely every time- thus a mistake in design delivers a mistake in production with 100% efficiency!!)

A flaw in any process design will systematically allow weakness, this is how security testers find vulnerabilities with a high degree of consistency. This is also how our operations team continually finds vulnerabilities in code already corrected- corrections did not get checked back into the source code tracking system.

An attacker’s apology…

Defending an information asset is very difficult, while attacking is very easy. Defenders must protect every thing absolutely, and attackers only need to find one mistake or vulnerability. This is what true penetration testing is all about.

Please understand that my job in InfoSec has always been easy. I have spent my short life studying organizations tasked with the protection of information assets. These companies teach good auditors what mistakes are often made, and how to exploit them for maximum leverage. My job was EASY in comparison of these security professionals. *IF* I was tasked with the thankless job of defending a network, I would use the annual penetration testing requirement like an annual physical, and any time something significant might need the attention of a dedicated expert.

What is a significant infrastructure or or application upgrade?
You penetration testing investment should be for truly noteworthy changes. Altering network or DMZ topology. Changing operating systems, application or database platforms, security and network device replacement, etc. Even changes to admissions or visitor registration, a new facility or perhaps opening a new data center only begs for exploration by a social engineer!

For many environments, the majority of changes would be insignificant (including most minor code updates), and security concerns should be detected through operational security due-care exercises described in PCI Requirements 2.2, 6.1, 6.3, 6.6, and others.

What exactly does penetration testing call for?

The guidance speaks to attack vectors or techniques, “Consider including all of these penetration-testing techniques (as well as others) in the methodology, such as social engineering and the exploitation of exposed vulnerabilities, access controls on key systems and files, web-facing applications, custom applications, and wireless connections.

This is what information security practitioners dream about. PCI has clearly stated that a penetration test must reach beyond the technology, and encompass business practices, physical security, and social engineering! One of peers always stated in executive reports, “if you think you can solve the security problem with technology, you clearly do not understand the problem.”

Penetration Testing goes far beyond actions required in PCI Requirement 11.2 for vulnerability scanning at the network layer (ASV or Approved Scanning Vendor services) or Requirement 6.6 for the detection and correction of vulnerabilities in custom application code- this is about exploring how deep different vulnerabilities can allow attacks to travel. This is active exploitation- not passive vulnerability detection or verification they exist.

Don’t neglect Social Engineering

The effectiveness of security controls, technology, and business processes are dwarfed by the creative genius of those humans trusted with sensitive information. You’ve seen the Think Geek t-shirt, “there is no patch for human stupidity.” I won’t admit to owning one..

Here is a very short exercise for those new to the science of social engineering:

  • Does development sanitize (remove) sensitive data (credit card numbers) from the databases they use?
    What are the odds of the help desk team walking off with a computer… or maybe out of the building?
  • Does your new-hire process carefully identify employees before issuing user credentials?
    Ever tried sneaking in with a batch of new hires?
  • Do remote offices carefully validate the identity and work orders for support personnel?
    Do remote offices disdain visits from technical support? c’mon….
  • Does the help desk carefully authenticate callers needing help for password resets?
    I hate to reference the classic Mitnick, but, well, errr- it’s classic and it still works!

Special situations require special responses. All processes have a shortcut, there is always someone with the ability skip a step or make a judgment call. Have you ever ‘donated’ your wallet while traveling? If someone else has your government issued ID, how do you get past a security checkpoint without missing your flight? Given the right circumstances, anything is possible, any obstacle can be overcome.


One Response to “PCI Requirement 11.3.2 – Penetration Testing”

  1. didier rutmann Says:

    Attackers are well-aware of the valuable information accessible through Web applications, and
    their attempts to get at it are often unwittingly assisted by several important factors.
    Conscientious organizations carefully protect their perimeters with intrusion detection systems
    and firewalls, but these firewalls must keep ports 80 and 443 (SSL) open to conduct online
    business. These ports represent open doors to attackers, who have figured out thousands of
    ways to penetrate Web applications.
    The standard security measures for protecting network traffic, network firewalls and Intrusion
    Prevention Systems (IPS) and Intrusion Detection Systems (IDS), do not offer a solution to
    application level threats. Network firewalls are designed to secure the internal network
    perimeter, leaving organizations vulnerable to various application attacks.
    Intrusion Prevention and Detection Systems (IDS/IPS) do not provide thorough analysis of
    packet contents. Applications without an added layer of protection increase the risk of harmful
    attacks and extreme vulnerabilities.

    Web Application Level Attacks is the Achilles heel. In the past, security breaches occurred at the
    network level of the corporate systems. Today, hackers are manipulating web applications
    inside the corporate firewall. This entry enables them to access sensitive corporate and
    customer data. An experienced hacker can break into most commercial websites with even the
    smallest hole in a company’s website application code. These sophisticated attacks have
    become increasingly threatening to organizations.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: