Geet Pradhan: [00:00:00] This is not a prescriptive solution. Yeah. It is different for every company. Some companies who really need visibility into a particular thing. Yeah. For example, we needed a lot of visibility into our administrative actions on our cloud. So one of the things we decided was like, hey, AWS needs to be number one or number two, or number three, because that's where most of our stuff lives, and we just need to know what's happening. Some teams might say, Hey, we need I don't know, CloudFlare or like network logs, that might be something which they wanna focus on.

Ashish Rajan: Hello and welcome to another episode of Cloud Security Podcast. I've got Geet with me. Hey man, thanks for coming to the show.

Thank you so much for having me. Maybe to set some context, if you can share a bit about yourselves, your professional journey, and we can start there.

Geet Pradhan: Yeah, sounds good. I'm Geet Pradhan, obviously you know that I'm a senior security engineer at Lime. We. For those who don't know what Lime is, we are a micro ability company.

We have electric scooters, electric bikes. It's more for like short term rentals. Do check us out. We're really cool. But be safe about when you use Lime,

Ashish Rajan: wear a helmet.

Geet Pradhan: Yeah, definitely wear a helmet, definitely do that. Prior to this I worked for AON Cyber [00:01:00] Solutions as a security consultant doing a bit of DFIR, doing a bit of advisory and some testing.

Yeah. And. Yeah. And I just really enjoy cyber. Yeah. I think it's a pretty interesting and cool thing to do, especially when people just ask you like, oh, do you know how to hack stuff? Maybe not, but I think there's just more to cyber than that.

Ashish Rajan: A hundred percent. Yeah. And maybe just to take that DFIR lenses a bit more as well.

I think you are, we are gonna talk a bit more about that topic, but I guess I wanna set the plane a bit more for what DFIR is today in the context of cloud and the different kind of complexity different organizations have. How do you define detection response today in your experience?

Geet Pradhan: Oh, that's a great question. And one of the ways that I do the most simplest answer is I think detection response or security operations or SecOps is one of the cornerstones of security right now. Yeah, like detection response, essentially. Hey, you need to be able to. Identify what is going wrong or anomalous or just something weird in your environment.

Yeah. And then responding to it. Yeah. Essentially like it is the cornerstone of security, in [00:02:00] my opinion, because everything that we do is, Hey, something's going wrong and you need to fix it. Yeah. You know what, if you have some products to fix it, if you have services or if you have people. But like it is one of the cornerstones, and I think it's an interesting domain because yeah.

With the complexity of when you went from on-premise to, to cloud, now we have another threat vector with AI and you need to identify different attack patterns on, on how it's deployed internally or externally. Yeah. It just keeps changing. Yeah. But the concept is as simple as hey, you need to identify what's weird and what's not normal.

Yeah. And respond to it. Yeah. And the response can be as complex as we want, can be as simple as we want. But the crux of it, it's just as simple as that. Yeah.

Ashish Rajan: And maybe, and it's also more challenging as a one person doing everything else as well. Oh, yeah. Yeah. So how does it become challenging as a one man unit or one woman unit, or one team also?

What, I don't thinking, trying to think of a word where holding the forward for the entire security Oh.

Geet Pradhan: The [00:03:00] superstars that we have. So yeah. Superstars. I'm thankful that I'm not the only person on my security team. Yeah. We have. Four or five engineers who are really good and have skill sets and different things.

And the way that we have designed our SecOps pipeline right now is a lot of people can, provide that immediate triage, provide that response with a little bit of context, right? I'm not gonna say it's not tough. Yeah. We are, we're still scratching the surface.

There's so much to do. There's so many different sources. And again, being in a company which does like physical products as well as the software side, there's just a lot of things which we haven't covered yet. Yeah. And it's not a why have you not covered it? It's simply yeah, we're, we're getting to it.

Yeah. We decided to tackle some of the top tier or our kind of tier one applications or tier one systems based on not just our priority, but also business's priority. Yeah. Yeah. And we're navigating and moving through that. The building, that detection response pipeline was very, it was from scratch.

So essentially designing that and the talk I actually gave in BSides [00:04:00] was things that I learned, right? Yeah. Like I, I know that there would've been some things that I've done better. Some things that I did pretty well, but now at this stage, going back, I, Hey, this is what I would've done differently.

Yep. Yeah. And it's interesting because one of the things that I've now want to do is go back and redesign it because there are some institutional issues that came up with that pipeline right now. Yeah. Yeah. Which I would not have seen. Okay. And as we decide to scale and add the complexity I think it might even make sense to go back to the drawing board.

Yeah. Maybe not rip everything apart. Yeah. Yeah. But but add some things here and there to make it a bit more scalable.

Ashish Rajan: So as someone who was building the pipeline from from ground to your point, from ground zero. What was something about the traditional methods that don't apply in a cloud world that you found as you were building the detection response pipeline?

Or maybe actually maybe even one step further, how do you define detection response pipeline? 'cause I think a lot of people don't would even think like that. So how do you define that and what does that mean in the cloud context?

