PCI DSS 11.3: Pentest Methodology

As commented in the previous post, one of the new requirements of the PCI DSS v3 is to have a procedure that describes the methodology to be followed in conducting the  internal and external pen-test. I have developed a sample procedure that can be easily adapted to the specific casuistry of your Organization in order to meet the requirement 11.3 of the standard.

I hope you find it useful, and any comments or ideas for improvement are welcomed.
 

1. Introduction

 1.1 . Objectives

The purpose of this document is to establish a methodology for planning , implementation and review of the penetration testing to be performed annually in the Organization. This methodology, based on NIST SP 800-115 standard will follow a consistent and repeatable process in each of these tests , ensuring the quality and reliability of these.The responsibility for carrying out these intrusion tests annually is of XXXX department. The tests can be executed both by internal staff as always outsiders and when executed by specialists in testing intrusion that have the experience and knowledge .Finally , it should be noted that the purpose of the tests to be performed will identify vulnerabilities that could be exploited by an attacker to compromise the security of the systems of the Organization thereby compromising the confidentiality, integrity or availability of information stored, processed or transmitted by these.Note that this method includes all the minimum requirements set by the requirement 11.3 of the PCI DSS standard .

 1.2 . Scope

The scope of the penetration test includes the following elements :

• External intrusion test, i.e. analysing the vulnerabilities that could be exploited by an attacker is located in the Internet:

• Black box tests: with no users or prior information.

• Grey box tests: not users, but having the details of the applications and the infrastructure of the organization perimeter .

• White box test: With users to access systems, application or authenticated areas that want to be tested.

• Internal intrusion, i.e. analyzing the vulnerabilities that could be exploited by an attacker with access to the internal network of the organization:

• Black box tests:with no users or prior information.

• Gray box tests: not users, but having the network diagram of the organization. Additionally, if there are several network segments used by users with different levels of privileges (eg, normal users and admin users ) are allowed to perform audit tests from various network segments.

• White box tests: tests with domain users, system users or application users. The method to follow is to asign same profiles and access privileges to auditors who are assigned to the users you want to check the level of system security. For example , if we want to see is what a provider can leverage vulnerabilities to compromise the security of our organization, should be assigned to audit users with the same profile and privileges assigned to that provider.

• Exploitability tests. For vulnerabilities identified in internal and external pentest these tests should check if you really are exploitable considering that the following conditions are met:

• It was determined that the risk of executing the exploit is acceptable . Keep in mind that running an exploit always carries some risk of causing a denial of service or instability on the target system or application.

• There is a publicly available exploit for the vulnerability.

• Can be generated as an exploit at a time and with reasonable effort into the planning of the tests performed.

• Documentation of the tests performed, the findings, their evidence, the conclusions reached and the recommendations made to address the vulnerabilities identified during testing.

• Re-test and capture evidence after the resolution of each of the vulnerabilities reported during testing.

 1.3 . Assumptions and limitations

This section should be identified (if any) the assumptions or limitations applicable, both the organization and the team that performed the tests.
 

 1.4 . Risks

In this section should be listed the risks inherent in conducting penetration testing over the information systems of our organization. Additionally, it should be noted for each mitigation measures that will be taken. Examples might be:

Example 1#

• Risk: Denial of Service in systems or network devices because the network scans.

• Mitigation measure 1: network scans must be performed in a controlled manner. The start and end of the scan must be notify to responsible personnel to allow monitoring during testing. For any sign of trouble will abort the scan in progress.

• Mitigation measure 2: scanning tools must be configured to guarantee that the volume of sent packets or sessions established per minute does not cause a problem for network elements. In this sense, we must perform the first scans in a very controlled way and use minimum configurations that may be expanded when is evident that the configuration is not dangerous for network devices or servers in the organization.

Example 2#

• Risk: During testing, if auditors are successful in testing may have access to confidential information of the organization.

• Mitigation Measure 1: Both the provider as organization and the individual professionals involved in testing must sign confidentiality agreements in which the responsibilities assumed in case of breach are stated.

• Mitigation Measure 2: Documents and evidence generated by the audit team will have the classification of confidential information and should only be accessed by authorized staff based on the principle of need to know.

• Mitigation Measure 3: The audit team will apply all necessary measures to ensure that the confidentiality of information organization can't be compromised because of the tests performed. These measures include encryption of reports and evidence and masking of any sensitive data that is included in the reports or evidence generated .

2 Logistics

 2.1. Staff

Key staff involved in the project by the organization will be listed :

• Technical Project Manager: XXXXX
• Chief Information Security Officer: XXXXXX
• Chief Information Officer: XXXXX
• Head of Communications: XXXXX
• Responsible for web site YYYY.com: XXXXX

Telephones and emails to contact all personnel involved in the tests (both, supplier and Organization) are listed in the Annex I "contact sheets" of this document.

Is particularly important to correctly identify the  people to contact in case of major incident, both by the supplier and by the Organization.

 2.2 . Calendar

Penetration testing must include a schedule detailing where the main tasks and milestones to be achieved during testing. In this sense, they should be planned at least the following dates:

