How Secure is Your Multi-Factor Authentication?

Nice for having you, you will talk about how secure is your multifactor authentication. Can you give a brief insight what you will share with us? Yes. So I definitely wanna talk MFA is one of the biggest buzzwords and zero trust, and there's a lot of great things about MFA, but it can also introduce some vulnerabilities that can affect how secure you really are. That's kind of what I wanna talk about is how do you, that, That sounds really interesting. So Rebecca, the stage is yours. Great. So just to kind of start out, I know people are good with telling stories.

So the story I wanna tell is about Goldilocks and the three authenticators. We've all been talking about this for the last two days, how bad passwords are they've been around forever, but they're still pretty ubiquitous, but from a security perspective for things we really care about, you know, pretty much all security experts agree that passwords are too weak. So what about this great, wonderful, strong PKI authentication?

Well, it's been around for a while as well. And there are definitely communities that are using it and using it successfully, but a lot of people kind of came to the conclusion that PKI is just too hard. So that leaves us with MFA multifactor authentication, which is just in that sweet spot of being stronger than a password, but a better user experience than trying to get digital certificates out to your entire subscriber population. So just to kind of go back to passwords for a minute, I mean, if they're so bad, why are we still using them?

I mean, for example, I used a password this morning to log to the cover call EIC conference. Well, passwords are really nice and simple. You have the user, you have the resource owner, the user says, Hey, I would like access to your system. Resource owner says, great, give me your password. And then once that user's authenticated, the user gets access to the resource. And the reason I think that passwords are still so ubiquitous is that it really gives that resource owner a lot of control, at least a lot of perceived control.

They know who the users are, they can issue and manage those passwords. They can monitor depend. They can determine what strength they want for the passwords and users hate them, but users do know how to use them. You know, we've all figured out how to deal with password managers and other things so that we don't have to be remembering 50 different strong passwords, or we're just bad users. And we use simple passwords that are easily guessable because we figure who cares.

So when we change that ecosystem into the world of multifactor authentication, the biggest difference is that now there's often a third party involved. It's maybe another piece of the organization within the same company. It might be a completely separate credential provider. That's outside the boundary of the company.

So instead of just having this nice bilateral interaction in the multifactor authentication ecosystem, what usually happens user still starts the process, but now the resource owner redirects that authentication to that credential provider and it's the credential provider that the user authenticates to because that second factor is generally not something that is maintained by the resource owner, whether that is a device one time password, whether it's some sort of a cryptographic function of a device it's generally maintained and validated by something external to the resource owner.

So that credential provider really then tells the resource owner, Hey, this is the user that we've got at which point the resource owner can provide access to that resource of the user request. And there's a lot of really nice things about this ecosystem.

For one, the users can like it because they don't have to manage a separate credential for every single resource. Although in many cases, they now just have a whole wallet full of them on their phone. The resource owner likes it because they get a stronger authentication event without having to manage it all themselves. And of course the credential provider, if it's a commercial provider, it's their business model. It is just internal that, you know, it's still kind of their focus in the organization and they can really focus in on doing this capability securely.

The MFA ecosystem is also nice from a standards perspective. There's a lot of standards that are out there. I've focused on a couple of the us based ones, but you know, the NS special publication, 863 a talks about how do you proof the identity before you issue the authenticator? 863 V provides a really comprehensive look at what are the various types of authenticators and how can you put them together to get different levels of assurance there's weight. Canara has a capability to check those Fido does a really good job of identifying those authenticators themselves.

And then just in terms of the actual exchange of information, we have things like O I D C and oof, and SAML. So all of these standards really help to make this ecosystem very functional. And then, oh, sorry, NCC three C talks about the fed that assertion itself and whether it's signed encrypted or requires some additional capabilities. So in general, I have a really good level of assurance about my overall transaction.

However, when you look at the operations behind the scenes from the user, most of us either we're managing that user's device ourselves, if they're an internal user, or we're just assuming the user is untrusted, if they're a consumer at the resource owner level, the resources are usually protected based on how, what that perceived value is. And problem comes when we look at the credential providers. Now I'm not casting aspersions on any of the big commercial providers.

