PCI Requirement 6 is all about regularly updating your systems.
PCI requirement 6 deals with consistently updating your systems and patching any vulnerabilities that appear.
PCI DSS requirement 6.1 states merchants must “deploy critical patches within a month of release” to maintain compliance.
Application developers are not perfect, which is why updates to patch security holes are frequently released. Once a hacker knows he can get through a security hole, he passes that knowledge on to the hacker community, who then exploit this weakness until the software has been updated.
You should patch all critical components in the card flow pathway, including:
This is especially true for Windows systems. Older Windows systems can make it difficult for merchants to remain secure, especially when the manufacturer no longer supports a particular operating system or version (e.g., Windows XP). Operating system updates often contain security patches to exposed vulnerabilities. If you use an unsupported operating system that doesn’t receive updates and patches, the vulnerability potential increases exponentially.
Be vigilant and consistently update the software associated with your system. Don’t forget about critical software installations like credit card payment applications and mobile devices. To help keep up to date, ask your software vendors to put you on their patch/upgrade email list.
See also: Security Patches in Your Business: Complying with PCI Requirement 6.1
See also: SecurityMetrics PCI Guide
If you develop payment applications in-house (e.g., E-commerce websites, POS applications) you must use very strict development processes and secure coding guidelines as outlined in the PCI DSS.
Don’t forget to develop and test applications in accordance with industry accepted standards like the Open Web Application Security Project (OWASP). This will guide you in your application development process by enforcing secure coding practices and keep software code safe from malicious vulnerabilities (e.g., cross-site scripting, SQL injection, insecure communications, CSRF, etc.). Follow for more data security articles like this
In addition to updating and securing applications, web application firewalls (WAFs) should be implemented in front of public-facing web applications to monitor, detect, and prevent web-based attacks. They can also be used to perform application security assessments. Even though these solutions can’t perform the many functions of an all-purpose network firewall (e.g., network segmentation), they specialize in one specific area: monitoring and blocking web-based traffic.
A WAF can protect web applications visible or accessible from the Internet, including outward facing or intranet applications that involve payment card acceptance. As per PCI DSS regulations, your WAF must be up to date, generate audit logs, and either block cyber-attacks or generate a cyber security alert if an attack is suspected.
SSL and TLS 1.0 are no longer considered acceptable forms of encryption when data is transmitted over open, public networks. The PCI Council has recently extended the migration deadline from June 30, 2016 to June 30, 2018 because so many companies require more time to migrate their systems to at least TLS 1.2 or higher. It’s crucial that you move away from these versions to more secure versions as soon as possible.
See also: How to Migrate from SSL to TLS 1.2
While you work towards this goal, you are required by the PCI Council to write a Risk Mitigation/Migration Plan, which details how you will mitigate this risk until you’ve completed the migration.
.svg)
