to be honest i'm trying to convince a few of them to come on let's do it because i really want to do one uh but yeah so far no avail unfortunately

well i mean we're obviously we're impartial with our advice and as much as it might seem like we'd like to do one if it's not the best thing for the client then there's just no point in doing it and it's it it's kind of the same with compensating controls we try and avoid compensating controls because the standard is written the way it is for a reason the standard is chosen as that approach because it works when it's tried and tested so doing something other than what's the tried and tested approach is always fraught with extra risk no matter how you approach it yeah um and i haven't done a lot of compensating controls over the years most of them have been sort of they tend to end up cookie cutter right they tend to end up well because we couldn't do this last year because the technical limitation the technical limitation hasn't changed so nothing's changed so it's just the same uh and it just although you revisit it nothing changes the technical limitation is still in place so you're still using the same control you're still compensating in the same way and it still produces the same results And so you end up with a sort of, you almost template it, especially if it's a common technical control.

I don't remember in the days gone by when you had Linux where you couldn't remove the Linux admin account.

Yeah, you couldn't remove that account from Linux, but you could disable it.

And so you had to do a composite.

And it was sort of, even I think the example example compensating control that was filled out by the council was that Linux admin account one.

It was their example of how to fill one out because it was such a common thing.

Yeah, it's a

Then, then if you give them the ability to, you know, pick and choose kind of frequencies more than what's already allowed in the current version, I'm not sure how well that would bode.

Yeah.

'Cause I think when it comes to well-established frequencies that are, are, are set in the standard, like quarterly, um, you know, the, uh, vulnerability assessments being quarterly every 90 days, that's established by industry standard on the basis of, you know, how frequently new vulnerabilities appear, which is something that the council can easily look at in the wider Security landscape and go, "Well, in general, vulnerabilities come out this frequently, so it really should be quarterly." There's no real reason for them to increase flexibility in those.

What I think we're more likely to see is them find activities that get a frequency that didn't get it before, either because they were- they were continuous or because they're newer or they need more discrete intervals.

So the change in requirements introduces new requirements to have frequencies rather than ditching old frequencies for flexibility where they, they don't need to.

For me, it depends on, um, the technology itself, uh, hardware.

Yeah.

I, I would look at, you know, the, the, the, the sector that technology is in.

Yeah, so happy

about it.

The areas I always poke around when I'm doing scoping workshops, both merchants and for service providers, is to poke around the unusual stuff, right? Most businesses are very familiar with their payment process.

We take payments over the phone, we do this, we use that software because they do it all the time.

But where you've got sort of odd, out-of-band transactions that don't fit standard processes, refunds, or where somebody rings up and needs help, or they send an email in because they can't be bothered and stuff.

So it's those obscure ones you talk to the the customer service people or the other people in the business and go are there any other instances where you do a payment that's not standard and and those are the way you should dig um that's where you'll find your issues

or a level two service provider, you're entitled to do it for yourself, but have some professional context I think would help.

Yeah, to explain, like you said, the terminology is the key one because PCI SSC, the council is quite adept at taking industry terminology and repurposing it to mean something completely different within the standard.

As a QSA, actually, from one QSA to another, are you satisfied if they provide you with a network diagram with the transaction flow? Does that satisfy you or would you go deeper?

So generally speaking with most clients, validating a process flow to show that the process in no way captures card data, so like a redirect mechanism and everything else.

There's no way for that process flow to take in card data, so it couldn't possibly get in via that method anyway.

So you could say, well, with certainty that, you know, because there's no, the form on the website doesn't send the card data to the website etc the place you then look is logs and you look at a log and go well there's no entry in the log where it captures that information within the standard format of a log that it captures and so there's no way for car data to get into the environment there's no way it can be stored in the logs there's no need to go any further than that However, if the process flow is more complex or there is a way that card data comes into their environment so they are transmitting it or processing it in some way, then you probably need to look deeper into application logs, into memory storage, into what it's doing with that data and where it's sending it and where it's encrypted and where it's not.

But for the vast majority, I don't tend to dig deeper than validating the process flow cannot bring card data in in the first place.

So in the event of a security incident, what actions by a service provider most strongly influence a QSA's assessment of readiness and maturity?

there's well it's an interesting one there's a lot of gray area when it comes to investigating insecurity incidents because when you've got split stuff between service providers and merchants the merchant wants to see the logs and or do the investigations and the service provider doesn't want to allow them access to the systems because you know there's securities to consider there's um you know sensitive data there's other clients data to consider there's a lot of discussion when it comes to investigating serious instances and the responsibility surrounding what should or should not a service provider allow their merchant access to.

There are some requirements around drawing those lines in the standard, but it's still an area where you end up with, we want to see this because it's been a breach.

Can I just ask, when we talk about serverless in a PCI setting, what do we actually mean, and how does this differ from how cloud providers usually describe it?

Uh, so it's usually pitched as platform as a service these days, whereby you use one of the big cloud providers, like Amazon, Google, or whatever, et cetera, but you don't, uh, have any input into the infrastructure.

The infrastructure, the servers, the traditional stuff that sits underneath it, you don't see any of it.

You simply put your code in, put your applications in, and, and, and you run it.

And a lot of, certainly some more of my clients these days, are now using those environments to put their PCI applications in, either their, either their web pages, their payment e-commerce environments, or, or whatever other systems they've got that are handling card data.

Normally it would be in a cloud environment where they have to build servers and set up virtual networks and stuff.

They don't have to do any of that now.

Right.