I actually think a lot of them do a very good job, but there isn't really a common standard for what are the best practices for how you manage, how you operate that credential provider to prevent attacks on the credential provider itself. So why is this a problem?

Well, after the solar winds attack earlier, the national security agency in the us actually published a cybersecurity advisory talking about one of the ways that the solar winds allow attack, allowed attackers into systems. And it had to do with essentially compromising the key that's used to sign those assertions. And the NSA advisory concluded basically the security of your Federation depends on the trust of your on-premise components.

But I would also claim that you could replace an on-premise identity provider with a cloud provider, and you still have this same problem that if that credential service provider gets hacked, what you lack, what you think you're getting from that multifactor authentication can actually be providing a back door for an attacker into your system. So back to our fairy tales is this really mean the sky is falling. We have our users, you know, penny, penny ducky, lucky, goosey Lucy and our things. And they're trying to get to a resource. They wanna go tell the king that the sky is falling.

The problem is in this story that they run into a man in the middle attack. Foxy Locky has different ideas about what he wants to do with these users. And so we wanna make sure that our MFA ecosystem isn't subject to this man in the middle attack so that users can actually securely get to our resources. So how do we do this?

Well, I wanna go back to that. PKI is too hard model because there were things in the PKI model that I think we can leverage to try to make sure our MFA ecosystem is as secure as we think it is now the PKI model, in addition to the ITU X 5 0 9 standard, which is all about the certificates themselves and what they look like and what their formats are and how you do revocation checking and all of those other pieces. The ITF RFC 36 47 provides a framework for developing and building a certificate policy and certificate practice statement.

A lot of you in the audience are probably failure, fairly familiar with these, but essentially it's a structure for a document to talk about all the different ways for how your PKI is operated so that somebody independently can look at it and say, is this good enough for me? Some key things that are contained in this framework is it doesn't just talk about the standards for how information is exchanged between the parties. It has whole sections on facility management. How do you manage physical access to your trusted systems? How do you deal with personnel?

How are you making sure that you're watching for the bad guys? It has a whole section on technical security controls about how are you protecting the keys that sign the certificates, not to mention the keys that are the private keys of the certificates, and how are you preventing malicious code from getting inserted onto those systems that are maintaining those keys.

And then the final thing it talks about is the idea of a compliance audit of somebody coming in and independently looking at how something is operated so that we can know that it's not just a bunch of words on a piece of paper, but the company is actually living up to what they say they're doing. So ideally what we really want in this multifactor authentication world is we really should look at the standards and figure out what can we do to put together some fundamental, foundational best practices who are the right standards? Bodies is this ITF?

Is it it, is it missed? Is it other European companies?

You know, where in the right places for kind of establishing what are the baseline best practice rules everybody should be following at that credential service provider level? You know, what are the different assurance levels?

I mean, one of the nice things about the N S P hundred 63 standards that identifies three levels of assurance. So something that's a low risk transaction can have maybe a lower set of security in cost versus something that is a much more high risk transaction. And then again, what are the right ways to mitigate those threats?

You know, we've done, we've had a lot of discussions on how MFA itself mitigates the threats of an attacker, you know, pulling a password off the internet or pulling a password out of a database and using it. But we haven't talked as much about what are the mitigations to make sure somebody can't arbitrarily send out assertions from a trusted credential service provider, and again, develop some sort of a framework so that we have a way to, for these credential service providers to document what they're doing.

And there's a good way for everybody who's purchasing or procuring these MFA solutions to be able to look at, Hey, is this provider really doing what we need them to do? What we expect them to do as they perform these actions?

Of course, today, that's not really happening. And that, that isn't something that we can look to, cuz there is no such framework that's been established, but I do think as we are looking and, and I think these questions are valid, whether or not we're looking internally in an organization to say, Hey, is my organization operating our internal credential provider successfully? Or there are questions that I think are fair to ask a commercial provider, a cloud service provider that is providing these multi-factor authentications and cloud service providers.

In some cases are doing the whole range. They are doing the identity proofing. They are issuing the credentials, they're verifying the credentials and generating those assertions. In some cases, the cloud provider might be relying on your organization to do the identity proofing and then they are, they are just issuing that and validating that second factor for you. But some of these questions I think are valid in any case.

