Ramesh Ramani: [00:00:00] We had a single bug bounty report, single with 80 plus vulnerabilities, 80, eight zero

Ashish Rajan: Could just be an email someone sends over, say, "By the way, I just own your domain. Pay me whatever."

Ramesh Ramani: No one owns this. DNS is one of those things where it's either no one's problem, or when stuff breaks, it's everyone's problem.

Ramesh Ramani: And guess what? We found 400 such issues, 400. My colleague and I, we spent months trying to convince different stakeholders in the organization. It was very difficult. By 2024, our bug bounty program for DNS takeovers went to almost zero.

Ashish Rajan: If this was happening today and someone starting this journey today, would you advise them differently?

Ashish Rajan: What does it take to reduce your domain takeover across cloud, on premise to absolute zero? Or at least nearly zero. I had a great conversation with Ramesh Ramani. He is a staff security engineer at Block, and we spoke about how their journey of starting with almost eighty plus domain takeover [00:01:00] problems are to almost zero domain takeover issues today.

Ashish Rajan: Now, the journey was obviously not a short one, took a few years, but Ramesh got into some of the components that were involved, both technical, both people's related, and process related. There is a caveat, you could not solve domain takeover of any kind in just one hour, but at least you get to have an idea of where you can start and what some components could be that you can leverage to at least tackle the problem to be comfortable.

Ashish Rajan: And we get into all of that in this conversation with Ramesh on where they started, what were some of the harder parts, what are easier parts to start with if you have the foundational pieces already covered, and what are some of the ways to tackle this at scale in a stateless way without having to rely on extra infrastructure that you manage.

Ashish Rajan: All that and a lot more in this episode of "Cloud Security Podcast." As always, if you are here for a second or third time and have been listening or watching an episode of the "Cloud Security Podcast" for a long time, I would really appreciate if you take a quick second, hit the subscribe or follow button, whichever podcast platform you listen or watch this [00:02:00]on.

Ashish Rajan: We are on Apple, Spotify, YouTube, LinkedIn, and anywhere else you listen or watch your podcast from. Oh, by the way, quickly, my book, "AI Security Engineering," is out on Amazon for purchase. It's called "AI Security Engineering." It is designed for anyone who's trying to build secure AI systems in the cloud, on premise, and it's based on all the strategic work that I've done with the Fortune five hundred, Global two thousand companies, and the conversations we've had on our sister podcast, "AI Security Podcast," and "Cloud Security Podcast" as well.

Ashish Rajan: It has got some Anthropic and a lot more other companies who have supported the work that I've done. Uh, it's currently sitting at number one on the Amazon US store. Really appreciate support from everyone who's helped get the word out of the book, and I'm looking forward to all the reviews and feedback that people share about the book, either on Amazon or to me directly.

Ashish Rajan: I look forward to hearing your feedback when I see you in person at one of the cybersecurity conference like RSA BlackHat or the community meetings we organize across AI Security Lab and Tech Riot. I hope to talk to you soon about my book, and I'll see you soon. [00:03:00] Peace. Hello, and welcome to another episode of "Cloud Security Podcast."

Ashish Rajan: I've got Ramesh with me. Hey man, thanks for coming on the show.

Ramesh Ramani: Oh, thank you for having me again. You know, I had a great conversation last time, and lovely to be back.

Ashish Rajan: I'm glad to have you back as well. We have another topic, but maybe before we get into the topic, if you just wanna share a bit about yourself and your professional background.

Ramesh Ramani: Yeah, absolutely. You know, I've been in the tech for twenty years now, this year.

Ashish Rajan: Oh, wow.

Ramesh Ramani: Yeah, and the first ten years was primarily, a data center, you know, network security and, you know, instances and, uh, we're talking about like hardware servers and stuff like that, right? So that's what I dealt with the first ten years of my career.

Ramesh Ramani: And the last ten years has been primarily cloud security. Yeah. And, you know, I've been with Block for the last six years now, and, uh, I'd like to talk about a few things that we did, uh, that I've done since we spoke last. Um- Yeah ... I had an opportunity to, and the honor to talk at AWS re:Invent about, you know, how, what Block did in the last five years, you know, as our network security journey evolved.

Ramesh Ramani: I had, uh, the honor of actually speaking at f- [00:04:00] you know, one of my favorite, uh, cloud security conferences, which is fwd:cloudsec, about how we, you know, we did-- we sort of solved for the domain takeover problem at scale. We eliminated that as an entire class of attacks. And, yeah, and I found out that, uh, you know, earlier this year, you know, the podcast we had last time, for the unified egress access, uh- Yeah

Ramesh Ramani: you know, identity-based authorization solution, we went GA with it

Ashish Rajan: oh, wow. Congratulations. That's pretty awesome. Well- Thank you ... you, you're already GA at the domain takeover one, so I think that's kind of like uh- Yeah ... this is probably just opening it up for the world to understand what you guys have done.

Ashish Rajan: 'Cause I think it's a good place to start. So I 100% agree, fwd:cloudsec is a good community, and glad you guys had the conference talk there. So I'll, I'll definitely put the l- talk in the show notes for people to get more information. But just to set the scene for people, maybe if you start with what is domain takeover, and why was that a problem for you guys at Block?

Ashish Rajan: And just to kind of reel that back into the past a bit as to where did this whole thing start?

Ramesh Ramani: Yeah, absolutely. So the first time I heard about [00:05:00]domain takeover was in 2020. I think I was watching one of, you know, a security researcher. Gosh, I wish I'd, I'd you know, was able to recall his name. But they actually went, you know...

Ramesh Ramani: I had a look at their video, and I was like, "This DNS takeover is such a big," you know, like, you know, it was a mind-blowing issue back then. I was like, gosh, it's crazy how in the cloud you can, you know, you can very easily, you know, now take over domains, right? Not just in the cloud, but anywhere. So any sort of third-party providers essentially, right?

Ramesh Ramani: Uh, it was a mind-blowing thing for me when I, when I first had a look at it, and then I started digging into it within my own organization. And 2020 is when Block started moving slowly into the cloud. 2019, we were still more or less a data center, you know, uh, driven environment, you know, sort of hybrid, you know, moving towards the cloud.

Ramesh Ramani: And I realized that, you know, as we move towards the cloud, this problem is only going to get bigger. Because what's gonna [00:06:00] happen is that when we were in the data center world- You know, we had these different registrars, and now you have all of these different, uh, internal DNS providers that we have to deal with.

Ramesh Ramani: And exactly what happens over here is that we started realizing that a lot of users started using the cloud, and now because they started using the cloud, they were using it... It was a Wild West, right? Yeah. So what would happen is that someone would spin up an account, they would go ahead and create a zone.

Ramesh Ramani: They would create a public registrar, would say AWS, uh, Route 53, and voila. You know, they would, you know, they would go on with this now, right? Like- Yeah ... create a hosted zone and then create, like, these multiple subdomains and then, you know, point it to your EC2 instance, point it to your load balancer, point it to whatever, right?

