🔒 Security Week Product Discussion: Account Takeover Protection

Hello and welcome back to Cloudflare TV. We're here on the last day of Security Week, Security Week Plus. We've gone obviously Saturday and now we're on to Tuesday. So I have kept going with product announcements. I'm here with a great group of security team members and product managers to talk about the blog post they published today, what they announced and how we're using them internally to help protect Cloudflare as well. So I want to start by asking the panelists to introduce themselves and then we'll jump into some of the material. So why don't we start with Julie, Michael and then Kenny. Hello, my name is Julie. I'm a security engineer on the detection and response team, which is our internal blue team. I focus on writing security detections and handling security incident response. And I'm based in Denver. Hello, everyone. Nice to see you all again. My name is Michael Tremante. I'm a product manager for the web application firewall. So, you know, direction and feature base for anything regarding protecting web applications on the web as part of our platform. And I'm based out of the London office. Hello, everybody. My name is Kenny Johnson. I'm the product manager for Cloudflare Access, which is a product under the broader suite of teams. Products at Cloudflare. I'm based out of Austin, Texas, and we'll get in a little later about exactly what teams does as a product. Great. Looking forward to it. Thanks, Kenny. Julie, why don't we start with you today? We'll flip this a little bit. I want to talk about your blog post and, you know, you were focused on account takeover protection, obviously theme of the day. Why don't you start by telling me a little bit about what that lifecycle looks like? What is the typical account takeover from, you know, from your vantage point? Yeah, of course. So, the goal at the end of the day for an attacker that's using this tactic is to compromise an account. Preferably an account that has the ability to access privileged systems. And a lot of ways that attackers focus on that are the easiest are through social engineering or finding a way to, like, gain access to one employee account and then use that information to launch a further attack. So, for example, a set of passwords and email addresses could be breached and then they would use those through credential stuffing to try to get access to any account they could and then gain initial access. So, once the initial access occurs, the combination works. They can gain information on that system and then pivot to other systems or use that information they gathered to create a more sophisticated attack. Another way they can kind of get that initial access to an account is through phishing emails or creating a fake landing page for employees to try to put their credentials into. So, credential harvesting. These are attacks that are really, really increasing lately, especially as everyone's working from home. There's less communication. There's less times where you're talking to IT or security and you're verifying the things that you're doing. So, you're at home and you get redirected to a page and you sign in because it looks the same as any sign -in page you've seen before. However, what often occurs is that an attacker will try to send a really well-crafted email to you that sends you to a link where you can put in your credentials and then they'll keep those credentials and use them to log in as you and access systems. And so, often what they'll do is as quickly as possible, log in, gain information, and then log out with the information and data that they took so that they can then launch a better, more sophisticated attack on maybe executives or people with higher access, such as engineers or IT members or security team members. And often, the end user has no idea this even occurred. And so, when somebody gets a page that they're sent to or something that looks potentially suspicious, what do you recommend that they do? I think at Cloudflare, we seem to have a very open policy of reporting, which is terrific. And I know that nobody's blamed for clicking on something. I think the thing that we just want to make sure people do is report it. But what do you think that should happen there? What sort of process should security and IT teams put in place for responding to things like that? Yeah, I think first, security education for the end user is really important. Security awareness training is required by a lot of compliance acts. So, it's usually implemented, but you can really cater it towards the attacks that you're seeing as a security team so that users are prepared and they're not getting generic information. So, when we do security awareness training, we emphasize the fact that you could be sent to a page that looks exactly like the Octa page and you need to check the URL. Is it what you're expecting? Can you go to Cloudflare.octa and just verify that that's the page you're going to rather than clicking on a link and going to it? And then if anything seems abnormal at all, of course, report it to the security team. On our end, once we see that, we would pull up a logs for an end user and verify that the IP address, location, the behaviors all match things that we have previously seen for that account. Obviously, we would suppose that if an attacker was able to get access to that account, they wouldn't be logging in from the same IP address as your home address, wherever you live. So, that's like the first sign. Obviously, if you see any suspicious behavior, that's when you start launching into your incident response and trying to cut off access that account immediately, seeing what the attacker got access to. But at the end of the day, of any link, these attackers are focusing on ways to trick employees. That's what they're spending their whole day, like time doing. So, if at the end of the day, the user clicks on a link, then that's the security team's fault. That's our fault as a company, because we should make it almost impossible for them to get to that point where they would even enter their credentials. Great. And so, you mentioned where they came in, right? So, they may have come in from a different IP address. Did these attackers try to hide their tracks in any way or come in from locations that maybe differ from where they are? Yeah. So, usually, we see in the more sophisticated attackers, they'll try to mimic the employee's location. Obviously, they usually can't get the same IP address as the employee. But if they know it's an employee, they'll go on LinkedIn and they'll see, hey, this employee is based out of London. So, I'm going to make sure that when the initial login happens, that IP address is from London. And in general, this is a more sophisticated attack. If it's an automated attack, you'll often see just any IP address, it'll hop around. It could be in Africa, Asia, US, doesn't really matter. They're just cycling through IP addresses. But when they're specifically targeting an individual, they'll go through and be like, this employee is based out of California. So, they'll make sure they use a California IP. And that's when it's on the security team to make sure you're really paying attention to those IP addresses. Are they used for VPNs? Are they used as proxies? How much can you trust that IP address? And can you link it to a home ISP? Since we're all working from home, everyone should be either on a Cloudflare VPN, or they should be on their home ISP. And so, let's say an account was compromised, right? So, you've done the, maybe somebody reported, they typed something in where they shouldn't have, and you've locked down the account and done. Actually, let's talk about the account lockdown itself. How important is it to have a system where you can quickly lock stuff down? I think prior to introducing Okta and systems like that, maybe we had, I think in the early days of Cloudflare, I remember maybe there was a JIRA password that differed from some other system password. Can you talk a little bit about that consolidation and why that matters? Yeah. So, using a single sign-on like Okta is really helpful for both IT and security, being able to centralize that management and make sure there's only one path for initial access. Our transition onto Okta has been amazing for us. If you're a company that has various systems and you don't have one single sign-on, and you're maintaining all these separate passwords for users, that's when it's helpful as a security team to have a checklist of all the systems that an employee has the access to. And then you would need to go individually and check the logs for each of those systems, which can become incredibly cumbersome. I obviously recommend some automation for that. Not every security team has the resources for that. But on our side, as soon as we implemented Okta and now everything is behind it, we really only need to look at Okta logs. And we have built automation that quickly calls Okta's API and can suspend and unsuspend users, revoke their session cookie. And so it really speeds up that process. Great. And so besides shutting the account down and checking the logs for the login itself, what other logs do you typically look at as part of your response process? Yeah. One thing I'll mention first is that we only allow hard tokens for employees to log into systems. So they must authenticate by touching a hard token inserted into their computer or a YubiKey that they have for mobile devices. This has a lot of benefits because someone should never be able to get access to an account, log into Okta without having that physical token. And so that really limits the scope of ways attackers could get into an account. So basically, they would have to steal your laptop and have your password, which the chances of that are incredibly low. I mean, they still exist. We still think about those situations. But majority of times, if an attacker got your password, they would be able to log in. And then as soon as they were prompted for a physical token touch, it would fail. And so you would see multiple failed logins. So one thing that we look for now is where there are like 10 times that someone tried logging to this account and kept failing because they didn't have the hard token. And so that's like a sign that someone was being targeted. And so if someone was successfully able to log in, you might see like a couple of failed attempts, you would see someone log in, you would see a new device register because obviously they did not have the physical laptop that the employee would have. And then you would start looking to see if they successfully logged in, what applications did they access? What pages did they visit? Was it a page where they could download information? Did they trigger like a download of an internal confluence page? Did they access your tickets? These are things that we look forward to make sure we understand the scope of if an account was breached. What did they have access to? And how could they use that information to pivot and try to target Cloudflare in a different way? And that's, I think, something that a lot of security teams think about. And that's why it's really important to be able to have those initial like login authentication logs. So you really understand who's going into the systems. And then if those were successful, that's when you can start pivoting and looking at other systems that have internal information. Great. And I think the nice thing about the way that we've designed our network, and Kenny can speak to this a bit more, is that those Zero Trust principles, right? Where if you are able to authenticate, your ability to move laterally is very restricted by what specific applications you have. And I want to talk a little bit more about the hard tokens in a second when we get to what Kenny announced today. But let's go into some of the hacks that you've seen. I think Twitter was a very prominent one that you talked about in your post. What happened there? Why don't we start with what happened? And then I have some follow -up questions. Yeah. So in 2020, wow, that seems like it wasn't that long ago. Twitter had a breach based on actually a teenager who was researching Twitter's internal systems and employees and actually started by SIM swapping, which is basically when you go to a phone carrier and you tell them, hey, I'm this person, even though you're not, and you convince them that that's your identity. So they send you a new SIM card and you're able to take over that phone number. So they SIM swapped with an employee and then use that employee phone number to call other employees to then get their password. And so they sent them to a similar page as I was talking about. They crafted a login page that looked super similar to Twitter's internal system login page. They actually used Okta as well. So it was an Okta login portal branded with Twitter. And then once the employee put in their credentials, the attacker was able to capture those and then log into Twitter systems. And it was possible because they did not use heart token. So they allowed text messages or timed one-time passwords to be used to log in. So they were able to convince the employee to also give them that one-time password. And as soon as they were able to log in, of course, they just started pulling information, understanding internal systems. And the Twitter employee did not think to report this immediately. So security team had no idea. And at the end of the day, the attacker ended up being able to access incredibly sensitive internal systems. So this must have been an employee that had access to internal tooling other than just your typical email JIRA basic design tools. Essentially, or they didn't have systems that were locked down to this specific employee or group of employees can get to this system. I think one of the things I was really excited about we launched, I think it was Wednesday of last week, was the data loss prevention tools that are built into teams. So from an access and gateway perspective, if you're inserting yourself into that SaaS application flow to maybe an administrative dashboard, you can put controls around saying, okay, this user can only access these specific accounts within that dashboard. And so perhaps, obviously we're speculating here, but perhaps they didn't have that. So what lessons did we learn if you were sitting there in their retrospective with their security team? What were some things that you would raise? What could we do better in terms of locking this down? Yeah. And that's interesting because I think a lot of large companies, especially they didn't get hacked themselves, but they were watching the Twitter hack go down and then they sat down and did retrospectives of what could happen in a similar situation. So we did at Cloudflare as well. Only being able to use a hardware security token was the first big blocker. So if you have to have that physical key, right, even if someone calls you and tries to get your password, they're really not able to do anything. So that was the first step. The second step was having that granular access control that you were talking about that were able to do with Cloudflare access. At the end of the day, it's really difficult to implement on the IT side if there has been no infrastructure to do it before. You're starting from scratch and you're trying to understand everyone's role in the company, how those roles work together, who needs access to what. And a lot of times people ask for access to things that they actually don't need. And so having the executive buy-in to tell people no and also having those very granular access control lists are really, really vital. If you use access and if you use Okta, both of those are really great tools for doing that. But if people have access to everything, even internal sensitive systems, then you're opening up the risk of if you were compromised, if an employee laptop was stolen, if there was this attacker that was able to get in, there would be no stopping them in the amount of information they could take and things that they could do internally. So at Cloudflare, we're really specific about having very granular access control lists. And it's something that we keep improving over and over again to try to ensure that only people who critically need access to certain systems get it and that there will be audits implemented and really good off -boarding of users to make sure everything stays as tightly in control as possible. I'm laughing because as part of that iterative process of removing people that may have had access to something that no longer needed, there are certain access I had to just our blog, for example, that I remember in the early days of Cloudflare, I had maybe ability to edit posts or something. And I got an email not that long ago says, you've been downgraded in access to just submitting drafts or something. And so I think that point you made about it's an iterative approach and you can improve something, triage, maybe hard tokens, as you mentioned, might be the most important thing to start, get that in place, move on to the next thing and so on and so forth. And it's an evolving process. I think the other thing to keep in mind that I've seen is there's a trade-off of security and usability that your employees are potentially willing to withstand or slow them down productivity -wise. You don't want to stop them from working. You want to find that balance, I would imagine, between security and usability. Yeah, I think most companies think that implementing only hard tokens is actually really going to make it difficult for the employee, the end user, and that people are going to be really upset about it. But at Cloudflare, we've rolled it out. And I think, of course, there was bumps along the way, but I don't think anyone prefers typing in a one-time password every time they access a system instead of just being able to touch a key that's in their computer. It makes a lot of sense. It's very intuitive. And you don't constantly have to have your phone out and trying to juggle things. And so for companies who are considering switching, I would say it is a really, really great thing security-wise and usability-wise, as long as you train your employees and you get them used to it. I don't think I would ever see a world where I would want to go back to typing in a password or getting a text message. One, those are more insecure. And I work in security, so of course, it's not my favorite thing. But from a usability standpoint, it's just a lot of overhead to have to take time out of your day to get things done, to constantly be typing in passwords over and over again. Yeah. I think your point of training is well -received because I remember when we rolled it out, it was the most sensitive applications at first required HART token, and then gradually more and more and more to the point where any sort of access requires HART token. And I think getting people used to it for sensitive and then rolling it out elsewhere. And I agree with you. I don't want to go back to having to look up some time-based one-time password or anything like that. I think another learning that I would imagine here is don't share those codes that get sent to you with anyone, right? Those are for you to log in and nobody on the security or IT team is going to ask you for those, even if the phone number shows up as maybe a co -worker or something. Yeah. We always emphasize security or IT will never, ever call you. And we have internal messaging. So we would just message you internally unless you have lost your phone or your laptop. And then we'd be communicating with you over your personal email, but we would preface it. We would have a co -worker reach out to you. There'd be multiple streams to verify. So we always say, always verify before you take any action, especially when that could put internal systems at risk. Terrific. And so my last question is just about mobile devices, right? So everyone is glued to their phone for the most part. And what about mobile device authentication and how does that work? I may have tried to put the hard token in my phone, didn't find a spot for it, but what do you actually do there instead? Yeah. So any person or employee that wants to access internal systems on their phone has to have a mobile device management on it. However, if you don't want to download it on your personal phone, you can ask for a company phone and those have the mobile device management auto-downloaded on it. And then to authenticate, you would have to have a YubiKey. So we provide YubiKeys to everyone. And then everyone who has the mobile device management can use their YubiKey to authenticate and then log into internal systems. And that way we have all those logs. We know what people are accessing. We know what device they're using. We can verify a stem through the use of a hard token. And if there was ever any issue, we can always go back and we have all those records. So that's the most important thing to us is that we have those logs. And so if there was an incident, we would understand what was going on and we wouldn't just be like left in the dark. And I think it was great how we rolled that out, the mobile device management. I think we emphasize really as a company that is incredibly focused on privacy of basically anybody using the network, we really emphasize, here's exactly the lightweight controls it has, focused on security. Nobody on the security team cares what websites people are going to or apps they're using. They just care that the phone is secure if you're going to use your personal device to access. So kudos to the team on rolling that out. I want to switch gears to Michael. So we were talking about protecting employees at Cloudflare. Michael, let's talk about protecting web applications from account takeover attempts. So you are a recurring guest on Cloudflare TV during Security Week. Yesterday, you launched our new app, which has gotten some great responses from the community and from our users. How does the new app work in terms of account takeover attempts? How can we build on that or what have we built on that to help with some of the problems that Julie is talking about? Yeah, no, for sure. We've definitely thought very carefully about all the features we can build as part of the web application firewall to protect specifically login authentication endpoints. Of course, in the scope of the WAF, it's not necessarily only protecting internal employees, but it's more about also protecting potentially your end users, right? So in a B2C type context. There's quite a few features we've built and a couple of them we've launched this past week to help our customers do that. I'll just mention a few, and then we can deep dive in some of them maybe. Number one, last week, we implemented the ability to filter traffic based on the managed IP list, which is provided by Cloudflare, which will automatically be populated with IPs we think are proxy or HTTP or other proxy IPs. Julie mentioned earlier, an attacker may try to come from a specific location to try and hide their tracks. That's exactly what forward proxies are for. And if you have the ability within the WAF, of course, to detect when that is happening, you can increase the security postures on your login authentication endpoints whenever an IP connection and authentication connection is coming from, for example, an IP in a managed IP list. Another example of a feature, that's one. And of course, you can combine all of these things together. They don't work individually. They actually are complementary to each other. Another really cool feature we recently released actually today is account takeover protections by checking against the database of leaked credentials. So in Julie's examples, again, those are really targeted attacks, and someone may be trying to find the username and passwords of a specific individual. What we've seen happen more and more often on the worldwide web, though, is that many companies, for various reasons, get breached. And sometimes those breaches will contain databases of leaked username and password pairs from the end users. And hackers will often sell on these databases or use them themselves directly to try and get access to other systems. As unfortunately, there's a lot of research behind this. More than 50% of users will have reused their username and password across more than one application on the web. Not everyone is using password managers and has long passwords to keep their account secure. So what we've done is using databases available in the public domain, we've essentially imported these databases into our WAF engine. And by specifying specific rules that match against your authentication endpoints, we can actually warn the application itself, so the application owner, whenever an end user is accessing the application with a username and password pair that has been breached prior on the worldwide web. We found that that's a really good signal to potentially indicate an account compromise. And based on that signal being present, so we do find a match, it is then up to, of course, the application owner to decide, for example, if to force a password reset or to initiate a two-factor authentication, or maybe even just simply increase the logging for that specific user section to see if any activities out of the norm. I just want to interrupt you for a second. That decision of what to do is something that, as you and I have been talking to customers about this feature as we've been building it, has really kind of come up and it's been unique between the customers we've been speaking to. I think some want to then right then and there, based on that request header, force a password reset, and maybe they're giving some indication as to why. Others want to just flag it for internal account teams because I think they don't want to be seen as the source of the breach, right? And so I think their fear is if they communicate that out directly without messaging it in a phone call or something, they're going to be blamed for that. And so I like how you built it with the ability to just signal and then let someone else decide. Of course, if somebody does want to block it outright, that's their prerogative, right? And they're able to do that. But if they want to more carefully message it, they can, right? Yeah, that's right. So the WAF is the tool, and I think I said this in our session yesterday as well, a big part of security is visibility. In this context, web application firewall is only warning and alerting the application that something might be off or some action may be needed. It is then up to the application owner, based on the header, that we would forward to the origin as part of the authentication request to then decide what to do next, right? In our case, because this is intended to protect applications which are used by end users, not necessarily internal employees, the database we've loaded has got billions upon billions of leaked credentials. So it's more of a signal something might be off, especially if the rule starts triggering over and over again in a very short period of time. For example, that's a really clear indication that a credential stuffing attack might actually be underway, right? And with big numbers, if you have a large application with hundreds of thousands of end users signed up, it is very likely some of those will have reused the username and passwords, and therefore you need to increase your auditing or logging of end user behavior as soon as they log in. One of the things you mentioned a second ago was the lists, the managed IP lists that people can utilize. And so I know we're looking at open proxies now. It seems like we've got a lot of interest. I saw some tweets this morning in response to the post, I think tweeting at our CTO asking for other types of lists. Do you see us, I know you're working with another product manager on this, but do you see us introducing other managed IP lists? And if so, what are you hearing from customers that would be useful there? Yeah, no. Managed intelligence from Cloudflare is in very high demand. And it mainly comes from the fact that given we have so many web applications behind the proxy, we do have a great visibility of what's going on on the worldwide web, right? So this gives us a bit of a competitive advantage to build these intelligent feeds that we want to provide to our customers to use and deploy with a simple click. The proxy IP list is the first example we've built here. We get to a lot of demands, even all the way down to being able to categorize IP addresses based on commercial versus residential or versus hosting company IP addresses, for example, is a very high demand, as that's also an indicator, right? Based on where your traffic is coming from, if this is known to be a residential IP address, you can make different assumptions or have a different security posture compared to an IP that is normally used for commercial or for hosting reasons in the past, right? Other examples, and I think Kenny as part of Cloudflare Access and the broader Cloudflare Teams products already using are IPs that are known, for example, to be hosting malware, or we've seen some prior malicious activity coming from specific IPs. And in that context, it's not only lists of IPs, we're actually looking at expanding that concept further and potentially providing lists of domains or lists of full-on URLs or paths that you can then use in your filtering as part of the WAF to build those security posture. There's actually a really cool internal blog post I was reading a few months back that talked about the ability to detect carrier-grade NATs or VPNs based on a number of unique sessions coming from behind those IP addresses. And so IP addresses are useful in some contexts, right? But they're a very blunt instrument, right? And so if you're trying to rate limit or do something based on an IP address that hundreds of people are NATing or padding behind, that's not that effective, right? And so I know we're looking at, and we've been using ourselves, a lot of the stuff that Kenny's working on to really authenticate the individual user behind it, right? And the resource they want to go to, not just the IP address, but definitely there's still a number of uses there for managed IP lists. I think the other thing that, as we get into the intelligence, just to divert here for a second, but the ability to take a lot of intelligence that the Cloudflare for Teams group is creating and using that in the area that you look after, right? And so serving files back, for example, and the contents of those files, checking them against some of the gateway malware stuff that we announced last week, as well as potentially some of those domains, right? Which if a domain was recently registered, it's actually a really high signal that it may be something that you don't want to send. One other example that I think is good to mention, the botnets are a thing that is becoming more and more common nowadays, and botnets can be very, very large. We always hear about compromised devices all the way from your microwave, to your oven, to your security camera. Very often these devices are part of a broader botnet that gets used then to perform all sorts of attacks, including potentially credential stuffing attacks. The larger the botnet, the more effective it is, because your rate limiting strategies out of the box become very ineffective, given that a very small number of requests will come from the same IP address. So if you're employing a pair IP address rate limiting strategy, it's likely going to go completely undetected. However, these botnets, when they get created, they often get reused or sold on the dark web for the highest bidder to do whatever action they want to do. Therefore, at scale, we can actually see when a specific IP address is performing several malicious payloads across our entire customer base. That's another example of where the additional intelligence really becomes effective. So if it's flagged as a botnet IP address, then you know that very likely it's not a legitimate end user logging in, and you can make a decision on a very limited amount of requests. That's a great point. You can fly low and slow against a single customer of ours, but if you're doing that to multiple customers and there's a good chance it's going to be proxied and protected by Cloudflare, you're likely to trip some of our models and find yourself on the naughty list and get blocked from applications. So let's talk a little bit about how the exposed credential stuff works. That was really fascinating to me. Can you talk a little bit about how we built it on existing technologies that we highlighted earlier in the week, the Rust -based technology, and get into that a little bit for me? So it's very interesting how we built this. So yesterday we announced a new web application, Firewall. The new WAF allows us to build and provide rule sets that our customers can use and turn on with a simple click. Powering the whole thing, there is a matching engine, which we use to essentially write the rules themselves, which are written in our wire filter syntax. It's our internal syntax that we use to write rules. The matching at the edge against the login endpoint is using the same rules that are powering the rest of the WAF, right? And you can be very specific on how you write those rules. So you can say, for any request matching this specific authentication endpoint, if it's a post request and the request contains a specific username and password field, only then perform the additional logic to check the username and password. The username and password pair, of course, remains within the process of the WAF, so it's not stored or logged in any way whatsoever. What the WAF will do when it finds a match, it will then perform a lookup with a hashed and encrypted version of the username and passwords against a database that we're collecting and building based on public domain leak credentials that we find on the World Wide Web. The actual WAF itself will actually make an API call against the service we've built to perform the lookup. And the nice thing here is that service is actually built using Cloudflare Workers. So at Cloudflare, we try to dog food and use all of our own products and our platforms to learn and make them better. This is one perfect example of that. The worker itself implements a pretty sophisticated protocol that ensures complete anonymity on the username and password we're doing the lookup for, but then will return a positive result in the event the database contains the specific username and password pair. And then, of course, that gets sent back to the WAF, and if the match is found, we then add a header. Adding a header is now an action available in the new application firewall, just like a block or a challenge or any other action, and that header gets then sent to the origin. The whole process, because it's built on workers, the database gets actually cached at the edge automatically. As for that part, another little nugget of interesting information, we're using workers.kv, which is our distributed data store, which we've built on top of workers to allow for fast lookups, very fast reads across the entire edge network. So the nice thing is that turning this feature on is a single click. We've reused components and technologies available within Cloudflare, and the entire process is actually pretty performant as well at scale. So you don't have to worry about the load on the system. It's pretty cool to see how we're using those building blocks that we're adding. I think we've talked a few times about, so in this case, workers and workers.kv, we've recently launched the project Fairshot using durable objects, and I think just that was a crazy thing to see how quickly that came together to get out there and protect those vaccine sites. And the only reason we were able to do that, of course, is because we had that durable objects technology that we use ourselves, and as we implemented that, I'm sure there's a lot of feedback loops to Kenton and his team talking about how we can improve that experience. And so you mentioned dogfooding. I want to talk a little bit about that. So we're dogfooding in the sense of that we're using our own systems to build our products, but what about this technology that you've developed? How are we planning to use that for Cloudflare? Yeah, no, that's a good question. With the help from the security team and from the various application teams, we're we already deployed the exposed credential checks on all of our staging environments. We were actually looking at the data recently. Of course, staging environments are accessible only to internal employees at the moment, and we have very good security standards in the company. So we've successfully not made a hit against the database once, but as expected, we're actually planning on deploying the exposed credential check on the authentication endpoint of our own dashboard, our end user facing dashboard. If that's not happening right now, it will happen in the next couple of days max. And we'll use that data then to make subsequent decisions on how to protect our users. We haven't made a decision on what actions to perform in the event there is a match. If it's just monitoring or increasing logging for specific sessions to look for malicious potential activity, or if potentially to do something a little more drastic like a password reset to increase the overall password security of our end users, or maybe initiate or enforce a two -factor authentication. But I'm really excited about this. It's going to give us really good data. Of course, we're also talking already to several customers who are looking at deploying this on their own applications to start leveraging the new app feature. Yeah, I was on a call with one a couple of weeks ago, and as soon as they saw we're building, they're like, we absolutely need this right now. And I think it emailed you after and they wanted to get it up and running in a couple of weeks. And so I know you've got some pent -up demand there. So looking forward to you helping solve those customer problems. What if someone is watching this at home and they want to start deploying this for their account? Who's this available to now? And how do they get access to it? I know it's early stages, but how do they get involved in the beta? Yeah, so along with Kenny's post today, there's a post about account takeovers with the WAF. In that post, under the Expos credential checks, there's a link which will bring you to a form to sign up for the beta. So for anyone listening from home, please head over to the form and sign up. All those requests will actually get to me directly. And I'm planning on getting back and getting a number of folks into the beta so we can start testing and getting feedback on how the feature is working, what sort of additional functionality customers would like to see in the beta. We're going to be giving this out probably to our enterprise customer base, but we are exploring possibilities to bring this down maybe even to some of our self-service plans, especially given the data we're using is in the public domain. So as part of giving back to the community and making the web a better place for everyone, that's something we're seriously considering, especially given account takeovers has become a very prominent problem for anyone launching an application nowadays. Yeah, I'd love to see us distribute this very broadly. So I'm sure we'll talk about that once we start taking the betas. But if anybody's interested, regardless of what plan level you're at, just go ahead and sign up for it. And hopefully, we'll be able to bake it in soon. So where you sign up for any account at Cloudflare, you get access to this. But we'll announce more on that as it plays out. OK. Kenny, thanks for waiting patiently over there. Michael mentioned a little bit about just kind of teed up some of the Cloudflare access stuff. But before we jump into the feature you announced today for access, can you just explain what access is for everyone? Yeah, happy to set the scene for those of you all that aren't familiar with access. So access is actually a product that we were able to build on top of Cloudflare's existing network infrastructure for some of its more core products, things like DNS and CDN. Really, what Cloudflare access allows you to do is put Zero Trust access control in front of the applications that you maintain as a business. So that can be self-hosted applications that you're either running in your own data center on a public cloud. That can be non-HTTP applications, things like SSH or RDP, as well as SaaS applications. So access can actually act as your SSO provider, pushing out to your SSO provider like Okta or Azure AD or somebody like that to provide Zero Trust verification across that set of applications. And what you're able to do with access is actually set up and configure granular policies at an individual application level to check the user device as well as location of that user before either allowing or denying access. And the device context piece is kind of the new element that was announced today and that we're really excited about getting launched out into the world. Great. Well, we'll get into that in a second. Can you just give some examples of how people, excuse me, are using access today? So I know you speak to a lot of customers and I think I heard some cases around contracting employees and other use cases, but how do you see this get adopted in an organization and then get rolled out? Yeah, great question. So typically where we see businesses get started are self-hosted homegrown applications that they built internally, just because typically those applications, it's a bit more, there's a bit more of a lift to put authentication security controls in place. So by standing access up in front of that particular application, you can put in place hard authentication rules like verifying that there's a hard key running, hard key plugged into the device, there's a certificate on the machine, things like that. The other piece that's really common that we'll see is if I'm using Okta as a business, but I have a swath of development contractors that I don't necessarily want to fully onboard into my Okta system, I can actually set up additional identity providers within access. So I can either plug in GitHub and allow specific GitHub accounts to have access. I can stand up a one-time pin for users to be able to log in. So it gives me a lot of flexibility to kind of span across multiple identity providers and then allow Zero Trust access into various applications versus just giving like broad swath VPN access to my entire plane of apps. Yeah, I loved when we moved from having to log into Cisco and a connect VPN to go to things like the wiki and the Jira ticket tracking system to just being able to fly through the access authentication. Everyone, when we launched it, when they asked me what it was about, my question to them was, do you have a VPN? And they said, yes. And like, do you like it? No. And then, you know, it's a pretty easy discussion from that point onward. You mentioned Zero Trust a few times, right? That's a term that's thrown around quite a bit. What is the Kenny Johnson definition of Zero Trust? You know, as in speaking for Cloudflare, how do we think about Zero Trust? Yeah, I'm trying to check my buzzword count. I think Zero Trust is in the squarely outside buzzword territory these days. But yeah, in terms of how we think about Zero Trust, it really is truly that. It's trust. It's having Zero Trust in any request being made to any application, verifying that the verifying the integrity of any request made to any individual resource or service. So if you think about kind of a more traditional VPN model, once it's kind of castle mode, once I log in using a VPN, I have broad swath access to a number of different applications versus the way that we think about access and the way that we think about Zero Trust is that even if I've been able to prove and successfully log into, say, our Confluence Wiki, that doesn't mean that I should then also be able to access GitHub or GitLab or something like that. Each individual application has its own set of policies, its own requirements, its own set of allowed users to ensure that every single individual request being made to that application is checked. And those authentication methods, like what do we support today? Where can people find that? And if there's something that's not listed there, how do they get their identity provider added to that? Yeah, great question. So if you go to developers .Cloudflare.com and go to the Cloudflare for Teams section, in the identity section, we list out the kind of base set of integrated identity providers that we work with. Additionally, if you have an identity provider that's not listed, as long as they support either the SAML 2.0 standard or OIDC, they can be integrated with access as well. So it's very possible to take something that's been homegrown or a identity system that just isn't listed to also set up. So that's something that we can definitely have a conversation about. So if Michael's built his own homegrown auth system, he can get it added to access and get up and running. That sounds great. Exactly. As long as it's OAuth or SAML. All right, Michael, follow the standards. So Kenny, we've spoken about hard tokens a few times, and I know Julie had to drop off, I know she's super excited about the use of hard tokens on employee-issued laptops from the company. But before we get into that specific part, how do you use hard tokens today with access? I know we have to use them, we all have them in our laptops, but how does that actually work? Yeah, so that's an additional piece that we're able to set up and require within access policies. So I'm actually able to configure policies down to the specific type of multi-factor authentication. So do we want to see biometric verification? Do we want to see hard key verification? Or is a one-time pin suitable for this particular application? And the way that we're able to verify that is it comes as part of the SAML payload that we receive from the SSO provider. So we're able to see the type of MFA that was used in a given authentication attempt. So that's really handy because, again, I can granularly define these things. Maybe for Slack, a one-time pin is acceptable, but something like Bitbucket or GitHub, I want to actually enforce a hard key. Yeah, that actually is really useful as we talked about the gradual rollout. So I would imagine we use that to say these really sensitive applications require a hard token initially getting users accustomed to them before just turning them on full bore for all applications. So it's great to see that you can mix and match the authentication, the multi-factor authentication methods. Yeah, it let us fit nicely to the adoption curve of hard keys within the business. Yeah, exactly. And I think the mobile keys especially, the hard keys are probably not going to leave your laptop, although I'll tell you in one second why mine did leave my laptop. But then the mobile device, having the thing on your key chain, the YubiKey. So the hard token, I remember I had one of those MacBook Pros that had those awful keyboards that you just couldn't type anything into it. And you would type, you'd hit a letter and the same letter would come up five times. And so I put a request in to our IT department and they were great in getting me a new laptop really quickly. But in the interim, I needed to do something. And so I was able to actually take that token out, put it in my personal MacBook that was older. In my case, anyway, it was current and patched and everything, but had a usable keyboard. Why do people care about where that hard token is? What are some of the things that people worry about when you put a hard token in a different device to access a corporate resource? Yeah, that's very much the yes, but of, hey, you've implemented hard keys. It's, yeah, that's great, but it's really easy for me as a user to walk my hard key over to a personal device and still gain access to applications. And really the reason that becomes important is there's a number of reasons as a business where that becomes a big deal, but kind of the first piece is you don't necessarily know where that device has been. And you don't know, you don't have any visibility over that device. You don't maintain any control over that device. So that device could literally be running Windows XP and a really old version of Internet Explorer with many, many known security holes. It could be running malware. Similarly, so there's kind of the security, just vulnerability piece, but then there's also the data loss prevention and data exfiltration piece in terms of if I'm an employee, malicious or not malicious, who's attempting to access sensitive customer data or sensitive documents from a personal device, it's really easy to accidentally download that and leave that on a device. Or I could even be using a parent's device or a friend's device and leave something sensitive behind. So it's just another way of maintaining control over where your data as a business lives, as well as having control over the integrity and security of the devices that are accessing your particular resources. Yeah, that's a great point. The data control side of it, I wasn't even thinking about that as much. I was thinking more of the, it's not running the latest antivirus or not running the latest browser. And there's problems there that could get taken, but actually bringing data down to those devices, which may otherwise be compromised. That's a really good point. So how can we, I remember meeting with Joe Sullivan, our CISO, prior to security week and trying to enlist the help of his team. And they've been terrific just helping talk through some of these hacks and Julie just joined us. But one of the things he said to me was, and he's probably said it to everyone he's met with, but hey, here's what we want, right? I want the ability, and this is not even an area I work on, but I was a good messenger coming back to you and Sam and saying, hey, this is what Joe wants to see happen. Talk a little bit about the request to say, these hard tokens can only run on a Cloudflare issued laptop. How do we go about actually enforcing that at a technical level? Yeah. So that's what we're really excited to announce today is the ability to support and enforce that only managed corporate devices are accessing specific applications within Access. So that's really kind of, we took our internal security team and Joe's request, as well as we've had a number of customers begin to bring up the ability to check if a device is managed or not. We took that and built support for that into Access. And the way that that works is within Access, I'm now able to define a list of corporately managed serial numbers. So the serial number is a relatively atomic thing that can't be changed to identify a particular device. And then within Access policies, I'm able to require that in order for a device to have access to a particular application, their serial number must be in the list of corporately managed devices. Great. And so those can be loaded up as sort of the IT team is provisioning the device. I think we might, if we get to it, we might have time at the end to actually see what that looks like. We haven't done a live demo yet, but we might tempt the demo gods on the last day of security. We can see how that goes. So what is required to run on the devices and how do we think about this from an agent perspective? There's a lot of discussion of endpoint protection and what actually do you need to run? Yeah. So the only thing that needs to run the device is the Cloudflare warp agent. And if you guys aren't familiar, the warp agent is built on top of Cloudflare's public DNS resolver 1.1.1.1. I think I got the number of ones right. It's built on top of that. So it's been road tested by millions of users out in the world. We've repurposed that within the Cloudflare for Teams suite to do two things. One, to do HTTPS and DNS filtering on devices, as well as now to capture context from that device. So once the warp agent is running on the device, we're able to communicate things back like, what's this device's serial number? Is this device running Carbon Black or CrowdStrike or another endpoint protection software? Those types of things, which then allows us to do real-time checks when a customer attempts to access a particular resource. I love seeing how we're taking these consumer applications and learning from them and baking them back into products that we're selling to customers and using Cloudflare for Teams. Really cool to see. Similar to how we can roll out new protocols to our free customers who can help us learn about them as we start to mature them and harden them to bring them up a plan. It's great that we can do this and lock this down, but what if I want to allow employees to access some applications, for example, from their personal device? Are there ways that we can do that and mix and match those policies? Yeah, and that's really the beauty of access, is that I'm able to granularly define policies at an application level, even down to a subdomain or path level within applications that I'm self hosting, and I'm able to create multiple policies that apply to a single application. I can be really, really flexible in terms of, let's take Slack as an example. Maybe I just want to allow anybody to have access to Slack that has a corporate domain email address. That's just a single access policy saying, hey, anybody with an at Cloudflare email address can get access. Then we take something that's slightly more sensitive, like Confluence. Let's say anybody who I see as running a corporately managed device, I just want to allow them through. So just at Cloudflare email address coming from a managed device. But maybe I also want to allow people to access Confluence from their personal devices. That's where I could add an additional policy to maybe step up what they're required to do in order to access. So maybe I want to enforce that they actually have to go through MFA, or maybe I want to require that they do have a personal device hard key on their device. Or even possibly you could do something like applying an MTLS certificate onto that device. So if a user truly does want to use their personal device, you could put them through the steps of actually downloading your certificate and verifying that certificate. So there's a number of things that I'd be able to do. And then finally, something that's where I can actually access production code, like Bitbucket or GitHub or something like that. That's probably just a unilateral that only can be corporately managed devices. And I want to require a hard key. So I'm actually able to then just completely lock that down to only managed devices. Plus they have to go through a specific tier of MFA in order to have access. Great. So we've got about five minutes left. Let's see if we can try to bring it up. And while you're bringing up what it looks like from a policy definition perspective, who can start using this today? What size company do you have to be? So really, this has been built for anybody. So this could be somebody large like us at Cloudflare. We're figuring out the best way to deploy this internally all the way down to if you just have a few individual employees within your business. If you're the team's plan with Cloudflare for teams, the first 50 users are actually free. So if you want to go try it out, you can go to the team signup page and set up an account and give this a go. This is in the team standard plan. So it will be available to any user. Yeah. So what this looks like is I'm able to set up and define a list of corporately managed serial numbers. So once I've set up and defined my serial number list that I've called corporate serial numbers, what I'm then able to do is within an access application. So in this case, I've got something like Grafana that I'm running on a digital ocean. Server. I'm able to come in, and in this case right now, what I'm requiring is that I have the Cloudflare gateway running so that the Cloudflare work agent is running. I've been doing this whole call on the on the work agent, by the way. And what I'm also then able to do is now I can require that a specific set of managed serial numbers is verified before a user is able to access access Grafana. What I'm able to do additionally within this policy, I can do things like check to see what country this request is coming from, the email address, IP ranges. And the other newer piece that we announced is support for endpoint protection providers like Sentinel One and Carbon Black. So I can actually check to see, is this particular process running on my device? Yes or no. Before allowing access into that particular resource. I love how you can decide exactly what you want to do. And I think Joe mentioned he wants to do five factor authentication, right? Where it's like, you must be running this agent. You must have a hard token. You must be using a Cloudflare issued laptop. You must not be in these specific countries, for example. And I can't remember what the fifth was, but maybe it was time of day or something. But it's neat that you can mix and match all those to meet your specific organization security posture. Yeah, definitely. And we make it easy to really granularly do this as well as I can create shared policies as well that I am able to centrally manage and then apply those broad swath across my application. So if I just have a set of allowed countries, I can just take that on one time and then apply that across my set of apps. Great. And if people are starting to use this and they want to give feedback to you or to Cloudflare, how do they actually go about doing that? I think the best way, if you're an enterprise customer, is just get in touch through your account management team. I think that's the best way. And if you're a free user, you can reach out on Twitter through the community. Great. All right. Thanks so much, Kenny, Michael. This is great chatting with you all. Appreciate the live demo. It's always a little bit scary, but it went off without a hitch. So thanks, everyone. And this concludes Security Week. So thanks for joining us. And hopefully, you learned a bunch and get started using some of these new products we shipped. So talk to you soon. Bye. Thank you, Michael. Bye. Bye.