Elevate Cybersecurity Resilience With PCI-DSS 4.0

Earlier this year, the PCI Security Standards Council revealed version 4.0 of their payment card industry data security standard (PCI-DSS). While organizations won’t need to be fully compliant with 4.0 until March 2025, this update is their most transformative to date and will require most businesses to assess (and likely upgrade) complex security processes and elements of their tech stack. This is in addition to implementing role-based security awareness training and regular secure coding education for developers.

This represents a golden opportunity for companies in the banking, financial services and insurance (BFSI) space to seriously upgrade their security programs, ushering in a new era of people-driven cybersecurity resilience.

What Are the Biggest Challenges in Getting PCI-DSS 4.0-Ready?

Just as an organization’s security program is all-encompassing with intricacies that are unique to its business needs and available resources, the new PCI-DSS standards cover a lot of ground. However, they reveal a pointed shift toward flexibility in approaches to meeting security requirements, and in an industry where tools, threats, strategy and compliance measures can change in an instant, this is significant.

PCI-DSS 4.0 embraces the concept that there are many ways to achieve the same goal of airtight security best practices. This is true, but it seems best suited to organizations with advanced security maturity and leaves a lot of room for error, especially for those who have not been realistic in their assessment of their true internal security maturity. Ultimately, companies must be prepared to engage in security as a continuous, evolving process, not a once-off “set-and-forget” exercise. A strong security culture is a must, with an organization-wide commitment to security awareness.

And those working on the code-level tools—the development cohort—must be enabled to deliver compliant, secure software in any business environment handling digital assets and transactions.

Claroty

Are Your Developers Prepared to Deliver Compliant Software?

Developers are an integral part of reaching a state of software security excellence, and this is especially relevant to more than just token PCI-DSS compliance. It is crucial that developers understand the broader picture of PCI-DSS 4.0 in terms of what they can control and integrate as part of their default approach to a software build.

Three key areas represent the most relevant changes for development teams, and they can be broken down as follows:

Authentication: A viable plan for access control has always been a key part of PCI compliance; however, version 4.0 kicks this up a notch in a way that will require careful implementation both internally and externally. Multifactor authentication (MFA) will become standard as well as bolstered rules around password complexity and timeouts.

With authentication and access control security issues now the most common likely to be faced by your average developer, it is imperative that precision training is rolled out to help them identify and fix these problems in actual code.

Encryption & Key Management: We operate in a world where we can access some of our most sensitive information via multiple access points, such as through our online banking apps. With this high-value data at risk, encryption and strong cryptography practices are a must. Developers have to ensure they carry up-to-date knowledge on where information is transmitted, how users can access it and, even in the event of it ending up in the wrong hands, ensuring it is unreadable by threat actors.

Malicious Software: In the previous PCI-DSS guidelines, security controls around software protection from malicious code were referred to as “antivirus software,” but this oversimplifies what should be a multi-layered approach shielding against far more than viruses alone. Antimalware solutions must be applied wherever necessary and continuous logging and monitoring are mandatory.

It is also vital that developers have learning pathways that cover identifying vulnerable components, especially with most codebases relying at least in part on third-party code.

What Constitutes “Enough” Training for Developers?

Similar to previous recommendations, PCI-DSS 4.0 proposes that developers are trained “at least” annually. However, if the implication is that once a year is enough of a touchpoint for secure software creation, it is nowhere near adequate and is unlikely to result in safer, compliant software.

Developer education should start with a foundational education in the OWASP Top 10, as well as any other vulnerabilities that are language-relevant and business-critical. This should be part of an ongoing program with the view to continue building upon those skills and embedding security not just into software development from the start but also into their mindset and approach to their role. In addition, roles and responsibilities must be abundantly clear to the development cohort and their managers. Security should be a shared responsibility, but it’s only fair to document expectations and ensure they can be met properly.

With the lead time available to prepare for PCI-DSS 4.0 compliance, it is possible to make some significant headway into organization-wide improvements to security culture. That is fertile ground for growing the most security-aware development cohort you’ve ever had.

Pieter Danhieux

Pieter Danhieux is a globally recognized security expert, with over 12 years of experience as a security consultant and 8 years as a principal instructor for SANS, teaching offensive techniques on how to target and assess organizations, systems and individuals for security weaknesses. He is the co-founder and CEO of Secure Code Warrior.

pieter-danhieux has 1 posts and counting.See all posts by pieter-danhieux