40% Of Breaches are Related to Credit Card Data: Is Payment Software Secure?

Forty percent of the data breaches for 2017 were reported as involving credit card data, according to the 2018 Trustwave Global Security Report.¹ The data breaches analyzed used attacks such as phishing/social engineering, malicious insiders, and misconfigurations. This is illustrated below in Figure 1: Methods of Compromise².

Those numbers likely do not include hundreds of incidents that are not reported due to a desire to avoid negative publicity. There is one thing that is certain: Data breaches are a still a thing of the present and will continue well into the future.

Fortunately, in the payment industry, there has been an ongoing effort toward formalizing an assessment process to minimize the risk posed by the use of payment applications since 2008. The effort began with Payment Application Best Practices (PABP), now called the Payment Application Data Security Standard (PA-DSS), both standards under the Payment Card Industry Data Security Standards Council (PCI SSC). Now PA-DSS is evolving toward what has been referred to as the Software Security Standard (S3) Framework, currently in the draft phase and expected to be finalized in the second half of 2018.³ This is a great response for an industry that has been very dynamic, innovative and with a great appetite for software-based applications that are independent of limitations imposed by hardware. Let’s discuss three of the likely changes we expect to see with the release of S3: Expanded scope, a new standard covering the software vendor and software security lifecycle, and greater autonomy for software vendors implementing low-impact changes.

Expanding the scope

Currently for a payment application to qualify under PA-DSS, very strict criteria must be met. Within PA-DSS, a payment application is defined as one “storing, processing, or transmitting” cardholder data as part of the authorization or settlement process. This has left hundreds of applications supporting payment transactions out of scope and opened the gate to higher risk for users of those applications. Yet it has always been the recommended position of the PCI SSC that all payment application should follow the PA-DSS as its standard practices are valid across the payment industry. Only a portion of the vendors related to payment transactions, but currently outside the scope of PA-DSS, implement its requirements.

The new S3 standard is expected to broaden the spectrum of covered payment software, including token-based solutions and fraud monitoring software; for example, consider a digital wallet on a mobile device. Usually, the second step in the process after a token stored on the device has been captured by the merchant’s acquirer is to transmit it for authorization. This means that somewhere in between, there is payment software receiving the token stored on the device and matching it to the credit card number belonging to a specific credit card. From a practical point of view, this wider definition from “payment application” to “payment software” will cover solutions currently out-of-scope, resulting in lower risk for all stakeholders.

A new standard for the secure software lifecycle

Typically, industry has applied security at the end of the development process. With the introduction of S3 however, phases such as requirement analysis and design will get additional attention. For example, software vendors often have informal or formal processes requiring that changes or additions to baseline code be peer reviewed by someone knowledgeable in code-review and secure coding practices. Final changes must be approved by an authorized party. If the same vulnerabilities were to be addressed at the requirement analysis phase, the cost could be up to 100 times less than the cost of correction for software that has been deployed, according to a white paper published by Carnegie Mellon University.⁴ In addition to higher costs associated with correcting deployed software, there are also substantial indirect costs such as loss of reputation, revalidation costs by external consultants, and the loss of future sales.

Thus, it is no surprise to see that the proposed changes introduced with the S3 standard cover areas such as:

• Software Security Governance: Establishing a formal process for building secure payment software from ground zero.
• Secure Software Engineering: Designing payment software that protects sensitive data, functions and resources, and is resistant to attacks.
• Secure Software Management: Monitoring changes and helping to ensure new vulnerabilities are not introduced.
• Secure Communications: Encouraging timely communication regarding vulnerabilities from software vendors to their stakeholders.

Of those four areas, the first two are expected to have an immediate impact on software security, as they impact early phases of the software development process.

Software vendors with greater autonomy

The world is hungry for software spanning platforms such as web, mobile, and Internet of Things (IoT), among others. Consumers are demanding greater speed from software vendors. These realities do not mix well with the current PA-DSS validation process, as it is geared toward a waterfall development methodology versus a quicker time to market models like agile or lean. Eighty-two percent of businesses were already using agile development in 2016, according to a Deloitte University Press survey.⁵

It then makes sense that under S3, software vendors would be given autonomy to self-assess low-impact changes to their payment software to help speed elements of the development cycle. This will be accomplished through a documented process and only for those software vendors meeting certain criteria, such as specific training requirements.

A positive future lies ahead

Over the millenia, humans have accumulated knowledge and transfered it to future generations through the combination of symbols and rules embodied in a written communication system. These efforts have led to groundbreaking advances in fields like medicine, with the discovery of penicillin or in mechanical engineering, with the birth of the steam engine. If we can extrapolate from those successes, the progress achieved so far, along with future security initiatives, will ultimately lead the payment industry toward payment software that is more secure and with mitigated risk levels.

Sources

1. https://www2.trustwave.com/GlobalSecurityReport.html
2. Source: 2018 Trustwave Global Security Report https://www2.trustwave.com/GlobalSecurityReport.html
3. What’s Next for the PCI Software Security Framework? From: https://blog.pcisecuritystandards.org/what-is-next-for-the-pci-software-security-framework
4. Estimating Benefits from Investing in Secure Software Development. From: https://www.us-cert.gov/bsi/articles/knowledge/business-case-models/estimating-benefits-from-investing-in-secure-software-development
5. Tech Trends 2016. From: https://www2.deloitte.com/content/dam/Deloitte/lu/Documents/technology/lu_en_techtrends_lux_15042016.pdf