Software, whether a locale installation or a web application, carries the risk of attack. While phishing and other social engineering attacks are some of the most common forms of a system breach, hackers still go for open vulnerabilities in software, whether due to bugs or misconfigured settings. That’s why the sixth requirement of the PCI DSS 4.0 emphasizes the practices and policies that help maintain secure software. 

How Are Companies Securing Their Software?

The truth is there are some aspects of security that you can’t 100% prevent, namely those associated with social engineering or the vulnerabilities that come with extensive and diverse IT infrastructures. However, one of the positives of securing software is that, in many cases, you can approach the problem through solid best practices and some strategic automation. 

The challenges differ when you talk about different types of software. Generally speaking, PCI DSS will focus on one or both of the following software types: 

• Out of the Box Software: This is your general-purpose, straight-from-the-vendor solution. With these kinds of software, you’ll often deal with default configurations and packages, so there is little difference between different installations outside of specific data and security.
  
• Bespoke Software: Bespoke, or custom, purpose-built software, is a solution that’s–well, custom-made. Typically, this kind of software is built from the ground up for a specific organization or application, either in-house or by a third party. 

There is little wiggle room between these two categories (generally, when an out-of-the-box application is modified to fit specific needs). Still, for PCI DSS, the distinction is more important than the overlap. 

Across these categories, administrators and security professionals will focus on a few overarching approaches to threat detection and prevention:

• Patching and Updating Strategies: Patching complex software isn’t just a matter of downloading the right files and pushing a button. Business goals, security issues, and overall functionality must be considered alongside security and compliance. Therefore, organizations will have sophisticated plans to help them maintain patched, secured, and efficient software.
  
• Scanning, Audits, and Reviews: As new security threats emerge, software must always stay secure. As such, PCI DSS (and most other compliance standards) require that companies run regular audits and vulnerability scans of software, review results, and make changes based on the results of those scans.
  
• Upgrades and Retirement: As new software is released or updated–and, subsequently, retired–it’s crucial that the organization has a plan to ensure that the transition is smooth, that security requirement are met, and that transitory operation (identity and authentication management, integration with other systems) are correctly implemented. 

What Is the Sixth Requirement for PCI DSS 4.0?

The sixth requirement is specifically about how an organization manages their software. It covers a range of procedures and practices that may ensure the safety of the software. This means addressing hacking and vulnerabilities on the front end and development and management on the back end.

6.1 – Defining Processes and Mechanisms for Maintaining Secure Software

• Documentation: As with all requirements, compliant organizations must maintain compliance documentation, including well-recorded policies, procedures, and rules for conduct for relevant personnel.
  
• Roles and Responsibilities: The organization must also have a hierarchy of positions and people in place to provide accountability and clarity of action related to software security. These responsibilities must align with the tenets of requirement six.

6.2 – Customer Software Security

• Secure Development: Any custom (bespoke) software used to manage cardholder information or primary account numbers (PAN) must be developed based on industry standards, in accordance with PCI DSS requirements, and must include consideration of relevant IT security issues at every stage of its development lifecycle.
  
• Developer Training: Any developers working on bespoke software must be trained (at least once every 12 months) on security relevant to their job function (including programming languages), secure design and programming techniques, and the use of relevant testing and vulnerability testing tools.
  
• Reviewing Code: Code used in bespoke software must be reviewed before release to identify any errors in the code. Any changes made to that code during the review are reviewed and approved by management and individuals other than the writer of that code.
  
• Security Techniques: Bespoke software development must incorporate techniques to prevent or mitigate common threats, including injection attacks, buffer or pointer overflows, attacks against weak encryption, attacks against unsecured APIs, cross-site scripting, attacks against authentication or authorization measures, and others. 

6.3 – Security Vulnerabilities Are Identified and Addressed

• Managing Vulnerabilities: A compliant organization will identify vulnerabilities using industry-recognized sources, assign risk rankings to known vulnerabilities, use those rankings to identify high-risk vulnerabilities, and apply those risk rankings to both traditional and bespoke software.
  
• Inventories: Organizations must maintain inventories of bespoke software as well as third-party software components for vulnerability management.
  
• Patching and Updates: High-security patches, released for critical systems, must be installed within one month of release. Other patches must be installed within the timeframe suggested by the releasing entity. 

6.4 – Web Applications Are Protected Against Attacks

• Protection for Web Applications: Emerging threats to web applications must be addressed on an ongoing basis. This includes manual or automatic vulnerability scanning (at least once every 12 months, conducted by a security entity specializing in application security) that includes all vulnerabilities given a risk rank following requirement 6.3. The organization may also opt to use an automated solution for continual detection that meets the requirements above and generates appropriate audit logs.
  
• Automated Detection and Prevention: Automated technical vulnerability detection solutions must be in place for public-facing web applications to prevent web-based attacks. This solution must actively run, generate audit logs, remain up-to-date, and either block attacks or generate an alert for immediate investigation.
  
• Management of Payment Page Scripts: Payment scripts loaded into consumer web browsers must include a method of authorization to ensure the script’s integrity (through mechanisms like a Content Security Policy (CSP) and an inventory of scripts with written justification for each.

6.5 – Changes Are Managed Securely

• Rules and Procedures for Changes to Systems or Components: Any change to a system component includes a reason for that change, documentation of security impact and approval, testing to ensure the security of that change, and plans and procedures to revert to a secure state should the new or changed component results in security issues.
  
• Compliance Confirmation: Documentation must be in place to demonstrate that the organization meets PCI software security requirements on new or changed systems.
  
• Production Environments: Organizations must maintain separate and distinct production and pre-production environments, segregated with access controls. Each environment has separate roles and functions. PANs are not used in pre-production environments unless they are protected along PCI DSS guidelines and included as part of the overall development environment.

Prepare for PCI DSS 4.0 with Lazarus Alliance

As we dig into the requirements of PCI DSS, you will see the increasing complexity and interoperability of the different technologies, policies, and practices you’ll need to deploy to receive PCI verification and maintain compliance. These practices aren’t just to complete a checklist. However–they are tried-and-true security practices that will help support your security efforts ten years from now. 

Are You Thinking Ahead for PCI DSS 4.0?

Call Lazarus Alliance at 1-888-896-7580 or fill in this form.