Reduce Your PCI Scope

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

Reduce Your PCI Scope

Lessen the Cost and Simplify PCI Compliance

In this webinar, SecurityMetrics Principal Security Analyst, Matt Halbleib, covers:

• Defining your PCI scope
• PCI scope changes with PCI 3.0
• Tips to reduce your scope
  

‍

This webinar was hosted on March 25, 2015.

Reduce Your PCI Scope Transcript

We'd like to welcome everybody to the this morning's webinar, reduce your PCI scope to lessen the cost and simplify PCI compliance. My name is Matt Halbleib. I'm a principal security analyst at Security Metrics.

Let's go through the just a quick slide here about security metrics ourselves.

We provide, PCI, HIPAA, and other data security solutions for businesses of all sizes.

As a we are a global provider of ASV, QSA, not ASV, approved scan vendor, qualified security assessors, forensic investigations, PAQSA work, and p two p e services.

We've assisted over eight hundred thousand organizations with with their compliance needs.

So a little bit about the agenda here. We'll we'll go through defining your scope, talk about understanding some of the inflows and outflows of your cardholder data that helps you, further refine the scope. And we'll talk about some scope changes in three dot o that may have an impact on on some of us.

And then we'll we'll go into the benefits of reducing your scope and some tips on how you might, you know, make reduce your scope as well.

A little about me as an individual just briefly. As I said, my name is Matt Holbleib. I've been in IT for well over for over twenty two years.

The last fifteen years, I've I've been in information security as a as a field.

And specifically, over the last seven years as a QSA, I've done system and network administration, telecoms administration, mergers and acquisitions, and quite a few other things. But so let's talk about defining your scope.

The first thing we need to do is, talk about what PCI what PCI Security Standards Council means when they talk about your, what is in scope for PCI.

On page ten of the PCI DSS, there's a couple of, sentences that are of critical importance.

Right at the top of the page, it starts with the PCI DSS security requirements applied to all system components included in or connected to the cardholder data environment.

Then the next sentence helps us understand what the cardholder data environment is. It's comprised of people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data.

Then they define a little bit about what system components include. So networking devices, firewalls, switches, routers, servers, computing devices, applications.

It's important to understand and we'll come back to this idea that if it stores processes or transmits or is connected to systems that do, then it's considered in scope from a PCI perspective.

So when I talk to new customers, the first thing I usually like to do is ask them to just kind of consider their their whole environment and their systems as a black box. I'm not concerned initially about what's inside the box. The first thing I want to understand is what are your inflows and outflows of cardholder data?

How does it enter into your environment and who do you send it to?

Even infrequent flows are still in scope for PCI. Even if it only occurs once a quarter or even once a year, if you have cardholder data coming in or going out, it's still considered one of your your cardholder flows.

So we draw that boundary around the environment and look at where, you know, where card comes in cardholder data comes in, where it goes out.

So some examples of maybe some of the inflows would be a point of sale system. Pretty obvious there. A brick and mortar store with a point of sale system. Maybe a mobile POS system.

Do you have an ecommerce website?

Do you have a mail or telephone order system? Do you use virtual terminals to process some of your cards? Have you outsourced any of your processes to a third party? Are they processing under your merchant ID?

Let's say you have a brick and mortar pizza store or something where, you know, really you just make pies and and serve pizza, but you wanna be able to take orders over the web. So what you really did was outsource that responsibility to, a PCI compliant third party to take orders over the web and send them to you, and then you, of course, make the pies and deliver them or whatever.

So that's a third party who may be processing under your merchant ID. If there were ever a problem and some of the cards that were processed on that website were ever compromised or something, it would look as though it came from your merchant ID. So you need to be aware of those. There are other PCI requirements as well that we'll talk about when it relates to third parties, but, make sure you know through those third parties that you process with.

Then on the outflow side, you know, you swipe the card at the point of sale system, what happens to that, information? Does it go directly to the processor from the the terminal? Do you send it to a back of house server, and that batches things up and sends them out? Does it store them for thirty days or whatever?

Need to understand, you know, exactly that process. Do you like back to third parties. Do you have third parties that are they're processing for you? Or have you outsourced the management of any of your systems or infrastructure to a third party? They can affect the security of your cardholder environment, and so that relationship is still in scope from a PCI perspective.

I mentioned backup servers on there. Do you actually do backups to your systems and do you send those off-site? Are they encrypted or not encrypted? Do you have a backup server at a different data center that you might send it to?

