Home > News and Blog

August 10, 2023
by David Goodale

PCI Compliance Version 4: Is Your Business Ready?

(Slightly edited from video transcript for greater readability)

David Goodale:

Hello, David here at Merchant-Accounts.ca with another episode of the podcast. Today we're talking about PCI compliance version 4.0, and what you need to know. Returning is Robert Spivak of Control Gap, who was kind enough to come on a previous episode of the podcast. In that last episode, Robert unknowingly dropped a bit of a bomb on me. He told me that PCI version 4.0 is coming and I didn't even know. If I didn't know, it probably means that a lot of merchants don't know, and I wanted to get ahead of the curve as much as possible and find out what's coming along and what business owners need to be prepared for. Robert, thanks for joining us again today.

Robert Spivak:

My pleasure.

David Goodale:

Perfect. Let's just jump right in. I'm going to start by explaining that the earliest versions of PCI didn't make a lot of sense, especially for small merchants. There were things, I remember as an example, and I'm not like a network systems administrator, there was a question, do you have a DMZ? If you tick no you just failed. But to my understanding, that's something you'd only have if you have like a bunch of servers. You don't need a DMZ if you only have one server. The point that I was making is earlier versions of PCI were pretty broken to the point of being, I think, kind of un completable by small merchants. Since that, it has gotten better. I know we've had three live revisions and the fourth one's coming. I guess my question is for e-commerce merchants in particular, what changes are coming in version 4? I'm hoping in some way it's going to continue to improve, but I'm going to let you answer that question.

Robert Spivak:

Absolutely. Thank you, David you've made some good points. Like everything the standard evolves as things happen, as the world evolves. If you think back to the original versions of PCI, we had nowhere near the types of technology in, the world, the types of e-commerce technology that are being used today. Keep in mind that every standard, as it evolves, will catch up with the ever-evolving technology that exists out there. The challenge is that the world just moves at a much faster pace than any regulatory body can. But we do the best we can for sure. Now from a 3, 2, 1 to 4.0, as you mentioned, as of March 2024 or beyond March 2024, you need to start completing an SAQ (Self-Assessment Questionnaire) version 4. They do still have SAQ A and SAQ A-EP for e-commerce merchants.

Robert Spivak:

Many changes are coming your way and some are more impactful than others. I want to talk about three specific ones that I think are going to feel like they're monumental tasks, but with the right partners, with the right type of QSA (Qualified Security Assessor) that can help guide you. I think they're manageable and they're certainly achievable. It's just a matter of being prepared and giving yourself the lead time to figure out what you're going to do to comply with these particular requirements. The first one has to do with requirements 6, 4, and 3. As you know, with every website, whether you're using an iframe, whether you're using any type of mechanism to build the site, there are usually additional scripts that get added in the background, whether that is tracking scripts for Google AdWords, or advertising campaigns, marketing campaigns Google Tag Manager, are you familiar with any of those? David?

David Goodale:

Yeah. Like Google Analytics to see the traffic that your website's getting and watch, your checkout funnels and all that type of stuff.

Robert Spivak:

Absolutely. One attack factor that has recently been more prevalent is the fact that hackers have gotten wind of the fact that everyone uses Google Ad Managers and analytics and various other tools to be able to do that. They're attacking those scripts, they're using man in the middle attacks in those scripts, or they're modifying them in such a way that they're malicious and they're scraping information, whether that's privacy or PCI data, whether it's an iframe or not. Those things are happening. One of the things that requirements 6, 4 and 3, actually talks about is the fact that you have to ensure as the merchant, that all those scripts are being sourced from a secure place, and that as they're being built and downloaded to the consumer browser, that they cannot be modified. Now, that can be a daunting task. How am I going to do that?

Robert Spivak:

How am I going to ensure that what gets downloaded to an iPhone versus a Mac versus a PC? How am I going to handle that? There are several ways you can do that. There are third-party tools that you can use that would give you the ability to handle that. There are ways to define context security policies that restrict where those scripts can be sourced from, and location requirements or restrictions as to what site that they can be loaded from. Those are some techniques or tactics you could use to be able to meet this requirement. It needs to be validated, and you have to be able to make sure that you're doing it correctly. That may mean you need to do some additional testing. You may need some expertise from either a web organization, or a QSA company that could do that validation for you.

David Goodale:

