Editor's note: In the first part of a three-part series, Ben Rothke and David Mundhenk gave an introduction to the need for application security, and firms that have in-scope PCI applications have a lot to do to ensure PCI compliance.
Application security is a critical part of both good (actually basic) information security practices and PCI compliance. There are several compliance domains relevant to PCI and application security.
PCI Data Security Standard (PCI DSS) requirement 6 states it in seven simple words: “…develop and maintain secure systems and applications.” Those seven words trickle down in 28 individual requirements. These requirements are for application developers who create applications that process, store or transmit cardholder data (CHD).
Requirement 6 is applicable to the development of any internal or external application that’s in-scope for PCI DSS compliance. Any in-house developed application that processes, stores or transmits CHD falls into this category.
We won’t regurgitate the PCI section 6 requirements as you can read it here. But suffice to say application security must be done right. If your firm writes applications that will be in the cardholder data environment (CDE), section 6 will be a lot of work and is not a trivial endeavor.
Credit card payment applications that are developed by software vendors to be used by multiple customers may fall under the Payment Application Data Security Standard (PA-DSS). These applications are required to be assessed by a Payment Application Qualified Security Assessor (PA-QSA). It’s important to note that a PCI DSS QSA is not qualified to assess a payment application.
[ ALSO ON CSO: 5 PCI Compliance gaps ]
Additionally the PCI Security Standards Council has created and enhanced the Point-to-Point Encryption (P2PE) standard previously referenced by the authors in “End-to-End Encryption; the PCI Holy Grail." These new standards represent a concerted approach by the industry to raise the security of credit and debit transactions to levels previously afforded to the more stringently governed electronic funds transfer capabilities of the banking and finance institutions.
Due to the intensive and highly detailed security requirements surrounding the PCI P2PE standard, and the significant costs of implementation and complexities associated with administering certified P2PE implementations, overall industry adoption of this standard has been slow. In some instances, payment application vendors are choosing to ‘cherry-pick’ the more optimal aspects of the P2PE certifications to further enhance payment card security, but not institute all of the P2PE standard’s comprehensive requirements. The result of such could be referenced as P2PE ‘lite’.
Either way, P2PE solutions that employ secure ‘encrypt-at-the-swipe’ payment card data capture ensures resilience against sophisticated RAM-scraping malware, and other threats to CHD being processed in payment systems. Cypher-text representations of CHD stored in RAM of P2PE systems are robustly protected unless there is access to the data encryption key (DEK) to decrypt the data.
Secure coding, what does it really mean?
While many universities have augmented their computer science and engineering programs to include information security and data protection on their curriculum, the majority of graduates will have minimal exposure to leading edge information security concepts and practices.
That leaves the onus of secure coding training to the employers and government entities.
Both the PCI DSS and PA-DSS standards have been updated as of this year to version 3.1. Due to the exponential growth in payment application security related compromises over the last few years, both standards have newly enhanced requirements for secure SDLC processes and practices.
[ ALSO ON CSO: PCI Shrugged: Debunking Criticisms of PCI DSS ]
PCI DSS requirement 6.5 mandates that firms train developers in secure coding techniques, including how to avoid common coding vulnerabilities, and understanding how sensitive data is handled in memory. What this means is that you have to show your PCI Qualified Security Assessor (QSA) that your developers for applications deployed within CDE have had training for secure coding techniques.
The PA-DSS secure SDLC requirements in particular have also been significantly bolstered to include updates such as these:
- 5.1 – Software vendor has designed and implemented a formal process for secure development of payment applications
- 5.1.5 – Secure source-control practices are implemented to verify integrity of source code
- 18.104.22.168 – Coding techniques include documentation of how PAN and/or SAD are handled in memory
- 5.1.7 – Provide training in secure development practices for application developers, as applicable for the developer’s job function and technology used, for example:
- Secure application design
- Secure coding techniques to avoid common coding vulnerabilities
- Managing sensitive data in memory
- Code reviews
- Security testing
- Risk assessment techniques
- 5.4 – The payment application vendor must document and follow a software-versioning methodology as part of their system development lifecycle.
- 5.5 – Risk assessment techniques (for example, application threat-modeling) are used to identify potential application security design flaws and vulnerabilities during the software-development process.
Some of the above requirements mandate that previously ad-hoc SDLC processes be formalized, documented and included in actual processes and practices executed by payment application development teams and managers. Other new requirements mandate that payment application developers fully understand CHD elements such as the Primary Account Number (PAN) and sensitive authentication data (SAD). This is primarily in response to the rash of RAM-scraping malware and other volatile memory attacks plaguing many retail merchant PoS systems.