Save Money on Your PCI Audit: How Scoping Boosts Your Budget

Watch to learn the top things you need to focus on to improve your security and ultimately–your bottom line.

Having issues accessing the video above? Watch the video here.

Save Money on Your PCI Audit: How Scoping Boosts Your Budget

George Mateaki, Principal Security Analyst

“From a business point of view, what security controls are critical? It’s not about due diligence or proving compliance, it’s about real dollars. Your PCI DSS controls translate to saving you actual money. Every control in the PCI DSS standard is there because there was a related breach and loss of data.” 

With over twenty years in IT, George Mateaki shares a broad perspective and attitude with attendees that can only come through decades of real-world experience. 

His wisdom and perspective led him to focus on these questions: 

“What is it that results in actual loss of data? What are the things that actually cost businesses money?” 

All of the controls you employ reduce your risk to an acceptable level–humans need to mitigate risk, and that is no different in the PCI DSS world. “These are not little irritating hoops people have to jump through, these are things that people have lost data over. These are serious requirements.” George reviews the top things you need to focus on to improve your security and ultimately–your bottom line. 

This webinar was hosted on September 24th, 2020, as part of SecurityMetrics Summit 2020.

Transcript of Save Money on Your PCI Audit: How Scoping Boosts Your Budget

Hey, everyone. This is George Mateaki with SecurityMetrics.

And our current presentation tonight tonight right now is your PC audit PCI audit and how scoping can boost your budget.

And so if for some reason you thought this was the, the checklist checklist mentality, less security, presentation, this is not the one. Right? I just wanna mention that briefly before we get into this.

With PCI security, sometimes if you're doing a self assessment, there's a temptation to sort of rationalize what what it is you have. Do you have, an actual documented standard? Well, I think of it when I bring the servers up.

So that that is a checklist mentality. I just want to, flatly discourage you from that approach.

You should look at I'm I'm gonna go into why this is important, but especially with regards to, scoping and boosting your budget.

Alright. So a little bit about me. I've got, about twenty years in IT, ten years in cybersecurity.

And, what that means is I'm I'm I'm of the older variety. I'm a bit seasoned, so I guess you could say I'm tasty.

So, alright, we're gonna go ahead and start. Let's go to our second slide here.

So data security and compliance technology, it basically, if you're able to close your security breaches, you'll be able to reduce your your expenses and and your compliance gaps so you avoid a security breach. Now bear in mind that a security breach is not cost free.

So in terms of boosting your budget, keeping yourself secure is part of boosting your budget. Do you really wanna spend money cleaning up, you know, lost or or data breaches?

There's a a lot of money involved in that in that activity. So definitely avoiding breaches, you're already starting off on the right foot in terms of avoiding, unneeded costs.

Alright. Let's move to slide three. So what we're looking at covering is we're gonna talk about understanding your environment, basically defining what you have so you can manage it, Scoping and outsourcing. This is, an interesting discussion point.

There's nothing wrong with using third parties. You just have to secure it appropriately.

And reducing compliance burden.

And then I'll I'll get pretty deep into that part.

So let me just start out with saying that about a decade ago, Verizon did a study, and they they they were intent on figuring out, you know, what is it that results in actual data breaches?

What what is the thing that you can do to prevent actual loss? Right? You can have scares of all types. You can have people attacking you. But do those actually result in data loss? Well, as part of that study, they also looked into the airline industry, And they found that what the airline industry did, they did a similar thing in terms of risk.

What is it that results in actual loss of life?

You know?

What little things can we do for passengers?

Does that little, infomercial that we give, passengers next to the door really help save lives? And if it does, you know, great. So what they found, they found that in terms of loss of life, the number one thing that they could do was look at the the sheer crosswinds that occur as people are landing.

And that by putting in controls to address that, they reduce the loss of life.

I want you to consider PCI the same way.

These are the security controls that you need in place to avoid losing data and losing actual financial, funds.

That's what they represent. It's it's a serious thing. It's it's you know? And that's why I compare it to to Verizon study where they did something similar. And back then, what they found in terms of data was that third party, management was the piece that resulted in that that loss of data and financial, funds.

And so by putting, appropriate controls in place to manage your third parties, how access is provisioned and removed, took out the actual or reduced the loss of data and the loss of money. So from a business point of view, this is critical. This this isn't some marketing thing. This isn't some cool thing that we do to show our our due diligence that we're trying to to to be positive. No. This is real business dollars.

This translates your PCI controls translate to saving you actual money.

And I'll I'll get deeper into that as we go through this agenda.

So let's let's move on to, slide three here. So continuing in that theme where PCI is, you know, this big scary thing that that will if you don't do it, you could result in actual loss of revenue, and breach of data.

