PCI-DSS has long been the standard for securing payment card-related information. Meeting this bar was the bare minimum requirement for showing that an organization had sufficient controls to keep this data secure. With changes to PCI-DSS already being released and required by 2024, organizations developing and running applications to collect or process payment card-related data need to get prepared to meet the latest requirements.
Unfortunately, not every organization can meet the requirements, with auditors observing less than 30% of their clients remain compliant year over year. The failure to maintain compliance comes often occurs when organizations are unable to show evidence of current control effectiveness. If a business takes a set it and forget it approach to security, it will be unable to provide continual evidence that their controls, policies, and procedures are working effectively. Companies that don’t meet compliance will find themselves unable to take payment cards, crippling their ability to do business.
This blog explores the challenges in securing applications for PCI-DSS and how organizations can prepare for the changes in PCI-DSS 4.0.
Securing Applications for PCI
When it comes to PCI-DSS, the heart of security needs to focus on where the payment card-related information is collected – often in an application. Ensuring that applications used for payment processing and data collection are secured is crucial for meeting the explicitly outlined PCI requirements. With the latest changes in PCI-DSS 4.0, organizations will have more flexibility in implementing the security controls that can help them meet the high bar of PCI-DSS and deliver better organizational security needs.
Changing for Flexibility
The current incarnation of PCI-DSS had particular requirements to implement to comply with the framework. Organizations that could not meet the explicitly stated needs could utilize compensating controls to deliver the equivalent of the indicated control. While this sounds good on paper, the execution of proving that compensating controls are sufficient is daunting.
To replace compensating controls and help streamline the review process, the concept of customized controls was added to PCI-DSS 4.0. Customized controls are defined by the organization and approved by an auditor. This change puts the focus on the act of achieving compliance, rather than the method of achieving it, and opens up more options for organizations to use to achieve compliance.
Bar is Still High
Just because organizations can utilize customized controls for some of the control requirements of PCI-DSS 4.0 does not mean that the requirements are any less stringent than before. Most of the exact requirements present in the current version of PCI-DSS are still in effect in 4.0. This is especially true for securing applications that handle payment card information.
A rigid set of requirements address application code and whether it is implemented using best practices. These include testing required to identify potential flaws and vulnerabilities before code can be used in a live environment. Collecting the evidence to show compliance with these controls falls on the application developer, no matter if development is in-house, externally contracted, or from off-the-shelf software.
Meeting The Bar
Meeting PCI-DSS requirements for application security requires following best practices and having the right tools to verify your solutions. The verification involves increasing visibility into the different flaws and vulnerabilities that might exist in the code and those in the endpoints where the application is hosted. It is essential to use solutions that accurately detect issues and provide in-depth reporting that can supply evidence to auditors.
Testing
With applications, code is the best place to start testing. While manual inspection might allow testers to catch some application problems, it does not scale well for modern software – it is a lengthy process and can have a low accuracy rate.
Current codebases amalgamate numerous external libraries and thousands of lines of code. Automated tools are the only efficient and effective way to test the code and its implementation. Using code analysis tools such as software composition analysis (SCA), static application security testing (SAST), and dynamic application security testing (DAST), testers can identify security vulnerabilities, design defects, logical errors, and implementation flaws, as PCI-DSS requires.
Vulnerability Management
The composition of software is only the starting point when evaluating the security of an application. Vulnerabilities in the underlying infrastructure and services that support the application are just as critical. Vulnerabilities exploitable by cybercriminals can bypass existing security controls such as authentication and access controls to allow attackers to directly access sensitive data, even if the application itself is bulletproof.
Detecting and managing these vulnerabilities before the attackers can identify them and make use of them is required by PCI-DSS and is a security best practice. Modern vulnerability scanners can automatically assess infrastructure on-premises and in the cloud, identifying vulnerabilities based on the same databases attackers use to find system vulnerabilities. Automatically scheduled assessment helps organizations meet PCI-DSS requirements, showing that vulnerability analysis is continuous and not a one-time effort.
App Security You Can Trust
Organizations need trustworthy solutions when working to meet PCI-DSS current and future requirements. Fortra offers a full suite of products to help your software solutions meet PCI-DSS requirements and ensure they are secure from design through production.
Get the Complete Guide to Application Security for PCI-DSS
Learn more about how PCI-DSS 4.0 changes the application security landscape and how your organization can get prepared before the changes are mandatory.