If it has primary account numbers in those systems, then it's considered in scope.

Once we kind of know what the inflows and outflows are, the next thing we need to do is is look at what happens once that information enters our environment.

So what happens inside the black box? K. So as I mentioned a minute ago, you swipe it at the terminal and does that send directly out or does it send to a back of house server? Do you, is your website hosted at your location or is it at a third party?

Look at the environment inside and where those flows the systems those cardholder flows actually touch.

And that will help you understand then which systems may or may not be in scope for PCI.

Once you know those PCI requirement three dot o or I should say PCI three dot o requirement one dot one dot three actually requires that you have a current network cardholder flow diagram.

So once you know what the flows are, which systems they touch inside, then you can kind of create a simplified flow diagram of where the data moves inside your environment.

Once you understand what the flow is, then the next thing you need to take a look at is the actual network itself.

How is your network constructed? Do you have one firewall at the edge? Is it segmented internally? Is it a multi interface firewall?

Do you have multiple firewalls? Let's say you have a web server. You've got an an outer firewall, a DMZ, and an inner firewall, you need to understand what the the actual components are that make up your network.

Then you can overlay the card flows onto the systems in the network environment and the network diagram and understand which systems store, process, transmit, or are connected to systems that store, process, transmit cardholder data. Those will be the ones that are in scope for PCI.

Let's talk a minute about storing the primary account number.

If you store the the primary account number electronically, that qualifies you for an SAQD.

So if you were to read through the council's direction on which s a q to to fill out, you'll notice it'll list, you know, ecommerce and doing it over a web server.

No storage no electronic storage. It'll say that on all of them till you get down to an s a q d.

One thing that we often find is that many merchants don't know they're actually storing, cardholder data, be it encrypted or unencrypted.

So if you've got a point of sale system, make sure to ask whoever your vendor is exactly how the system works. Does it store cardholder data? Does it only, you know, hold it temporarily in memory while it sends out for authorization, which is fine. That's not storage if it's just holding temporarily in memory. But if it's writing it to a database and keeping it for thirty days so that it has a record of all the transactions that allows you know maybe to easily process a refund or something, that's storage.

So make sure to ask questions of any vendors you have if they're selling you systems and things exactly how it works so that you understand, where you're storing or not storing cardholder data. In our experience, we we find really that primary account numbers have a way of moving around in systems.

A simple example of this is the the finance group in many companies.

They're real good about keeping information private. They know that they have people's payroll information and social security numbers and things, and so they don't talk a lot about what they do in their processes.

But usually, the person handling PCI tends to be a little more on the IT side of things. And so those two don't always talk together. But often, when I go out to a customer site and I start asking questions of other groups, do you ever, you know, have or receive cardholder data, you'll find that they do. So back to these finance people, oftentimes, they'll get statements from the bank that may have a a full card number.

The banks are getting better about sending redacted card numbers now, but sometimes you still find it. Sometimes, some of the card brands, maybe Amex or somebody, send you a file of all the transactions that you've had for the last month so you can finance can reconcile the books and things. Do they have a refund process? Sometimes they'll get a notification of a disputed transaction or a refund or whatever from the bank.

And then, you it could be sent an email. They could log in to a portal and and then finance because they typically have, data retention requirements of, you know, seven to ten years kind of thing. They'll often print off some of that information and keep it in a file. You can do that, but then you need to know that that card flow exists and you need to properly secure that physical paper with in accordance with PCI and section nine.

So just once again, it's kind of the point is you need to go out there and ask all the different organizations if they receive cardholder information, and what exactly that comprises. Does it have the primary account number? That's the gating factor. If you, look at page seven and eight of the the PCI DSS, it talks about sensitive authentication data and defines different elements of what's what's on a card. And the primary account number, if you don't have the primary account number, then the other information may you may have privacy concerns over it, but the PCI doesn't think you have cardholder data. Because without the primary account number, you really can't produce fraud against the card.

So one thing that we ask all of our clients to do is run a cardholder data discovery tool, and this just helps find unencrypted pans and confirm that the cardholder data environment is what you think it is.

So in our experience, we we have a at SecurityMetrics, we have a tool we call PanScan.

And on the right of the slide here, you can see some of the statistics from twenty fourteen. Over three hundred and thirty two million cards have been found, unencrypted credit cards. It won't find encrypted ones because they don't look like cards. Right? But three hundred and thirty two million plus unencrypted credit cards.

Sixty one percent of the scans find unencrypted pan data.

