Watch to receive clarification on the PCI Multi-Factor Authentication (MFA) supplement.
Having issues accessing the video above? Watch the video here.
Join Gary Glover, Vice President of Assessments at SecurityMetrics (CISSP, CISA, QSA, PA-QSA), to learn:
This webinar was hosted on September 28th, 2017.
Okay. We're gonna go ahead and get started. Thanks again for everyone's attendance. We're excited to be talking to you today. Our webinar today is understanding the new multifactor authentication supplement.
And our presenter will be Gary Glover, our vice president of assessments here at SecurityMetrics.
Gary has been with SecurityMetrics for twelve years and holds credentials such as QSA, PA QSA, CISSP, and CISA.
So a lot of experience in the industry and with security, and will be able to give us a lot of information as well as real life experiences as he's been on-site auditing.
Before we get started, just a little bit about SecurityMetrics.
We've been helping organizations comply with mandates, avoid security breaches, and recover from data theft since two thousand. And because we get this question a lot, it's probably the most common question we get. We will be sending a recording of the presentation out to everyone who registered for the webinar. We'll be sending that out to the email address you used to register for the webinar. We'll send that out in the next few days along with the slide deck so that you can review it, share it internally, share it with customers.
So watch your inbox for the recording.
Throughout the webinar, if you have any questions, please chat them in using your GoToWebinar control panel, and we'll address as many as we can today on on the webinar.
We're gonna try to stick to during the live q and a more general questions that a lot of the audience will benefit from. So if it's questions specific to your environment, then we'll go ahead and reach out on an individual basis after the webinar in the next few days to make sure that all of your questions do get addressed. So please chat in any questions you have, and we'll try to answer as many as possible. If not, we'll reach out to you on an individual basis. So with all that said, we'll go ahead and get into the presentation. I'll turn the time over to Gary.
Thanks, Colin.
Appreciate all of you being out there wanting to listen to us this morning.
Today, we're gonna be talking about, this new multifactor authentication informational supplement.
It can really be, something that is interesting or or needs to be understood by both merchants, acquirers, service providers, other kind of people, that are just working on PCI DSS compliance for their organization.
Frankly, there's some really good stuff in here just for people interested in security and how to good how to do really good, and clean multifactor authentication from anywhere outside of this critical network. We're gonna be specifically talking about credit card networks today, and and we'll use the term card data environment or CDE a number of times as being the critical network that we're, going to be connecting into.
Just a quick, rundown of what some some of the principles, some of the things we're gonna be talking about. We're gonna try to do some clarification on the, multi-factor authentication supplement. Sometimes those documents can get pretty technical, and and, we wanna help help, interpret and understand that. We're gonna be really kinda talking about how that supplement impacts you currently and in the future, and then we're gonna be doing going over some detailed multi-factor authentication principles and a number of examples.
So this will be kind of a high level approach.
As as Colin kinda mentioned, we're gonna be talking about general principles and general applications.
And, if if anybody has specific questions, you're welcome to, you know, get those to us and or call into our, you know, enterprise salespeople and ask them, and they can get the right information for you.
So let's get right into it. We're gonna be talking then about this supplement. Here's some of the basics. It was released, you know, February twenty seventeen of this last year. Now just kind of as a review, multi-factor authentication is required by the PCI DSS for any and all remote access into the card data environment from both outside, that would be from the Internet perspective, and from inside perspectives from your organization, that would be for doing tasks like server management, from a management zone or from out of scope zones, these areas getting into the CDE perhaps.
So, its purpose of the the web you know, the supplement released in February was to really clarify some of the principles of multifactor authentication. We've spent some time as a group here at SecurityMetrics. Our QSA is talking about it, getting further clarification from the PCI Council.
That took kind of a long time for inter inter, emailing back and forth to make sure that we're really understanding completely their guidance.
And, I just wanna make sure that everybody's clear on this supplement. In fact, none of the supplements really create new PCI DSS requirements.
Their intent any of these supplements that are put out by the council are for providing further guidance, maybe for helping people go the extra mile, kind of different things that that are gonna help you understand the principles of security that we're gonna be talking about. I'd like to, quickly go over there's a statement from the supplement, word for word. I wanted to read that. It says, while PCI DSS eight dot three, which is the requirement that is on multifactor authentication, does not currently require organizations to validate their MFA implementation to all the principles described in this guidance document.
These principles may be incorporated into a future version or future revision of the standard.
So the message from the council clearly is, here's what we want you to understand that we mean when we're talking about multifactor authentication.
And the clue is start working now on getting this right early on. Don't wait till the last minute and wait till some sort of a a change in the in the standard occurs.
Work with your QSA if you have questions.
You know, even though it may not be a requirement yet, to do some of this stuff, you should begin to get ready, look closely at your current multifactor authentication system.
So a little bit more on on kind of purpose. This supplement really does a great job of getting down to some details of of authentication principles, what is really meant by the independence of factors, and clarifying the difference between multistep authentication and multifactor authentication as the, PCI Council kinda sees and defines it. Additionally, there are some issues, addressed in this supplement, about using cell phones as an authentication factor, and we're gonna be talking about that as well.
So, again, the real purpose of this supplement is to emphasize the importance to all players of getting on board and not just doing the minimum for a multifactor authentication solution. And this really is both to, implementers of these solutions and also to vendors who are creating these solutions.
The the real problem is what we're trying to do is reduce the risk of insecure remote access. It's still the biggest problem, still the biggest vector for attack into, sensitive authenticate sensitive data systems.
And, so strong multifactor authentication can keep, criminals and hackers away from getting into your systems.
So why was it released kind of this year?
There was a discussion near the end of twenty sixteen and the beginning of twenty six seventeen with the QSA community at both some of the queue the community meetings, etcetera.
And, the council highlighted some differences in opinion for interpreting the necessary features of multi-factor authentication.
I was at that meeting, and there was a lot of confusion amongst kind of the industry and and, the QSAs in in general about what principles are what is meant by what phrase. And and so the council really wanted to put this out as a way to help, both QSAs and entities implementing multi-factor authentication to be clear on their inter interpretation of multi-factor authentication principles. Unfortunately, this is still a pretty difficult topic at times, and even with the supplement now available, it can be a little bit confusing to many readers. Hopefully, we can help with that understanding, this morning.
In preparation, as I mentioned earlier for this webinar, we interacted with the council quite a bit. It takes quite a bit of time via email back and forth to make sure that our interpretation guidelines we discuss here are correct.
So let's get right into some of the basics then.
As I mentioned before, remember, we're all in this together to really make compromise by remote access a less frequent occurrence.
Everybody needs to be on board for security reasons, not just compliance.
And you need to really think about the MFA solutions that you have currently implemented.
Don't just maybe take a vendor's word for it, but really try to understand your solutions and how they meet the MFA principles that we're gonna be talking about today.
Just a bit of background to sync up.
The statement here is directly from the PCI DSS, eight dot three guidance. Multifactor authentication requires an individual to present a minimum of two separate forms of authentication, before access is granted.
Now it doesn't mean you know, I've had other people ask me, it doesn't mean that two is the only answer. You can have more than two.
It's not like the holy hand grenade where three was the counting, only three, not two, not four. In this case, multi-factor means you can have multiple, different factors available, and being used.
But two is the minimum.
So here are let's talk about what these factors are. Some of this is kinda review for for many of you, but I just wanna make sure that we're all on the same page here. Multi-factor authentication requires two of the following types of authentication methods, something you know, only you know, like a password or a PIN number, something only you have, like maybe a hardware token or a smart card in your possession, or something only that you are. For example, a fingerprint, an ocular scan, or maybe a face scan. Now with the cool new iPhone x coming out, maybe that's gonna be a cool thing. Who knows?
So, no, there can be other things added to a any kind of a multi-factor, authentication solution such as geolocation, time, IP address, MAC address, etcetera.
Those things are great and and add in the security, but they don't count.
Two of the three methods have been mentioned above must be present, and IP or MAC address is not considered something that you have or that you are.
A few effective, multifactor authentication examples for remote access include things like, a remote user entering their username and password and then entering a one time password sent to them on their smartphone.
The remote user, another example might be a remote user, is entering their username and password and then must use a unique dynamic number found on, RSA secure ID token or something.
So let's talk a little bit more about factor independence.
Access to one of the factors in in a solution can't automatically enable access to an additional factor.
So, for example, if you want to use a laptop login as one factor and an open SSH key certificate file, for example, stored on the laptop that's used to gain access to a remote server, that's really not good. You would have to do more server validated server side validated factors to make that work. For example, adding a Google authentication, maybe n plus a server side password. So so having a a client side, basically, you know, that's the the laptop password and, a key certificate of file delivered, even if the key certificate of file requires a password on the you know, sometimes there are are are SSH key files that you have to have a passphrase for, but that's a client side validation of the passphrase, not a server side validation.
So it's really, so that's really kind of talking about the the accessing. One factor can't grant the access to another one. It's also best to physically separate your factors of authentication. A good example would be a password is in your head, and a token is sent to a device or coming from a separate device. So that's a good example.
A bad example might be, let's say you log in to your laptop and then click on a link to a remote access methodology, and, maybe a password is being added automatically from a password vault or an automated password single sign on system or something that keeps that factor on your laptop. That would be bad because, it's not really separating them plus access to the one is getting access to the second one.
Just to be really clear here, and we were very clear on this with the council and they were clear with us, the communication with them reiterated that independence is not a PCI DSS compliance requirement at this time, but emphasized that we should get focused on increasing security and not focusing on just compliance, we being the industry, we being the people who are implementing these solutions.
So this guidance document really is trying to move us to the next level and get us ready for potentially more requirements in the PCI DSS. Now if they do add more requirements to the PCI DSS, these will be, you know, added in the normal methodology. You'll know about them, and there'll probably be some sort of a of of an introduction or a period of time when you're gonna be able to implement those.
So remember, kind of the principle last principle I want for this slide is if you have to be compelled in all things to meet compliance requirements, you're not always a wise security asset. Compliance is usually the floor of security, not the end.
A little bit more on factor independence, and and this next topic is covered in the supplement is out of band authentication.
And these things are these are factors then that are communicated through separate protected channels. It's not something that's stored on your laptop or on a phone or or whatever. It's something that is, delivered in a different methodology, and you have to be really careful about, you know, the possession of of the protection of this out of band authentication, you know, how that's, protection is needed of the of the item that's getting the out of band token or factor. So, for example, cell phones, fobs, etcetera.
For example, if you are to be careful of independence issues, you you're using a single device like a smartphone to do a remote connection, let's say a VPN or SSH or whatever, and that smartphone also receives the one time password via text or Google auth.
This just killed your independence rule and nullifies the MFA principles because you're using, you know, access to the same cell phone, the same device to both get one of the factors and using it to log in through some open VPN or or remote access solution.
You also really have to be careful about considering controls around really who has possession of a cell phone or another, fob or factor.
And, one thing that we often talk to people about is, I know there's probably a lot of people out there who have a text message notifications automatically pop up on your cell phone so that you can kinda glance at it and see, oh, there's a a message from somebody in the first, you know, one line or something of the message displayed.
Often that message, will display the second factor, you know, token, and it will display it without you entering the PIN number or anything. You know, on an Apple Watch as well, you can get often, you know, a quick SMS text message that will contain the, you know, the Office three sixty five password and or the the token for two factor authentication.
That would be validating the true principles of factor independence for an out of band authentication. So if you get a one time password via SMS and it pops up automatically so you can see it, that's not a good method.
The next topic in factor independence is the the topic of cryptographic tokens and the use of cryptographic tokens.
There's there's a principle of storing a token or a public key on a secure cryptographic environment that could be embedded directly into a device like a laptop or a phone or a tablet, and that can be used to enforce independence of factors when authenticating from a single device or a channel.
That can be embedded into a secure execution environment, for example, a chip or maybe a separate onboard portion of the CPU. CPU. Maybe there's a a a fancy secure software way that that you can have the secure execution environment. But it's something that is designed specifically for that. It's not just something you can say, you know, well, my computer has a whole lot of chips in it, so, therefore, one of those has gotta be a good secure one.
So this could help really in the example I used on the last side of using your cell phone to perform the remote access login and also receiving the second factor. So a token could be accessed via an API or some sort of out of band communication method to have that secure execution environment send the factor that's stored there without your interaction. So that would preserve an independence if there was that type of an environment.
An illustrative another illustrative example might be, there's sometimes a hidden SMS text message, they're called over the air programming, can be sent directly to a SIM card. Let's say a SIM card has a secure element on it, and and an over the air programming method could be sent to that SIM card that is, again, not something that you, the user, would be interacting with. It could then be used to run an application that will prompt you for a fingerprint or a PIN or something, then that could send a more complex token as a second factor. That would be able to preserve the independence, of those things.
You know, I haven't seen a ton of these type of solutions available. I know that there's a few out there. Duo Security has a few solutions. There's probably more.
If you guys are out there using any of them, just let us know. I'd like to to start creating a list of some of these cool secure environment, methodologies. But I think that might be something that's coming more in the future as smartphones get more use of some of these, secure elements, etcetera.
So kind of back to overall factor. No matter what your factor is, you have to protect it. If it's something you know, you've gotta use a strong password principles. You can't just give up on all the other things that we already know to do. If it's biometric data or something you are, you have to make sure that it can't be replicated by some unauthorized entity. So make sure you keep your index fingers and thumbs with you at all times.
Have, you know, data data that's like that you have, make sure you're not sharing that, giving your card to somebody else, sharing certifications or other things with co workers, you know, key fobs or whatever. So those are still important principles for protecting any kind of factors.
Now there's lots to discuss and understand, I think, here under this concept of multistep versus multifactor. This was one of the topics that, caused a lot of discussion both among the QSA's community and, you know, kind of, internally here with us, and and we wanted to make sure we understand kind of, exactly what the council was thinking about here.
So let's kinda just get into this. The the PCI DSS standard itself has always stated that both factors have to be verified before full access to the network where an asset is granted.
So that's fine and has been well understood. However, if any factor fails, no access is granted.
So all of those facts have to be right. So that's a pretty understood principle.
The supplement, however, has added some additional guidance along those lines that states that if your solution for, that your solution for multifactor authentication can't provide any clues as to which if any of the factors was a failure. So, and and this I shouldn't say this is just the council. The council is using NIST and other, documents and other standards for for generating. This is just didn't come out of someone's head there.
They really are trying to implement the best industry practices here. So I agree. I agree that this is a principle that probably was not quite as understood by the community. So there are a lot of current multifactor authentication solutions that uses a pattern such like this, that it'll ask for a username and password.
Then if those two work, it will send you a request to enter a second factor, like an SMS text, a number that you've gotten a Google auth token, fingerprint, etcetera.
So if you type in a wrong password, you won't be asked for the second factor usually.
So that method, NIST, and the council consider to be multistep and not multifactor because all factors weren't presented at the same time, and then the decision said, sorry. No access.
So a better way would be for the username to be validated.
Remember, that's really not a factor. That's just a a username.
And then the password and the token be asked for all at once, and then, either access is granted at that time or not.
So you don't know what factor failed during that authentication pass, that process, either the password or the token.
So many of you out there may be using the system similar to the first example, and and I think the message that we're trying to get and the message the council is trying to get to us is that those should be moved away from. And it may be that there isn't something that's available, for your solution, for your whatever, for your environment.
However, that's one of the things that that your IT people, that your, you know, as a merchant or whatever you can be asking your vendors, hey. Can you do your your solution in this way?
So and as a note here, the enforcement of true multifactor authentication is not a requirement in the PCI DSS yet. This, again, was confirmed by email from the council that it may be added to another rev of the standard. So work with your providers and your QSAs now to make sure that your remote access systems are systems are truly multifactor authentication and not just multistep authentication.
This is one of the big kind of reveals of this document and the thing that I think is gonna be one of the more difficult things, to make sure that we all get right in the industry to to once again improve the bottom line of remote access and make sure that it's being done in a secure way and large compromises of data aren't happening through insecure remote access.
So using SMS is is a very common delivery method for the second factor, a one time password example. So it's very convenient, very easily. It's really it's reliable.
It happens quickly, typically.
So the supplement does address some concerns that the PCI Council has with SMS, and that NIST, documents being they're deprecating the use of SMS for the delivery of tokens.
Now they still allow it, but they may remove it at some point in the future. If the NIST does remove that from their recommendation, the PCI Council will follow suit and will make modifications to the PCI standard. So that's kind of more a warning to be prepared.
And, remember, again, this is a a a disturbing reminder for me when we're using SMS for multifactor delivery, defeats the purpose of independence if you auto display that notification text message. It shows up outside the PIN of your of your phone outside of getting into your phone. So disable that feature if you're going to be using a phone for PCI DSS compliance multifactor authentication.
Your QSA should be checking with that, you know, if you're using that type of a method.
So just be sure that you're keeping independence as an as a as a thing there.
So let's go through the examples that are presented in the guidance document. There's many more different types of of solutions.
So ask your QSA for help if needed. You're also welcome to to, you know, call in and and get some consulting or whatever from us if you have any questions on this.
So for the first example, the the admin there on the the left gets access to their workstation using password password a, and and there is then a a way that a one time password is generated from a client software token stored on the the workstation.
And it's provided then as well as, you know, a a password, another password, password b being asked for before authentication is granted into the CDE server there on the right.
So the password b and the one time password derived from the token are the two separate factors. And password a is really just kinda protecting access to the certificate used to create the one time password, but it wouldn't be considered, you know, necessarily one of the two things that you have to have. So some things to be aware of in this method, make sure that the software token is embedded carefully. It can't be moved to another physical device.
Protect that physical device, and to maintain proof of possession by a person. Otherwise, it would result in just using two password tokens, not two separate types of tokens.
Another example for this might be you could have a certificate, protected on the client by a client side certificate password, like like I mentioned before, an open SSH or client cert. Then you would also have to be prompting for the second server side password on the CDE system as well. This helps protect the client side certificate from being copied to another computer and used as a potential factor. So I would say that the client key passphrase also would have to be different than either password a or b in that type of a situation.
Second example, an example of kind of a bad, MFA solution, the workstation password, then gives you automatic access to, you know, gives you access to the workstation.
This is the case where we talked about earlier where the workstation kind of auto completes or autofills or or stores, in a password vault or it's cached or saved on a browser where that password is being used to get into the password b that I here is being entered automatically by some, process as well as this one time password being generated by the certificate. So if you were doing, that kind of a thing, you're losing independence, and that is not an example of a true, good multifactor authentication system.
Third example is a good example. This one uses the same password twice. You can see password a used both times. However, one to get into the laptop, and then that same password is used to get access to the CDE system on the right. However, the second factor is being received by this independent channel on a cell phone and an out of band and used at the time of the authentication.
So, that's great. But once again, be careful when using the phone to get a second factor. Don't use that same device to log in to the remote system. This is best of independence again. So don't use an SSH client on the smartphone to log in to your system. It is the thing that receives the second factor, not the thing that makes the the authentication.
Example four is, you know, is a good example. It may be a little uncommon. That's where you can, basically, you're entering both factors, just to get onto the laptop, just or get in get into the workstation or laptop or something like that. That would be a password and some sort of a biometric type of a of a, factor.
Then there is a you know, maybe there's a signature or a client certificate or something stored on the laptop that is being used when making the, request to connect to the CDE system. So here, in this case, the two factors are enter enter right right getting into the system.
So you have to be really careful, implementing this so that there's always two required to get into that device and make sure that, you know, there's there's no way to circumvent that, that there's not multiple people that can do that, for example. It's a little difficult difficult if you're doing this using a bring your own device.
If you were, then maybe a secure execution environment that's non modifiable by the user or a secure chip would be needed to be used, which makes that kind of a thing more difficult.
So after all that, that was a bunch of stuff. A whole lot of things real quickly for us to think about again, and we'll provide this webinar for you to look at later and have the slides available.
But if I were to summarize then some of the main things that we need you to to remember from this presentation, they would be the multifactor authenticating MFA guidance document here. The supplement is not changing the PCI DSS requirements. However, we really need to learn the attributes of our current solutions and really be thinking, hey. Let's think about security and not compliance. Let's go the extra mile and and not just say, well, the standard doesn't say this exactly, so I'm not gonna do it. Let's start working on true multifactor authentication and not having multistep authentication, figure out which one you are, who are you, are you one of which type, and evaluate your solution using the principles we've discussed here. And, you know, go download a copy of the supplement, you know, and, hopefully, with this quick discussion of it, it might be a a nice reference for you to have.
And, making sure that you're understanding factor independence, that's really a key part of a good multifactor authentication solution. So there you go.
We're all in this together.
It's not like, it's QSAs against the world or the council against the world or whatever. It's all of us as an industry against the bad guys who are trying to get into our computers. We need to be ready for future changes both to, the standard and just to the security environment as a whole. Again, the PCI standard is just something that helps us in our in our quest for security and represents the floor, not the ceiling, of security measures that can be taken to protect sensitive data in your environments.
So with that, we are into the question period.
Maybe I went too fast. I don't know. Or else we have a whole lot of time for questions, I guess, Colin.
Yeah. Thanks, Gary. We definitely have a ton of questions pouring in, so I'm sure there's they're gonna keep coming in. So if everyone can be patient with us as well, maybe need to take a few pauses to kinda organize the questions and make sure we can get to them.
So I'll start out with asking from I'll just kinda shoot a few questions Gary's way and continue to chat them in as they come up. Before we address the first question, just to reiterate as we had it come in a few times, we will be sending out the slide deck as well as a recording of the presentation in the next few days. So you'll receive that to the email that you used to register for the webinar. So watch your inboxes over the next few days, and we'll send out the recording.
So, Gary, how does this compliance or changes with multi backdrop authentication affect PADSS and internal access to issuer card data?
So So it really doesn't have anything. PADSS is is really just about software and software systems. I guess the one thing that may be it may affect as far as, the PADSS would be, there is a section that talks about vendor remote access. And if you were a PADSS vendor, a software vendor, and you are part of your processes are that you're getting access into, you know, your client systems to help the manager or whatever, then you would want to implement, multifactor authentication in a correct way. The the PA DSS refers directly to the PCI DSS for that requirement.
So as changes occur in the PCI DSS, they would be affecting the PA DSS there.
And, as far as internal access to issuer card data, I think that really kinda goes just back to what is your card data environment, and where are you managing it from? Are you managing it from within? You know? Are you doing administration from a workstation that's considered to be inside the CDE?
If that's the case, then you're you're okay. If it's outside the CDE or or if you're using it, well, and I frankly, I think we ought to be using multifactor when you're whenever you're managing systems in the CDE as as required.
So I don't know that this changes that at all. It's it hasn't modified the the need for that. That's something that was already in the PCI standard.
Okay. Great.
And so the use of multifactor authentication right now is is it being suggested? Is it required? When does it become required?
And when accessing a com a company's network from within into the CDE?
This one is that one.
So let's see. Let me read that one again. The use of both factors.
That's correct. Yeah. So even even from within the company's network, not public site, that is one of the PCI, DSS requirements came out that came out in three dot two, and that specifically is let's let me I'm opening up my actual paper proper copy of the standard to find them.
That would be eight dot three.
Secure all individual non console administrative access and all remote access to the CDE using multifactor.
And, you know, there it is in in eight dot three one and eight dot three two. These are the things that that's being covered in. So review those sections of the PCI DSS. That's something that that really is kinda already in effect.
Okay. Great. And will lack of factor independence result in a failed rock in twenty eighteen?
So it's a plus a certificate on the same laptop. You know? And that's this is the this is the difficult part. Right? And I think a lot of people have this this question.
That's something that you can you you need to work with your your QSA on. As I mentioned, the the council said independence is not being used. It's not there's not a separate requirement for independence.
So, you know, I hate to go against any other QSA or whatever. I would just work with them and just say, but but I would rather you just, you know, work on factor independence as most as best as possible. But theoretically, from what the as the council says, there can't be a failure.
In fact, there shouldn't even be a failure if you're not if you're doing multi step authentication instead of multi factor authentication until that is is, you know, made an actual requirement. However, again, we're not trying to just meet the PCI DSS. It sure would be good to do it the right way, And that's the the message I think that the council and the industry is trying to give.
Great. So are RSA tokens still considered secure to use as a factor?
You know, they can be used if it's correctly used correctly and I it's it's, you know, the question was given their history. So, I mean, if you're if you do it incorrectly, then that's bad.
I know that there has been some, you know, worries about RSA having bad, you know, predictive things or whatever.
Currently, I have not heard of anything saying that we will not accept these anymore as far as for the PCI standard. I know those guys are pretty sharp, and they're gonna work hard to to do the best they can to to get those things dialed in.
Great.
And you mentioned you pulled out some of the direct words from the standard.
Can you address what non console means in eight dot three when it's talking about the CDE is on a virtual machine?
So when you think about virtual machines, the virtual machine really needs to be thought of just like a regular machine, and virtual machines are not just kind of floating around out there in some ethereal goop that doesn't have any organization.
A virtual machine needs to be associated with a network zone or a security group on Amazon or something like that. So they really are organized and logically, config you know, logically put together in network segments just like a real physical server would be. So, if you are outside of that zone, where that virtual machine resides, then you would need multi factor authentication to get in to administer that machine.
For example, you know, I think and and I'm not an expert in Amazon. There are other QSAs here at SecurityMetrics that are if you have more further questions on that.
But I think, you know, there are some principles of, you know, you can do some remote web administration of some of these virtual machine settings. You would wanna make sure that multifactor authentication is in place when you're doing that kind of stuff, as well as just getting directly into those systems with remote desktop or SSH or whatever method to actually control them or run programs or change settings on the servers in the OS as a whole.
So, you know, my thought and and, hopefully, I'm under answering this right way. You treat a virtual machine the same as you do a physical machine, where it's located, and wherever you're low where you're administering it from, you need to consider where that is. If it's from within the CDE or outside, it needs to be protected if you're outside with multifactor authentication.
Great. So does the upcoming TLS version one deprecation affect multistep or multifactor authentication at all?
Let's see. So I I I don't know that I can talk specific. I'm not sure I totally understand here, but but I think, you know, as as we've seen in the standard with the council in the past couple of years, you know, they made a couple of really quick changes of the of the PCI DSS because of, SSL things and differences, and insecurities that are being discovered. So as as those you know, as TLS one is deprecated, then it shouldn't be used.
Right? I mean so, yeah, it would affect multi factor authentication if it's being used as a way to, yeah, I don't you know, as a communications method, I suppose, if you know, I'm not and that's why I'm not sure is that you're saying TLS is being used as a as an actual factor or or just as a method for communication. If it's just for communication of the the solution, then, yeah, as that one gets deprecated, we should quit using that because it's it's not secure. But there will be obviously probably a time period where you have time to move to a solution.
And that's the tough part. You know, merchants and everybody out there are just going the standard changes and they think, oh my gosh.
You know, this isn't this is impossible for us to do. Well, it's gotta be realistic. You've gotta have a way of moving through. You've gotta have a plan for getting rid of it. And, be being aware of things before they happen is really important so that you can plan for these rather than being caught by them.
Kind of going right off of what you're saying, Gary. So the changes that we've been talking about. So what's the difference between the existing multifactor authentication requirements in eight three one and eight three two and the future requirement that you're talking about? About?
Well, right now, as I mentioned earlier, the current the current system or the current requirement just says both factors have to be, you know, validated before full access is granted.
And, you know, and that's that was where the big I don't wanna say schism, but the big the big argument, the big kind of discussion that occurred, was, wait a minute.
You can interpret that one way, and you can interpret that another. And I and I can see the point of the council and this saying, well, this is how we always thought it was being interpreted, was that both of these factors are being validated before any type of of indication of as to which one was being validated was being done. Right? And so the difference that I might see coming forward is the council specifically saying both factors have to be presented at the same time rather than presenting a username sending a password first. And then once that's good, then sending a request for the for the the other you know, like, for for Office three sixty five or whatever. I can type in my password, but if I type it in wrong, it just says password wrong. If I type it incorrect, then it will say, please enter the code sent to you by SMS.
So I knew that I had the password right, which which gives me a piece of information.
So a true MFA solution would not give you that piece of information. It would require you to enter them both at the same time. So in the future, I could see the council making that specific wording in the standard. But, again, there would if they did that, they would say, here's when it it's entered as a best practice.
It will be a best practice for this long of a time. It will become, you know, implemented at this date in the future. They will do that kind of a stat that kind of stuff. But once again, they're trying to get us to think, with security in our heads and just saying, let's really do this the right way, as early as possible.
Perfect.
So we're still getting a lot of questions, so we're trying to keep up. So thank you for sending them in. A lot of them are specific to your environment, how you currently have your multi factor authentication set up, or how you're thinking of setting up and solutions you're using. So for those, we're gonna reach out on an individual basis just to make sure that we can fully understand your question, your environment, etcetera, so that we can give you a better answer and don't have to lean on the, well, it depends.
So a few of these we'll still get to, but if we don't get to your question, we we are documenting all of them. We will reach out.
So if you're using external payments such as using a hosted payment page, does multifactor authentication apply for many aspects or components of of your web app?
So that's a good question.
And and, let me let me give you a couple of different ideas on that. So So the question really is so so now I'm I'm really trying to outsource all of my payment processing, and I have a web page, and I provided a link or maybe it's an iframe or something to somebody else that's collecting the actual credit card information.
So are you out of scope for PCI DSS?
The answer is no.
So if you are a small merchant and you only have to do an SAQ, there may not be a question asked about that. However, at the very top of every SAQ, it says you must be compliant to all PCI DSS standards that apply to you, even, you know, even if you're not being asked to validate them on this SAQ form. Right? So that's an important concept to kinda have before I go into my last answer or my my answer to that, and that would be, you should be thinking, hey, this this web application that I'm using to redirect to somebody else, is that, you know, is it is it storing, processing, or transmitting credit card data? No.
But is it a potential place where somebody could, mess with the pathway for the storage processing and transmitting credit card data? Yes.
So if somebody gets into your website and changes the redirect or puts in some other additional code that sent you know, does whatever, does other stuff, collect even collecting other PII, whatever, but we're sticking specifically with with, PCI here.
Why would you want to say, well, we don't really need multifactor authentication because it's just a website and somebody else is collecting that information.
For heaven's sakes, protect that website from remote access in a very secure web method.
And if you are being assessed by an assessor like one like QSA, I would say yes. That does apply to you even though it's because you're you know, we now go through the full PCI DSS requirements if you if you're a, you know, a level one merchant or whatever, even if you are, shipping that link to somebody else, I would still go through and say, how are you managing this machine remotely? You need to have a good, secure remote remote access.
Okay. So Okay. Awesome. Thank you.
One of the questions is and I'll kind of address it. Are have there any customers been full have fully implemented an MFA solution that has been approved by SecurityMetrics?
If so, what is the solution?
We we, I could send out an email to the QSA in our group and probably get a list of some of that stuff. Maybe we can put it as part of your response to people. I don't have a specific name or any kind of solutions that work. However, you know, we kinda went through, a a solution using open open SSH or that kind of stuff. You can do it the right way as long as you do, you know, prompting on the server side, for for both factor, Google authentication factor, and a password. So there are definitely some open source solutions that this can be done correctly on, but I I don't really have a list of specific ones that I'm prepared to present at this time.
Great. So could you walk through we have up on the slides.
Can you pull up example four again just a few slides back and just kinda walk through that again?
There was a few questions of just Oh, okay.
You know, trying to fully understand this example. So if you wanna just kind of walk through potentially, you know, how this example works and what would be good multifactor authentication practice versus how this you know, how to not implement this.
Well, so I don't you know, I I guess I'm not exactly I don't have a Windows ten machine, and I don't have, a biometric that would do that. What I don't know is is how that's being done. It would be let's see.
The password and the biometric would have to be entered at the same time. And I and maybe that's why maybe if if the Windows ten systems enters a password and then says now prompt for biometric, that wouldn't be. So it really depends on kind of how that's being done. This was a a example presented by the council as something that is a valid multifactor authentication system.
So they are assuming that the password and the biometric are are presented at the same time or, you know, type in your password and do your fingerprint before we say, you know, one or the other. So here's your biometric. Now type your password.
It it it couldn't make an approval of either one of those factors before being asked for the second factor. It'd have to be a method for getting both of those at the same time. If that was the case, then it would be a true multifactor authentication.
Otherwise, you're right. It would be a multistep if one of those are being and I and and I'm sorry. I'm not as familiar with exactly how that system is being done.
Perfect. And once again, we've received a lot of questions that walk us through examples, so we'll reach out to you on an individual basis so that we can give you a more clear answer.
So Gary, will multifactor authentication need to be applied across all devices in addition to server access?
So for example, firewall switches, emergency access, etcetera.
Yeah. So the real question there is or the real answer to that question is, are you are you administering the firewall remotely? Is there a requirement to do that?
Some people will will do that or switches or whatever. They'll they'll they you know, if you wanted to expose that directly, you know, then you could you would have to use multifactor authentication.
Another way to do it would be saying, I I only can can administer or modify my my firewalls or my switches from within the CVE or within a network. You know, I'm already authenticated to this network as an administrator.
You could then do the multifactor authentication to there, right, from outside to get to be an to get, you know, like, you're doing a VPN solution or VPN, remote access methodology.
You do it, true multifactor authentication to get, basically, your laptop sucked into the local network, and then from there, you can manage the firewall and switches.
That would that would count.
It's not necessary to say, I must have a specific solution for a firewall and for a switch as long as they're the management of those devices are not exposed to the outside in any way, until you make a two factor authentication maybe as a network administrator.
And in that explanation, when you're saying remotely, are you saying remotely from the location or just remotely from the CDE?
Definitely from from the Internet, from outside.
So eight three one says examine network or system configurations is applicable to verify multifactor authentication is required for all all nonconsole administrative access into the CVE.
So, so that to me means that if you're outside the CDE and administering it, even if you're inside your your, you know, company network behind your main edge firewall, you need to have multifactor authentication in place.
Now if you are already authenticated to the CDE, let's say, let's say you're from you're coming from the outside to manage a whole bunch of servers that are already defined within your, you you know, your data center where all of the back end servers are that are that are running websites or POS systems or whatever.
You use open v you know, use VPN to get in two factor, multi factor to get in.
Now from there, once you're in to you can go, you know, RDP to various systems.
You don't need to do another two factor authentication to get to, you know, server b and server c and server d once you authenticate into the CDE, if maybe that's what the question is.
You just need to make a multifactor authentication to get into the CDE, inter CDE management or or authenticate. You know, it doesn't have to be multifactor because you're already there.
Great.
Well, we're gonna wrap up the q and a there in the presentation. Like I said, most of the questions that we've received that we didn't address and sorry if some of them slipped through the cracks as they are pouring in, but we will have them in the report. We'll reach out to you on an individual basis. And like I said, we'll have a easier time walking through your unique situation and being able to give you a little better consulting and guidance on that.
So with that, we're gonna wrap it up. We'll send out the recording and the slide deck in the next few days as well as a few additional things like Gary mentioned, maybe some recommendations, and we'll put in a link to the actual information supplement so that you can find that to review as well. So if you have further questions, feel free to reach out to us. And otherwise, we will send you the information and the follow-up in the next few days.
Thanks for attending, everyone.
Have a great day.
.svg)
