MFA Everything

Overview

This session discusses what MFA is, why it is critical to use it for all access, and strategies for implementing MFA across an organization. The presentation also includes a brief demo showing how open source software can be used to help enforce MFA when accessing servers, databases, web applications, and Kubernetes clusters.

MFA Everything

(transcript)

Jonathon: 00:00:03.438 Hi, I'm Jonathon Canada, and I'm a solutions engineering manager at Teleport. Another role that I have outside of my job at Teleport is I'm a cyber operations officer in the Army National Guard. So in that role, I've been able to see some pretty interesting things around incident response and picked up a few lessons learned from that role. So I'm really excited to be talking to you today about how to MFA everything; that is, use multifactor authentication everywhere within your environment, within your organizations. So here's the agenda for today: I'll start talking about some definitions, what multifactor authentication is, different forms of second factor authentication. I'll talk a little bit about the Colonial Pipeline that happened earlier on this year. Then move into single sign on, and then I'll move on to a demo of Teleport and an overview of my deployment of Teleport.

What is multifactor authentication (MFA)?

Jonathon: 00:01:11.978 So what is multifactor authentication? So it's using any one of these three different forms of authentication. So those three are: something you know, something you have, and something you are. So something you know — those are things that you have memorized that you just know in your head. So that's passwords. That's security questions, those security questions where they ask you, "What's your favorite kind of food?" or "Who was your best friend when you were in elementary school?" Those are things that that you know. Something you have. So that could be a code that gets texted to you. That could be a code from one of those authenticator apps. OTP, one time passcode. Could be a YubiKey, so a hardware device that that you can plug in to a device to prove that it's something that you actually have. Something you are. So this is getting into the biometrics category. So scanning a retina, using Face ID so it scans your face to know it's you. Touch ID, fingerprint authentication; those are all things that you are. So to implement multifactor authentication, it's typically going to be at least two of these three different categories. So it could be, for example, something you know mixed with something you have. So what that could be is a password combined with the code you're using from an authenticator app. Something that's used on the government military side is a CAC card. So a CAC card — essentially it's a smart card. So something that you have —your ID card — you plug it into a computer and then you're prompted to enter a pin code. So something you know.

Jonathon: 00:03:18.666 And so what happens if MFA is not being used? So if you're just using something you know — so just a username and password — well if that account gets leaked, there's a compromise somewhere out there and someone is able to get a hold of your username and password, they now have the keys to the kingdom. Anywhere that you use that username and password, they can now access. However, if you had MFA enabled, even if your username and password were stolen, if you had that combined with something you are, that person who has stolen your username and password — they're not going to be able to access whatever account they're trying to get into because they're not going to have something that you are. They're not going to have your fingerprint, your retina, etc. And this last bullet point, according to Microsoft — implementing MFA — can block over 99.9% of account compromised attacks. That's a pretty good statistic.

The Colonial Pipeline attack

Jonathon: 00:04:31.096 Which brings me into the Colonial Pipeline. So this was a ransomware attack that occurred in May of 2021. So Colonial Pipeline is the largest petroleum pipeline in the United States, and it carries 2.5 million barrels per day of fuel from Texas to New Jersey. And this accounts for nearly half of the East Coast's fuel supply. So very major pipeline. As I said in May 2021, when this occurred, there is a group called DarkSide that hit Colonial Pipeline with ransomware and that shut down the pipeline for six days and caused gas prices to rise to prices that hadn't been seen since 2014. Colonial paid 4.4 million dollars in bitcoin in order to resume their operations. However, the CEO of Colonial told The Wall Street Journal on May 19, 2021 that complete restoration of all systems would likely cost tens of millions of dollars. Very expensive breach. The cause of this breach was a leaked password for an account, an old account that had access to the virtual private network, or VPN, used to remotely access the company's servers. So this account did not have MFA enabled. So kind of like that example I used on the previous slides, the hackers only needed a username and password to cause tens of millions of dollars in damages. So MFA is super important; make sure it's enabled everywhere possible.

Single Sign On (SSO)

Jonathon: 00:06:38.746 Single sign on. So single sign on, MFA — I see them as related. So implementing single sign on can make it so that you can force all users to authenticate via MFA whenever they go to access any of your internal resources. So if you can use SSO for all access, then you can just enforce MFA as part of the SSO authentication process. Additionally, when you start using SSO for everyone's access, you're going to be able to tie everything that a user does to their identity. So if somebody goes to access a particular system, you're not just going to see that somebody is going into that system as potentially shared account user, but you will be able to tie that action to the identity of a specific user in your organization. So when I say user identity, what I'm really saying is users that exist within your identity provider, within your LDAP, just all the users tied to their specific names within your company, your organization. So that way, if somebody goes to SSH into some server, you can make it so that you're not just seeing — hey, somebody SSH'd his route into that server, but you could see, okay so it was actually Jonathon Canada who has SSH'd his route into that particular server.

Jonathon: 00:08:24.623 So now this brings me to Teleport. Teleport is open source, so we can go into our GitHub repository, look at our code, start using it today. But what it allows you to do is — it allows you to tie SSO into access to your computer resources. So if you're using Okta, OneLogin, Duo, Active Directory, anything that is SAML or OIDC, you can tie that into Teleport in order to grant SSO sign in access to your users in your organization. So in order for somebody to say SSH or access a database, a web application, a Kubernetes cluster, you can grant that access via a single sign on and tie every action that that user does to their specific identity as it is within your SSO, within your identity provider.

Demo environment overview

