Prahathess Rengasamy: [00:00:00] So CSPMs will let you know that you don't have S3 buckets, but you do have DynamoDB. Your organization is like entirely serverless. So you can focus on serverless security and write security policies for that. And you start with security policies and then you add in the human entity. With respect to acquisitions, right?

From a security team's perspective, you're acquiring the business. You're also getting the revenue and all of that. And you're also inheriting all of their, pretty much all of it. Like any compromise or any security incident there is your incident now.

Ashish Rajan: Have you ever tried scaling cloud security after a merger and acquisition?

You figured out everything you had to do with AWS or Azure, Google Cloud. Now your company goes ahead and acquires another company. And how do you even scale security from there? So in this conversation, I had Prahathess, who has been through this journey multiple times through his experience with Credit Karma, Block and a few other companies where some of the extremes of the security requirements can vary quite a bit. So in this conversation with Prahathess, you'll hear about how do you start the cloud security journey from day one in a big organization starting from absolutely I'll just say foundational pieces of cloud [00:01:00] security of just a CSPM.

Then you're moving on to different stages of cloud security as you mature your practice. And soon that you realize that, Oh, I'm at that stage where a CSPM is just not enough anymore. Now that I have done some acquisitions or different companies, different skill sets, different security teams have moved in.

I have different priorities. Now I need to go a layer deeper than what a CSPM or CNAPP can take me. This is that conversation. So if you're someone who's trying to scale a cloud security practice in your organization, what that could look like from the beginning stages, all the way to using some kind of data insights to figure out what is the best place for me to start working on this, especially after a merger or acquisition event has happened in your organization.

So if you know someone who's actually trying to solve this problem as well, please do share this with them too. And if you are listening to one of our episodes for a second or third time, I would really appreciate if you can drop us a review or rating on iTunes, Spotify, but if you're watching this on YouTube or LinkedIn, give subscribe and follow for more people to know about Cloud Security Podcast as well.

Welcome to another episode of Cloud Security Podcast. I have Prahathess with me today. Welcome to the show, man. [00:02:00] Thanks for coming on the show.

Prahathess Rengasamy: Happy to be here, Ashish.

Ashish Rajan: Could you share a bit about yourself and your cloud security journey, man?

Prahathess Rengasamy: My name is Prahathess. I started off in application security and product security to begin with.

And I transitioned into cloud. I started into cloud doing GCP security to begin with. And I was also responsible for Kubernetes cluster right out of college. First thing that I ran into and I fell in love with it. I've been doing cloud slash Kubernetes security ever since. I've worked at companies of very different scales, like Credit Karma, Chime, Apple, and very recently Block helping them secure cloud infrastructures and Kubernetes platforms as they go along.

Ashish Rajan: How does it scale? In terms of cloud security, how does it scale between, I feel like a lot of people normally start with CSPM and people feel that's the end goal. Take off all the false positives and take off all the alerts and you're done with cloud security.

Prahathess Rengasamy: Ideally, you start off with setting security policies. You need a CSPM first or like CSPM like tool. If you're native to GCP, you have asset inventory that gives you an idea of what are all the resources you use and stuff, so you need visibility into the [00:03:00] services that you use.

The platforms like GKE or like EKS that you have in your infra. And ideally you start with security policies and standards to begin with. And the reason being without the policies and standards, you are flying blind. You're playing whack a mole and CSPMs would be super happy to give you a lot of findings.

And you'll be going after them and getting people to remediate it, but without one set goal and writing down these policies are also like internally good exercise because you understand where the risk is in your infra and security is all about risk communication and risk reduction at the end of the day and defining policies with your risk profile in mind, your threat model in mind gets you along.

That by itself is like a huge security measure. CSPM's help inform that. And CSPMs can be used to write misconfiguration rules that are tailor made for you knowing your risk. You can have a security policy saying that, let's go with the cliche example, no S3 buckets can be public, but your organization doesn't even have S3 buckets.

For example, say they're all in on serverless and DynamoDB and they don't use S3 buckets at all. That policy is not going to serve anyone. And setting [00:04:00] that up and like having whole set of orchestration around it is not going to help. So CSPMs will let you know that you don't have S3 buckets, but you do have DynamoDB.

Your organization is like entirely serverless, so you can focus on serverless security and write security policies for that. And you start with security policies and then you add in the human entity. How are developers getting access to the cloud? So in very early stages, like it's, everyone has access to everything.

And in AWS land, it'd be like everyone has like users and static access keys provision, no SSO yeah. It's even it's 20, 24 almost 2025 I guess. So it's still a problem today. And that because that's how companies start and that behavior is very hard to change. And then you focus on like how users get access into the cloud, and then like with respect to scaling, you'll start looking at networks. What can talk to what? Is dev staging and prod seperated properly or is it all just like one big account that has like everything and is this YOLO testing and production? So this is the point where I'm gonna digress into a second point cloud security [00:05:00] does not scale in a silo.

