25 Oct 2021 · 32 min
Google security researchers Kurt Thomas and Elie Bursztein say modern hardware security keys block over 90% of phishing attacks, but cheaper SMS-based 2FA can be bypassed for $500. The real gaps: cookie theft, account recovery flows, and Business Email Compromise.
Chapters
Security.
Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here are myself, Tim Peacock, the product manager for threat detection here at Google Cloud, and Anton Chuvakin, a reformed analyst and member of the cloud security team here at Google. You can find and subscribe to this podcast wherever podcasts are sold and distributed, as well as at our website. cloud.withgoogle.com/cloudsecurity/podcast. If you enjoy our content and want it delivered to you piping hot every Monday afternoon Pacific time, please do hit that subscribe button on your podcasting app of choice. You can follow the show and argue with your hosts on Twitter as well, twitter.com/cloudsecpodcast. Anton, this is a fun episode we've got on— well, what's it on? Phishing? SMS? 2-factor? What are we really focused on today?
Well, actually, this is all of the above. And to me, this is interesting because we get to push really good people from one of the great Google security teams about whether they really fixed phishing or not. Like, I think one of the things I'm going to ask, as you'd hear in a few minutes, is, have you guys actually solved phishing? And I think they were pretty close to saying, well, yeah, for this context, I think this solves phishing, which to me is kind of an amazing feat of engineering and, of course, of getting that technology to be adopted. So this is magical. And And it does not involve AI. Actually, does it?
I don't know if we can say whether it involves AI or not. It's really fun to push 2 people who've worked on a team as successful as theirs as much as we did. This was a fun conversation for sure.
Okay, with that in mind, maybe time to start on the episode.
Our guests today are Kurt Thomas and Elie Berstein, both anti-abuse and privacy researchers here at Google. First question on our topic of phishing today: is MFA a silver bullet? Like, can we just say MFA fixes phishing for good, or is that too much?
Well, it's complicated, as usual in security.
I knew it, I knew it.
You knew it, you knew it. Yeah, exactly. In general, state-of-the-art multi-factor authentication that would rely on security key and crypto would solve phishing As we know, yes, if we have those security keys or phone security keys who don't rely on human sharing secrets, but rely on cryptographic protocol and deep operating system and browser integration, yes, those will protect against traditional phishing. People entering their password or getting their SMS code stolen. Absolutely. So yes, state-of-the-art MFA would solve traditional phishing. As we're probably going to go into detail later on, there are alternative forms of phishing like cookie theft, which is not traditional phishing, that are not covered by MFA, and we can talk about the limitations there. But yes, doing MFA will remove most of the threat model for phishing. Kurt?
There are a variety of bypasses, and we'd love to dig into them. Some of them are rooted in phishing, some of them are rooted in malware, or even just the account recovery process. So Friction that we try to remove from users also becomes a mechanism for attackers to break in. But as Ellie said, I do think it's appropriate that if you take something like security keys, when paired with secure recovery options, that you can in fact prevent at least remote phishing. Even though there are going to be bypasses, and we're going to talk about them, that shouldn't leave users or administrators feeling kind of helpless about the process.
Mm-hmm.
Like all MFA, even if it's not a security key, dramatically increases protection against phishing. And I think that's the message that you should be sending to users and administrators.
So wait a second. So this is a bit subtle because I think that we tried to push you in the absolutist corner, like, is well-designed MFA completely solves phishing? And you kind of told us yes, and then there was a bit of a pause, and then there was a bit of a but, right? So I'm hearing if it's really well designed and well implemented, it solves phishing, right? Like, if I have secure account recovery, I have secure cryptographic hardware, then phishing is kind of gone for good. It's not 90%, it's not 98%. It's sort of like actually gone.
You're pushing us into a corner. Thank you so much for pushing us there.
But I gave you a hole. I said, well-implemented. You can always say, ah, well-implemented is impossible, right?
Yeah, I get it. Thanks for giving us the rope to hang ourselves with. Thank you so much. Really appreciate that.
Or to escape with.
Yeah, or to escape with. I think the main problem is phishing is ill-defined. I go to a web page or something which will have no local foothold, right? No APT, no malware, and the user is deceived to enter some credential. Yes, absolutely, security key, because there is no user input and you cannot mess it up, you will be protected against phishing. And as Google said a few years back, since we have implemented @Google Security Key for all our employees, we haven't had a single case of phishing successful. Just to be clear. So this is what Google is using every day for all our employees. We have Security Key. This is the only thing you can use. And thanks to that, the traditional form of phishing is gone, and we haven't had a single case.
Hmm.
That's the reality of it. As we said, if you take the broad thing of the user credentials have been stolen, which is a broader definition, then things got more complicated, right? So we want to be very clear about that. But if the main concern, which is the bulk of the phishing stuff, is you get deceived and there is some impersonation happening, I don't know, like you get a free gift card and then you enter your credentials, or, you know, there was this infamous holiday gift phishing that people really hated on Twitter. And, you know, there was this massive thread and people were really upset. And that is completely preventable through strong MFA, which is security keys or Windows Hello, part of the same protocol called WebAuthn, right? WebAuthn will solve that. Yes.
Okay.
And there is no conditional but. This is yes.
So this is actually really good because I feel like we should celebrate this moment very briefly, maybe not with champagne, but it feels like if you go this route, this specific attack that's well-defined yet still still common is actually gone for good, which is not something we have a lot of in our beloved domain of cyber, right?
Ah, come on. We made great progress on system security, right? When we had buffer overflow and we had very simple shellcode, you implemented ASLR and you implemented DEP, and then a lot of the traditional exploits became incredibly hard. We started to have sandboxes. The complexity of attack has rose quite high, right? I think we estimate now that a zero-day against a phone, Android phone, is over $1 million, right? So the bar to break into a phone has increased tremendously through a set of few core technologies, which actually make a big difference, and that make you feel you want modern hardware and modern operating system, which have all those core technologies, right? And we can talk more about it when we talk about cookie theft, right? But those are the core technologies which, yes, make an advance. So I don't know if I would do the champagne only for that one. I would say we made a lot of progress, and then the attacker moved on to other things, of course. Right. That's always the case.
Right. And so to me, this is still a good moment where it's not just like we raised the bar for this specific attack, which is not theoretical, but actually common. We sort of have an implementable way to fix it for good. To me, this is still a brief moment kind of happiness. I think system hardening is a good example. If you look at, I don't know, Windows from the '90s, doesn't matter what version, it's a different system compared to modern OS, to Chrome OS, to even modern Windows. Progress is very visible, but I can't say we fixed overflows or we fixed remotes or we fixed other stuff. So probably phishing is good. If phishing dies, I don't think anybody would be upset.
Yeah.
But to kind of continue on this theme, When you go and slightly broaden, I guess, phishing beyond just, here's the clickable link, click on the link, I'll steal your creds, I use your creds, I'm you. Like, if you broaden from that to cookie theft, a few other things, then MFA starts to be reliable yet not perfect. So what are some of the bypasses if you go this type of broader phishing credential theft stuff?
I also think there's an important caveat in there that security keys are not widely adopted by consumers or any enterprise folks. So when we talk about bypasses, we even have to think about other forms of multifactor authentication, be it like SMS or an on-device prompt or different things like that. So we actually ran a couple of experiments in our research group where we teamed up with the University of California, San Diego. There are underground markets where you can purchase what we call hack-for-hire groups.
Mm-hmm.
So these are people who will break into somebody's account on the order of like $500 to do it. And we actually studied all the bypass techniques that they were using to get around 2-factor authentication.
Cool.
So that's fun research. You can kind of learn all of the dark secrets that are used by simply paying a credit card. And what we found is that a lot of the techniques that were used are kind of man-in-the-middle phishing pages. The fundamental flaw with SMS authentication right now is you're going to get a code sent to your device, and then you're going to relay that code to a website. And ideally, that website is the person you're authenticating to, but it could also be the phisher's page. And so they would do live attacks as you are logging to the page. They would relay all of the information— your username, your password, the 2FA code— to the real login server and then have access to your account and then proceed to, say, download all of your contacts or all of your data and things like that.
So it's not any kind of profound Signal 7 hacking. It's really just an intermediate page. It's not like— way less fancy. It's not capturing SMS in flight.
Yeah. And this is an evolution because we've seen tens of thousands of off-the-shelf phishing kits that continue to be used. And they don't have the capability necessarily to do this man-in-the-middle style attack. All they do is start collecting additional information about you. What's your phone number? Where are you located? Because we alluded to earlier, account recovery is a major vector through account compromise as well. While you're phishing somebody for the username and password, you can also gather all this auxiliary information that might let you bypass the recovery mechanism. Say, hey, I lost my phone. I can't do SMS right now. Can I just prove to you I know my phone number? Can I prove to you I know where I live? And you then let me into the system.
Yeah, but this, to me, is not well implemented, though. To me, this is poorly implemented account recovery, right?
It's hard to say that it's poorly implemented because there is friction in that process. What do you do when somebody loses their device? Do you just say, you can never get it back?
Sorry, bye.
Exactly. And this is a unique position for, I think, folks in the cloud. When you have an administrator, there's actually a trusted source of contact you can go to that you can go for the recovery option. But when you're talking about consumers, that doesn't exist at all. And so there's always going to be these trade-offs of how hard can we push security versus how hard do we push the friction on end users and usability.
Yeah. One of the work in our team is to understand what we call at-risk population, which are people who have different type of risk profile. And an account, if you are a CFO or a CTO, your risk profile is drastically different from someone who might not have such an ability to, you know, to send an email, say, hey, do a wire transfer. We talk about BEC, right? Business email compromise, where you can game the chain. And again, this is a form of phishing, or it's this form of impersonation, if you would, right? It's a broadened thing. And if you can confuse someone in the chain to believe you are really the CEO or the CFO, and you really don't the money transfer order, then there is still this human element, right? This human element is not going to go away. You need education, you need a lot of other control to that. And so your risk profile will be very different whether what type of company you are. We did a lot of presentations at RSA around, you know, the different type of enterprise vertical have different vulnerability, different posture, different risk. If you work for a political campaign, we just had a paper on that where your risk is way higher because who would not try to attack an election, right? I mean, at that point, this is a big topic. You are a more bigger target. And we can think of other activists, we can think of other at-risk populations. So there is also this question of trying to get defense at the level of risk you are facing.
Mm-hmm.
Try to understand that with a caveat, right? With a caveat, which is If you have multiple accounts on the same computer, you can get confused, right? If one uses 2-factor and the other one does not use 2-factor, you know, that becomes a problem because some people might want to, oh, I'm sharing with my personal account because I'm going on a Sunday in the cabin in the woods and I still want to read this document which was shared with me and I don't want to take my work laptop and something like that. And now you create this kind of implicit trust between your own accounts. And we know people have a lot of accounts. People have different accounts for different profiles. That's a very important model for them. The same way they have multiple Chrome profiles, right? People would like to kind of bucket stuff. As an administrator, there's also this question of being careful about the implicit trust and what type of device you are letting your data be in, because it's very easy to believe you are isolated.
Mm-hmm.
And then in reality, you are sharing the computer with other companies because you have multiple SaaS. You might have also your own process and things like that. So you have to kind of take this view of like the weakest link, right? We talk a lot about that in security. What is your weakest link? Can someone use as a stepping stone, right? Doing lateral movement to other things. So I think that's a fairly common thing. So fortunately, if you use any kind of workspace like Google G Suite or others, you have control to forbid the sharing of documents to other devices. Mm-hmm. And that may want to restrict the, the So device themselves, right? Or the account you share with outside of your domain. So you're actually trying to avoid this kind of sharing with accounts who might not have 2SV, right? You might have 2SV for your account on your company, but not for your personal account.
Not for the personal one.
Yeah.
And I guess this kind of gives us a roadmap. I don't want to give an attacker a roadmap too much, but if you are a top-tier attacker with a lot of time and money and resources, and you have to bypass a well-implemented MFA, You would probably go and look at some of the things you talked about, like either account recovery or physical attack, or you're going to attack kind of a human process presumably around this. Like maybe it's a physical token issuing process can be attacked or something, right? That's roughly what I'm thinking maybe with my attacker hat on.
You would, right? I think if you push to the extreme, and we saw that with recent ransomware attack, you can also target the supply chain, right? There was a bunch of companies who were victim of ransomware, not because their stuff were compromised, but because some of their providers were compromised, and then it was used to deliver a ransomware payload, right, as an update process. There's a lot of companies you rely on for your— and a lot of hardware you buy. So your supply chain security is kind of a big issue, right? Again, that's not phishing anymore, right? We're talking something very, very different here. Yeah, of course, of course.
Yes.
If someone else down your supply chain got phished, and they get tricked into installing, or I don't know, like tech support scam or something like that, and they install malware, then it was propagated down the supply chain, and ultimately you are a victim of phishing by 5 degrees of separation.
Yes, yes, yes, that's right. Yeah.
The challenge of sharing and not sharing documents, we dealt with that at one company I worked at by just having 2 separate email systems. There was an email system that could only send emails to itself, and that's where all of the company business was done unless you were a salesperson.
This is a bit pushing it though in modern day and age, right?
Yeah.
Can you really maintain Lotus Notes for that long?
No, it was 2 different workspace domains actually.
Okay.
Yeah. Interesting.
You could, right? And I think the military do that, right? They have NIPRNET, right? Which is this exact idea of you have a classified network and an unclassified network.
But then again, I'll give you one hint where the founders were working before they came to start that company.
It does, but I think those are very expensive, right? We're back to what Kurt said.
Yes.
And process— procedurally expensive, not just money expensive. It was really expensive.
to explain it to new hires. And eventually the system broke down when the company got too big and we gave up and had one email system.
For most of the people, I think, who are listening to the podcast, I think the simpler answer is security keys and modern, you know, like WebAuthn would be perfectly appropriate. And even turning that on will give you protection against most of the common threats.
On that topic of this is good enough for most people, what can we realistically do to help juice the numbers on multifactor or 2-factor and WebAuthn? WebAuthn and security keys in particular? How do we help?
Elliot mentioned that we did a recent study with politicians and political campaigns. And I think actually understanding their pain points that they experience is really indicative of what the rest of the industry is going through as well. There's a lot of barriers to adoption now to even just any form of MFA. You know, you have inconsistent terminology. So when I say, oh, I have MFA, does that mean SMS? Does it mean security key? And then when you try to encourage people to adopt stronger factors, they're like, but I have 2FA already. I use SMS. To people who are not in the security space, they feel like they've already done everything you asked them. Why are you coming back for more?
Yeah.
I think there's other challenges related to like, how do you enroll new accounts? You know, that differs from product to product, from platform to platform. There's a notion of shared accounts. Like, what do I do when I'm working with somebody, we both need access, and the provider only allows one phone or one key to be associated with that account. Or you have a transient account with multiple owners over time where you don't want to lose access because, let's say it's your marketing person that handles the press account or something, that person may change. Then all of a sudden you're locked out of that account moving forward. I think there's lots of friction that's added there. And then there's also just perceptions around value around an account. Like, well, I'll do it for my workspace account, but I'm not going to do it for these entertainment ones or maybe my personal email because, you know, what's the threat there? Even though those are sometimes stepping stone attacks to getting access, as Ellie mentioned. I think a lot of the challenges aren't around the technology of like making security keys more secure. Like we're actually— they do everything that they're supposed to do. It's just in terms of how do we reduce that friction across all these different services with all these competing messages. And of course, all the different security advice we're giving people, how do security keys weigh against that? Yeah.
This is probably— we have a question about value versus burden, which we kind of wanted to get to. But since you guys are touching on this topic now, I guess it's like working at Google, I don't really feel the burden, but I definitely see the value given the disappearance of phishing attacks. But what kind of discussions you've seen people have during the research maybe about this whole burden, friction versus value of MFA, of well-built MFA, not just MFA?
There are 2 different things, right? If you take the enterprise view of it, the value is set by the company. There are some companies like Google which will put a premium on security and say, no matter what, we should not get hacked. Some startups, some other companies have a different idea of what is a priority and would not put the same premium value to security because it's very, very hard to measure. And, you know, I've talked to many CISOs. Mm-hmm. In the past about security, and they're like, how do I justify my job? How do I justify investing millions of dollars into something that no one can see? It's a cost center, right? Many companies view security as a cost center, not as a productivity center, right? There is a moneymaker, the guy who sells the product, and there is everyone else which is taking money out of the profit. And security fell into it and they're like, well, but nothing happened. So why am I buying a new firewall? Why am I buying a new AV? Why do I need to buy security key and I need to buy 2 of those for each of my employees? And you know why, now it's remote, so I have to ship them. Why am I doing all of this? The beauty of enterprise in a way is there are regulations, right? You are supposed to do phishing training and things like that. And also there is a fewer number of people to convince. If you talk about the broader, more complicated part, which is end users, that is harder because they're like, That seems to work. I'm fine. That's good enough. I'm watching YouTube. I'm happy.
We have a data point from a study we did where we actually looked at people who had their account compromised, and this is for consumer users. How many went on to turn 2FA after the fact? So you've had a negative experience. It was only 3% of users.
3?
3%.
3?
Yeah, 3% of the people who had their account compromised went on to turn 2-factor authentication on. The answer is you probably feel like, well, What does it matter if it happens again? It didn't affect me too badly, or just the friction is too high. I don't want to do this. Those are serious barriers.
We have further data points on that. One is we ran a study of, do you know about phishing? Because a lot of the things we do, we show banners to people, even in Gmail or on Google Chrome, and say, hey, you're going to get phished or you're going to get tricked into it. Half of the people don't know about phishing. And we're like, would you like to know more? And the answer is no. No, it's like, yeah, I don't know about it, but that's fine. I don't want to know about it. You know, there is no curiosity about it. I think people just view that as an annoyance rather than anything else. It's a very big problem. And the other study was done by another company. They had this very interesting study, which is like, okay, if you compromise, we're going to put your account in read-only. And they had a bunch of photos, right? I'm not going to tell the name of the company, but then people were like, oh, that's fine. I'm going to use it on read-only and I'm going to browsing and I stop interacting. And it was disastrous for their business model because the idea was like people should have engagement. They're like, no, I'm fine. I'm just going to lurk here. And, you know, I have access to everything. I'm just going to read. I'm fine. And then they do nothing. They knew their accounts were compromised, were logged on. And, you know, they said, oh, we're going to have this gradual idea of still letting you see things because that's not that bad. And then the answer is like, if you ever do that, then they will do nothing.
Wow.
That's how hard it is.
So this cyber stuff doesn't really matter all that much for a pretty broad chunk of the— well, in this case, consumers, not companies, but actually some companies as well, it seems like.
It depends where you put your premium, right? If you have a lot of intellectual property and you are very concerned for your intellectual property to be stolen, then yes, you'll probably put a premium of what happens if it's stolen. If, as Kurt said, most companies do a great job at mitigating the risk, even if you get Compromise, right? Like your bank will revert bank transfer, you can cancel credit card charge very easily. So people are like, yeah, I got compromised, it was mildly painful, I'm done with it, good. And then move on, right? And I think that that is the— in a way, you could say, because the industry does such a good job, then people don't feel they should contribute to it. And they just say, like, let them deal with it. And then I don't care.
Wow.
Maybe feeling safe enough is probably where they are at Interesting.
Do we have numbers we can share about multi-factor adoption among consumers? Do we have industry benchmarks we can share?
I don't think we have any benchmarks at this moment. We're more focused on identifying what are the key pain points and kind of working to address those. That's really what we highlighted with political campaigns, which is really indicative of also what probably a lot of small businesses feel too, like competing priorities. You don't have an established security culture yet, so how do you go about doing that? How do you weigh these things? That's where a lot of our research is at the moment.
I do think also that those numbers are very, very hard to get because the future is probably having kind of a blended authentication where everything works together. That's, you know, FIDO2 security key where now Windows Hello is compatible with WebAuthn. So you authenticate on your Windows or on your Mac, and then the same fingerprint reader you use will also authenticate you on the web. So for the user, it feels like a single sign-on. This is not technically a single sign-on, but this is the same mechanism. And so because every 2-factor authentication authentication is merging through the use of crypto, which is awesome because the user don't just have to click. I think we won't have numbers moving forward. Like every modern operating system, every phone as a security key, every Windows Hello, Mac authentication, Authy ID, I think that's the name of it. And every time you click on it, it will be that, right? So they'll be like, oh, I'm on the website, they want to know who I am, I'm clicking. And then the same data as when I log. And so the experience is blending. Which is really good because really all we can ask from a user is click. That's, I think, the maximum we can do. And then, you know, the computer do a ton of things. It's look at the fingerprint and then, or look at the camera or whatever you want, and then decide if it's really the user, do authentication, do the crypto, and then the user don't see any of it and it is fine. We have to admit that for end user and for most enterprise and most cloud user, we want single click for the user, nothing apparent. You know, that's all these quests of passwordless and saying, well, you're like, it will have to be harder on the hardware, harder on the provider. hardware on the admin. But at the end of the day, I mean, it's a positive message, which is the technology is there. We all have to adopt it. It's a little bit of a painful transition to this password to crypto-based authentication. And there is a lot of things to figure out, but I think it's going to get better. And I think we cannot get the user to do more. We have to, as a community, say, okay, fine. We need to give up on the user learning and we need to give up on the user investing more security because they won't. You can force them through certification and require it for the job, but ultimately they will be like, okay, I'm doing it for my work account and forget my pay. And then we're not moving them. So standardizing around stronger 2MFA, which is FIDO2, right? The security key Windows Hello is the best thing we can do. And having a unified thing. And every time we see a marketing person say, oh, I'm going to call security key something else. And we saw that quite a bit in the last few years. We are crying because they are diluting the message of like, No, security key is a specific thing, and then you're confusing people, right? So we would have to do kind of an industry effort to be talking the same language to the user and say, this is what you need, this is how it works. You should see one UI on Chrome, Firefox, Edge, and so forth, which is your default UI. This is what you need to trust. Trust this thing like you trust HTTPS. So you have one indicator for encryption and one for authentication, and that's all you should ever see. And if it's not that, don't do it. Just don't do it. Don't do it. That's not what you're expecting. And if we get to that level of universality, like HTTPS, I think MFA is in a great spot, right? So, and then maybe Anton, we can have champagne. Maybe we can that day say, yeah.
Then we can do it.
You're right. I think you win. The magic is there, but somebody needs to like wave a wand in the air and then magic happens. But apparently people are like, what do you mean wave a wand? That's too much work. I want magic. I don't know. My analogies suck. Fine.
No, no, I think it's a good analogy. It's a case of the magic being here but not widely distributed yet.
Yeah.
I want to move towards wrapping up and ask Kurt and Elie, do you have something for the audience to go read to learn more? And do you have a specific pro tip to help users improve security outcomes? I'm guessing it's going to be use hardware multifactor, but if it's something other than that, that'll be exciting too.
The benefit of being on a research team is we have too much to read. We've written multiple papers on— if you have questions about what is the relative value of SMS versus on-device authentication or security keys, we can actually give you concrete numbers about how does that fare versus data breaches where people are doing password guessing, how does it fare versus phishing, how does it fare versus targeted attackers.
Hmm.
And so we have concrete metrics there. If you're interested in kind of our investigations we did into different higher outfits or underground markets related to data breaches and things, we also have written extensively I think the important takeaway here is, yes, while we would love everybody to use security keys, really adopting any form of multifactor authentication is going to block over 100% of the bots that we see that attack Google every day. It's going to block over 90% of the phishing attacks that we see using, say, off-the-shelf kits. And even for targeted attacks, it works in, say, 70% of cases. Even when you have something like SMS, it'll block 70% of those attacks.
Wow.
The answer is yes, use multi-factor authentication. It has really strong positive security outcomes and usability trade-offs. They exist but are manageable.
That sounded like kind of an optimistic note to end on.
Are we allowed to finish on an optimistic note? It's security. Okay, fine. Yeah, good, good.
I have one to add.
Oh no, Elie wants to add something. We don't need to end on a good note.
One last thing, and I'm going to be super self-serving, but With the help of the team, we've been writing for many, many years and put our research open source, open to people, which is our PDF, but also our slides, and you can download them. And I did put them on my website. So you have all our papers that Kurt mentioned, and we try to write long blog posts to explain a little bit our reasoning and give a behind the scenes. I know that a lot of people like that. You'll find all the links we describe into my website, and we don't have a good website at Google to show all of these things. So here is one link where you can find all the things we discuss. I want to attract attention. We had a great paper with Kurt and others at IMC last year where we look at the factors that affect people who are mostly phished on Gmail. So we took all Gmail, we took billions and billions of phishing emails, and we look at what is the factor affecting your posture and things like that. We just put it, I just put it online. And we have a lot of those kind of things. So if you want to just follow along what we do and you want to keep in touch with us, that's probably For now, the place we hope to do more, you know, on the Google blog and so forth, and we always post on the Google blog. So that's also a good resource, right? The security blog is where we post as well, to be clear. But if you want the paper and you want to search for them and have like a little bit of a longer write-up or mailing list, then we do that too. And again, we're really happy to talk to people. We're always happy to go and talk about security with various people because we're researchers, right? We are a little bit different. type of breed at Google, I would say, that engage more with academia and industry. We go to conferences and so forth. So if people have an interest to reach out to us, by all means, we're always happy to discuss more of those points.
Amazing. So a second optimistic note, please reach out and bother Elie and Kurt, and they will be happy to share more.
Yes, please. I don't know if Kurt signed up for that, but Elie signed up for that. I don't know if Kurt would sign up for that. Do you sign up for that, Kurt?
Kurt's making a bit of a face. I don't think Kurt signed up to be bothered, but Elie did. So listeners, Bother Eli, not Kurt. Thank you both so much for joining us today.
Thank you so much.
Thank you.
And now we are at time. Thank you very much for listening, and of course, for subscribing. You can find this podcast at Google Podcasts, Apple Podcasts, Spotify, or wherever else you get your podcasts. Also, you can find us at our website, cloud.withgoogle.com/cloudsecurity/podcast. Please subscribe so that you don't miss episodes. You can follow us on Twitter as well, twitter.com/cloudsecpodcast. And of course, your hosts are also on Twitter. Anton_Chuvakin and _TimPeacock. Tweet at us, email us, argue with us, and if you like or hate what we hear, we can invite you to the next episode. See you on the next Cloud Security Podcast episode.
Security.
More from Anton


EP289 Software Engineering vs. Software Craft: How Google Scalably Eliminates Classes of Vulnerabilities


EP288 CISO Tested, Board Approved: Cloud Resilience with General Mills CISO Noah Korba


EP287: Creating Trust at Global Scale with Local AI: Reken-ing with Shuman Ghosemajumder


EP286 Building an AI-pilled, solo vibe-coded, Clickhouse-based SIEM with Dan Lussier


EP285 Scaling Lessons from Leading the NSA to Defending the World with Morgan Adamski


EP284 Closest Alligator to the Canoe: How Transforming SOC Became P0 for Lloyds Bank


EP283: How Google Cloud CISO Chris Betz Uses LLMs to Defend Billions of Users from Vulnerablities


EP282: Debating Coupled or Decoupled SIEM with Alex Hurtado and Christopher Witter


EP280 Hyperscaling Cloud Security: Wiz Joins the Cloud Security Podcast by Google