I have an interesting question on that. If I could cut in, Robert, because maybe you're about to get to the key. I'm sorry for doing that, but so other guests that have come on the podcast have talked about the rise of no-code or low-code solutions. I'll give you an example, perfect example. I have a rental website for vacation properties and I was going to build a calendar functionality program for it, and apparently, I forgot that it's been over 20 years since I was a programmer. Because I started that and I was like, no, this is not happening. I spent like three minutes and downloaded an application, a software platform called Owner Res. I'll give them a plug. I like it. One of the functions they provide is a calendar. They give you a calendar widget, you drop that widget into your website. A lot of websites, they're using the logic of widgets. It could be like a calendar and forms, you know, like contact forms on a website. On an e-commerce website, there could be some sort of shipping logic widget from FedEx. Would this mean that when you're pulling in remotely hosted scripts that are going to be going into your website, you now have PCI steps to address? I'm curious to know if I'm understanding correctly.

Robert Spivak:

You're on the right track in that if those are being drawn in with the collection of cardholder data, you have to be able to inventory on the page, every script, every function, every widget has a description of what its function is and what's the justification for being on that page. If you have a fully redirected page that goes to a third party, a lot of that goes to them to be able to do that. But you need to ensure that you understand what it is. But to your point, if you're building your page and you're drawing that widget that has a payment function, a widget for shipping, you have to be able to document that and keep track of that. It could be a spreadsheet, or it could be something along those lines, but it's a matter of ensuring that you know what functions, what scripts, and what widgets are running within your page that you're presenting to the consumer when you're asking them to pay for something.

David Goodale:

Well, it's so interesting and the old developer in me from a long time ago is saying, this is like PCI scans and is another example of something that forces good habits. Hey, you should probably be patching your Apache a little more often. In this case, you could have a Frankenstein of 10 million scripts on your website you know, on our website we are guilty of this. We had a smooth scroll function. If you're on the FAQ, which is long and you click on it, I wanted it to smoothly scroll down, like quickly but smoothly, scroll down the page, and then at one point we stopped using that, but it's easy for that little JavaScript to live on, sucking up space on your website, which slows it down and all that stuff. This is actually what I would see as a benefit because this is good housekeeping from development standards.

Robert Spivak:

You're right. That is the key it's about keeping clean code. It's about keeping it optimized. It's about ensuring that you don't have dead code. I'm a developer by history as well. Keeping chunks of dead code if you might use it having commented code or code that's been commented out but still lives on that particular page. Those are all common coding hygiene things that should be done. They get forgotten over time because we get busy, we are building sites very quickly, or in a larger organization, they may have a team of people that are working on that. Having the right tools to able to ensure that you understand what is running on that page and is it necessary. It goes back to if you want to think of nothing better than principle least privilege, what are the functions that need to be on my page and are they secure? The main reason why is because that is an attack vector. Now again, hackers become creative, they become smarter and they evolve their attack vectors. This is now a new type of attack that we're seeing more and more of. The standard is evolving to address the fact that dead code can be leveraged against you.

David Goodale:

Perfect. What about on the scanning front? Is there anything changing there? Like is the scan getting updated or new rules there?

Robert Spivak:

That's a great point David, and it segues to my next main point that merchants need to be aware of when they're doing e-commerce requirements 11, 3, 2 and 1 which were not required in PCI DSS version 3, 2, 1 are now a requirement in version 4 that requires you to handle ASV (Approved Scanning Vendors) scanning. That means you have to do vulnerability scanning on your site, even if you're redirecting to somewhere else, but your website needs to be scanned with a vulnerability scanner. That could be any of the ones that are out there. You also have to submit your ASV and you have to have your ASV scan completed. There are two different levels to that. An ASV scan is what with used with an approved scanning vendor while just standard vulnerability scanning can be done by anyone. A lot of QSA companies or there are companies out there that are approved scanning vendors and you have to leverage them to be able to run the scans to certify that your site is meeting all the PCI requirements and that gets submitted and recorded so that way you can submit those scans and your attestation of compliance to the card brands or your acquirer if that's the case.

Robert Spivak:

Keeping in mind ASV scans and vulnerability scans have to be done every three months. One of the key caveats is that if your PCI anniversary date traverses March of 2024, as of March 2024, you have to adhere to 4.0 requirements. Let's say right now you're not doing your scanning. If your next scan goes beyond March 2024, you have to be ready to be able to do that. Keep that in mind, especially when you're looking at your anniversary date. When you have to comply or when you have to submit your attestations, you're going to need to ensure that you have your ASV scanning already tuned up and your vulnerability scanning process running already. Now many organizations are doing that early.