Ashish Rajan: Oh, okay. What do you mean?

Prahathess Rengasamy: This is true with pretty much any security program, but specifically for cloud security, I feel that it's a bit more important. You need an infrastructure or a platform engineering team that is at a level of maturity that cloud security and the infra slash platform security can work together to establish practices.

At the end of the day, the platform engineering team is going to be doing a lot of the work, meaning the company has all been running in like EC2 instances or GCE instances to begin with. And they're thinking about a Kubernetes platform. So platforms are good in two things.

One, they represent us of risk because a lot of people deploy to there and a lot of applications are running there. You pop it there and like you have a broad impact, but at the same time it's also a huge security event because if you get security right in one place, a good chunk of your applications or good chunk of your deployments are secure.

So your infra teams and the platform teams need to be mature enough to start focusing on broader stuff where you can get a lot of paired path type security.

Ashish Rajan: And you started off with CSPMs as that, Hey, building ground for [00:06:00] policies. Then you landed on identity. How does Ashish get access to AWS, Azure, Google cloud, whatever you have now.

And then the next part after that is now that you've figured out the access part and the policy you need. Now you're not just doing whack a mole. Now you're trying to Think of the bigger picture, which obviously required, like you can't start building IaC security team if the platform team is not doing IaC as well.

Platform team is still working through building a platform and you're like, Hey guys, I want to use Terraform, IaC modules and everything like, ah, too early.

Prahathess Rengasamy: And it goes hand in hand with the platform and the infra team. So cloud security doesn't happen in a silo, its very foundational team across the company. So this has to happen in concert.

That's why I see like most of the scaling issues come into play. Like sometimes like the security teams are a little early. Now you start making Terraform modules and you have all those beautiful patterns and stuff paired paths defined. But folks are just clicks opsing

Ashish Rajan: Actually, to your point, that goes into the account vending thing as well that people talk about as well.

Like the platform team needs to have that baseline for, Hey, as a standard and organization, we [00:07:00] believe that any Google account or Azure subscription or AWS account needs to be created this way. And then your module for security comes in and performance and cost optimization over that.

Prahathess Rengasamy: And it doesn't end there as well.

When you talk about account vending, where a infra team gets into the state of account vending, like we can start vending GCP projects or AWS accounts or whatever, right? Up until that point, we'd have a fixed set of accounts or like accounts that are created, not often, and you'd have security roles in there.

You would have your CSPMs looking into there. You'd have security automation that's in place. Once you start account vending, you need to automate all of your security baseline tools, like IAM roles and like all the other things into those accounts as well. So that's when like you get to scale with the infra teams, right?

Like you have all your security configuration saying that in any new cloud account that we do. These are all the roles I want. These are all the security services that I want enabled. So exactly. That's a very good example of like how a security scales with infra.

Ashish Rajan: See a lot of people go through that as just in time provisioning as well.

And obviously I made you jump onto the whole Terraform modules straight away because there's a self [00:08:00] service just in time provisioning that ends up happening for access as well in between all of this. What do you see for that normally?

Prahathess Rengasamy: So just in time vending of accounts. It's exactly what we spoke about, right?

Like you go, you click a button somewhere in a portal, like backstage or something, and like it provisions an account. The provisioning step has like a security step that provisions the security specific infra there as well. So then you get the visibility into the account right away without having to play catch up.

So just in time access is a whole topic on its own. Just my two cents is that you start with everyone has access to everything by default. Because startups are small, scrappy, everyone needs to work with everything. And then the org grows into a point where there is duties, there is finance teams there's product teams and their individual teams that do not need broad access to everything. Just their product related lane is good enough for them. So at that point is when like you start segregating duties. So for just in time access, like it's still catching up really. So the most mature I've seen people get today in general is you break glass into an admin access or like you request admin access.

And you'll have an [00:09:00] approval process that stamps for you. By default, you have read only, like you can see the console, you can interact with it, you can read metadata and stuff. I shouldn't say read only, view only, where you can see stuff. This is where the state of things are in general, but there are a few crappy, like really advanced cases here as well, where whenever you need access to data, for example, like I want access to my big query dataset.

Yeah. That I formerly did not have access to or it's out of my team's scope, but I need access so that I can do one of things. So you define a role and you also define who owns that role and they become approvers for that. And you can request it and you get time bound access. I don't have permanent access.

No credentials are stored. Like I won't be BQ admin for 25 years or something like that. But I'll be able to edit and work with this data set for one day. That's about it. And automatically the access goes away. So this is the point that we are getting to, but initially I think you need that initial step of putting admin behind an approval process and identifying the roles that individual [00:10:00] profiles use and giving that role as a default so that like you don't get bludgeoned with like admin access all the time.