Geet Pradhan: [00:05:00] Yeah, so I'll take the first question first, right? How do you define a detect detection response pipeline?

It's. It can be simplified to be like, Hey, what are your log sources? From your log sources, do you have any sort of alerting, any sort of event set up to identify when something is going wrong or weird, or whatever word you wanna use, right? Once you have those sources, once you have what you want to alert on, then what do you do like after that, you have to notify the team to actually perform the actions of response, right?

As I said previously, it's as simple as identifying something that's wrong and responding to it. So in the most basic like bare shell solution of a detection response pipeline, it's that. Yeah. Yeah. Obviously there's more complexity to it with hey, once you add more sources, there's more alerts, there's alert fatigue, there's noise, false positives.

But at the easiest answer I would give to that is you need to be able to set up a way to ingest your logs or ingest your events. Yep. From those events identify, hey, what is malicious or anomalous or something, which it [00:06:00] doesn't make sense. It doesn't add up. And then from there you have to just make sure you give that information to the people who can actually triage it, respond to it. Yeah. And just take a look at it with a final lens.

Ashish Rajan: The end to end flow of the entire process. Correct. Yes, correct. So is there a SIEM playing a role in there as well? Yes. You have log aggregators and all of that

Geet Pradhan: yeah. So going back to what we did yes, I was lucky enough to be given a paid SIEM solution.

There are some open source options out there as well. Yeah. But we got a pretty good SIEM product. And from there it was very easy to set up some of the detection pipeline. Yep. At that time, we had identified, Hey, what are the log sources that we have? And what can we ingest straight away?

Some things like, like for example, Okta Google, they have direct API connections to our SIEM. Yeah. So we didn't have to think about a janky way to figure out where the log sources are. Ah, yeah. But, there is a particular log source so GitHub. Yeah. It's not the worst, but it's not the easiest.

Yeah. So what we did something, we worked with the infrastructure team who handles or owns GitHub [00:07:00] internally, and we set up a kind of export pipeline essentially to put those logs into a particular bucket and then have my SIEM and I think most SIEMs are pretty good at this kind of read from that bucket, right?

Yeah. Yeah. It took a little bit of time and definitely a great learning experience. But it's not hard, but it's definitely not easy when there's no direct connection to the SIEM. And from there, all the sources are in the SIEM, ideally in an ideal situation, all your log sources are being ingested by the SIEM.

Once it's there, you can add complexity and you can add your detection rules there. I would like to talk about like maybe not adding them in the SIEM and the benefits for that and. And why I found it better to manage the rules myself. Yeah. Instead of into a platform. Yeah. And then just from there, having that hey, okay my, my SIEM has all these lock sets.

There's individual alerts set up for maybe one lock set, maybe multiple lock sets together. Yep. Yep. And then just giving that information to people. And one of the biggest learnings on that second half was that. [00:08:00] We're, in a remote workforce, everyone's not on their laptop all the time.

Yep. I don't wanna have to log into my SIEM app to see an alert every single time. I would prefer it if I get it in a different format. For example, what we do is we use Slack internally. We use email internally. We have other messaging, notifications and med messaging solutions that we have. We decided to take a step of Hey, I want to get that to those messages because even if, I'm traveling from A to B and I just wanna see what's happening. I can just open up my phone and see very easily. Okay. There is something and if something needs my attention, I'm, I can just go back and open up my laptop. Ah, yeah. And see it.

Ashish Rajan: Yeah. And would you say that as you explore that a bit more in terms of building that detection response pipeline, whether working log sources are easy to take out from workflow?

So a lot of people are almost always overwhelmed by the where do I start question. Yeah. And the reason I specifically called out that you may not have a huge team you're an [00:09:00] individual trying to build the entire ation response pipeline. Starting from scratch of, okay, I've identified log sources, AWS, log sources, GitHub, GitLab, everything.

Now I put into a SIEM. Traditionally, and this is what I was asking from earlier, traditionally we would just prefer to have it in a SIEM because quote unquote agnostic. But I'm curious to know from your perspective, why was your active choice to not keep that in SIEM? And obviously I got Slack notification became your thing, but is that because of scalability as well, perhaps? Or is it just more that you can add a lot more context if it comes into a messaging system?

Geet Pradhan: That's a good question. So we actually did it the same way that everyone would do it, right? Yeah. We were like, Hey, it's in the SIEM, we'll just push those messages to whatever notification platform.

Yeah. Yeah. Directly. Now, what I learned there is I needed to log into the SIEM every time. Oh, yeah. Yeah. That's different now as we are a remote workforce. I'm based in London. My team is in the US. We have folks in, in the east as well. Our operations are [00:10:00] global, right?

Yeah. We were just talking about that. Yeah. What I didn't like is, hey, I cannot always log into the SIEM and it's annoying sometimes right at the. The crux of it. I didn't wanna always have to open up my laptop. Yeah. If I just wanted to see something. Yeah. And in a remote workforce, there's some trust, you have to have some trust. And I think the ability to give my team just the action of saying, Hey, you have your phone with you all the time. Yeah. If there is something that needs your attention, you can just take a look at it. I'll tag you. And if you have a ready answer for that. Yeah. For adding that context, because most people do, most people know that, okay, this seems weird to you initially, but this is expected behavior, right? Yeah. They can just tell you over the message and you don't have to go back into the platform, investigate each and every suspicious activity that you see. Yeah. And it's just easier when you're building out that.

