Blog

PCI-DSS 4.0 will be here sooner than you think, and it’s an opportunity to elevate your organization’s cyber resilience

Pieter Danhieux
Published Jun 30, 2023

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.

Download your ultimate guide to PCI DSS 4.0 compliance for developers.
Colorful credit card being held above a laptop keyboard.
Colorful credit card being held above a laptop keyboard.
View Resource
View Resource

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.

Interested in more?

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 demo
Share on:
Author
Pieter Danhieux
Published Jun 30, 2023

Chief 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.

Share on:
Colorful credit card being held above a laptop keyboard.
Colorful credit card being held above a laptop keyboard.

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.

Download your ultimate guide to PCI DSS 4.0 compliance for developers.
View Resource
View Resource

Fill out the form below to download the report

We would like your permission to send you information on our products and/or related secure coding topics. We’ll always treat your personal details with the utmost care and will never sell them to other companies for marketing purposes.

Submit
Download
Thank you for downloading!
View Whitepaper
To submit the form, please enable 'Analytics' cookies. Feel free to disable them again once you're done.
Colorful credit card being held above a laptop keyboard.

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.

Download your ultimate guide to PCI DSS 4.0 compliance for developers.
Access resource

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 demo
Share on:
Interested in more?

Share on:
Author
Pieter Danhieux
Published Jun 30, 2023

Chief 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.

Share on:

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.

Download your ultimate guide to PCI DSS 4.0 compliance for developers.

Table of contents

View Resource
Interested in more?

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 demoDownload
Share on:
Resource hub

Resources to get you started

More posts
Resource hub

Resources to get you started

More posts