Ramesh Ramani: Like point it to your Heroku, point it to your Vercel, whatever application, right? And now, you're good to go.

Ashish Rajan: Yeah.

Ramesh Ramani: Oh man, this started becoming a problem for us. [00:07:00]I'll tell you a story. So in 2021, we had a single bug bounty report, single, with 80 plus vulnerabilities. 80, 8-0. Oh, one

Ashish Rajan: report with 80 vulnerabilities.

Ramesh Ramani: One report with 8-0 vulnerabilities. Out of these, there were cl- you know, like clo-- half of these were production destinations, uh- Wow ... production domains. Oh my god, this was, this was an eye-opener for us. And we realized that, you know, this is something that we need to do about. We had started working on this, but then we realized the scope and the scale of this problem when we got this one report.

Ramesh Ramani: Yeah. And we're now moving into the cloud. This is 2021, when we were like, you know, aggressively moving into the cloud, where we wanted to move everything off our data centers and into the cloud by 2022. Imagine now everything being moved to the cloud, and now everyone going bonkers and creating resources in the cloud.

Ramesh Ramani: Imagine the kind of problem that we were going to face, right?

Ashish Rajan: Wow.

Ramesh Ramani: So me, I was a part of the network security team back then, or there wasn't a concept of network security, it was just platform [00:08:00]security back then. And just me alone trying to, like, work with the vulnerability management team to try and fix this was insane because we now had to find out who manages those domains.

Ramesh Ramani: Oh God, that's like the worst thing that you can try and, try to, uh, wrangle for. Yeah, and we had a tough time. It took us, like, a long time to, like, sort of sort that issue because- A lot of these destinations were truly dangling. And what that means is not just from a DNS standpoint, dangling from an attribution standpoint.

Ramesh Ramani: No one owns this. DNS is one of those things where it's either no one's problem or when stuff breaks, it's everyone's problem, right?

Ashish Rajan: Yeah.

Ramesh Ramani: So, so that was the issue essentially that we were trying to tackle at scale.

Ashish Rajan: Right. Okay. 'Cause I think what-- I'm almost curious 'cause obviously 2021 world was very different.

Ashish Rajan: AI was not even there back then, and I think you mentioned people may be dropping domains into Vercel or any of the [00:09:00] Y-Core apps as well. Do you feel the DNS ecosystem has actually gotten better? 'Cause I, I I'll set the context as well. I want this to be almost a reflective, obviously, of what you guys have done, which is amazing.

Ashish Rajan: But I also wanna paint a picture for, through our conversation for if this was happening today and someone starting this co- journey today, would you advise them differently? So I'm curious as to, has the DNS market now gotten better now that we have Vercel and all the other ones who are basically allowing anyone to have a DNS, or is it actually getting More...

Ashish Rajan: Actually, I'll let you answer before I answer it myself, I guess.

Ramesh Ramani: Yeah. I wish I could tell you that, Ashish, our industry is getting better at this. Yeah. Uh, it's sadly not, right? It's not the third party's problem, honestly. Vercel or whatev- Hugging Face, which is in the news now, right? Yeah. Uh, Vercel, Hugging Face, like all of these different applications, you know, like third parties, right?

Ashish Rajan: Yeah.

Ramesh Ramani: Not just third parties which help you create [00:10:00]applications, but just any third party that you want to integrate with. Heroku, for example, right? You know, GitHub, Lovable, doesn't matter. Eventually, whenever you want to like integrate with a third party's, provider, DNS automatically comes into the picture here.

Ramesh Ramani: Because, for example, like if you were to consider Vercel or if you were to consider Hugging Face, an application owner can now go ahead and very easily create these applications on these websites.

Ashish Rajan: Yeah.

Ramesh Ramani: Now, once you've created the applications on these websites, how do you communicate to them? You want to make sure that you have a DNS where your application is able to like query that particular domain, and that domain should, you know, belong, you know, within your organization.

Ramesh Ramani: Because your organization now has certain rules to say that if you create an application, it should belong within our own registrar, it should belong to our own domain, and certificates as well, right? Yeah. If you want to communicate with another [00:11:00] destination, you want to make sure that the certificates are trusted as well, because now you have CORS and you have cookies, you know, which provides auth based on DNS and these certificates, right?

Ramesh Ramani: So having said that, what's happening over here is that this is a common problem across these applications. These applica- You cannot solve for the DNS takeover problem at the source level, at the third party level. It's hard to solve for because they're just providing you an application. You, as a user, go ahead and create access towards that application using your own custom DNS.

Ramesh Ramani: Yeah. For example, you create a Vercel app. You go ahead and, let's say I work at Block, I go ahead and create test.block.vercel.com as an example, right?

Ashish Rajan: Yeah.

Ramesh Ramani: Now, the test.block is a zone that Block owns, right? But the CNAME now points to a Vercel app, for example, right? Like, it could be test.block.whatever.com.

Ramesh Ramani: Yeah. And the CNAME [00:12:00] for that points to Vercel's domain. Yeah. Whatever the application that you have created. Vercel's done nothing wrong here.

Ashish Rajan: Yeah.

Ramesh Ramani: Like, it's completely on us, right?

Ashish Rajan: Yeah.

Ramesh Ramani: We set a CNAME pointing towards Vercel's domain, or say Hugging Face's domain. Which is completely different from them creating a domain for us, which they cannot because- Yeah

Ramesh Ramani: we own the domain. So to answer your question, sadly it doesn't, because the onus is on the organization that's integrating with it. If the organization that is integrating with these third-party applications does not do a good job of managing our own des- our own domains, it doesn't matter. The external third parties can't do much about it.

Ramesh Ramani: So it's very much a problem of the company that's integrating with these third parties and not the third parties themselves. DNS is a problem of the source entity and [00:13:00] not the third party entity. So sadly, there is no technology which prevents y- which helps you to sort of put these preventive controls at a third party level.

Ramesh Ramani: It's more or less what you need to do at the source here, what, you know, that the company is trying to integrate with.

Ashish Rajan: And I guess to your point, there's M&A as well, so it just doesn't need to be a VSL or any other third party. It could just be the fact that you acquired a company, which I think is pretty common these days as well.

Ramesh Ramani: Yeah, absolutely. That, you know, as you go ahead and, you know, uh, get these different organizations, you know, acquisitions, right? And let me give you another story. At Block, you know, what happened is that several years ago, I can't even recall when, what happened is that Block went ahead and acquired a company.

Ramesh Ramani: Now, that company's DNS now automatically becomes our problem, right? Yeah. Any... so you know, when you acquire a company, their problems become your problems now. Yeah. So their DNS problem became [00:14:00] our problem now, right? So what happened is that to a year and a half later, Block, assumed all of their name servers.

Ramesh Ramani: Now all of their domains are ours. Fast-forward a year and a half later, Block sold that organization to another company. Now that's fine. What we did is that we went ahead and transferred, you know, the zone records to the other company. Yeah. But here's something that we missed. You know, the Route 53 records associated with those destinations still pointed to accounts that we owned

Ashish Rajan: Oh.