Hey, every single thing does not need to be explored, right? And that is something which I think was a hard learning for me because when I started I was like, oh, I have to have my [00:11:00] laptop open all the time. I have to be online 24 7. And as a unrealistic expectation in security and in SecOps specifically, that you have to always be on, yeah, there is a side to it, which you do.

But I think another learning which I had is Hey, if you build your pipeline in a way which is smart and kind of caters to. You what your standard process is, not just as a company and as your team look like, but in your life. Like you, you need to understand that your team cannot always be online.

And even if they, you expect them to always be online. They might be driving the kids to work one day or they might have their laptop with them if they're on call or whatnot, but it's just easier to get a first like indication on their phone. Yeah. Before actually having to run to their laptop and open it.

And I think that was a decision that all of us agreed upon. Saying, Hey, this seems like a much smarter idea. And some of the other teams were already doing that for, like the S-R-S-R-E infra team was already doing that when we saw success there. Yeah. Especially being a [00:12:00] distributed workforce.

Yeah. That did help.

Ashish Rajan: Would you say that, I guess I understand the motivation behind this as well, but I also feel a lot of people who are probably starting off on a project, like they'll hear you talk at B side. They'll just go, okay, sounds like a good idea. I have a paid team. I can do log aggregation.

Okay. I understand. I cannot always be online, so I need to find easier ways to access information, find more to check something in terms of, I guess the kind of alerts to start with. We were talking about CloudTrail earlier Yep. And. By default, a lot of people just go, okay, make sure, like even AWS recommendation is, Hey, have your AWS CloudTrail turned on.

That's the first thing you need to make sure. Yeah. Have your CloudWatch turned on S3 access logged turned on. Yeah. Every Tom, Dick and Harry log they can find the on the AWS environment turned all of that shit on. Yeah. And now you're like going, okay. As a person who has to seen through, for lack of better word, across the entire ecosystem and we are not just talking one A WS account, it'd be hundreds of a WS accounts. Where's a good point to start? And what are some of the log sources that [00:13:00] you recommend people must have as a starting point?

Geet Pradhan: That's a fantastic question and obviously one of the things that I do preach is hey.

This is not a prescriptive solution. Yeah. It is different for every company. Some companies who really need visibility into a particular thing. Yeah. For example, we needed a lot of visibility into our administrative actions on our cloud. So one of the things we decided was like, hey, AWS needs to be number one or number two, or number three, because.

That's where most of our stuff lives, and we just need to know what's happening. Yeah. Some teams might say, Hey, we need I don't know, CloudFlare or like network logs, that might be something which they wanna focus on this, these are all correct answers. Yeah. I don't I don't think I can ever say, no, you're wrong.

The one thing that we did, and I think we should have done a bit better, and in hindsight if I have to do it again, I would do that, is I would whiteboard water these log sources, if you're building a detection pipeline from scratch, there is a pretty high chance you don't know. You don't have visibility into every single source.

Yeah. Which is a different problem, which is a problem that we [00:14:00] also faced. And I'm sure there's a lot of like companies that are facing this because there's products which are identifying shadow sash, shadow it. So there's a business for that. That means there are companies who are actually experiencing day to day.

We do as well, not as much as we used to anymore. We fix that as much as we could, but. The first thing is just identify what does your company do? What are the applications that are used? Yeah. And that is a big task. It's not gonna be done by only you. Yeah. You're gonna have to work with your teams, right?

Yep. Yep. Maybe you have to work with your skip level. Maybe you have to work with your sister teams. You need to just talk like, one of the things which you also need to in security, which I always talk about is Hey, you need to be friends with everyone. Yeah. Because. They're gonna think of you as the police.

You need to change that. There's actually a really cool talk in B besides by Nate Lee, about the power of persuasion. If you can link that, great. Yeah.

Ashish Rajan: I will leave that. Yeah.

Geet Pradhan: He actually talks about how, if you want someone to do something, you just do something for them and you just need to be friends.

Yeah. With your team. When you're friends with the team, you'll get the answers that you need. Yeah. So what [00:15:00] we did is we were like, okay, what are the applications that we can, you can touch. At that time it was obviously nascent stages of a security team, and this was a, three years ago. So there was a lot of mess.

One thing that me and another engineer we were thinking about doing is hey, we have, we are very close to our infra team. Because we're like a spinoff from them. We, like our manager was the same but we're still in there. And we were like, okay. Let's just start with them.

Yeah. Let's not go to the IT side. Let's not go to the other product team side yet. Yeah. Let's start with this because infrastructure visibility is a big thing. So then we were like, okay, let's take these. One thing I would've done a little differently is I would've taken the business use case.

