Ramesh Ramani: [00:00:00] We have different data security levels, but if the partner, let's say ChatGPT.com is only approved for data security level, say two.

But if the user says, okay, fine, I want access to ChatGPT.com for my application, but I'm gonna send data security level four.

It'll deny that. It'll deny it.

That because it's gonna be like, Nope, ChatGPT is not allowed to receive data security level three or four. So I deny access, I deny this request of yours. Or if we also ask them, are you planning to send merchant data or, consumer personal data? Yeah. Et cetera, et cetera. And if that application or if that partner is not approved to receive it, deny access.

So not only are we ensuring that the application can talk to only approve the partners on the internet, but also only approve the data levels and data types can be shared with them.

Ashish Rajan: Hello, welcome to another episode of Cloud Security Podcast. I've got Ramesh here with me. We're gonna talk about something really interesting.

Ramesh, actually, before we start, Ramesh, could you give a 30 second intro about your professional journey? How'd you [00:01:00] end up where you are today?

Ramesh Ramani: Yeah, absolutely. Gosh, where do I start? It's been like about 17 years in total. That I've been in this domain I started off as a network engineer and and then right after that I pivoted into network security, and then I pivoted then into designing and architecting data centers.

Oh, this is not just from a security standpoint, but also from a virtual machines hosting storage. Everything. So I, I moved into that that gave me a really good understanding of what systems are like. So that was like a great learning experience. And then that's when, the entire world in 2016 was pivoting to cloud security.

Yep. And then I was like, yeah, no, it, I need to move out of this. I need to get into cloud security. So yeah, in 2016 I helped build one of the first cloud environments for a pretty big retailer.

Ashish Rajan: Yeah.

Ramesh Ramani: And after that, there was no turning back.

After that it's been completely cloud security and building systems, building applications to secure our cloud environment. And I've been at Block for five and a half years right now. No other better place to like actually dig deeper into cloud security, to be [00:02:00] honest. They give me the freedom to do all of that and yeah.

That's where I'm right now.

Ashish Rajan: And network security would've been an interesting on network in general is would've been an interesting starting point. Obviously today's topic is a whole egress access control. What are the, I guess maybe before we go into what your talk is, and egress control in general is quite challenging in traditional numbers, so just to set the scene.

What are some of the typical challenges people come across with egress control, egress access controls in traditional environments.

Ramesh Ramani: A lot of focus is given to ingress and rightly ingress is the is the point where everyone literally, enters your environment, right?

But ingress and egress have changed over the years, to be honest. Now with regards to specifically and I was actually talking to my mother a few days ago and I was, and she was asking me, what is your talk all about it? And then I was like, look, if a hacker managed to like, enter your system, or if a thief managed to enter a house.

If they can't get out, you've you've solved half the problem there. That's right. Yeah. You keep the locks safe so that they don't enter. But let's say they enter.

Ashish Rajan: Yeah.

Ramesh Ramani: But if they [00:03:00] cannot get out, you've, you've solved that problem right there. That's exactly what egress is, right.

We talk a lot about ingress. Ingress is absolutely essential. Yeah. But what if that's been breached? You want to make sure that no one can get out with your corporate secrets, or any of that stuff. And one of the major challenges today is that people don't look at egress. That's one of the largest challenges.

Yeah. People look at ingress more more often than not. But look, also the other problem here is that egress has. With ingress you perhaps you could have like singular points. Yeah. Egress is not the same. Egress has like multiple points where you can go out ingress. Sure. Yes. Many organizations are now moving to a particular step where now if you're in the cloud, you can control your exposures and then make sure that your ingress, you have like fine you.

You have you. You can try and, map out the path for all ingress. It's not that easy for an egress because now you have to [00:04:00] understand what are all the egress end points? What are the different ways that you can egress? Oh god, the number of ways that you can egress through cloud is unimaginable.

Ashish Rajan: Actually, it's a good point because. Every conversation is, and maybe to your point, because you came from data center world as well, a lot of the started with firewalls. Yes. And I remember I think at least when I started my career, I was working with a lot with checkpoint firewalls. And I couldn't believe, it's funny 'cause one of the reasons I moved on from that to I am or other parts of security was because.

Everything was all about what port number, what door domain. Okay. Inbound. Outbound. Okay. Just only inbound. But even then, I think we were primarily looking at inbound because it was, the whole idea was I'm gonna make a hard shell, like a coconut shell, for lack of better word, that it's gonna be super, super hard to get to, but you end it just super just go, end up whatever you want.

Come out wherever you want. Then it is like not much. Then proxy happened. There's a lot. There's lots that happened after that. Is the traditional challenges that we've had with them, they obviously [00:05:00] open up the Pandora's box for, okay, now that we are there, keep can going any direction. Most people focus a lot on inbound, as you said, there's firewalls, WAFs, all kinds of stuff that people talk about and throw in egress controls.

Does that get even more complex in a multi-cloud environment? We were talking about this the other day as well, about. It's not just one business. There's multiple businesses, people acquire, there's M&A, there's all of that as well. Now you're bringing other organizations. Yes. Like these days, the complexity to what you are talking about from an outbound connectivity, it, you're just like, you may think you have made a baseline, right?

But someone else comes in and go, actually we have our own baseline. There's another one at the baseline. What's been your, the trigger point for you to go, okay, I need to, like traditional approach would've been, Hey, by exception? But you didn't choose that path, right? Why? Why go down the path of, or automating this kind of a thing.

