Software Composition Analysis and the Payment Card Industry
Software Composition Analysis and the Payment Card Industry Introduction
The payment card industry is changing. For over 50 years function specific secure hardware has been a dominant component of protecting card holder data. During the last 11 years there has been a significant shift in consumer behaviour driven by the broadening of capabilities across the payment card industry. Software has always been at the heart of payments and is present within dedicated devices from specialist suppliers. Now the industry is creating payment software for use in a wide range of consumer based off the self-products. How software is being developed has also changed. Agile development, using off the shelf open source software components is the standard development method to achieve the economy, efficiency and effectiveness that is being demanded. The Payment Card Industry Security Standards Council (PCI SSC) is responding to these changes by publishing security standards for the development and management of payment application software that stores, processes or transmits cardholder data.
With the increased availability and use of open source components in software development there is an increase in probability that a developer will use components which have known vulnerabilities. In 2017 Equifax had a massive data breach caused by attackers exploiting two vulnerabilities in the popular open source framework Apache Struts (CVE-2017-5638). Following the disclosure of the breach downloads of the vulnerable version of Apache Struts continued at the same rate as prior to the disclosure, roughly 80,000 downloads per month
This paper is designed for organisations that are part of the DevOps cycle of software code in the context of creating secure software for payments. Clearly relevant to FinTech and applicable to traditional organisations.
Now, let’s look at the benefits of software composition analysis and how this is relevant to the PCI SSC Software Security Framework for secure software development.
Modern Software Development the role of Software Composition Analysis (SCA)
Modern applications are typically composed of 90% open source components. Comparing this to legacy applications which are 90% proprietary code gives an indication to the changes that have happened in software development which has created a change in the risk landscape and how software now needs to be managed.
Because of this software development practice of leveraging third-party software to, engineering, production and delivery of applications has become known as a software supply chain.
Each of these software components includes several attributes such as a license and version number.
The 2018 State of the Software Supply Chain Report by Sonatype revealed:
- One in eight open source component downloads contain a known vulnerability
- Open source vulnerabilities increased 120% YoY and their mean time to exploit compressed by 93.5%
- Suspected or known open source breaches increased 55% YoY
An example of what can happen if the open source software supply chain is not managed is Equifax’s massive data breach in 2017, where attackers exploited two vulnerabilities in a popular open source framework Apache Struts.
The breach is estimated to have cost Equifax $4 Billion
“at the time that the breach was announced, I wasn’t even aware that we were running Apache Struts in the particular environment”
Graeme Payne, former Equifax SVP and CIO
Because of this situation solution providers need to demonstrate that users can trust their software supply chain.
This has led to the development of tools and processes help solution providers manage and secure their software supply chain to create an environment where software is secure by design.
The process for engineering in security by design is referred to as DevSecOps, where the collaborative framework of DevOps includes security as a shared responsibility.
The technology for managing open source components is referred to as Software Composition Analysis (SCA). SCA helps organisations build an inventory of open source software components and their attributes such as:
- Licensing and copyright information – Are there licensing obligations that create a risk?
- Security vulnerability information – Are there know security vulnerabilities in components?
- Operational information – How well supported are components?
This inventory is referred to as a software Bill of Materials (SBoM), which is produced by a Software Composition Analysis (SCA) service. A good service would report on at least known security vulnerabilities and licensing issues but can also help with Copyright and quality code management.
Automating Software Supply Chain Management
If an organisation is new to managing an open source software supply chain, they may start by performing an audit of their software code, identify issues and then remediating. This point in time approach although useful does address the dynamic nature of the problem.
The number of open source components available to developers is increasing all the time which leads to an increase in the number of vulnerabilities being discovered and reported.
Fortunately, this problem can be managed and automated via a combination of people, process and technology.
Bringing all areas of an organisation together from development to operations to define a policy and process for managing security combined with integrating SCA technology into the development environment then it is possible to move to a secure by design principle.
At the start of the development process insecure open source components can be identified and therefore avoided. At the delivery end of the process a Bill of Materials can be generated which documents what open source is used and that only secure components have been used. This will help build trust in the software supply chain.
Service Provision
There are two approaches which can be taken:
- Baseline Model – the customer can pay for an audit (as currently delivered), receive feedback and then undertake a remediation cycle. Typically, a second audit will be required to pass, however, this fail the requirements.
- Dynamic Model – the customer pays for an audit and 2 services which help to streamline the process:
- Integrating a Software Composition Analysis (SCA) tool into the build environment enables an “on-demand Software Bill of Materials SBoM” which can be quickly validated by the Software Composition service.
- By subscribing to the service, the customer can receive alerts about new vulnerabilities and component releases – reducing the management overhead.
- Integrating a Software Composition Analysis tool into the build environment enables an “on-demand Bill of Materials” which can be quickly validated by the Software Composition service.
- By subscribing to the service, the customer can receive alerts about new vulnerabilities and component releases – reducing the management overhead.
Then internal versus external we have a process of having developers self-managing as above but we provide independent reporting to validate
Closing Thoughts
Developers of software need to be cognisant that the Payment Card Industry has evolved its security standards for software. 2019 and beyond new software security standards are being published by the PCI SSC. It is for the software developer and their stakeholders to ensure that all software that stores, processes or transmits card holder data has been developed in accordance with the PCI software security framework and its associated standards.
The PCI SSC does not and cannot predict the future. The PCI SSC publish security standards as a response to visible trends. Therefore, whilst the PCI SSC Software Security Framework and associated standards are relatively new the underlying trends indicating need has being visible for several years. Therefore, there is no need to wait. Use the present to demonstrate to your clients that your developments are secure, and that security of cardholder data is embedded within your DevOps process.
Contractual relationships between organisations and their payment acquiring and card brand counterparts means that compliance with the security standards published by the PCI SSC will always be written into the contractual relationship of organisations accepting payments for goods or services. This is because it is the card brands that drive the compliance relationship that the acquirer has with their client organisations.
The PCI Software Security Framework and its associated Security Standards will respond to the requests of organisations for data security standards that are relevant to modern payment acceptance methods; is technology neutral and technology relevant; and provides implementation flexibility together with ease of continued maintenance.
For most organisations PCI software security standards are not their primary purpose which is why working with experienced partners is a proven method of simplifying the problem of payment security and compliance.
About the Authors
Martin Callinan has over 20 years’ experience in the software industry specialising in software licensing, IT Governance and risk avoidance. He has seen the challenges of risk management related to various aspects of the software ecosystem. Martin is now focused on assisting organisations leveraging the benefits of open source software to create bespoke applications in house or through third parties while managing the business risks of intellectual property, open source component licensing, copyrights, security vulnerability management, and operational risk.
Martin is actively involved in the open source software industry to help create best practices and industry standards for the adoption and management of open source based software. He is actively involved in supporting latest industry best practices and standards such as ISO/IEC 5230 OpenChain Standard.
Michael Christodoulides is a cyber security, risk and assurance professional with extensive experience of managing and delivering risk and assurance assessments across the payment card industry and its stakeholder groups.
Michael believes that businesses which deploy effective security controls in accordance with internationally recognised standards are also enabled to grow. This is because they can focus on doing what they do best without unplanned distractions caused by breaches in data security.
Michael has previously represented payment card industry stakeholders as a representative to the Board of Advisors of the Payment Cards Industry Security Standards Council (PCI SSC), the UK Finance Acquirer Working Group and Global Co-chair of the PCI SSC Taskforce responsible for developing secure practices for merchants