So most companies have some sort of compliance that's going on in the company. Yeah. Yeah. Something, PCI HIPAA is the one, yeah. And there's always a list Yeah. Of those applications. Yeah. So I would say find the person who's doing this. Yeah. Because they've already done the hard part for you, they've already identified the systems or the applications or the resources in [00:16:00] scope.

Ashish Rajan: And the log sources as well.

Geet Pradhan: And if not the log sources specifically hey. Okay. GitHub is in scope Yeah. For this for this particular compliance effort. Yeah. So then you know that, okay, you use GitHub, right?

Yeah. If you didn't know that would be a different problem in itself. Yeah. Yeah. But for example, Workday is in scope. Yeah. Or I dunno, any other HR platform that you have that gives you. A visibility into what we're doing, and B, and most importantly, it gives you the prioritizing framework. Yep.

So then you're like, okay, if there's a compliance issue, that means if anything goes wrong, we're gonna get affected. And there's always a Hey, is it security first? Is it compliance first? Again, they're both right. Yeah. With my experience and just knowing what we're doing right now and what other companies are doing right now.

I would always say, Hey, if there's, and there's gonna be an in intersection between them for sure. Yeah. If there's cross-functional impact, if that system gets breached or gets popped, it just gets screwed up basically.

Ashish Rajan: Yeah.

Geet Pradhan: Prioritize that. [00:17:00]

Ashish Rajan: Interesting. And sounds like there's a softer, not soft skill, but I was thinking more for a cultural perspective.

There's a question to be asked as well because as, as much as. You may have the right intent. You've heard Geet talk talk about this at BSides. I'm talking to people who are watching a, listening to this. They might go, you know what, that's exciting man. I think I should do the same. I should make friends, my infra people, blah, blah, blah.

There is a whole security culture thing to be spoken about here as well. What was your experience and what have you found it to be? And I guess maybe it goes back to your per persuasion thing as well, but I'm curious to hear how'd you go with the organization, security culture.

Geet Pradhan: How long do you have?

It's a challenge, right? Whoever you ask. I'm sure you've seen it. Yeah. Everywhere. Yeah. It's the same as us now. Security is never the first hire. Yeah. If it is, please introduce me to the people who are doing that because I would love to meet them. So security is never the first hire? Yeah.

Or never the first 10 20. So something's already built out. So there's already a culture there. Now. A lot of [00:18:00] security adds complexity and adds a step. Yeah, one thing I realized is hey very basic, like product teams wanna ship, ship code, ship features. We add a complexity saying, oh, maybe you don't do that, maybe you don't.

Just like basic meme example, push to prod. Yeah. Maybe we don't do that. It interrupts what they're currently doing. It interrupts on their velocity, it interrupts on multiple of their metrics. Yeah. So you are, you're basically making their life harder. Yeah. One, one big thing that I learned in my previous role is security impact or security goals, yeah.

Are not always equal to business goals, not always equal to cross-functional goals. So this is where I go back to Hey, you need to understand the problem. Yeah. You cannot just say, oh no, you cannot do this. Without really understanding what, what it is they do and why they do it.

Yeah. Yeah. One big example of a behavioral change that we did is we spoke to the teams. Literally we spoke to the teams.

They were pushing to prod because they thought it's fine. It's a, it's not that important repository. It's okay. And. When [00:19:00] we SIEM simply had a conversation with them, they were like, oh, dude, yeah. This is bad. Yeah. Thanks for telling us. There's a fundamental, and I think it's preached or spoken about it.

It's called, Hey, don't say No. Yeah. Internally, me and the rest of our team, we have a mindset of saying, Hey, let's not say no. We'll say yes and Yeah. So you wanna do something? Yes, sure. We're not gonna, we're not gonna say no. But if you wanna do it, here's guardrail. 1, 2, 3, 4, 5. Oh yeah. So in the context of cloud, we were like, Hey, we want, the team wanted to deploy a couple of S3 buckets. Yep. And they were like, yeah, we want all the permissions. This role has to have all the permissions here. We wanted to do everything list, but we were like, okay, cool. We're not gonna stop you creating the S3 bucket, but, or Yes and you have to have these guard rows. So do you usually need a put object permission. Maybe you need to get in list. Sure. That's fine. Yeah. Yep. But do you need to put object? They were like, oh, maybe not actually. You're right. Cool. And that was it, right? Yeah. Another good thing for us in my company is that [00:20:00] a lot of the things were through code.

So we could just insert ourselves as a code owner, and that is the complexity that they add. They had to be like, Hey, as a code owner, can you review this and approve it? Sometimes you do have to approve things. And it also depends on the individuals. Yep. Yeah. So I was having a conversation with some of the team members just yesterday at BSides who were there, and he actually said a really cool thing.

He is Hey, you spoke so I spoke about security champions and that's, I know that's a big word out there. Yeah. But essentially it's just security forward minded people in your company. Yeah. They don't need to do cool sta cool stuff. And they don't need to have a security hat on always, but.

You have to identify the people who are open to change. Yeah. Those people are the ones who are gonna help you. Yeah. You cannot change a behavior of the whole team straight away. It's much easier if you have someone on the inside, and I sound very cool saying this, you have to find that someone on the inside.

And if you find that person, it just makes it a lot easier. So what we did and this is not just for SecOps, right? It's security culture as a whole. Something as [00:21:00] small as, hey, if they ever create a pr Yeah. Approve it immediately, or again, within reason. Yeah, of course. But respond to that request soon, so then that builds like, okay, I'm doing this for you.

Yeah. And this is, again, going back to Nate's talk. It's like they think that they owe you something. Yeah. Not always big, not always small, but okay, you're doing this for them. You're building that relationship. Yep. And then because of that, when you ask for something, yeah. Saying, Hey, can you help me spread the word about this or we have a concept of RFCs, right? Yeah. Where we need to comment, where we need to be like, Hey, we don't approve. We do approve. This is what you need. That helped us in saying, okay, maybe now we start being a bit more aggressive and saying, I don't approve this anymore. Oh, we said yes, but maybe not.

You need to do 1, 2, 3, 4. Yep. And that's really helped. So you have to build those interpersonal connections. And it doesn't have to be you doing all of that, if you have team members split up the work, right? Yeah. For example, we have someone doing AppSec now. Yeah. And he is [00:22:00] writing a lot of code.

He's deploying our app, AppSec pipeline or expanding it and scaling it. So he deals a lot with our actual developers. So he's already maintaining that relationship. So what he is doing is he's okay, I will tackle this right. In my current role, my current project, I'm dealing a lot with strategy.

And talking to folks who are, cross-functional leaders, right? So I'm trying to build that rapport, rapport with them, with the risk team saying, Hey guys, here's my risk register. It's very janky because I'm not the expert here. Here's a gift for you. And that's just building a rapport.

Yeah. Does anything have to come out of it? No. Yep. But. It helps if you're friends, right? Yeah. And that's I think one of the biggest like learnings in security that I have. Yeah, SecOps, non-SEC ops, that's something which I think is pretty cool.

Ashish Rajan: And I guess to your point, security culture kind of goes a long way in making things easier as well as you go and deploy.

Fair. And maybe 'cause we spoke about log sources and the easy way to find it. We also spoke about the pipeline and as to where that. Or how [00:23:00] that can help build something. Are there any I'm just trying go with examples of alerts or detection responses that are good starting points. 'Cause I, what would be some of the examples for that?

Geet Pradhan: Luckily the security community is pretty cool. Yeah. One thing when I was researching this, I was like, oh gosh, do I have to pull out the documentation from all these log sources? Pull out all their audit logs, pull out and it was very daunting.

Yeah. And that's exactly how I started. So we started with GitHub because GitHub's documentation is pretty good for like the actions that you do. Yep. Okay. I also then decided to just do all these actions myself and just generate those audit logs. Don't recommend it. Okay.

Because it takes a lot of time. And going back, I would maybe do that if I want to understand like a particular behavior, but. My intention for doing that and actually creating that noise was to see, alright, if I perform this action, what is the alert or what is the Rex that I need to alert on?

Or what, whatever that kind of logic is. A lot of the work has already been done for [00:24:00] you because again, if you're building out a pipeline, you're probably starting from scratch and there's probably companies who've built similar product, if not similar products, but they've built the infrastructure.

Yeah. And one of the big lessons that I learned is there are libraries out there. Okay. Which have already done that. Some of them are by vendors. Yeah. So you may need to take like those, the grain of salt with your environment. And I talk about it in my talk as well. There's Elastic has a pretty cool library.

Okay. For detection rules. Splunk has a pretty cool library. Sigma is something that I really love. Like Sigma, the open format. Yeah. They have a pretty cool library. Some of it, it also depends on the community. Yeah. So Sigma for example, like there's a lot of people contributing to it. It's not the it's not the solution for everything, right?

It's not the magic wand that I'm gonna give you, but it's a good start. Yeah. It is very specific to like individual systems. Yeah. So you may have to add your own. Yeah. But there's a good start for at least a base. When you start building out your pipeline, you need alerts to say, okay, cool, what's happening?

So that's one way you should go. You spoke about AWS Yes. AWS has a [00:25:00] very interesting tool or service called GuardDuty. Yes. There's a lot of debate about GuardDuty in the industry, but at the very least

Ashish Rajan: yeah. Starting point,

Geet Pradhan: you have a starting point and doing a lot of the work for you.

Yeah. Not putting the cost of the service and everything into this discussion, which is a.

Ashish Rajan: Or even config for that matter can be quite expensive.

Geet Pradhan: Yeah. AWS config is annoying me right now, let's just say. Oh, fair.

Ashish Rajan: The reason I was asking that was because it's almost as people build these use cases and they find simple examples to do this there is a question to be asked about how do you scale this across multiple AWS accounts.

And at the same time, how do you know. It's time to like a zero day comes in. So first question, how do you scale this and how do you add more and make it like a seamless process to keep adding more as a well oiled machine for whatever. Yeah.

Geet Pradhan: So this is actually where, again, when I mentioned like this is one of the things that we want to continuously do.

Yeah. This is where I would actually take the help of the teams that you, I mentioned, like in a team. Product teams because they're good at designing these systems, right? Yeah. Let's face it, we are, [00:26:00] I myself, I am not the best system design person. The system is already designed.

I will threat model it because I can do that, but I'm not the guy you've the first guy you go to, to design a system. Yep. Yep. For that particular use case, right? Your SRE org, your infrastructure org deals with this exact problem every day. That is the one of their cornerstones, right?

Yeah. What we are doing, and again, because of our relations with them, is we're asking them, saying, Hey, I'm concerned about, my, my export web hook to my particular workflow or automation platform. I'm concerned that it's gonna be too much load if I add more alert or if I add more log sources. How have you solved that?

Your data pipeline. How have you solved that? We have a data team who does this literally for a living. Yeah. Say, hey, observability and telemetry from other sources comes to you guys. Yeah. How have you solved that? We have this system, can you help us? It's an ongoing conversation.

But I would say if you already have [00:27:00] those things, definitely go and approach them. Yeah. And sometimes like you just can't do it yourself. Fair. You may need to onboard a tool. Yep. There's a whole I'm a big believer of Hey, if you can do it yourself.

Ashish Rajan: So scaling do it yourself or

Geet Pradhan: scaling depends on your company, but get help. Okay. 'cause there are com, there are teams in your org, which probably understand the type of scale, like the a hundred accounts that you mentioned. Yeah. That's a scale that we like myself, I don't know how to solve that. Yeah, okay. Right now. Yeah. But I know for a fact my infrastructure team will be able to handle the resiliency aspect of it.

They'll be able to advise me at least on, Hey, this is what we did when we built it out. Yeah. You will experience similar problems, load. Maybe your collector goes down because there's just too many logs coming in, right? Yeah. Yeah. We actually had a very interesting example which we have a custom internal tool, right?

Yeah. And the logs from that are not the easiest to get. And that the team which handles that has their [00:28:00] own kind of logging mechanism. Yeah. So they have they have two week logging and then they have archiving, logging. So when we're trying to ingest that into our SIEM. It was very difficult because we tried to ingest every hour or the ingestion timeline was pretty large.

Yep. And the collector used to just say, oh, this is too many logs. And then it used to just not work, so that's a problem. We went back to the team and saying, Hey guys. Can we then put those alerts in your pipeline? Yeah. And just send us the alerts instead of the actual like log set. It is not the best solution.

Yeah. But until we can figure out how to get their logs into our pipeline, that is how we're solving for that.

Ashish Rajan: Sure. And this is an interesting one as well, because a lot of people may already have on-premise environments. How do you translate that into this cloud native world? Because a lot of the things you called out Yeah.

Are very API driven. It's also easy to have API be automated a lot of that stuff as well. Maybe some gen AI in there as well to help you build detection around it for people who are transitioning from an on-premise world to a cloud [00:29:00] world. Yeah. How would, how easy is that transition to do and what are some, were you have, do you have some thoughts on the whole process as well?

Geet Pradhan: Yeah, so the actual digital transformation. Yeah. I don't think I am the best person to talk about the complexity there because. There's articles and on articles on, there's so much data on that, in terms of the actual detection and the security side of it, it's a pretty different threat model.

To give you an example, if I'm an on-premise system, I'll be worried about, Hey, is there malware on here? That would be the first thing I look for. Yeah. When it comes to the cloud, and again, it's, there is I'm worried about malware and those things obviously.

But I'm also now concerned about like attack behavior and attack. Like the chain. Yeah. For example hey someone gets access to my, my, developer account. I would be concerned on that. And on-prem as well. But in the cloud. Okay, cool. They got access to that. I now need to know, are they looking at are they put, list objects, get objects, put objects?

The data events, [00:30:00] which sometimes you don't really look that deep. Yeah. But if the job of that particular developer or what, whatever, product that they're developing or feature or service, it's just to get objects and there's 50 or a hundred or 300 get objects. But then there's like a list object, which is a different object.

Yeah. That's something that you really need to alert on in an on-premise environment. You may not really need to go that deep. Yeah. It might just be like, okay, is there any malware on this? And that kind of flags it because. You're on premise, right? Yeah. There again, that's one example. There's countless ones in AWS and even in SaaS deployments in general.

Yeah. Yeah. That's, threat modeling is completely different. Yeah. Another really interesting thing is just the dynamic resources, which is fun. And actually read about something similar we like a couple of weeks ago about hey, crypto miners, right? Yeah. Someone did something and deployed a crypto miner for 90 seconds.

Now 90 seconds if you're like telemetry into ingest is five minutes, forget five minutes. Even if it's two [00:31:00] minutes. Yeah. You won't catch this. No, it's literally 90 seconds, right? Yeah. Again, if it's, you might catch like some part of it, but that changes things because you may not be able to even know that happened, right?

Yeah. Yeah. The dynamic nature of these resources makes it very complex, right? So not only do you need to have good visibility into, okay, how is this done? At your company. Yeah. You also, this again goes back to my initial point of Hey, you need to talk to your teams because maybe for them it's normal, right?