Ramesh Ramani: So their, even though their domains were now transferred over, their name server records were still pointing to ours, given to our systems. So when they were getting these bug bounty records, it was, it was coming to us. Yeah. Because we were the ones who have to fix this. So-

Ashish Rajan: Yeah ...

Ramesh Ramani: you see, you, you see what I mean?

Ramesh Ramani: So-

Ashish Rajan: Yeah.

Ramesh Ramani: Given up the- ... DNS is either someone's, either, either no one's problem or it [00:15:00] becomes this really fuzzy place where you don't know who manages this. So-

Ashish Rajan: Yeah ...

Ramesh Ramani: yeah, it was painful for us. And it's not a very good way that MNAs, you know, hel- MNAs just makes the situation worse, actually.

Ashish Rajan: I think now I feel like, uh, we've given co- a lot of context to the audience about how the DNS problem is not just as simple as, "Hey, I understand domain takeover," and, "What's my CNAME or my zones?"

Ashish Rajan: or whatever someone else takes over. And I guess- Maybe to even simplify it even more, you touched on there something which is really interesting. Doesn't even need to be a bug bounty program as well. It could just be an email someone sends over, say, "By the way, I just own your domain. Pay me whatever."

Ashish Rajan: Uh, and you're like, "Oh." And so even if people think, oh, it's only part of a bug bounty program, uh, well, if you have a public domain, most likely someone would email you, find you on your name server, and just email you, "Hey, by the way, I think I can take away your domain." But maybe let's also talk about how does one approach to solve this?

Ashish Rajan: What [00:16:00] worked and what did not work? And was a f- was it like a one-shot pony in terms of you guys went straight in 2021, 2022, whenever, whenever you started, and basically were able to get to the bottom of it straight away? Sounds like you knew what the problem was. What was the journey like to go from the beginning to where you guys are today, where you're comfortable to talk about it publicly?

Ramesh Ramani: Yeah, absolutely. And this is something that I alluded to when I spoke at, uh, fwd:cloudsec as well, which is, you know, the... As I said, you know, the biggest-- You know, when we started, yes, you're right. I had an idea as to what we needed to do, right? This was a problem that was really close to me because I love DNS and, and all the problems that come along with it.

Ramesh Ramani: Um, I thought to myself, yeah, we need to do something about this, and the best way to sort of tackle this problem is by enumerating through our DNS, you know, uh, configurations and our DNS records. Mm. Which was the simplest way to start, to be honest. We had internal tools that Block had created, which allowed [00:17:00] us to actually find all the internal, you know, DNS, uh, records, for, you know, all of these domains that we had, which was great.

Ramesh Ramani: And this was a good point for me to start, because if you want to understand the hygiene of your DNS, just, you know, navigate through all the endpoints and all the DNS records that you have and see, you know, what the situation is like, and that's where I started. I used this tool and then wrote up several scripts, which will iterate through every single domain within our system and try and find out a domain record and try and find out if they're susceptible for takeover.

Ramesh Ramani: That part is not the easy part, to see if it's susceptible to takeover. Why? A couple of reasons. You have different types of takeovers here. You have hosted zone takeovers, which are probably the most impactful. Hosted zone take-takeovers are probably the most impactful because assume you have something like [00:18:00] You know, test dot, you know, block dot com or whatever, right?

Ramesh Ramani: Now assume block.com or whatever, ramesh.com is a hosted zone that is created on Route 53, and it's a public registrar or whatever. Now the Route 53 records pointing to that, let us say, are orphaned, and someone comes ahead and, you know, captures the route, you know, the name servers for ramesh.com. Now what happens is that it's a hosted zone, right?

Ramesh Ramani: So every single subdomain that precedes it is compromised. So test.ramesh.com, you know, like, uh, test1.test.ramesh.com, doesn't matter how many subdomains far you can go in, every single domain is compromised. Now, the problem with this is that, you know, like let us say you have like an application like Hugging Face.

Ramesh Ramani: Let us say now a user wants to communicate with that, and now it has like, say, callback auth, you know, authorization URLs [00:19:00]that it's sending to say, callback.ramesh.com as an example. Those tokens go to the attacker, right? Yeah. Who owns that particular domain right now. The cookies go through, the callback URL goes through, so now they get tokens.

Ramesh Ramani: And for example, let us say, uh, there are users who go ahead and create, uh, these applications, and now the cookies get redirected to anything, you know, as that is, as a part of that domain, ramesh.com. So any sort of subdomain that is created, the cookies may forward, you know, the auth tokens to ramesh.com or the owner of .ramesh.com, right?

Ramesh Ramani: So the entire hosted zone is compromised. Mm-hmm. This is the largest impact. Then comes things like MX takeovers or, you know, mail for mail, right? You have text, you know, based on text records, and now you have like CNAME takeovers. You have elastic IP takeovers or IP takeovers in general. The reason I'm actually going through all of these is 'cause as a security engineer, I needed to [00:20:00] understand what matters most to.

Ramesh Ramani: I realized that I needed to work from what's most impactful going to what's least impactful. Business reasons, and of course, you know, you want to be able to like justify, you know, uh, the cost towards what you're building. So hosted zone takeovers were actually the most important thing that I started to, uh, work on.

Ramesh Ramani: Uh, going back to the initial thing, what I had to do is that enumerate through all of these destinations, find out what was susceptible for hosted zone takeovers And from there, you know, start building out a list. And do you know what? We found 400 such issues, 400. And all of these were internal, uh, you know, internally problematic.

Ramesh Ramani: And, you know, we went about cl- you know, I had to start cleaning this up. Cleaning up all of this is a problem as well. Why? Because I had to understand who owns these resources. Someone created these, and they're no longer a part of the organization. That [00:21:00] account belongs to no one right now. AWS records belong to no one right now.

Ramesh Ramani: Am I okay to delete this hosted zone record? What if there's a production application which is using a subdomain related to this hosted zone, which is in some other account?

Ashish Rajan: Yeah.

Ashish Rajan: That's... Yeah.

Ramesh Ramani: This was a problem. It took me months to work with the vulnerability management team to even do a cleanup.

Ramesh Ramani: This is the size of the problem. Uh-

Ashish Rajan: By... And this is, by the way, just the internal ones. We haven't spoken about the, the domain registrar ones or the external ones which may be somewhere else.

Ramesh Ramani: Yeah, absolutely, right? This is just cleanup.

Ashish Rajan: Yeah.

Ramesh Ramani: We're talking about cleanup. Now, if

Ashish Rajan: you- So out of...

Ashish Rajan: 'Cause this, the funny thing is in what you were saying as well, a lot of people would hear about DNS takeover and go, "Well, that sounds easy." Tech- technically, yes, it's easy, but the risk you're taking by just deleting the hosted zone, you're like, "Okay, what's the ripple effect that I'm going to create here for this revenue?"

Ashish Rajan: I may as well

Ramesh Ramani: resign and leave at that point of time.