Ramesh Ramani: Yeah. Look, this is something to be fair what happened is that I was working okay let me a short story, right? Yeah. I started off at Block as Block's first cloud security [00:06:00] hire. And then right after I was, I joined Block, I became a Kubernetes security engineer.

Ashish Rajan: Right.

Ramesh Ramani: I was actually helping our entire build out Block's first Kubernetes platform.

Square's first Kubernetes platform. We only had Cash, which had their own Kubernetes platform, but it was Square's first Kubernetes platform was, it was a huge platform. And whether I helped the team build something known as a network policy application.

Okay. So what the network policy application would do is that it would automatically pull out egress dependencies sorry, our S2S dependencies. Yeah. From a centralized tool.

Ashish Rajan: Yeah.

Ramesh Ramani: We would pull that information and then we would go ahead and deploy network policies at each namespace level.

Ashish Rajan: Oh,

Ramesh Ramani: okay. Now, because I helped with this like about, about in 2023 December I came up with this idea. I was like, okay, fine. We did this for Kubernetes, for S2S dependencies. Why not just expand this for all of egress? Yeah. And all across Block. So then I did a POC and then I think management liked it.

Very [00:07:00] supportive manager and the infrastructure leads, infrastructure security leads. And yeah they really liked the idea and we thought, okay, fine, because look, Block is in a unique place because we have sources of truth for everything. Oh, okay. For lots of things, we have a source of truth for all our applications, right?

We have a source of truth for all our partners. It's just about bridging this gap. You bridge this gap and knew that we could solve for this problem. Okay? So that's how it started. And I was like, okay, we have the source of truth for both. Let's bridge this and enable this as, a singular solution that all users across Block can use.

So that's how it came about.

Ashish Rajan: Ah, okay. 'cause most organizations are primarily stuck at the, the source of truth part? Yes. Because yes. Okay. That's where, because I'm the, I was, when I, when we were talking about this the one thing that kept coming to mind was like, but how do I know that Ashish requested access to an application to be going out to the internet or the specific port on the internet to specific domain.

And now with the AI and stuff as well. It could be like, is he going to. And as [00:08:00] much, I don't think DeepSeek is that problematic. But if that was a case as a risk posture for your organization that hey, we don't want any AI domains to be accessed from here, which is again, an egress problem.

How do you manage that across 'cause people are using proxies, whatever, to, to what you said here, it's definitely interesting. How did you expand that to the broader organization? And is that more from a compute perspective because you already had the source of truth? Or was it more from a, like the traditional I know the firewall rule, I know the inbound.

Like what was the approach you took to start bridging the gap and using that to expand onto, hey, how do we do egress access control at scale?

Ramesh Ramani: Yeah, look first off, I wanna make it clear that this egress access control is specific to production environment. Okay. Not for laptops. Okay. So because laptops is probably a different problem altogether. Yeah. Egress from there is, you have like local proxy clients, et cetera, et cetera. That's not this, but this is specifically for applications and production, talking out to the internet. Yeah. That being [00:09:00] the case, essentially, like I said, these sources of truths.

Ashish Rajan: Yeah.

Ramesh Ramani: It sometimes plans just work.

Ashish Rajan: Yeah.

Ramesh Ramani: You know you come up with a design and it just so happens that stuff clicks. So that's essentially what happened over here because like I said, this, these sources of truth were there.

Ashish Rajan: Yeah.

Ramesh Ramani: And then I was like, okay, fine. We need to build a system which bridges the, there's gap, but the biggest problem was how do we identify applications?

Yeah. Yeah. The, what you spoke about if Ashish wants to access a particular application out on the internet from production

Ashish Rajan: Yeah.

Ramesh Ramani: For an application that they own, how do we identify that application? 'cause there are, that application can now live in AWS

Ashish Rajan: Yeah.

Ramesh Ramani: Can now live in GCP, can now live in our data center.

Yeah. And now AWS we have certain environments which might have for example, Kubernetes.

Ashish Rajan: Yeah.

Ramesh Ramani: Now our Kubernetes platform will have a particular type of egress.

Ashish Rajan: Yeah.

Ramesh Ramani: Now our cloud environment will have a particular type of egress, native services, like for example, EC2 Lambda and stuff like that.

And then now you have data center. Yeah. It has its own egress. You have firewalls and our own servers. Like software firewalls. Yeah. They have their own [00:10:00] egress parts. So the idea was like. This can get really messy. This can get so messy that at any point in time and look, here's another problem, generally organizations today, go ahead and they've shifted left for egress access. Yep. Yeah. Which is a great thing to do, right? Where now users, if they want their application to reach out to certain applications on the internet, users go into that repo and then say that, this is my application.

I need access to this. It's a GitHub's fashion. It does not scale at this scale. At Blocks scale. 'Cause now you have these vast different environments.

Ashish Rajan: Yeah.

Ramesh Ramani: Do users now go into, like GitOps style for each environment? Ah, that's gonna be crazy, right? Yeah. And for us to maintain governance over all of this

Ashish Rajan: Yeah.

Ramesh Ramani: Is crazy. So how do we ensure that any application at prod can go ahead and talk to something out on the internet by centralized governance.

This is where we use our application identity, which is SPIFFE

Ashish Rajan: IDs.

Okay.

Ramesh Ramani: [00:11:00] SPIFFE IDs basically provide us this rich context of an application about an application where it exists, which business unit.

Who are the application owners?

Ashish Rajan: Okay.

