Dhruv Ahuja of Chaser Systems

Alright. Welcome back to another episode of Modern Cyber coming to you for the last time this year from the sidelines of fwd:cloudsec 2025 here in Denver. And as with the previous episodes that we've recorded live here, I have the opportunity to sit down from one with one of the speakers from the event, talk to them a little bit about their research, what they learned, any of the lessons they could share. I'm delighted to be joined today by Dhruv Ahuja. Dhruv Ahuja, thank you so much for taking the time.

Thank you for having me join me. Yeah. My pleasure.

For those who don't know you, why don't you just take a second, tell us a little bit about your background, how you got started in cybersecurity.

Right. So my background is normally from the financial services world in London mostly. And, before that bit of sysadmin roles and Rackspace and companies like that. So I hadn't realized, until I looked at cybersecurity specifically that I was already good at it. It's sort of a given you have to be good at it in sysadmin and financial services roles. Yeah. Yeah. So when I looked at security becoming a specialization, with the adoption of the cloud Yeah. I tried to move literally in one of the organizations I was working at the time, and they were very happy to have me.

Awesome. Awesome. I'm I'm curious about that background in financial services. Financial services is one of those things that like everybody hears about and obviously we all know our banks or or Yeah. We mostly use banks. Right? It's one of these industries that often whenever people say, oh, like an industry with high regulatory compliance requirements or a lot of regulatory oversight and very, very sensitive data, everybody says, you know, first three things people say are like financial services, health care, government. Right? Yeah. I under you know, from your own experience working in financial services, are financial services companies different from other kind of companies?

Yes. They are. They have, very different of course, the regulatory pressure. To give you an example, I used to work before I went working for a bank, I used to work for a market data feed company. Yep. So we were supplying tick data of stock market and several other classes of assets. Yeah. So you can imagine if if we supply the wrong data, you know, it will be an international turmoil in the market. People will make like money decisions based on Based on yeah. And everything was tuned down to the milliseconds. Yeah. So it had to be extremely extremely robust. Okay. With, latency guarantees given as SLAs out to other investment banks. Okay. So it's pretty serious business. Okay. So these days, for example, I don't see people caring about latency that much in the cloud. Yeah. What that sort of a world needed. Yeah. We've sacrificed latency for eventual consistency. Right? Yeah. That kind of a thing. And you'll see that the companies like Bloomberg, Thomson Reuters Financial Risk, Refinitiv, etcetera. Most of the core data feed prem for them. Yeah. And if you talk to any like hedge fund or investment bank, they are attached directly into the exchanges switches for the low latency. Yeah. So it's a very very different word not necessarily visible to anybody on the outside unless you are on the inside. Yeah. That that's when you see the real protocols they use and that kind of a thing.

Are they different protocols?

Oh, yeah. They are very different. They are extremely efficient because you have to pass in so much data in a minimum amount of time. So they do away with, like, excessive syntax. Okay. So, I mean, like, TCP IP is not, like, the core underlying Not for market data. It's UDP. Okay. Yeah. So Interesting. Yeah. So because the you can't wait for an acknowledgment to come back and But even UDP, like sorry to interrupt. But when I think about UDP, I think I I again kind of think of eventual consistency and, like, yeah, it might have higher throughput performance, but I don't to your point, like, I don't have that acknowledgment. So I don't know for sure that something has gone through.

