When considering secure coding for payment card industry compliance, code must adhere to the PCI DSS requirement. PCI DSS stands for Payment Card Industry Data Security Standard.
This adherence means building security into the development process. Compliance is dependent upon coders being properly trained to ensure that any card payment transactions are not occurring in an insecure environment.
Requirement 6 of PCI DSS relates to applications that store, process or transmit cardholder data. Further, it remands that all external and internal applications must follow the Payment Application Data Security Standard (PA-DSS) This requirement is the responsibility of all developers working on code related to cardholder data.
Objectives: Requirement 6 (PCI DSS)
Establish a process to identify security vulnerabilities by using reputable outside sources for security vulnerability information and then assigning a risk ranking such as high, medium or low to newly-discovered security vulnerabilities
To comply with 6.1, consider:
- Documenting your list of software assets used to develop applications, explaining each function the asset provides and keeping it updated
- Creating a system that monitors every item for vulnerabilities continuously; this system should be a reliable source
Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.
Once you have identified vulnerabilities per requirement 6.1, they need to be rectified with a patch. Anything is high-level should be patched first. You should also keep a patching audit log.
Develop secure software applications for internal and external applications, including Web-based administrative access in accordance with PCI DSS, industry best standards and with information security integrated. You can develop secure software applications by:
- Requirement gathering: Determine the functional and technical specification requirements from the previous phase
- Design: All design protocols should be in harmony with the requirement specifications
- Development: Coders must develop secure code and undergo regular training
- Testing: Complete the process with a test to assess specifications, design, and security functions
Remove development and test accounts, user IDs and passwords before release.
Design a process to comply with this requirement that verifies the removal of these elements. Document the process and include an audit record.
Review custom code prior to release to identify any coding vulnerabilities.
This process should be implemented by coders that are familiar with PCI DSS. The reviewers should verify the documentation of processes per 6.3.1. Comprehensive documentation of the code review process should occur and be approved before final release.
Examine policies and procedures to verify that the following are defined:
- Development/test environments should be separate from production environments with access control in place to enforce separation
- Enable a separation of duties between personnel that are developing and those in the production
- Do not use live PANS for testing
- Remove all test data and accounts before a production system becomes active
- Change control procedures related to establishing security patches and software modifications must be documented
PCI DSS decrees that test or development areas are never secure enough for holding cardholder data. Thus, the need for separation. You can keep them separately more easily with network segmentation.
Address common coding vulnerabilities in software development processes as follows:
- Train developers in secure coding techniques, including avoiding common coding vulnerabilities and understanding how sensitive data is handled in memory
- Create applications based on common coding guidelines
With this requirement, PCI DSS requests training of coders for best practices. Before giving a coder clearance to work on PCI-related code, it is recommended they receive specific training.
For public-facing Web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:
- Review public-facing Web applications via manual or automated application vulnerability security assessment tools or methods annually and after any changes are made
- Install an automated technical solution that detects and prevents Web-based attacks in front of public-facing Web applications, to continually check all traffic
You can meet this requirement with a Web application vulnerability scanning tool or Web application firewall. Many organizations apply both.
Ensure that security policies and operational procedures for developing and maintaining secure systems and applications are documented, in use and known to all affected parties.
The documentation required in previous requirements should be properly managed and available to any applicable parties. Conduct at least an annual review of this documentation so that it stays up-to-date.
Common PCI DSS Challenges
While each part of requirement 6 is clear, that doesn’t mean that mistakes aren’t made in coding for PCI compliance. Here are some of the most common challenges organizations face:
- Not treating PCI DSS as a separate project: Organizations often try to fit in the compliance measures to existing projects, but this needs its own project roadmap
- Applying requirements universally across the entire infrastructure: Stricter controls might be needed in some areas, whereas less-stringent ones might be appropriate in others
- Not exercising full control over the movement and usage of credit card data: Some organizations allow other departments or third parties access to this, which means the requirements must be met within those groups as well
- Storing cardholder data when it’s not necessary: Only do so when it is essential
- Addressing PCI compliance only during an annual validation: Sustaining your PCI compliance should be a daily effort
- Not implementing continuous training for coders to ensure they are up-to-date on all known threats: Annual training at the least should be achieved
- Not documenting processes or documenting them in a non-granular manner: There should be no room for interpretation in this documentation. Rather, it should be very clear for each step
PCI DSS Compliance Best Practices for Coders
With all these requirements that must be met, it can seem daunting. However, following the best practices instituted in Requirement 6 and beyond will do more to keep cardholder data safe. You should keep in mind that meeting PCI compliance doesn’t mean that your infrastructure is immune to breaches. It simply reflects you are meeting the minimum standard. So it’s important to go outside that minimum and set up additional ways to keep data secure.
Other best practices you should consider include:
- Identifying and maintaining goals in relation to PCI coding compliance: It’s not just about obtaining compliance reports, it’s a proactive goal to secure cardholder data
- Establish long-term processes and governance related to PCI: This isn’t something you just set and walk away from. Rather, it must be a core objective of any organization
- Focus on risk and security: Compliance is a byproduct of identifying risk and mitigating it with securing actions
- Never stop auditing and scanning
- Define ownership of PCI compliance
- Segment your data: Create a cardholder environment separate from other company data
- Control access to cardholder data with role-based access controls
- Use encryption protocols beyond SSL/TLS
- Conduct regular risk assessments
One Last Thought: Maintaining and Going Beyond PCI DSS Compliance
First, you have to reach the compliance state then you can enrich your activities further by implementing best practices and improving your PCI compliance program to exceed the requirements. One of the most important parts of compliance and managing risk is that the coder stay well-educated and trained on security awareness topics.