SAFECode and PCI SSC Discuss the Evolution of Secure Software

When the PCI Security Standards Council (PCI SSC) developed its Software Security Framework (SSF) a few years ago, it relied on the expertise of a Software Security Task Force. As part of this task force, SAFECode, along with other industry partners, played an instrumental role in the development of the framework and its standards. 

SAFECode is a global industry forum where business leaders and technical experts come together to exchange insights and ideas on creating, improving, and promoting scalable and effective software security programs. In this blog, we interviewed Steven B. Lipner, Executive Director at SAFECode, and Troy Leach, SVP, Engagement Officer at PCI SSC to discuss the evolution of software development, and the industry’s approach to assuring the security of software. 

How much does industry rely on software and third-party software?

Steven Lipner: Software is the underpinning of modern industry. Almost all organizations, large and small, rely on commercial software products. And industry-specific software systems are widely used in industries ranging from retail to manufacturing. Smaller organizations typically rely on licensed software while medium- and large-sized organizations use a mixture of licensed and in-house developed software. Today, more and more organizations rely on cloud services that in turn rely on the service provider’s software. One important factor today is the emergence of a software supply chain: both in-house and commercial developers often rely on software, including open source software, that they didn’t develop themselves.

Troy Leach: This is especially true for payment software. Our industry has embraced many modern innovations for accepting payments. We’ve seen significant growth in the use of cloud services for e-commerce acceptance and third-party developers for developing mobile payment applications. We’ve also seen the general adoption of more complex software architectures and functions than the more simplistic payment architectures of the past.

How has software development evolved in the past 5+ years?

Steven Lipner: There are four trends that are an important part of software development:

• Reliance on a software supply chain, especially including open source.
• Reliance on cloud services and service providers to supplement or replace in-house development and management of systems and software.
• Adoption of secure development processes. This has grown although it is by no means universal.
• Adoption of rapid development models such as DevOps and Agile that enable development teams to add new features and meet new customer requirements in hours or days rather than months or even years.

Troy Leach: I remember how relatively uncomplicated many architectures were when we first launched our PA-DSS standard and program at the PCI Council. Most payment applications only had a handful of updates every year and the development of those payment applications was generally proprietary. Today, we see updates for a vast majority of payment applications happening much more frequently and leveraging off-the-shelf code and third-party services to include payment acceptance in a larger set of functions.

How has the industry’s approach to assuring the security of software changed over the years? In other words, how have we assured software in the past and how do we need to assure it in the future?

Steven Lipner: There has been a big change in approaches to software security over the past 15 years or so. Historically, organizations emphasized security features such as encryption and password-based authentication, and then some used ad hoc penetration tests to detect and eliminate some design and implementation errors. Beginning in the early 2000s, some organizations began to integrate tools, techniques, and training into their software development processes so that developers would be responsible for building software that was secure against attack, as well as being functionally correct and performing well. The most mature organizations incorporated root cause analysis of discovered vulnerabilities and continuous improvement with the aim of eliminating or mitigating entire classes of security vulnerabilities during development rather than fixing problems one at a time after they were discovered in the field.

Troy Leach: This has also made the evaluation of payment software more difficult to assess through traditional modes, as the software is developed from diverse groups of developers and through various methods. It has required the industry to adapt how we determine the effectiveness of the security to protect the payment data, as well as the access to the environment where payment processing occurs.

In your opinion, what are the similarities and differences between the NIST Secure Software Development Framework and PCI Software Security Framework?

Steven Lipner: Both frameworks recognize that creating secure software is, first and foremost, a process that the development team or organization must create and adhere to. And both recognize the importance of integrating secure development tools, developer training, and continuous improvement into the software development process. As you’d expect, the NIST framework is very general while the PCI framework is somewhat more targeted at software developers in the payment card industry.

Troy Leach: I agree with Steve that the recognition of a changing environment, approach and outcome are intended to be very similar between the two frameworks. PCI Council has a smaller subset focus on payment software predominantly in the private sector. Our goal is to provide businesses a way to independently verify the security and protection of payment data by testing the security capabilities of the software development organizations.

What is SAFECode working on as it relates to software security? How are these frameworks being used by industry and how do they help create that assurance?

Steven Lipner: SAFECode has published several best practice guides and training courses that can help organizations and individual developers do a better job of building secure software. Our “Fundamental Practices for Secure Software Development” is a widely used guide to integrating security into the process of creating software and it’s cited in a number of places throughout the NIST SSDF. We’ve also released documents on major issues including software supply chain and threat modeling, as well as a number of short blog posts on topics ranging from the role of “security champions” within a development organization to “fuzz testing” for software security to issues associated with transition to encryption algorithms that are resistant to attack by quantum computers. These resources are widely cited and used across the industry, and we continue to create more based on our members’ needs and experiences in secure software development.

Troy Leach: My hope is that, as the PCI Council expands the type of software that can be assessed through our Software Security Framework, we continue to receive valuable feedback from our Software Security Task Force which has good representation from SAFECode members. I know that, during the previous release, Steve personally was instrumental in helping to shape our perspective with his recommendations, along with his SAFECode colleagues, and I hope for that collaboration to continue.

What are the practices that software developers need to apply to assure that what they are delivering is secure for customers?

Steven Lipner: The SAFECode Fundamental Practices document is a great introduction to the practices that developers should apply. At a high level, the two things I prioritize are (1) for organizations to be able to accept outside reports of vulnerabilities in their software, remediate those vulnerabilities, perform root cause analysis, and update their processes, tools, and training to prevent similar mistakes from occurring and (2) for organizations to have a complete inventory of third-party components that they incorporate into their software and to be able to learn about and respond to vulnerabilities in those components.

Troy Leach: From our perspective, our Secure Software Lifecycle Standard complements the same security practices by establishing good processes and a consistent methodology for when and how risk and related security are considered throughout the life of payment software. This helps the payment industry to improve consistency in software management processes and provides transparency to those relying on the practices of software developers.

What are the key things that customers should do to verify that the software they purchase has been developed securely?

Steven Lipner: Look for public evidence of a commitment to secure development. If a potential supplier doesn’t have an easy, non-threatening way for someone to report a software vulnerability, it’s probably a good idea to find another supplier. If an organization has a website that talks about its commitment to secure development and the way it goes about that process, that is a sign that they’re actually committed to software security. Certifications of compliance with some standards may provide useful information if the standards require actual implementation of secure development practices – the PCI Secure Software Standard and Secure Software Lifecycle Standard are two examples. Such certifications can be especially helpful for assessment of suppliers of cloud services.

Troy Leach: That’s precisely the goal of our assessment program: to identify and promote good security practices and the recognition of independent evaluation. This gives merchants, service providers and others selecting which payment software to use greater transparency and confidence regarding how the payment data is being protected.

What are some available resources that SAFECode and PCI SSC have developed on this topic?

Steven Lipner: The SAFECode website includes a lot of material on secure development. See the resource centers at Resource Centers – SAFECode and training material at SAFECode Training.

Troy Leach: You can learn more about the PCI Secure Software Standard and Secure Software Lifecycle Standard by downloading these from our online Document Library. Other helpful resources include our PCI Software Security Framework FAQs, SSF At-A-Glance and Transitioning from PA-DSS to the PCI Software Security Framework documents. We are currently offering informational and certification training for Secure Software Lifecycle Assessor and Secure Software Assessor.

Also on the blog: NIST and PCI SSC Find Common Ground in Development of Software Frameworks