And in seven percent, they actually found track data.

And once again, back to that page seven and eight of the PCI DSS, track data is considered sensitive authentication data, and you're not allowed to store it post authorization.

Also with that track data, if it is recovered or in some way stolen from you, people can actually make a fraudulent card with that information. So it's really something that you you have to be careful about not having around.

So run a cardholder data discovery tool of some sort, whether you run RegEx's or PanScan or some other tool. What that helps you do is identify where in your organization you might have pan data, and that would help identify a process that you didn't know or understand.

Once you identify the process, you can start to look into it and figure out how the data got there, and then determine from that what you might do to fix the process in some way. It shouldn't be having unencrypted card data.

So ask, you know, is there a business reason that you need to to keep this data? And if you have to, then it has to be encrypted in accordance with the PCI DSS, and that's mostly section three.

That also, once again, because it's electronic storage of pans, means you're an SAQD.

So on the other hand, once you investigate this process, say, if the data is not needed, then change the process and securely delete the data. You can't just do a regular delete. You have to do a secure delete and overwrite the file so that the information is no longer accessible.

Let's talk next about, some of the changes in scope with three dot o. Some of these have been talked about in other webinars, but, we'll go over some of these that might impact the scope.

PCI three dot o clarified that there are some of these, what we kind of call secondary systems that are in scope for PCI.

So some of these might be we have log servers here. Sometimes people, you know, all you require section ten requires that you log all the events in your systems and you store them on a ten dot seven requires that you store them on a centralized log server.

Sometimes people put that in an environment outside of the PCI, environment itself or the PCI network. And that's okay, but we we have to look at the security of that system and make sure that it's storing the records and things in accordance with section ten requirements. Plus, you have to properly secure that system.

NTP is another example of one of these that is oftentimes, a system that resides outside of the cardholder data environment because NTP might be used throughout the entire organization, But it's it's section, requirements ten dot four and its sub requirements say that you have to run, network time protocol of some sort in the environment so that the logs are all properly synchronized.

So once again, this is a system maybe outside, but you have to secure it and we have to look at it. DNS is another example of a system that, you know, may reside outside of the typical CDE, but in three dot o, we'll look at this security and and how it's, how you secure that system and how it's addressed. An example of why, the DNS may be an issue for your environment, attackers can do a DNS hijacking type attack where they actually modify the DNS records so that they point to a different system than yours. And so the end user is trying to get to your system, but the DNS gives them the address that's really controlled by the attacker.

Then they can actually take that information and, you know, whether they gather card details or whatever it is they wanna do with it, they're sitting in the middle of that connection now, and they can they can harvest that information. So DNS servers are are in scope for PCI.

Let's also talk about, some changes in requirement twelve dot eight. Two dot o had requirement twelve dot eight itself, which basically said that you have to have a process to engage third party service providers.

You had to monitor their compliance on an annual basis, and you had to have legal agreements in place that basically stated that you were giving that third party, either cardholder data or in some way they affect the security of your cardholder data environment and they recognize that. So that was part of the contract. The addition in three dot o is that there now has to be a document that clearly delineates which requirements are managed by the third party and which are managed by the merchant themselves.

So if they're managing your firewalls, then there would be a list of requirements in section one, maybe a few in section seven or eight about accounts, eight dot three because that is two factor authentication, and they may be handling that for remotely accessing your firewalls.

And in the case of of, them actually remotely administering some of your systems, there is actually an additional, some additional requirements in section eight that state that as a service provider, they need to use unique individual credentials to log into your systems for both for each technician who may be logging into your systems, but also the credentials they use to log in to that individual merchant need to be different for each merchant. In the past, sometimes they would use the same credentials or a generic credential to log in to multiple different merchants, So then an attacker would would compromise one environment, take those credentials, they can, you know, they the attackers are not idiots. They go out and look at, at the service provider's website and it lists all the merchants that they service.

So then the attacker will take those same credentials and log in to other environments and extend their compromise beyond the initial one. So PCI three dot o says that they have to have unique accounts for each and each technician.

They have to use different accounts for each particular account of theirs. So yours your credentials should be different from the next guy.

And, of course, eight dot three, which has always been a requirement, which is two factor authentication.

So twelve dot eight now adds this idea that they have to clearly delineate which responsibilities are the service provider and which are the responsibility of the merchant. Twelve dot nine is a new requirement as well and it becomes effective at the end of June, June thirty of twenty fifteen. But it requires that service providers provide a written acknowledgment to their customers that they understand they're, you know, responsible in some way for either cardholder data or the impact the security or environment or whatever. So that's requirement twelve dot nine.