• Pre-project activities
• Meeting of Project Start
• Start and end of external tests
• Start and end of internal testing
• Project monitoring meetings
• Delivery reports
• Presentation of results
• Meeting project completion

 2.3 . Location of evidence

External intrusion tests will be performed remotely from the supplier's premises .Internal intrusion tests will be conducted in the office XXXX of the Organization. Audit team must to have access to the Organization's network.It must manage access permissions to the building early enough to ensure that the audit team can access without problems during planning period .

 2.4 . Equipment for performing the tests

All the tests will be conducted from the equipment owned by the audit team so no equipment for the execution of the tests is required.The only requirement in this regard will be to have an active network connection for each member of the audit team. Those connections must provide access to the target network segment in every case.

3 Communication strategy

 3.1 . General communication

The following meetings between the audit team and the organization will be conducted during the course of the project :

• Previous meeting

• Channel : Telephone
• Required Attendees : XXXXXX
• Optional Attendees: XXXXXX

• Kick-off Meeting

• Channel : Face to face meeting in the office of the Organization YYYYY.
• Required Attendees : XXXXXX
• Optional Attendees: XXXXXX

• Meeting Follow-up 1

• Channel : Telephone
• Required Attendees : XXXXXX
• Optional Attendees: XXXXXX

•  Meeting Update 2

• Channel : Telephone
• Required Attendees : XXXXXX
• Optional Attendees: XXXXXX

• Meeting presentation of results

• Channel : Face to face meeting in the office of the Organization YYYYY.
• Required Attendees : XXXXXX
• Optional Attendees: XXXXXX

• Closing meeting

• Channel : Face to face meeting in the office of the Organization YYYYY.
• Required Attendees : XXXXXX
• Optional Attendees: XXXXXX

 3.2 . Incident Response and Management

If an incident occurs during the execution of the tests that have an impact on the systems or services of the organization, the incident should be brought immediately to the attention of those responsible for incident management in the project. Contact phones are detailed in Annex II "Contacts Incident". This annex also includes scaling procedures to resolve the incident.

The provider will follow the instructions of the incident management team of the organization to contain and solve any impact caused by penetration testing.

Having identified an incident, penetration testing must be stopped immediately and will not be resumed until receiving authorization from the technical manager of the project.

4 . Target systems and networks

It should be noted that in order to complies with PCI DSS the scope of the test should include, at least the following :

All systems and applications that are part of the perimeter of the cardholder data environment card (CDE ).

 4.1 . Systems included in the scope

• System 1: IP: System: System Description
• System 2: IP: System: System Description
• Wifi network XXXXYYYYY
• ................

 4.2 . Applications included in the scope

• Application 1: URL: Description of the application 
• ...................

 4.3 . Systems excluded from the scope

• System 5: IP: System: System Description
• System 6: IP: System: System Description
• ....................

 4.4 . Applications excluded from the scope

• Application 3: URL: Description of the application
• .....................

  

5. Executing the tests

 5.1 . No technical evidence

Non- technical tests to be performed during penetration testing are detailed in this section. Note that some of these tests can be combined with technical tests to increase their effectiveness:

• Attempted access to the facilities of the organization without identification , posing as employees of the Organization.

• Review of bins or containers for sensitive information of the organization.

• Attempt to obtain confidential information using social engineering techniques, both onsite and telephone .

(Note that these tests are an example. Each organization can add or remove evidence of this type according to your circumstances and objectives) .

 5.2 . technical tests

Technical tests must be follow the OSSTMM methodology. Tests must be conducted at network, system and application level and must ensure that at least identifies any vulnerabilities documented by OWASP and SANS ,as well as those identified in the PCI DSS standard v3:

• Inejections: Code, SQL, OS commands, LDAP , XPath , etc.
• Buffer overflows .
• Insecure storage of cryptographic keys
• insecure Communications
• Improper error handling
• Cross -site scripting (XSS )
• Control of inappropriate access.
• Cross - site request forgery (CSRF ) .
• Broken authentication and incorrectly session management.
• Any other vulnerability considered High Risk by the organization.

Additionally, we must carry out tests to validate the effectiveness of the controls established to segment the data environment cardholders (CDE ) from other systems and networks of the Organization.

  

6. Information Management

Note that all information generated as part of the audits will be owned by the organization and will have the classification of Confidential. Therefore, it must be stored and transmitted ever in encrypted way.

Reports and evidence generated should only be accessed by authorized personnel based in the need to know principle. 
 
Information concerning the audit will be stored only for a term of X years, being securely deleted and unrecoverable after that period.

The supplier undertakes to store the information on audit only for a period of X months, thus committing itself to eliminate it safely and unrecoverable after that period.

 6.1 . evidence

For all findings or vulnerabilities identified during the tests carried out will be generated and documented sufficient evidence to prove the existence of the same. The format of the evidence can be variable in each case, screen capture, raw output of security tools, photographs, paper documents , etc.

 6.2 . deliverables

As a result of tests performed should generate a document containing at least the following sections:

1. Introduction
2. Executive Summary
3. Methodology
4. Identified vulnerabilities
5. Recommendations for correcting vulnerabilities
6. Conclusions
   Annex I: Evidence