The Ins and Outs of Penetration Testing

Article Penetration Testing
Penetration Testing

 

Co-written with Chad Wheeler, Manager of RedLens InfoSec and Chris Wallace, Penetration Tester at RedLens InfoSec.

The Payment Card Industry Data Security Standard (PCI DSS) Requirement 11.3 requires organizations to perform both an internal and external penetration test of the cardholder data environment.

For those of us without an IT background, understanding exactly why this is required, what happens during a penetration test, the type of test your organization needs (wait…there are different types?), what is involved in preparing for a pen test, and what resources may be required for follow-up remediation efforts can be difficult.

What is a Penetration Test? We have quarterly scans scheduled, isn’t that the same thing?

Vulnerability scans and penetration tests are separate processes. Both are requirements of the PCI DSS and help secure your environment in different ways. The simplest way to explain the difference is that a vulnerability scan is only identifying and ranking potential vulnerabilities, while a penetration test is taking it a step further and attempting to exploit those identified vulnerabilities to gain access to secure systems or stored sensitive data. A vulnerability scan is often the first step in the penetration test process.

Vulnerability scans are automated. A penetration test involves a live (qualified) person manually probing your network and looking for holes that they can then continue to explore and uncover further weaknesses or potential for malicious activity. Because of the thorough effort involved, penetration tests are generally performed annually to examine network security, while scans are a less intrusive way to gain monthly or quarterly insight into known vulnerabilities.

The intent of a penetration test is to simulate a real-world attack situation with the goal of identifying if a hacker can break into your organization’s network, and if so, how far they would be able to penetrate your environment. This allows an organization to gain a better understanding of the potential gaps and develop a strategy to remediate any issues and defend against attacks. You would much rather these holes be uncovered by an ethical hacker than a cybercriminal with malicious intent. Taking this proactive step can help you avoid the cost of network downtime, meet PCI requirements, prevent fines, and protect your reputation.

Does your organization need a Penetration Test?

The PCI DSS requires penetration testing, so most organizations perform pen tests to comply with that requirement. However, penetration testing definitely isn’t for payment card information security only. Other information security standards like HIPAA and GLBA also have requirements for pen testing to identify if sensitive personal information is at risk. Penetration tests are also recommended as a way to validate your overall network security. Basically, if any part of your network is connected to the Internet, then the information your organization handles is within the reach of hackers. Similarly, your internal network may be susceptible to attack from compromised workstations, or insider threats.

Turning back to PCI, different levels of testing are required based on the different payment processes of your merchants. Certain merchants may not fall under the requirements for penetration testing based on way they are handling payments and the Self-Assessment Questionnaire (SAQ) they are attesting compliance with.

The chart below details the requirements for each of the SAQs.

Below are the updated requirements for vulnerability scanning and penetration testing by SAQ type under PCI DSS version 4.0.
SAQ Description Penetration Test Requirements Vulnerability Scanning Requirements

A

Card-not-present merchants (e-commerce or mail/telephone order) that have fully outsourced all cardholder data functions to PCI DSS compliant third-party service providers

None

ASV external scanning (quarterly)

A-EP

​Merchants accepting only e-commerce transactions that have partially outsourced the e-commerce payment channel to compliant third parties; merchant’s website does not receive account data, but controls how customers, or their account data, are re-directed to the third-party.

  • External penetration test (annual)
  • Segmentation test (annual)

ASV external scanning (quarterly)

B

Merchants using stand-alone, dial-out terminals

None

None

B-IP

Merchants using stand-alone PTS-approved payment terminals with an IP connection to the payment processor

Segmentation test (annual)

ASV external scanning (quarterly)

C

Merchants with payment application systems connected to the Internet, no electronic cardholder data storage

Segmentation test (annual)

  • ASV external scanning (quarterly)
  • Internal vulnerability scanning (quarterly)

C-VT

Merchants with web-based virtual payment terminals provided and hosted by a PCI DSS compliant third-party service provider

None

None

P2PE

All payment processing is via a validated PCI-listed P2PE solution

None

None

D

