For a RFE submitted to PCI-SSC requesting to add in-memory requirement to protect sensitive card holder data, the council responded that version 3.0 of PA-DSS got an update in 2015 pertaining to in-memory handling. Following makes a version wise comparative listing of the changes that were made to PCI-DSS and PA-DSS specs in this regard, along with further justification as to why the changes pointed out by the council are not nearly sufficient, what can be done about it and why this RFE must be given a serious consideration.
Opportunity for PCI-DSS:
PCI-DSS could be considered a forerunner in establishing a firm and granular set of rules for handling sensitive data at rest or in-transit especially in comparison to other industry standards as in health care and more. It yet again has the opportunity to do the same, setting a similar standard for how data in-memory ought be handled. By giving this topic a short shrift or too broad based a mention in its specifications, the PCI council would be missing an opportunity given the prevalence of infractions in this area and eventually would have failed to help set a standard to protect in-memory card holder data.
Industry Relevance:
Verizon's Data Breach Investigations Report (DBIR) over the past several years point out how attacks targeting sensitive in-memory data, especially in payment industry has only consistently and exponentially increased over the years. Reports of that kind give more of a reason to consider adding relevant requirements like the one requested so as to keep up with the industry trends and stay relevant in the long run.
Comparative Data:
Following is a version wise comparative table of information pertaining to the topic in PCI specs (both PCI-DSS and PA-DSS) thus far. Specific words pertaining to the topic are marked in red and green. Any difference between versions of specification are underlined. Not only are information pertaining to in-memory sensitive data handling, if any, sparse and not specific enough, you would also notice that version 3.2 of the PCI-DSS specification is missing a mention on the topic that is present in the 3.0 spec! So, if anything, information pertaining to the topic that already existed was removed from the newer version!
| 3.0 ( Nov 2013) | 3.2 (April/May 2016) |
| PCI-DSS | | 6.5 Address common coding vulnerabilities in software-development processes as follows: · Train developers in secure coding techniques, including how to avoid common coding vulnerabilities, and understanding how sensitive data is handled in memory. · Develop applications based on secure coding guidelines.
Note: The vulnerabilities listed at 6.5.1 through 6.5.10 were current with industry best practices when this version of PCI DSS was published. However, as industry best practices for vulnerability management are updated (for example, the OWASP Guide, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these requirements. | 6.5.a Examine software-development policies and procedures to verify that training in secure coding techniques is required for developers, based on industry best practices and guidance. | The application layer is high-risk and may be targeted by both internal and external threats. Requirements 6.5.1 through 6.5.10 are the minimum controls that should be in place, and organizations should incorporate the relevant secure coding practices as applicable to the particular technology in their environment. Application developers should be properly trained to identify and resolve issues related to these (and other) common coding vulnerabilities. Having staff knowledgeable of secure coding guidelines should minimize the number of security vulnerabilities introduced through poor coding practices. Training for developers may be provided in-house or by third parties and should be applicable for technology used. As industry-accepted secure coding practices change, organizational coding practices and developer training should likewise be updated to address new threats—for example, memory scraping attacks. The vulnerabilities identified in 6.5.1 through 6.5.10 provide a minimum baseline. It is up to the organization to remain up to date with vulnerability trends and incorporate appropriate measures into their secure coding practices. | 6.5.b Interview a sample of developers to verify that they are knowledgeable in secure coding techniques. | 6.5.c Examine records of training to verify that software developers received training on secure coding techniques, including how to avoid common coding vulnerabilities, and understanding how sensitive data is handled in memory. | 6.5.d. Verify that processes are in place to protect applications from, at a minimum, the following vulnerabilities:
| 6.3 Develop internal and external software applications (including web-based administrative access to applications) securely, as follows: · In accordance with PCI DSS (for example, secure authentication and logging) · Based on industry standards and/or best practices. · Incorporating information security throughout the software-development life cycle
Note: this applies to all software developed internally as well as bespoke or custom software developed by a third party. | 6.3.a Examine written software-development processes to verify that the processes are based on industry standards and/or best practices. | Without the inclusion of security during the requirements definition, design, analysis, and testing phases of software development, security vulnerabilities can be inadvertently or maliciously introduced into the production environment. Understanding how sensitive data is handled by the application—including when stored, transmitted, and when in memory—can help identify where data needs to be protected. |
|
| | 6.5 Address common coding vulnerabilities in software-development processes as follows: · Train developers at least annually in up-to-date secure coding techniques, including how to avoid common coding vulnerabilities. · Develop applications based on secure coding guidelines.
Note: The vulnerabilities listed at 6.5.1 through 6.5.10 were current with industry best practices when this version of PCI DSS was published. However, as industry best practices for vulnerability management are updated (for example, the OWASP Guide, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these requirements. | 6.5.a Examine software-development policies and procedures to verify that up-to-date training in secure coding techniques is required for developers at least annually, based on industry best practices and guidance. | The application layer is high-risk and may be targeted by both internal and external threats. Requirements 6.5.1 through 6.5.10 are the minimum controls that should be in place, and organizations should incorporate the relevant secure coding practices as applicable to the particular technology in their environment. Application developers should be properly trained to identify and resolve issues related to these (and other) common coding vulnerabilities. Having staff knowledgeable of secure coding guidelines should minimize the number of security vulnerabilities introduced through poor coding practices. Training for developers may be provided in-house or by third parties and should be applicable for technology used. As industry-accepted secure coding practices change, organizational coding practices and developer training should likewise be updated to address new threats—for example, memory scraping attacks. The vulnerabilities identified in 6.5.1 through 6.5.10 provide a minimum baseline. It is up to the organization to remain up to date with vulnerability trends and incorporate appropriate measures into their secure coding practices. | 6.5.b Examine records of training to verify that software developers receive up-to-date training on secure coding techniques at least annually, including how to avoid common coding vulnerabilities. | 6.5.c Verify that processes are in place to protect applications from, at a minimum, the following vulnerabilities: |
| 6.3 Develop internal and external software applications (including web-based administrative access to applications) securely, as follows: · In accordance with PCI DSS (for example, secure authentication and logging) · Based on industry standards and/or best practices. · Incorporating information security throughout the software-development life cycle
Note: this applies to all software developed internally as well as bespoke or custom software developed by a third party. | 6.3.a Examine written software-development processes to verify that the processes are based on industry standards and/or best practices. | Without the inclusion of security during the requirements definition, design, analysis, and testing phases of software development, security vulnerabilities can be inadvertently or maliciously introduced into the production environment. Understanding how sensitive data is handled by the application—including when stored, transmitted, and when in memory—can help identify where data needs to be protected. | 6.3.b Examine written software-development processes to verify that information security is included throughout the life cycle. | 6.3.c Examine written software-development processes to verify that software applications are developed in accordance with PCI DSS. | 6.3.d Interview software developers to verify that written software-development processes are implemented. |
|
| PA-DSS | 5.1.6.1 Coding techniques include documentation of how PAN and/or SAD are handled in memory. | 5.1.6.1.a Examine coding techniques to verify they include documentation of how PAN and/or SAD are handled in memory. | Attackers use malware tools to capture sensitive data from memory. Minimizing the exposure of PAN/SAD while in memory will help reduce the likelihood that it can be captured by a malicious user or be unknowingly saved to disk in a memory file and left unprotected. This requirement is intended to ensure that consideration is given for how PAN and SAD are handled in memory. Understanding when and for how long sensitive data is present in memory, as well as in what format, will help application vendors to identify potential insecurities in their applications and determine whether additional protections are needed. Whether or not any coding techniques result from this activity will depend on the particular software being developed and the technologies in use. | 5.1.6.1.b Interview developers to verify that they consider how PAN/SAD are handled in memory during the application-development process. |
| 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 (for example, vendor guidelines, OWASP Top 10, SANS CWE Top 25, CERT Secure Coding, etc.) • Managing sensitive data in memory • Code reviews • Security testing (for example, penetration-testing techniques) • Risk-assessment techniques. |
| 5.1.6.1 Coding techniques include documentation of how PAN and/or SAD are handled in memory. | 5.1.6.1.a Examine coding techniques to verify they include documentation of how PAN and/or SAD are handled in memory. | Attackers use malware tools to capture sensitive data from memory. Minimizing the exposure of PAN/SAD while in memory will help reduce the likelihood that it can be captured by a malicious user or be unknowingly saved to disk in a memory file and left unprotected. This requirement is intended to ensure that consideration is given for how PAN and SAD are handled in memory. Understanding when and for how long sensitive data is present in memory, as well as in what format, will help application vendors to identify potential insecurities in their applications and determine whether additional protections are needed. Whether or not any coding techniques result from this activity will depend on the particular software being developed and the technologies in use. | 5.1.6.1.b Interview developers to verify that they consider how PAN/SAD are handled in memory during the application-development process. |
| 5.1.7 Provide up-to-date training in secure development practices for application developers at least annually, as applicable for the developer’s job function and technology used, for example: · Secure application design · Secure coding techniques to avoid common coding vulnerabilities (for example, vendor guidelines, OWASP Top 10, SANS CWE Top 25, CERT Secure Coding, etc.) · Managing sensitive data in memory · Code reviews · Security testing (for example, penetration-testing techniques) · Risk-assessment techniques. |
|
Requirements comparison between data at-rest/in-transit vs data in-memory:
While there is hardly any mention regarding data in-memory, requirements imposed for data at-rest and data in-transit are far more specific. Having very specific requirements for data at-rest, has not only helped sanitize and better control and protect card holder data at-rest, it has also helped place responsibility and accountability on the right shoulders, an expected positive outcome of setting standards, not to mention a show of success of the organization setting those standards. However, given the sparse, indirect and very open ended expectations set for in-memory sensitive data handling thus far, it is likely to result in passing the buck when it comes to responsibility and accountability. Especially in a complex hierarchy as it exist in payment industry, this could end up directly reflecting on the standard setting organization in the long run.
For example, for data at-rest, PCI specifications are very clear on how much of card holder data can be stored, how to contain it, need for encryption before storing and the need to sanitize the environment looking for card holder data at-rest. In comparison, all it states for sensitive in-memory data is some broad based reference to secure coding practices and a thought or two in that line for payment application developers possibly to confine attack vectors to a narrow scope. Just the way topological scoping is enforced by way of defining card holder data environment, an equivalent in-memory scoping of sensitive data should be methodically enforced, as opposed to being left as a suggestion by way of a vague and in direct mention in PCI specifications. Also, just the way sensitive data sanitizing by way of search is enforced for data at-rest, an equivalent method to sanitize volatile memory at varied points ought to be enforced. Method equivalent to encryption as suggested for data at-rest, as in protecting or guarding sensitive data while in-memory could be initially suggested and eventually enforced as the industry catch up to its need and understands the liability in not doing so.
Scope of coverage of topic between PCI-DSS Vs PA-DSS specifications:
Based on the response I got from PCI SSC regarding this RFE and given the focus in the specifications predominantly on coding practices on this topic, I am inclined to think the council, at least at perceptional level would like the onus of in-memory handling of sensitive data to be more in the hands of payment application developers. That thinking might stem from the fact that it is after all the code written by payment application developers that deals with memory. For one thing, it is inconsistent with data at-rest/in-transit requirements, as it is after all the code written by payment application developers that is more likely to handle data at-rest/in-transit. It is also not in the best interest to shift the onus of in-memory handling purely to PA-DSS, just the way PCI doesn't do the same for data at-rest or data in-transit. In other words, as with data at-rest and in-transit, it is better to not look at the in-memory requirement purely from developer perspective.
Conclusion:
It would be short sighted to assume the requirements that exist thus far in PCI-DSS and/or PA-DSS are sufficient for data in-memory especially given the current state of things in the industry. There is also an opportunity for PCI council to set the trend for other standards to follow suite when it comes to in-memory data handling!