So in in those architectures, you would have multiple streams and you'd be sure that, okay, well, if not there, then on the other one, it would have made it through. Okay. So that's point one. Secondly, the tick data was like changing every four milliseconds. And your decision making usually would take longer than that. So you would catch on the next one anyway. Yeah. And finally, the there is there was some sort of a checksum built in into a custom UDP protocol called fix as well. So you would know if something went to miss and so on. So they basically implemented some of the TCP in a very lightweight application layer protocol Okay. But working on UDP. Okay. The other thing about the specialized hardware was that you would have over provisioned Yeah. Bandwidth there. So there was and we would be monitoring for UDP packet loss. Switches can measure that. So we would be keeping an eye on those monitors whether there was any loss. Yeah. We would be running at zero loss. Yeah. This is not because of the Internet. Right? This is private cables patching directly into the exchange. Yeah. Yeah. And you can monitor them. Yeah. So it's interesting. I mean, it's it's almost as like parallel infrastructure that a lot of the rest of the world doesn't really know about or use and and Yeah. Yeah. Yeah. Out there. And and so, I'm kind of curious about the macro question about, like, well, why do we hear so much about financial service companies moving to the cloud then if you've got all this, like, parallel infrastructure that's built up over the years?

Yes. So that's the other side of financial services, like retail banks. They have no requirement for all of these low latency kind of things. I mean, you know, if you try make make a transfer to someone Yeah. Your SLA is, like, in three, four hundred millisecond range, you know. Or if that's So make a transfer to somebody, let's say, over, like, you know, just kind of like a not a Venmo, but, you know, a service like that that's, you know, transferred from my personal account to your personal account, and it happens within a few minutes. I'm kinda okay. Happy. Right? Yeah. Yeah. So they can they don't need all this throughput and low latency. For them, it's okay to move to the cloud. Okay. Secondly, most of retail banking is just forms and websites and doing various things. With the largest banks of the world, they are still running mainframes. And there are several layers of APIs built on top of it. And those API layers have now moved to the cloud. Okay. But for banks which are, like, more than 200 years old, they have so much record and data. They can't possibly move off those mainframes which are in bunkers in The UK anymore. Yeah. Yeah. Yeah.

I've had this argument with with somebody not too too long ago, and I kind of not an argument, but just kind of a, an opinion that I had and I shared with somebody, and they they kinda push back a little bit. And I said, like, look. Look. At the end of the day, we do very little with cash anymore. Right? Financial service companies are primarily data companies. Mhmm. And they're about storing, you know, like, my ones and zeros and your ones and zeros and protecting my ones and zeros and making sure that I have access to them and hopefully nobody else does who Yeah. Who isn't meant to. And then I can use my ones and zeros in exactly the way that I choose to use them. Am I wrong to think about financial service companies that way?

No. But there's more that goes on behind the scenes. So, you know, banks are heavily regulated. What does that mean? Sure. So a real bank is able to offer a credit line. Yeah. Right? If a bank can only hold money, they are not really a proper bank. But they are working their way towards having such a large amount of capital that they can take on some risk. Yeah. So banks have to run a nightly calculation on how much risk they have taken on during that day and they can't exceed a certain threshold set by the regulator. Okay. And these reports have an SLA with the regulator. Okay. They have to run on time and so on. Yeah. So there is the mission critical infrastructure of risk calculation within a bank.

But again, when I hear that, I'm like, that's this is a data problem. This is not like Yeah. True. True. True. But a lot of people, you know well, since we are in a cybersecurity conference, I've seen some of the best pen testers on board with banks. You know, they really know what they're doing at every layer of the stack. Yeah. So it's crucial that people are not able to just bypass MFA etcetera in a bank. Yeah. Yeah. Yeah. Even in the login security architecture, I'll give you an example. For example, if you log in into a bank just to check balance, the bank may not ask you to use your bank authenticated device or 2FA, if you will. But if you add a new payee Yeah. They ask for re authentication or some special code, etcetera. Right? So all of this is designed by very specialist architects in the bank. Okay. And then all of this has to be pen tested Okay. Before it goes live.

Does all of it have to be signed off by a regulator?

No. Okay. This is signed off internally by, c suite executives. I suppose they are liable or not. I don't know. Really?

Yeah. Okay. Okay. But they did take the job seriously with this. Yeah. Fascinating. I mean, you know, all of this from my initial question, are financial services companies different? I think it's eye opening for a lot of people, probably myself included, obviously, that to think about what all goes into these types of organizations. Let's change gear for a second. What was your talk on here at fwd:cloudsec?

