How Does Payment Security Work - Ep 66

How safe is payment security? What are the payment system cyber security solutions? 
This week's guest is Dan Fritsche, CISO at RSI Security. He has security and compliance expertise that spans over 20 years. His experience is across multiple industries, but in this episode Rob and Stan explore his experience in the payment security area.

Glossary of terms used in this episode:
PCI SSC – Security Standards Council

PCI DSS - Payment Card Industry Data Security Standard

PA-DSS – Payment Application Data Security Standard

PCI SSF and SSS - Software Security Framework/Secure Software Standard

PCI Secure SLC - Software Life Cycle

PAN – Primary Account Number

SAD – Sensitive Authentication Data

SPoC - Software based PIN entry on COTS

CPoC - Contactless Payments on COTS

CDE - Cardholder Data Environment

Voltage SecureData Payments

Follow or subscribe to the show on your preferred podcast platform.
Share the show with others in the cybersecurity world.
Get in touch via reimaginingcyber@gmail.com

Transcript

[00:00:00] Dan Fritsche: You know, I would've said in the past, PADSS was built on top of a network security standard, which had some inherent problems because you're trying to look at an application from a network perspective, and so this clears all that up. It refocuses, like I said at the beginning, on the way. that application security is done differently today than it has been in the past, and it allows for the development process to be looked at as well.

[00:00:29] Rob Aragao: Welcome to the Reimagining Cyber podcast, where we share short and to the point perspectives on the cyber landscape. It's all about engaging, yet casual conversations and what organizations are doing to reimagine their cyber programs while ensuring their business objectives are top priority. With my co-host, Stan Wisseman, Head of Security strategist, I'm Rob Borrego, Chief Security strategist, and this is Reimagining Cyber

[00:00:52] Rob Aragao: So Stan, who do we have joining us for this episode?

[00:00:53] Stan Wisseman: Rob, our guest today is Dan Fritsche. Dan is currently the CISO at RSI security and [00:01:00] has security and compliance expertise that spans over 20 years. His experience is across multiple industries, but today we're leveraging his experience in the payment security area to talk to him about that.

[00:01:10] Stan Wisseman: Dan has assessed and influenced standards and compliance regulations including again, one of the key ones we're gonna talk about today, the payment cards industry data security standard, also known as PCIDSS, HIPAA, GDPR, NIS, and others that he's influenced. Dan, it's great to have you on the podcast.

[00:01:29] Stan Wisseman: Is there anything else you'd like to add about your background with our list for our listeners? 

[00:01:33] Dan Fritsche: Yeah, well first, thanks for having me. I think probably what's most relevant is my application security background and. Specifically in around 2008, I started doing PCI stuff in the PABSS program.

[00:01:46] Dan Fritsche: So have been actively involved in that in various ways over the years with PCI and into this new  SSF software security framework that we're gonna be talking about. 

[00:01:55] Stan Wisseman: Speaking of which you know, the PCI Security [00:02:00] Standards Council implemented some changes and back in October, 2022.

[00:02:06] Stan Wisseman: The PCI Secure Software framework and we're gonna throw another acronym at our listeners, the SSF, and we'll be, you know, using that freely throughout this episode, but it went into an effect back in October. So what exactly is the PCISSF and how does it work? 

[00:02:24] Dan Fritsche: Yeah, well basically it's PCI’s new framework.

[00:02:27] Dan Fritsche: And they kind of designed it specifically to address the need for kind of a more modern approach to secure development and how applications are used for payments and, you know, how that impacts credit card usage. So they broke the new standard into two different sections. The first one is focus actually on the, the development of the software, which

[00:02:46] Dan Fritsche: was kind of embedded in the, the standard previously. And, and the new, the other component is more akin to the old PADSS, which is the secure software standard. And that's focused specifically on the application. And then they both have [00:03:00] what they call objectives, which, you know, previously we called standards.

[00:03:03] Dan Fritsche: It's basically a similar thing. And you know, they also have a process for validation of those objectives. And then they also have like PADSS, the ability to be listed on the SSC website. The PCI website once the validation is complete. 

[00:03:17] Stan Wisseman: And you said PADSS , what does PA stand for?

[00:03:20] Dan Fritsche: That stands for Payment Application Data Security Standard.

[00:03:24] Dan Fritsche: Okay. 

[00:03:24] Rob Aragao: Does that mean that the PCISSF is going to be replacing the Payment Application Data Security Standard? 

[00:03:33] Dan Fritsche: Exactly. So the PADSS program officially closed. I think Stan mentioned it earlier, October. That was October of 22. And then the SSF program got started. It was actually published in 2019 and was available starting in 2020.

[00:03:47] Dan Fritsche: But really you know, it's, it's just now starting to be commonplace. So it does replace it, but it's got a lot of differences, which, which is what we're here to talk about. 

