Tuesday, November 10, 2015

Understanding PCI DSS Penetration Test Guidance v1.0

Author - Manasdeep
The Penetration Test Guidance v1.0 document was released on March 2015 to update and replace the long pending PCI DSS original penetration testing information supplement titled “PCI DSS Requirement 11.3 Penetration Testing” that was published in way back in 2008. It stands fully updated as per requirements of PCI DSS v3.0 standard. As always, it stands as a guidance document which does not supersede, extend or replace PCI DSS requirements.
  • All those entities that are required to conduct a penetration test using external or internal resource(s).
  • Serves as a roadmap for the companies that specialize in offering penetration test services.
  • Guides qualified security assessors' (QSAs) who help to scope penetration tests and review final test reports.
  • Applicable to all organizations undergoing PCI DSS compliance; irrespective of budget, size constraints.
The update feature major highlights as follows:
  • Penetration Testing Components
  • Qualifications for an Penetration Tester
  • Penetration Testing Methodologies and Reporting Guidelines
  • Gives terminology understanding for types of tester(s), various types of PT testing (such as black-box, white-box, and grey-box etc.)
  • Guidance on reference risk-ranking sources such as National Vulnerability Database(NVD) and Common Vulnerability Scoring System (CVSS)
The guide clearly puts forward the goals concerned with PT exercise as follows:
  • To determine whether and how a malicious user can gain unauthorized access to assets that affect the fundamental security of the system, files, logs and/or cardholder data.
  • To confirm that the applicable controls, such as scope, vulnerability management, methodology, and segmentation, required in PCI DSS are in place.
The guide also clarifies the difference between Vulnerability Scan and Penetration Test as follows:
Vulnerability Assessment
Penetration Test
Identify, rank, and report vulnerabilities that, if exploited, may result in an intentional or unintentional compromise of a system.
Identify ways to exploit vulnerabilities to circumvent or defeat the security features of system components.
Frequency is at least quarterly or after significant changes.
Frequency is at least annually and upon significant changes.
Typically involves automated tools combined with manual verification of identified issues.
A manual process that may include the use of vulnerability scanning or other automated tools, resulting in a comprehensive report.
Takes typically several seconds to several minutes per scanned host.
Engagements may last days or weeks depending on the scope and size of the environment to be tested.
A. Scoping for Penetration Test
A much needed guidance on scoping was needed which is now provided in this document. Following points must be kept in mind for scoping as follows:
1)   The scope of an external penetration test is
Exposed external perimeter of the CDE and Critical systems connected or accessible to public network infrastructures.
2) Testing must include both application-layer and also network-layer assessments. External penetration tests can also include remote access vectors such as dial-up and VPN connections. Same concept is to be followed in case of internal Penetration test.
3) Segmentation checks should be performed from any non-CDE environment that is intended to be completely segmented from the CDE perimeter. Isolation should be such that even if the out-of-scope system component was compromised it could not impact the security.
4) The penetration tester may be allowed to:
  • Continue exploring inside the network
  • Expand his attack against other systems within the CDE
  • This can include data-loss prevention controls that are in place
B. Clarity on Critical Systems:
Security systems relevant w.r.t penetration test should be included such as:
  • Firewalls,
  • IDS/IPS,
  • Authentication servers,
  • e-commerce redirection servers including assets utilized by privileged users which may involve supporting and managing the CDE
C. Application-Layer and Network-Layer Testing
Software written by or specifically for the organization which is part of the penetration test scope should be included in both an application and network-layer penetration testing. For those applications which require user authentication to the custom software, it is important that testing should be performed against all roles or types of access.
Testing for PA-DSS Compliant Applications
PA-DSS validated applications do not need to be tested. However, the implementation of the application does need to be tested.
D. Testing for Web Application
Web application that was not specifically coded for the organization such as commercial, off-the-shelf etc, does not typically need an application-layer penetration test since entity is not responsible for the source code of this type of software. However, tester should perform a network-layer test to ensure software was implemented, configured, and being securely maintained.
E. What is considered a “significant change”?
Whenever a change could impact the security of the network or allow access to cardholder data, it can be considered significant by the entity. Penetration testing is done then to ensure that controls applied are still working effectively after application of the upgrade / modification.
F. Qualifications of a Penetration Tester
Mandatory requirement for penetration tester are:
  • He / She must be organizationally separate from the management of the target systems.
  • A third-party company performing the PCI DSS assessment for the entity cannot perform the penetration test if involved in the installation, maintenance, or support of the target systems.
Skill level of penetration tester may be gauged from industry accepted certifications such as OSCP, CEH, GIAC, knowledge of OSSEC etc. Following questions need to be addressed for careful consideration of determining penetration tester has is adequately trained to perform the penetration test.
  • For how many years has the penetration tester’s organization been performing penetration tests?
  • Did the penetration tester performed assessments against organizations of similar size and scope?
G.  Steps to take when cardholder data is identified during penetration testing
Following steps must be taken whenever card holder data (CHD) is encountered during penetration testing:
1)    The tester must immediately inform the organization the presence of CHD
2) Necessary information must be documented as a substantial evidence to establish the presence of cardholder data in the tested environment.
3) Tester must disclose the facts on how CHD was accessed and what was retrieved.
Once the organization is notified for the same, it should carry out the following follow-up activities:
1) Do an root cause analysis on how the cardholder data was retrieved
2) Raise an incident flag and carry out the activities as per the documented incident response plan.
Finally, any output from testing tools which has presence of CHD accessed by pen tester, it needs to be properly secured as per PCI DSS.
H. Expectation of client from the Penetration Testing done as per PCI DSS
As per PCI DSS, the intent of carrying out a penetration test is to simulate a real-world attack and identifying the extent on how far an adversary can successfully penetrate into the scoped environment. Therefore, it is important to define some basic success criteria which can set limits on the depth of the penetration test being carried out.
In absence of written agreed upon points on depth of penetration testing, the pentester can possibly exceed the boundaries and expectations of the target entity. Therefore, formal rules of engagements should be well written in advance between two parties, before any penetration testing takes place.
Success criteria of a penetration test can include:
  • Direct observation of restricted services or data in the absence of expected access controls
  • Compromise of an intermediary device used by privileged users to access the CDE
  • Compromise of the domain used by privileged users
  • No compromise of the target systems
Note that above criteria will differ in every environment, hence it is always useful to establish the context prior to penetration testing during pre-engagement meeting itself.
I. Conclusion
The guidance document on Penetration Testing is a welcome addition to the PCI DSS official documents as it provides the much desired clarity on best practices on Penetration Testing Process to be followed as per the PCI DSS requirements. In addition to that, assessors now have a ready reference to look into to cover the basic things that are essential to cover in Penetration Testing exercises. Finally, it serves as a common reference point for all the parties involved in the PCI DSS assessment exercise. The current guide is also fully updated as per PCI DSS v3.0 and hence able to better serve the assessor needs directly.
About the Author
Manasdeep currently serves as a Security Consultant - Quality at SISA Information Security Pvt. Ltd. Bangalore. His work focuses on conducting quality checks on deliverables and conducting onsite PCI DSS Audit assessments, Risk Assessments and Security Audits.  He possesses strong analytical skills and likes to keep himself involved in learning new upcoming attack vectors, tools and technologies. The views presented here by the author are personal.

No comments:

Post a Comment