I think it was titled I'm Roles Anywhere Now for Everyone with Let's Encrypt. Okay. What was kind of the background and the basis of the of the presentation?

So I personally am a big fan of asymmetric cryptography. Okay. The IAM Roles Anywhere is the AWS service which lets you use certificate authorities and certificates to get a role back from, AWS. Okay. A session token which is connected to a role. And, I've been exploring the idea for eight nine months now and we we are actually using this in production for about six months now. What we've done is that we have some workloads with specialists. You know, AI came along and everybody got interested in GPUs. So we wanted to run some experiments, by running our own small little models. Okay. So we went to a specialist GPU provider but a lot of the telemetry data we have, is in AWS s three buckets. Okay. And so we wanted a cleaner way of accessing that Okay. Into this random GPU provider that we have. So we were looking for a more elegant method than static credentials. Yeah. So that's where it all started. Okay. And then, I don't know how and when exactly I was able to connect the dots that all AWS IAM roles anywhere needs is a public key infrastructure CA, PKI. Right. Let Let's Encrypt happens to be one. Yeah. I can easily give these GPU machines, which are just Linux machines. Right? They can easily get an identity for themselves from Let's Encrypt, and I can use the same identity with AWS. Job done.

And so that identity that you're using, let's say, outside of AWS on these Linux based hosts, is it using kind of like the AWS command line tools to then do things like session management and obtain these credentials.

That's correct. It is. Yeah. It's very transparently integrated into their SDK. Okay. But that's the heavy lifting AWS have done for you already.

By providing the certificate authority infrastructure and then providing the ability for you to kind of, like, access these roles externally or what do you mean?

The latter, yes. Okay. For the former, they say that you could either use AWS private, CA Okay. Which is a I think, I don't know, $400 a month or something like that. I'm horribly wrong there. But Sure. The or you could upload your own CA certificates. Okay. Which is the option I chose. Okay. It wasn't so much about not being not using an AWS service. We are an AWS user, and our service wouldn't have mattered. Yeah. But I am more of a I like interoperability, and I like to prove interoperability. Okay. So for me, not using the built in PKI was a win Okay. Because that means I'm using a neutral protocol like Let's Sync Group uses Acme. Yeah. Yeah. You know, if I can tie in an Acme issued certificate and get it working with the cloud provider of my choice, I feel much more safe and insulated from, choices I may have made today, but I would not make again tomorrow.

So in that scenario, let's say worst case scenario, some government authority shows up to Amazon with a subpoena and says, like, hey. You know, Dhruv is subject to whatever investigation we need access. Even Amazon can't access the certificate authority that you've put in place in order to generate these credentials.

That is a good point. I hadn't thought of that. Yeah. But, yeah, you're right. But, ways that's encrypt based. I think it's US based. I don't know. So yeah. Yeah. Yeah. I mean, okay. So they need a second subpoena. But my point is that it's like a certificate authority not in the certificate authority not in the control of the cloud providers who've created That is a good point. That is a good point. Yeah. And, in my talk, I stressed twice that you don't have to use Let's Encrypt. Yep. This proves that you can use the Acme protocol with any of the other providers or host your own even. Yeah. So, yeah, that can add another layer of protection if you wanted.

But this Acme protocol was important to you?

Yes. It's open source. It's interoperable. Okay. Yeah. I I would say so. Yeah. Okay. That's interesting. I mean, if I could push back for a second, I mean, like, it sounds like you found an elegant but maybe complicated solution to a problem that you probably could have solved in an easier way.