[00:03:55] Stan Wisseman: So is the SSF, again, looking at the scope of what this applies to, [00:04:00] is it for all payment software being developed and is it now part of the PCIDSS for companies that are internally developing their own payment software?

[00:04:10] Dan Fritsche: Yeah, those are great questions and there's a lot, a lot to answer that. So to start, the software security framework, SSF applies to anything that PABSS applied to before. That's the easy one. So whatever had PABSS needs to have SSF again. Right? As time has progressed, PCI’s been releasing what are called modules.

[00:04:29] Dan Fritsche: So there's specific types of software. So there's a core module that applies to anything that goes through SSF, and then there's the first module called module A that is about account data protection. So that one kind of applies to pretty much everything. And then eventually they came out with module B, which is specific for terminals.

[00:04:49] Dan Fritsche: So like hardware, devices, POI, point of interaction devices that, that need to, to meet the standard. And then the third module that they added more recently is the web [00:05:00] software. So anything that uses internet technologies, those kinds of protocols, those kinds of languages to initiate electronic payments in general.

[00:05:09] Dan Fritsche: To get back to your other question PCIDSS specifically, if someone develops their own application in-house, we would call that a bespoke piece of software. So in the past, under PADSS, it was never even eligible to be reviewed under PADSS however. Oh, okay. Yeah. The new standard allows for it to be reviewed under that as optional.

[00:05:30] Dan Fritsche: The only difference is, is that is one of the few that still at this point doesn't qualify to be listed, so it can still go through the process. It just doesn't get submitted to PCI officially. But the good news is, is that's valuable because then the organization has the ability to say, Hey, we've done this, we meet this.

[00:05:47] Stan Wisseman: why do it if you 

[00:05:48] Dan Fritsche: can't be listed? Yeah. It also simplifies their DSS . Right. So in theory, under PADSS, when there was no SSF program, It would get reviewed under their PCIDSS, which meant [00:06:00] generally speaking, that only a QA that probably didn't have an application background would look at it to see if it met some basic requirements. It never had validation. 

[00:06:09] Stan Wisseman: And just pausing, cuz again, this is a, a very heavy acronym episode. Can you explain what a QSA is? 

[00:06:15] Dan Fritsche: Yeah, QSA is a qualified security assessor mostly to, to do the PCIDSS, which is basically the network standard. Their network. They'rethat's a certification you get through PCI to be able to do a P C I D S assessment.

[00:06:32] Stan Wisseman: And you were previously a QSA as well, right?

[00:06:34] Dan Fritsche: Right. I was a QSA and then a PAQSA. And, the PAQSA validation, you know, that that title or certification was for specifically applications. So now Gotcha. They've separated that, which is really interesting because before you had to be a QSA in order to be a PAQSA.

[00:06:51] Dan Fritsche: Which was network to application, right? Mm-hmm. Well, now you don't have to be a Q S A. They have a separate, they've separated the program. It's actually more difficult than it used to [00:07:00] be for other reasons, but it, it's not as closely intertwined. 

[00:07:05] Rob Aragao: So, so they're getting more granular  is what I'm hearing in essence, Dan 

[00:07:08] Dan Fritsche: And they're, they're getting more specific, right? So, you know, I would've said in the past, PADSS was built on top of a network security standard, which had some inherent problems because, you're trying to look at an application from a network perspective. And so this clears all that up. It refocuses, like I said at the beginning, on the way that application security is done differently today than it has been in the past.

[00:07:30] Dan Fritsche: And it allows for the development process to be looked at as well. So to your point, segmented and focused on better. 

[00:07:37] Rob Aragao: So for  merchants as an example does the credit card payment software, you know, that they would purchase, have to be validated? Under the PSI security software standard or SSF in this case?

[00:07:47] Dan Fritsche: Yeah, the software security framework. Either the, the software security standard specifically for an application. So technically that question has always been up to the card brand. So that's Visa, MasterCard, American Express, Doscover and [00:08:00] even JCB. And actually recently China Union Pay as well. So in the past they, they, some of them would post that if you're going to use an application, it has to be listed

[00:08:10] Dan Fritsche: under PADSS. So at some point, several of them, not all of them, said that you have to either do PADSs or SSF. And so now that implies SSF only because PADSS and some of them are working on maybe still making that official, but their previous requirements applied. So any new applications under that are, that are getting developed have to meet PCISSF.

[00:08:35] Dan Fritsche: The previous ones under PADSS eventually have to get revalidated. You can still use them as long as they can still support the PCIDSS standard, but with the new 4.0 standard for PCIDSS, that's gonna become more and more difficult over time. To be able to leverage a PADSS they will need to move to a, an application that's validated under the new SSF standard.