Let's also talk about and there have been other webinars about SAQA versus AEP, but this is, this nicely demonstrates the difference between just three of the s a q's. So s a q a, which is an e commerce merchant, who there are two situations that qualify for an s a q a. One is and they both kinda have the same language, but it says the entirety of the payment page has been outsourced to a third party.

By that, we mean that let's give you an example. I click and I say I want to check out. I click on a box and it takes me to a totally different website and, you know, you provide a little screen that says you're being redirected to this person to provide payment or whatever. That's clearly being redirected to a third party. That's an s a q a type situation. There is another one, which is some of the payment pages is served up by the merchant, but the part that takes the actual card details, the entirety of that is served in an iframe from a third party.

And that also meets the definition of an s a q a. If you're doing any sort of other sort of redirect, like a direct post to a third party or some JavaScript or something like that. That's an s a q a e p. And you went from fourteen questions to a hundred and thirty nine questions all of a sudden.

And the hundred and thirty nine requirements have some difficult ones in it. You have to have an annual pen test, which depending on your environment could run-in the tens of thousands of dollars.

You have to do internal and external scanning. You have to have file integrity monitoring. You have to have centralized logging. A lot of the things that are not required in SAQA all of a sudden become a requirement in SAQAEP, and they are, complex and sometimes a little difficult to meet, and, of course, would cost more money. Lastly, then, SAQD is really all of the requirements.

Once again, back to the if you're electronically storing the primary account number, that qualifies an individual for an SAQD or if you don't fit any of the other SAQs.

Let's talk now a little about some tips and benefits of reducing your PCI scope.

Some of them might be obvious to you already now, but I'll start off by saying if you don't need the pan, don't store it. Let's go back to that SAQ a versus SAQ d, fourteen versus three hundred and thirty five requirements.

I know it might seem sometimes to make make life easier to say, well, I'm gonna store the pan for a time because maybe I wanna process a refund or, some places where I've seen it are like florists and things. They get customers who call in and order flowers and have them delivered to, you know, to a hospital or to a spouse or whatever.

The florist will often store the cardholder information somewhere because they're a recurring customer and they wanna make it easy for that customer to order flowers.

That seems like a a good decision at first because it, you know, increases sales by making it easier for your customer to to order from you. Downside is that you're now storing electronically storing cardholder information and primary account numbers. That's an SAQD.

So you, you know, your your burden went up significantly.

So take a good look at at those card flows we talked about at the start.

And once you know what those are, determine if you're storing the data anywhere, and then determine if you really need to to store it. And if not, you know, consider an alternate method. Maybe can you store the can you store it out at your bank? And you can they give you a portal to log into when you want to do a refund or something?

Can you outsource some of it to a third party, more the SAQA type situation, where you outsource the entirety of the payment page to a third party?

If you're storing the PAN, recognize then that section three requirements all of a sudden apply as well. So three point one requires you have a data retention policy. So back to this idea of do I need to store it? Three point one says that you have to consider legal, regulatory, and business requirements for storing the primary account number.

So if there's a legal reason, then then you have a legal reason and you need to store the the account number. But make sure to ask the questions of, are you know, what are the legal regulatory and business needs for storing this card? And if I if I don't have a compelling need, then I wouldn't store it.

If you're storing the primary account number electronically, then you have all of the PCI requirements.

You're required to do file integrity monitoring. That's the first line there. We usually call it FIM, but, file integrity monitoring. It's a software package you have to purchase that you install on all the systems in the cardinal or data environment. So if it stores, processes, transmits, or is connected to systems that store process transmit, then you need to have file integrity monitoring on it.

That's, of course, you know, more money. You have to have an IDS, IPS. That's intrusion detection system, intrusion prevention system. It's an either or there. They're similar systems but, but different. One may modify your firewall rules, intrusion prevention side.

You know, may modify firewall rules to stop an attack or something. An IDS would simply alert you that there's been an attack. So once again, that's another system you'd have to purchase and install in your environment, and then you'd have to have all the care and feeding that goes along with that system. You have to have an annual penetration test, internal and external. And if you've segmented your internal network, three dot o requires that you test that internal segmentation.

You have physical security requirements around the systems that are hosting the data and storing the data.

You have to have the, you know, of course firewall and all the controls that go along with the firewall, change control, internal and external scanning, and and way more than that even.