Ashish Rajan: Most organizations these days, especially that are growing quite a bit and some of them that you've worked for as well in the past, there's a lot of merger acquisition that happens too. It's fortunate for the company, but unfortunate for the security team, sometimes with my last role as a CISO as well, we had a merger acquisition that happened, we acquired a company, became multi cloud in 24 hours basically, and suddenly like we don't have anyone who can look after this.

But in terms of the challenges that people see when they're scaling cloud security and now that they have either acquired companies or they're merging companies, how does the cloud security landscape kind of change?

Prahathess Rengasamy: With respect to acquisitions, right? From a security team's perspective, you're acquiring the business.

You're also getting the revenue and all of that or technology or all of that. And you're also inheriting all of their pretty much all of it. Like any compromise or any security incident there is your incident now. You can go in a number of ways. There are certain acquisitions that are like really mature, where they come in with their own security team.

They've had all their [00:11:00] security practices in place and everything's logged on. And it's it's pitch perfect for the most part, at least. And for those cases, like you're truly happy, like they can manage their security on their own. At that point, like what you're looking at is what are our policies compared to their risk and you're working with the security team there to understand like risks, threat models, and how you can work together.

And then you figure that out. The other cases, as you mentioned, suddenly like you are a heavy AWS shop and all your policies, tools and automations are tuned towards like that one cloud. And then suddenly like GCP is thrown into the mix and which is like an entirely different cloud and the fundamental premise of how IAM works, how our policies work is like very different from anything in AWS.

So at that point, like you're inheriting a lot of risk. And you're at a point where you can't say S3 bucket should not be public or all the EKS instances would have pod identity enabled or something like that. You won't have generic stuff. So you end up having to write generic policies, like there'll be no static credentials.

And what does that mean for GCP? What does that mean for AWS? And you end up having to generalize a lot of your cloud security [00:12:00] policies. And start applying it to the new cloud, which is a lot of work. And if this cloud security team is tailored to its one cloud, like everyone is an AWS security expert, but they haven't worked with GCP, which is rare these days, but that is an issue.

Like it becomes a point of you have to learn what's good, what's bad. And you have to repeat all the processes that you did for AWS into GCP. CSPMs make this a little bit easier. Again, as I mentioned, like for you to scale security there, you need to generalize your cloud security policies. And to the application for that specific cloud.

And that's just the security, your own thought process part. That is the people aspect of it. Often the hardest part of security, in my opinion, where you need to understand how mature their infra is. And probably you are in an account venting state and you have just in time accesses defined for the cloud that you're working with.

Now you have to scale it for the other cloud. Again, they work very differently. And even culturally, they might be like GCP project owner for everyone type of company, which creates friction between your policy and like the state of things. So [00:13:00] it'll be a long tail of things that we need to deal with and a lot of education on the customer front and ensuring that you communicate this very clearly as to what can go wrong?

Why we need this for a thing that didn't exist before? So a lot of communication plus technical work is how like usually mergers go.

Ashish Rajan: From a team perspective, you touched on this as, which is interesting because now that you have two mix of people where you have one side that is AWS specialist, one side is GCP specialist, and you have trying to bring this together.

What kind of team normally works well at scale for cloud security? Do you actually have specialized team for CSPs and they help each other or what have you seen works ideally? And again, obviously you can paint multiple scenarios, but ideally what would be the right path for this?

Prahathess Rengasamy: Yeah. So in my experience, firstly, like not having siloed teams for CSPs make a lot of sense because that's why I spoke about generalizing the policies a little bit, right?

Fundamentally, both the clouds. The requirement for security for both the clouds are the same.

Yeah.

Don't lose customer data. The how and the process of applying [00:14:00] that specific security policy changes. And it's in my opinion, it's always worth the time to invest in like existing folks, like who are not aware of both the clouds to pick up the new cloud, because it's a value add over time and you don't have to worry about silos because ideally you want a very uniform state across your cloud.

For example, like public spanner database in GCP and like public DynamoDB should be the same. Ideally, no public databases. You want to achieve like a very uniform state as a cloud security team. And for that, I'd say siloing doesn't necessarily add too much value.

Ashish Rajan: Interesting. Cause a lot of people feel that I guess the argument that people have is around, should I become jack of all trades or should I just master of one?

Which is hard these days when most of us are working on multi cloud.

Prahathess Rengasamy: True. I completely see that perspective. But as a person who started off in GCP and then moved to AWS, I've seen this happen before. Ramping up on AWS didn't feel super hard for me because the fundamental services that you work with, the concepts were the same.