So looking at these three different areas that we started with, I think the first area that's really important is the facility management and the personnel controls, you know, is the company just at least doing some sort of a basic background check of their trusted roles. How do those trusted roles authenticate to access the system?

There's a really good example of this in the PKI world many, many years ago, where an organization was running a pretty secure system and issuing certificates, but it turned out that their trusted users were authenticating using usernames and passwords to get access to the system. Somebody hacked to use username password and proceeded to issue a whole lot of UN invalid certificates. And as a result, that company is no longer in business. So it's really important to say, how are these privileged users getting in?

And that should be at least as strong as the types of credentials that are being managed by the system. Endpoints is a zero trust track. We talked a lot about the endpoints as well, that if your endpoint is compromised, then it doesn't matter how good your user's credential is. The attacker now owns the endpoint.

So again, for those privileged users that are managing and operating the credential service provider, are those endpoints being managed? Are they being validated before they're allowed to do privilege functions? Multi-party control is always a good security practice for highly privileged activities and monitoring audit logs and making sure that the people that are doing the monitoring actually know what they're looking for. I know of another example, again, these sort of an older example, but it was a system that had been misconfigured at its very onset.

And so the auditors were looking at the audit logs and they saw the same error message with every transaction. So they just assumed that this was a normal expected error message and ignored it until 300,000 credentials later when they had to go back and fix the problem that one ended up not being a breach issue, but it was certainly a cleanup. And then I think the last question, which is especially interesting in our cloud world is the physical access controls. We often think, oh, it's the cloud. And so we don't need to look at physical access and to a point that's true.

But when you're looking at things like your private signing key, that's used to digitally sign assertions, you probably wanna know where is that key located even, you know, physically, what country does it live in and how is it physically protected from an attack? There are a lot of attacks that are much more successfully done if you have physical access to the device. So even though we're living in a cloud world, figuring out what's just out there in the cloud and where are the key things actually managed and what's the right balance, what's the risk that's acceptable for your organization.

So the second set of questions are really kind of along these technical security controls. And again, these are fairly straightforward, but they're often things we forget about because we just assume, oh, I'm somebody else is handling that. And I think it's worth making sure we find out that they really are handling it again, back to that. Everybody thinks, oh, it's MFA. It's not PKI. But I think the, the N person also stated PKI still sitting there in the background, I'm still using public private key technology to digitally sign assertions. So where does that private key live?

And is it in a five, one forwarded validated hardware security module in my mind, that is the minimum you want for that signing key because anything else is just too easy to copy again, do you have two party control in place?

And even though this is a cloud, how is access to those systems controlled for, you know, whether it's on premise finally, it's your basics is the software being managed and our security patches being regularly installed so that we're making sure that the overall security of the operations of the multifactor authentication provider meet the same kinds of standards that we look for in other critical areas of our organization.

And then finally audit is a big area because it's one thing for an organization to say, Hey, these are all the things we do and we'll answer your questions, but are these processes documented? I mean, this is a standard thing that auditors look for, do you can, they, it's not that as an outsider, an organization's not gonna give you access to all of their internal documentation, but you at least wanna know that it's there. And is there an independent audit that's performed?

Does somebody else get to look at this documentation and verify that the practices being used are in fact, the ones that are talked about, and then finally, as a consumer, as a purchaser, I would wanna at least be able to see, Hey, here's the summary audit report that says, yes, the audit was happened. There were no significant issues and this is the date.

So these are the kinds of things that I think as you look to outsource some of this complexity of the multifactor authentication, you wanna make sure that your providers are meeting the same level of assurance that you expect from your own internal practices. So just to kind of summarize, I couldn't find a good fairytale about this one, but I did find a great quote from Henry David throw, which is if you have built castles in the air, your work need not be lost, then that is where they should be now put the foundations under them.

So in our cloud, highly connected world where we're really relying on a lot of different providers to help us secure our key resources, make sure that we're doing these same things for our MFA providers that we are doing for just our resource protection, make sure you know, what the requirements are, what are you expecting, evaluate your providers, not just on their functionality and their usability and all of those great things that are very important, but also what are they doing to secure their own operations and use that as a key evaluating factor when making your decisions.

So if that does like to open it up for any questions.