Ramesh Ramani: Which region? What infrastructure.

Ashish Rajan: Yeah.

Ramesh Ramani: What more information do you need? Yeah. All our system now does is it's now bridged this gap got the information about the application. It knows where the application exists, and it knows for that business unit what is the enforcement endpoint.

And that's it. So long as we maintain that mapping of application to domains. Problem solved.

Ashish Rajan: So the person requesting for application access, you have the source of truth for the application.

Ramesh Ramani: Correct.

Ashish Rajan: And you have the enforcement point as well, correct. What happens to exceptions?

Ramesh Ramani: What, so in this case, there is no such thing as an exception.

Here's the thing, and here's the beauty of the system, right? Earlier on users would need to request access to certain domains, and they were not treated as exceptions. Because if you need access to a domain, you have access to a domain. That's it.

Ashish Rajan: Yeah.

Ramesh Ramani: There's no rolling back [00:12:00] after some time. There's nothing to say that, okay, fine.

This is a risky domain, so you cannot send it. Even if you do want to send it, you can only send it for a particular amount of time. For example, there might be legitimate use cases for something like pastebin, right?

Ashish Rajan: Yeah.

Ramesh Ramani: Some bad from production. Yeah. But there might be legitimate use cases, so you need to have exceptions for that.

We thought about all of that and we were like, and we already had a system in place. Our centralized source of truth users would go into that centralized source of truth and say, my application needs to talk to this domain. But there was no way to actually confirm that the domain is a legitimate domain.

Oh yeah. If the domain is from an approved partner. Yeah. And if this particular, and this was only for one system. Yeah. And then we had like many such systems.

Ashish Rajan: Yeah. So I think, so you're talking about the the number of systems that went out? 'cause the way I see this as well, one of the biggest challenges a lot of people have is even with the cloud security alerts and stuff as well.

Very. Which is, I know it's slightly day waiting from egress control, but essentially if the challenges people had there was they didn't know who the owner was. Yes, absolutely. But with your SPIFFE id, [00:13:00] sounds like you have an understanding of what the application is, who the owner is. Yes.

What the enforcement point is. So going back to your Kubernetes statement or even a VMware or virtual machine, or serverless, regardless, they're all mapped. They're all mapped. So at least from that perspective, you're able to quickly make an assertion for. Okay. If there is an exception of there was gonna be an exception, it should have already been in there.

Yeah, absolutely. Yeah. Because we would've accounted for that at some point. Correct. What about retiring some of those or, 'cause I imagine systems go up and down, or not just going up and down, as in availability born the context of, oh, now we move on to containerised, we don't use virtual machines anymore.

So what happens in those kind of scenarios? Or does it still stand as,

Ramesh Ramani: that's a really good question. So at that point in time, what happens is that those, the SPIFFE IDs will be retired. Okay. So like I said, we have a centralized source of truth, which is known as registry. And this, it maintains a catalog of all our applications.

And it's the one that minced the SPIFFE IDs as well.

Ashish Rajan: Yeah.

Ramesh Ramani: It minced the SPIFFE ID. So our system over here, which is the that [00:14:00] we built right now, the egress access network, egress access system pulls from that source of truth.

So when a user goes ahead and requests access to a domain out on the internet for their application, the system automatically pulls a SPIFFE ID from that source of truth.

And because it's automatically from the source of truth, what happens is that at any point in time, if that SPIFFE ID does not exist, it will it'll be taken out of the system.

Oh, so for example, let's say the infra is say, I don't know just some legacy infra, right? Yeah. And our SPIFFE ID has their infra, but let's say that infra no longer exists. Yeah. That SPIFFE ID will no longer exist. So if the SPIFFE ID no longer exists, then it'll automatically get updated in the system and you're good.

It'll longer get deployed into that area.

Ashish Rajan: So how, okay. Maybe, so now that you've explained what was the method to solve the set scale? How does one request access to Yeah a new egress. Yeah. A new outbound.

Ramesh Ramani: Absolutely. So like I said, we have like multiple business units, right? Yeah. One business unit [00:15:00] goes to a source of truth, for requesting access.

Yeah. Yeah. Another business unit users go to another and they request access. Yeah. And then there are others where it might not exist, right? Whatever. Now we just have a centralized UI. Ah, okay. It's just one singular UI right Now, users would go to that UI. Yeah. And then in that UI they will say they will search for the domain.

Yeah. say ChatGPT.com. Yeah. They search for that domain over here in, in our new system, domains and IP addresses are first class objects. Which means we treat them, we treat them in a way that they require. Maximum sort of security.

Ashish Rajan: Yep, yep.

Ramesh Ramani: The way that, because we made it first class citizens, we're now able to do interesting things about it.

So now what happens is that because we have a singular UI, users just go and search for that domain. Once they find that domain, then they request membership to that domain.

Ashish Rajan: Ah, okay.

Ramesh Ramani: So it's like group, it's like a group management system. Yeah. Let's say github.com is a group.

Ashish Rajan: Yeah.

Ramesh Ramani: And let's say that's a file maintained in a repository.

Ashish Rajan: Yeah.

Ramesh Ramani: Written into github.com [00:16:00] file will be the SPIFFE IDs for each membership request.

Ashish Rajan: Yep. Yeah.

Ramesh Ramani: If it is approved.

So user go into that UI. They find ChatGPT.com. When they search for it, they're like, okay, fine. I found it. Click on it, go into it. And they type in their application name.

Ashish Rajan: Yeah.