Merchants with electronic storage of cardholder data; all merchants not included in the descriptions for above SAQ types

  • External penetration test (annual)
  • Internal penetration test (annual)
  • Segmentation test (annual)
  • ASV external scanning (quarterly)
  • Internal vulnerability scanning (quarterly)

D-SP

All service providers defined by a payment brand as SAQ-eligible

  • External penetration test (annual)
  • Internal penetration test (annual)
  • Segmentation test (bi-annual)
  • ASV external scanning (quarterly)
  • Internal vulnerability scanning (quarterly)
  • Authenticated internal scanning (quarterly)

 

What is the different between an Internal vs. External Penetration Test?

An external penetration test is performed from the open public network outside of your organization. In an external penetration test, the tester uses the approach that they are just an anonymous attacker looking to breach your network and gain access to information.

An internal penetration test is when the tester probes from inside your organizational network, but outside of your cardholder data environment, or other critical network. An internal penetration test helps you determine the potential risks posed to your systems by insiders, like employees or contractors, or a hacker who was able to breach your network.

Can you explain the different types of Penetration Tests?

Depending on your environment, where sensitive information exists, and how your networks and applications are configured, you may need to have one or more of the below tests performed.

Network Penetration Tests are used to identify vulnerabilities and security issues with the design, implementation, and maintenance of servers, workstations, and network services. Penetration testers will try to expose issues with poorly coded software, misconfigured firewalls, or unpatched and outdated software and/or operating systems.

Application Tests are used to identify any security issues within software applications. For example any insecure development practices in the design, coding, or publishing of the application will be identified. These tests will expose if the application is vulnerable to injection attacks (SQL injection, cross-site scripting, remote code execution, etc.), if there are any broken authentication or authorization settings, or any improper error handling.

Segmentation Tests are used to analyze if hackers could gain access to a secure network (i.e. the CDE) from a less-secure network due to a misconfigured firewall. Basically, they are testing to confirm you have your CDE segmented properly and there are no security holes. Inadequate segmentation is actually what led to many of the highly publicized data breaches, including the breach at Target. Organizations are usually vigilant about testing for vulnerabilities within their secured networks, but fail to properly segment, and inadvertently allow hackers access through other less secure networks.

Wireless Tests are used to test for misconfigurations of the wireless network, insecure encryption standards, weak passwords, unsupported technologies, or the presence of any unauthorized/rogue wireless access points. Employees may install an access point without authorization from the network administrators, and hackers can then access the wireless network to carry out a man-in-the-middle attack. Whether it is with malicious or non-malicious intent, a rogue wireless access point can allow un-authorized access to your organizational network. A wireless penetration test can help you identify these access points and disable them accordingly.

Who performs a Penetration Test?

The PCI DSS requires that the penetration test is executed by a qualified resource and the tester should be organizationally independent. Common certifications of qualified personnel will include:

  • Offensive Security Certified Professional (OSCP)
  • Certified Ethical Hacker (CEH)
  • Global Information Assurance Certification (GIAC) Certifications (e.g., GIAC Certified Penetration Tester (GPEN), GIAC Web Application Penetration Tester (GWAPT), or GIAC
  • Exploit Researcher and Advanced Penetration Tester (GXPN)
  • CREST Penetration Testing Certifications
  • Communication Electronic Security Group (CESG)
  • IT Health Check Service (CHECK) certification

The quality of the penetration test and the value that can be obtained from it are based on the qualifications and level of experience of the penetration testing personnel. While some automated tools may be used during the test, the penetration tester is relying on his/her knowledge of the various systems involved. They will be manually evaluating vulnerabilities from many different vantage points, and their prior experience allows them to understand and foresee the shortcuts that development teams may have utilized.

Professional penetration testers, also called Ethical Hackers, use information gained from target profiling, research of services, and application analysis to identify vulnerabilities. They must be up to date on hacking methods, be trained on the types of technologies within the targeted environment (operating systems, hardware, web applications, network services, protocols, etc.) and follow correct pen testing methodology when conducting the test (e.g., NIST 800-115, OWASP Testing Guide, etc.).

What systems do we include in a penetration test?

A PCI penetration test must at a minimum, include all systems in the merchant cardholder data environment (CDE). The scope of an overarching information security pen test will go outside of the CDE and include any systems that could affect the security of the network. Critical systems to be considered can include (but are not limited to):

  • Firewalls
  • Authentication servers
  • Intrusion Detection systems
  • Active Directory Domain Controllers
  • Exchange servers
  • SharePoint and other file shares
  • End-user workstations
  • URLs of web applications (application testing)

How long does a penetration test take?

The length of time and resources needed to perform a penetration test will depend on the size and complexity of the environment. A smaller organization may be able to complete a pen test in just a couple of days, a larger environment can take several weeks. During the discovery phase, penetration testers will attempt to determine the “attack surface”. It is the size of this attack surface that will normally give a good idea as to how much time will be needed to complete the testing. For example, of 100 systems, if there are only 2 exposed services/ports, the time required to test is significantly less than if there are 10 exposed services/ports on each of those 100 systems.

Time can also depend on what is found during the testing and what weaknesses the tester is able to exploit. Often the penetration tester will chain several types of exploits together to break through various layers of defenses. For example, if they are able to access a key server, they will then use that breached server to stage a new attack based on the resources they now have access to.

How often must tests be performed?

The PCI DSS requires that you perform penetration tests on at least an annual basis. You also must perform tests anytime you make a 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).