Yeah. If they want to do some sort of processing and they're just like, okay, we're just gonna spin up an EC2 instance quickly do this and then close it down, that is an attacker behavior. Yeah. It's literally an attack of behavior, but it might actually be something that the team is doing for a particular use case, right?

Yeah. Yeah. And you have to understand that you don't have to shut it down, but maybe for hey, service A or for coming from the AWS, I don't know, dev role, data eng team or whatever that team is, anyone with that role doing that? It's their job. Yep. Yep. And that's how you tune your detections, right?

Okay, I'm [00:32:00] gonna alert on any resource that's get created. Yep. And deleted in let's say an hour or two hours. Okay. That would give you at least a starting point. Yeah. But then this particular example that I gave those would be the false positives. And if they do it every day, then you need to fix that.

Ashish Rajan: So what do you put as milestones then? Because I'm almost, to your point it could also become an exercise where it may seem like there is no end. 'Cause if you keep adding detection one after the other Yeah. Like we have moved from on-premise to cloud. But, or you are going cloud to multi-cloud.

What's the I guess how, if you were to think about this from a milestone perspective, because that allows people to go, okay. My first project is I need to identify my important applications. Yep. Where the log sources are. What are some of those stages that you recommend people can look out for Yeah.

As they start building their detection response pipeline. Yep. That can be helpful for them, especially if they're starting today.

Geet Pradhan: That's a great question. Because. It's essentially no end. Yeah. Like security operations, there's no [00:33:00] end. Yeah. Unless, God forbid, company shuts down. I think even then there's no end.

But the first milestone is exactly what you said. Let identify the log sources you want to ingest. Yeah. I would say second milestone is figure out a way to ingest them, because it's not always gonna be easy. Yeah. We used APIs, there's an example of GitHub where you have to create that.

You have to export those logs into a bucket. Yep. And have your SIEM read from the bucket. Yep. CloudFlare was a difficult one for us because we had to create log push jobs. Yeah. From CloudFlare to S3. Yeah. And it was not easy. There was a little, it was a little difficult for us to do that. I think now it's easier with their log push V two or whatnot.

But that is something which is tricky. The custom application that I told you about. Yeah. That was even more trickier because we could not do that. So now, so we pivoted and we put the alerts on their system. So once you've identified those applications, you have to figure out, A, is it easy to ingest all of them?

Yeah. And B, if it's not easy how do I solve for that? So now you have those logs that you've identified. They talk, they're in your SIEM or [00:34:00] wherever, and you have a good handle on them. Then the third milestone is actually putting those initial detections or the alerts or just the things to look out for Yeah.

For these applications and sources. Yeah. We spoke about the libraries. You, maybe you can take it an app at a time, maybe you can take it all the time. Yeah. But the next milestone is that now, along with that milestone, I would say something maybe that you should do in parallel is figure out a way to get those alerts.

To you, which is the notification site. Yeah.

Ashish Rajan: Oh, yep.

Geet Pradhan: Yeah, we either through Slack so we have a notification priority, which also spoke about in my talk. Yeah. If you can link that.

Ashish Rajan: Yeah. I would also

Geet Pradhan: which basically is Hey, every alert does not, is not the same. We spoke about GitHub.

Just to give you an example if I'm if I'm deleting a repository Yeah. That's a pretty big thing. Yeah. But if, I don't know, I'm bypassing branch protections. Yeah. It is a big thing. But maybe it's a repository which kind of does not make sense. And another milestone is the prioritization aspect, which and context aspect, which I think needs to be done after [00:35:00] these things.

Ashish Rajan: Okay.

Geet Pradhan: So the notification of Hey, when do you get that? And also what is your response step? And the crux of it. Do you or are you a equipped to know what to do? Yeah. B, once you know what to do, can you do it right? Yeah. One of the things that we have seen, and it's a big challenge, is do you have the access to fix it yourself?

Oftentimes the answer is no. Yep. So then you need to identify what is the process to invoke the team who can do this. Yep. We were lucky enough that we had prebuilt on-call rotations. We had some of those automations in place where we can just ping the team oncall to say, Hey, take a look at this.

It's urgent. Yeah. Not everyone has that. Yeah. So maybe you need to A, find out the team who owns that code or that resource. Then you have to know okay, do they have an on-call rotation B? What is their standard process? So that is another milestone. Okay. But just another, provide another perspective here.

I think these should be going in parallel.

Ashish Rajan: Oh, okay. But as a single person doing all this in parallel as a

Geet Pradhan: single person, yes. Doing all this in parallel. And the reason for that is. That is [00:36:00] your detection pipeline. You can ingest everything. Yeah. But there's no point if you don't know how to respond.

There's no point if you don't know the alerts. Yeah. Because, and every SIEM has a different costing. Yeah. If you're putting all the sources in there, you're gonna rack up the cost. If you have too many alerts in the second column, you're not gonna sleep like the Goldilocks principle of Hey, how much is enough?

