In this fireside chat, Alexa Levine, product marketing manager at HUMAN. Jeff Zitomer, senior director of project management at HUMAN, and Jason Wikenczy, principal of payments and cloud advisory at Coalfire, a QSA company, discussed PCI DSS 4 compliance.
Coalfire is a respected QSA company that recently completed an evaluation of HUMAN security for PCI DSS compliance with version 4 new browser script requirements, known as 6.4.3 and 11.6.1.
View the full webinar here and continue with our Q&A below.
Q: Jason, can you give us a quick overview of these new requirements?
A: Jason Wikenczy
With PCI DSS, the overarching goal is to protect cardholder data across every stage of the payment process, including the client side. Requirements 6.4.3 and 11.6.1 were introduced in version 4 to address vulnerabilities in web-based payment systems, often targeted due to limited control over the consumer's environment, like personal devices.
Requirement 6.4.3 mandates that organizations keep a detailed inventory of scripts running on payment pages, justifying the need for each one to prevent unauthorized scripts that can inject malicious code.
Requirement 11.6.1 is about detecting and responding to unauthorized changes on payment pages, including security-affecting HTTP headers. These headers are critical for browser-server communication. If tampered with, it could expose sensitive data to threats like Magecart attacks, where malicious code is injected into websites to steal cardholder information during transactions.
Q: Regarding security affecting HTTP headers in PCI DSS, Jeff, can you explain how these fit in?
A: Jeff Zitomer
HTTP headers are metadata exchanged between a browser and a server. They include security policies that the browser enforces to protect the payment page. PCI DSS highlights the importance of monitoring these headers to ensure they haven't been altered maliciously or by mistake, like a developer turning off a security control during testing and forgetting to re-enable it.
Sophisticated attackers can also exploit headers to disable other security controls. That’s why tracking and monitoring changes to these headers is essential. One tool you can use is a Content Security Policy (CSP), which allows you to limit which domains your website can interact with. PCI doesn’t mandate CSP, but it’s a powerful tool if it's part of your security posture. The main point is that any security-impacting header must be closely monitored.
Q: Are organizations using a third-party payment service provider different from these requirements?
A: J.Z
The short answer is no. No, they are not exempt. Even if a third-party provider processes all cardholder data, the scripts running on your site that embed that payment page can still access sensitive information. That’s why you must comply with 6.4.3 and 11.6.1, as those scripts can be exploited to steal cardholder data.
Q: What is the deadline for all 6.4.3 and 11.6.1, and what are the consequences of missing them?
A: J.W.
These requirements are considered best practices until March 31, 2025. While they’re not mandatory until then, early implementation is highly recommended.
Early assessment can be used as a tool, so even if you've got controls in place, they may fall short. They shouldn't result in noncompliance because the controls themselves are still best practices.
The lessons learned through that assessment can test the waters, so to speak, and you can apply that going forward. So it certainly helps with better preparation. Now, after March 31, 2025, comes April Fools Day, and whether that's intentional or not, I don't know.
After that date, noncompliance will likely result in penalties, including fines and reputational damage. But beyond compliance, the more significant risk is security. These requirements are designed to protect against attacks, so delaying implementation could expose your payment systems to substantial vulnerabilities.
Q: What is the Coalfire Product Applicability Guide?
A: J.W.
The Product Applicability Guide (PAG) is a tailored assessment we offer at Coalfire. It evaluates a product, platform, or service against specific frameworks or security standards. We assess how a solution aligns with regulatory requirements or best practices, helping organizations optimize technology to meet compliance goals.
This process helps identify gaps and allows organizations to make informed decisions on improving their product or service use. The PAG also clarifies shared responsibilities between providers and customers, streamlining compliance efforts.
Q: What did Coalfire find when evaluating HUMAN's solution?
A: J.W.
HUMAN’s solution takes a security-first approach and goes beyond the PCI requirements, which is commendable. Their focus on continuous monitoring and proactive risk mitigation is particularly strong. The platform’s operational effectiveness also stood out—it simplifies the compliance process and enables clients to meet the requirements more efficiently.
A: J.Z.
We’re excited about the findings, especially since some PCI 4 requirements, like client-side security, are new and challenging for many companies. Our product was developed with expert input, and this validation from Coalfire confirmed that our approach is both innovative and effective. The feedback also helped us refine the product further.
Q: On that note, can you give us a quick overview of what the HUMAN product does and how it works?
A: J.Z.
At its core, HUMAN simplifies compliance with PCI DSS by automating monitoring scripts and headers on your payment pages. Our solution identifies all third- and fourth-party scripts running on your site and continuously tracks any changes. We integrate with existing workflows, making it easier to manage these processes continuously.
We also offer granular control over script behavior. You can allow specific scripts while blocking risky actions, even if they’re not malicious. This flexibility ensures you meet PCI requirements while maintaining security beyond compliance.
Q: Regarding security beyond compliance, what’s the difference between achieving compliance and securing cardholder data?
A: J.Z.
PCI compliance aims to protect cardholder data, but simply checking off requirements doesn’t always guarantee security. It’s possible to be compliant without entirely securing your environment.
Our product helps you achieve both by streamlining the compliance process and providing deeper security controls beyond the basic requirements. This way, you’re not just compliant but also actively preventing threats.
Q: Jason, can you share some best practices for achieving PCI compliance?
A: J.W.
One of the critical themes in PCI DSS version 4 is risk analysis, particularly in script management. The first step is conducting a thorough risk assessment of your script environment. Identify all scripts running on your payment pages, understand their functions, and assess security risks.
This process helps determine the scope and prioritize actions. Factors like data sensitivity, the criticality of the scripts to payment flow, and whether they are third-party or internal scripts also play an essential role. More complex scripts require more extensive risk mitigation strategies.
It’s essential not to get tunnel vision on just the two control requirements (6.4.3 and 11.6.1). These requirements are part of a broader PCI DSS framework, so they should be integrated with your existing workflows, like supply chain management, vulnerability management, patch management, incident response, code review, and developer training.
Another critical factor is documentation—ensure that new processes related to these requirements are adequately documented and aligned with your other PCI compliance documentation. It’s also crucial to involve the right cross-functional teams, including security, compliance, and IT, to make sure everyone is aligned and working together to maintain compliance.
Q: Jeff, what do you think sets apart client sharing and securing the client side?
A: J.Z.
Securing the client side presents unique challenges because it’s essentially outside your control, yet critical for online functionality. Client-side scripts are essential but can also load other scripts or change without notice, often coming directly from third or fourth parties. These scripts bypass many internal security controls and tools, creating potential vulnerabilities.
Our solution simplifies this complex process by automatically identifying all scripts running on your site. After deploying a simple JavaScript snippet, we auto-discover payment pages and inventory all scripts and vendors associated with those pages. This gives you a clear view of your environment, helping you determine what's in scope and what isn't.
With this visibility, you can begin evaluating necessary scripts, which should be removed, and how to handle unexpected changes. We integrate with tools like Splunk and Datadog for incident response and open Jira tickets to streamline evaluations and approvals.
One of the most significant issues with client-side security is that you’ll often be surprised by what turns up on your site, whether due to a developer’s changes or a malicious attack. You can’t realistically pre-authorize every script, so you need to monitor and authorize changes as they happen. PCI DSS 4 emphasizes this point, allowing for real-time authorization rather than requiring everything to be pre-approved.
Securing the client side is different from other areas of security. It requires a mindset shift, and many companies may not have the necessary skill set to fully understand and manage these risks. Our product is designed to bridge that gap, providing the tools and insights needed to manage client-side security without requiring deep technical expertise.
Q: Now, I will turn it over to questions from the audience, so please get them in the chat if you want your questions answered. I'll start with the few we have so far.
Q: How can organizations identify and prioritize critical HTTP headers?
A: J.Z.
For our customers, deploying our sensor on their site lets us automatically detect security-impacting headers. Once deployed, our sensor returns with a list of detected headers alongside the scripts running on your payment pages.
This eliminates the need to manually message developers to ask which headers and scripts are in use. We also provide continuous monitoring for changes, alerting you when something needs your attention so you can decide whether to authorize the change.
For those who aren’t our customers, there are other tools available that offer scanning. However, when evaluating these tools, it’s essential to ensure they cover headers in addition to scripts, as many don’t focus on headers. Headers are a newer aspect of client-side security, so not all tools are designed to handle them.
If you don’t have a tool, you can use developer tools manually. Navigate to the payment page, examine the headers that are being loaded, and identify which ones are security-impacting. You’ll then need to maintain an inventory of these headers and monitor for any changes, even though this isn’t always explicitly stated in the requirements.
Q: Are there headers that might not usually be considered security-relevant but could be, based on specific use cases?
A: J.Z.
Yes, hypothetically, there could be. Out of the box, we monitor the headers our research team has identified as security-impacting, along with those highlighted by thought leaders. But as more QSAs, security consultants, and experts review these requirements, it's likely that additional headers will be flagged as critical based on evolving use cases.
Our infrastructure is designed to adapt to this. We can easily update our sensor to detect and report on new headers as they’re identified. Once detected, these headers are fed into our portal, which follows the same monitoring, alerting, and review process we've built for other security-impacting headers.
Q: A QSA mentioned that if you use an HTTP redirect, 6.4.3 and 11.6.1 don't apply. Do you have any thoughts?
A: J.W.
I’d say it depends. If it's a traditional HTTP redirect, then no, the requirements wouldn’t apply. However, if the redirect is done via scripting, which is possible, then yes, 6.4.3 and 11.6.1 could still apply.
Beyond compliance, from a security standpoint, redirects always introduce a potential risk vector. So, regardless of whether you're compliant or not, you should still consider the security implications of using redirects.
Q: PCI DSS states that authorization could be automated. What are a few guiding principles for that?
A: J.W.
I’d describe it as semi-automated. While the workflow can be automated, there still needs to be human oversight and input. The goal of PCI DSS is continuous improvement and feedback, so even with automation, someone needs to take ownership and ensure a logical justification for each decision.
Machine learning models can help but still require human oversight to ensure everything runs smoothly and decisions are sound. Automation is a tool, but it doesn’t eliminate the need for human involvement.
A: J.Z.
I was glad Jason answered first because my usual response is that while some things may sound reasonable, you still need to justify your decisions to your QSA. The key point is that it depends.
For example, if you’re dealing with a vendor who has an Attestation of Compliance (AOC) and a strong security program, automating some processes might be acceptable. The same goes for well-controlled internal processes related to PCI requirements.
However, the bottom line is that you need to rationalize and justify every decision to automate. It’s crucial that everything aligns with what your QSA expects and can be supported with clear reasoning.
Q: What key metrics should organizations track to measure the effectiveness of their client-side security program?
A: J.W.
The main objective is to track incident metrics to see how well the program mitigates issues. You should monitor where incidents originate—whether from third-party or internal scripts—to gain visibility and assess if there are supply chain management issues.
Metrics around script compliance, such as whether scripts function as intended, are also important. Vulnerability tracking should be part of this process.
Another key metric not directly related to PCI DSS is user experience. One of the biggest challenges with implementing controls like 6.4.3 and 11.6.1 is doing so without negatively impacting the user experience, so tracking this is essential.
A: J.Z.
The question is good, especially when comparing PCI to client-side security. Starting with PCI, one key metric is your script inventory. You should have a written justification for why each script is necessary. This is a great opportunity to do some housekeeping—remove outdated or unnecessary scripts that don’t need to be on your payment page. So, one metric could be the size of your inventory, and ideally, you want to see that number decrease over time.
Another metric is the time it takes to review and close alerts. For example, when a new script is detected or an existing one changes, how long does it take to assess and authorize that change? Keeping track of this time is essential for managing the security process.
You should also track how many "surprise" scripts or vendors appear on your site. Ideally, you shouldn't discover a new marketing analytics script on your site without being informed beforehand. That number should be as close to zero as possible.
For client-side security, you can apply what you learn from PCI. For example, regularly clean up your inventory and quickly address high- and medium-level alerts.
On the user experience side, scripts often enhance the richness and interactivity of your site, but reducing unnecessary scripts can also improve performance. So, there may be performance benefits to doing this cleanup, along with security gains.
Q: Does HUMAN's product also check the integrity of scripts, in addition to inventory checks?
A: J.Z.
Yes, absolutely. We not only auto-discover and track the inventory of scripts, but even after a script has been approved or authorized, we continue to monitor it for changes in integrity. What we focus on is behavioral integrity. This means that we won't generate unnecessary alerts if a script changes but doesn’t trigger any behaviors that could indicate an attack.
Scripts often change dynamically, and a simple hash check would result in constant alerts for every minor change, leading to alert fatigue. If you had a team manually reviewing each alert, they’d click "authorize" repeatedly without assessing the risk. That’s why we monitor for behaviors that could pose a threat rather than just flagging every change.
That said, we can build that feature if there’s demand for a traditional hash-based integrity check. It’s easy for us to add, but we believe that monitoring behavioral integrity provides much more value in terms of both security and compliance. However, if enough people prefer a hash-based approach for compliance needs, we’re open to implementing it.
For more on PCI DSS compliance, check out HUMAN here.
