Published on
In the second installment in this series, we introduced how payment processing works and explained the first three PCI requirements. In this post we will explore the next four PCI DSS requirements, including a cornerstone of any PCI compliance program - PCI secure coding training for developers.
Visit our Business Guide to PCI-DSS Compliance Training for more information
Requirement 4: Encrypt transmission of cardholder data across open, public networks
If you send cardholder data between your application and a customer’s device, you must encrypt the data with a trustworthy SSL certificate. Websites using an SSL certificate will have a website address that begin with https instead of http.
TLS is a protocol that generally refers to using an SSL certificate for encryption and digital signatures. TLS is used with HTTPS to protect the integrity and confidentiality of data sent between two systems (e.g., browser and the website). While similar in functionality, SSL and TLS are technically different protocols, TLS is an updated, more secure version of SSL.
To be compliant with this requirement, you must use a TLS v1.1 or higher. The good part is that there are plenty of options: from free single subdomain certificates such as those offered by Let’s Encrypt, to commercial-grade certificates, which show your business name in addition to a green padlock.
To do more than just meet the bare minimum, check your website with Qualys SSL Labs and make sure the configuration settings get your website an A+. TLS. v1.2 should be the minimum version that is used.
Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs
Since new threats emerge almost daily, protecting your employees’ workstations is extremely important. Make sure all workstations are equipped with anti-virus software that is regularly updated. The anti-virus software must be set up in such a manner that only authorized personnel can disable or modify it. Using legacy anti-virus software that only relies on signature is not enough. Look for a next generation end point security tool that offers more.
This requirement also says that all employees should be aware of the organizational policies and procedures regarding malware protection. Building your team's security awareness knowledge is an essential component to PCI compliance.
While non-technical roles can get by with high-level security awareness courses, your technical teams will benefit from a more in-depth approach. That is discussed more in the next requirement.
Requirement 6: Develop and maintain secure systems and applications
This is one requirement you want to go beyond the bare minimum on. There is simply too much at stake to skimp here. The following are the security best practices you should build in to your Secure Software Development Lifecycle (SDLC).
1. Introduce hands-on secure coding training
Hands-on training that requires developers to actually code is highly recommended. This ensures that developers are practicing what they are learning and getting experience in the outcome you are looking for: more secure code. Studies have shown that actual hands-on coding exercises are more effective than basic multiple choice lessons or viewing a slide deck.
To achieve a higher level of security success, you need effective secure coding training that gives developers an in-depth understanding of the most prevalent web vulnerabilities and strategies to mitigate them in a proactive way. Armed with this knowledge, your developers are better equipped to incorporate secure coding tactics into every line of code.
2. Use static and dynamic code analysis
In order to consolidate your PCI secure coding initiative, make sure your products are tested with both static and dynamic code analysis tools and techniques.
The purpose is to automatically identify coding errors before a program is released, and static analysis is a great way to do this. The tools used in this process parse and examine the source code of a program based on a predefined set of rules and patterns without executing the code. Static analysis requires human evaluation of the output, since the tools are prone to produce false positives and false negatives. Adding dynamic code analysis tools helps find additional vulnerabilities that static analysis tools might miss.
An example of success with static analysis is Facebook-developed internal static analysis tool Zoncolan. The tool automatically scanned the 100 million line codebase in less than 30 minutes. This helped Facebook to completely eradicate some web vulnerability types such as SQL Injection from their code.
As Facebook noted, “Zoncolan helped find and triage more than 1,100 security issues with severity “significant” or higher, indicating they required immediate action.”
3. Don’t forget a secure code review
As the name suggests, this process refers to manually reviewing the source code of a program in order to identify possible security issues. In contrast to automated static analysis, which is faster, manual code reviews usually requires more time and the person in charge of this process must have a strong security background.
However, manual code reviews can reveal additional vulnerabilities, such as logical flaws that cannot be detected using static analysis tools.
4. Bug bounty programs
Since none of the above practices can guarantee there are no vulnerabilities in the application, you should also consider a bug bounty program as part of your Vulnerability Disclosure Program.
A bug bounty program is a crowdsourced security solution where independent ethical hackers find and report vulnerabilities in a company’s products or infrastructure. Some hackers do this for a living, while others are motivated by monetary rewards (“bounties”), public recognition, or even future job opportunities.
Bug bounty programs have been around for more than 20 years but became popular several years ago when technology giants including Google, Yahoo, and Microsoft successfully implemented this as a complement to their classical penetration testing audits.
If you are interested in learning more about Vulnerability Disclosure Programs, check out our blog post where we show you how to develop a VDP.
Requirement 7: Restrict access to cardholder data by business need to know
This requirement states that only authorized individuals should be able to access the organization’s systems. Practically speaking, each workstation should only be allowed to access what is required for the user to successfully do in their job.
For instance, an ordinary workstation should never be allowed access to any network configurations. Each employee should have their own unique username and password that will give them the correct access level once they log into a workstation. Likewise, each employee should only be allowed to access their own network area.
There are some exceptions to these rules, of course. For example, the IT department needs access to the entire network, but they should not be allowed to access personal information.
The goal is to limit the users’ and services’ privileges to the least amount necessary to complete their job.
Continue reading the final installment in this series, where we cover the rest of the PCI DSS requirements.