Again, breach of data can be reputation, and that adds to your your loss of financial, funds there.

And so, let's so so I'm pushing this idea that every single control in PCI was put there because somebody actually lost data or lost, you know, funds due to that control not being there.

So so let's talk about security controls just for a moment.

A security control has to do with, putting into place something that will mitigate risk.

So let me let me paint this big picture for you.

In terms of security, when you have risk, cybersecurity is all about minimizing risk.

Each additional way somebody can attack you is referred to as an attack vector.

That increases risk.

Putting in security controls helps to close these risks.

If I have a house and it has a door and a window, I know exactly I've just quantified the entry points to that building.

How would I appropriately secure that risk?

The controls I put in place, locks on the door, locks on the window, some logging device to check who comes in and out. All of these little controls help to to lessen the risk that a breach will occur. And that's that's all cybersecurity is trying to do. They're trying to minimize the risk to an acceptable level. You know?

As a person, you you have some level of risk. You know? How how often is is somebody gonna attack you? Well, you know, whatever that risk is, ultimately, you have life insurance.

You may carry a gun. You may carry a knife or you know? The there are things that people do to try to mitigate the risk of being attacked depending on where you're at in the world.

Could determine how much money and resource you spend on this. You could hire actual security guards.

In the PCI world, it's the same thing.

But we're specifically targeting controls that have resulted in people losing money and data. Okay? From the security policy to your your checks on on wireless devices, these are not little irritating hoops you have to jump through. They're actual things that people have lost data and money over.

So, again, I I I don't know how to emphasize this enough. These are serious.

Take these controls seriously.

Alright. Let's move on to to slide five. So slide five is all about, you know, you have to recognize you have you need to identify what it is you're gonna try to manage. Right? You can't manage something you don't understand.

Otherwise, you're just saying, oh, I heard it's a good idea to have a security policy.

That doesn't that's not effective. You need to to focus your resources on exactly what's gonna help you secure your data.

And so number one, PCI defines, scope as any systems involved in transmitting, processing, or storage.

K? And and and all the people that are familiar with this this this area know that there's one more.

So transmit process or storage, it's pretty clear. You touched credit card data, you're in scope.

If you have the ability to impact that security data, you're in scope.

So as you try to get your arms around this thing, you first need to define it and document it. Where is it that you have credit card data in your environment?

Alright. So we have, systems that may store it, systems that may transmit it, systems that may process it, some sort of payment application, and then systems that may affect the security. Now that one gets a little harder to define sometimes.

In my practice, I try to go to just one level beyond the environment.

If there's a system one level beyond the environment that could affect security, I address that. Is provisioning appropriate?

Have you locked this down? Are patches being applied?

Could this system end up, you know, allowing you to pivot into this card data environment?

So that that is, so four areas. Right? The three main ones, transmit, process, or store, and this fourth one affect the security of card data. That that's critical.

K? So that is the first step. You need to admit that you have card data that you need to to figure out what you're gonna do with it. And so PCI has a set of standards that that you can follow, and, and they give you prescriptions on what you need to do at a bare minimum.

K? I think in one of my slides, I've mentioned this PCI should be a baseline.

This is a bare minimum of what you should do.

Once you figure out your environment, then you figure out what areas are extra valuable to you, and you, put appropriate resources to those to protect it.

This is a, you know, a common, security principle, defense in-depth, layers of security. If you're old enough or or if you got to catch, get smart, you remember all the little layers of doors you had to go through, That's the idea.

You don't want to have, a big robust door. They break through, and then it's just, you know, soft and fluffy in the middle. They waltz in and take all your stuff. That's that's what we're trying to avoid. Okay. So layers of security, that's important.

So, getting your hands around what you're what you need to bring into compliance.

And there's, on this slide, I have documentation. That is critical.

And I've so from my background, and I manage data centers, throughout the world.

And, one one thing that I hate is walking into a wiring closet and seeing spaghetti.

I just I hate that. And so, oftentimes, when I'm working with data centers, I'll try to, you know, have some folks spend some time getting that repaired.

Obviously, that that results in slow troubleshooting of major issues when you don't have good documentation of where everything is. The way that starts is somebody says, oh, this needs to come back up. You know? Somebody's really mad. Go make it happen. They do it, and they say, we'll go back and and document that move. Then over the years, you get spaghetti.

Well, documentation for your payment channels can can take a similar path.

And so you you need you need a process that touches your documentation if your payment process changes.

So so, obviously, we need to figure out how do you accept payments in your environment.

