PCI DSS Penetration Test

PCI DSS Penetration Test

Introduction

When handling credit card details, the Payment Card Industry requires organizations to adhere to certain standards, which includes performing a Penetration Test. This has the benefit of testing the environment from an attacker’s perspective and therefore identifying real security flaws rather than theoretical security issues. If your company handles credit card details, then you need to make sure that the cardholder data environment (CDE) is sufficiently secure against attack from malicious parties that may target this applications and networks.

What do we cover?

Our PCI Penetration Test covers PCI DSS requirement 11.3 as described in the information supplements of 2008 and that of 2015.

Therefore this focuses on application-layer and network-layer assessments, where:

  • Externally, the scope includes external perimeter of the CDE, critical systems and applications connected or accessible to public network infrastructures
  • Any access to these networks or systems is also included in the scope; therefore, this may include VPN and other remote access methods.
  • Internally, the scope involves targeting the CDE and critical systems from any out-of-scope LAN segment; such tests are referred to as segmentation checks
  • Custom-developed applications should be tested with credentials and different user permissions
  • Social engineering may be included as part of the tests to be performed

Rather than simply satisfy the PCI requirements by covering the bare minimum, we try to perform realistic attacks and provide a valuable service to our customers. The goal for this penetration test is to identify and demonstrate ways that can allow a determined attacker to leak or manipulate cardholder data.

Examples of security issues found during PCI DSS penetration tests include:

  • Security holes in the network segmentation, allowing users from guest networks (such as WiFi) limited access to the CDE
  • Buffer overflow, heap overflow and other memory corruption issues on trusted systems outside the CDE, that have access to the CDE; such systems are referred to as critical systems
  • Ways to bypass or sometimes abuse security solutions such as Web Application Firewalls
  • Application-layer access control vulnerabilities, allowing authenticated malicious users to access victim cardholder details
  • Debug log files with card data available in hidden but guessable locations on the web server

Which methodology is used?

How does the process look like?

Most of our engagements follow these steps:

  1. First step is that you contact us
  2. We ask you a number of questions to understand what you have in mind, the goals for the exercise and the scope
  3. We perform a scoping exercise to better understand the size of the project; in the case of an external penetration test, the scoping exercise often involves port scanning to better understand the exposure and therefore tailor our proposed work to your needs
  4. We verify with you our scope where appropriate
  5. We work on a proposal which describes the goals, the scope, the methodology, deliverables, dates allocated for the project, terms and conditions and the price
  6. The actual work takes place during the allocated dates; your IT staff involved in the project often need to be available during the tests
  7. Upon completing the tests, we work on the reports and often provide a brief report of the main findings so that your staff are informed of the results immediately
  8. The deliverables are provided to you
  9. Often the process also includes testing of the security fixes once applied

What are the deliverables?

At the end of the project, the client usually receives the following:

  • Executive report, which is an easy to follow 4 page report that includes information about the penetration test, list of the findings and a short explanation of the security fixes or mitigation techniques
  • Technical report, which includes the following sections:
    • Introduction, which describes the scope, methodology and purpose of the work
    • Methodology, which describes our tests to explain what was covered and how; this would include both tests that led to vulnerability discoveries, and also those that did not
    • Findings and recommendations which are categorised as High security threats, Other security threats and Other concerns and recommendations
    • Each finding that is considered a security threat includes:
      • a description of the security issue as it affects the target system
      • our assessment of the impact of the vulnerability
      • details on how to reproduce the issue found
      • solutions and recommendations, which are tailored for the target audience and can go into quite some detail
  • Other material is sometimes provided such as:
    • video demonstrations showing exploitation of your systems
    • dedicated exploit code to reproduce the security issues found
  • When the tests are done on-site, we often brief the involved executives and/or technical team and discuss solutions to the security issues found
  • Similarly, conference calls can be used when the work is done remotely

What costs can one expect?

Cost is dependent on the size and complexity of the system on test and the level of rigor in which testing is to be performed. This is determined through pre-sale client discussions and scoping questionnaires. The price of an engagement will be delivered as a fixed bid quote.

Get in touch