PCI DSS 3.2: What's New and How It Affects You

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

PCI DSS 3.2: What's New and How It Affects You

In this webinar SecurityMetrics Principal Security Analyst, Bruce Bogdan, covers:

• New and evolving requirements of PCI DSS 3.2
• Time saving tips to implement PCI DSS 3.2
• Updates on SSL and TLS encryption
  

This webinar was hosted on June 15th, 2016.

PCI DSS 3.2: What's New and How It Affects You Transcript

Welcome everyone to today's webinar, PCI DSS three dot two, what's new and how it affects you. We're excited to have one of SecurityMetrics QSAs and principal security analyst, Bruce Bogdan, as our presenter today.

Just a few housekeeping items as we get going, and we'll say this reminder a few times because it always comes up and people are probably gonna be joining in as we speak. But we are recording the webinar. We will be sending it out in the next few days to anyone that registered for the webinar along with the slide deck. So, take notes, you know, anything you need to do, but you will get a recording to review. So, hopefully, that's helpful.

A little bit about security metrics.

We've been helping organizations comply with mandates, avoid security breaches, and recover from data theft since two thousand.

We've been in the PCI game kind of from the beginning. So as it continues to evolve and change, you know, we're part of groups that are influencers and ahead of the curve, and we feel like we can bring some really good insight and hopefully be able to help your organization get compliant and and secure.

Today's agenda is gonna cover some of the new and evolving requirements of PCI DSS three dot two and new service provider requirements. And then we'll also go over some time saving tips to implement PCI DSS three dot two to hopefully make the transition as smooth as possible at your organizations.

So with that being said, I'm gonna go ahead and turn the time over to Bruce. If you do have any questions throughout the webinar, feel free to chat them in and we'll address them. If we get overloaded with questions and don't have enough time to get to all of them, we will reach out to you afterwards on an individual basis. But please send in questions. We wanna be able to help you. So, Bruce, take it away.

Alright. Thanks, and welcome to the webinar.

Just a quick note. So I am a principal QSA here at Security Metrics. My specialty is PA DSS and PCI doing on-site audits.

As I'm going through the slides, go ahead and send in your questions. And if you have anything, we can stop and answer the question right at that point rather than wait for the end, and I'll just continue on if we start to run short on time.

So moving on with PCI DSS three point two. I know everybody's excited about the new change. Just like every time a standard comes out, we're all excited. It was released on April twenty eighth, and most, if not all of the changes in it, are considered a best practice until January thirty first of two thousand eighteen.

If you look at the actual standard, the three dot two standard that I think you can download from the council now, if not, you can soon.

It will say in a gray box in the requirements when that requirement becomes effective.

One requirement that doesn't meet January thirty one, twenty eighteen, is for the rolling out changing SSL to TLS one point two or later.

That becomes effective end of June two thousand eighteen. So a little about six months before this.

You can do a PCI DSS rock still until October thirty first.

So if you have if you're in the middle of doing your PCI, you can continue on with three dot one. I would suggest if you're starting now, though, I would go to three dot two because if you suddenly have an issue in the middle of your audit where you have a remediation items that might take you past the end of October, you don't wanna have to restart again with three dot two.

So this is from Troy Leach, the CTO of the PCI Security Standards Council. He said, moving forward, you can likely expect incremental modifications to address the landscape versus wholesale updates to the standard.

So what he meant by that is the council has been on a three year cycle. They've gone from one dot two to two dot o, two dot o to three dot o, then three dot one three dot o to three dot one every three years, and major updates have been happened every three years with a couple of times there's been interim updates for emergency situations. But I think the council is now going to course, with, again, the SSL, the TLS issue, that is a major issue, but it's not necessarily a weakness in the standard. It's just a weakness in the technology, not addressing the standard. So as he said, it looks like there will only be minor changes from here going forward to the standard, we can hope.

So we talked about the sunset dates for revised SSL and early TLS. So, basically, you need to move from SSL or TLS version one dot o or one dot one to TLS one dot two or better by the end of June two thousand eighteen.