How is what changed? And you can always pick up the how. You just need to pick up the project, apply your [00:15:00] instincts from like the other cloud and see what equates to that in the new cloud and roll with it. So it would be doable. And I believe like that way you get to see a very generic view of the cloud.

Even if like tomorrow you acquire another company and that becomes Azure, you don't have to build a new team or like a new set of capabilities. You have the general policies. You just tune it to Azure or Oracle cloud and apply the equivalent controls there. And it works with any number of mergers that are positions you would not surprised again.

Ashish Rajan: There could be multiple things to start working on, right? If you have a generic policy and you can just spend hours trying to just build the whole, there's a dedicated team. And lets just say in this case, it's multi skilled. They have various GCP experience and they're trying to build all that. I just throw Kubernetes in there as well.

They have a Kubernetes skill set as well. What was the whole idea behind the whole data driven insight and at what stage people should consider data insights as a start? We should start collecting some data. What was that breaking point for you guys?

Prahathess Rengasamy: The general is policy. And we were sending alerts about our policies to [00:16:00] everyone. And for a good chunk of the teams, the alerts were meaningless because that was a standard operating procedure. They needed that to run their business. And as a central security team, not like an embedded one, like a central foundational security team, you tend to miss out on that context.

What is useful for someone, what is not useful for someone, unless you're meeting with them very tightly or you are collecting that specific data, you do not know. As to answer your question about like, when you should start thinking about it, Earlier the better, like even if there's just three or four teams, more data you collect, more you can have an educated conversation about risk to that specific team.

Ashish Rajan: I think it's worthwhile clarifying, when you say data insights, are we talking about something like a security data lake?

Prahathess Rengasamy: It's not quite a data lake, though, data lake is an essential part of it, right? By insights, what we mean is what are some novel security controls that you can put in place? Or what are some trends that you can observe with say a specific team or a specific org Yeah.

That you can address now that you have the data that you weren't able to before.

Ashish Rajan: But then what are the components of a data insight that you're building? So you mentioned data source as [00:17:00] one. What would be an example of data sources that people should consider?

Because like I just say, on the audience who is either listening or watching this, they recently gone through a merger and acquisition, have a new company. They think they've figured out AWS security, but now they have to figure out Azure, GCP, Oracle cloud, Kubernetes security, all of that.

What are some of the data sources that makes sense to have as part of the insights?

Prahathess Rengasamy: Talking about data sources, pretty much every security team has like a spreadsheet hidden somewhere. Don't tell me that you don't, I won't believe you. CSPM is a very good data source to begin with. For companies that are small and say that hey, we don't have a CSPM in place, you can lean on the existing asset inventory type services.

In GCP, it's quite literally called asset inventory. It's at the org level. You can query what your assets are and start collecting data from there. In AWS, there's config. There is a resource explorer very recently. And there are other native security services that you can leverage to collect security information, particularly cloud security information.

And all of that maps to risk. So this is [00:18:00] generic data available to anyone who's running in the cloud. If you have a CSPM, you get it a little bit more organized. The second aspect of it apart from tools is the harder part. You want to make sure that the data is specific to the team and you want to build context at the end of the day.

The underlying foundation for insights is that you need specific context. Otherwise you're making the mistake of t shirt sizing security findings. But organizations are very different and like teams are very different with respect to the product they work on. So the threat is very different. I'll give you an example at the end of the session, , that means like if you're trying to build context for a specific team or a new merger acquisition company that came in means that if they have a security team, you are working with them.

Otherwise you're working with the infra teams or who are the security conscious there. There'll always be a team or a person who has done security at that other place, right? Like you're working with them to build an understanding about what their business is, what is meaningful to them. And that is very manual.

You cannot automate that probably can help with it, but we are quite a ways from that future where you talk to them to see, what are the services that you use? Like my [00:19:00] CSPM tells me that you're pretty heavy on serverless or you're pretty heavy on Kubernetes. How does your deploy systems work?

Because guess what? Like you have a standard CI CD process. They come in with an entirely new CI system. And their deployments work very differently and say that like you're signing everything in your CI system and they might not have signatures and you might have to put in different controls, right?

So you define these controls and you map them to findings in CSPMs, right? Like CSPMs have a bunch of detections. If not, you can write your own detection. You aggregate that data into some type of a data source. This is manual. You can code it into a system that collects this data and you maintain this foundational data set per business unit.

I gave you an example of one. This can be like four or five. You work with them, you build this ground truth dataset and you have this ground truth dataset separately and you get an information about CSPM. If you're looking into data security and you have a data security tool, you get in data about data security and like you consume whatever security tooling that you're using or the cloud provider provides and that you have access to aggregate all of the data into one source.