So one option is sometimes you can outsource some of the aspects of PCI.

Are there service providers who could take on some of these responsibilities for you? Now, it it doesn't totally get you out of PCI. It simply puts the burden of maintaining the systems on somebody else, and it goes back to those twelve eight and twelve nine requirements in terms of delineating which requirements are managed by the service service provider and which are managed by the the merchant.

Maybe you're not an expert in firewalls, so you outsource the responsibility for the management of your firewalls. We talked about that earlier.

Log collection and monitoring. There are services out there that you can send your logs to. They will store them, They will correlate them. And they can even send you alerts when they find suspicious activity.

So you it's can be difficult to actually do log collection and and monitoring correctly. It's a requirement that you monitor the logs on a daily basis. You can have a system monitor the logs for you that sends you alerts when certain events happen, but you have to configure that system to send you the alerts on specific activities.

So sometimes you, you know, you might be able to reduce some of your burden by letting letting somebody who specializes in that type of work actually collect the logs, monitor them, and tell you when there is a problem or they think there might be a problem.

As well, I listed their system hosting.

Sometimes you, you know, there are services that provide hosted PCI environments for you, where you can put your servers and they'll be behind a firewall that they manage. They'll make sure that the systems are patched. They'll make sure that they're hardened. They'll keep the logs for you. They'll install the file integrity monitoring and monitor that. They'll handle the IDS, IPS. They'll handle your internal scans for you.

You know, you can find hosting providers that will take on a lot of those responsibilities.

Let's talk about another option that is becoming a little bit bigger. It's point to point encryption, p two p e.

Basically, encrypted data if the three bullets there. If you have properly implemented p two p e validated solution, you have no access to unencrypted data or the encryption keys, and you have no access to the systems that control the keys, then you're you may be eligible for a p to p e s a q.

Probably are.

And from that perspective then, typically the data is encrypted. You have to have the right readers.

So out on the like I say, you have to have a validated solution, has to have been implemented in accordance with the p to p e implementation manual. You have to have a validated p to p e service provider who who, manages it helps manage the system for you. And then if you've done all those things, that encrypted data is a transit your network because you have no ability to do anything with it. Essentially, it's like it's not really like it's cardholder data to you because it's not too much different than maybe sending it out across the Internet.

Like when you're, you know, you go to Amazon to buy something, it's really an encrypted over HTTPS connection. Transits lots of systems to get the to the end point, but it's not considered cardholder data to you in a properly implemented p to p e solution. So that's one that, would greatly reduce the scope of the environment because, you know, those other systems on your environment that are transit is transiting through aren't considered in scope.

Another option is tokenization.

In whereas encryption actually takes the primary account number, runs it through some mathematical algorithms to create ciphertext on the backside that doesn't look anything like a card number. And without the key, you can't decrypt it.

Tokenization, on the other hand, completely replaces the primary account number.

So you can store that token in your database and anytime you want to run another transaction again with that customer, you send the token and the transaction details to your whoever your tokenization service provider is. And then they would go out and actually put that back into a real primary account number, send the primary account number out for authorization settlement later.

So tokenization is an option and, just make sure that if you do implement some sort of tokenization that you're not still storing the pan somewhere or you don't have old caches of the pan in your environment. It goes back to running that, data discovery tool.

If you had been doing business differently, decide to implement tokenization, make sure you run data discovery to find all the caches where the primary account number might have been.

That's knowing your flows again, all those things so that you can understand then what needs to be replaced with a token, how to implement the tokenization or p to p e solution, and, and properly secure the environment.

Sometimes they're in a tokenization situation, let's say it's a call center or something, they may have a device that'll create a token when the user speaks it over the phone.

It may go to an IVR.

It integrate voice response. So that'll intercept the the touch tones that somebody pushes when they when they enter their card details, and then that would send it out for tokenization or something. Those systems would still be considered in scope, or perhaps like your call center, like I said, those may still be in scope because they're actually getting the the card number and maybe sending it out through a a virtual terminal or something.

So just take a good look at those flows, know what they are, but tokenization is one way to help reduce the scope.

Segmentation is also another way that, if you manage all these systems and things, you can use network segmentation to reduce the systems that store process transmit or are connected to systems that store process transmit.

So back to our very first, few slides there. If your network interacts with the CDE, it's in scope. Oftentimes, when we go out to new customers, we find that they have one big flat network. They have a firewall at the edge, and everything inside can talk to everything else. That's a flat network. It's all in scope for PCI because they can all talk to each other.