David Goodale:

It's interesting to me because what this tells me, and I didn't know that, is that it's going to push more businesses away from hosting themselves. Because a lot of small businesses that use Redirect, they could use shared hosting. I don't get overly technical, but if a scan finds a problem on a server, hey, you're running PHP 7, you need to be running PHP 8. I'm just making an example. It's not an accurate example. The point is, if you need to do something if you're on a shared server and you contact your web host, they might say, we can't just upgrade PHP because all the other merchants on that shared box are using PHP 7. I'm wondering if there will be an effect where this chases merchants away from hosting it yourself, or even like a WooCommerce running on a shared WordPress hosting platform where they can't host it themselves anymore. I'm curious to know what you think about that.

Robert Spivak:

The good news is that most service providers, if they are hosting websites, have had to be doing ASV scanning and vulnerability scanning anyway for years in 3, 2, 1. That was a requirement. If you were a service provider, you couldn't get away from that. To your point, merchants may choose that they want to have someone just take that headache away from them and manage the website, manage all the different components of it, and do that. You're again, taking your requirements and you're putting it on your service provider, which is going to be important for requirement 12 and 8, where you have to define your responsibility matrix and ensure that your provider is fulfilling these requirements in 4.0. What I expect to see throughout the next 6 to 12 months is that there's going to be a bit of a disconnect between service providers that haven't completed their 4.0 and merchants that want to complete their 4.0. There may be some discussions back and forth. I say that politely as discussions because we know what those will be. But ultimately there's going to be some discussions around, hey, why aren't you doing this for me? Or I want you to do this for me. In some cases, those service providers are going to have to change the way that they operate to be able to comply with what their merchants require.

David Goodale:

Now I have what I think is an interesting question. There's a shopping cart platform that you may not be familiar with or you might, it's called Foxy Cart. Are you familiar with it?

Robert Spivak:

Not myself personally. No.

David Goodale:

That's okay. But I love Foxy Carts so much, it's not like Shopify, it doesn't have 10 million users, but I love it because it's ultra-flexible. It's a shopping cart platform intended for developers or people that have some programming skills. This is about to make sense in a second. If you were going to do a website selling comic books, I'm just making that up. There's a lot of skews and a lot of stuff, and you're a developer. You and a marketer have a real vision about how you want it to look. You have an idea of the checkout flow, maybe there's a subscription basis for new issues coming out. Like there's a lot of functionality and you're like, I don't want to reinvent the wheel. There's a lot of custom stuff that I need, but I don't want to write add to Cart logic.

David Goodale:

I don't want to integrate with FedEx, I don't want to program my shipping logic. I wish I could drop those parts into my pages. It's kind of coming back to the headless e-commerce thing. If you have a Foxy Cart store, you could have a static and almost static HTML website, and then you're just going to drop a block of code where you want your items to appear. Foxy Cart populates that into your page. When they click checkout, it comes up on an overlay, just a modal window or whatever you'd call it, an overlay. All of the data, all of your checkout, all of your products, it's impossible for your website to have this information. The checkout flow is handled by Foxy, the emails are handled by Foxy, and it's all handled by Foxy in that window. In that case, what does a merchant scan? Foxy would be PCI level one, they're a service provider. But would they still scan comicbooks.com? I'm curious about the answer to that. If you happen to know it.

Robert Spivak:

It is a good question. Based on the way that the DSS is written today, you would still be required to scan your site because, this will go into the third major requirement that we'll talk about in a moment, is that even though you're using Foxy Cart to do all the components that you're looking for, you are placing that code on your website. If I'm a malicious hacker or a malicious admin and I can modify that code to create that exact copy of a modal that looks like Foxy Cart, I can look and feel and do everything that Foxy Cart does and I can man in the middle of that code so they can look like it's going straight through to Foxy Cart and no one's the wiser.

Robert Spivak:

One of the key things that leads me to is a requirement 11, 6, and 1, which is you need to now have tamper and change detection on your critical files on your website. As we know, some static components of your website should never change, and you should never have any concerns about them. Those are the ones that you need to monitor. That could be some of your core web code, it could be some core functions that you have within your web server because if I can modify those links that point, that code to Foxy cart or a redirect server or to an in an inline frame if I can modify that or corrupt it in some way, I can affect how cart data is being collected. Potentially skim it from your website and you wouldn't know. This is something that in the SAQ A-EP and other standards, or SAQ D, is already a requirement, but it wasn't a SAQ A specifically for e-commerce merchants that would do a redirect or an iframe.