Ramesh Ramani: The system will automatically populate it because it's connected to our application source of truth. Ah, okay. So you just type in the name of your application, it auto-populates.

Ashish Rajan: Yeah.

Ramesh Ramani: And then you say, okay, fine grant me membership to ChatGPT.com.

Ashish Rajan: Yeah.

Ramesh Ramani: Not before defining what type of data you want to share with ChatGPT.com?

Yeah, I was gonna say, we are gonna clearly say, we are going to ask the users what is, what data security level you're planning to share with ChatGPT.com and what data types are you going to share with ChatGPT.com. And our second source of truth kicks in over here.

Ashish Rajan: Yeah.

Ramesh Ramani: Our second source of truth is our source of truth for all the partners.

Yeah. It has clear information about what data security levels they are approved to receive what data type they're approved to receive.

Ashish Rajan: Yeah.

Ramesh Ramani: These two sources of truth, this [00:17:00] system bridges these two and then says, okay, fine. When a user says I'm going to send DSL level, we have different data security levels, but if the partner, let's say ChatGPT.com is only approved for data security level, say two.

But if the user says, okay, fine, I want access to ChatGPT.com for my application, but I'm gonna send data security level four.

It'll deny that. It'll deny it right there because it's gonna be like, Nope. Chat GPT is not allowed to receive data security level three or four. So I deny access, I deny this request of yours.

Or if we also ask them, are you planning to send merchant data or consumer personal data? Yeah. Et cetera, et cetera. And if that application or if that partner is not approved to receive it, deny access. So not only are we ensuring that the application can talk to only approved partners on the internet.

But also only approved data levels and data types can be shared with them. So we are centralizing governance. Yeah.

Ashish Rajan: Yeah,

Ramesh Ramani: absolutely. [00:18:00] Centralizing governance and I think this is where our system shines. Which is, I don't think, I'd love for your audience to tell me, and this is not the case, but I don't think any company out there makes sure that this level of granularity is maintained in the sense that application A can only talk to an approved partner out on the internet and only approve data types and levels are sent. So this is intentional data is matched against, approved, whatever the partner is for. Yeah. If they do not match, deny access.

Ashish Rajan: So every time a new application is being mapped into the system, there is a data classification being added as well.

Correct? Yes. Because that was gonna be my next question about how do you manage the data access parameter, if you wanna use that word for this, in terms of what kind of data goes in, whether it's data leakage, there's so many things that are like with the re part. Yeah. A lot of people when, and in my mind when I think about outboard control.

A lot more of that is more from a hey, data breach perspective, like example you gave about talking to your mum about the story. But a person can come in if [00:19:00] they, for some reason, whatever mis mistake happened and they got in, the ultimate goal for them is to take out the data. Yes.

That's C2

Ramesh Ramani: access data.

Exfiltration. Yep. Yeah, absolutely. So

Ashish Rajan: that's where I'm like, oh, okay. If you're able to do a automation for outbound man access management. So the sounds like the basic components that people need to build on that would be having a source of truth. Source of truth, absolutely. Application, yes.

What kind of data level that can have. And the other part was the domain that they want to access. Correct. The partners, the partner, source of

Ramesh Ramani: truth, our partners as well.

Ashish Rajan: Source of truth your partners as well. Yes. And you bridge that gap to identify through a self-service portal that Yes.

Which the security team build the secure the Yes,

Ramesh Ramani: yes. My team, we, oh,

Ashish Rajan: vibe coding or everyone's coder.

Ramesh Ramani: No, I look, we have an absolutely great team out there which is no, which is a part of the infrastructure security team. Oh, the infrastructure security team, we have like multiple teams within it.

Yeah. Yeah. And we have a great team who over they're known as the ID identity infrastructure team. Yeah. They're the ones who own the source of truth for [00:20:00] all our applications. And they're the ones who who help build the backend for the bridging system or the network access system.

Ashish Rajan: Oh, that's awesome man. Yeah.

Ramesh Ramani: And then we have another team which owns the partner source of truth.

Ashish Rajan: Yeah.

Ramesh Ramani: So it's essentially like multiple teams within infrastructure and outside infrastructure who came together to build the system. I'm from the network security team. Yeah,

yeah. Yeah, I was one who bought, brought these teams together to do this.

But yeah, it was, without the infrastructure teams help, none of this would've been possible. Yeah.

Ashish Rajan: Wow. 'cause I think it's funny the reason why I ask that question is because a lot of times where these kind of stop is the network security would have to go down the GitHub path that you mentioned.

Yes. It's a very common approach. I have spoken with so many people I know. 'cause it's what else can we do? It's usually the second thing comes out okay we are trying to automate it, but let's just take it to a place where developers know and understand what it is. Yes. So they create a request.

Yes. A pull request comes in, I approve it. But to your point. Now times that beds 500, 600, then you just have one person full time sitting and approving or rejecting approves as well. Correct. And trying to validate, hey, what kind of data type should I be [00:21:00] allowing for? Yes. Is there a policy for this nor, this is so much involved with this, which is not,

Ramesh Ramani: which is why we, which is why bridging these two was like the best thing we could do because we were like, at that point in time, we don't need any people to be in the picture Yeah. When users go into the centralized U and request their access. Yeah. Also, it's not a, we provided a UI to users unlike GitHub. Where in GitHub it's more of a GitOps actions.

Ashish Rajan: Yeah.