And, of course, that changed from it was supposed to sunset in two weeks here, but when they when the council got feedback from all of you guys that you just had too many customers still using, you know, things like Windows XP where they couldn't use TLS.

They realized that this was gonna be too big a change, and they pushed back the date. Two years, actually.

There's expansion of requirement eight dot three, which was two factor authentication.

They're now using the term multi factor authentication.

I'll explain more what that means in a minute, but it's nothing to get excited about, or worry about.

And then there's some additional steps for service providers and some other requirements.

There's no new SAQs. They came out with a couple new ones with three dot o.

Most of the SAQs the thing about the SAQs is all the requirements that are required for a for a full assessment and are pretty much outlined in SAQ d are all required for everybody. But, you know, the council realized that not everybody needs all the requirements in the full standard, and so they created the SAQs for different situations. So, technically, you're still responsible for all the requirements.

But in your given situation, like, say, a small brick and mortar store, you might only need everything might be not applicable except for ten requirements. And, therefore, they made SAC a, SAC b, C, d, etcetera.

So any change that changes the full standard changes the SAQs to the same requirements.

SAQ AEP added fifty run requirements.

SACD, regular SACD added fifteen requirements or changed fifteen requirements for a multifactor cryptographic architecture, which we'll talk about in a minute.

Updated, migration dates.

So as I said, June two thousand eighteen, end of June two thousand eighteen, you need to be updated.

Clarify on masking card data, requirement three dot three.

The masking requirements are the still the same. You can display the first six and last four, and it's not considered cardholder data.

For anybody anything beyond that where you have displays of more than first six, last four, up to the full pan, you need to create a document where you have a list of roles of who needs to see that the full pan and, have that as part of your policy documents.

So all the roles and how much of the card number they need to see.

As far as six dot four dot six, this is your change control process where as part of change control, you need to have, you know, things like customer impact and rollback procedures, management sign off, code reviews if this is for section six, as for development.

And part of this now, they've added a requirement that the manager management reviews the changes to make sure everything was installed correctly and implemented correctly. So that's another checkbox on the change. Installed correctly and implemented correctly. So that's another checkbox on the change control documentation that beyond management sign off is management or, the review team actually reviewed and checked to make sure everything was implemented correctly and that they meet the PCI requirements.

K. Multi factor authentication requirement eight dot three dot one. We've had a lot of lot of calls about this because it sounds like it's a big change.

It's not. All they've really done here is you still two factors are still required.

It can be something you know, username and password, something you have, getting a token from your, you know, Google Authenticator or Duo Security or some other second factor token, RSA keys, and something you are, biometrics, fingerprints, retinal scans, something like that.

You still only need two of these to meet multifactor authentication.

Multifactor authentication is just the current buzzword for two factor authentication. So that's all that's changed with that.

There's an expansion to when you need to do two factors or multi factor authentication is all connections to the cardholder environment now need to be two factor. And somebody just asked about certification for one of the factors. I'm assuming you mean certificates as one of the factors? And, yes, a certificate would would, meet the something you have requirement. So you can have a certificate on your machine.

So you need a username, password, and that certificate on, say, your laptop before it allow you to remotely connect to the CDE CDE being card data environment for those that don't know.

But the certificate needs to be unique for each user. So it needs to identify the user. So you'd have to have a a certificate authority in place to roll it out to all the administrators that wanna remotely connect that way.

Service rider agreement requirement twelve dot eight dot two.

So this is in conjunction with twelve dot nine.

Basically, this is a we call it a responsibility matrix between you and your customers or your service providers and you, where you basically put a document together for twelve dot eight and twelve dot nine outlining your your roles in PCI. So who's responsible for which section of PCI so that you don't have gaps between, you know, sound like a insurance commercial. You don't have gaps in your coverage between what the customer covers and what the service provider covers.

And you need to have a statement in there, specifically what twelve dot eight dot two is talking about. You have to have a statement in there saying that the service provider will treat cardholder treat your data or will will meet all the requirements for the security of cardholder data. Data. So even though they might a service provider may not get their own PCI assessment, they do agree in your contract that they will meet the PCI requirements.

K. Designated entities, if you don't know what one is, you probably aren't one.

