The Secure SLC Standard improves business efficiency for payment application vendors but could also stand as new security benchmark for other industries to follow.

Rohit Sethi, COO of Security Compass

February 13, 2019

5 Min Read

When the PCI Security Standards Council (PCI SSC) released the new PCI Software Security Framework in January 2019, it took a progressive leap forward, drastically raising security standards for the payments industry. The framework was created in an effort to align with newly emerging and rapidly advancing technologies in the payments ecosystem.

The new standards require that payments application vendors implement enhanced security controls to adhere to a strictly defined security process. At a high level, the process requires that applications be designed, developed, and maintained to protect the integrity of all payment transactions as well as sensitive data collected in association with those transactions.

In the framework, there are two standards. The PCI Secure Software Standard defines security requirements and assessment procedures for payment applications. The PCI Secure Software Lifecycle (Secure SLC) Standard covers the secure development of applications throughout the whole development cycle. While the former is mandatory and the latter is optional, organizations that can demonstrate compliance with the Secure SLC Standard can forgo the required assessment for every release. This kind of process acceleration is crucial for organizations that employ agile and/or DevOps development processes. 

The Secure SLC Standard not only improves business efficiency for payment application vendors but also has the potential to stand as new security benchmark for other industries to follow. 

5 Compliance Tips
Software developers are adopting more competitive software life-cycle management techniques with faster release cycles, and the PCI Standards were designed to better support these agile environments. To help comply with the PCI Software Security Standards, consider the following:

1. Devise a systematic process for building security in early and maintaining this throughout the SLC.
"The traditional software development lifecycle [addresses] security concerns in the testing phase, which results in very expensive fixes or, worse, security issues that aren't uncovered until operation. Secure development practices integrate security-related activities in each phase of the SDLC, yielding benefits by making security a continuous concern rather than simply part of test procedures," as Archer Batcheller et al. put it in a report from 2017. The Secure SLC Standard requires payment applications vendors to use a documented secure software development policy and corresponding strategy. These must establish measurable rules for ensuring that the vendor's services and products are secure and that its security and compliance obligations are fulfilled.

2. Define and assign security roles and responsibilities in your organization.
In a survey of 29 security leaders, conducted by secureCISO in Phoenix 2018, it was found that 100% of C-level executives, VPs, and security engineers believe that a lack of security skills and awareness poses the greatest challenge to their development of an application security program. Part of facing this challenge involves clearly defining security roles and assigning responsibilities, along with appropriate training to ensure that each role has the requisite skills to carry out its responsibilities. The new PCI standard requires that you identify specific personnel who are responsible for various components of the Secure SLC and provide them with training on the PCI Software Security Framework. Pay close attention to the roles recommended by the standard and identify any gaps that need to be filled using existing employees, contractors, or new hires.

3. Automate threat identification and definition of security controls. 
The Secure SLC Standard requires that threats are identified before development begins. These threats are managed throughout the software life cycle through the implementation and testing of security controls. This essentially stipulates that organizations perform threat modeling activities and/or security requirements management (referred to as ASRTM or Application Security Requirements and Threat Management by Gartner). Generally, this involves maintaining a database of known threats and continuously identifying which of those apply to your application based on its architecture and specific technological makeup.

4. Create a process for continuously identifying and fixing security defects.
This should include regular and continuous testing, which most organizations accomplish with one or more of static analysis, dynamic analysis, or interactive analysis security testing tools, alongside periodic, manual penetration testing. Test results should map back directly to specific security controls you've defined to create traceability and ensure controls were correctly implemented.

5. Communicate with clients and stakeholders about security.
The Secure SLC Standard requires that vendors provide adequate guidance related to the secure installation, configuration, and use of their applications. Hence, in addition to a secure development process, the deployment process must be secure. Also, all stakeholders must be informed in a timely manner regarding any security-related changes to the software or any new vulnerabilities that are discovered. Vendors should create a mechanism, such as a security email alias for clients and external researchers, to notify them of any discovered vulnerabilities.

The PCI Framework in the Bigger Picture
As modern payment technologies evolve, the new PCI Software Security Framework will be crucial for ensuring that the integrity of payment transactions and sensitive data are protected. But the framework also may play a significant role in setting a new security standard for other industries that have equal or greater needs for secure software assurance. Historically, the PCI Data Security Standard (DSS) referenced the Open Web Application Security Project (OWASP) Top 10 in September 2006.

After this point, it became widely referenced by dozens of other compliance documents worldwide. PCI has taken a leadership role in setting the precedent for software security baselines, and we believe that other standards and regulations will similarly take note of the heightened security of payment software resulting from the software security framework. Thankfully, we're at a point where there is an abundance of comprehensive, professional resources to help organizations comply with the new framework. Now, it's only a matter of whether organizations choose to use them.

Related Content:

 

 

 

Join Dark Reading LIVE for two cybersecurity summits at Interop 2019. Learn from the industry's most knowledgeable IT security experts. Check out the Interop agenda here.

About the Author(s)

Rohit Sethi

COO of Security Compass

Rohit Sethi, COO of Security Compass, is responsible for setting and achieving corporate objectives, company alignment, and driving strategy to execution. He specializes in software security requirements management (SSRM), working with large companies in various industries to build security into the software development life cycle.

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights