PCI-DSS 4.0 will be here sooner than you think, and it’s an opportunity to elevate your organization’s cyber resilience
A version of this article appeared on Security Boulevard. It has been updated and syndicated here.
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 BFSI space to seriously uplift their security programs, ushering in a new era of people-driven cyber 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 towards 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 on the code-level tools - the development cohort - they must be enabled to deliver compliant, secure software in any business environment handling digital assets and transactions.
Are your developers prepared to deliver compliant software?
Developers sit as 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 the development team, 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. Multi-Factor Authentication (MFA) will become standard, as will 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 our online banking. 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 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. Anti-malware 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, and that is fertile ground for growing the most security-aware development cohort you’ve ever had.
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.
Chief Executive Officer, Chairman, and Co-Founder
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoChief Executive Officer, Chairman, and Co-Founder
Pieter Danhieux is a globally recognized security expert, with over 12 years 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. In 2016, he was recognized as one of the Coolest Tech people in Australia (Business Insider), awarded Cyber Security Professional of the Year (AISA - Australian Information Security Association) and holds GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA certifications.
A version of this article appeared on Security Boulevard. It has been updated and syndicated here.
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 BFSI space to seriously uplift their security programs, ushering in a new era of people-driven cyber 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 towards 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 on the code-level tools - the development cohort - they must be enabled to deliver compliant, secure software in any business environment handling digital assets and transactions.
Are your developers prepared to deliver compliant software?
Developers sit as 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 the development team, 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. Multi-Factor Authentication (MFA) will become standard, as will 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 our online banking. 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 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. Anti-malware 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, and that is fertile ground for growing the most security-aware development cohort you’ve ever had.
A version of this article appeared on Security Boulevard. It has been updated and syndicated here.
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 BFSI space to seriously uplift their security programs, ushering in a new era of people-driven cyber 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 towards 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 on the code-level tools - the development cohort - they must be enabled to deliver compliant, secure software in any business environment handling digital assets and transactions.
Are your developers prepared to deliver compliant software?
Developers sit as 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 the development team, 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. Multi-Factor Authentication (MFA) will become standard, as will 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 our online banking. 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 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. Anti-malware 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, and that is fertile ground for growing the most security-aware development cohort you’ve ever had.
Click on the link below and download the PDF of this resource.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
View reportBook a demoChief Executive Officer, Chairman, and Co-Founder
Pieter Danhieux is a globally recognized security expert, with over 12 years 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. In 2016, he was recognized as one of the Coolest Tech people in Australia (Business Insider), awarded Cyber Security Professional of the Year (AISA - Australian Information Security Association) and holds GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA certifications.
A version of this article appeared on Security Boulevard. It has been updated and syndicated here.
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 BFSI space to seriously uplift their security programs, ushering in a new era of people-driven cyber 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 towards 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 on the code-level tools - the development cohort - they must be enabled to deliver compliant, secure software in any business environment handling digital assets and transactions.
Are your developers prepared to deliver compliant software?
Developers sit as 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 the development team, 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. Multi-Factor Authentication (MFA) will become standard, as will 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 our online banking. 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 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. Anti-malware 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, and that is fertile ground for growing the most security-aware development cohort you’ve ever had.
Table of contents
Chief Executive Officer, Chairman, and Co-Founder
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoDownloadResources to get you started
Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise
The Secure-by-Design movement is the future of secure software development. Learn about the key elements companies need to keep in mind when they think about a Secure-by-Design initiative.
DigitalOcean Decreases Security Debt with Secure Code Warrior
DigitalOcean's use of Secure Code Warrior training has significantly reduced security debt, allowing teams to focus more on innovation and productivity. The improved security has strengthened their product quality and competitive edge. Looking ahead, the SCW Trust Score will help them further enhance security practices and continue driving innovation.
Resources to get you started
Reactive Versus Preventive Security: Prevention Is a Better Cure
The idea of bringing preventive security to legacy code and systems at the same time as newer applications can seem daunting, but a Secure-by-Design approach, enforced by upskilling developers, can apply security best practices to those systems. It’s the best chance many organizations have of improving their security postures.
The Benefits of Benchmarking Security Skills for Developers
The growing focus on secure code and Secure-by-Design principles requires developers to be trained in cybersecurity from the start of the SDLC, with tools like Secure Code Warrior’s Trust Score helping measure and improve their progress.
Driving Meaningful Success for Enterprise Secure-by-Design Initiatives
Our latest research paper, Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise is the result of deep analysis of real Secure-by-Design initiatives at the enterprise level, and deriving best practice approaches based on data-driven findings.
Deep Dive: Navigating the Critical CUPS Vulnerability in GNU-Linux Systems
Discover the latest security challenges facing Linux users as we explore recent high-severity vulnerabilities in the Common UNIX Printing System (CUPS). Learn how these issues may lead to potential Remote Code Execution (RCE) and what you can do to protect your systems.