Listen to learn about one organization's experience shifting from PCI DSS 3.2.1 to 4.0.
With the required shift from PCI DSS version 3.2.1 to 4.0 upon us, many organizations are concerned about their ability to successfully meet new requirements.
Martin Kenney, Senior Systems Engineer/Admin, IT at InfoSend, sits down with Host and Principal Security Analyst Jen Stone (MCIS, CISSP, CISA, QSA) to discuss:
Resources:
Download our Guide to PCI Compliance! - https://www.securitymetrics.com/lp/pci/pci-guide
Download our Guide to HIPAA Compliance! - https://www.securitymetrics.com/lp/hipaa/hipaa-guide
[Disclaimer] Before implementing any policies or procedures you hear about on this or any other episodes, make sure to talk to your legal department, IT department, and any other department assisting with your data security and compliance efforts.
Hello, and welcome back to the SecurityMetrics Podcast. My name is Jen Stone, and I'm one of the principal security analysts here at SecurityMetrics. Very excited to have with me today, Martin Kenny. Martin, will you please tell us a little bit about yourself and your organization?
Sure. I'm a network engineer here with InfoSend. Been here for about five, six years now, I think it is. Ended up coming in as just a Linux administrator that needed somebody to come in and got involved with PCI and SOC audits here. And over the last year, two years, have really gotten involved with it, looking at different frameworks as well. Yeah. And trying to get as much information in as I can about all the different frameworks.
Do you know what? It's interesting from my perspective seeing people who are like you, technologists, you know, sysadmins and network engineers, people who are, you know, expecting to be really hands on, technical in their careers who then are said or are told, hey. We need this risk assessment done, or we need you to respond to PCI. We need you to and all of a sudden, you start building a body of knowledge in the compliance world that you might not have expected to be part of your job.
Is that Not my job.
Is that because how how how did that come to you? Is it you're just you didn't say no, or are you in is it an interest? Do have a small organization?
I I guess it would be a just an interest in learning new things, and the security aspects of it are applicable Yeah. From from a technical perspective. But also, we need somebody to do it. It makes everybody's job here easier if somebody can help guide it and has the knowledge behind it on what the expectations are.
So, that's that's where I ended up coming to it.
I didn't wanna do it. Yeah.
And I hear that from people in your position a lot. Is that why am I doing this? I don't wanna do this. But over time, it becomes something that is actually a really valued skill.
I've seen the benefit of me going out and really digging into these things over the last last year. We're seeing a lot more of our customers wanting different compliances, whether it's an actual audit and certification or self assessment and or applying of a framework. Nice.
So broadly applicable to what you do and and helpful to your, the people around you.
So another thing that was a little bit different about InfoSend is you chose to do a 4.0 audit when, technically, you still could have done a 3.2.1. And and a lot of organizations are holding off to the very last minute before they have to do 4.0. What what made you decide, hey. We're gonna go ahead with a 4.0?
Because we're going to at some point. Why not why not do it now? Yeah. That way, we do it now if there's something that needs to be implemented that wasn't implemented correctly due to a change, we have time to go ahead and fix it.
That's basically what it was.
Yeah. Great. So did you find it to be a big stretch moving from 3.2.1 to 4.0?
Not really. It were there are definitely differences and definitely things that needed to be implemented ahead of time, but it wasn't that big of a deal, in order to put it in place.
So in terms of new technologies, new configurations, new requirements that had to be, put in place, is there anything that took a long time?
The research and the requirements, it was more around the targeted risk assessments and look and looking for a framework that we could incorporate so that it would be the same for everything in order to comply with that portion of it. You with four in a lot of the different sections, they wanted targeted risk assessment for this, targeted risk assessment for that, and that was where we, we needed to find something.
Right. And and that's a I think that's a change that a lot of people aren't yet fully aware of because in the past, one of the requirements was did did you do a risk assessment? Yep. And and it could be it was sometimes I'd get risk assessments that were just not really helpful in terms of PCI, but they for sure were a risk assessment, and they for sure were that organization. And so I think what the council wanted to do was have a risk assessment that was actually more meaningful and supportive of the security stance of an organization rather than, hand us any old risk assessment. So so the so the targeted thing came about.
Mhmm. Yeah. And I think that the the risk assessment portion of it, we were doing risk assessments, and they were things dealing with credit card, dealing with, payment processing, but it was dealing with other things throughout the business. But it was more of a broad risk assessment rather than specific and targeted to the things that are required with 4.0.
So what what did you end up going with to help you with that risk assessment? Because that's a that's a question I'm getting a lot, from people right now. What does that mean?
CS well, you wanna know what we ended up going with?
Yeah.
Yeah. So we ended up using CSF, the the framework there, and adding to it and kind of making it our own.
They end up having a a pretty laid out template Mhmm. In order to in order to use, and we were compliant with most of it, implemented the ones that we weren't. And then for the targeted risk assessments, just added items onto that template for specific for those ones that needed to be targeted.
Oh, that's a great way to do it. I I'm a big fan of the NIST CSF. Mhmm. I think it has broad applicability.
Excuse me. Especially, there's a lot of organizations that bridge the PCI HIPAA world.
And the NIST CSF is a recognized security practice from HHS, which is important to follow. You know? So if you're kind of in an organization that needs to satisfy both of those, the the CSF really helps, provide that that framework. So Yeah.
And during the research, found that, there were multiple lawsuits that have been and that's been used as a, defense of the company that they went through and did a risk assessment using this, and it ended up being reasonable what they end ended up implementing, and they had it documented so they were able to win those court cases.
Oh, interesting. So it gave them a defensible position.
That's a that's a good piece of knowledge. So when you do these targeted risk assessments, do you find that that you have enough information from because the the targeted risk assessment means you're looking at something specific that might bridge the business and technology because it's not just technology. It's great. The point I'm trying to make is that sometimes you have to bring in people from the business. And how was that done?
Did you have did you lead that effort as well, or did someone else? Yeah.
It was all it was, I was the point person and would end up going to other people in the company in order to get that information.
Nice. Okay.
It wasn't yeah. It wasn't it wasn't a big deal as far as, needing different people in the team, trying to head it up.
So a couple of the the requirements that people are, I I think, most worried about, and I'm not your assessor, so I don't know if this is even applicable to you. But, if you have a, public facing web page that takes in credit card data, then a lot of a lot of people have an ecommerce site that's in scope and they need to manage scripts on a page. Is that something that you had to work work with?
Yeah. We ended up dealing with, we ended up yes. That's yes.
We ended up dealing with that. And there was a, there was actually a program that you guys offer for, taking a look at the web pages themselves.
The shopping cart monitor and shopping cart inspect are the two That sounds right.
Things. Yeah. I'm not trying to sell anybody something, and I promise you I did not know that you had done that.
But it's a big I mean, it's a big fear for a lot of organizations. How are we going to deal with it? And there are several really good solutions out there depending on if you want a third party solution, which SecurityMetrics offers, I think, a really excellent third party solution that just manages it for you. And then there's other organizations that they have a fully in house security operation center, and, you know, they have you know, they wanna fold all that activity into that. In which case, I typically say, oh, shoot. What are their names?
Jscrambler and Human and SecureDefense are the ones I can remember off the top of my head that that are other options for that.
But so you were able to take advantage of a third party offering to meet that?
Yes. We ended up yeah. A lot of the difficulty that I'm finding with, the way our business is positioned is is we don't host anything in the cloud. Everything's done on prem with our own technology.
Okay.
So finding other companies that we can integrate with for compliance solutions is difficult because everybody's, yeah, we can can tie in with AWS, we can tie in with Azure and we don't use any that.
Uh-huh.
So and you do it on prem with what we've got, custom written code?
No. Okay. Well, we'll look for something else. But you guys you guys were able to, integrate and work with that.
So it worked out pretty well.
To hear that. That's really great. So another one of the ones that people ask me about a lot and are actually were really worried about would apply to you, and that is the internal vulnerability scanning now needs to be authorized.
And so I get organizations that they're not even sure what the word authorized means. The you know, their question is like, does that mean what is an authorized scan? Does that mean, like, the CEO has to say, yes. You can do this scan? Like, no. That's not what that means.
So, you know, running it it's it's running a scan, using a role, right, that lets you see more information than the than a system would otherwise give you. That's what an authorized scan does. So, were you already doing authorized scans, or was that a change for you?
When you're talking about the authorized scan, we, yes.
We were doing it for vulnerabilities, but one of the things that we weren't doing was the internal penetration test Oh, okay.
On the internal network and then with a written report based upon a framework. So that was something that was new this year, and we had to figure out. Mhmm. And that was more research on figuring out how to go ahead and go about doing a internal penetration test and then writing up a report about that.
Right.
The the the the language around, knowing what your methodology is and how you're Mhmm.
How you're doing that's been strengthened, and and is pretty important, I think. So did it take a lot of time to get that taken care of?
We just due to the the research on it, we don't have we at that point, we didn't have anybody that was doing internal internal scans.
Mhmm.
So it was researching tools in order to be able to do it. We were able to leverage the same tool that we were using for the the vulnerability scans, just actually utilizing the tools that were already installed there.
Alright. How about policies and procedures? Because sometimes policies and procedures need to shift based on 4.0. Some in some organizations, it's it's still pretty consistent to what they were doing.
Did you Yeah.
It was pretty considered. There were some changes, but it seems like there's changes every year and every time it up revs a little bit when it ended up going from 3.2 to 3.2.1, there were slight changes that we ended up modifying. So it wasn't, it was about the same as as the as the previous years.
That's good to know. I don't always hated doing the documentation in the policy and procedure part when I was hands on.
It seems like it's the only thing I do now is writing the reports and hence the formalization of that.
But I think that policies and procedures, when done correctly, can actually be supportive of the day to day activities.
Mhmm. Agreed. And that's one of the things that's nice about, working here is looking at the compliance, the audits, and the implementation of compliance frameworks as a team effort rather than a adversarial of us versus whoever's doing the audit. Right. So it it's looked at it's something that's going to make us better.
Even if there are findings, it's a it's good to find out beforehand and fix it rather than have something happen, and then you're in big trouble.
So I didn't tell you I was gonna ask you this question, but that makes me curious. How was it working with, my colleague, Michael?
Was you said it was a collaborative effort?
And it's been great. Yeah. We've, we've gone with SecurityMetrics for the past ever since I've been here.
So for the past five, six years Oh, wow.
We've been using SecurityMetrics. And it's usually been Michael that ends up leading the audit. Sometimes there's people that he's training. And there's other people that end up coming along.
Yep. He's great.
Yeah. It's yes. He is.
I agree. He knows so. He he he I think at this point, he's done more 4.0 audits than probably any other QSA out there. He's just everybody decided to go ahead and do that, this year. So it's been great to have his experience to lean on as we all start transitioning, from 3.2.1 to 4.0.
I'll tell you one thing. Going through the PCI audit is a lot easier and a lot more enjoyable, if that's the correct word, than when we go through our SOC audit. I I dread our SOC audit every year. Oh, right. Even though it's pretty much the same, I absolutely dread it. And I think it ends up coming down to when we're doing PCI, it's somebody technical Mhmm. Who's doing the audit, who can ask the correct questions and let us know exactly what we need to provide versus a SOC audit are being done usually by accountants who aren't technical, and they ask very broad questions that could mean anything.
Right. I think having a technical background is really helpful as an auditor.
Yeah.
Because there's so many different ways to bring a solution that meets a requirement, but but sometimes you have to talk through the technical aspects of it. And if the person on the other side doesn't understand that and they're just looking for a yes, no, check the box, then it can be just extremely frustrating for organizations to especially, if you're doing something in I foresee this in the new, customized approach where there's organizations that have very mature security programs that are based on NIST standards usually Mhmm.
That if you're trying to explain this is how we do it, and this is why we know that it meets the requirement. But if the person doesn't have a technical background, they might struggle a bit with that.
Yeah.
We we ended up having that, with, the PCI, three, with password requirements.
We weren't we weren't meeting the PCI password requirements because we were following NIST.
Oh.
And it was well, we're this is more secure doing it this way. We don't want to lessen the security by doing it exactly the way PCI requires it.
Exactly. If you're looking for, are you doing it exactly the way this piece of paper asks me to tell or tells me to ask you, then then that's that that's a conversation that's just going to get more and more frustrating and and can reduce the security stance of the organization being assessed.
So, I'm glad that you've had a positive experience with with Michael in that way.
Finally, having gone through it now, kind of knowing what it takes, the knowing the differences between 3.2.1 and 4.0, is there any kind of advice or maybe gotchas or what what what would you tell people who are suddenly realizing I have to do a 4.0 now?
It's not that scary. If you've if you if you're first jumping into it, probably seems overwhelming, but look at your auditor as somebody who's there to help you rather than somebody who's gonna try and get you and ask questions and find out from them what are other people doing to comply with whatever you're having a question with.
That's those would be my suggestions with it. It's not it's not that big of a deal. Just take it one step at a time.
That's excellent advice and reassurance. I really appreciate you taking the time to tell people about your experience. I know that there are a lot of people who want to know what they're getting themselves into, and and hearing your experience, I think, was going to be helpful to people.
Oh, good. I'm glad glad I could help.
Alright. Thank you.
Thank you for having me.
Thanks for watching. To watch more episodes of SecurityMetrics podcast, click on the box on the left. If you prefer to listen to this podcast, it's available on all your favorite podcast platforms. See you on the slopes.
.svg)