Ramesh Ramani: Whereas over here, the way is that when a user requests access the identity infrastructure team built this backend in such a way that essentially any access requests have to be approved both by the system and by owning team members.

So if the system essentially does a validation

Ashish Rajan: Yep. Yep.

Ramesh Ramani: For the type of data that you are declaring that you want to send. That's correct. And if it doesn't match, it denies the access. But if that's good, a team member of the application owning team has to approve it.

Ashish Rajan: Oh, okay. It's like Git

Ramesh Ramani: yeah. In git, like you have a team member who has to approve that request. Something like that. They have to approve that request. But all of [00:22:00] these automated actions, we couldn't, we could have done it in GitHub, but we chose not to do it. We figured we'll give a UI to users because now we can put all our governance policies, we can create governance policies around it.

So singular governance. Yeah. And then because we have this singular governance, we can go ahead and do other interesting things of, seamless deployment everywhere else.

Ashish Rajan: Interesting. And how does it deal with, so to your point, SPIFFE ID, everything. Now we'll bridge the gap. But most people to what we were saying earlier, they have a mix of compute as well.

Yes. And Kubernetes has always looked as a data center within a data center. They talk about namespace earlier. A lot of people would not even know what namespace is like having at the end of this conversation. But in terms of the different types of requests are coming in, is it because everything is a network level request?

That's why it's you're able to make the same change so easily across all kinds of compute? Yes. Yes. Because it doesn't matter what the compute has done. Yes. It just, it's asking me for network access. Yes. Which is a standardized protocol. Yep. So I, all I [00:23:00] need is, oh, network connection to port, plug, whatever.

Yes. 5, 1, 5, 6, 7, 8. Yes. And Oh, okay.

Ramesh Ramani: So here's the thing, right? So there are two things that happen within this system. A user goes in searches for chatgpt.com or github.com. Yeah. Let's say they find it. Yeah. And then they have their membership, their application owners requesting membership to it.

Ashish Rajan: Yeah.

Ramesh Ramani: That is how, they become a member of that particular application and they get that access granted.

Ashish Rajan: Yeah.

Ramesh Ramani: But let's say chatgpt.com does not exist, or github.com does not exist within the system. But remember, these are first class objects.

Ashish Rajan: Yeah.

Ramesh Ramani: They, we empower the users to now go into the system and create the domain.

Oh, okay. If the domain does not exist, github.com does not exist or chatgpt.com does not exist. We ask them to go ahead and create the domain, and then the system does the validation again, because we have our source of truth for our partners. Yeah,

Ashish Rajan: Yeah.

Ramesh Ramani: Now the system is able to say that, okay, chatgpt.com belongs to a partner because the system knows it.

Ashish Rajan: Right.

Ramesh Ramani: The system knows that chatgpt.com is there in our it's Open AI.

Ashish Rajan: [00:24:00] Yeah.

Ramesh Ramani: Is an approved partner within our source of truth for partners.

Ashish Rajan: Yep. Yep.

Ramesh Ramani: And it just bridges that, it makes a call to LLM.

Ashish Rajan: Yeah.

Ramesh Ramani: Checks to see that if chatgpt.com does in fact belong to Open AI.

Ashish Rajan: Yeah.

Ramesh Ramani: And it checks with the system to see if charge jp.com is approved to receive this type of data.

It does the validation and what about Subdomains? Subdomains as well. Every domain is unique. You mentioned ports and protocols, et cetera, et cetera. When they go ahead and create github.com, they have to fill out certain metadata. Yeah. They have to say github.com. What is the port number?

Okay. What is a protocol number? Yeah. And what is a product ID? The product ID is the unique identifier and a source of truth for partners. Oh, okay. That's

Ashish Rajan: how it knows. So

Ramesh Ramani: openai.com will have a product id.

Ashish Rajan: Yep. Yep.

Ramesh Ramani: And so the system knows that. That's the product id. So users have to go to the source of truth.

Ashish Rajan: Yeah.

Ramesh Ramani: And enter the product ID for Open AI there. Interesting.

Ashish Rajan: And that's

Ramesh Ramani: how the LLM and the system knows that ChatGPT.com should belong to openai.com and it's an approved partner.

Ashish Rajan: Yep.

Ramesh Ramani: [00:25:00] Yep. So the interesting thing is, you spoke about AI right? Now, let's say, we have all these systems which maybe need out to need to reach out to, say Databricks

Ashish Rajan: Yeah.

Ramesh Ramani: Or Snowflake or whatever, right? Yeah. These AI processing platforms. You need to have tight control or type of data that you're sharing as well, because your models can also change.

Ashish Rajan: Yeah.

Ramesh Ramani: And how we are ensuring, and this what I was talking about, AI and when we are sharing data with these different AI processing platforms like Snowflake, Databricks, et cetera, et cetera, right?

Not just that, even LLM.

We want to make sure the type of data that we're sending out is the right type, is the right type of data. Let's say for example. Inadvertently we share secrets over here. Yeah. We wanna make sure users are purely aware of the type of data these partners are approved to receive.

Yeah. Where do they go and find that? That'll be our source of truth for partners. They go into that source of truth, which is known as a Block software list, which is our catalog of all our partners. And over there they would go ahead and say that. They would look at it to say, oh, [00:26:00] chatgpt.com, OpenAI is allowed to receive DSL data level three. Not four.

Ashish Rajan: Yep.

Ramesh Ramani: Or they're allowed to receive only, application type data. No merchant data, no customer data, no customer personal data, et cetera, et cetera.