Ashish Rajan: Possibly. Or you should be ready at that point in time that y- there's a potential [00:22:00] red slip coming your way because you've basically stopped production and made people, uh, made the company lose some revenue. Yeah. But I'm, I'm also curious, the reason I bring that up is I wonder if people also think that, "Hey, why not just do automation of ownership, automation of removal, or automation of, uh, something that is older than, I don't know, six months deleted?"

Ashish Rajan: Or was there some thought given to automation for all of this in the beginning?

Ramesh Ramani: No one auto- No, no one does any sort of cleanup and automation for DNS. What are you talking about? Um, no, sorry, uh, jokes aside. We did think about it, right? But, cleanup with DNS is not simple for the same reasons that I just mentioned right now.

Ramesh Ramani: Attribution is a big problem in the industry for DNS.

Ashish Rajan: Mm-hmm.

Ramesh Ramani: How do you attribute a domain to an, uh, you know, to an application, right? Uh, or it's, it's hard because you start to wonder what is an application, right? Then how, you know, uh-

Ashish Rajan: And who, who's the owner for this as well? Even that's a big question to [00:23:00] ask 'cause- Exactly

Ashish Rajan: the owner left, like, six months ago.

Ramesh Ramani: Exactly, right? And this also comes down to another thing, registrars. Registrars is a big issue here as well. And the reason I bring this up is because- What ex- Sorry, what do you mean

Ashish Rajan: by registrar? So people may not know what-

Ramesh Ramani: Sure ... a registrar is. Like, how do you describe it?

Ramesh Ramani: Absolutely. So registrars are these, uh, you know, companies where they tell you that you are authoritative for a domain that you purchase from them.

Ashish Rajan: Yeah.

Ramesh Ramani: You can now purchase, you know, like, these domains which are, uh, from these large organizations like GoDaddy, you know, Cloudflare, uh, you know, AWS, uh, and stuff like that.

Ramesh Ramani: Yeah. You can go to them and you can tell them, "Hey, I want a domain." And they will check with you, and they will first check to see if that domain is registered already globally or not, right? Yeah. If it's registered globally, obviously cannot use that name. However, if it's not been registered, then you can go ahead and use that name.

Ramesh Ramani: Uh, so at enterprise scale, organizations tend to reach out to-- You know, they have like [00:24:00] partnerships with these different registrars and, um, you know, the, you know, the legal team is m- generally involved with these registrars. I say legal because there's a lot of brand and reputation, uh, associated, you know, with domain name systems uh, right?

Ramesh Ramani: So legal is a big component, uh, you know, with registrars. So yes, uh, generally what happens is that, uh, because it's directly related to your branding and domains, you know, users generally have to go through legal, and from legal they will, you know, they will get access to a domain. is what we think is the right thing to do.

Ramesh Ramani: This does not always happen because- Yeah ... of the cloud. Cloud makes everything so simple, right? Now, all I can do is just go into AWS, just create a new domain. No, no one's gonna question me, right? I'll just go ahead and create a new domain. I will pay for it from my pocket. Yeah. Of course from the team's pocket, not my pocket.

Ashish Rajan: Yeah,

Ramesh Ramani: yeah, yeah. Uh, from, from the team's pocket, and, uh, I will create whatever [00:25:00] subdomain that I want, uh, you know, from that, right? That is the crux of the problem, essentially. So this is why I said registrars are the issue. Ah. If you don't have control over where these domains are being created-

Ashish Rajan: Yeah ...

Ramesh Ramani: then that becomes the bottleneck essentially.

Ramesh Ramani: Oh.

Ashish Rajan: Oh, interesting, 'cause here what you said say for whatever reason if I use the ramesh.com example of started, but I purchased that domain also from Amazon, and for whatever reason, if you are a h- 100 people company, Ashish suddenly decides, "Hey, by the way, I like ashish.ramesh.com." I can do, but I don't need to reach out to you or legal for get, uh, getting that started.

Ashish Rajan: I could kick it off myself. A

Ramesh Ramani: Terraform change away. I

Ashish Rajan: could go ahead. Yeah, yeah. And it's like, oh wait, 'cause it's already part, it's already a validated domain on Amazon- Yeah ... so it's gonna go, "Oh, well I know this." Yeah, yeah. Yeah. You own the, uh, subdomain. Please, please go ahead.

Ramesh Ramani: And furthermore, if you create this in an AWS account, Yeah

Ramesh Ramani: Route 53s is on at the account level, right? Yeah. If you create this at, at the [00:26:00] account, and if you own that account, you can do whatever for that account.

Ashish Rajan: Yeah.

Ramesh Ramani: Right? Yeah, yeah. So create whatever subdomain you want, point it to any sort of third party, doesn't matter, and integrate it with production, doesn't matter.

Ramesh Ramani: Yeah.

Ashish Rajan: Which is

Ramesh Ramani: why I said registrars. Yeah. Uh, registrar consolidation was one of the biggest challenges that we had. Right. Automation was not, uh, the challenge, but trying to build a policy in your organization to say that you cannot create DNS records willy-nilly anywhere you want. Okay. You need to have a policy.

Ashish Rajan: Yeah.

Ramesh Ramani: And I kid you not, Ashish, my colleague and I, we, we spent months trying to convince different stakeholders in the organization to bring a policy That no one can go ahead and create domains anywhere other than the registrars that we have allowlisted. No one else. It was very difficult because it was a political battle at that

Ashish Rajan: point.

Ashish Rajan: Yeah. But can you- And because- ... can you actually stop me from [00:27:00] doing that? Like as in, so when I go, when I'm going with this is that as soon as you mention it, I'm pretty sure like me, a lot of people are thinking, "Hey, what's the control to even realize?" 'Cause you can't control third party. Like you, I mean, you said Cloudflare earlier.

Ashish Rajan: Maybe Cloudflare is not in that approved registrar- Yes ... but I just go and go, Ashish or ramesh.com on Cloudflare. Would you be able to stop me from doing that?

Ramesh Ramani: Very good question. So the answer is no, sadly. However, because majority of the users within our, within our environment use You know, like just cloud environments, we're able to put policies in the cloud environments.

Ramesh Ramani: Oh, yeah. Uh, directly to say you cannot create this at, you know, the cloud level. Very simple, just put an SCP in, in AWS to make sure- Yeah ... that you cannot go ahead and, uh, you know, request creation of a, uh, you know, for- A domain, yeah ... you to create, register a, a domain with AWS- Yeah ... or with GCP. So at the cloud level it's easy to do.[00:28:00]

Ashish Rajan: Yeah.

Ramesh Ramani: Whereas now if you were to ask me can I do this at Cloudflare, yeah, sure, that, that problem exists, right? So that's where the next step comes in, which is

Ashish Rajan: automation.

Ramesh Ramani: Yeah. Yeah. Right. Right. Okay. So you stop the bleeding by making sure that you bring in a policy across the organization.

Ashish Rajan: Yeah.

Ramesh Ramani: Uh, which is by putting in a guardrail to ensure that no one can sort of go beyond that guardrail, right?

