Read Time:2 Minute, 36 Second
This is the fourth blog in the series focused on PCI DSS, written by an AT&T Cybersecurity consultant. See the first blog relating to IAM and PCI DSS here. See the second blog on PCI DSS reporting details to ensure when contracting quarterly CDE tests here. The third blog on network and data flow diagrams for PCI DSS compliance is here.
Requirement 6 of the Payment Card Industry (PCI) Data Security Standard (DSS) v3.2.1 was written before APIs became a big thing in applications, and therefore largely ignores them.
However, the Secure Software Standard and PCI-Secure-SLC-Standard-v1_1.pdf from PCI have both begun to recognize the importance of covering them.
The Open Web Application Security Project (OWASP) issued a top 10 flaws list specifically for APIs from one of its subgroups, the OWASP API Security Project in 2019. Ultimately if the APIs exist in, or could affect the security of the CDE, they are in scope for an assessment.
API testing transcends traditional firewall, web application firewall, SAST and DAST testing in that it addresses the multiple co-existing sessions and states that an application is dealing with. It uses fuzzing techniques (automated manipulation of data fields such as session identifiers) to validate that those sessions, including their state information and data, are adequately separated from one another.
As an example: consumer-A must not be able to access consumer-B’s session data, nor to piggyback on information from consumer-B’s session to carry consumer-A’s possibly unauthenticated session further into the application or servers. API testing will also ensure that any management tasks (such as new account creation) available through APIs are adequately authenticated, authorized and impervious to hijacking.
Even in an API with just 10 methods, there can be more than 1,000 tests that need to be executed to ensure all the OWASP top 10 issues are protected against. Most such testing requires the swagger file (API definition file) to start from, and a selection of differently privileged test userIDs to work with.
API testing will also potentially reveal that some useful logging, and therefore alerting, is not occurring because the API is not generating logs for those events, or the log destination is not integrated with the SIEM. The API may thus need some redesign to make sure all PCI-required events are in fact being recorded (especially when related to access control, account management, and elevated privilege use). PCI DSS v4.0 has expanded the need for logging in certain situations, so ensure tests are performed to validate the logging paradigm for all required paths.
Finally, both internal and externally accessible APIs should be tested because least-privilege for PCI requires that any unauthorized persons be adequately prevented from accessing functions that are not relevant to their job responsibilities.
AT&T Cybersecurity provides a broad range of consulting services to help you out in your journey to manage risk and keep your company secure. PCI-DSS consulting is only one of the areas where we can assist. Check out our services.
