Planning Guide for Penetration Testing John Pelley, CISSP, ISSAP, MBCI Long seen as a Payment Card Industry (PCI) best practice, penetration testing has become a requirement for PCI 3.1 effective July 1, 2015. This document is provided as a merchant benefit for beginning the PCI DSS 3.1 compliance process. Redhawk Network Security, LLC 62958 Layton Ave., Suite One, Bend, OR 97701 sales@redhawksecurity.com 866-605- 6328 www.redhawksecurity.com
Planning Guide for Penetration Testing, PCI DSS 3.1 What you need to know about a new requirement for PCI DSS 3.1 effective July 1, 2015. The Payment Card Industry (PCI) best practice for penetration testing has become a requirement for PCI 3.1 effective July 1, 2015. PCI DSS 3.0 is retired as of June 30, 2015. All merchants and service providers must have quarterly network scans and validate compliance annually with on-site audits by a Qualified Security Assessor such as Redhawk, or by completing a PCI Self-Assessment Questionnaire (SAQ). Merchants now affected include those that are using SAQ A-EP (external only) and SAQ D (internal and external) to validate compliance. Merchants have 14 months to comply with new guidelines. What is penetration testing? Businesses must conduct penetration testing that covers the entire payment-card-processing environment, as well as validate segmentation and scope-reduction controls. The standard also specifies what application-layer and network-layer tests should include. The requirement encourages businesses to check their segmentation more carefully and reduce the scope of the Cardholder Data Environment (CDE). How can Redhawk collaborate with affected businesses to implement compliance over the course of the next fiscal year? As a trusted security partner, using proven expertise and adaptability, Redhawk s top priority is to effectively tailor testing procedures to fit each merchant s ideal time frame and budget as closely as possible. This document is provided as a merchant benefit for beginning PCI DSS 3.1 compliance best practices. Penetration Testing Penetration testing is a manual process utilizing an extensive testing toolset. Precise vision of a certified professional is required in selecting the appropriate tools and in identifying attack vectors that typically cannot be identified through automated means. Penetration testing should also be performed with no restrictions on ports or services by the Internet provider. For example, a penetration tester utilizing Internet connectivity provided to consumers and residences may have SMTP, SNMP, SMB, and other ports restricted by the Internet provider to minimize impact by viruses and malware. If testing is performed by a qualified internal resource, the test should also be performed from a neutral Internet connection unaffected by access controls that might be present from the corporate or support environments.
Application Layer The penetration tester should perform testing from the access point of the defined roles of each application. The organization should supply credentials to allow the tester to assume the required roles. This will allow the tester to determine if, at any given role, the user could escalate privileges or otherwise gain access to data they are not explicitly allowed to access. When the organization has created new accounts for the tester to use, it is important that the organization ensure all roles and applicable security in the application have been set up to allow the tester to effectively test all functionality. In instances where a web application utilizes a backend API and the API is in scope, it is recommended that the API be tested independently of the web application. In order to have an understanding of the initial scope of testing, it is important to determine the number of payment card site locations, IP addresses, system hosts, servers, as well as web applications and any other systems that come into contact with the CDE. Web Application Penetration Testing: White Box and Black Box Web application penetration testing is performed in two stages: The first phase is performed as a Black Box test. This test is performed with limited information to determine vulnerability from real world external attack scenarios. The secondary White Box phase tests software and the internal structures and functions of each application. As a comprehensive approach, these deliberately evasive and invasive testing methods isolate vulnerabilities associated with web applications. The following methodology is used for analysis: Evasive methods are utilized to test security flaws from an external perspective, providing a real-world test of online applications and security controls. Testing proceeds until the organization detects and shuns an attack or a full analysis is completed. Perimeter security devices are reviewed for vulnerabilities using scanning tools in concert with architecture and configuration analysis. Tools used for testing are documented along with detailed results.
Black Box Penetration Test The Black Box phase of penetration testing subjects a system to real-world attacks by security analysts. The benefit of this penetration test is to identify the extent to which a system can be compromised before the attack is identified and assess the response mechanism s effectiveness. Specific attacks are performed based on the type of server and services. All findings will be documented in the final penetration testing report. Black box testing includes: Network Surveying Results include domain names analysis, a theoretical network topology and information regarding ISPs, system and service owners. Port Scanning Port scanning is used to identify which tcp and UDP ports on externally visible hosts are accepting connections from the Internet. System Identification Identification of target operating systems by analyzing tcp and udp packets to and from the testing host. Services Identification Utilizing the information obtained, attempt to identify network applications or what traffic is allowed to connect. Vulnerability Exploitation Analysis of vulnerabilities through attempts to exploit them. A vulnerability indicates areas that may be exploited and identifies threats that can compromise an asset. Security analysts would attempt to execute the attack after a review of the scan with the organization. Any exploits would require permission from the organization. Password Cracking If passwords are found from intelligence gathering, tools would be used to crack passwords and may be used further to exploit access to internal assets. White Box Penetration Test The White Box penetration test focuses specifically on privilege escalation. Trusted applications are deployed and attempts are made to obtain access or change privileges to assess the security of the organization s network. White box testing includes: Authenticated Access Use of authenticated credentials to test local privilege escalation and audit local security. Data Flow & Controls Review Review application data flow and controls between proxy, central and remote applications. Security Strategy Develop optimum security installation guidelines, central and remote applications. Authenticated Hacking Perform penetration and vulnerability assessment against central applications (from a trusted perspective). In all, the Web App Pen Test provides audit-friendly reporting and documentation of real-world online threats and the resulting internal and external PCI DSS compliance.
Network Layer Network-layer testing is suitable for automated testing, so automation is the first logical step in a network-layer test. Tools may be used to quickly identify a service, the version of the software, test for common misconfigurations, and identify vulnerabilities. Automated tests can be performed much faster than could be expected of a human. However, simply running an automated tool does not satisfy the penetration testing requirement. Automated tools cannot interpret vulnerabilities, misconfigurations, or even the services exposed to assess the true risk to the environment. The automated tool only serves as a baseline indication of the potential attack surface of the environment. The penetration tester must interpret the results of any automated tools and determine whether additional testing is needed. Using the documentation provided by the organization during the pre-engagement, the tester should: 1. Verify that only authorized services are exposed at the CDE perimeter. 2. Attempt to bypass authentication controls from all network segments where authorized users access the CDE, as well as segments not authorized to access the CDE. It is imperative to test the application and network layers beyond the limitations of an automated scan to determine vulnerabilities. Only a qualified professional working with management and/or IT staff can sufficiently address security threats and vulnerability concerns for each specific merchant CDE. Segmentation The segmentation check is performed by conducting tests used in the initial stages of a network penetration test (i.e., host discovery, port scanning, etc.). It should verify that all isolated LANs do not have access into the CDE. The penetration tester should verify that each network segment reported to be isolated from the CDE truly has no access to the CDE. For environments with a large number of network segments considered to be isolated from the CDE, a representative subset can be used for testing to reduce the number of segmentation checks that need to be performed. Testing of each unique segmentation methodology should be used to ensure that all security controls are functioning as intended. If it is determined during the segmentation check that the LAN segment has access into the CDE, either the organization needs to restrict that access or a full network-layer penetration test should be performed to characterize the access.
Data Breech Response Plan If cardholder data is accessed during the penetration test, it is important that the tester notify the organization immediately. The tester should keep detailed documentation as to exactly what data was accessed and how it was accessed. After being notified, the organization should immediately review how the cardholder data was retrieved and, as appropriate, should take steps to execute its incident response plan. Verify that such a plan is in place. If the output of testing tools or activities includes cardholder data that was accessed by the tester during the engagement, it is important this output be secured in accordance with PCI DSS compliance regulations. Post-Exploitation The term post-exploitation refers to the actions taken after the initial compromise of a system or device. It often describes the methodical approach of using privilege escalation or pivoting techniques which allows the tester, in this case, to establish a new source of attack from the new vantage point in the system to gain additional access to systems or network resources. Penetration testers should be able to demonstrate the risk presented by exploitable systems to the CDE and what post-exploitation may likely occur with those systems. Post-Engagement After testing has been performed, there are activities for remediation and retesting: 1. Remediation Best Practices - Penetration testing efforts, while thorough, may not always guarantee exhaustive identification of every instance where a security control s effectiveness is insufficient e.g., finding a cross site scripting vulnerability in one area of an application may not reveal all instances of this vulnerability in the application. Often the presence of vulnerability in one area may indicate weakness in process or development practices that could have replicated or enabled similar vulnerability in other locations. Therefore, it is important for the tested organization to carefully investigate systems or applications with the ineffective security controls in mind when remediating. 2. Retesting Identified Vulnerabilities - The organization should take steps to remediate any exploitable vulnerability within a reasonable period of time after the original test. When the organization has completed these steps, the tester should perform a retest to validate the newly implemented controls mitigate the original risk. Remediation efforts extending for a long period after the initial test may require a new testing engagement to be performed to ensure accurate results of the most current environment are reported. This determination may be made after a risk analysis of how much change has occurred since the original testing was completed. In specific conditions, the flagged security issue may represent a fundamental flaw in an environment or application. The scope of
a retest should consider whether any changes occurring as a result of remediation identified from the test are classified as significant. All changes should be retested; however, whether a complete system retest is necessary will be determined by the risk assessment of those changes. Summary of recommendations for compliance with penetration testing requirements: 1. Scope the organization environment to determine active CDE. 2. Perform annual penetration testing for internal and external systems based on information security best practices. Retest after changes in network or applications. 3. Test the application and network layers to determine vulnerabilities. 4. Retest vulnerabilities identified through penetration testing. 5. Reduce the scope of the CDE to eliminate unnecessary complexity and increase organizational resource efficiencies. Overall, although PCI DSS 3.1 is a requirement, partnering with Redhawk for penetration testing is an opportunity for greater agility, control, and performance of merchant PCI procedures and greater corresponding customer loyalty and trust. An independent third party specialist should perform penetration testing. In selecting a vendor the following are key questions to ask: 1. Ask the vendor to explain their pen testing methodology and how it differs from testing such as a vulnerability assessment. The vendor should be able to explain their methodology and be cautious of a vendor that claims the testing is automated or refers to scans as the process. 2. Ask the vendor to explain their specific methodology. Some steps are common for all testing, but there are differences from vendor to vendor in the tools and manual processes utilized. 3. Ask the vendor if their security team has top security industry certifications such as the CISSP or PCI QSA certifications. You want trained and experienced security analysts on the project. 4. Ask the vendor how they secure their processes and data to protect your information. Data should be encrypted in transit. There should be a secure collaboration process for information sharing such as encrypted email and secure online services. 5. Ask the vendor about how they assure system availability while testing. Penetration testers should work closely with the customer to assure that testing does not create downtime. Any vulnerability identified that may create downtime if exploited should be documented, but not tested without permission.