What can we expect from a Penetration Test?

A good penetration tester will document everything they find. They will provide a detailed report with step-by-step explanations for precisely how they gained access to systems, what tools were used, the paths they took, etc., and their expert recommendations for how to patch any weaknesses. Any exploitable vulnerabilities found during the test will need to be corrected, and testing should then be repeated to verify the remediation efforts were effective.

Penetration Testing for Your Biggest Weakness – People

While the PCI DSS does not specifically require organizations to test if their people (employees, contractors, etc.) can be tricked and exploited, your cardholder data environment (CDE) is comprised of people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data. It is a good best practice to incorporate social engineering techniques into your ongoing penetration testing methodology. Testing your people throughout the year is an excellent method to determine the overall effectiveness of your security awareness program.

Some additional guidance from our Penetration Testing team below:

[Wheeler]: As we know, penetration testing is a very important part of overall security, and a required component of PCI compliance. Typically, when customers request a penetration test for PCI compliance, they request only their CDE (including critical/supporting systems) to be tested, which is the minimum requirement for req. 11.3. Sounds reasonable, right? However, examine the over-simplified network diagram below:

To be compliant with PCI 11.3 (in terms of scoping), a penetration test would need to test components inside of the shaded boxed labeled ‘CDE Scope’. Maybe this penetration test didn’t reveal any vulnerabilities, or maybe only some minor issues were discovered. However, imagine this: an attacker is able to compromise another system on your network that resides within a non-CDE network, is able to move laterally to the domain controller/DNS server, which can communicate with the CDE systems. Game over.

By expanding the scope of a penetration test, it may be possible to demonstrate compromise of these protected systems that may not have been able to be compromised otherwise. This is an example of compliance vs. security. The CDE may have been compliant, but the network wasn’t secure. Consider this when beginning your penetration test planning. It may require more time and resources to widen the scope of testing, but I personally guarantee it is less than the time and resources needed to deal with a major breach.

[Wallace]: Third party testing is the most effective way to understand how vulnerable your network is to a malicious attacker. Not only does it provide an independent review of your infrastructure, it also provides a way to assess the organization’s effectiveness in detecting and responding to an attack. When a penetration test is performed using in-house staff, it may actually leave the business blind to possible vulnerabilities due to increased familiarity with the network and comfort with the current state. A qualified, impartial penetration tester can provide the fresh perspective the business needs to improve your security posture.

Please contact us with any questions regarding your penetration testing requirements.

Share

About the Author
Katie Johnson

Katie Johnson

PCIP

Manager, Operations Support

As the manager of Operations Support, Katie leads the team responsible for supporting and delivering CampusGuard services including online training, vulnerability scanning, and the CampusGuard Central® portal. With over 15 years of experience in information security awareness training, Katie is also the Product Lead for CampusGuard’s online training services. As a Senior Customer Relationship Manager for a limited number of customers, Katie assists organizations with their information security and compliance programs and is responsible for coordinating the various teams involved.