Ashish Rajan: Yeah.

Ramesh Ramani: So the, we are not empowering users to, put the right information, but they're also validating.

Ashish Rajan: That's pretty awesome. Because I was gonna, I had so many questions about the AI part, but they got answered with the whole data. 'cause I think the majority of the risk in that context is in a lot of ways sold by the network access control and the kind of data that you're allowing. Identity can, if you can't even get out then, I mean you can really don't need to put that in the picture.

Was there a technical challenge that you came across as you were building this or having a source of truth made it an easier switch?

Ramesh Ramani: Oh man. The source of truth made it an easier, actually, to be honest. Like I said, not too many not too many organizations out there have a source of truth for their applications and a source of truth for their partners, right?

The source of truth is what enabled all of this, to be honest. We've always had this issue where we weren't able to, solve for the [00:27:00] challenge of how do we ensure we are only talking to authorized partners, approved partners on the internet, and how do we ensure that we're only sharing the type of data that we should be sharing with them?

These are two separate problems. Yeah. Security to make sure we're only talking to approved partners. Yeah. Compliance to make sure that we're only sending data that we are supposed to send. That's right. Yeah. This was our biggest challenge.

Ashish Rajan: Right.

Ramesh Ramani: I didn't think the challenge was to go ahead and deploy policies everywhere.

Okay. I did not think that was a problem. I thought this was the bigger problem to tackle. And like I said, the infrastructure security team and the infosec team, they, they help, they helped us out with this. Yeah. Yeah. So we realized that we have these sources of truth.

I reached out to them, made up a plan design architecture, and they were, all of us came together to actually do this and then look to pick up biggest challenge. We, InfoSec teams can do so many things. Yeah. But the eventually it, we put this in the infra team stack. Yeah. And we need buy-in from them.

Ashish Rajan: Yeah, of course. It's a huge Of course. Yeah.

Ramesh Ramani: Because we're [00:28:00] buy in. None of this infosec can do so many things and then infra teams will just say, Nope.

Ashish Rajan: Yep, yep. It could happen as well. Yeah.

Ramesh Ramani: Yeah. The way that we actually solving for this problem is by making sure that, we don't even have to like, trouble them.

Oh, okay. The way that we're doing this is that let us assume. Simple example, we have an existing system which say pulls this information and deploys it into, say, some proxy.

Ashish Rajan: Yep. Yep.

Ramesh Ramani: We do have that right now, pulling it from a source of truth and deploying it into a proxy.

Now lets say we replace that source of truth with ours.

Ashish Rajan: Oh, okay. Yeah. Yeah. Yeah, that's right. Done. Not, that's it.

Ramesh Ramani: This is how we, this is so we are not telling you, we are not telling the infra teams, Hey, we will go ahead and directly and apply this as a policy within your system. But because infrastructure teams may not be super happy with that. Yeah.

They're like, we don't want you deploying this. Yeah. It might mess it up Instead, whatever that current source of truth is where they're pulling API. Yeah. For their application to domain [00:29:00] access that source of truth. We are replacing it with our source of truth.

Ashish Rajan: That's right.

Ramesh Ramani: Because our centralized system now maintains application to domains.

Ashish Rajan: Yeah.

Ramesh Ramani: Mapping in a central repository, their repository we're replacing with ours.

Ashish Rajan: Oh.

Ramesh Ramani: So they pull it from us. So now every user gets the same ui. Yeah. What whatever they request it goes and sits in the same backend, which has been replaced now.

Ashish Rajan: Yeah.

Ramesh Ramani: So the infrastructure teams can pull from this new database and deploy the policy.

Ashish Rajan: And to your point, that's what makes it sure everyone is in sync as well. Yeah.

Ramesh Ramani: Like our major platforms I don't think they would, maybe they will in the future want to directly create their own lightweight modules, which can go ahead and deploy it.

Ashish Rajan: Yeah.

Ramesh Ramani: But for the time being, if we want the entire company to be onboarded onto this.

Ashish Rajan: Yeah. Yeah. If

Ramesh Ramani: we want the entire company to be on board on this, we wanna make sure the infrastructure teams are not burdened.

Ashish Rajan: Yeah. Yeah.

Ramesh Ramani: And the way to do that is just by presenting the same data to them, but this data is now hooked into our system instead of their system.

Ashish Rajan: Yeah.

Ramesh Ramani: So now that's how we're bringing everyone together

Ashish Rajan: because I think the interesting part over there as [00:30:00] well as you mentioned, is a lot of the times, a lot of the conversation that you'll have stops as a part that, hey InfoSec we did so much.

We have engineering, we have done all of this. But now the moment you try and get the non-security and the buy-in, that's where, and to your point probably is because it is a lot of ask. 'cause they already are doing a lot of things. They already have systems and everything around it. So they have to, wait, so you want me to stop what I'm doing and now do this thing?

Exactly. It's a big ask. Yeah,

Ramesh Ramani: it's a big ask.

Ashish Rajan: And that's where a lot of people went down the GitHub path as well, because that's the easiest way. Oh yeah. It's already in place. It's just another request. So people are like, okay it is very interesting. I wonder how many people would be challenging their current thinking about GitHub and all that.

So maybe the next question that I have is then organizations that are trying to implement this are the people who are listening to this belong I don't know, identity team, infra team, wherever. What is a good starting point to start implementing this in their organization as well?

Ramesh Ramani: Like I said, I mean we're lucky at Block because we have these two sources of truth start a source of truth first.