Ramesh Ramani: And that's what I mean- Yeah ... by SCPs and the cloud level. And second thing is putting this in your policy language, in general, the InfoSec policy language to say that, you know, you cannot build or you cannot request access to a domain if it is not from our approved registrars. And we name those registrars, and we provide, points of contact, et cetera.

Ramesh Ramani: You need to make this easier for your entire, you know, organization. Mm-hmm. It should be searchable that, hey, these are our allowlisted, registrars, and this is the paved path for it. So [00:29:00] stop the bleeding first by, you know, putting in policies, announcing this policy. Go ahead and let the entire organization know, uh, you know, through communication that you cannot use any other registrar going forward.

Ramesh Ramani: Starts with educa- it starts with guardrails, then education, and then finally automation. That is when the last automation step comes in that you alluded to a little earlier, right? Do you start with automation? No. We didn't start with automation. We s- first started with cleanup, then we stopped the bleeding- Yeah

Ramesh Ramani: you know, by putting in the policy. Then, uh, educate users, you know, along with that. And finally- Yeah ... we moved into automation. That was the s- you know, the steps that we took.

Ashish Rajan: 'Cause you had the whole, I remember in your talk you had the entire AWS architecture that you guys had shown and built. Maybe if you wanna do a high level of what it had and what components it had for people.

Ashish Rajan: And obviously I'll put the talk in the show notes so people can go and actually see the diagram of the architecture and everything. I'm [00:30:00] curious, what are some of the components and wh- why on AWS? 'Cause you obviously use GCP as well, and ob- I mean, obviously there could be multiple reasons for the DNS primarily being there, but I guess where I'm coming from is A lot of people would have gone, "I probably need to use third-party tools for this."

Ashish Rajan: Like, even just a simple thing that you mentioned of maintaining a, for lack of a better word, a domain registry internally for what are our active domains. There's so many moving parts and you're almost-- And a lot of them may seem it's outside the scope of security as well- Yes ... as some may pull out.

Ramesh Ramani: Yeah, absolutely. First off, I built the entire... And first off, this was not a-- I didn't build this all just by myself. It was a combination of work between me, platform security, and- Yeah ... and product security.

Ashish Rajan: Yeah.

Ramesh Ramani: Because product security cared a lot about this because it was directly impacting the applications, uh- Yeah

Ramesh Ramani: you know, within Block, right? So I'll get to that shortly. But, uh, the point here is that I used AWS 'cause it is [00:31:00] what I was most familiar with.

Ashish Rajan: Oh,

Ramesh Ramani: yeah. It was easier for me to, like, you know, uh, build systems in AWS just 'cause it was stuff that I'm used to, honestly. More or less what all developers do nowadays.

Ramesh Ramani: You know, you use the tools that you're most familiar with.

Ashish Rajan: Yeah, of

Ramesh Ramani: course. I mean- So, so that- ... if you were

Ashish Rajan: familiar with GCP, you'll GCP, and same way. Yeah. So it's not that AWS had better functionality, just that's where familiarity was.

Ramesh Ramani: It's just familiarity. It's got nothing to do with, I'm sure GCP has-- I could have built a system in GCP as well.

Ramesh Ramani: I could have built this any- But it's just that I choose to use AWS 'cause it was- Yeah ... it was most accessible for me. So initially, what I did is that I built a, the system in AWS, which will continuously enumerate through our DNS records, and it'll give me a report about all the destinations, uh, which-- or domains which are susceptible to takeover.

Ramesh Ramani: And, I would get the report and I would work with vulnerability management team to find out who's, who owns those destinations- Who owns it, yeah ... and do this manually. You can understand how this was not going to scale, right? Ah, yeah. Uh, not just that, also to identify [00:32:00]if a particular domain is susceptible for takeover or not is not easy to, right?

Ramesh Ramani: Like, a new, a new vendor might come up today and a new third-party solution might come up. We have no clue if they're susceptible for domain takeover or not. So it's a hard problem. So I had to reach out to third party tools out on the internet. For example, there's, there's this, uh, program on GitHub called EdTakeover.

Ramesh Ramani: It's a great repo. Mm-hmm. And that repo gives information to anyone and everyone about what are all the third parties which are susceptible for domain takeover, the SIEM-ing based, you know- Right ... domain takeover. So I tried to integrate it with that.

Ashish Rajan: Yeah.

Ramesh Ramani: Just, and scaling was still not easy for me. Right.

Ramesh Ramani: Uh, especially at a block, at, at block scale, it wasn't working very well. Time was not on our side. We were moving to the cloud. I had to do something quickly, right?

Ashish Rajan: Yeah.

Ramesh Ramani: This is when we came up, you know, I, I found out that the product security team, you know, was working on this problem as well. When I said, when I say this problem, they were trying [00:33:00] to sort of, uh, reduce the scope of their attacks from their application standpoint.

Ramesh Ramani: I was like, let's use this as an opportunity. Let's pitch this in because this is obviously going to matter, uh, to product security as well. And it just so happened that they were using a third party tool to scan the external attack surface of our environment. I was like, hallelujah, this is great. Yeah.

Ramesh Ramani: Let's go ahead and just use this system. Why should I break my head and build this system, you know, which does all of these things ins- instead of just hook into this third party solution, right? So, um, yes, I worked with them and my coworker, uh, Eli Foster, was also the co-speaker for, you know- Yeah ... at, uh, re:Invent CloudSec about this.

Ramesh Ramani: Uh, both of us got together and we were like, "Yeah, you know what? This is definitely doable right now because of the third party tooling that we had." And this third party tooling surprisingly came from an acquisition.

Ashish Rajan: Right.

Ramesh Ramani: So I was like, what is he- All

Ashish Rajan: these sides of acquisition,

Ramesh Ramani: I guess ... ironical, right?

Ramesh Ramani: Yeah. So it came from a third party solution, and they [00:34:00] just wanted to expand it across block. I was like, great. I'm the, I'm all board, let's do this, right? We got a plan together, and we realized that this is never going to work till we do a cleanup and we bring in a policy, you know, to restrict everyone to use a singular registrar.

Ramesh Ramani: So we spent months for this. We spent months, uh, trying to conjure up these different, you know, mechanisms to go ahead and talk to different stakeholders, to centralize on a singular registrar, to work with the vulnerability management team and the legal team to understand what should be the right process that we need to follow.

Ramesh Ramani: And we came up with a framework. Mm-hmm. Let me explain to you how this work. Attribution is a problem, as I alluded to you in the beginning, right? How do we deal with DNS problems without having to worry a whole lot about attribution? There are a few ways about this. Hosted zone takeovers straight up comes to platform security.

Ramesh Ramani: We, we started [00:35:00] routing issues. We started routing issues and putting people as, uh, you know, owners for different issues.

Ashish Rajan: Yeah.

Ramesh Ramani: Hosted zone takeovers would now fall straight within platform security because we now had full access to the registrars. Because we have access to registrars, we can now go ahead and run cleanup very easily.