[00:08:57] Stan Wisseman: So, Dan, when you're describing the  [00:09:00] PCIDSS earlier you mentioned it was divided into the core as well as other modules like the account data protection module. Are all the modules out or are they expecting to have new ones roll out as well?

[00:09:13] Dan Fritsche: Yeah, there's likely to be more. You know, if I had a crystal ball, I'd probably retire if I knew all the ones and, and could capitalize on that, right?

[00:09:21] Dan Fritsche: But sure there will be some more. Some of the things, good examples of what didn't used to exist is now you can actually validate STKs and APIs. So those are software development kits, those are basically kind of a, an an underlying component for an application that other people can then develop around.

[00:09:39] Dan Fritsche: That didn't used to be allowed. And, and now you can do that. So there's a lot of new things out there that never qualified under PABSS. 

[00:09:48] Rob Aragao: I guess if my company is one that's developing these different applications, right in, in support of the payment card industry in general, is this, in essence putting that firm requirement in place now that my solutions as I go to market have to be validated [00:10:00] for them to be actually used?

[00:10:01] Rob Aragao: Because this kind of, this is you were talking about, ri, we're painting this kind of broad stroke that here's what we're recommending and ultimately it sounds like it's gonna become a requirement. Like 

[00:10:13] Dan Fritsche: Yeah, I mean basically it comes down to the definitions that PCI has created for payment applications.

[00:10:18] Dan Fritsche: So payment software, specifically software that stores processes or transmits payment data. Then to define that is data is created or captured or exchange specifically for the purpose of conducting electronic payment transactions. And that definition is a little bit different than it used to be under PABSS.

[00:10:39] Dan Fritsche: So what I just stated is kind of the new way of doing that versus the old way. So it's required. Again, that goes back to the brands. They're the ones that ultimately require whether or not they have to do it, but if it fits this definition, they're pretty much are going to need, to meet it at some point.

[00:10:58] Stan Wisseman: Again, this came out in October. Are the brands starting to put out requirements that you've heard that are on the streets as far as what they're doing? 

[00:11:09] Dan Fritsche: Yeah. I mean, some of them I think have, and, and previously I think they added SSF to the PADSS. So that one is the one that applies, the one that I haven't seen yet

[00:11:19] Dan Fritsche: and I need to go look again, but this, the development one, we haven't talked a lot about that. We've been focused on the application security, the software security standard itself, the other half of that is what's called Secure SLC or Software Lifecycle. So that's for the developers who are doing it.

[00:11:36] Dan Fritsche: And so that one has still, always been optional. I'm kind of waiting for that to become mandatory. So again, I, I would not be surprised if at some point that becomes a requirement. In fact, another interesting thing that I recently learned, talking directly to PCI, some of the other standards that exist are going to point to it.

[00:11:54] Dan Fritsche: And so some of the other standards, like there's a one that's for mobile. I won't give you that acronym cause we've had too many [00:12:00] already today. But that mobile standard is going to point to software security framework potentially. So there's more than one way that this could end up applying to software developers if they're attached in any way to payments for credit cards.

[00:12:14] Stan Wisseman: One of the things that was in the PCISSF that I didn't recognize as far as a way in which they characterized requirements, it was object-based approach to requirements. So what does that mean? 

[00:12:28] Dan Fritsche: Yeah, it's, it's objective based. So it came out that actually kind of existed some from some of the other standards, but basically the best way to explain it is a quick example. So in PADSS like the DSS, to do a password. The requirement was seven characters and alpha numerics, which meant literally the word password with a capital P. would be fine. Yeah. Which is ridiculous. Right? Which is a terrible baseline, but it's a baseline. Right? Right. So then, so that's, that's a [00:13:00] requirement. So the new requirement is something like 12 characters, right. And alpha numeric so longer, that helps a little. Right. But it's still, that is a specific bare minimum.

[00:13:09] Dan Fritsche: Instead, an objective would be generate you know, passwords that meet certain security standards or better is authentication, right? So make sure that you use secure authentication practices. So that's the objective. The hard part about that is then the definition of that objective is not specific to, you know, seven characters and alpha numeric.

[00:13:27] Dan Fritsche: So then you have to have a mature risk program, and this actually applies a lot more to the DSS than it does even to the SSF, but it's the same idea, right? So the idea is you're meeting the objective, but then you have to define that objective and justify it. And so only the more mature organizations are really able to do both of those things well.

[00:13:44] Stan Wisseman:, And you're justifying it to the Q S A that's doing the assessment?

[00:13:49] Dan Fritsche: Yeah, I mean, you're meeting the objective, right? So if you've got an environment where, you know, you don't need to have 12 characters enough, you know, most of them need more than that, right? Mm-hmm. But there's a lot of [00:14:00] nuances to that. Ultimately, you know multifactor authentication is what you're gonna want, right?