Robert Spivak:

Now you are required to have this, and it could be your third party that does this for you. But you need to be conscious of the fact that your code can be modified without your knowledge. If someone can hack your account and get on your Wix site or your Foxy site or Woo pay or whatever site you're using to host your website on, if they can hack that, they can modify your code and you wouldn't know until it's too late. The idea now is that you need that change detection component to be able to alert you that someone's making changes to your code and then, whether it's of course yourself making those changes or is it someone unauthorized, and now you need to go investigate.

David Goodale:

Is that some sort of script that models or, or monitors the file size of files sitting on your server? I'm going to frame this question. Netflix and Sony can solve this problem. You know, John who has a small business and he sells, you know, $4,000 a month of like hobby stuff. How can he comply with this in a reasonably easy way? Is it possible?

Robert Spivak:

It is very possible. There are tools out there and services that will do that. Normally a change detection tool will take a hash of every file that you tell it to monitor. It will take a copy of the original file that's approved, create a hash value, and it'll compare it regularly. Now that could be live, it could be daily, weekly. You can pick the frequency, which is good. You could do a manual process, but it's very difficult because as your website grows and you may have multiple pages, you may not be able to maintain that level of frequency. But there are a lot of tools out there. Tripwire is one, Carbon Block, and another Waza has capabilities like that as well. There are tools out there and you just have to look for a change detection tool.

Robert Spivak:

I'm not endorsing any of those products. I have seen them used in many organizations, so I'm just mentioning them out of familiarity. But definitely, you can have that. A lot of other organizations are implementing things like what's called VMDR or MDR, which is managed detection and response. In that particular case, it's an agent that runs on your machine or your web server and it'll do that detection for you and it'll either prevent the change from happening or it'll at least alert you and they can come at a reasonable cost that you would have.

David Goodale:

That first one, are they downloading your website and just like making like I said, a hash of the file and they're just monitoring for changes. What I want to know in that case is because I'm thinking like my customers, I don't want to deal with this. That'll, that'll be the response of every single merchant. Yeah, of course. Can they like sign up for a service that costs some small amount of money and they would just get an email alert, hey, we noticed that this page changed on this date and this time. Then would that qualify as what they're looking for?

Robert Spivak:

Absolutely. That again, at that point then you have a service provider who's doing that service for you. You've taken that requirement, you've given it to a service provider that's going to do that. I expect that many hosting providers will have that as part of their service built in so that they can say, yes, we do the scanning for you, we do the change detection for you because it's just part of the service and it's something they have to do anyway. They'll be able to extend that into their merchants of course for a nominal feat.

David Goodale:

Interesting. In that case, just one more, just because you're such a font of knowledge of picking your brain. My homepage has, no not my homepage, a different homepage. Thinking of a page that just has a date on it for some reason and the date updates every day, is that going to break that logic? Because every day when the date changes or you'd be able to work around that because as long as the change was detected when the new day happened, then it would make sense, I suppose.

Robert Spivak:

Well, again, keep in mind that typically changing the date in, in a webpage is a function. That's not necessarily going to be a static value that's changing on that particular page. It'll be something that goes and collects the normal date or current date from the system or from a UTC source or something like that. If you had a static value that you manually change in that file daily, yes, you're going to get an alert saying, hey, this is now changed. Are you okay with that? Normally you want to be doing files that don't change regularly or specific files that you know should not change. For example, dynamically created pages can sometimes be a challenge because they're going to be constantly updated with either new graphics, new pictures, or things of that nature. But there are portions of a page or there are certain functions that you can set change detection on that would be static.

Robert Spivak:

For example, I can monitor the source link to the payment page that I redirect to and that can be a specific function. I can, the widgets that I use and I've downloaded that code shouldn't change. Therefore, I'm going to ensure that I'm monitoring that particular piece of code. Again, it's somebody that has familiarity with web design that can create the specific functions, widgets, and pages that you're looking for and the critical components that you know should not change versus the ones that dynamically have to change because you have to evolve with the changing types.

David Goodale:

Interesting. This is fascinating and I listen, I will bet I'm going to throw a bet out there right now. This is going to catch a lot of merchants off guard. I hope that a lot of people watch us because I just know from my customer base, merchants aren't watching PCI so if the processor, even when the processor alerts them, they're going to best they're going to look at it, ugh, you know, it'll be, ugh, and then I'll look at that later. This is something, I think some service providers could be a good business to be in. You could have a very good, well you do have a very good business to be in *laugh* because I think a lot of people will need help with this. Is anything changing regarding the questionnaire itself? Is it getting more questions, is it getting more streamlined? If, just curious if you have any feedback there.

