The following is a transcript of the PCI DSS 4.0 Decoded panel - it has been minimally edited for clarity.
Gabriel (Gaby) Friedlander: Thank you very much everyone for joining us today. I have to say that I share the same mission with all of you regarding secure coding and what Wizer is doing for helping companies achieve this. Unfortunately, too many companies develop code, and security is treated more like a bug than something that needs to be prioritized from the beginning. As I usually tell people, you wouldn't want to live in a house that was built negligently. You want safety measures to be implemented from the start.
Regrettably, when it comes to apps, many treat security like a bug. It's only addressed if someone raises a flag, and then they go and fix it. This happens even with the biggest apps, making it easy for vulnerabilities like XSS to go unnoticed. So, hopefully, we can change this mindset.
David Mundhenk: Absolutely. I've been evangelizing as an app tech guy for quite some time. During my tenure at Coal Fire, I was part of the application validation team and used to conduct secure code training. I also have a background in pen testing. I can assert with great conviction that most application security assessments and pen testers primarily focus on the server side. However, they might recoil in horror if asked to examine the client-side web browser.
Unfortunately, the entire attack surface and paradigm related to the client side have been neglected until now.
Gaby: Yeah, there's so much I can talk about here, and I'll do that in a second. Notably, those XSS instances are usually not detected by the SOC since they run on the client side. It can linger there, invisible to the security team for a considerable amount of time.
Gaby: Before we delve into this, something I'm passionate about, let's start at a high level. Let's first discuss who needs to comply with PCI and how one can determine the need for compliance. For instance, as a startup, nobody might have informed me about it while I'm writing my code. How do I ascertain the need for compliance, and who informs me about it? Lee, I believe you touched on this when we were offline. Would you like to kick off the discussion on this topic?
Lee Quinton: To determine if you need to comply, the first and foremost question is: Do you receive, store, process, or transmit cardholder data in any way? If you handle cardholder data, you're likely to be on the hook for compliance at some point. As a merchant, your bank should have reached out to you, and even new merchants will typically receive a PCI pack to guide them and outline their responsibilities.
For service providers, it's a bit more dynamic as they are more directly accountable to the card brands and may be working with acquiring banks. However, that's usually the point where compliance becomes a consideration.
Gaby: So, if nobody informed me about the need to be PCI compliant, am I in the clear? Does that mean I'm off the hook? Anyone else want to weigh in on this?
Jeff Hall: No, you are still legally liable. Problems often arise with managed security services providers and anyone in managed services. If you're managing firewalls, network servers, etc., and you've never discussed with the customer what data they use, whether it's PCI, HIPAA, or any other, you need to understand your customer to determine if you're in scope.
Especially with PCI data, if you're handling devices that could potentially come into contact with PCI data, you're required to be compliant, just like the customer. Unfortunately, many managed service providers ignore this and say, "Until someone tells me, I won't take any action." The consequence is that a breach occurs, leading to lawsuits, and everyone claims they weren't informed. Ultimately, it was your responsibility to find out, not someone else's obligation to tell you.
Gaby: If we were to run a poll, how many MSPs do you think actually reach out to their customers and follow the recommended practices? Perhaps around 10 percent? So, we're facing a significant issue. Essentially, the current situation is that if nobody informs me, I might choose not to address it and claim ignorance. I might say, "They didn't tell me, so I'm in the clear," but in reality, I am legally bound by these obligations.
Ben Rothke: Yeah, I mean, there was a famous case in tort law about 75 years ago involving a tugboat. To keep it brief, they were found guilty because they didn't follow appropriate due diligence at the time. In 2024, companies may not know about PCI, but they should have someone on their staff knowledgeable about security, overall privacy, data processing, etc. Ignorance is never an excuse.
If companies throw up their hands and say, "We didn't know about PCI," they'll be found derelict. Lawyers love cases like that because they see dollar signs everywhere. One nuanced point about PCI is that it's often referred to as a law or regulation, but it's not. To be a law or regulation, it has to come from Congress or a government agency. PCI is a contract from the card brands.
If someone is non-PCI compliant, they won't go to jail, but they're likely to go out of business. In 2024, with the state of security, unless someone is living in a cave, judges will show no mercy.
Gaby: Okay, so here's another scenario. As a startup or a merchant using Box or Stripe, I might think, "I'm just swiping cards through Stripe, it's not me directly." They are my service provider for processing cards. Do I even need to care about PCI?
Jeff: Well, let's discuss Square real quick, as it's still commonly referred to as Square, even though the parent company is Box. Square has an interesting relationship with Visa, being its largest investor. Square focuses on small-level, level four merchants and doesn't impose compliance on them. They rely on Square's technology. In case of a breach, Square becomes the point of recourse because it's the hairdresser or the person selling art at the fair relying on Square for a secure point of sale solution.
This situation applies to many other providers in a similar position. However, it changes when you operate a website with more than 22,000 transactions annually. In such cases, banks will insist on PCI compliance.
Gaby: So, you're suggesting that... Here's my take on why this happens, right?
I have a form on my website, and I'm using Stripe. Even though I'm not directly processing the payment, there could be vulnerabilities like XSS or a keylogger injected into the page hosted on my website. For instance, if I used an iframe improperly, it could lead to keylogging credit card information. So, having a secure checkout page is crucial, regardless of who processes the payment.
The question is, does Stripe provide guidance on this? Are they informing users about the proper implementation to ensure compliance?
Jeff: Okay, if you sign a contract with Stripe, you'll set up a merchant ID tied to a bank. The bank will send you a packet of work containing MasterCard and Visa's rules of operation. You're supposed to read the extensive tome from each of them, understanding all obligations. Unfortunately, many companies may have received this packet but are unaware of the need to comply with PCI.
Gaby: A lot of businesses might have received the packet and simply shelved it without realizing the importance of PCI compliance.
Jeff: Exactly. The CFO typically signs the packet, and often there's a lack of communication to other departments like developers or IT. This oversight is part of the problem.
David: Those contracts have a lot of fine print, and people might not read the entire document.
Jeff: An important point is that you can outsource responsibility, but you can never outsource liability. Even with third-party MSPs, the vendor has to deal with liability. Cloud providers clearly outline responsibilities in matrices, but the manuals often go unread.
Gaby: So, from what I gather, most businesses are not fully PCI compliant, is that correct?
Jeff: I would say no one is compliant 100 percent of the time. Some organizations are close to it, operating at a high level of compliance, especially those using P2P and tokenization. While breaches may occur, the risk of cardholder data being released is low. The real risk lies with banks and service providers, as they are obligated to handle the data.
Gaby: Got it. Another question before we move on to PCI 4 and other topics. As a startup, if I'm SOC 2 compliant, I might think I've covered a lot and paid a significant amount for the compliance process. So when they tell me about PCI, I might say, "I'm good. I followed the NIST framework, and I'm secure." You were laughing. Do you have anything to add? Why is it not enough?
Jeff: According to the PCI Council's rules, it's not enough. Let's go back to the SOC 2 example. I'm a recovering CPA with almost 30 years of experience in the industry. While SOC 2 offers good coverage, the depth of detail required in PCI is much deeper. In a SOC 2 meeting, people may think it's done after 40 minutes, but I, as a QSA, will delve into another hour of work with much greater technical detail.
We discuss topics that SOC 2 auditors can't address due to qualifications and technical limitations. We explore firewall configurations, open ports, review frequency, and distinguish between outbound and inbound traffic. The level of detail in PCI is significantly more profound than in most other security frameworks.
Gaby: This brings me to another question. If I don't necessarily need to comply with PCI, is it still worth trying to follow and comply with it? Is there value in doing so, even if it's not a strict requirement?
Ben: Gaby, can I backtrack 30 seconds to the SOC 2 question? SOC 2 is essentially a report card. Sometimes it's all As, and sometimes it's all Fs. You have to read that SOC report. Strictly speaking, you could construct a SOC report stating that you have no security, don't care about it, and only hire clueless people. Although no AICPA firm would sign off on that, you can have a SOC report indicating a lack of concern for security, potentially making data public. Companies may have a SOC 2 emblem, but if they never read the report, they might miss the fact that the company doesn't prioritize security.
David: Addressing your question, Gabriel, I currently have a client with an extremely remote possibility of encountering cardholder data due to the nature of their business. Despite this remote chance, they're still concerned and have decided to undergo PCI assessments. While they also engage in SOC 2 and other assessments, they find value in PCI DSS as a metric to ensure they're doing the right things.
Lee: As far as security baselines go, PCI DSS is very solid. The 12 requirements cover a wide range of aspects, aligning with other frameworks like NIST, CMMC, and more. PCI is prescriptive, providing clear guidance on what needs to be done for each control. Despite not handling credit card data, following PCI best practices can help maintain a good baseline of security across an organization.
Gaby: Absolutely, whether it's PCI data or not, it's still data. Following security best practices outlined in PCI, regardless of the specific data involved, is beneficial. It provides clarity for those who may not have extensive knowledge, allowing them to follow established guidelines rather than guessing.
Jeff: I recently presented to the local ISACA chapter, explaining why the PCI DSS and secure SDLC standards are among the best for securing sensitive data. They are prescriptive, providing guidance on how to architect an environment for information protection and how to assess its effectiveness.
Gaby: The PCI Council with PCI 4 mentioned increased flexibility and the ability to customize. What's happening? We've been discussing the detailed nature of PCI, and now it seems like we're moving towards a more abstract approach.
Jeff: The customized approach was introduced to accommodate concerns about password standards, like not having to change passwords every 90 days and having shorter passwords. While it sounds good, working on PCI 4 without a customized approach has made me realize that this flexibility comes with a significant cost in time and dollars. Implementing it is not a simple task, and it can add around 75% to an organization's time and cost. So, while you get flexibility, you need a solid justification to your management for going down that road. It's more about reliability.
Lee: For large organizations with mature processes, experienced personnel, and well-tuned tools, the customized approach may fit well. It allows meeting the intent of a defined control in a different way. However, if you lack these elements, it's better to architect something meeting the defined control. PCI is based on people, process, and technology, and achieving the numbers on defined controls is often easier than creating something entirely new for the customized approach. If you don't have existing measures meeting the control's intent, it becomes challenging and costly to justify why you can't meet the defined approach, increasing assessment and ongoing business costs.
David: If you decide to adopt a customized approach for a specific control, it requires conducting a targeted risk assessment. This involves empirical validation to ensure that the proposed control provides equal to or better protection than the original requirement. The process demands a detailed, logical approach and extensive documentation. As a QSA, I've encountered challenges with compensating control worksheets, especially in contentious situations where clients argue that their existing controls offer sufficient protection.
Gaby: Shifting our focus to the broader picture, apart from the customized approach and flexibility, what other significant changes are present in PCI?
Jeff: A notable change, as you mentioned earlier, concerns firms using iframes. Specifically, those relying on SAQA. Many of these companies believed that SAQA exempted them from responsibility, thinking they could run a subpar website within an iframe without consequences. However, this misconception is addressed by introducing the requirement for ASV scanning. Now, companies utilizing SAQA will need to undergo ASV scanning to ensure their website's security. As David highlighted, breaches can occur, leading data to be skimmed off by malicious actors, and in such cases, the responsibility falls on the organization, resulting in potential legal repercussions.
Gaby: Here, we've encountered challenges with MSPs, particularly when they need to communicate with their customers. Now, we're delving into the realm of XSS and similar issues. Many MSPs and IT professionals may not be well-versed in these areas. Who will raise the flag and notify the company that their R&D needs to improve coding practices?
Jeff: Typically, it's the bank or law enforcement that steps in when they discover data leaks. They approach the company, alerting them to the issue, and then it becomes a fire drill to identify where and how the breach is happening and how to remedy it.
Ben: It's crucial to understand that PCI doesn't necessarily involve cutting-edge security practices. Instead, it emphasizes basic best practices for information security, privacy, and data security—essentially good security practices for 2024. While it might be expensive and cumbersome, PCI covers fundamental aspects of due diligence.
Gaby: As a startup, launching our product with a focus on functionality, we're keen to start accepting online orders. In a small company with developers handling DevOps and cloud infrastructure, the R&D manager may not be inclined to learn about PCI compliance. Who will inform us about the need for PCI compliance?
Jeff: It's akin to a 10-person startup expecting guidance on not sending racist emails or inappropriate behavior from HR. Similarly, the responsibility for PCI compliance falls on the IT person, and due diligence in 2024 dictates that the bank will eventually request documentation proving PCI compliance.
David: Security and compliance differ; being secure doesn't guarantee compliance and vice versa. Developers should ideally incorporate security into their software development lifecycle and go through security training for developers. While they might not have heard of PCI, connecting to a processor will prompt the bank to demand an attestation of compliance.
Lee: By 2024, experienced developers touching payment card flows would likely have heard of PCI. When setting up a merchant ID, the bank sends a packet containing operational regulations, including PCI requirements. Even smaller merchants will eventually face PCI discussions with their account representatives, given the prevalent concerns about identity and credit card theft.
Ben: Facebook has become a cesspool of credit card fraud, with little concern for the issue due to their focus on ad revenue. Learning from PCI, it's advisable to always have a spare credit card for online purchases, given the prevalence of breaches and businesses on platforms like Facebook primarily existing for identity theft.
Gaby: Bringing it back to our initial discussion on client-side vulnerabilities, David, focusing on 6.3.4 and 11.3.1, which address client-side JavaScript and HTTP request headers, what do you believe is essential or ideal for development teams to handle client-side vulnerabilities?
David: Addressing client-side vulnerabilities is relatively new, particularly with requirements like 6.3.4. It emphasizes practices such as maintaining an inventory of scripts, conducting risk assessments, and having business justifications. The challenge lies in the dynamic nature of this architecture, requiring continual assessments whenever changes are introduced. The difficulty for development teams is gaining visibility into the client-side web browser, a crucial aspect that needs attention.
Jeff: The challenge parallels what we see in security, where people tend to focus on vulnerabilities with higher CVSS scores. It's crucial to understand that even low-level vulnerabilities, when chained together, can lead to significant security risks. Scanners often miss these nuances, emphasizing the importance of understanding how vulnerabilities can be chained to exploit systems.
Gaby: Wizer offers comprehensive solutions for secure coding, including security training for developers, secure code labs, and Capture The Flag (CTF) challenges tailored for developers. Secure coding is a skill that developers need to learn, as it doesn't come automatically with years of experience. The difficulty in CTFs for developers highlights the gaps in understanding, emphasizing the need for dedicated developer security training.
Jeff: The story of security personnel overlooking low-level vulnerabilities and their potential to be chained together is akin to the challenges faced in secure coding. Many security professionals fail to grasp how seemingly minor vulnerabilities can lead to significant breaches when combined. This underscores the importance of understanding the intricacies of vulnerabilities and their potential impact.
Gaby: Reflecting on PCI guidelines for developers, there is optimism about the emphasis on training developers to write secure code. While some aspects may seem optimistic, such as reliance on automated tools, the overall focus on education and secure coding practices is a positive step forward.
Lee: AI is powerful, but it currently lacks an understanding of context.
Gaby: Exploring PCI, I've come to appreciate its specificity, particularly in addressing development aspects. The depth of coverage in PCI is noteworthy, and I haven't seen many other compliances reaching such levels of detail.
Jeff: I recommend checking out the Secure SLC standard created for PCI, offering valuable guidance on secure code development applicable to any sensitive information.
Arthur (Art) Cooper: Shifting gears a bit, considering the evolution of breaches, how do you think the frequency compares between the late '90s and now?
Gaby: I'd say there are more breaches now, given the heightened awareness and prevalence of incidents.
Art: Interestingly, the frequency of breaches was higher in the late '90s. Hacking was a trend, with hackers showcasing their exploits but not necessarily using breached data for financial gain. The shift occurred when California introduced SB 1386, compelling organizations to disclose breaches. This transparency led to increased awareness.
Jeff: Adding to Cooper's insights, credit card transactions with American Express used to be less common due to rampant breaches in the '90s. The paper receipts on the cash register posed a risk, and Amex's stringent fraud management prompted businesses to avoid accepting it. The Wild West era of breaches has transformed, and PCI standards have played a pivotal role in saving the payment card industry.
Lee: The emphasis on web-related breaches is evident now, with a decline in major payment card breaches. It's crucial to move away from storing unnecessary cardholder data and focus on securing web environments.
Art: Point-to-point encryption for merchant devices remains essential. Encouraging businesses to avoid retaining cardholder data and embracing secure practices has contributed to reducing payment card breaches. The focus has shifted to web security, emphasizing the need for continuous vigilance against evolving threats.
Gaby: We've received some insightful questions from the audience, and while we have limited time, let's address a couple. Is the web client-side payment page part of the CDE scope? In 2025, yes. PCI standards are evolving, and it's crucial to adapt.
Jeff: Regarding the entire website's compliance, it's recommended to isolate payment code from the rest. Most organizations understand this, but compliance extends to everything if not isolated.
Jeff: Documentation is key. Open-source tools may assist, but comprehensive documentation, especially on third-party scripts, is crucial.
Lee: For script integrity, evaluate validation methods like subresource integrity. Content security policies for iframes are essential. In larger builds, dynamic pages may require sophisticated tools.
David: Understand the scope beyond scripts developed in-house. Marketing scripts, third-party tags, and their sources must be considered comprehensively.
David: For service providers, compliance is expected and required. Merchants and MSPs can gain a competitive edge by showcasing PCI expertise.
Jeff: Merchants are expected to comply, but MSPs with PCI expertise can stand out in the market.
Jeff: PCI DSS 4.0 will impact service providers and banks the most, as they still handle significant data. Tokenization companies also face challenges.
Lee: Tokenization companies hosting card data are potential targets. Preparing for PCI DSS 4.0 is crucial for these entities.
Jeff: It's the merchant's responsibility, regardless of the platform. Shopify provides compliance documentation, but merchants need to ensure adherence and obtain an SAQA.
Gaby: Thank you all for sharing your insights. If there are any final thoughts or ways to contact you, feel free to share.
David: Thanks to Wizer for shedding light on this topic. I appreciate the privilege.
Lee: Start targeted risk assessments now, even if not mandated until next year. Annual risk assessments won't be required after March 31st this year, emphasizing the need to showcase compliance through targeted assessments.
Gaby: A big thank you to all our speakers. If you want to get in touch with them, please reach out to pcidreamteam@gmail.com. Thanks, everyone!
The Definitive Guide to PCI DSS v4: Book authored by PCI DreamTeam available on Amazon
PCI Secure Code Training: Wizer's comprehensive training for developers helps them master security fundamentals, bolster their secure coding skills, and learn to recognize and defend against diverse types of attack.
Email questions to: pcidreamteam@gmail.com
Connect with our amazing panelists on LinkedIn!