I can't disagree with that. Okay. But you would either have to bite the bullet and learn how AWS Private CEO works. Okay. And then Which proprietary never mind the ping, and the pay and then learn those specific APIs and then it tied down to it. Okay. Acme was something I already knew. Okay. So this was easier for me to get working. Okay. So, I mean, if anybody does watch my talk, they will realize that it is really quite straightforward to get RedSynthrit working with Roles Anywhere. Okay. So if you've if you if you have issued yourself a certificate using cert bot or any other client Yeah. Library like Lego Yeah. Which was in my talk, it is really very straightforward. Yeah. Yeah. If you are familiar with Roles Anywhere and Let's Encrypt separately Yeah. This has been an easier way out than even using AWS private CI. I'm I'm trying to remember now. I can't remember what is the, Linux command line command for generator certificate, but It's open SSL and then 15 arguments to it.

Yeah. Yeah. Right. Right. Right. Yeah. It's been a while since I've had to do that thankfully. And I I don't really miss those days. No. I did not want to get into all that either. Yeah. But the Let's Encrypt has come so far. The client libraries are so mature. They've thought actually about user experience. I mean, so many of these services, I mean, if you think back to the early days of when I was working in IT and by the way similar to you I started in kind of a sysadmin position and you kind of just cybersecurity was just part of what you did at the time. Right? I also had my worst breaches, during my time as a sysadmin before I got into more kind of specialized cybersecurity. But that's a a longer story. But certificate management was like a nightmare back then, and certificates were very much fixed to the physical, you know, hardware host that you were running on and, you know, generate the signing requests with, like, fingerprinting of the CPU at time. And if you ever, like, then had to migrate from server a to server b, that was also a nightmare. Cancel certificate, reprovision the certificate. And companies were charging thousands of dollars a year for these services. Right? Like Yeah. I just think about, like, the economies, the the, unit cost of of certificate nowadays are like darn near zero. Right? Yeah. Let's interpret has definitely threatened the models of DigiCert and the rest of them. Yeah. Yeah. Yeah. Yeah.

How have you seen the evolution of certificates over the years? Like, I mean, I look at it and I'm like, this is fantastic. I can put a certificate anywhere that I need to now. I can get a certificate for any service that I need in a matter of seconds. Right? Yeah. Yeah. Just like extremely affordable price points. There is the flip side of that argument which means that like every phishing service can also get a certificate that looks legitimate as well. Right?

Yeah. So I think the CA industry has has they are at fault with this, you know. They've asked people to trust the padlock in the browser more than the domain name. Yeah. And I'm not sure why the browser makers have also decided to now hide away the domain name completely. Yeah. Feels a bit wrong that we we basically coached other people to just trust the padlock. Yep. Yep. So yeah.

Yeah. Kind of a weird evolution, of, like, this trust in user trust on the Internet over time. Right? Yeah. They used to be this thing called extended validation certificates. We used to turn the browser bar green. Banks used to have it, and that would require much more validation than just solving a challenge over over TCPIP. Yeah. You would have to send your company registration documents to the certificate authority. They would charge you 500 to $1,000 or what have you. Right? And then issue you the certificate.

That's interesting though. Like, I mean, if you think about that. Right? If you could bring that back to the current Internet, which I know would be super challenging because the scale of the number of companies that the number of legitimate valid companies even like Yeah. Put the criminal gangs aside for a second, but just the number of valid organizations that would need to be authenticated and and verified with their documents. I mean, like, that's bonkers already. Right?

Yeah. I think it's also the end user education. Okay. Well, browsers have only in the recent, last few years started removing that feature that the browser bug would turn fully green if this were the case. Yeah. Or any visual indication of higher trust. Yeah. But then think about the user and user education. Like, okay, well, this is green and you know, you can really trust it. Yeah. Green means But if it's but if it's not green Yep. It's just plain Yeah. But there's still a padlock Yeah. How do you are you not supposed to trust it? Yeah. What what TLS really gives you is an encrypted channel and a verification of the authenticity. The criminal can also be an authentic person. Right? The authenticity of the certificate, not necessarily of the entity behind this.

