Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Application Security

02:30 PM
Rohit Sethi
Rohit Sethi
Connect Directly
E-Mail vvv

5 Expert Tips for Complying with the New PCI Software Security Framework

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

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.

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 ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Threaded  |  Newest First  |  Oldest First
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/3/2020
Pen Testers Who Got Arrested Doing Their Jobs Tell All
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/5/2020
New 'Nanodegree' Program Provides Hands-On Cybersecurity Training
Nicole Ferraro, Contributing Writer,  8/3/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-08-08
In JetBrains YouTrack before 2020.2.6881, the markdown parser could disclose hidden file existence.
PUBLISHED: 2020-08-08
In JetBrains YouTrack before 2020.2.6881, a user without permission is able to create an article draft.
PUBLISHED: 2020-08-08
JetBrains YouTrack before 2020.2.8873 is vulnerable to SSRF in the Workflow component.
PUBLISHED: 2020-08-08
In JetBrains Kotlin before 1.4.0, there is a script-cache privilege escalation vulnerability due to kotlin-main-kts cached scripts in the system temp directory, which is shared by all users by default.
PUBLISHED: 2020-08-08
In JetBrains TeamCity before 2020.1, users with the Modify Group permission can elevate other users' privileges.