Ramesh Ramani: Not a big problem. But we would also get information about where that record exists. So w- at Block, every account is associated with an application-owning team. This is something that I alluded to in our previous conversation as well. Yeah. We have in catalog, it's a registry of applications. This catalog of applications has accounts mapped to it, which team owns it, et cetera.

Ramesh Ramani: So we were not able to like, you know, say, this account has this record, and this record is susceptible for takeover, so now this account belongs to that team. So first we would go into our registrar, if it's a hosted zone [00:36:00] takeover, and if it's pointing to a dangling Route 53 name server, you know, we go ahead, platform security cleans it up.

Ramesh Ramani: Yeah. If it is not, if it is account related and if it is like those C name takeover records or, or MX, et cetera, issues, which, you know, we would automatically point to, to teams who had these records created in their accounts. So that is how attribution... We start, we realized that we could start pt- piecing in attribution by either routing it, you know, to the relevant teams or finding out who owns accounts- and applications. So we decided, okay, we now have a framework. If it is hosted zone takeovers, goes to a team. If it is anything else, it goes to the account-owning team, because now we're able to, like, scope this. So we came up with this strategy, because without having ownership, you cannot do much with DNS and automation.

Ramesh Ramani: So then we realized, okay, cool, now we can start the automation process. Then that's when we went into AWS, and I, and we first started off with simple you know, a [00:37:00] system which pulls... So we wanted to have every, we wanted to have a source of truth for DNS now.

Ashish Rajan: Okay.

Ramesh Ramani: What we did is that this third-party tool that we used, we wanted this third-party tool to become our source of truth for DNS.

Ramesh Ramani: How do we do this? What we did is that as a part of the system, we have in an application, a sub-application, which pulls from our registrars and updates that information into this third-party tool. Now, this third-party tool does an external attack surface scanning, right? It also has information about all our accounts, our AWS accounts, our GCP, Oracle, whatever.

Ramesh Ramani: It has information about all our accounts, and now we're feeding it information about all our DNS. From our registrar.

Ashish Rajan: Yeah.

Ramesh Ramani: So now this third party tool becomes our source of truth for- Inventory like a- Yeah. It has full visibility into our accounts, it has visibility into our DNS, and it's now able to enumerate the external attack [00:38:00]surface.

Ramesh Ramani: Bingo. This is what we were missing. This was the, the missing piece in the puzzle. We wanted a singular source of truth, which has- Yeah ... all information about our DNS and, uh, about our accounts. And as it finds these vulnerable DNS, you know, domains, either as hosted zone takeovers or CNAME takeovers or elastic IP takeovers, we had one system which had full visibility into this, and was also able to find these issues.

Ramesh Ramani: So it was simple from here to ha- write another sub-application to essentially just see, hey, you know, what are we, susceptible for, you know, in terms of takeover? If something became susceptible, the system would shoot a webhook to us. We read that webhook and we identify, ah, this domain is susceptible for takeover, and this domain is in this registrar.

Ramesh Ramani: This registrar has this dangling [00:39:00] record, and if it's hosted zone, platform security, we get an alert. We send it to a tooling which automatically creates a ticket and gives it to platform security. Why? Because the type is a hosted zone takeover type. And hence it comes to platform security. We have access to the registrar, so we just go ahead and clean that record and it's done.

Ashish Rajan: Yeah.

Ramesh Ramani: If we do not clean that record, and if we close it without clean, cleaning that record, it's like any other CSPM tool which automatically finds out that, whoa, this is still an exposure, and then fires off another webhook. It comes into our system. Our system's like, oh, this ticket got closed, but it's actually still, you know, an exposure.

Ramesh Ramani: Spins it up again and assigns it back to me and my team. Similarly, you know, for CNAME takeovers, for CNAME takeovers or for elastic IP takeovers, the elastic IP is associated with an account, and that account we're able to understand who owns it. So now we're able to route it to that [00:40:00] relevant application team, to fix.

Ramesh Ramani: So- Yeah ... this is how we set up the entire automation. You know, we have a singular source of truth, which is the, you know, which is our third party tool, has access to our DNS, has access to all of our cloud, uh, resources, and now is able to, like, find these issues and shoot a webhook to us. We look at that information and route that ticket appropriately till closure.

Ramesh Ramani: That's how we were able to solve for this. Now, could you not, by 2024, our bug bounty program for DNS takeovers went to almost zero. Wow. We started with, you know, roughly around 200 and 200-ish in 2022. By the time- Yeah ... we started building this, by 2024 we were close to zero. So- Wow. And we're now doing this regularly.

Ramesh Ramani: Yeah. Uh, so now even our AI applications and users, now when they go ahead and create these random, you know, domains, you know, to integrate with these different applications as third party, our [00:41:00] system automatically identifies this because it now understands and has visibility into all of our DNS, so to speak.

Ramesh Ramani: Yeah. It's now able to like holistically look at this, for the entire organization, and is now able to like drive it to remediation all the way to the end.

Ashish Rajan: Interesting. And one thing that I, uh, and thank you for sharing this as well, 'cause one thing that I noticed about the architecture was the stateless form.

Ashish Rajan: 'Cause to your point, you're, you're scanning periodically. Most people would've approached that with, "Hey, I'm gonna store the state of this DNS domain." Why the choice to go stateless? And I guess was that the better choice in this context for... I, I'm just curious, curious in terms of why the stateless approach?

Ramesh Ramani: I started building the system with two principles in mind. I don't want to manage infrastructure.

Ashish Rajan: Yeah.

Ramesh Ramani: Uh, and I wanted- Oh, that's for the

Ashish Rajan: Lambda function

Ramesh Ramani: I want-- Yeah, exactly. I don't want, uh, to manage infrastructure. [00:42:00] I want everything to be a managed service. So everything was either a Lambda, a step function, or S3 bucket.

Ramesh Ramani: That's it. In fact, the S3 bucket is also-- We don't use it that much. It's just Lambdas and step functions and API gateway. Right. All of these are managed services. I don't have to manage any of these, right? I just have to, you know, talk about permissions, et cetera. I don't have to think about, oh, do I need to patch this, et cetera.

Ramesh Ramani: As a security engineer, the lesser I can manage, the better. Yeah. So, that's why I went with that really. I did not wanna manage infrastructure. I wanted a-- And I wanted to keep costs down because with Lambda you only pay for the invocation, right? That's right. Yeah. Uh, similarly for, similarly for step functions and API gateways, you pay for usage.

Ashish Rajan: Yeah.

Ramesh Ramani: And I don't have to worry about being, you know, uh, how much, throughput I'm having. None of that stuff. It's just simple. Also because it's

Ashish Rajan: internal as well, so you know the volume it would be as well.

Ramesh Ramani: Correct. Absolutely. And because I kinda have to [00:43:00]go back to this, because our third party solution was our single source of truth- Yeah

Ramesh Ramani: which maintained information about every single asset which was vulnerable.

Ashish Rajan: Yeah.

Ramesh Ramani: I could just rely on it for, you know, for state. Why do I need to build my own state related information, right?

Ashish Rajan: Ah, yeah. Good point.

Ramesh Ramani: So it's