It's a fairly new thing. So, basically, the card brands will create a designated entity or designate you a designated entity.

And it's mostly for people that store in large volume, process, create card credit cards, things like that. It's, most service providers won't fall into this category.

Or I guess if you as we've noted here, if you've had a lot of breaches, they might make you a designated entity.

So there's an appendix, a new appendix in PCI three dot two for designated entities where there's a bunch of questions specific to them and a bunch of questions where some of the annual requirements for you to, you know, review or semiannual, like your firewall reviews, things like that, you need to do it more often to make sure that you're keeping up with your PCI on a month to month basis.

As I said, if if you're gonna be a designated entity, your bank or the card brand will actually tell you you're a designated entity.

So the designated entity, DESV section is now included in the appendix.

Designated entities ensure PSAC compliance on a day to day basis. I said, you know, maybe every month, but, yeah, every day there's things tasks you need to do to prove you're keeping up with your PCI.

Okay. New service provider requirements.

Cryptographic architecture. So requirement three dot five dot one.

So you don't need to make any changes to your cryptography.

If what you're using is compliant, it's still compliant.

But you do need to create a document describing your your cryptographic architecture. So how it's laid out, what it encrypts, what encryption algorithm you're using, things like that. So timely detection and reporting, ten dot eight. This is a new documentation requirement where you need to document a detection and alerting process, meaning you have in the document how you detect things, what the process is for alerting, whether you have to alert the card brands, the police, the news, your boss, whatever that and who what the numbers are all needs to be spelled out in ten dot eight.

Here's part of the timely detection and reporting. You should have in the document all the security control systems, your firewalls, IDS, file integrity monitoring, antivirus, physical controls like, you know, door locks, whether it's keyed or badge access, you know, security guard at the desk, whatever, logical access controls, including your your multifactor, audit logging mechanisms, and segmentation controls if used, which I don't know of anybody nowadays that doesn't use segmentation in their environment.

Well, I take that back. Large IDs. I guess small brick and mortar stores might not have segmentation.

And then ten dot eight dot one, if there's a breach or a security failure, the process should include or you should describe in the document how to restore security functions, identify and document the date and the time of the breach or the security interruption, documenting the cause of the failure.

And then as I said, it should include a list of who to contact in the case of breach or failure.

I define addressing any security issues that arose during the failure, perform a risk assessment after the failure to find the gaps in your in your security or, you know, what the problem was, then implement controls to prevent the failure in the future, and then continue on with monitoring your security controls.

New penetration testing requirements. So it's always been once a year you need a pen test.

New with three point one was a segmentation was added to that pen test, a segmentation check to make sure you're segmenting your environment correctly.

Now with three point two, the segmentation check needs to occur every six months. So you have a full blown pen test once a year and then six months later a segmentation check.

This is a new thing. It it's, basically, the council's requiring companies to create a compliance officer and a compliance program. So it can be assigned to it work best if it is assigned to c level staff or somebody with the authority to make decisions and get other people to do things. It can't be a junior level position.

They're they're supposed to monitor the PCI compliance of the company as a whole and stay on top of things.

And, yeah, basically, just have a program to monitor your compliance.

Most companies I've been to have something similar to this already, so it may not be a big change for some of you, but it does need to be a formalized process now.

Quarterly personnel reviews, twelve dot eleven and eleven dot one, twelve dot eleven dot one.

So you need to perform quarterly views to confirm your personnel are following security policies and operational procedures.

So this doesn't need to be individual interviews, but it should be at least a quarterly meeting with your IT staff in charge of the network where you talk about, you know, you review what's the security of the environment.

And in the case of a call center, you should probably have a quarterly meeting with the the people just to talk about, you know, security on the call center floor, you know, if you take card numbers over the phone, what to do, things like that.

So, again, not individual interviews, but at least quarterly meetings with the relevant staff.

K. Implementing PCI compliance.

So the PCI, if you're I'm sure most of you are aware, there's a prioritized approach tool you can download from the PCI council's website.