And this [00:20:00] would require in most cases writing custom scripts and you layer the foundational ground truth dataset that you created. On to the entire data set that you're collecting from like these different sources. If you can normalize it to a reasonable data format, all good for you. Now you have data security findings that are ground truth laid upon for this specific business unit.

And now you can take it to them and say that, hey, this is the data that we have. You can present the data however you want, Looker or Tableau or whatever the company uses for. presenting and say that, hey, we have these many issues. And out of all of these issues, like we have removed 60 percent of them because they don't apply to you because those are not like the top risk or like threats within your system.

And these are the three critical categories of things that we need to focus on and eliminating that would remove this much risk, right?

And you are suddenly in a position where you can have these conversations with the individual teams. So data informs you on like multiple levels. Yeah. So this is just like the team conversation aspect of [00:21:00] it, right?

Internally within the cloud security team, say that it comes to the end of the year, you want to be measuring performance as to like how you're doing.

Ashish Rajan: Yeah.

Prahathess Rengasamy: And instead of doing like a very generic measurement where the data is a little bit skewed, right? Some teams might not fix their S3 buckets at all or their DynamoDBs at all because they need it.

You can present saying that for this business unit, these were the risks. And this is how it has been trending over the last couple of quarters. And if it's going up, means that something's going wrong and you need to go fix it or need some specific attention. And if it's going down, all good for you.

Ashish Rajan: I think as you described that, hey, I talked to the new team that's joined me in my organization for what's the crown jewel for them.

What's the context that's required. I'm not specifically talking about security logs there, right? I think they'd obviously have application logs. Cause you know how, when you talk to a SOC team, send me all the logs, send me all the security logs, send me some application logs. I've got my SIEM that's going to take after everything.

I feel like the first thing people say is that. They're like, why do you need the logs? And to your point about the tooling is just one thing. [00:22:00] People is the other thing. Like, how do you bring people on board for this journey as well? Because as a senior person on one side, I think something we had to face was there's a whole, oh, are you guys auditing us?

Or was it the other one that I've heard is more like the fact that, oh no, we've got it covered. Don't worry about it guys. What was the way that you approach this to make it more friendly and didn't not sound like an audit, if that makes sense?

Prahathess Rengasamy: The two answers to it. Depends on the company culture.

Some companies are open that way. Some companies like are defensive. The best way to prove value is do a POV quite literally do a proof of value in any company that are going to be teams that you have the best rapport with. There are going to be teams that are super busy for security. The start with the teams that you work really well with, do a proof of value for them specifically, and use that as an example to sell it to everyone.

They had these many issues. They didn't have to fix all of this. And they just focused on this and that reduced their risk by this much. And you can make that a success story and people get on board with success stories really fast. So doing proof of values and not doing it for the [00:23:00] entire company all at once.

It's a really good idea. You want to build those partnerships at the end of the day and starting with the teams that you're most comfortable working with or like that you have a very good relationship with is how I would recommend doing this. Like tooling and data is there. Like just to give you an example of the list of data that you can collect, it's very interesting. It's some of them are not even security. So you want to, for example, like in an acquisition, you want to identify the crown jewel right away. The acquisition has 10 AWS products. You want to assume crown jewel right away. How would you do that? One easy thing you can do is go to AWS cost explorer.

Look at where they're spending the money. Obviously equal amount of money in every account. That'd be very weird. It's going to be like one or two accounts where they're spending like a million dollars or 100, 000 dollars like on something. And that means that you can use that as a proxy metric to assign importance.

Anything wrong with this account is going to be a business risk because we are spending this much. You won't spend this much without driving a lot of business, right? So you can use that as a proxy metric, for example.

Ashish Rajan: The other part to it as a, that's a good example, by the way, of the cost thing.

It's going to compare, find a friendly team that you can work with to start showing the [00:24:00] initial value, then that brings everyone else on board as well. Because, Hey, look at your peer, took advantage of this and that was security becomes the enabler as well in that context. I'll call that out in a developer friendly way as well.

Prahathess Rengasamy: And this is not to block anyone. This is not to audit anyone. This is to better help them because at the end of the day, these insights are obviously like you're looking at detective controls, but eventually you want to move to the paved path approach where even if a developer fails, the default should be secure.

Even if the worst mess up happens. Whatever, the outcome of that should still be secure.

Ashish Rajan: So taking this to the next stage, now that you figured out a team that you want to work with, you obviously have asked the right questions. You figured out the crown jewel. Okay. This is where, in this account, they're spending almost a million dollars.

In terms of the next step of, now I have the data source and I need to do some transformation, some kind of business intelligence tool kind of a thing. That sounds like way out of the cloud security space. Did you have to learn a lot about data security or were you working with a data team. How were you like, making insights happen from the different data sources you had?

