Deep dive on PCI DSS 4.0 API Security Requirements

The Payment Card Industry Data Security Council created PCI DSS as the global standard for protecting payment data. The PCI DSS is the compliance stick to which entities that transmit, store, handle, or accept credit card data of any size must adhere. Recently, PCI DSS came up with version 4.0. In this blog, we delve deeper into the new version and explain why securing APIs is critical for PCI DSS compliance and how organizations can do so. Most relevant controls are called out in requirement 6 – Develop and Maintain Secure Systems and Software. Let’s take a look.

Control 6.2: Bespoke and custom software are developed securely.

Section 6.2 is focused on developing secure software, or, as we all know, ShiftLeft aspects of security. The council desires organizations to reduce vulnerabilities in their software and systems so they are less likely to be compromised. Organizations’ Secure Software Development Lifecycle (SDLC) programs should catch these vulnerabilities early in the development cycle and prevent them from ever being released into production.

6.2.3 Bespoke and custom software is reviewed prior to being released into production or to customers, to identify and correct potential coding vulnerabilities, as follows:

  • Code reviews ensure code is developed according to secure coding guidelines.
  • Code reviews look for both existing and emerging software vulnerabilities.
  • Appropriate corrections are implemented prior to release.
As seen above, organizations must perform code reviews, including their APIs, before moving them to production. They should also validate the accuracy and compliance of API documentation or the OpenAPI schema/Swagger files.
Doing it manually is highly complex and error prone. Also, as existing APIs change and new APIs are deployed, manual effort won’t be helpful temporarily. AppSentinels can continuously track and report discrepancies between the Swagger files and how the actual API looks on the network.

6.2.4 Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software, including but not limited to the following:

  • Injection attacks, including SQL, LDAP, XPath, or other command, parameter, object, fault, or injection-type flaws.
  • Attacks on data and data structures, including attempts to manipulate buffers, pointers, input data, or shared data.
  • Attacks on cryptography usage, including attempts to exploit weak, insecure, or inappropriate cryptographic implementations, algorathims, cipher suites, or modes of operation.
  • Attacks on business logic, including attempts to abuse or bypass application features and functionalities through the manipulation of APIs, communication protocols and channels, client-side functionality, or other system/application functions and resources. This includes cross-site scripting (XSS) and cross-site request forgery (CSRF).
  • Attacks on access control mechanisms, including attempts to bypass or abuse identification, authentication, or authorization mechanisms, or attempts to exploit weaknesses in the implementation of such mechanisms.
  • Attacks via any “high-risk” vulnerabilities identified in the vulnerability identification process, as defined in Requirement 6.3.1

In 6.2.4, the first control, PCI DSS, requires software engineers and security teams to mitigate and prevent “common software attacks and related vulnerabilities.”  PCI DSS requires organizations to ensure applications are projected against standard attack methods like injection attacks, XSS, CSRF, etc.

The fourth control concerns business logic attacks. This new control was introduced and wasn’t part of the previous versions. This attack technique involves precise control for APIs. Given the prevalence of business logic attacks involving APIs, the PCI Council felt it was prudent to include it in the new standard.  

Business logic flaws can be introduced as APIs are initially deployed or updated. Implementing a continuous automated solution to uncover these flaws in the API’s lifecycle will be key to meeting the new PCI DSS requirements. 

The fifth control calls for protection against access-control attacks, including attempts to bypass or abuse identification, authentication, or authorization. This point is critical and relevant for API Security, as these attack techniques comprise four of the five in the OWASP API Top 10. 

6.4 Public-facing web applications are protected against attacks

PCI DSS Section 6.4 covers controls that must be in place for publicly facing applications because they are inherently at a higher risk.

6.4.1 For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected against known attacks as follows:

  • Injection attacks, including SQL, LDAP, XPath, or other command, parameter, object, fault, or injection-type flaws.
    • Atleast once every 12 months and after significant changes.
    • By entity that specializes in application security.
    • Including, at a minimum, all common software attacks in Requirement 6.2.4.
    • All vulnerabilities are ranked in accordance with requirement 6.3.1
    • All vulnerabilities are corrected.
    • The application is re-evaluated after the corrections .

OR

  • Installing an automated technical solution(s) that continually detects and prevents web-based attacks as follows:
    • Installed infront of public-facing web applications to detect and prevent web-based attacks.
    • Actively running and up to date as possible.
    • Generating audit logs.
    • Configured to either block web-based attacks or generate an alert that is immediately investigated.

6.4.2 For public-facing web applications, an automated technical solutions is deployed that continually detects and prevents web-based attacks, with atleast the following:

  • Installed infront of public-facing web applications and is configured to detect and prevent web-based attacks.
  • Actively running and up to date as applicable.
  • Generating audit logs.
  • Configured to either block web-based attacks or generate an alert that is immediately investigated.

6.4.1 and 6.4.2 are controls around public-facing web applications and require organizations to protect these applications against new threats and vulnerabilities. To reduce the risk of attacks, the PCI DSS council recommends organizations run an active vulnerability management program that promptly identifies and addresses application vulnerabilities. It also gives organizations the option to implement technical solutions that can detect and prevent these attacks. 

AppSentinels’ automated stateful testing can identify vulnerabilities in applications, and its run-time protection helps block web and API attacks, including OWASP API Top-10 and business-logic issues. AppSentinels can block attacks themselves or via integrations with existing inline devices.  

In conclusion

New security threats and attack vectors have emerged by adopting new software development methodologies, primarily API-driven applications. The PCI Security Standards Council has recognized these new threats and has worked to address them in its newest PCI DSS 4.0 standard. Protecting APIs is critical to meeting the guidance and achieving the industry-standard PCI certification. AppSentinels‘ full life-cycle API Security platform, with its Continuous Discovery, Continuous Stateful API Pen-Testing, and Multi-layer Protection, helps companies meet these compliance and security requirements and helps organizations focus on their core business. Talk to us at contact@appsentinels.ai to know more.