When it comes to segmentation, let's say you had a multi interface firewall at the edge, and from that you create one interface on the firewall that's dedicated just to those systems that store process transmit cardholder data, and it doesn't allow any other traffic into or out of that from any other zones, then that's segmentation.

Or, you know, maybe a little simpler would be to look at it as a what we call an air gap, which is, you know, really having truly separate environments for the two. The network equipment that runs your CDE for the one environment is totally separate from the, maybe, the office environment or whatever.

That's segmentation.

Where it starts to get a little tricky is and and maybe you'll hear some different answers from different people is on the, you know, am I allowed to what sort of rules am I allowed to have on the firewall? And what sort of you know, can I send outbound to another system? And does that make it in scope? So when we talked earlier about, if all you had was an outbound rule from your PCI segment and you're pushing logs out to a log server, I'd need to as a QSA, I would look at the configuration of that log server, but it doesn't necessarily put that other environment in scope because I can't go from the log server into my cardholder environment. I can only send things out.

That would be pretty typical. Now if you have the ability to talk from that office environment into the cardholder data environment, may or may not be in scope depending on how you do that.

If it looks like outside access, two factor authentication and things, it might not be in scope. So that's a little bit tricky, but, you know, the simplest would be no communications between them, then there's they're not connected. And so it's, you know, reduced down to just those systems that truly store, process, or transmit.

Now having said that, you know, if you segment your environment and you've got an office network and a and a cardholder data environment network, PC it's not a bad idea to apply the PCI requirements to that office network. They're good security practices, but it's not strictly required by PCI.

So let's talk about some of the takeaways.

What are some of the benefits of reducing scope?

You can save money, and we mentioned internal and external scans here, but you can save money on on lots of different things. We've talked about outsourcing, you know, web servers or outsourcing log management or whatever.

If you don't have to hire personnel to manage those devices, then in some ways, you know, yes, you pay somebody else to do that service, but you don't have, you don't have to go hire somebody who specializes in firewalls and somebody who specializes in in vulnerability scans or, you know, log monitoring or whatever. So sometimes, while it seems like it's costing you a little more money to outsource some of those functions, you can actually save money that way.

Also then, we have their freeing up internal resources by outsourcing. That's that same idea. You know, you can take your own resources and and rather than have them manage, the log server or something, you can free them up to to do other work by outsourcing that.

Once again, back to the SAQD, three hundred and thirty five requirements. And, really, if you look at the reporting instructions and things, there are several steps to accomplish each requirement.

Each requirement may have a policy element. It has a process element. And then, of course, there's the actual, you know, whatever the the requirement calls for as in, you know, maybe, hardening a system or whatever.

So p c you know, the the takeaway there is PCI can be intense and time consuming.

So look at, some of these other ways maybe of reducing your your burden, whether it's through the segmentation or tokenization or p two p e or outsourcing some of those things.

So circling back on the the whole thing.

First thing you need to do is know your inflows and outflows of cardholder data.

Until you under really understand what all the flows are, you don't know what it is you need to secure.

Use some sort of a cardholder data discovery tool to help uncover some of those caches of data that you didn't know existed, but indicate there is a a cardholder data flow there.

Once you identify some of those caches, then you need to ask yourself, how did they get there?

What are they used for? Do I really need to do that process? Can I modify the process so that I don't have to store the card number?

It becomes a business decision at that point, but that data cardholder data discovery tool can actually help you identify some of those processes, those inflows and outflows that you didn't know existed.

Then, you know, making sound business decisions and reducing your scope through those tokenization p to p segmentation and things.

And just so you know, SecurityMetrics is here to help you.

So with that, let's open it up to some questions. If you have questions, you can send them in and we'll we'll try to answer them.

Hi. Somebody asked the question if storing only the last four digits of the PAN counts the same as storing the whole thing, and the answer is no. Technically, if you look at the PCI requirements, you're allowed to store the first six and the last four digits. That is not considered a primary account number.

So good question.

Another one somebody asked is, where will we find the definitions and concepts of, for determining the difference between an SAQA and an SAQAEP?

If you go to PCI security standards dot org, and look at the documents there, they have a very nice document on, you know, determining whether you're an s a q a or s a q a e p. So the p c I security standards dot org has not only the p c I security standard itself, but you can get the s a q's out there. You can find, you know, payment applications that are validated. You can find, point of interaction devices, so PTS, you know, like a terminal. You can find which one of those are validated and things.