I would highly [00:31:00] recommend that please have your source of truth. This is a tough thing. This is a tough ask. Yeah, that is. That is a big ask, is a really big ask for organizations. Block, we are in lucky place with Block with regards to this. Yeah. But yes, you need to have two sources of truth, a catalog of all the applications that you have, and a catalog of all the partners that you have approved.

Ashish Rajan: Yeah.

Ramesh Ramani: So you need to have these two things. If you had these two things, I think it's easy to build a system.

Ashish Rajan: Actually that just made me think of something else as well. If a partner has been compromised, I'm just gonna call, I don't know. Just use whatever example. Any good question. I see where you're going with this.

Okay. Yeah. So what happens to all the exceptions that have been already put across for the beginning of time?

Ramesh Ramani: Very good question. Think about, so this is something that I spoke about during my talk as well, right? This is another place where our system shines incident response. Yep. Let us see a particular partner comes up to us and says.

Hey, my particular product, not the entire vendor. Yeah, but a particular product, yeah. For that vendor has been compromised. Yeah. Now we have full information about every single application that is [00:32:00] talking to this partner, to this product.

Ashish Rajan: Yeah.

Ramesh Ramani: Salesforce as an example, let's say Salesforce is a vendor.

Yeah. Salesforce has tons of services and product, right? Yeah,

yeah. Let's take Slack as an example. Slack now belongs to Salesforce, right? That's right. But Slack is its own product. Yep. So let's say, just an example, right? Yeah. Let's say Slack comes up and says, Hey, we have been compromised.

Ashish Rajan: Yeah.

Ramesh Ramani: The domain is gonna be api@slack.com. That's right. As an example. Yep. So just that product has been impacted not all of Salesforce. That's right. Yep. And our system knows that. Our system knows that Slack is a product.

Ashish Rajan: Yep.

Ramesh Ramani: And Salesforce is the vendor. Yep. So now we are able to immediately, our system network egress access system gives us full visibility into all the applications that have access to api.slack.com

Yep. And now we can assess risks accordingly and turn it off as well. Absolutely. A hundred percent Interesting. It's just as simple as just removing the SPIFFE ID from the membership done

Ashish Rajan: also, and then trigger, it triggers a workflow, which basically takes it off

Ramesh Ramani: it. So the workflow, so it doesn't trigger a workflow.

So this, so again, this is where we are slightly [00:33:00] different from GitOps, right?

In GitOps, at any point in time you make a change and you push

Ashish Rajan: Yep.

Ramesh Ramani: Only the incremental changes made. That's right. Whereas our system doesn't do that. Our system treats all of these policies as just policies. It's nothing.

It's nothing great. At any point in time we have it on.

Ashish Rajan: Yeah.

Ramesh Ramani: Every 15 minutes it'll pull everything.

Ashish Rajan: Yeah.

Ramesh Ramani: Deployed everywhere. Everything. There's no incremental change.

Ashish Rajan: Oh. Because

Ramesh Ramani: we don't treat it as something extremely special. It's just lightweight component just pulls everything and deploys it. It really doesn't matter.

Ashish Rajan: Yeah, I think that is quite key because a lot of times, and I think this is the way the lifecycle management became a thing of its own. Yes. 'cause everyone's once you've deployed it, you either remove it, but then a lot, there's a lot

Ramesh Ramani: of management mean there's a lot of management overhead.

Yeah. Yeah. You now have to pull that in, check against, what the increment is. Yep. You don't wanna maintain all that. Just pull and deploy. Yeah. Make life simpler.

Ashish Rajan: So what would if [00:34:00] people who are listening to this and they go, okay based on what was shared, it sounds like we need to have source of truth for these things that start there.

Even if it's a third party product or whatever, hopefully API enabled, but whatever the thing may be, use that as a starting point to start pulling. What does that look like from a security policy perspective, egress control, whatever. Now, what would be a, if, assuming they have made the source of truth, what would be different stages of maturity that they can go for?

Because I imagine you just can't suddenly start with 25 applications, and to your point, production applications as well. How do you even start picking the right ones to go for? What's your thinking with, if people are trying to implement this, what could be different stages of progression or maturity they can have?

What's a good starting point as well?

Ramesh Ramani: Excellent question. So the way that we are doing this within our own organization today is we, like I mentioned, we have like multiple systems. We have multiple egress systems as well. Multiple. Again the point of the system is to bring all of them together.

That's right. So we have one system which [00:35:00] essentially puts firewall rules for applications that have don't want to have dependency over our, other egress systems. So it's like a paved path for systems that don't want to have a circular dependency on our existing production proxies.

So we started with that.

And that's a fewer number of applications, say some 10 or 12 applications. All we did is that now we are starting with this, where we've set like a config file to say that for this type of, let's just call, we're calling it the proxy list system. So for all proxy list, here's a config file.

These are all the applications. So at any point in time if a user wants access to a particular domain for. These sets of applications, the system will identified. Yeah, there's all mapping.

Ashish Rajan: Yep. Yeah.

Ramesh Ramani: Where we've also said that we have a mapping for C, we have a mapping for square, et cetera, et cetera, to say that.

For cash. This is the enforcement endpoint for Square, this is the enforcement endpoint for Proxy list. This is the enforcement endpoint. So we started with Proxy list. It's just a very small set of [00:36:00] applications versus cash and square, which is like thousands of applications. That can be a pretty big issue if something goes wrong.

