Watch to learn how to prepare for level 2 PCI compliance, as well as how to manage your university's merchants.
Having issues accessing the video above? Watch the video here.
In this webinar, Michael Simpson, Principal Security Analyst (CISSP, CISA, QSA), covers:
This webinar was hosted on February 27th, 2019.
Okay. Welcome everyone to our webinar this morning. This is PCI compliance one hundred and one for universities.
And my name is Andrew, and I work in marketing here at Security Metrics.
And our presenter today is Michael Simpson, and he is the principal security analyst. And he holds the credentials of QSA, CISSP, and CISA.
And another interesting fact about Michael, he actually worked in a university environment for about eleven years. So he has a lot of experience and knowledge working in PCI compliance in the university space. So he's gonna have a lot of good tips for us today, a lot of things that can help you in your specific environment.
So just a couple of housekeeping items before we get started.
We expect this webinar to last probably about forty five to fifty minutes and then we will leave about ten minutes at the end of the webinar for questions.
So please, if you have any questions that come up, feel free to chat those in using your GoToWebinar control panel, and we will respond to as many of those as we can at the end of the webinar.
If we run out of time and we don't have time to get to your specific question, we will reach out to you on an individual basis within the next week to make sure you get that question answered.
That's something that's very important to us. We always wanna make sure that we answer every question that comes in to our webinars.
Just a little bit of background before we dive in about security metrics.
So we've been in the business of helping organizations comply with security mandates, avoid security breaches, and recover from data theft since two thousand.
So our areas of expertise include the PCI DSS, HIPAA, GDPR, any any of these compliance mandates that, help you secure sensitive information.
And again, just another reminder, we will send out the recording in the slide deck, upon the conclusion of the webinar today. So keep an eye out for that in the next few days.
We'll we'll make sure to get that sent out for your review.
Well, at this time, I'm gonna go ahead and turn the mic over to Michael, and then we'll dive in and get started. Thank you.
Alright. Thank you. And thanks for joining the webinar.
We like like was mentioned, we will have a Q and A session at the end. So if you have any questions, as we're going along, use the question, you know, use the comment field to just enter those questions so that we can address those when we get to it. I wanted to start out just by talking about the agenda for today, what it is we're going to be discussing. First, we're gonna talk about how to scope a university assessment, from a PCI standpoint.
After that, we'll talk about establishing and maintaining your own internal PCI compliance program and then how to prepare for on-site PCI DSS assessment.
So first scoping a university assessment.
Right now for the last several years I've led a team of assessors who focus on working with our government entities, our higher education, customers, and our large enterprise environments.
One one thing that I've noticed, over these years is that the university environment and the the government environment is it's really a different beast when it comes to PCI.
Typical merchant assessment or even a service provider assessment, there there'll be one, two, maybe a small handful of payment flows that are part of their credit card environment. So when we talk about scoping a PCI environment and how that scope includes the the people, processes, and technologies that are involved in the the collection, storing, processing, or transmission of data, For a typical environment, it is a much more simple exercise to identify what people, processes, and technologies are involved in that scope. A university, however, or a high, you know, higher education, group, they will typically have, you know, between a hundred or two hundred merchant accounts, and each of those merchant accounts may have multiple payment flows.
And so your PCI scope will include all of the people's processes and technologies that are involved in the storing, processing, and transmission of data for all of those payment flows for all of your merchant accounts. So it's it's a it's a bigger beast to to deal with. So how do you begin to tackle such a complicated environment?
Let me start by saying that Security Metrics does not advocate the killing or consuming of elephants or any other endangered animal.
But, just as an elephant can be eaten one bite at a time, university compliance can also be broken down into smaller achievable goals.
By breaking down your scoping and your compliance activities into smaller goals, you not only are able to better understand your merchant environment, but you're able to have little wins along the way and and and it gives you that drive to to continue going forward until you're able to to finish, compliance for the university.
So so typically, the best place to start when scoping a university environment is by contacting your merchant bank. Most universities will have a primary merchant bank that they work with.
The treasury department or the bursar's office is usually a good place to start to to get that contact.
A lot of times that's where the driver for PCI compliance is coming because they're the ones working with the merchant bank.
But sometimes it's not. Sometimes I've seen universities where their CISO office or their IT security office is really the driver for PCI compliance. So so the first thing you need to do is really identify all of your merchant accounts.
So work with your merchant banks, and realize that there may be multiple merchant banks. Typically, a university will have one main merchant bank, but there may be some outlier accounts that are held by another another bank or processor, you know, sometimes maybe Bank of America is your is your primary merchant bank, but you may have some, campus merchants who because of the solution that they've chosen, they their merchantite account is held with, you know, PayPal or some some other merchant bank or payment gateway.
And then there will also likely be some payment flows that are using the merchant account of a service provider. And these can easily fly under the radar of your merchant banks. They will have no idea because no credit card data is going directly into their accounts.
And sometimes it even flies under the radar of the bursar office or the treasury office.
If if a department goes out and opens a Square account and all of the payments are being processed using that MID of Square.
Or there's other, you know, there's several service providers out there. I've seen a lot of universities they have T2 for their parking garages. And sometimes t two will be set up in a way that t two is using their own merchant account, which can help simplify compliance, for the university, but there still is a risk there that should be addressed.
So all of the payment flows, regardless of who owns the merchant account, really should be included in your scoping exercise just so you can make sure the appropriate security controls are in place to address the risk that's brought onto the the university.
The next thing that you'll wanna do after scoping, so so or after after look, coming up with your list of merchant accounts is to identify the primary contacts for each of those merchant accounts.
So there should be someone for each of the departments or each, university merchant, whoever has chosen to start accepting credit card payments, that is responsible for that account. You'll need those primary contacts for for the next step.
And and the next step really is once you have that list, start finding out what the payment flows look like. So you'll want to go into a discovery phase where you're working with each of these. I I call them MRPs, your merchant responsible person. Each MID should have identified one person who's primarily responsible for the compliance of that environment.
Work with them to figure out what the payment flows look like. And there may be, like I said, multiple payment flows for each merchant ID.
So find out, you know, what are the ways that they're receiving credit card data. Is it coming via e commerce? Is there mail order telephone order? Are they handling card present transactions?
Are they receiving credit card data through fax machines? Are they receiving credit card data through email?
Try to find out exactly how credit card data is being received, who's involved in that process, how it's being processed, if there's any storage of credit card data in the environment, whether it's electronic storage or paper storage, and then where that data is going after it's been received, how how that's being transmitted, to to the processor or to the merchant bank.
Realize that, as you're going through this scoping, it's going to be a difficult process. There there's a lot to look at. There's a lot of data, to go through. And as you're scoping the environment, you're probably going, especially if this is your first time, you're probably going to encounter some problems.
You know, and and we'll talk about some of the problems that that you should keep an eye out for. But, you know, maybe maybe you find out that someone is receiving credit card data through email, and and that brings your campus email infrastructure into place, and maybe it brings your entire campus network into scope, for PCI.
If if that happens, don't get frustrated. You know, as part of this process, it's one of the reasons why we're going through this process is to identify those issues.
Let the merchant know the problem, help them to, you know, educate them, help them to understand what their payment flow, like the decisions that they've made and how they're processing and receiving credit card data, how it affects the university as a whole. And give them some suggestions for how they can correct that and then just make note of those issues so that when we get past the initial scoping exercise and we start working on our compliance program, you can circle back and make sure that those issues have been addressed.
So the next thing I wanna do is just quickly go over the different SAQ types. Because once once you identify each of your merchants and you've got you know basically how their payment flow look looks and and and what their, processes are, the next step I would recommend is to kinda put them into an SAQ level so they understand, you know, based on my payment environment and the way that I process payments, these are the PCI requirements I really need to be focusing, Ian on.
So the first one I wanted to talk about is the SAQA. A lot of, campus merchants fall into this category.
SAQA can be, a mail order telephone order process that's fully outsourced, though I don't see that very often. Typically what we see for SAQA merchants, it's an ecommerce environment that has been fully outsourced.
So so maybe the, you know, the the students coming onto your website to sign up for, some type of a a course or seminar that you guys are having or maybe there's products that you're offering.
But before they get to the point of entering their payment data, the university website is fully redirecting their browser out to the payment gateway. So let's say you're using, you know, authorized dot net or pay pal. Their web browser is redirected to that third party and the collection and processing of data is all handled by the third party. That's one example of an SAQA. Another example of an SAQA would be maybe a customer stays on your website and they're entering in all of their data, but your website brings in an iframe from the payment gateway.
So the customer might not know that part of the website that's being shown on their web browser is coming from the payment gateway, but as long as all of the collection and processing of credit card data is performed using an iframe from your payment gateway, your your PCI DSS compliant third party provider, then you could still qualify for the SAQA.
Typical scoping issues that I see with SAQA environments, people who I you know, self identify SAQA and then we come on-site, one is that they are not fully outsourcing that data to third party. So some some websites will be configured in a way where they're actually collecting the data, holding it in memory, and then using an API call to send that to the payment gateway.
If your website touches that data at all, even if it doesn't, even if it's never stored to disk, that website, that environment would be an SAQD environment. So just be aware of that. SAQA, you cannot be part of the flow of credit card data.
The other issues we'll talk about when we go to the next slide for SAQ AEP.
But one of the other common problems that I see, university employees tend to be very friendly and very helpful, which is wonderful. University environments are great, but sometimes their helpfulness can cause compliance issues. So if if they have customers coming in person and saying, hey. I wanna sign up for this seminar, but I'm having a problem with my computer.
Can you help me out? If if you have staff that are going to your website and entering credit card data for your customers, then you no longer qualify for the SAQA because you are no longer outsourcing all collection and processing of data to that third party. You're doing some of it yourself on the staff workstation, and that typically is just some general purpose staff workstation on a general purpose network, and that is an easy way to bring your entire campus infrastructure into scope. So so be aware of that when you when you're scoping these environments.
Make sure that if if they have an ecommerce environment and they're working towards validating using the SAQA controls, that they are not entering that data themselves. This is their customers entering the data into the website, directly.
And then so the SAQ AEP is very similar. This is another ecommerce channel where the collection and processing is fully outsourced, but you're using a method besides a full redirect to the third party gateway or an iframe.
One example would be like a direct post, or using JavaScript to, you know, the the customer's web browser when they're entering data into the different fields.
Your website is telling the browser, hey, when when they hit the submit button, I want you to send, you know, the the pan, the CVV data, all of the pertinent credit card information, send that directly to my payment gateway and send me the rest of the information. So your website is really the orchestrator that that is telling the data where to go from the the customer's web browser.
If if you meet that, you know, if if your website has that type of a control, there's a lot more there there's a higher risk, so there's more requirements that you need to make sure are in place in that environment. So that's what the SAQ AEP is for. Again, even with the AAP, your website cannot be collecting the data. Your website should not touch the credit card data. But if it is directing that flow, if it's telling the the user's browser where to post the data to, then then you are an SAQ AEP and not an SAQ A.
So so that's a typical scoping problem that we have between the SAQ A and the AEP. The a, if you're not an iframe or a full redirect, you're not an a.
The next thing to look at is does my website ever touch the data? If it does, you're not an AEP either. But if it doesn't, you may very well be an AEP.
The next one is the SAQB.
This is typically, you know, bank provided terminals that are connected to an analog line. That's almost always that's what we see for SAQB's. It could be a full paper process where you're using a an imprint machine or knuckle buster to to take credit card data and then you're mailing that to your bank, but I I just don't see that often.
Typically, you've got a, you know, POI device that's been sent to you by your bank and and it should be connected to an analog line. The problem that I typically see with an SAQB is sometimes they will not be connected to an analog line. We you can't, you know, connect these to VoIP lines or digital lines, they can't be connected to the IP connection of the device.
A lot of times on assessments, I'll be going through an assessment and I and I see that they, you know, this SAQ b quote unquote environment, I see that it's connected to an IP connection and not to an analog phone line.
And when I ask them, you know, why they switch from their analog line to their IP connection, they say, well, I called my bank because we were having some difficulties with the connection and they said just plug it into the network.
So realize that sometimes your bank may give you bad information.
You can plug these devices into a network but you have to secure the network that they're plugged into, which brings us to the SAQ BIP.
So the SAQBIP, very similar to a b, it's usually a bank provided terminal.
It's make you know, it has to be a PTS approved device, which usually your bank should be sending you PTS approved devices, but these are connected to an IP connection instead of an analog line.
One thing to realize and and with all of the SAQs, there's a section, that's titled eligibility criteria or eligibility to complete. You wanna look at those eligibility check boxes, and make sure that you can answer affirmatively each one of those eligibility criteria.
One of the eligibility criteria for the BIP is that this IP connected POI terminal is not connected to any other device on your network. And this is usually accomplished through network segmentation, so you cannot take a bank provided terminal and just connect it to your staff network and be eligible to comply with or to assess using the SAQ BIP. This needs to be on an isolated network segment.
Typically you'll have a firewall that only allows four forty three traffic out to the gateway or the bank, and it's not really allowing any traffic in. So we just need to make sure those are appropriately segmented.
The SAQC, this is, for, a little more complex payment environment. So you usually have, you know, maybe you'll have one or multiple, point of sale systems. You'll have maybe some workstations with software on it.
An example would be like a a pharmacy. You know, maybe you've got a a pharmacy that the the the school of pharmacy manages or maybe they have multiple sites and they're running Rx thirty or some other payment application that is processing credit card data, for that merchant environment.
One thing to make sure with the to be eligible for the SATC, they cannot have any electronic storage of credit card data.
If they're storing data electronically, they they do not qualify for the SAQC. They need to be using the SAQD.
The other requirement eligibility criteria to be aware of is that they if they have multiple physical locations, those locations cannot interconnect. You know, we need to have an individual LAN per location and and and they don't they don't have connectivity between the the multiple locations.
And the reason for that is the SAQC, even though it is one of the larger SAQs, there are several requirements that are are not in the SAQC that should be in place if you have a more complicated network environment like that.
So, one thing to look out for there. And then the SAQ CVT. So this is a this is a fairly simple SAQ. You see there's only seventy nine questions in the SAQ, CVT.
This is where you're using a a workstation, a dedicated workstation that's on a isolated network and you're connecting to a virtual terminal. So maybe that this virtual terminal, you know, it's a website provided by your bank where you could go key in credit card data, to process payments. And that this data can be received, through, you know, in person transactions or it could be through the mail or over the phone. But all the data is being manually entered using the keyboard through that, you know, web browser connection to the PCI compliant virtual terminal.
Problems that I typically see with the CBT, if if the department that is using a CVT to process credit card data has is doing a lot of card present transactions and they decide, you know, this would be a lot easier if we connected a USB card reader to to this terminal. So instead of typing in the sixteen digits, we can just swipe the card.
If you have any type of card reader, any anything that's directly contacting the credit card, you don't qualify for the SAQ CVT. And again, the reason for that is the CVT does not have the appropriate requirements to to address the security concerns of that type of an environment. Requirement nine dot nine, which has to do with the physical security of these, you know, swipe devices are not included in the SAQ CBT. So if if you have swipe devices, you you do not qualify for the CBT.
The other thing to realize too, again, there's a network isolation component here. So they cannot be using their standard, you know, staff workstation that's connected to everything on campus and, you know, they're receiving emails and going, you know, doing research or whatever. This this is an isolated environment. It's part of a payment environment, and that's what the device is used for.
The SAQ P2PE, this is the newest of the SAQs and one of the smallest. You you'll notice very few questions in the SAQ P2PE.
The SAQ P2PE, so this is for a point to point encrypted environment that has been validated and listed on the council website.
So when when you swipe or dip the credit card into this P2PE terminal, the terminal is strongly encrypting that data before it sends it out, through the network or or through the the workstation it's connected to. So even if someone were to be able to capture that data in transit, there should be no way for them to unencrypt that data. The the merchant will not have the merchant or the university will not have the decryption keys, so only the PTPE solution provider will be able to decrypt that data when it gets to their back end infrastructure.
The problems that we see, and and I'm seeing it a little less than when P2PE first came out, when when P2PE first came out, everyone out there that had any type of end to end encryption solution was trying to market themselves as a P2PE solution.
So there's a lot of times where we'll go on-site to a to an environment that is supposedly, you know, a PTPE environment and we find that the they have an end to end encryption solution, but it's not a listed solution that has been validated.
And we can't use the SAQ PTPE if it's a non validated solution, because we need to make sure that all of the process involved in the key injection, all of the physical security of the both the key injection facility and the physical security of the devices between injection and the time they get to your location, all of those appropriate controls are in place, to secure that payment data.
The benefit of the P2PE, if you're using a listed P2PE solution and your payment terminal is a validated terminal to be used on the solution, it's running the right hardware, you know, if you truly have a p two p e, environment, it really it just takes your network out of scope from a PCI standpoint, because that data is strongly encrypted before it hits the network. Or there's some PTPE terminals that are, like, USB connected to a workstation, and all of the data is entered into that USB terminal and it's strongly encrypted before it enters the workstation and then goes out to the the payment gateway or the PTPE solution provider. So this this again takes that workstation out of scope because that workstation no longer is receiving, processing, or transmitting credit card data. It's only, you know, transmitting this strongly encrypted data and has no ability to decrypt the data.
And then the last one is the SAQD. And the SAQD, we've got, this is basically the full PCI DSS standard. There are two SAQDs, be aware. That there's there's the SAQD for merchants, which most universities are gonna fall into that, bucket. And then there's an SAQD for service providers. It has some additional questions.
And there will be some times when a university will be a service provider. So if you let's say you've got, you know, in your food services area, maybe you have a restaurant that's a complete third party, it's their own merchant account, they're processing data and they're just basically renting space, in your environment. If you provide security services for their CDE, you know, if you're saying, hey, we'll handle all of your firewall for your CDE, then you are now their service provider and you should be looking at completing an SAQD service provider for that environment.
If all you're doing is being an ISP in that situation and you're not providing any security services that doesn't make you a service provider, be aware of that. There's an FAQ out there from the council that specifically addresses that and that a lot of universities run into, that solution or or that problem where, you know, they are basically just acting as an ISP, but they don't wanna be part of that third party's payment environment and that is totally acceptable as long as you're not as long as there's no implied sense of security. You know, you can you can protect your own network.
I know my ISP at my house, you know, when I connect to to their network, I I'm not on some flat network where I can attack any other of their customers. You know, so you can protect yourself as an ISP, but do not if you don't wanna get into the SAQD service provider role, you know, don't become their PCI service provider.
Don't, you know, don't offer, firewalling for their PCI environment. Have them let them know they're responsible to have their own firewall. You know, if if you provide any other security services for them, you know, let's say you're helping them with their antivirus or or their log monitoring, you know, anytime you get into that role where you are providing security services for another organization's PCI environment, then you become a service provider.
The other thing I wanted to talk about now that we've kinda gone through the different SAQs, don't try to shoehorn yourself into an SAQ that doesn't fit, because what you're doing if you do that is you are, you're not appropriately addressing the risk that your organization faces, by accepting credit card data in a particular manner. So you wanna make sure that that you are using the appropriate SAQ for your payment environment.
The next thing I wanna talk about when it comes to scoping, look into how you can reduce scope in your environment.
Start start by focusing on those bigger higher risk environments, your your SAQDs and your SAQCs.
Look at any electronic data storage. I I work with a lot of large universities that have been able to completely eliminate any electronic storage of credit card data. But maybe maybe there is a reason for that electronic storage. So any anytime you have a merchant on campus that's storing data electronically, find out what the purpose of that is. You know, make sure that there is an actual reason and do a cost benefit analysis with them and decide, okay, Maybe there's a a a benefit that you're receiving for storing this credit card data, but is it coming at a higher cost?
Would you be better off reworking how you manage your your payment processes to eliminate that storage of data because that really would help not only to reduce your compliance efforts, but it reduces the risk that you face. And that that really should be what we're focusing on is reducing your risk.
And then the next thing to look at, can you leverage a point to point encrypted solution environment, you know, or solution to, to eliminate some of your SAQC and the environment? So so these more complex, point of sale solutions, Can you implement point to point encryption to be able to reduce the risk and thus reduce the scope of your environment? And this shouldn't be just part of your initial exercise. The whole scoping that we've talked about. Obviously when you're starting PCI compliance scoping is kinda where you start. But scoping is an annual exercise mandated by the PCI council. So this should be something that you're going through every year, revalidating your scope with all of your merchants.
And every year, while you're doing that, look at look to see how you can reduce that scope or another way to put that, how you can reduce the risk in your environment.
So now that we've talked about scoping, how do you build a successful campus compliance program?
Compliance can be really difficult, especially in a university environment and especially that some university environments are more decentralized than others.
Sometimes each individual school on campus, each department, they're kind of a silo in and of themselves. You know? And there's it it's very difficult if someone from the, let's say, the CISO office or someone from the bursar's office, they've been put in you know, they've been tasked with maintaining compliance, but they have no authority to enforce anything.
So so there's a couple of things that can help make this task easier. And the first one is get that executive buy in.
PCI requirement twelve dot four dot one. This this only applies to service providers, but in my opinion, it really should apply to everyone and it's especially helpful in a university environment.
What this requires is that you have a documented charter that describes how you manage PCI compliance in your environment, who's responsible to ensure that that you guys are maintaining compliance, how you communicate your compliance efforts up to the executive level. It should never be a surprise to, you know, your vice presidents or the president on campus that that there's a compliance problem. You know, they it shouldn't be a surprise to them that that they somewhere on campus, some some, department is is processing data in a way that is bringing the campus at risk of a breach.
That that should be part of the communication process. And if there is a problem, if you have that executive buy in, they can help to give you the political ability or or, you know, the power to be able to actually enforce changes and to to to make people come into compliance.
I worked with a a state institution that recently hit level two status and they had this problem where they were, you know, their their treasury department was responsible for PCI compliance, but they had no oversight over these different state entities.
So, you know, the first thing they had to do was work with the governor's office and and get something in place so that they would be able to have some leverage over each of these departments. So if someone was, if someone chose not to be compliant, they didn't bring the entire entity out of compliance. So they would be able to pull their merchant account, their ability to accept payment card data if they weren't bring if they weren't securing those payment channels. So executive buying is really critical to to having a good compliance program at a university.
The second thing that I think is really important is that you you you as one person, you cannot you cannot bring the full campus into compliance and maintain compliance. It's just too much work, especially for the really large university environments.
So if you've been tasked to kind of oversee PCI compliance effort, you need to help to push that out to the people who are really responsible for this. So anyone who's chosen to accept credit card payments for their department, let them know that as part of that decision, they are also accepting the responsibility to maintain compliance of that payment flow.
And you're there as, you know, a resource to them, you're there to help them understand what needs to be done, but it's their responsibility to to maintain compliance. So you'll be working with them to help maintain compliance.
The other thing that you need to do in a university environment is kinda determine who's responsible for what.
A typical merchant has to do this when when they're just looking at their different service providers. You know, they if if they have two or three service providers that all have, you know, maybe some of them are receiving credit card data or maybe some of them are helping to secure their firewalls or other, parts of their their infrastructure, They need to document who's responsible for what, so they can make sure that everyone understands their role in the payment environment and and can, be filling that role. In a university environment, this this can kind of be even more complicated because maybe some of these, some of the responsibilities will be handled by the merchant, some of them may be handled centrally by the the treasury office or the IT security office or the, or the just general IT department.
So so you and some might be, you know, outsourced to a third party. So you really need to determine, who's responsible, at the merchant level and then who's responsible for each, you know, PCI requirement.
Some of those examples of what I was talking about, you know, a lot of times policy, especially what I call like capital p policy, there's there's usually a policy board on campus that helps to draft and and approve policies. And a lot of times, you know, making changes to that policy is a very rigorous process. It doesn't happen very quickly.
So maybe some of the PCI element the policy elements will be addressed by campus policies, but maybe some of those need to be addressed by departmental procedures.
So so you, you know, look into that. Vulnerability scanning, you know, maybe that's handled centrally by your IT security officer, maybe each individual merchant's responsible to to run, you know, vulnerability scans against their environment.
Requirement twelve dot eight where you're listing your service providers out and you're reaching out every year to, you know, make sure that they're still compliant, you're asking for their attestation of compliance.
Some universities, they have the the bursars or the treasury office handle that requirement.
Sometimes they'll have the individual campus department responsible for that, for for reaching out and getting the AOCs from the service provider. So and and sometimes it's a mix. You know, maybe the campus is getting the the big ones that a lot of people are using like, you know, the PayPal and the authorized dot nets. But but maybe if, you know, an individual campus department has another third party that, you know, they're the only one that uses, maybe they're responsible to to oversee that, their compliance to to make sure that they maintain compliance.
So once you find that, be sure you document it. You know, create a matrix, create a a document that each merchant has where they know, okay, these are my PCI requirements, that I'm responsible to maintain and these are the groups that are helping me to maintain them so that they understand, you know, what what they really need to be focusing on and maybe ones that they don't have to focus on as much because another department on campus is handling those on their behalf.
Once you kind of identify those responsibilities and help them understand the responsibilities, I think the next thing to really look at is is education.
We need to make sure that anyone who's part of these payment environments, really understands their role in the environment and they understand, you know, they have security awareness training so that they know what are some of the vulnerabilities or some of the attack vectors that they need to be aware of and how can they prevent those from, negatively affecting their payment environment.
There's there's a general twelve dot six secondurity requirement that just says, you know, every at higher and annually you're you're giving your staff security awareness training. And then for for those departments who have a terminal, like your SAQ b's or your SAQ PTPE's, your c's and your d's, If they have a device that's physically interacting with a credit card, then requirement nine dot nine has its own, training requirement where, you know, they need to be trained to to be able to prevent and to spot tampering, problems on on the terminal. And they need to know if they see a problem, who they report that, to so that, you know, the an incident response process can go through and you can determine if there has been a potential breach or if there's, you know, a problem that needs to be addressed.
So so these are some of the training requirements. You need to decide, you know, as a campus, are we gonna handle these centrally? Is there gonna be like a a central training portal that everyone that has been determined to be part of one of these campus environments gets enrolled into and it kind of forces that training, or are we gonna make that, you know, be a responsibility of each department to do their own training and to be able to document the fact that they are doing training.
Other other training to be aware of is your incident response. A lot of times, usually, incident response is done at a campus level, but each of these departments that are handling credit card data should be aware of that campus incident response process and their role in that process.
If they're not, then if they have a potential problem, maybe they have an ecommerce site and their ecommerce site has been defaced or or breached in some way. If they don't know that they should be contacting, you know, let's say the CISO office or the Treasury to kind of start the campus incident response, you know, maybe they'll just say, Oh, looks like our sites had a problem. Let me just fix that really quick and get back to going. You know, maybe you haven't really addressed the problem that's actually happened.
So so make sure that that training includes how to handle incidents.
Risk assessment's also something that sometimes that's handled centrally as a university level, but but there probably should be a departmental level risk assessment where they're looking at how we can reduce risk in our environment.
The other thing that I think is important is regularly following up. So we talked earlier about identifying an MRP or a merchant responsible person for each of your merchant accounts. You, whoever's in charge of compliance for the campus, should be following up regularly with these people to make sure that, you know, they're you're answering questions that they have. Help them understand any new PCI requirements that are coming, down, that that they will need to to to put in place.
The other the other thing that I find really helpful is there may be staff turnover issues. You know, maybe you've got a merchant account where their MRP gets a job somewhere else on campus or maybe off campus and no one steps in to fill their their their position.
A lot of campus environments you cannot hire a replacement until the person leaves so so you tend to lose a lot of information. So, you know, if your MRP leaves, someone else comes on and they don't know that they're supposed to maintain your PCI compliance, you can easily come out of compliance. So doing regularly regular follow ups with your MRPs will help to make sure that that's not a problem.
Part of that regular follow-up is is identifying any changes that occur in the environment.
Requirement six dot four dot six, it's a newer PCI requirement that deals with significant changes in the environment. From a SAQ standpoint, this only really affects SAQ c's and d's, and I think the AEP.
But as a whole, your campus is likely gonna be an SAQD. So this is really something you should have in place, a way to identify significant changes in the environment. The the reason for this requirement, as far as I know is too many companies were seeing PCI compliance as an annual process. You know, they would have their assessor come on-site once a year, they would assess the environment, if there were any issues they would address those issues and then they'd get a, you know, piece of paper that said, Congratulations, you're PCI compliant.
And then some of them, they would just kinda forget all about PCI compliance until it was time for their next assessment. So sometimes they, you know, they'd have a QSA come on-site, they'd do an assessment, everything, you know, looked fine, they were compliant, but then a month later, they totally changed their payment flows. They had a whole new environment, and they didn't do anything to make sure this new environment's secure or compliant until their assessor comes out the next year and goes, oh, wait. What did you guys do?
You know, so so this requirement six four six it it basically states that you have a change management process where after a significant change happens in an environment, you guys are reassessing to validate that you guys are still PCI compliant.
So so this is something that you should be working with your MRPs to know, you know, let them know that if if they're looking at making a change to the way that they process data that they communicate that with you, prior to the the change being made. So you can kinda talk through potential problems and and pitfalls and help them understand, what they would have to do to bring this new environment into compliance.
And don't hesitate. If you guys have a QSA, don't hesitate to reach out your QSA and get them involved in the planning process so that you you you it's easier to set it up right the first time than it is to try to address problems after the fact. So that's one thing. As part of a campus compliance program, you gotta be able to manage changes in the environment.
Alright. So the next step is how to prepare for an assessment. If you are a level two merchant then you're probably required to have an annual assessment performed by a QSA.
Part of preparing for an assessment is just documentation.
It seems like at least half of PCI is making sure you've got policies and procedures documented and you've got evidence that shows that you're following your policies and procedures.
So make sure your MRPs, all of your merchant account, you know, your merchant IDs, they're they are going through a process regularly to look at their documentation and to update it.
So this would be, you know, if there's changes, make sure that they're that affect their flow diagrams or their network diagrams, make sure those are up to date. Go have them go through their policies and procedures, have them look at their, you know, list of employees that are part of their environment, make sure that everything's up to date so that you are ready for that assessment.
One thing that kind of helps with that is by creating what I'd call a merchant binder.
What what I've seen helpful is is if the treasury or the bursar's office is responsible or or if the CISO office is responsible for compliance, create some binder templates, for each of the SAQ types. So if if you've got a new merchant on campus or or department comes to you and says, hey, we wanna open a merchant account. We wanna start accepting credit card data through ecommerce flow, and we're gonna use I modules, you know, to to accept and, process our our data. You know, they would very likely be an SAQA merchant. So give them that binder, which would have the SAQA in it, it'd have a place for them to put their network diagrams or flow diagrams.
Since it's an a environment, it'd have a place for them to have a list of all of their third party service providers, including their payment gateway.
It'd have a place for them to put the AOC from from that from all of those third party payment providers. It'd have a place where they could document, you know, the, the hardening standard that was applied to their web server. It'd have a place where they could put documentation that shows that they're maintaining patches as required by requirement six dot one and six dot two.
So it it basically helps them to maintain compliance.
It's a place where they could put a repository of all their documentation to show that they're compliant.
One of the one of the benefits of doing this merchant binder approach is really that staff turnover problem really is not that big of a deal. If an MRP leaves and new one comes on, you know, after the fact and and there's no knowledge transfer that can happen because the MRP's already gone, then the binder can be that knowledge transfer. Just by reviewing what's in the binder, they'll know their PCI environment. They'll know the requirements they have to abide by. They'll know who's responsible for each of those requirements and they'll have documentation in there that they can just continue to update to show that they're maintaining compliance.
And then the last step is an internal examination. If you really wanna be prepared for an external assessment, the best thing you can do is do internal assessments. So spend time. As you guys are doing these quarterly follow ups with your MRPs, actually go through the documentation with them.
Make sure, you know, that go through the scoping exercise with them. Make sure they have the right SAQ. Look at the evidence that they're maintaining. You know, verify that that they are maintaining all the applicable PCI DSS controls that would secure their environment and reduce the risk in their environment.
So kind of the takeaways from from what we talked about today. One, validate your scope.
Obviously, the first time this your initial scope scoping exercise is is going to take you a long time. It it it might be it might be months for you to go through and make sure that you understand the full scope of of the university environment. But this is something that you really need to do annually, is to go through your scope, make sure you understand it. The next thing is help the merchants feel responsible for their own PCI compliance. You are there as a resource, and you are there as a cheerleader. You know, you're there to help inform and educate and and, you know, facilitate compliance, but don't try to take on the full burden of compliance yourself because you will not be able to bring the the merchant environment into into full compliance if it's just one person.
And then regularly update the documentation.
Make sure, you know, like I said, policies, procedures, diagrams, make sure it's all up to date. All of the evidence that shows that they're compliant, keep that updated. That will not only help with your assessments, but that really will help to foster this, continual compliance attitude. You know, help help the merchants to realize that compliance is not once a year, that this is a every day of the year effort to to maintain compliance in the environment.
And then regularly conduct your internal audits. So, spend some time with them, make sure that they're ready, for their assessment, look at their binders, look at their evidence that they have, you know, do do a quick sanity check to make sure that that you do you have properly scoped your environments, that you guys have the appropriate controls in place.
So an internal assess or an external audit, it really should just be a validation that says, yes, your internal compliance program is working.
So with that, we're going to pause a little for a second to look at the questions that have come in, and then, we will go to the question section.
Alright. Thank you, Michael, for sharing some of this information with us today. We had a lot of great questions come in. And, first of all, we had a couple of questions come in regarding p two p e. And, if you could take just a minute and address, first of all, we had a question, what SAQ do we qualify for if we use a p two p e terminal, not a validated solution, but a validated terminal encrypting at the swipe connected with an IP connection. Does that still need to be a separate dedicated IP network that only allows forty three traffic?
And then related to that, regarding p two p e, is my understanding correct that any network can be used when using a P2PE validated solution?
Alright. So those are good questions.
The first, if you are using a P2PE validated solution, yes, the network is completely out of scope.
You could technically connect these to the Starbucks open WiFi, and you'd be totally compliant. So because of the fact that the encryption solution has been validated, it has all of the appropriate controls to protect that data in transit, the network truly is out of scope and you can you can connect these anywhere. So so this is for a lot of university environments I've seen, where they have, maybe they've got an area where they don't there's no analog because they've gone all digital on campus. They've got, maybe poor cellular connection so they can't use a cellular bank terminal.
So they're left either using an IP connected terminal and having a dedicated VLAN for that, or using a PTPE terminal and they can plug it into whatever or connect to the campus WiFi. So PTPE can be a really powerful tool in your university environment.
So what happens if you're not using a validated solution? You you've got a maybe a PTS validated terminal and it is using end to end encryption, but it's not a p two p e validated solution. You do not qualify for the SAQ p two p e.
So you would have to then decide, okay, what do I validate?
By typically, what I find in those situations, if it is a PTS certified device, then you would typically be able to validate using the SAQ BIP.
But at that point, your your network is still in scope, so you still need to have the isolated network segment.
You'd still need to have firewall rules in place to protect that that transmission of traffic.
There's one caveat with that.
So the PCI Council has allowed, merchants who are using a non validated end to end encryption solution to reduce the scope of their environment and potentially bring their network out of scope. But that's something that has to be done, as as a conversation with your merchant bank and your QSA. So so your merchant bank really needs to understand the environment. They need to understand the risk.
The fact that it hasn't been validated, they need to understand why it is not a validated solution and what additional risks it may pose. So this is usually where your QSA would get involved to to review the environment, review how encryption keys are managed, how they're injected, what type of encryption is being used, if the merchant has any access to those keys, and and, you know, help the, merchant bank understand that because it's really the call of the merchant bank to decide if you can reduce the scope in your environment so that your QSA could look at the environment. I've had I've had some environments like this where, you know, we've talked to the merchant bank, we've let them know about the solution.
Verifone has a a non validated solution. A lot of merchant banks have their own non validated solutions. So if if the non validated solution is provided by by your merchant bank, usually, they will allow for scope reduction because they feel good about their own solution that they've sold you.
Sometimes if it's not their solution, maybe they'll say, yeah, you can take the inner network out of scope as long as you do a penetration test against the device to to ensure that it's properly protected. The device itself is protected from external attacks and and to verify, you know, that the data is strongly encrypted. So so maybe they'll give you a couple of hoops to jump through, and then if you jump through those hoops, then you can reduce the the or remove the network from your PCI scope. But if it's not a validated solution, you can't automatically do that. That can only be done you can only use the SAP P2PE if it is a validated solution.
Awesome.
Another question coming in here. If we use a VT with a USB connected device, what SAQ would we fall under if not CVT?
Alright. Another good question. So again, because the CVT does not address the physical security of that payment device, and there may be typically, I see more problems with unintended storage of full track data if if you're using these USB connected devices.
The the SAQ CVT is just not designed to handle that. So typically, if you are using, an SAQ or if you are using a USB connected device to that physically interacts with the credit card, you would be an SAQC as long as you can validate that you are not electronically storing credit card data anywhere. If you're electronically storing data, then then of course you would be an SAQD.
Great. So going back to, logging that you touched on towards the beginning of the webinar, what needs to be logged on servers, networking equipment, etcetera?
Alright. So that's a good question.
If you go through the PCI DSS requirement, ten, it it will specifically address what needs to be logged.
You know, so so any like account creation, that should be logged. Anytime an administrator, is is performing an administrative function on a server, that should be logged. You should be logging all authentication requests.
So really go through PCI requirement ten and it will tell you specifically what needs to be logged.
Logging, it's logging can be a preventative control, but it it's usually a detective control if if you have it set up well. You're really trying to identify potential problems that are happening on your network or your devices. You know? So if you're having someone trying to brute force your devices and and you're logging that and that log data is being, you know, reviewed, usually automatically, technically you can do manual review of, you know, daily reviews of your logs, but I I've never seen that be effective. So usually you'll have some type of, SIM solution that's that's monitoring your logs and alerting you to problems that it identifies.
Sometimes you'll be able to identify problems before they occur, you know, like in the case of a brute force. If you see someone's really banging on a box and trying to breach out a box, you can take some preemptive actions to to prevent further incursions in the network, or sometimes there'll be detective controls. You know, if your log data shows you that, you know, there's been an unauthorized change to your NTP configuration, you know, someone reset the clock on your one of your servers or pointed it to a different NTP server, you know, maybe that's an indication that there's been some type of a compromise on a system.
Or if you see that, you know, new administrative accounts have been created or new access has been granted and you're not aware of that, you know, that's another indication that there could be a potential, incursion. So so really logging is is a difficult and a complex thing to go over. We probably don't have time here. We could probably do a whole seminar or webinar just on on logging, but log as much as you can.
Go through PCI DSS and see exactly what they require you to log. And then just make sure that those logs are actually doing you good, you know. Part of the logging is so that if there's a problem, forensics can actually come in and find out what caused the problem and what was affected. But if you're using them correctly, the logging data can really help to prevent or minimize the impact of a breach.
K. Great. And we probably have time just for one more question here, and then we need to wrap things up.
But could you expand on the risk involved when the service providers are using their own MID and what our responsibility is as a university? What should we be asking for and looking for?
K. That's a really good question because there are on universities, there's a lot of service providers who will use their own Mid, and they'll sell it in the way that, you know, they'll say, hey, we're using our merchant account, so you don't have to worry about PCI compliance, which is not true.
Technically, if there was a breach in that environment, the, you know, Visa and Mastercard, the merchant bank, they would not be coming to you because it's not your merchant account. But that doesn't mean that the university doesn't have risk.
If there if you had a a breach, if one of your service providers had a breach and it was their merchant account, but it happened on your campus, how is that gonna be reported in the media? You know, is that going to be, oh, this service provider had a a breach and it affected their customers, or is it gonna be, oh, you know, news at eleven, university x had a breach and they're lost customer data. So there's definitely a reputational risk that's There there is also a potential, you know, it's kind of a it's a weird environment. If if they are the merchant of record, then what are you? You know? Are you are you their service provider?
I I I don't think in an environment like that you are technically a service provider. Like, I don't think you'd have to fill out an SAQD, but you should really understand what your responsibility is and what you should be protecting. Let's let's let's say, you know, in the case of of a t two implementation for parking. You know, maybe t two is running their own merchant account, and they're responsible, you know, for all of the patching of their systems.
They're responsible for the network that it's connected to. But maybe you're responsible for physical security. You know, if T2 is not coming out to periodically inspect the devices and make sure they haven't been tampered with, to make sure there are no skimmers installed on there, if you have that type of a breach, whose responsibility is that ultimately gonna be in the courts? And that may be a better conversation to have with your with your legal team.
But really what I think your responsibility is as a merchant or, yeah, as a university merchant, you you just you need to go through an environment and decide, you know, if this were my environment, what SAQ level would I say this is at and what PCI requirements would apply to it.
And validate that your service provider is managing all of those. If they're not, then address the ones that are your responsibility. And it's not a bad idea to get them on the phone, your service provider, and say, okay, what are we responsible for in this environment? What do we need to make sure we're doing to help maintain a PCI compliant environment even though it's your merchant account? So so really be aware of what your responsibility is and make sure that you are that those requirements that you're responsible for are being met in order to reduce the risk of, of a breach in that environment, even if that risk is just a reputational risk.
Awesome. Well, thanks again, Michael, for taking some time to speak with us today regarding PCI compliance for universities.
And thank you to all of you who are in attendance for for being with us today.
We we did have a few more questions here that we, unfortunately, don't have time for. But, again, we will reach out to you individually, the next few days to make sure you get those questions answered.
And also stay tuned, for the recording that we will be sending out.
You can check your emails, in the next couple of days here. We'll make sure we get that sent out so that you can review this webinar and review the slide deck.
And and, again, we we really appreciate you being here in attendance today.
Thanks, and we'll see you next time.
.svg)