Correct. Yeah. Yeah. Yeah. Interesting.

So so wrapping up on the topic of your of your talk today, so you designed the system. You kind of shared, obviously, what you built around there. What are some of the, like, key lessons learned that the audience would take away from that presentation?

Key lessons. Let's see. So I think people should be more confident in using asymmetric cryptography in their lives. Yep. That definitely and this this, because less encrypt is entirely free, all you need to have is a domain name. And people in our industry have 10 or 12 lying about anyway. Yep. Never put to good use. I might have six or so of my own personal ones. Yeah. Yeah. Yeah. And you know if you go to something like porkman.com, you can get one for 1 or $2 now. Yeah. So I would say that they should definitely start playing with this. Yep. And and and then learn from experience. Yeah. Improve their general PKI handling and, CA kind of skills. The other one is that the the world that opens up with this because, you know, Roles Anywhere literally was made for being able to use human AWS role outside of AWS anywhere. Yep. So all the hacks and the other, you know, vendor solutions, if you will, who are managing this now go away Yeah. With this kind of a solution. Yeah. But you said something there. I just wanna make sure I understood. So you said, like, the the concept of IAM Anywhere was designed for humans to be able to use IAM Roles Anywhere. The concept of roles and IAM Roles Anywhere Yeah. That's the full service name of that particular service. Right? Yep. Was designed to to let you assume an AWS I'm role Yeah. Outside of AWS. Right. Yeah. But the solution that you designed is for a machine to assume an identity. Right? Like, because you're not talking about you Humans. Transferring, like, the the log files from your, Yeah. Sorry, from your service to this GPU provider. Right? You're talking about that happening all through automated, I assume, data streams of some kind.

Yes. Yes. Yeah. But talking about humans, Ben Britt, I'm getting the surname wrong, has recently published a blog post which was in the cloud security firm Slack as well where he uploaded the, Belgian citizen bureau, what have you, CA certificate onto I'm Roles Anywhere. And Belgians are allegedly issued with a citizen ID which has a private key on it. Interesting. So you can authenticate a Belgian citizen into roles anywhere now. Yeah. That ties it down to a human right.

Yeah. Yeah. I mean, some of these European countries, especially some of the smaller ones like Estonia, I know are doing great things with kind of digital IDs and and, you know, to your point, using that as a basis for, for some asymmetric, cryptography and and, authentication access and then encryption for all the all the government services and transactions. Yeah. Yeah. Yeah. Yeah.

So signing should be based off a private queue. Right? It's like if you open I'm not gonna name websites here, but, you know, most popular signing contract signing services. Yep. They just record an IP address and send you a magic link in your email. It's not a very strong kind of legal authentication even.

No. I mean, to be fair, anybody who had access to my email could theoretically intercept any signature request. Yeah. Yeah. Yeah. Doesn't take a genius to kind of draw something that looks like a signature with their finger. So yeah. And all the best with proving that this IP and Jeremy was near this IP address physically at the time.

That's true. What does that even mean? Right. Like, I mean and there's no reason for instance, especially if I'm signing on something like whether it's I'm signing on my laptop or I'm signing on a mobile device, I've got biometric verification on both systems. You know, it could be my fingerprint on my on my keypad or it could be my face ID on my phone. Yeah. There's no reason there's not a biometric verification that this is actually Jeremy who's signing this electronic legally binding.

Yeah. Legally binding. Right. Yeah. Yeah. True. Yeah. True. So it's just playing with this, opens up your mind to these opportunities that, okay, I've got a digital signing key. Yep. There's a certificate authority which has issued this to me for a certain reason. Yep. How can I leverage this? Yeah. Yeah. Yeah. I wanna change yours for a second with a couple minutes left we have in the conversation. I know your background has been in network networking and network security. And obviously, we talked a little bit about some of the things you learned working in financial services with this kind of parallel network infrastructure, if you will. How have you seen networking evolve over the, you know, the course of your career? Because, like, to me, TCPIP fundamentals are still TCPIP fundamentals. And, you know, things like firewall allow and deny lists are still pretty much the same. Granted, I think the perimeter of the cloud as far as, like, what is the network perimeter is is a very different thing than the kind of castle and moat classic architecture. But what have been some of your observations?