And then once you figure that out, talk to the people, document it, however you're gonna document it, get data flow diagrams, get network diagrams, understand the critical critical components.

And then, once you've got that, you need to document changes.

So if equipment moves or if technologies change, these need to to flow into the process that updates the documentation. So establishing how you will document and maintain this document on on on your payment flows is critical and assigning responsibility.

You know, how many meetings have you been to where, yay. We're we're moving forward. By end of quarter, we're gonna have all servers migrated. Yeehaw. Let's go.

But nobody's assigned the charge. Right? You have somebody has to be responsible or else it's not gonna get that. There have to be dates in place. So on an annual basis, you should review your documentation and ensure that everything makes sense, everything's relevant, you know, at least on an annual basis, if not less.

If something changes, it better update the documentation. There better be somebody assigned to that to that, to those diagrams. Who's the author? When was it done? What's the date? So on.

And so another mistake people often make is they minimize the effort required to document this. It may be very simple, but unless you speak to the people that actually do it, you may get it wrong.

And I've run across this many times, where inadvertently, there's a coverage somewhere where people are filing away credit card numbers for whatever reason, and that's just how they've been doing it for years. And they come across it, and that's a violation.

Potential breach.

And so you have to have good documentation. You have should have policies that everybody reads. Understand that that, you know, you should not be writing credit card information down. It should not be emailed anywhere.

And if that's happening, there better be a well documented process on how that stuff gets purged.

Alright. So the the basic flow diagram, you want to, capture what payment elements are moving between the, you know, the different systems. That's the the key piece there for PCI. They they want you to clearly understand what's going on with with the payment, data pieces, your pan, your expiry, things like that.

And so the data flow should clearly outline what's going on. And sometimes you may have multiple data flow diagrams to clearly understand your environment. So once you've got it documented, you've got an established process to keep things, you know, up to date so that you don't somehow get a new payment process and nobody's aware of it and it's out of compliance and you run into problems.

Okay. So that that's that is some critical, points there for getting your scope together. Alright. So once you've got your arms around what you have, you you may want to consider outsourcing.

And many people do. Many people don't wanna manage the infrastructure, the day to day the patching, the the what whatever it is, you know, that needs to happen for your environment.

And there's many there are many service providers that will do things in a PCI compliant manner. They typically charge a little more than your non PCI, compliant folks.

But they've gone through the process. They know what they have to do in terms of providing evidence, and and, and so that's that's a good approach. So outsourcing, I I wouldn't shy away with from it just because you're afraid it may introduce new security problems. I I mean, to be honest, there there is some risk with bringing in a third party.

But if you appropriately secure them, it shouldn't be a problem.

So, number one, you document your process around managing your vendors.

You if they do AOCs, I you know, if you're gonna go that route, you're trying to stay PCI compliant, you probably should go with a vendor that that is p c that does PCI, assessments.

That meaning that they get an AOC every year and that you can, be provided with an AOC and gain confidence that they're doing things in a PCI compliant manner.

In addition to that, third parties, should acknowledge their responsibility with regards to PCI. That's actually a requirement for them to certify every year, but, you may run into varying degrees of difficulty getting that.

But it is required of them to provide that to their customers.

So the reason I I I I wanted to bring this up in this presentation is I've seen many, environments where the IT staff is overworked.

People oftentimes don't think of this as a security issue. It is.

If, you think of, someone that is, not getting enough sleep and trying to make critical important decisions on a regular basis.

If they're not getting enough sleep, a truck driver, for instance, the if they're not getting enough sleep, problems could come up where you get loss of life.

That's not good.

So with PCI, if if you value security, if you think security is important to you and it's not just a checklist item, you need to take it seriously. You know? Do not so the the typical mentality from businesses, they're IT guys. They like that sort of stuff. They can stay up late here and there, and they'll figure it out.

That's a bad approach to security.

You are already increasing the risk of a security breach.

For the same reason that they recommend people take mandatory vacations, is why you don't wanna overwork your IT staff, having them do, extra PCI stuff. If you were paying them a fair wage before, you need to augment your staff or or or compensate them appropriately or do something. Right? Don't just, overburden them and create scenarios where, security breach is, you know, will occur.

That's just not a good situation. So that's why I bring up augmenting staff. It it's not that hard. You create your contracts to, you know, NDAs if you have to, and you set up a clearly defined, contract of what they're gonna do and what they're gonna provide for you.

And so that's important.

So I I just want to, bring that up because I've seen in many PCI assessments where IT staff are overworked, they are missing the controls. They're screwing up the controls, and things are not getting done that need to be done. So just a warning.

Okay. So slide seven, reducing compliance burden.

So I'm gonna get a little biblical here.