Prahathess Rengasamy: Answer [00:25:00] is yes and yes to both, short answer. We had to figure that out a lot. Yeah. And one good thing about like primarily tech companies and like larger orgs is that business intelligence teams exist to inform on product decisions already. They're collecting all those metrics, like user activity metric or like user engagement metrics, and they're processing that already.

So a business intelligence framework. Or a paved path exists. So all we had to do was to take that and use it for security. In our case, it meant that we had to write a lot of, we had to build a smaller platform that aggregates all this data from all these different sources, because they are all very heterogeneous, they are not like come, they come with the standard spec and you can just pull and dump it into a data.

Not like that. So we had to aggregate them via custom scripts and jobs that we wrote, and we had to follow. the existing BI pipeline, which was like something like Airflow get the data and write it to this table in the data lake, as a data set in the data lake, use Apache Airflow type jobs to do [00:26:00] joins on like large data sets.

And we went with Looker, which was what the BI team was using to present the information and figured out queries per organization based off of the context that we got from working with them to surface the specific information that is. It required learning a lot of how data science works to begin with.

Thankfully, like we had an existing paved path that we could use for the most part to achieve this goal. And from my experience, like most companies do have this. I'd highly recommend just using the paved path, that's an entire field in its own and a security engineer trying to reinvent it from first principles is not going to work.

Ashish Rajan: Yeah. So if you have a data team, definitely just leverage them for maximizing this. Just find a project. What are some of the examples of things people can discover if they go through this journey, they've gone through identifying data sources, building some data insights on whatever the companies have acquired or the company that they're looking into to improve productivity or improve where the effort should be spent on security.

Prahathess Rengasamy: This is a step beyond the [00:27:00] CSPM that the CSPM cannot help you with, because like it won't be generic at that point and they can't sell it to anyone other than you. I'll give you an example. This has to be specific to Block.

So if you follow Block at all, Block is the parent company of a whole bunch of startups. Yeah. So to give you two very public examples. So Block owns Tidal. Tidal is a music streaming service. And the goal of a fintech company owning a music streaming service is to enable financial freedom for artists.

So it's in line with the goal, but Tidal is a music streaming service. Let's go to the other end of the spectrum and Block is also very public about Bitcoin and they have a lot of open source Bitcoin stuff. So that's called TBD and it's all cryptocurrency and Bitcoin related. And a good chunk of these infra were all AWS.

So the infra wasn't heterogeneous by any means between these two organizations.

Ashish Rajan: I see what you mean because Bitcoin detection.

Prahathess Rengasamy: Yeah. So you have a public S3 buckets, no public EC2 instances, no public whatever. But for Tidal, that means something very different for TBD that means something very different.

Tidal is a music [00:28:00] streaming service. Meaning they have a lot of CDNs to deliver like very high fidelity audio to the end users. So there is profile there. If you say that you cannot use public S3 buckets, like it's not gonna fly really. And if you take the Bitcoin example, when you say that no public EC2 instance or something like that, it won't work either.

Why? Bitcoin mainnet, the actual ledger that keeps record of all the transactions and occurrences within the Bitcoin network is public. You need to be able to connect to that to enable anything Bitcoin. There are like seven other things that.

Ashish Rajan: Yeah. These are just two examples out of the many.

I think you guys shared a case study in your talk as ell for fwd:cloudsec what was that case study?

Prahathess Rengasamy: Yeah. The case study was like one of the first examples. Like one of the very first things that we had to get insights for, we wanted to eliminate static credentials across the cloud, both AWS and GCP.

And the first thing that we wanted to go after was like GCP service account. Because GCP had like very, AWS has alternatives as well. GCP had alternatives at that point that we had some Terraform modules that developers can use as well. So we wanted to address [00:29:00] that again, like the infra was ready at that point for us to go after this.

So we wanted to know, like how many keys there are to begin with, there are a lot, and how many keys are like admin, have a primitive roles in GCP, like editor or like owner type roles. How many keys were vendor related? Because this is 2024 and there are still some vendors who are using static keys to access your cloud.

Also want to know what these keys are being used for. What is it being used in the CI pipeline or is it like a developer laptop access kind of thing? These were all the questions. And as you can imagine there are a lot of different business units that were using GCP for various purposes. So we had to go ahead and collect this data to begin with.

So we relied quite heavily on CSPM, which was Wiz and cloud native tools, like the cloud asset inventory was also like super useful. And one of the things that we quite heavily relied upon that you can't do anymore is a policy intelligence. Okay. GCP has this policy intelligence API that you can query to get roles and privileges and cross [00:30:00] account access for any IAM entity.

I'm saying you can't use it anymore because like it's moved to the premium tier. It used to be free.

Ashish Rajan: Okay. Fair.