If you're brand new to PCI, you're just getting ready to go for your first time, it can be a lengthy process to get ready. Like, set I wouldn't plan if you're brand new setting up your environment or reconfiguring your environment, I would never plan less than six months to get things into place, and experience has shown it's really more like a year long process to get everything ready before you're ready for a on-site assessment.

If you're under the gun to get things done from your bank, you need to create a timeline to meet your PCI goals and the prioritized approach tool from the council's website.

It helps you create the timeline by outlining what are the most important things to get in place first, second, third, fourth, etcetera.

And it's best, as we mentioned here, to break it into manageable pieces. So instead of doing everything at once, you know, eat the elephant one bite at a time. You know, set up your firewalls will be the first thing you do as part of the prioritized approach. Break it up into manageable chunks.

If you're already PCA compliant, make sure you keep your documentation in an easy to find place and updated.

Once a year, most of your documents, including your security policy, firewall rules, etcetera, need to be reviewed and updated and have a current review date or change date in a table of contents at the first or at don't know remember what they call it, but a table at the first that outlines when the review was done or the update was done and who did it.

And, of course, firewall reviews are semi annually and other documentation is, you know, quarterly, etcetera.

Finish your requirements on time, meaning when the the the best practice dates are in the standard. So for most cases, January thirty first two thousand eighteen.

You should have all your things done by that date or before. Don't don't wait and wait and wait and then rush to get things done in the last month before the requirement is due.

Make sure you scope your environment properly.

And if you need help with that, you're more than welcome to call us or contact your QSA to help you with scoping. For PCI, scoping is the customer's requirement, and you set the scope, but your QSA verifies the scope. So work together with that. For PA DSS, which we're not really talking about this, but scoping is the responsibility of the PA QSA, and then implement all the new requirements on their dates.

And this is a good slide. It's important to be compliant, but it's vital for your organization to be secure. Too often, we get in the mode of we're just trying to complete the checklist, but the goal here is security.

So, yes, we have to complete the checklist, but we wanna do it in a smart way. If you think you have a better way, then talk to your QSA about how to meet the requirement, and you can come up with a compensating control.

But, again, the goal is to make sure environment your environment is secure.

So some basics, the basics of what we just covered, create a team for protection of cardholder data, and as I said, preferably a c level person in charge of that team.

Understand your environment. One of the worst things you can do is outsource all of your IT to somebody else and not have any idea how your network infrastructure works.

And then plan for changes. Instead of just going in and, you know, changing firewall rules, adding systems, plan them ahead of time, make sure all the PCI requirements are met, and then go forward with your changes.

Administrator access requires multifactor authentication or still two factor.

But it also requires it all remote access to the systems now requires two factor authentication.

Semi annual segmentation penetration test, a document showing outlining your crypto cryptographic architecture, update to TLS one dot two or better by June of two thousand eighteen, Understand the requirements that you're responsible for.

Schedule and complete all your requirements on time, either as outlined in the standard, or you might get a mandate from your acquiring bank that you need to be compliant by a certain date.

And take time to understand PCI requirements.

PCI declaration occurs once a year, but PCI needs to be a continual process.

And now we're open for questions.

Thank you for all the questions that have already been sent in, and feel free to keep sending them. As we said earlier, we'll try to address as as many as we can get to today, and then, otherwise, we'll reach out to you on an individual basis, make sure that things get covered. So continue to send them in, and like I said, we'll we'll try to get to as many as we can.

And thank you for your attendance.

So we'll start out, Bruce. Are there any security camera requirements that coincide with PCI? And if so, how long to keep recordings?

So the requirements for security cameras haven't changed.

And it's not just security cameras. You need an access control logging mechanism. So if you don't have cameras, a badge access reader can double that. So if you have to badge in through a door, just the logs from that also meet the requirement. But camera feeds and or the logs from a badge reader need to be stored for ninety days.

Great. And there was a few different questions about the designated entity service provider, so I'll just kinda group them all into one for some clarification.

So is that designation affected at all by the type of SAQ?

You mentioned large volume. Is there a specific definition for that? And, you know, something like a payment gateway, is that more likely to be considered a designated entity?

