In the previous article, we discussed how the payment processing works and the first three PCI requirements. In this post we will explore the next four PCI DSS requirements.
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 as it travels between systems with a trustworthy SSL certificate. If a website uses an SSL certificate, you can access it over https instead of http.
TLS is a protocols that generally refers to using an SSL certificate for encryption and digital signatures. TLS is used when HTTPS is used to protect the integrity and confidentiality of data sent between two systems (e.g., browser and the website). Note that SSL and TLS are technically different protocols and 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 the green padlock.
To go beyond this requirement 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 keep on emerging almost daily, protecting your employees’ workstations is extremely important. Thus, make sure that 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 should be able to disable or modify it. In addition, 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.
Also, this requirement states that all employees should be aware of the organizational policies and procedures regarding malware protection. Therefore, ensure that all personnel have a strong security awareness understanding. Using an entertaining and short form Security Awareness training provider can help make this more engaging and effective for end users. Also bringing in interesting speakers from law enforcement or other areas that work in cybersecurity can increase engagement and awareness.
Requirement 6: Develop and maintain secure systems and applications
To go beyond this requirement, you should consider the following security practices as part of a 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 that you are looking for: secure coding. Studies have shown that multiple choice lessons, videos, and slides are not as effective as real hands-on coding. To achieve this, you need adequate secure coding training that helps developers to get an in-depth understanding of the most prevalent web vulnerabilities and the knowledge required to address them in a proactive manner.
2. Use both static and dynamic code analysis
In order to consolidate your secure coding initiative, make sure your products are tested with both static and dynamic code analysis tools and techniques.
Its 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 it. However, static analysis output requires human evaluation since the tools are prone to produce false positives and false negatives. Using dynamic code analysis tools can also help find additional vulnerabilities that static analysis tools cannot find.
An example of success with static analysis is with a Facebook developed internal static analysis tool Zoncolan. This automatically scanned the 100 million line codebase in less than 30 minutes. They managed to completely eradicate some web vulnerability types such as SQL Injection from their code. As Facebook stated, “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 will guarantee you 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 are allowed to 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 job opportunities. This approach has been around for more than 20 years but became popular several years ago when technology giants such as Google, Yahoo, Microsoft, and others successfully implemented this to their classical penetration testing audits.
If you are interested in learning more about Vulnerability Disclosure Programs, you can do so here, where we discuss this topic and 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. However, this doesn’t mean that someone who works in the HR department should be able to access the data center.
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 any network configurations. Each employee should have their own unique username and password that will give them the correct access level once logged into a workstation. Everybody should only be allowed to access their own network area. There are some exceptions to these rules. For example, the IT department should have 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.