Ashish Rajan: a that- 'Cause you basically, you're getting information from there. That's your source of what do I need to focus on.

Ashish Rajan: So at any given point time, point in time, you may only have one or two instead of hundreds that used to be the case. So- Yes ... you don't really need to maintain the state at this point in time. Yes.

Ramesh Ramani: Absolutely. And I mean, it's like any sort of system where you w-want to ensure that you... Any developer would hate to maintain state.

Ramesh Ramani: It's managing state is, is problematic.

Ashish Rajan: Yeah.

Ramesh Ramani: Managing databases is, is problematic. I, I- Yeah. It, um-

Ashish Rajan: Managing resources in general, we go into the vulnerability ma- we become the vulnerability management team at that point in time.

Ramesh Ramani: Exactly. Right. And I have- Yeah ... and, and I kid you not, I have to deal with vulnerabilities, you know, as a developer myself, right?

Ramesh Ramani: So I have fatigue as well. Yeah.

Ashish Rajan: Yeah.

Ramesh Ramani: So developer fatigue [00:44:00] is real. So- Yeah ... yeah, we have to handle for all of those things as well.

Ashish Rajan: I'm curious, now that we are in this AI world as we all live in, looking back, all the components and the work you did, are there parts of it that you feel can be done by AI, can be done better by AI, or AI just would be like an over-engineering at this point in time in terms of...

Ashish Rajan: And this is assuming you just completely researched today.

Ramesh Ramani: Yeah. It's a good question, right? I have conflicting opinions about this. Um-

Ashish Rajan: Sure, sure ...

Ramesh Ramani: could AI do this? Yes. What portion of AI can do this? Let me highlight this. Right now we use this third-party system to enumerate our external attack surface, right?

Ramesh Ramani: Maybe we could use AI to do that instead, right? Yeah. Maybe we don't re- need to rely on a third-party service to actually enumerate our external attack surface. How much can you trust it though, right? How much are you gonna trust these signals? You need to make sure that, you know, these signals are controlled, and you want to make sure that th- these signals are [00:45:00] valid.

Ramesh Ramani: Even though y- you might have AI run this external attacks scanning, and I'm sure lots of companies are already doing this, you know, to, you know, they have these sort of uh, automated red team and stuff like that, right? Yeah. Yeah. Uh, you know, going ahead and doing your, you know, scanning through your external attack surface, definitely doable.

Ramesh Ramani: Can you do this in a controlled way? And, uh, will you be able to trust the signals, you know, every single time? That's the important thing. I chose not to do that. I'd rather, I mean, it's easier for me to integrate with a third party and put, put the onus on them. If stuff goes wrong, you fix it, rather than- Yeah, yeah

Ramesh Ramani: me trying to go ahead and trying to, you know, tune my prompts, uh, you know, ensure that, you know, I now maintain databases, you know, to make sure that the data that I, that I scan and, you know, put it into a database, I need to maintain state. You're getting my point.

Ashish Rajan: Yeah. It's doable

Ramesh Ramani: I-- But I'd rather not do it.

Ramesh Ramani: Uh- Yeah ... you know, um, at, at [00:46:00] least that, that's where I am right now.

Ashish Rajan: Yeah. I, I think I, I'm with you. Well, I think the-- another thing I will add is 'cause a lot of people who would listen or watch this would-- may have third party reaching out saying, "Hey, by the way, we can do your-- look after your DNS that may be vulnerable.

Ashish Rajan: We have AI capabilities that can even go ahead and do whatever." But I-- obviously it doesn't take away from the component that you have to have an internal registry of applications and who the owners are. There's a, there's a lot of backend work that you guys have done to even enable to this point, so I do wanna caveat that.

Ashish Rajan: But assuming that was there, third parties could technically come and go, "Hey, yeah, as long as I have access to that information, and if you are comfortable for us to go down that path- Yeah ... we-- maybe we can identify and send it to an owner." And that could be one thing as well, I guess.

Ramesh Ramani: Absolutely. So long as you're absolutely sure- Yeah

Ramesh Ramani: the signals that you're getting, uh, so long as you trust the signals that you're getting from AI as it scans through your external attack surface, you're good. Let me give you an example, a slightly tangential example, [00:47:00] right? And it's something that I spoke about to you a little earlier, which is we are trying to see how we can scroll through, you know, our systems with AI and our logs to see how we can actually do least privilege, you know, within our systems.

Ramesh Ramani: I wanted to use AI for this, but I kid you not, using AI to scroll through our configurations, our logs, and trying to measure least privilege is not going-- is-- was not giving me the right signals. Oh. I needed deterministic results for this.

Ashish Rajan: Yeah.

Ramesh Ramani: I needed absolute deterministic results to measure least privilege because, not just least privilege, but also logs in general.

Ramesh Ramani: When, when you need to s- make certain sense out of logs and configurations, you need to bring out deterministic signals. I could not trust AI to bring me those deterministic signals for logs at that scale, especially LLMs. It's not possible. You might need a bespoke AI, uh, you know, to go through your logs and to like, you know, get you the signals that you need, at which point in time you, you're better off running your own ML [00:48:00]stack-

Ramesh Ramani: and trying to see what kind of, uh, inferences that you want. Yeah. I didn't want to go down that route, you know, for e- for both of these problems because signal matters to me. Yeah. I'm not there yet where I feel like these signals come out very maturely- Yeah ... through just LLMs parsing through your tons of logs and configuration data yet.

Ramesh Ramani: So yet is the key word here.

Ashish Rajan: So interesting thing, right? Because to people who may be r- already in the middle of a program or like the product sec people that you had who were tackling this when you caught onto the... caught up with them, people who are trying to solve this today, uh, in their security program, in the work that you've done, obviously ownership and attribution is number one, which is just non-technical things.

Ashish Rajan: But in terms of... and but obviously the hardest ones as well, so I don't wanna tri- trivialize it. It's quite difficult to do and takes a long time. But once you get past that hurdle, in terms of technical things, so obviously there are mul- there are different kinds [00:49:00] of domain takeover. You mentioned the whole CNAME, there's MX, there's Elastic IP, and the list goes on.

Ashish Rajan: Host- hosted

Ramesh Ramani: takeovers. Yeah.

Ashish Rajan: Yeah, yeah. So w- is there one that is easier to start with than the other that people- Yeah ... can use, esp- especially without creating developer friction, which is kind of quite important for a lot of people.

Ramesh Ramani: Yeah, absolutely. CNAME takeovers is a big- Oh. CNAME takeovers is a big thing, right?

Ramesh Ramani: Like, let me give you an example. So today, as I alluded to, we have some very good open source tooling, like ED takeovers, right? Yeah. You can reach out to ED takeovers and see if a particular third party is, you know, susceptible for takeover. AI makes that easier.

Ashish Rajan: Where

Ramesh Ramani: AI can actually do that, faster to tell you that, "Hey, this particular domain is susceptible for takeover or not," based on whatever research parameters it does, right?

Ramesh Ramani: Yeah. Again, can you trust it?