[00:14:04] Dan Fritsche: Right. And ultimately, in my opinion, you would want it to not have passwords. You'd wanna use two factors. And not include the password factor, because passwords are just inherently not a secure method, period. Right. So get rid of them. 

[00:14:16] Rob Aragao: On that kind of thinking, take a step forward. You know, here we are, we're going from PDSS with all the acronyms to SSF.

[00:14:23] Rob Aragao: Okay. So if I'm a company that you know, obviously is delivering payment applications and they were validated under PADSS, I guess I assume your recommendation is for them to get moving towards the SSF. But well, one, what do you recommend there, but two, is there gonna be kind of a grandfather period for them?

[00:14:44] Dan Fritsche: No, I mean, if they wanna release new software, it has to be done under the SSF. So yes. If they haven't been looking at it, you know, obviously, like you said, the strong recommendation is to get with a SSF assessor. So you know, you know, get, get, at least start with advisory, you know, [00:15:00] we do advisory in that space.

[00:15:01] Dan Fritsche: Right. I'm, I'm kind of excited to, it's kind of what I did previously in another career is built the PADSS, so I get to do that all over again. But some of my recommendations are I actually am a little bit hesitant to recommend PADSS companies generically, simply because they're gonna have that same mindset.

[00:15:18] Dan Fritsche: It takes a lot to switch and stop thinking the old way and think the new way. Not that it can't be done, I'm sure it's entirely possible, but kind of a fresh approach to how do you approach objective based controls and how do you approach this new way of thinking that is different from what PADSS was, is something worth thinking about.

[00:15:39] Stan Wisseman: From the customer perspective, you know, what does an existing compliant customer need to do now or, or in the near future?

[00:15:45] Dan Fritsche: Well, if, if by customer, meaning like a merchant or somebody who's leveraging a PDSS application they just need to see that they're, the software that they're using is gonna be validated under the SSF standard, so they don't have to [00:16:00] worry about the assessment process.

[00:16:01] Dan Fritsche: Right. The assessment process is for those who sell the application and those who develop the application, those are the two has of, of SSF. For somebody that goes through the network standard that gets a PCIDSS assessment they want to make sure that their application vendor, whoever that is, is gonna have an SSF listing if they don't already.

[00:16:20] Dan Fritsche: So they need to look at, you know, Hey, when do we need to replace our software? A lot of time, that is, a lot of times that's tied into their hardware as well. You want to do that kind of stuff all at once. And then, you know, is it using the latest stuff that's gonna be under the new software security framework.

[00:16:34] Stan Wisseman: So I guess a final question, are these set of changes that are being made by PCI going to adequately address today's threat landscape for against payment systems?

[00:16:48] Dan Fritsche: Well, it's kind of like saying is anything ever perfectly secure, right? I mean, Can it? I think it does. I think it does a better job of doing it than PDSS did.

[00:16:59] Dan Fritsche: I think it has [00:17:00] the ability to be more flexible. PCIDSS certainly does with 4.0. The flexibility there is amazing. It's an entirely different topic, but that's a good thing. Can it be misused? Absolutely. Right. Can you still deploy it in a way that screws up your security. Absolutely right. I think it provides more availability and, and better options.

[00:17:20] Dan Fritsche: Does it guarantee it? You know, never gonna say that as a security professional. 

[00:17:25] Rob Aragao: Not surprised. So Dan, thank you for very much for coming on and sharing, you know, what we're seeing and what you're seeing out there. You've been doing this for a long time, right? You've got great experience.

[00:17:34] Rob Aragao: You're, you're an SME in this space and to, to hear this evolution is obviously very positive. And again, I, I think it's, it's, it's good. I think people need to, as you said understand that it's here now and it's time for them to get moving. So people like you can obviously assist them with that. 

[00:17:48] Stan Wisseman: And I think we'll add a, a list of acronyms in the show notes just to help people out to navigate through this episode.

[00:17:54] Stan Wisseman: But that, you know, again, you, it's so natural for you, Dan, to, to roll off your tongue. Rob and [00:18:00] I are not as initiated in the payments security space. That's right. So even I was struggling with all these different acronyms.

[00:18:07] Dan Fritsche: Yep. After a certain point you can't get rid of it even if you want to. So yeah, thanks for, thanks for having me on board.

[00:18:14] Dan Fritsche: It's been great to, to talk about this and yeah, happy to help however I can. Excited to kind of be back in this space. 

[00:18:22] Rob Aragao: thanks for listening to the Reimagining Cyber Podcast. We hope you enjoyed this episode. If you would like to have us cover a specific topic of interest, feel free to reach out to us and you can find out how in the show notes.