Or Basically, for designated entities, as I said, unless you're acquiring bank or the card brands tell you, then you're not a designated entity.

If you're doing an SAQ, you're not a designated entity.

To be a designated entity, you need to actually go through a full audit. So if you're doing an SAQ, say a SACD, and you're breached, then they might require or call you a designated entity or and then you would have to have a full assessment. But that's always been true. If you're breached, you usually need a full assessment anyways.

So if you're an SAQ, don't worry about it. If you're a a a card not a processor, but, you create credit cards, I would guess you probably are gonna be a designated entity. If you're a gateway or a processor, it's probably a fair chance. If you're just a ISO or a service provider, you're probably not.

But, of course, you can't quote me on that because I'm not the one saying who's gonna be designated entity.

Hope that answered the question. I know I can't be super specific on that.

And just to throw this back in before we get to the next handful of questions, We will be sending out a recording of the webinar and the slide deck in the next few days. We've had a lot of questions about that. I know many people wanna review it or share it internally. So just wanted to clarify that we will be sending that out in the next few days. So watch for it. It will go to whatever email address you registered for the webinar under.

Okay. Let me just expand on that for a second. I just did just find the page.

It's page one hundred and twenty two, and it's in appendix a three of the standard.

Here's what the council says about who would be a designated entity.

Those storing, processing, and or transmitting large volumes of cardholder data.

And, of course, I don't know what large volumes means to them, but I I'm thinking we're probably talking in the millions of card numbers. But, again, you can't quote me. That's just my assumption.

Those providing aggregation points for cardholder data, meaning if you, bring in several different merchants using their own merchant ID and you bring them into your central point and then forward them onto the processor, that would be an aggregation point. Those that have suffered significant or repeated breaches of cardholder data, take what you will from that. If you think you're in that category, again, you're you're acquiring bank. I'll let you know.

Perfect.

So on an earlier slide, you talked about the three dot one and three dot two rocks and which were acceptable when and expiration dates. Can you just clarify again the expiration date of three dot one rocks and and when people need to receive a a three dot two rock.

Okay. So PCI is an annual process. If you just finished your PCI assessment and you did it under three dot one and it finished two months ago, you don't have to do a new assessment until next year, you know, ten months from now. It's once a year, and that doesn't change.

But if you're about to start an assessment now and you're gonna use three dot one, you need to be done that assessment by the end of October because the council will no or Visa will no longer accept the card brands. Let me say, will no longer accept three dot one reports after October thirty first, but you still only need to do it once a year. So if you plan on being finished before October thirty first, three dot one is fine. If you're gonna be finished after October thirty first, then do three dot two.

And sticking on kind of the three dot two version, what do you feel are the most significant changes or most complex changes related to the new version that might affect the organizations the most? Probably rolling out TLS.

That is I've had a lot of customers have real problems with TLS. And, actually, the major problem is having either terminals, older terminals connect to the web server or the the gateway using TLS, Or customers with their, you know, grandma's workstation they've had for years, and they don't wanna upgrade it, but it still uses Windows XP and Internet Explorer three. And so they can't connect to buy stuff from the online merchants if we switch to TLS right away.

That, to me, has been the biggest thing. Documentation is another big thing. There's quite a few new documentation requirements.

I personally don't write like writing documentation, and I haven't met many people that do, so that always seems big to me.

And probably authentication requiring all IT staff to use two factor authentication to connect to the environment.

Say a lot of people already do that. Some don't. The bigger larger your IT staff, the bigger that'll be.

Great.

And a few clarifying questions with penetration testing and segmentation checks. Can you just kind of, again, describe it, you know, what net network segmentation is? Maybe provide a few examples of network segmentations that people might do in order to reduce scope or be more secure?

Let's assume you're an entity that stores cardholder data.

They require that you have a DMZ. So if you store cardholder data and you have a web page. So they require you have a DMZ where the web pages live, and that connects to the Internet and the world at large.

Then you have a secure zone where cardholder data is stored.