Ashish Rajan: Yeah.

Ramesh Ramani: The, the point is what kind of signals can you make sure to make sure that you trust it? That's the tough point. But yes, CNAME takeovers are easy to do. Hosted zone takeovers, not so much. Mm. You know, it, like, because I still feel like hosted zone [00:50:00] takeovers, you know, an, you know, an AI agent can probably tell you it's susceptible, but you might need to have the right signals for this yourself because you own the registrar.

Ramesh Ramani: The C- you know, uh, you would know for sure, you know, and you own the, the accounts. So, would you tell the AI agent to, like, go ahead and look at every single account that you have, all the records that you have, and then see if all of those are susceptible? Maybe.

Ramesh Ramani: But you need to provide it the source of truth.

Ramesh Ramani: Where's, you know, the central piece, the central missing piece. I'm not fully convinced yet for hosted zone takeovers. For CNAME it helps- Yeah ... identify what's susceptible, CNAMEs, but for others, not so much.

Ashish Rajan: Cool. I mean, those are most of the technical questions I had. I've got three fun questions for you.

Ashish Rajan: I think you've answered them before, but I think I'm curious if the answers have changed. Uh, the first one is, what do you spend most time on when you're not trying to solve domain takeover problems in the world?

Ramesh Ramani: Spending time with my kids. Uh, watching your, you know, Cloud Security Podcast videos. I love watching them.

Ramesh Ramani: And, uh-

Ashish Rajan: I appreciate

Ramesh Ramani: that ... yeah. Uh, so yeah, spending time with my kids, spending time [00:51:00] with family playing games. So these are the things that I, that I love doing, uh, you know, during my, uh, off time.

Ashish Rajan: Awesome. Uh, that's a great answer as well. Uh, w- second question, what is something that you're proud of that is not on your social media?

Ramesh Ramani: Proud of that's not on my social media. Wow. My master's, wow. I haven't announced it on my, in, on my social media, but I got my master's two years ago. Wow. Um, from Georgia Tech. So yeah, I'm super proud of that, I guess. Uh-

Ashish Rajan: Jade, w- w- that's, hey, congratulations, man. Georgia Tech masters would've been amazing.

Ramesh Ramani: Uh, it was in cybersecurity only 'cause I liked it. I, I- ... I was talking to my wife and I was like, "Should I try this?" And she was like, "Yes, go for it." And yeah, I tried it. Uh, and, uh, yeah, that's something that I'm super proud of. Yeah.

Ashish Rajan: Oh, awesome. Thank you. And, uh, final question. What's your favorite cuisine or restaurant that you can share with us?

Ramesh Ramani: My favorite cuisine right now, uh- Over the last eight months has, uh, has slightly shifted to Korean style food. So, uh- Oh. ... I, I'm really enjoying Korean food right now. Uh- [00:52:00]

Ashish Rajan: Like

Ramesh Ramani: Korean

Ashish Rajan: barbecue? Korean fried chicken?

Ramesh Ramani: I'm a vegetarian. So you- Oh, right ... my, my, my options are very limited, but there are tons of like veg- Korean vegetarian restaurants nearby that my wife and I like to visit.

Ramesh Ramani: Interesting.

Ashish Rajan: Oh, wait. I need to, uh, expand my Korean vegetarian, uh, palate as well. But dude, thanks for sharing all

Ramesh Ramani: that. It's very cool. Uh, can I ask you one last question if you don't mind? Yeah,

Ashish Rajan: yeah.

Ramesh Ramani: How was the experience writing your book? I'm looking forward to

Ashish Rajan: reading it. Oh, right. Yeah, the AI Secure Engineering book was uh, quite a task for over an year.

Ashish Rajan: And the funny thing was with the, uh, because obviously now fortunately it's gotten number one on the Amazon US store as well- Yeah. Oh, wow ... which has been amazing. Awesome. Yeah.

Ramesh Ramani: Awesome.

Ashish Rajan: Oh, thanks, man. Uh, it's been great. Looking forward to reading it. I think the-- I appreciate that. It's als- so all the advisory work that I do with all the Fortune 500, Global 2000 companies, it's kind of the strategic work has led to where that book landed.

Ashish Rajan: The, the-- I think the hardest part, if I were to be honest, is the fact that I had to rewrite the book halfway because when I started writing the book with Wiley, there were no AI [00:53:00] agents, and by the time I got to the fifth chapter, suddenly AI agents became a thing. It almost became like, can you imagine an AI book or especially an AI security book with no AI agent coverage?

Ashish Rajan: You're like, there is no way you can publish a book and go like-- you can promote it all you want, but if there's no AI agent, it's a pointless book at that point in time, at least in my mind. So I restarted writing the book around June 2025. So it obviously is now 2026 now. So that's why- Wow

Ashish Rajan: it took a while. But at, at some point you have to draw a line going, okay, AI is not going to stop evolving. At some point, you have to draw a line and go, at this point in time, am I comfortable enough that most companies out there are not evolving any more dramatically quicker that I can catch up and I have to rewrite the entire book?

Ashish Rajan: So that's where I drew the line. But I think as my publisher and technical writers also said technical editors also said, "Rest is for V2." I will do a second edition if it's really needed, but if we don't draw a line, I would never finish the book. So it's like, uh, I think the exercise of [00:54:00] it has definitely humbled me about how people did write books and especially wrote books with their full-time job as well, which is just- Yes

Ashish Rajan: amazing for how people did that. Unimaginable. So yeah, man, I appreciate you asking the question as well, but thanks so much for sharing your experience too. Uh, where can people reach out to you and learn more about the work you're doing? And obviously I'll put the, both the talks on the show notes as well.

Ashish Rajan: Where can people reach out to you and learn more about the work you do at Block and otherwise?

Ramesh Ramani: Yeah. You know, talk to more people who are trying to solve similar problems, right? Uh, you can reach out to me at ramesh.ramani. That's ramesh.ramani at, uh, at LinkedIn. Oh, awesome ... so that's

Ashish Rajan: one way.

Ashish Rajan: I'll put the LinkedIn, uh, link in there as well. But dude, thanks so much for coming on the show.

Ramesh Ramani: Thank you. Thank you. Great questions. Thank you. Really appreciate it. Take care.

Ashish Rajan: Thanks so much for everyone. Thank you for listening or watching this episode of Cloud Security Podcast. This was brought to you by techriot.io.

Ashish Rajan: If you are enjoying episodes on cloud security, you can find more episodes like these on cloudsecuritypodcast.tv, our website, or on social media platforms like YouTube, LinkedIn, and Apple, Spotify. In case you are interested in learning about AI security as [00:55:00] well, do check out our sister podcast called AI Security Podcast, which is available on YouTube, LinkedIn, Spotify, Apple as well, where we talk to other CISOs and practitioners about what's the latest in the world of AI security.

Ashish Rajan: Finally, if you are after a newsletter, it just gives you top news and insight from all the experts we talk to at Cloud Security Podcast. You can check that out on cloudsecuritynewsletter.com. I'll see you next episode. Peace.

‍