Good resource for all those different documents.

Somebody asked about tokenization. Will we still see the pan at swipe or in memory?

That's a little bit difficult to answer. It really comes down to how the tokenization is implemented.

So I mentioned earlier about an IVR system. So let's say you have a call center and you want it you've implemented tokenization, but when they, you know, when you want somebody to enter a card number, you really send them over to an IVR system and the customer then, you know, touch uses the touchstones on their phone to enter the card number. That IVR system will have the the card number in it, but that may be something that you've outsourced to the person who's tokenizing things for you. So when you send the customer to do the IVR, really it's on your tokenization service provider.

They take those details, create a token, and then send them back to the systems in your environment so that you can store that maybe in SAP or something else.

Some other sort of v r p type system, so that you really only ever had a a token. You never had the pan in any of your systems. If on the other hand, if you're doing it through like a web browser or something, then absolutely the the pan would be in memory on that system. And in addition, depending on how you've configured that call center agent system, if it's configured to cache, web pages because of speed.

Then oftentimes it will also cache unless you've configured you you can configure it not to, but it will cache encrypted pages. And by that, I mean anything over an HTTPS session. And then sometimes when we run pan scan on systems, we'll find instances of the credit card in the cache files from the browser. So you would need to configure the browser to not cache encrypted pages, which will prevent it from writing it to the local system.

But that call center agent system would still be in scope for PCI.

And, yes, it would, you know, you'd have to secure it and put it in its own environment, segment it from everything else like we talked about.

But nonetheless, it could potentially greatly reduce your scope because maybe your SAP back end would only have tokens at that point. And all I've done is, you know, isolate my card environment to just these call center agents and their systems.

Yeah. Somebody asked a good question about faxing.

They say sometimes customers fax a a primary account number to them. Does the phone system become part of the CDE?

Technically, the the fax machine itself should be protected in some way, and, of course, the paper that it creates. So one problem we see in faxes is, people like to do electronic fax these days.

So, you know, once again, somebody faxes you a card number. In reality, your eFax sends it in email to you. So now, it's not really a fax anymore. It's now electronic data.

And that would be storage. And by the way, it's typically unencrypted and PDFs can easily be discovered.

The the the primary account numbers in there can easily be read out of them. So if you're going to do a fax, get just a stand alone fax with a POTS line as somebody mentioned.

Yes, it needs to be the protected and by that, I mean, keep it in a secured area where, you know, you can monitor for when a fax does come in so that it doesn't sit there for a long time. And then you just have the burden of of properly securing that paper once it comes through.

But, that's a very simple thing to secure.

But, you know, it it doesn't require, any extensive work to secure that.

Somebody asked, if you use p two p e and all processing of cardholder data is outsourced to a PCI DSS validated third party payment processor, what steps do you need to take to be PCI PCI DSS compliant?

Really good question.

You know, I would in all truth, if I'm a QSA and you and I'm coming to you, you've hired me to come in and and do an assessment and whatnot.

I would ask that question. I would do the data discovery things that I mentioned. And if it came down to really you had outsourced everything to a third party, then basically, you know, you're still you still have a PCI compliance burden. The PCI Security Standards Council won't let you out of it altogether.

But it's for the most part, it would be down to, requirements twelve eight and twelve nine.

Now that's saying that you have no backups, no storage, you don't get card data anywhere else.

Truly, you've outsourced everything to somebody else, then it kinda comes down to twelve eight and twelve nine in terms of monitoring service providers and and who's who's handling which requirements and things like that.

Somebody asked about, compensating controls, eliminating the need to separate a database server from a web server in an environment that does not store the pan, etcetera.

Not exactly the simplest question to ask without a little more background on it, or I should say to answer without more background. But in general, there is a requirement in section one that says that, one primary function per system.

So mixing a database server and a web server, even if it's not storing, is really two independent functions. And really, they have completely different security profiles involved.

Kind of the idea when looking at combining functions into a system is think about the attack surface that is involved with the system. And if they have different security profiles, if you will, involved with the system, like you would secure a database differently than you secure a web server, then really they have two separate purposes and they should be on two different machines.

And if on the other hand, you know, many firewalls will actually you can configure them as your NTP server.

You know, all the systems already communicate with the firewall, so the fact that you're also having it broadcast NTP internally, not a real big additional security risk in any way. So it didn't really change the security profile of that device. And so having those two together doesn't necessarily create a problem. Having a web server and a database together, that's that's a little more problematic and really not that separation. You know, one one, main primary purpose for each system.