If, the the biggest impact, the the biggest reduction in scope is going to be if you store cardholder data. If you can get away from that, do it.

There are so many, extra things you have to do for when you store cardholder data. And in terms of compliance burden, it's a huge burden.

Think also that, you know, in terms of attack vectors, you have actual card data that could be attacked.

If there's a way to decrypt it, you know, many times, criminals will find a way to get around and and decrypt it and get the data.

Short of holding a gun to somebody's head, you know, there's always that. But, putting in strong cryptography controls, it does take some effort. But if you can most entities do not need to store cardholder data. And sometimes they do it because they wanna be able to address customers' concerns or or whatever.

But in in in general, most times, people are able to to get away from that and reduce huge amounts of effort that's required around storing cardholder data. So if you can get away from that, thou shall not store cardholder data, that's a commandment right there that will help you reduce your compliance burden. And then segmenting. Now this is perhaps a more entry level problem.

But if if you don't segment your network properly, you're gonna bring into scope everything else that's on there. Right? So if I have a little web server, people come to it, they do ecommerce, and that web server has on that network other stuff that shouldn't be there.

That all comes into scope, depending on how it's set up. So your card data environment, you you want to limit let's let's let's put it this way.

You want to limit what has access to that area. And if at all possible, only allow things in the card data environment to reach out, not you don't let people reach into your card data environment.

Connections are initiated from what's within your card data environment.

And that's how you you reduce the amount of attack vectors that could that could hit your your card your systems.

You you just really secure that thing down with firewall rules, ensuring that only systems that have to talk to something outside of there do and that the systems in the card data environment reach out rather than other systems reaching into that environment.

And and that's in general how we we secure and segment off, systems that don't need access.

So from from a, biggest bang for your buck perspective, segmentation and not storing cardholder data are are the biggest, approaches to reducing scope. Let let me just, speak a little bit more on slide seven. There is an infrastructure bullet item.

It is important that that, you know, if you're able to reduce the infrastructure required for your environment, that's definitely a reduction on compliance burden.

So many people will outsource the infrastructure portion, the managing of patches, or they'll find, diff different virtualization, techniques that that gets them away from having to manage the infrastructure.

And so if you have someone that's already doing it, in a PCI compliant manner, you can lean on on their efforts. So let me just throw out a few, thoughts. File integrity monitoring, all the logging, all the patching, all that stuff, ensuring that that, you know, systems are managed correctly, that other software running on there doesn't have old outdated patches.

These can be a compliance burden. If you have people in place already that do it, you know, that's great.

If you can take this off your plate, that's that that would help you in focus focusing your efforts on other areas.

Okay. So in in summary, I'm just gonna summarize this. Number one, you need to take PCI seriously.

You can't look at it as a checklist type, activity. It's not, you know, just checking boxes.

Do you really have security in place at your environment?

And and to do this, number one, you need to define what it is you're trying to protect.

What do I have? Document.

You know, see what the data flows are. And, again, do not think that just because the process is simple that you don't need to talk to the people that actually do it. Please talk to the people that do it, and and you may be surprised to find out, woah. You know? I didn't know we were doing this this step here. So, again, find out what you have.

Once you understand your environment, then try to segment, limit access to those systems, to only what the bare necessities, bare essentials, only what actually needs access. And, again, reach out, not reach in. Right? If you're able to and and there's ways to make this happen.

If you're able to, all, connections should be initiated from the card data environment, and you limit what can just connect into, into that card data environment if you let anyone at all.

Once you have this defined, once you've limited what can access things, look at what you're doing in your process. Do you store cardholder data? If you do, that is a huge item.

You can reduce your compliance burden by quite a bit.

The next thing is, are you do you have anything on your network that doesn't need to be there? Get things out of the network that that that's where the card data environment is.

The the final thing, consider those systems that impact security.

It it store process and transmit. That's that's the PCI approach, but also systems that could impact security.

Now, with with this presentation, you know, we we we're promoting that that you close breaches and close gaps so that you can truly have less compliance burden.

And and that is the case. That is the case. The less you you have to simplify what you're looking at in your environment. So if you have, things that you need to address, address those. Get get your environment to a manageable state and then implement appropriate controls. Now PCI has prescription. Prescribe all the controls you need for the different twelve areas, twelve requirements.

And, again, that is a good starting place. Right? Baseline.

So from a compliance burden standpoint, this should represent where you start, and you should build from there based on, the value of your assets and the risk that you're facing.

Alright. I'm gonna go ahead and end there and and take, questions.

Get the Guide To PCI Compliance
Download
Get Quote for PCI Compliance
Request a Quote