So pretty much what you said, the management of the perimeter, whether it's your ingress rules or your egress rules is now very, very difficult to manage. Yeah. The meaning of an IP address is not what it used to be because ownership is by one of these large cloud providers. And they are multi tenant platforms and so that has definitely changed. Yeah. And, believe it or not, last year, I think 48% of UK's traffic to CDNs was IPv6. So it's finally coming around. Yeah. Yeah. Yeah. It was only three or four weeks ago. I was troubleshooting an I'm policy with somebody on cloud security for on Slack, and it turned out that one of these services from AWS was returning quad a record Yep. Which is I p v six. Yep. And the other one was returning a regular I p v four record, and their ISP had was already dual stack. Yep. So their MacBook or whatever it was had picked up an I p V four and an I P V six address at the same time. Okay. So it was egressing using both depending on what DNS record was returned. Interesting. So the point I'm trying to make is that I am beginning to see IPv6 for real now. Yeah. Yeah. Yeah. So and that that is IPv6 is very interesting because it's globally unique addresses. So I think there will be some loss of privacy because you will be no longer behind that.

So, like, oh, okay. So when I'm, you know, at home on my but still within my home network, I'll probably have some kind of now.

No. So the I p v six recommendation is that you'll get a slash 56 block at home. Okay. Each of your devices will have a globally unique I p v six address. Even my internal, you know, my refrigerator and my Yes. The devices? ISPs are particularly interested in the known ad aspect because the CPE, the customer premises equipment, becomes a lot cheaper if it doesn't have to do session connection tracking, that kind of a thing. Okay. So things like your home router and all of those things can become a lot simpler. Just routers. Yeah. Just plain routers. Yeah. Yeah. Yeah. That's interesting.

What are some of the key differences between IPv four and v six? I mean, you mentioned this like slash 56 and obviously, like, that doesn't exist in an IPv four world.

No. It's probably more than the entire IPv four space that you will just have at home. Yeah. That's what I was thinking. Flash 32 is as specific as we get. Right? Yeah. So DHCP is quite different as well. Okay. IP v six has a method of figuring out based on your MAC address what IP you will get from your 56 block. Okay. And, yeah. Other than that, I think it's just IP protocol. A lot of band aid that had been put on IPv four doesn't exist in the IPv six world.

So like the NATs and the PATs and those types of things?

Yeah. Yeah. Yeah. It's simply not necessary. Right? Yeah. Yeah. But still things like, you know, fundamental, let's say, like, subnet masks and route tables and all of those things still exist?

Those do those do exist. Okay. And, like, the space is much larger, obviously. Yes. I don't but I don't actually know, like, how big an IPV six address is from the standpoint of, like, how many It's four times bigger. Okay. It's a thirty thirty two bit IPv4 address compared to a 128 bit IPv6 address. Okay. So that does take up a little bit more room in your IP header? Yep. And the Internet runs on a very low MTU already less than 1,500 surely. So yeah. Yeah. I mean, it's not an argument against IPv6. I'm just saying that you know another 90 something bits will go Okay. Just into the header. Yeah. Okay. So this is probably an extra like nanosecond of processing here and there on Which you will reclaim back because of, you know, lack of NAT and the rest of it. Okay. Alright. Interesting. Yeah.

Aside from that, do you still see organizations struggle to manage a lot of kind of network based rules?

