Compliance Unfiltered is TCT’s tell-it-like-it is podcast, dedicated to making compliance suck less. It’s a fresh, raw, uncut alternative for anyone who needs honest, reliable, compliance expertise with a sprinkling of personality.
Show Notes: A Few Key Requirements of PCI 4.0 to Understand Before the Deadline
Quick Take
On this episode of Compliance Unfiltered, we’re giving a deeper understanding of some critical elements of the new PCI v4.0 Standard, in advance of the upcoming deadline. Adam covers some high-level challenges PCI pros can expect, while also charting a path to success relating to web application firewalls.
Have questions about the payment page scripts requirement 6.4.3.? Well, you’re not alone. Curious why this requirement even exists? All these answers and more on this episode of Compliance Unfiltered!
Remember to follow us on LinkedIn and Twitter!
Read Transcript
So let’s face it, managing compliance sucks. It’s complicated, it’s so hard to keep organized, and it requires a ton of expertise in order to survive the entire process. Welcome to Compliance Unfiltered, a podcast dedicated to making compliance suck less. Now, here’s your host, Todd Coshow, with Adam Goslin.
Well welcome in to another edition of Compliance Unfiltered. I’m Todd Coshow
alongside the falling snow in your compliance snow globe. Mr. Adam Goslin, how the heck are you, sir? I’m doing good. You reminded me of something, my wife actually shot me something over, like northern Michigan, go and see elk in their natural habitat, and you go on a sleigh, and blah, blah, blah. So yeah, you just, you triggered me on that one.
I like it. I like it. Well, today we’re going to talk about some triggering things, and that is the increasing number of differences in PCI 4.0, and a few of the PCI 4.0 requirements to understand in advance of the deadline. Now, with the increasing number of organizations heading towards PCI version four, what are some of the high level challenges that companies face on this path? Well, for the folks that haven’t had the opportunity to move toward four yet, actually, this would be a good opportunity to let listeners know. One of the cool parts about the functionality of the TCT portal is that For those organizations that have a 3-2-1 track up and running we can swing up a 4-0 track we can you know set up live linking between 3-2-1 and 4 so they can kind of see what of their prior track is going to map over to 4 Where do they have holes where they don’t have you know map things in. So it’s really helpful from that perspective, but you know for the folks haven’t gone there yet You really need to start thinking about you know getting, getting that moving You know the time is you know time is passing and you will be need to be If you’re having to sign your AOC after March 31st of 2024 you’re going to have to sign a version 4 AOC. So, you know, it won’t be, you know, it won’t be easy to get your, you know, your arms around for because there’s a, there’s a good number of new requirements. There’s some, some substantive changes to old requirements and they can be confusing. So, you know, we’re going to take a look at a couple of those, you know, for, you know, for the sake of today and kind of break them down for you.
Love that. Now let’s start with the payment page scripts requirements. 6.4.3. So, what are the requirements for this one? Well, if you’re outsourcing your, you know, online payments to third-party payment processors, then you’ve got a new requirement to adhere to. 4 is, is ensuring that you are validating or verifying the scripts that you have running on the pages that you serve to the consumer. You know, so, you know, according to 4, the payment page scripts that are loaded and executed in the web browser need to have methods for verifying the scripts that are, that are authorized and ensuring you, you have validated the integrity of the, of those scripts. You know, also managing and maintaining, you know, managing and maintaining an inventory of any of those scripts, providing justifications about why you’ve got those scripts. You know, so, you know, an example, an example of this requirement would be if your, your website is passing customers along to a third-party page for payment processing, you know, to initiate that, that sort of a process when your customers are going to pay the, your platform is basically telling the user’s browser to, you know, pull up that payment page from the chosen third-party site. The third party will go through, run payment processing, and then direct, that redirect the customer back into your website once everything is wrapped up. So, in, in. your e-commerce platform needs to have a way to confirm that these scripts are really the scripts that you intended to push them toward and the integrity of them is there, that type of thing. In short, you need to be able to verify your platform intended to send the customers to that specific third-party page and that they were successfully sent to the correct page. Because if something fails in that mix, you need some form of appropriate response action, redirect back to your platform, a pop-up message. We’re looking to try to ensure that the clients are going to their intended target. Now, why is it that that requirement exists? You heard my pause there. I’m curious. The purpose is to protect the consumer from bad actors that could otherwise redirect or hijack the payment processing, sending that consumer or customer to their own unauthorized look-alike site. When this happens, it allows the bad actors to collect a slew of credit card information. The customer isn’t any of the wiser. They get sent from your page to what they believe. Actually, in many cases, they don’t even know. But they get to a page where it’s asking for credit card information. They dutifully go in and fill it all out, which, of course, passes all this information to the bad guy. If they’re really slick, then they’re going to take that entry and, similarly, pass it along to where it should have gone in the first place. And, effectively, they’re sitting in the middle, gathering up this information unbeknownst to the consumer until all of a sudden their statements start lighting up with unauthorized purchases on their accounts, etc. The notion of the inventory and justification for scripts, etc., that’s really an act to force the organization to take their part in the responsibility for appropriately managing, validating, approving what it is that the target organization’s intending to leverage and why.
Now, how does one go about meeting this requirement? And, I guess, who’s responsible for which aspects of implementation? Sure. So, there’s a couple of different things. This is a relatively new, well, it is a new requirement for four. And, you know, organizations are just starting to get into it. a number of people popping up with solutions type of deal. But PCI doesn’t prescribe some specific tool or process for this validation. But I can envision several possibilities. It just depends on who you’re working with and how they’re going to go about implementing it. But one option could be some type of an encrypted handshake, two-way that goes from your site to the consumer’s browser that comes back and does a validation, et cetera, and to where effectively you’ve got a built-in check, double-check as the person is passing across. Other options that I have heard organizations talking through is leveraging the web server configuration itself to limit the approved scripts or approved destination locations that the user could be passed to. More at a systematic level so that if somebody got in there and managed to change the code for the direction of the push but had not gotten to the configuration of the web server that you’d have another way to be able to tag those and to learn on those. A third possibility is leveraging some alerting on your web server for any configuration changes where you’ve got file integrity monitoring pointed at the code for the website where it will do an alert to the administrators if somebody’s gone in and done some form of a code modification to the destination location for where that consumer would otherwise be pointed. At the end of the day, one of the big recommendations that I’d have for any organization, certainly if you’re lucky enough to have a PCI consultant, then go ahead and hit them up, talk options through what’s gonna work best for your organization. As with anything, there’s gonna be many ways to approach it, if you will. Certainly, if you have an assessor, then making sure that you’re walking that through with them as well. Oftentimes, it’s a good idea to start with a consultant. That way, you can have almost an internal conversation about how do we wanna go about doing this and options and pluses and minuses. Once you’ve got your established path and before you start implementing it, that’s the right time to go and hit up your assessor to go ahead and wave this in front of them. I always like to, especially with new requirements, I always like to go to the assessor, make sure that they are comfortable with the chosen resolution approach. Because at the end of the day, they’re the ones that has to go off and sign off on it. You don’t wanna have… of the entire thing implemented only to find out that, oh shoot, they really wanted to also see this or here’s a reason why this wouldn’t work, whatever. So it just makes things a lot smoother and cleaner to kind of go down that path. And certainly for any of the listeners, if you don’t already have a kick-ass assessor or a consultant that can help you with navigating your compliance waters, TCT would be more than happy to give you some directional guidance on kind of cool folks to work with you from that perspective.
Now, excuse me. One of the questions that I’ve gotten, we talked a lot about the hows, if you will. You were talking earlier about the responsibilities. The reality is that it’s your responsibility as someone subject to PCI compliance to adhere to those PCI requirements, but you definitely need to work with your vendor to agree on those details and mutual responsibilities. They may have code snippets that you can go ahead and leverage to implement on your end. Certainly, they ought to have a responsibility matrix for their implementation and what elements are your responsibility versus shared versus theirs, that type of thing. Since each vendor is different, make sure that you’re collaborating with your consultant and assessor on your end, but also that you’re collaborating with your vendors to make sure that you’ve successfully implemented the appropriate approach. You need to go ahead and head down that path, so you make sure you hit the mark, if you will.
Now, moving on to another requirement to understand, what’s changing relating to web application firewalls? I know that’s a big sticking point for a lot of folks. Yeah, well, it used to be. Web application, some of the folks were like, web application firewall, new? No, it’s not new. It was in the 3-2-1 standard, but it was in there as an option. Effectively, organizations could go through and have an alternative manner or mechanism to validating or vetting the security of their web application. There were a number of ways to be able to do that, or you could go ahead and put in place a web application firewall. I’m mentioning it. He, I’m mentioning it now because it will be a big deal for some organizations. You know, the approach for requiring a web application firewall is not mandatory until 3 31 of 25, however, you know, as you’re, you know, as we’re about to go talk through, it’s going to take you a minute to go ahead and get this one in place.
You know, I really want organizations to take this one seriously and enough time to appropriately get it implemented in advance of the, of the deadline. You know, PCI four is going to require you implement an automated technical solution that continuously detects and prevents web-based attacks, you know, AKA web application firewall. So until 3 31 25, you could do the manual review or an automated code review, et cetera, or you could use the WAF, but in version four, that WAF then becomes, then becomes mandatory. So, you know, if you weren’t already implementing a WAF under your PCI DSS 321, then you definitely need to, you know, need to start, you know, start heading down the path of, you know, of looking at this particular requirement. And you’ll understand why in a minute.
Now, for those listeners that don’t already know what is a web application firewall, how are these typically implemented? And, you know, I guess any development ideas to pass along as well? Deployment ideas, is that what you’re gonna say? I’m, I’m very, very, very, very, very, very, very, very. All right. Yeah, cause I’m, I’m, I was just kind of reading between the tea leaves here. So the, the web application firewall, what is it? It’s a, it’s a system that sits in front of the web application. It’s effectively reviewing the incoming traffic. The web application firewall allows expected traffic to pass through and then block suspicious traffic. It generates logs. It sends out alerts. all that fun stuff, you know, but effectively, it’s looking at the patterns of the inbound traffic and ensuring that they meet the, you know, they’ve already been approved or blessed as approved traffic coming through. Now the web application firewall, what folks that aren’t intimately familiar with it already won’t know is, there’s typically three different modes and I’ll kind of walk through each of those. So first off, there’s training mode, basically. In this mode, the web application firewall is observing all of the, you know, traffic coming in that enters the web-based system. It’s collecting information so they can learn how to identify the expected web traffic. So, a user enters their username and their password, clicks login, we expect to see that traffic. Once they’re in and they go and click on the dashboard or click or update their account settings, you’d expect to see that traffic. So the WAF basically will sit there, observe and collect any information of traffic that’s coming through. When you’re training the WAF, typically you’d turn it on in that training mode for several months. You want it to collect up lots of information and data around user behavior, traffic it expects to see all that fun stuff, you know, and eventually you’ll go in and you’ll look at that information that it collected and start going down the path of designating expected versus unexpected traffic. So when you pass from the training mode into what we’ll call warning or alerting mode, after you’ve gone through that training and then you switch it into warning mode, in warning mode, the web application firewall will start sending alerts every time it’s observing something that it believes is unexpected behavior. So in that transition between the training mode and the warning or alerting mode, one of the things that will be done as far as the configuration of the setup is looking at the traffic patterns that had been received during training mode and effectively noting these are all of the ones which we expect, you know, type of thing. These are the ones that we don’t expect. So when you turn it on into warning mode, it’s basically almost look at it as a test of do we have everything correct? In other words, is it alerting on traffic it should have expected?
So where would I typically see something like that happen? Where I typically expect to see something like that happen is let’s say there was some element of infrequently used functionality on your website that didn’t happen to get touched during when you were in the training mode. Now, all of a sudden, I’m in warning or alerting mode, and somebody happens to hit that for the first time. To the web application firewall, this is brand new traffic. I’ve never seen this traffic before, and it’s going to go raise its hand. Say, hey, I’m seeing traffic that’s trying to do fill in the blank. Is this expected or not type of thing? It’s a way for you to run, I’m going to call it in a safe mode. It doesn’t actually stop any traffic from going through. It doesn’t take any action on the traffic that’s being seen, but it’s effectively allowing you to run in a pseudo full operational mode type of deal. It’s a really good exercise for organizations to go through, and again, do that for a period of time. Now, the one thing that I’ll say about both the training mode and the warning slash alerting mode, It’s going to take a while for you to run in a pseudo full operational mode type of deal. It’s going to take a while for you to run in a pseudo full operational mode type of deal. making sure that you are deliberately going through and doing kind of your, hopefully you’re an organization that has an end-to-end regression test that will touch every piece of functionality. You definitely wanna go in, you wanna exercise that in training mode. You wanna go through and do it again in warning and learning mode. You want the WAF to have all of the appropriate traffic. The third mode for the web application firewall is something that we’ll call blocking mode. So in this mode, the expectation is, is that the WAF is now trained well enough that you can go ahead and turn it on and tell it, you know what, if I didn’t expect this traffic, then go ahead and block it, type of, legit is just gonna straight block it. So that way, and this is really where you want your WAF to be under normal operations, because you want it blocking any nefarious traffic that’s coming at your website. So when somebody is attempting to leverage SQL injection or cross-site scripting or something along those lines and passing that through with the web requests or trying to get to one of your, one of your config settings, whatever it may be, you want it to just drop that traffic kind of right out of the gate. That is an important element as well. So yeah, I think that covers it from a high level about kind of what they are, how they work, all that fun stuff, but the one thing I would say, Todd, in summary, you know, on the WAF, this to get it up, running, functioning properly, et cetera, it is a lot of testing. It’s a lot of, you know, kind of leaving this system on over a period of time to make sure you’re seeing it. This isn’t something I can basically whip on on Monday and call it done. You know, if you’re going to do it properly, which is the reason why I’m encouraging, you know, the listeners to go ahead. start looking at this one start making the game plan and whatnot as of right now we’ve got the better part I’m gonna call it the better part of about a year and a half you know or so you’ve still got plenty of time no reason for anybody freak it out but yeah I would definitely look at this one sooner than later.
Parting shots and thoughts for the folks this week Adam. Well I want to you know kind of go over a couple of you know kind of important tips if you will you know so we talked about the need for you know going through exercising all of your functionality you know all of your functionality when you’re in training and alerting mode you know so that you can build the repository of the you know kind of the traffic signatures that you’re going to need you, you don’t want to turn on blocking mode and having legitimate traffic getting blocked that said excuse me And we also talked about, you know, making sure you’re hitting even rarely used functionality. You know, one thing that that organization should consider is, you know, sometimes you’ve got configuration settings within your system, which will enable and disable alternate functionality. Hopefully that’s in your regression test. But think through things like circumstances like that, where, oh, shoot, we didn’t test this circumstance where I had this bit flipped this way, yeah, which may expose some additional features or functions from within your system. Also, don’t forget about your web-based API functionality that maybe only a couple of handful of clients use, but it’s all kind of behind the scenes as it relates to the mainstream mainline use of your application. You know, so, you know, don’t forget about that as well. The other piece that I would that I would give as a real strong, you know, kind of tip, you know, as it relates to this particular topic is, you know, when you don’t forget that you’re going to need to have an internal process for the additional training that needs that your WAF is going to need as you make enhancements to your application. So make sure as you’re going through your training mode and your warning slash alerting mode, make sure that you also integrate some application layer change control during that process so that you can think through what exactly is it that I’m going to need to do in what order so I can get those new signature profiles loaded up to the WAF and not accidentally blocking the brand new functionality that you just told all of your clients about. Yeah, there’s, I’ll tell you what, there’s, there’s nothing that sucks more than, you know, than forgetting that part, you know, and everybody kind of throwing their hands in the air. Whoo, we got the WAF it’s in place. Yay. And, you know, then all of a sudden we do change control and some new functionality and everybody says it’s blowing up on them. It’ll be a real quick trip, but keeping in mind the requirements we’ve been talking about on this particular pod, they need to be implemented by March 31st to 25. So don’t let too much time slip by. Remember that it’s gonna take months of training and configuring and process changes at Saturday to get through your WAF. So I really want to make sure that the listeners kind of keep that in mind. It’s real easy to get tied up in the day by day, tied up in the deadlines getting pushed from the execs, but make sure that these items are items that kind of get onto your development plan and they don’t keep getting pushed off because you definitely don’t want to be one of those organizations that needs to go tell your customers you’ve lost your PCI compliance because you weren’t proactive enough.
Indeed. And that right there. That’s the good stuff. Well, that’s all the time we have for this episode of Compliance Unfiltered. I’m Todd Coshow. And I’m Adam Goslin. Hope we help to get you fired up to make your compliance suck less.