That is a real thing. It's in cognitive science, it also kinda applies here because if you alert too much. What are you gonna do? You're gonna, you're not gonna sleep. And if you don't alert, you're gonna be like, oh, the world is great as we're the most secure company and there's actually a breach going on.

Yeah. So that's why I'm like, take it slow. And identify your P zeros in what we call a p Zeros tier one application. Yeah. It's critical ones, don't make them a 35 applications list. Make them 1, 2, 5. Yeah. And start with that. Start very slow. Yeah. Because before you know it.

It's going to get overwhelming. Yep. And the answer to be that the overwhelmingness is automation.

Ashish Rajan: That's a good piece of advice. And those are all the technical questions I had. I've got three fun questions for you as well. [00:37:00] First one being, where do you spend your time on when you're not trying to solve the detection response pipeline?

Geet Pradhan: Ah, it At Lime or just in general? In life.

Ashish Rajan: It could be in general life as well.

Geet Pradhan: That's a great question. I like just to explore lot of things. I'm really into music. I play football. I work out I just try to be active and out there. Yeah. So I live in London and it's a lot of fun, right?

There's a lot to do. I like to keep myself busy. I'm fortunate enough that, I live in a city where a lot of these things are accessible. Sometimes I meet friends or I really enjoy food. Yeah. I go out for dinner and things like that. But I also like to keep updated on a few things that are happening just to keep myself relevant, I think with not just security, but in general.

Yeah. In my house, there's always music playing. Ah, so if Spotify has a leaderboard or something, I'll probably be quite high up there. Yeah.

Ashish Rajan: You walk into the Spotify bill just Yeah. Oh

Geet Pradhan: yeah. It's it's just continuous. Yeah. Yeah. Even if I'm not there, it's just going on. Oh, so my neighbors might just be like, this man never leaves his house. But yeah, I, having lived in been fortunate [00:38:00] enough to live in New York, Mumbai. Yeah. Pune, like great places where this is a lot to do. I need to slow down a little bit sometimes. And I just enjoy doing so many different things.

Yeah. And meeting different people. It's a lot of fun. It's awesome.

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

Geet Pradhan: I'm a pretty, I don't know if I'm a pretty public person, unfortunately. I was gonna say, what am I proud of that is not in my social media?

I've been cooking quite a lot more. I really enjoy cooking and. I kinda lost that. Oh wow, I want to cook more in the middle because I was doing all these cool meals that used to come in, and they're good for the reasons that they're good for, but I got an expensive pan. Okay? An expensive knife, didn't need it at all.

And that kind of led me to be like, Hey, dude, you spent so much money on. A knife and a pan, you need to cook more. So I don't post that on social media, but I fair, I've really been getting into cooking some fun stuff.

Ashish Rajan: Fair. Which is a great segue into my third question to the, what's your favorite cuisine or restaurant that you can share?[00:39:00]

Oh, maybe what favorite food you've made that you've learned.

Geet Pradhan: Oh, favorite food I've made. So I have, I hate following recipes.

Ashish Rajan: Oh, okay.

Geet Pradhan: It's this, I don't know where it comes from.

Ashish Rajan: You just go with the feel.

Geet Pradhan: Maybe it's like the Indian in me who's seen, like my mom just just kill it every time with just oh yeah, this means more salt.

Yeah. And I'm just always like, how do you know this? Yeah. But I try to follow a recipe sometimes and I get bored. And I just add some of my own things and it ends up tasting pretty decent yep. Nice. My, my fiance doesn't complain so far but I would say favorite, there's a lot of favorite restaurants.

I'll give one in London because it's relevant to us as a restaurant near Borough Market. I know. I'm not, it's not in Borough Market. Yeah, it's called Rambutan. Okay. It's a Sri Lankan spot. It's really cool. I really like it. I go there, I spent a lot of money in their place. It's like countertop seating.

You see what they make. Oh, wow. And it's just a nice vibe. There's a restaurant in New York, which I'm sure everyone in the world knows now. It's called Atomics. Okay. It was a very special meal for me and my fiance. But it's. A [00:40:00] great time. So I would say those two of different kind of levels in different cities.

Ashish Rajan: Yeah. So one in New York and one London. That's awesome. Yeah. Thanks for sharing that as well. For sure. Where can people find you on the internet and talk more about your talk and everything else you've been working on?

Geet Pradhan: Yeah, so I'm on LinkedIn. I'm pretty unfortunately active on LinkedIn, so if they follow me on LinkedIn, they will see a lot of like stuff.

Ashish Rajan: Yeah.

Geet Pradhan: I. I think the talk is gonna be on the BSides page if I'm not wrong. Yeah, if it'll be a livestream

Ashish Rajan: as well, but, and I'll blink it anyways in the short so people can actually catch to it. But yeah. Thanks so much with the show, man. Thank you for coming. Thank you so much. Appreciate it. Thank you for coming.

Thank you so much, guys. Thank you for watching everyone. See you next time. 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 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 system 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 [00:41:00] security, ranging from identity endpoint all the way up to what is the CNA or whatever, a new acronym that comes out tomorrow.

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

‍