Oh, yeah. Definitely. Yeah. Like this hasn't changed. This hasn't changed. Yeah. It may become more predictable with IPv6 because people can have fairly stable blocks. Okay. So if like we said a few minutes ago, cloud service providers have to share IPv4 spaces between customers. Yep. But there is so much IPv6 space that you won't have to. Yeah. In Amazon if you create a VPC right now, which is IPv6, you get a slash 56 block for free from Amazon. Yep. And that is guaranteed globally unique. Okay. Your egress and ingress will both be just that. Yep. So it's not it's not the VPC that you spin up today using IPv4. That is just RFC nineteen eighteen private ranges. Right? Yeah. This and the ingress might be shared on that. But that's not going to be the case with IPv6.

Do you think we're at a point where you could actually, like, let's say you were starting greenfield, you know, nothing, no legacy, anything. Could you start something that is a 100% IPv6 today?

No. No. I have already tried the you know, the no. There's a lot of DNS infrastructure missing to do that still. You will, at a point, need the end mile could be IPv6. Yes. But you will need at some point a NAT 64, six two four because quite a lot of the world is the servers are still IPv4. Okay. GitHub is a very good example. Yeah. They're completely IPv4. Okay. IPv six is on their road map, but they don't know anymore. Interoperability with a lot of popular services or you want, let's say, like, a lot of consumers in the world. Because you mentioned it's, like, 48%, so that means 52% are still not IPv six. Yeah. Yeah. Yeah. If you want them to be able to access your service, you're gonna need this. Yeah. Correct. Yeah. Or somebody will have to do NAT six four on your behalf. Okay. Yeah. Okay.

Talk to us a little bit about what you guys are building at Chaser Systems.

We build a network firewall basically for egress. It's like, you know, we we talked about IP addresses being shared and so on. So our product is focused on the use of domain names rather than because, you know, this if at a software contract level Yep. You are making an API call outbound to a domain name. Yep. Nobody gives you IP addresses anymore. And if they give you an IP address block, it's too big. Right? To be comfortable with, like, you know, Salesforce or something, they'll give you slash 17. Okay. That is huge to be trusted. You know, they've got all sorts of things running in that slash 17. So, but the last two years, we've shifted our focus from the sheer security properties of the product to the usability of the product. Okay. Developers don't know what, FQDNs or domain names to allow even Yeah. And how to then safely introduce a firewall into an environment where there was no firewall before. So we've developed a lot of logic around, driving mode and alerting and then how to keep the security team in the loop for approvals, Shortening the length of time it would take for a developer to find out they've been blocked to actually getting it approved and not allowed. Yeah. So and I think that's paid off very very well. When people see the user experience of it, they really appreciate it. I think this kind of, name based management is likely to be a lot easier for humans than, you know, IP address based management, which is what we've always had to deal with. Yeah. It's going to be a problem with IP v six though because the addresses are so long. You can't just pick up the phone and say I'm at one ninety two one sixty eight dot dot and this. Yeah. Yeah. So that's a problem. Yeah. But I was coming more from a software contract point of view. Okay. If you're writing software to integrate with a third party Yep. What's the contract? These were the JSON schema or whatever schema is which is the API contract. Right? Yeah. The way you hit it is also a part of the contract, the URL. Yep. And that's hardly ever an IP address these days. No. That's normally of FQDN. Yeah. Yeah. Yeah. So you can literally put down your contract into the egress rules. Yeah. Okay. This is where you're supposed to go. This is the third party we are supposed to trust. Yeah. Yeah. Yeah. Makes a ton of sense. Yeah.

Awesome. Dhruv, thank you so much for taking the time to join us on the show.

Me here. Yeah. Awesome. For our audience, thank you for joining us on this episode. If you know somebody that you think we should have on the show, please reach out. If you or somebody that you know wants to come on and join our breach series and share real world experiences, experiences, we are still looking for a couple people to join us on that series as well. Otherwise, on behalf of myself, on behalf of Dhruv, thank you so much for taking the time to join us on Modern Cyber. Talk to you next time. Bye bye.