Prahathess Rengasamy: Very recently, January of this year, they moved it to the premium tier. So you can't use it right off the bat without subscribing to them and paying as you go, we relied on all these data sources.

This is just the pure technical aspect, like how many keys there are, privileges there are, whatever. And the soft aspect of it is like, who owns EC and Block thankfully had some type of attribution up until the project. So for any single tenant projects, it was relatively okay to do. For projects that are shared between 25 different teams, projects that were platforms where multiple teams deployed. It became again, like that's where the insights came in. Okay. This is a account that runs a platform, say an ML platform or something. And then you work with the ML team to see like how they attribute which deployment belongs to who?

Because as a platform operating team, you want to know if a deployment is failing and notify the corresponding developer, right? So they have that attribution baked in already. So we collected that information, which was basically done via tagging. So we just had to [00:31:00] look up a very specific tag and map that service account to that user, if it's being used there.

So a lot of very nimble strategies in between to identify who owns what. And we wrote an automation that went ahead, collected all of this data, dumped it into BigQuery in like a standard format. We defined the schema to begin with, because we knew what information we wanted. One of the clear examples is like this key has not been used in the past hundred days.

It's there. Nobody has used it and it was created 20 years ago, something like that, a very long time ago, and they have not rotated it and you're looking for all of this information and you're able to connect between the CSPM, the cloud platform itself, and the specific digging for platforms and attribution that we did.

We're able to collect all of this information. We dumped it into BigQuery, layered in the context information and split it out into like view that where you can see per business unit, per project, per team, how many keys existed? How many keys out of those were had like admin accesses? How many keys out of those were not used in 90 days?

How many keys were like X number of years old? So this is the insights part [00:32:00] that my team helped with. And we had like patterns and to use workload identity federation to move away from service account keys that are defined by our sister team. And they were able to run a campaign to delete all the keys that were in dev environments that are over 90 days old, because nobody's using them.

And we're able to prioritize the keys to delete, keys to work with platforms to change behavior. Because like we ran into this one platform. That was created before workload identity federation existed in GCP. So GCP workload identity federation is still relatively new. If you look at all the docs, everything points to using service account keys by default.

So the platform as an operating procedure had service account keys created for every instance that it spun up automatically. So we were looking at the data and it was like, why is this account having these many number of keys? And we hit up a conversation with them. This is the platform and this platform has existed for a long time.

Identity federation wasn't just a thing. Oh, that's a use case now. And we work with them to get that addressed and start moving to a identity federation that reduced 20 percent of the keys right away. Low effort, high impact.

Ashish Rajan: Fair. That sounds [00:33:00] like a good deal as well, man. And that's also a good example of what kind of metrics can be helpful.

And maybe it'll help you uncover things that you probably would have not thought existed. Which to your point, a CSPM can't help you with. That's a very much more. Deeper level thing in an organization.

Prahathess Rengasamy: And it's a personal thing to an organization as well. Like it varies organization to organization and maturity to maturity as well.

Ashish Rajan: What would be some of the things you will tell your, a younger Prahathess on what would you change if you were to start this again?

Prahathess Rengasamy: If I were to do that again, so for this specific system, right? Like the GCP service account key system. The first thing that, because it was the first type, this insights type of POC that we drove, we reinvented a lot of the wheels.

We weren't using the existing BI systems to begin with and we needed really quick and I didn't have time to go figure that out. So we built the entire system ad hoc and we had to maintain that system. So I would say do not hand roll your data aggregation and presentation layer. If you have a BI team, just go with the existing pattern and they'll save you a lot of time.

Like a lot of time and you have support. [00:34:00] Someone can come in and help you with the stuff that you're not familiar with, which is good. The second aspect of it, this was it's not really a surprise for me, but it was definitely a learning is that data for security is always going to be incomplete. And so one of the questions we got for the talk after the talk as well, we don't have attribution data.

How are we supposed to go figure that out? Sometimes it's just worth, I don't have an answer really, but I do have approaches. Sometimes if you have a central attribution system, of course, lean on it. If not, it might be worth getting a little bit creative about it. If it's all infrastructure as code, look at, get blame for that specific resource.

There are tools like YAR that let you tag infrastructure for attribution. Probably before you get to insights, that's a problem worth taking on. It would be my recommendation, but sometimes like security teams maintain static lists of what belongs to whom to begin with. Just starting off with that would still be useful.

Ashish Rajan: Oh, so I guess your point about attributes is worthwhile calling out what do you mean by attributes in this context as well?

Prahathess Rengasamy: Attribution is just like jargon for saying this resource belongs to Ashish. This resource belongs to Prahathess . Yeah.

Ashish Rajan: Yeah, [00:35:00] like who's the owner or responsible person for this particular business unit or data set. And cause we haven't even spoken about the whole confidential data, different types of data, and there's a, I'm sure that people can add more layers to it as well as they build the data insights.