So we start with Proxy list and then we are now moving in, we are now first deploying it to Pro List and then for cash and for for other bigger systems, once this is successful, we know that the same methodology will work there as well. Only difference is that it's slightly better though because the proxiless we're directly going and updating firewalls.

Ashish Rajan: Yeah.

Ramesh Ramani: Whereas for the other systems, we're not updating it directly.

Ashish Rajan: Ah, yeah.

Ramesh Ramani: We instead converting it into a data type or database or data store and giving it to them.

Ashish Rajan: Yep.

Ramesh Ramani: They're pulling from that data store and going ahead and applying it. Ah, okay. So we're not even touching the their end points.

We're just presenting a new data store to them in this format. Yeah. Application, domain format, presenting it to them and giving it to them. So there are different strategies.

Ashish Rajan: Yep. Yep.

Ramesh Ramani: It completely depends on the team. I would recommend starting with making sure that you first deploy this to a small set of applications before you move larger. That's like any other like a staged approach. Yeah,

Ashish Rajan: Yeah. Yeah. And. Would you want the source of [00:37:00] truth to be used by the infra teams before you start doing this? Because you know how, you've mentioned that you want the buying part. Make sure that all works. That's the plumbing, for lack of a better word.

Yes. Correct. Make sure the plumbing works before you start adding applications to it. Correct? Yes. Yeah. Okay. That's for the stage approach.

Ramesh Ramani: Yeah. You need to have your sources of truth.

Ashish Rajan: Yeah.

Ramesh Ramani: Without your sources of truth, you can't do this.

Ashish Rajan: Yeah. And I think it's also probably important to have source of truth from a perspective of making sure that if there was a, new system, old system, whatever. Yes. That kind of becomes a, that, that becomes your source of truth to jump onto instant response and who the owner is, all of that as well. Yep.

Yep.

That's most of the technical questions I have. I've got three fun questions for you as well. Sure.

First one being, what do you spend most of your time on when you're not trying to solve egress outbound access management at scale problems?

Ramesh Ramani: Yeah, man. My kids, I spend a lot of time with my kids and my, and like I, I've mentioned to you before, right? My wife is into compliance and auditing and privacy.

Yeah. So a lot of time we spend a lot of time discussing tech and how compliance and privacy fits into tech. So that's how most of the time I [00:38:00] spend my time either, I go out playing basketball with my kids or, discussing tech with my wife. If not, I'm playing a nice RPG game.

Oh, nice. I like I love RPG video games and I'm now playing oblivion. Oh. Oblivion is an old game that they've now rereleased. Really just playing that right now.

Ashish Rajan: Awesome. And what is something that you're proud of that is not in your social media?

Ramesh Ramani: Oh, something that I'm proud of that's not in social media.

My team. My team the infrastructure security team, they're all rock stars. Super proud of my team.

Ashish Rajan: Awesome. And final question. What is your favorite cuisine or restaurant that you can share with us?

Ramesh Ramani: Oh man, that's too risky. I can tell you my favorite ice cream shop though is a place called Pints of Joy.

It's in the South way. So your favorite

Ashish Rajan: cuisine? Ice cream?

Ramesh Ramani: No. I guess my favorite cuisine at that point in time would probably be like, I'd say Japanese food. Oh, nice. I love Japanese food. But having said that, though, I'm a vegetarian, so it's very difficult to get vegetarian Japanese food.

Ashish Rajan: Oh, I was gonna say, what do you eat as a vegetarian?

Ramesh Ramani: Oh, dude, there are so many. There, there are California [00:39:00] rolls. There are like avocado sushi rolls. Oh, okay. Yeah. Yeah. There are so many vegan options in Japanese food. You're missing out if you have Yeah,

Ashish Rajan: I feel like I'm tempura.

Ramesh Ramani: Yeah. I don't even know. Tempura is is Japanese, please forgive me, but no, it is.

Ashish Rajan: Yeah, and I think the fried stuff basically. Yeah, I think fried is great anyways, but I appreciate you sharing that.

Ramesh Ramani: And, oh, sorry. One more thing. There's, if y'all are in the Bay Area, recommend you go to this place called, known as Ramen Nagi.

Ashish Rajan: Okay.

Ramesh Ramani: Grape. One of the best Ramen ever vegetarian Ramen.

Best vegetarian ramen ever.

Ashish Rajan: You said vegetarian and ramen together. Oh wow. You're saying it really good. Okay. People should definitely check it out and let us know as well. We can people find you on the internet to connect with you and talk more about

Ramesh Ramani: Ramesh. Ramani at Linkedin and on X at SEC mesh.

Ashish Rajan: Awesome. I'll put those links in there as well. But you thanks so much for coming on the show, man. Thank you so much. Thank you so much. Thank you. Thanks everyone for watching as well. We'll see you next one. Thank you so much for listening and watching this episode of Cloud Security Podcast. If you've been enjoying content like this, you can find more episodes like these on www.cloudsecuritypodcast.tv

We are [00:40:00] also publishing these episodes on social media as well, so you can definitely find these episodes there. Oh, by the way, just in case there was interest in learning about AI cybersecurity. We also have a sister podcast called AI Cybersecurity Podcast, which may be of interest as well. I'll leave the links in description for you to check them out, and also for our weekly newsletter where we do an in-depth analysis of different topics within cloud security, ranging from identity endpoint all the way up to what is the CNAPP or whatever, a new acronym that comes out tomorrow.

Thank you so much for supporting, listening and watching. I'll see you next time.

‍