Robert Spivak:

The questionnaires are a little bit longer because there are new requirements in each one. Each of the SAQs has evolved to have a new numbering system. Where we had the old numbering system, some things have changed. The biggest change is the SAQ D for service providers. That is the largest change that you're going to have. It may not be for most of your merchant base, but it will be for many of the service providers that affect your merchants. The main thing there is that they now have to explain how they validate each of the requirements that apply to them. That's a much more daunting task because it's almost like reporting on compliance without having to do one. That's going to be the biggest change for most service providers for most of the other SAQs.

Robert Spivak:

There will be some additional things that you need to fill out. There'll be more questions to answer. Of course, as we mentioned with SAQ A, there are 11 new requirements that you need to adhere to. Some of them you don't have to deal with until March of 2025. Some you'll have to deal with by March of 2024. The best thing I could advise is to engage a QSA company that's knowledgeable, that can guide you through this process. One of the things that we offer many of our customers is an impact assessment. We'll take a look at what your current scope is, we'll map it to 4.0 so that you have a clear understanding of what that transition looks like so that you can then start preparing whatever processes, changes, or tools that you may need to implement to meet the requirements associated with PCI DSS 4.0.

David Goodale:

I could see that being useful to a lot of people. Definitely. I will say just in this how long we've been going here, we've been going for 25 minutes. I have learned more in this podcast than I have talked to any guest in any other podcast, which tells me how much merchants are going to be learning as well. Is there anything else you want to mention that should be applicable or e-commerce merchants should know about in terms of changes coming?

Robert Spivak:

Just keep in mind that the e-commerce world is cutting-edge. There's constant evolution there, especially with tracking beyond social media platforms. If you're selling on social media, if you're using different functions as you know Twitter or X as it's called now, is certainly impacting a lot of online services, Facebook, WhatsApp, all the meta functions that are happening, and Instagram sales. As you keep evolving your e-commerce world and the way you want to sell to your end consumer, you just need to be mindful of how are you ensuring that they're keeping not only their PCI data safe, but their privacy data. Because Privacy is the next big thing that's coming for everyone. Beyond PCI, you can expect privacy to be the next big thing. I did want to mention that the Portland PCI community meeting for North America is from September 12th to the 14th. If anybody's in the area, you're welcome to come to the show. You can register online at the PCI Council meeting, or sorry the PCI Council website. We'll be there. Control gap will be there and I'm sure there'll be a lot of like-minded people that you can pick their brains and, and have a lot of good discussions around how the next evolution of PCI is going to affect you.

David Goodale:

That's, that's a really good tip. I do have one more question. Rob, you mentioned a few times service providers and merchants. What's the like, let me give you an example though. A web host is a merchant, but if they're selling web hosting to their businesses, is that a merchant or a service provider? Because They provide a web hosting service. I just.

Robert Spivak:

It's a very good question. A merchant is typically someone who has a merchant account with an acquirer or a bank. Now a service provider provides a service to merchants. That could be a web hosting provider. In that particular case, they may be both a merchant and a service provider. It's best to talk to your acquirer or your bank to find out what is it that you need to do or what SAQ you need to fill out or talk to a QSA company that can help navigate that for you. But the biggest differentiator is a service provider provides services to merchants. A web hosting provider, a code review service, a shopping cart provider a supply chain provider. Those are all types of service providers that can be out there. Your telco, whether in, Canada, you've got Rogers and Bell. In the US you have Verizon, Sprint, AT&T. Again, not plugging anybody, but those are all service providers that you would have in your ecosystem when it comes to payments.

David Goodale:

Interesting. Now you have given a lot of good advice on this discussion. Where can people get ahold of you?

Robert Spivak:

Control Gap is the easiest way to get ahold of us. There's a contact form on there. We usually respond very quickly. You can always reach us at pci@concontrolgap.com.

David Goodale:

Perfect. Rob, thank you for joining so much. This was just chockfull of good information. I appreciate it.

Robert Spivak:

Happy to help and support the community and again, looking forward to anybody who can make it to the PCI community meeting this September.

David Goodale:

Thanks, Rob.

---

Need professional guidance?
Contact us for a free one hour consultation.

---