The main directive of the Payment Card Industry Data Security Standard (PCI DSS) Requirement 6 is to "develop and maintain secure systems and applications." At a high level, the requirement seems reasonable and the language in the title is simple and straightforward. Closer investigation, however, reveals a much more complex compliance scenario.
While most of the contents of Requirement 6 are not technically difficult to achieve, maintaining the balance between an ecommerce organization’s business requirements, brand integrity, usability requirements, and security is challenging. It is the responsibility of the development team to weigh the best interests of the organization against its wish list, all while adhering to the best practices and requirements set forth in the PCI DSS standard to protect the organization and its customers.
Requirement 6 affects almost every aspect of the development process, from the planning stage to post-launch maintenance. Some of the provisions of Requirement 6 are very specific in nature and will vary depending on your deployment and development environment. Thus, this article will cover all of the general compliance guidelines.
System Configuration, Maintenance and Security
As with all of the PCI DSS requirements, it is important to consider all of the required accommodations early on and throughout the planning phase. The scope of Requirement 6 reaches beyond code, to the configuration of the development and production environments as well as the administration of both.
This includes simple things, such as the requirement in Provision 6.1 that all systems (both production and development servers, as well as all developer workstations) have the latest security patches installed within 30 days of their release (or 90 days if your company’s policy requires roll-out testing); and that all security patches are tested against the vulnerability they fix prior to deployment in a production environment. Provisions 6.3.2-6.3.3 require that production and development environments be completely separate, and that a policy exists to provide a separation of duties, responsibilities and privileges between users with access to either system.
Additionally, specific system vulnerabilities may be addressed in code or as system configuration adjustments. The solution to each will be different for each configuration. Most PCI-certified vulnerability monitoring solutions will provide additional, detailed guidance for each specific instance discovered.
Considerations During Development
Requirement 6.3 and 6.5 are quite vague, but generally encompasses what are already considered best practices amongst developers. The PCI Security Standards Council recommends the Open Web Application Security Project Guide as a reference for community-accepted best practices in the architecture of your solution.
Requirement 6.3.1.1 and 6.5.1-6.5.10 specifically deal with the most common methods by which malicious attempts to compromise an application are made – namely SQL injection, cross-site scripting (XSS), cross-site request forgeries (CSRFs), and malicious file execution. It is simple enough to completely sanitize an HTTP request header, but often times the intended functionality is to post markup or script to a server (such as in a WYSIWYG editor). Writing custom exceptions for these specific instances without exposing yourself to potential risk is extremely labor intensive if done manually. In this scenario, the use of a web application firewall allows the developer to catch specific attempts, but generally be open and allow the web application firewall to catch suspicious HTTP traffic and create exceptions based on your application's functionality.
Once you’re ready to push your application to a production environment, you’ll need to follow requirements 6.3.1.2-6.3.1.5, which describe validation requirements of encrypted data storage and transmission, proper error handling, and role-based access controls (RBACs).
The requirements for data transmission and storage are discussed in depth in PCI DSS Requirement 4, which was covered in an earlier article. Once those encryption methods have been implemented, they must be reviewed and validated. In addition to encryption, Payment Account Number (PAN) data from a production system must never be present in a development environment, and all testing data must also be removed prior to deployment to production.
Error handling is generally simple, but is often overlooked. Disabling error output (PHP/Java/Python) or disabling .NET’s debug mode will prevent the disclosure of potentially sensitive information in your code. This should also include validation that tracing is disabled in compiled applications (Flash/.NET), and as a best practice, it is recommended that you use custom error pages wherever possible.
In addition to validating all of these items within the scope of your application, you must also ensure that all external endpoints (including third-party APIs) meet your application’s own requirements. For the purposes of PCI compliance, any third-party API or provider with which you integrate is included in the scope of your audit. Partnering with a vendor who is already PCI compliant can help reduce the number of questions an auditor may have.
Development Review and Procedural Guidelines
Code reviews are an important part of development for many reasons, but PCI DSS requires them to ensure that all code is properly implemented when separate teams or programmers collaborate on implementation of a security objective, but also as a measure to ensure that no developer has intentionally integrated security flaws or "back doors" into the codebase.
It is also required that developers review all newly discovered vulnerabilities and assess their impact, applying security patches or code modification as appropriate. Using a PCI-certified vulnerability monitoring partner to perform scans on your network and applications not only simplifies the process of identifying known vulnerabilities, but it also ensures that you’re scanning for all of the latest known attacks, including 0-day vulnerabilities. Scanning, whether automated or manual, is required by provision 6.6.
Throughout the entire process, Requirement 6.4 outlines the need for change management procedures. These procedures must be part of your development and production-launch policies, and should include:
- Documentation—documenting the changes made both in functionality and in code, possible implications of these changes and their effect on other components of the application/network.
- Management Approval—a hierarchy must be established as part of this policy and changes then must be approved, once proper documentation is supplied, prior to launching the changes from the development environment to staging, and then from staging to the production environment.
- Testing—all code must be thoroughly tested, not only for its resilience against hacking attempts, but for the overall health of the application. Buffer runs, memory leaks, overflows, and other performance related issues can also cause severe security vulnerabilities. Items that may have previously been regarded as acceptable risk to usability or performance may not pass a PCI audit because of the risk they pose to security.
- Back Out Procedures—sometimes significant changes to the application and/or database schema, while not completely irreversible, may be difficult to revert. For every change that is documented, a reversal procedure must also be documented.
Conclusion
The provisions of PCI DSS Requirement 6 vary from being very specific to being very vague, or very cumbersome to relatively simple to implement. The requirement outlines the use of best practices throughout the planning, development, and maintenance phases of your application. You can use many options and methods to meet the provisions of this requirement, and each specific deployment will have its own set of quirks. In this article, I've outlined the several portions of Requirement 6 in the hope that it will point you in the right direction when you're developing for ecommerce.
Luke Fritz is Lead Application Security Engineer for FireHost
Resources
- PCI DSS
- Navigating PCI DSS: Understanding the Intent of the Requirements, v1.2
- Glossary of Terms used in the PCI Standard
- Automated, Continuous Vulnerability Monitoring
- Web Application Firewall and Other Application Protections