So those are two separate VLANs usually created by a single firewall creating two separate VLANs, or it can be created by two firewalls, one at the edge creating the DMZ and then a second one between the DMZ and the secure zone. But it's basically just segmentation is just DMZs created by the firewall to create different VLANs for use for different reasons. Your DMZ, maybe you have a application VLAN where your applications run and then a storage VLAN. And then you might have an out of scope VLAN for all the rest of the corporate machines.

And just to clarify, segmentation checks are now required every six months just for service providers only?

Yes. It is. For service providers only.

Do you have an example of what a cryptographic architecture looks like, and what would a QSA expect to see when they're doing that audit?

We don't have an example.

Basically, what would be in it would be a description of the algorithm you use, a description of what you encrypt, the method you're using for encryption, meaning, you know, it's a little hard to generalize about this because encryption is so specific.

The pathway for encryption, so if you encrypted on an application server and then pushed it into the database or if you're just using, say, SQL encryption right in the database, basically, just a overview of your entire encryption process and the pathways where you push the encrypted data.

Another question we have, which I assume applies to a lot of organizations, is regarding the assigned PCI officer, whether this needs to be a position dedicated solely to PCI, or can it be someone who's overall compliance or who handles other, you know, job roles with the assigned PCI officer?

So when it regarding the assigned PCI officer, does that need to be their sole position or just an aspect of their position?

Just an aspect of their position. They you don't need to hire somebody specifically to do just that.

But if they try to tag it on to the end of their already overwhelming duties, then they won't do a good job of it. Perfect.

A question here about reverse lookups and inbound connections. Are there PCI requirements for reverse lookups? Do they need to have reverse DNS, log them in a certain way, source them?

There's nothing in PCI that addresses that specifically. There might be security requirements around it that you wanna address as regarding what ports you have open, what ports you have open into your, your cardholder data network, but there's no specific requirement addressing that.

Great. And with three dot two, are there any specific changes for chip and PIN or chip and sign?

Not in the PCI standard. There are other standards that address that, but not the PCI standard.

A few questions about multifactor authentication.

If multifactor authentication is installed, do password expiration dates of ninety days still matter if the passwords aren't used as one of the factors?

So if someone's just using a username and a code from their phone, do they still need to abide by the password expiration?

So your username is not a factor. So right there, you're talking about a single factor being the code from your phone. So a factor is a password, and that would need to change and the code from your phone.

Specifically, say you used a biometric and a token, The token essentially changes, every time you use it, so that would meet the the ninety day requirement.

But say you're using your certificate and a biometric, that's a good question. It's not spelled out specifically in PCI.

I would say address that to your QSA because what would happen there is probably different QSAs would come on-site thinking different ideas about that, where they had to change your certificate every ninety days.

And I can't even say what I would do because I haven't even thought about that before. But as far as password goes, username is not a factor. It's a username password combination that is the factor.

And going back to segmentation checks, do they have to be done by an outside source, or can those be performed internally every six months?

This requirement is the same for a penetration test. So it needs to be performed by a qualified person, and it can be an internal resource just like your normal penetration test. And the internal resource needs to have, separation between the IT staff and themselves.

So they're independent. They're not following orders of the staff responsible for the assessment.

Speaking of service providers and their responsibilities when it comes to twelve dot eight dot two, the service providers are supposed to agree to their responsibility and sign on it. So have have you seen issues with any of your clients that have had issues getting this completed with their third parties?

Not so much. The biggest problem is just getting the paperwork done.

I think most most people I've run into are willing to do it.

The problem has been understanding what the requirement is and then finding the time to get it to do it. But as far as I very seldom run into service providers that are unwilling to do something for their customers because that's their their business, and they'd be out of business if they weren't willing to work with their customers.

So we we have a few other questions, but a lot of them are pretty specific to unique environments that will be easier answered on a one on one basis so that we, you know, aren't speculating too much on on how you're set up. So at this time, we're gonna go ahead and end the webinar. We appreciate everyone's attendance. We'll get you out a few minutes early.

And as I said, any any questions that went unanswered, we'll make sure to reach out to you to clarify. We will be sending out the recording and the slides in the next few days, so watch for that email. And, again, we appreciate your attendance. And, Bruce, thank you for the presentation.

Thanks, everybody.