We had a couple of people ask if, receiving primary account numbers in email is your email server in scope for PCI.

Short answer is yes.

It's and that's electronic storage as well. And, frankly, email systems are very difficult to secure.

We, as a QSA, we we strongly encourage our our, customers to try and find an alternate solution for that.

You know, you think you deleted an email, and it's not really gone. It's It's this big relational database. It's it's will exist for some time there. If you're receiving lots of pans in email and things, and really you've got a lot of them in that mail database.

And, it's really, you know, they yeah, it's it's difficult to secure email. And, yes, it is considered in scope for PCI.

Yeah. Somebody asked about, you know, vendor branded cards.

So brief brief history on PCI DSS.

You know, a little over ten years or so ago, the different card brands, Visa, Mastercard, and things, had their well, like, Visa was called KISS, cardholder information security program.

And it basically were the require you know, it was their set of requirements that each of their merchants who took Visa cards was required to meet.

Mastercard had a a similar program.

About ten years ago, there were sometimes maybe a little conflicts between what one program told you to do and what another program said to do. So five major card brands got together and created the PCI DSS.

That's Visa, Mastercard, AmEx, JCB, and Discover, all got together and created the PCI DSS, which is this unified set of security requirements that all people who take credit cards are required to meet.

So, specifically, you know, it was kind of originally targeted at all of their their brands of cards and things. So back to this idea of do vendor branded gift cards really, count as as pans from a Visa, Mastercard side.

If it's not one of those five major brands cards, so it's not like, let's let's you know, it's a Best Buy card, but really was issued by AmEx as a gift card or something. That's an AmEx card in that case. But if it's really just a, you know, a vendor branded credit card of their own, then that vendor is the one who would set the requirements on how to secure it. Having said that, using PCI to secure the information is not a bad idea.

As a matter of fact, it's a good idea. It's a good basic set of security requirements, but technically not, you know, falling under the same scope as the other major brands of cards.

Somebody asked, kind of a generic question of what is a cardholder data discovery tool and, it says, you know, pan scan for PDFs.

Yes. Pan scan will go through PDFs.

It will actually look through pretty much any file you pointed at.

It will not, for the most part, detect binary type stuff.

But it does have the ability to open zip files as long as they're not password protected.

It has you know, it will look into PDFs and things.

So generically, though, back to the first part of the question of what's a cardholder data discovery tool. There's a variety of them out there. PanScan is obviously ours, but you can do regex searches.

They don't always detect track data. If you did a Google search, you could find, you know, basic regex searches for looking for cardholder data.

Like I said, they won't necessarily find track data because it's formatted differently, but it would discover the pan inside the track. And then when you go investigate the pan that it found in the file, you may see what is really track data. Now if you don't really know what track data looks like, then you might not know you really had it. But, it has a very specific track one and track two have a very specific definition of the information that's in there, field separators and things like that. And you can find that out on, both PCI security standards website as well as I'm sure it's on Google.

You know, other tools out there, Spyder used to be one.

There are other people who have discovery tools. Data loss prevention tools actually, can also DLP is, you know, the acronym on that.

They will also typically look for cardholder information, both in email as well. If you tell it to some of them, we'll be able to scan through files and things. And that's another way to kind of prevent it from either occurring or moving out of your organization.

Somebody asked, would vendor hosted applications who are responsible for their own compliance also need to be considered for the data flow diagrams beyond drop off and pickup?

If they're a PCI validated service provider, no. You don't necessarily have to know all the ins and outs of what's going on inside their system.

That's part of I'll go back to twelve dot eight and twelve nine. Twelve eight says that you have to have a process to engage service providers. You have to have the legal agreements in place. You have to monitor their compliance on an annual basis. And now, the addition in three o, you have to have a list of all the requirements they're responsible for versus what you are responsible for. So if you're just kinda you you drop it off at that third party and they're PCI compliant, you've got all those other things in place, then no. You don't necessarily have to to understand how their environment's architected.

Well, I I certainly appreciate everybody's questions. There's been a lot of them. I know some people have asked, things about, like, SAQA versus AEP and things. We have some resources.

We'll have some people reach out to you. We're getting toward the end of the conference here or the webinar, I mean. And, you know, to answer that question would probably take a little more time than we have right now. But I really appreciate everybody's comments.

I hope we've, helped you out a little today. Thank you.

‍