I guess maybe final question, people need to be data experts for this or, and not just be cloud security people.

Prahathess Rengasamy: You don't have to be data experts to begin with. So the data collection, normalizing and putting it into like data lake or something is like pretty generic work.

The insights actually come from cloud security. You need to be, you need to have that cloud security thinking to determine what applies to whom. Like your expertise is what is being translated into insights at the end of the day. The data collection aggregation part of it is like mostly figured out a problem.

And you don't necessarily have to be, you can pick it up even if the company doesn't have a BI type rule.

Ashish Rajan: Actually, it's an interesting point. Cause you can have all the data, but if you don't know the right question to ask the data set, then what's the point?

Prahathess Rengasamy: Yeah. When I started out about this, I was talking to one of the data science folks that I knew because I wanted to learn as much as I can. This is what they said. If you have the data and you beat it long enough, it'll confess to [00:36:00] anything.

Ashish Rajan: Yeah.

Prahathess Rengasamy: You can play around with the data and have it confess to anything, but you want to make sure that you have the right insights and your own instinct, your own expertise and like your team's policies and vision are what are going to inform the insights at the end of the day.

Ashish Rajan: Yeah.

Prahathess Rengasamy: So you don't have to be a data scientist to figure this out, but you do have to be a pretty good cloud security person.

Ashish Rajan: So that's all the technical questions I had for you, man. I've got some non technical ones as well. What do you spend most time on when you're not working on solving data insights problem?

Prahathess Rengasamy: Probably just like hitting up people from different parts of the company. Really working with, primarily building relationships with other teams is what I spend most of my time on and also like I love mentoring folks. So I try and spend as much time as I can to help someone like probably break into security or like figure out Kubernetes security or things like that.

It's mostly people oriented for me.

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

Prahathess Rengasamy: Over the course of the pandemic, till 2021 and after that, I've become relatively [00:37:00] good at cooking South Indian food. So

Ashish Rajan: Oh, Kaapi and everything?

Prahathess Rengasamy: Everything. Yeah. Anything you want. South Indian. Dosa, Idli

Ashish Rajan: Wow. You can make anything South Indian at home.

Prahathess Rengasamy: Yeah, which we do every day. Yeah.

Ashish Rajan: Oh, wow. There you go. So it sounds like I need to take an invite from you whenever I come on your side of the world.

Prahathess Rengasamy: You are invited anytime you are in Seattle.

Ashish Rajan: I appreciate that. Final question, which is related as well. What is your favorite cuisine or restaurant that you can share?

Prahathess Rengasamy: Cuisine or restaurant? I'm very biased about South Indian food. So cuisine is going to be South Indian. Restaurant is like regional for me, like in the Bay Area, like ID company was good for tiffin items.

Okay, so it's called Idli Dosa Company. So

Ashish Rajan: i'll check it out. So when you say tiffin items, like for lunch?

Prahathess Rengasamy: No, ID company is called Idli Dosa Company. They actually specialize in different types of idli and dosa effectively and a lot of very good tiffins. They are in Fremont we usually end up going there like at least once a week .

Ashish Rajan: Wow. I need to check that out the next time in San Francisco, man. But dude thank you so much for doing this. And where can people connect with you online to know more about these kind of spaces and the whole data insights side?

Prahathess Rengasamy: Totally, my name is very [00:38:00] unique. So Google me and you'll find everywhere I'm at.

Personally, but I'm on Twitter @prahathess handle and LinkedIn are the two social media I use.

Ashish Rajan: I'll put that in the show notes as well. But dude, thanks so much for doing this. And thank you so much for sharing this as well. I look forward to having more conversations with you, man. I think this is going to be fun as well.

So thank you so much for taking the time out and I'll hope to see you again.

Thank you for listening or watching this episode of Cloud Security Podcast. We have been running for the past five years, so I'm sure we haven't covered it. Everything cloud security and if there's a particular cloud security topic that we can cover for you in an interview format on cloud security podcast or make a training video on tutorials on cloud security bootcamp Definitely reach out to us on info at cloud security podcast or tv By the way, if you're interested in AI and cybersecurity, as many cybersecurity leaders are, you might be interested in our sister podcast called AI Cybersecurity Podcast, which I run with former CSO of Robinhood, Caleb Sima, where we talk about everything AI and Cybersecurity.

How can organizations deal with cybersecurity on AI systems, AI platforms, whatever AI has to bring [00:39:00] next as the evolution of ChatGPT and everything else continues. If you have any other suggestions, definitely drop them on info at CloudSecurityPodcast. tv. I'll drop them in the description and the show notes as well.

So you can reach out to us easily. Otherwise, I will see you next episode. Peace.

‍