Jonathon: 00:09:35.304 So the architecture and how that all works is here in this slide. So again, it's all tied to whatever SSO you're using, and the Teleport cluster is everything that's within this box. So that's a Teleport proxy, the Teleport authentication server, and then all of the compute resources that your users would be accessing. So the component that users will always be interacting with is this Teleport proxy. So users can either — in a terminal window in the CLI — use Teleport CLI tool called tsh to log in through this proxy to then access whatever they need to access. Or there's also a UI that's served from this proxy. So this user could go into a web browser and navigate to the URL of this proxy, and they are now able to access it — access these compute resources.

Jonathon: 00:10:44.848 So this user authentication is handled by SSO. So you can have MFA enabled as part of that. The authorization in terms of what they're actually authorized to access is still based on their identity, so it's based on perhaps their group membership. So if somebody in your organization was maybe an admin within your SSO, you can make it so that their access to your compute resources would be that of an admin. So with Teleport, you can enforce least privilege based on the groups, the attributes of your users — so based on their role within your organization. And they will immediately have the access that they need to get their job done. So the day that somebody joins your organization — they get added into your identity provider — they immediately have access to the compute resources that they need in order to start doing their job. The day that somebody is offboarded from your organization — they are no longer in the IDP — all of their access is now revoked. Teleport is using short- lived certificates for all access. So you don't need to worry about passwords here. You don't need to worry about shared credentials if maybe somebody has put their public key on servers that you are not aware of, or maybe a private key is shared. With Teleport, it's all short-lived certificates that are based on the identity of the user who has received one of those short-lived certificates.

Jonathon: 00:12:30.558 And how a user gets one of those certificates is when they start their day, they log in through this proxy, which starts the SSO login based on their group membership in that IDP, or whatever other attribute you might have within your organization. They then receive certificates that reflect what their role is, the organization. That all gets encoded into the certificate that is issued to this user. Once they have certificates, they can then go through this proxy to access whatever they are authorized to access. The other part of this is access requests. So as I mentioned, you should enforce least privilege for all users. But should somebody require temporary elevation of their privileges, that's where these access requests come into play. So this person could request some other role that has more privileges than what they have. That request can go to one of these third-party applications. You can also use the Teleport APIs to create any integration you'd like. But wherever this person's request arrives into, one or more users can approve or deny that request. If approved, this user receives updated certificates that reflect what is authorized in that role that they've just been approved to assume.

Demo

Jonathon: 00:14:05.497 So with that, I'll now move into my demo. So this right here — this is a Teleport proxy that is serving this UI to me in my web browser. I'm using Auth0 for my access here. So I'm going to select Auth0. It's going to start the SSO flow. I'm going to sign in with Google, just use my Teleport account. Here, Teleport, I'm in an admin group, so I'm receiving an admin role here, and what I arrive into is I can see servers that I'm authorized SSH into, applications that I can connect to, any Kubernetes clusters that I have, as well as databases that I have set up. I can also view activity. So all actions that our user is doing to any of these resources, I can come in here and see that it's tied to the specific identity of a user. And if I view details on any of these, I'm able to see information about that particular event. So in this case, the Kubernetes request, I can see that this was a GET, pods on the default namespace and the user who actually was issuing that [inaudible] request. I can also see session recordings. So what somebody does in an SSH session or exec into a Kubernetes pod, all of that is recorded, as you can see here. In this case, this was an exec into an Nginx pod.

Jonathon: 00:15:53.907 But here in servers, if I want to actually SSH into one of these, I can click this Connect dropdown, and I can select which user I want to SSH as. If I select this root user, I immediately have this SSH session and I can do whatever sysadmin activities I might be doing, and any typos are getting recorded. So everything I do is being fully captured and audited by Teleport. So here back in the audit logs — here is me starting that session. If I view the details, here is where I can see — not only can I see that I SSH'd his route, but I can also see specifically tied to my identity. If I click this button here, this starts the playback for me of that SSH session that I just had.

Jonathon: 00:17:00.158 So all this can also be done in the CLI. So here in the CLI — tsh is Teleport's CLI tool. And I can log in and reference the same proxy that I was interacting with in my web browser, and I'm going to tell it that I want to use my Auth0 single sign on connector. So it kicks open a web browser tab for me, and I'm going to sign in with my Teleport account again. I successfully logged in. So going back into the terminal window, now I can see information about this session for my user roles that I have. What users I can SSH as, how long my access is good for other information. And here, if I want to see the same servers that I could see in my UI, I can do that with a tsh ls. If I want to interact with Kubernetes clusters, tsh kube ls. And if I do any kubectl requests, Teleport is going to record, audit that, tie it to my identity, as well as record any kubectl exec sessions that I do. Also, for databases, with Teleport, you can connect to databases and Teleport will record all database queries and again tie it to the identity of the user who is actually executing those queries.

Conclusion

Jonathon: 00:18:41.057 To summarize, implement MFA everywhere. Use at least two of those three forms of authentication. Again, that's something you know, something you have, and something you are. Colonial Pipeline, that's just a very recent example that I have. But if you go through and search examples of when MFA was not implemented, a compromise ensued, you will find many, many examples. Target, JP Morgan, many other corporations. And then use SSO. Tie role-based access control to your identities within SSO. And really, use SSO in order to grant access to anything within your organization. Applications, servers, Kubernetes clusters, everything. And because you'll have SSO tied to that access, you'll be able to capture the identities of who is actually doing actions and what those actions are. And you'll be able to implement MFA as part of your SSO setup. Whether it's Okta, Active Directory, Duo, you can implement MFA as part of SSO.

Next steps

Jonathon: 00:20:09.605 So next steps — implement SSO and MFA. Check us out on GitHub and join us. We are hiring for a variety of roles, growing like crazy. We would love to talk to you. Thank you so much for attending today's session. Have a great rest of your day.