Building Security Foundation and Security Boundaries with Kushagra Sharma

TLDR;

• Security baseline along with security boundaries define the security foundation for Organizations. There are various types of security baselines organizations should incorporate like Network, IAM, Infra, and Data.
• Baselining is a continuous process. Define it, measure it, monitor it, and refine it using internal and external audits & findings.
• There’s no one-size-fits-all security baseline. However, define grouped and layered baselines to scale security practices in organizations.

Host: Hi, everyone. This is Purusottam, and thanks for tuning into the ScaletoZero podcast. Today's episode is with Kushagra Sarma.

Kushagra is a senior platform security engineer at booking.com He has previously worked with FinTech, scale-ups, and in the consulting industry, architecting and building solutions in a hybrid cloud environment. He's a strong believer of a cloud-first strategy with a cloud-native approach. Kushagra, welcome to the podcast.

For our audience, Do you want to briefly share about your journey?

Kushagra: Yeah, sure. First of all, thanks a lot, Prasad, for having me here. It's a pleasure to be on this podcast. So hello, I'm Kushagra, working at booking in the cloud security space right now. A bit about me or my background is initially, yes, I started more in the DevOps side of things, and then sort of security came in naturally. So it was a nice transition from DevOps to DevSecOps which you call it in today's terms. And then, you know, moving to like core security, cloud security primarily.

What's interesting is that before all of this even started, I was working, you know, more on the eisle side of, you know, physical devices like turnstiles, IoT devices, and all. So security was always like sort of, you know, like in the back of the, of the mind in terms of building these solutions and also that was sort of the core. And then you have from scale-up startups to consulting to, you know, a corporate. So it has been a nice transition.

And, yeah, just to add to that. So if you ask me like part of it, like why the transition happens. So it's an interesting thing because when you work in DevOps, you sort of realize that security is knocking on doors or like, you know, they're coming to you in bed practices.

So DevSecOps comes naturally in there. And then the more you dive into security or get your hands dirty, then you know, there was a curious interest in the transition totally into security. So.

That's how I ended up in this show, specifically in space.

Host: Yeah, I can relate to it because when early on the security part of the DevSecOps was primarily driven by DevOps teams, right? Now we have like different roles, one focusing on DevOps, and one focusing on DevSecOps, but it's a very natural transition from DevOps to DevSecOps as well. So yeah, there are more things I want to learn from the podcast from you. But before we start,

We generally ask this question to all of our guests and we get unique answers. I'm curious,

what does a day in your life look like?

Kushagra: Okay, that's an interesting one. So I would say being in security like not every day is the same. So every day it's a different structure, but very high level. I would say, yeah, you start in the morning, you catch up with the, you know, your Slack messages, your emails, or, you know, things from the previous day. Also in our team, we have the concept, we still have standups. So even though we have a security team, we have like constant standups with the team members to see what's going on.

But the main part of it, I would say is like, you know, because we, as part of the cloud security team, we manage baselines for public cloud. So there's a constant iteration of, you know, what we see as refining the baseline, which means, you know, adding controls, tweaking controls, reducing false positives. So this refinement of the baseline, you know, it's like a never-ending process that I would say is part of my job, part of my daily routine, which I like the most because, you know, you have different sources for it, different feeds and different things showing up here and there.

And at the same time, we also have quite a lot of same team meetings with the platform teams and also, as I said, security is embedded in the whole process. So we talk a lot with teams and it's a lot of stakeholder management at the same time. So that takes more or less most of your day. And yeah, after that, you have time.

Outside all of these things, you also go on the other side of things like offensive security, trying to like… look into vulnerabilities and how you can add controls to it, which we'll talk about later during this podcast. So that's it in a nutshell.

Host: Yeah, so few things that you mentioned like security baseline or working with other stakeholders. So we'll talk about those. And that's what today's episode is about as well, like looking at security, how to build a security foundation and security boundaries. So let's get started. So last year, you spoke at FwdCloudSec, and you're speaking again this year as well. So in last year's topic, you presented how you set boundaries, AWS permission boundaries in a large cloud environment in large cloud environments. Before we dig deep into the topic,

Can you help our audience understand some of the basic terms? Like,

What is the security boundary?

And particularly when it comes to cloud environments, what does it mean?

Kushagra: Right. Yeah, that's a good call because usually, different people have different definitions of things. Right. So, in general, like security boundaries, you know, like sort of a parameter, because some people also call it a perimeter. So it's a perimeter that defines, you know, the maximum permissible permissions. It can be network boundaries or network-level permissions. So it's basically defining a logical separation for your cloud environment of what's the maximum limit that a user can attain.

Now it can be at a network level, at the infrared level in terms of permission. So specifically the talk I gave was more on the permission side of things how can you set boundaries, you know, on the IAM side. So the whole boundary, you can have multiple boundaries for multiple things like network boundary, IAM boundary, and then together all of these sort of constitute your baseline, which you'll touch upon later.

So that's the concept of the boundary. But yeah, if you hear me saying perimeter, it's like the interchangeably used with as well.

Host: Make sense. But there is another term that practitioners sometimes mix up while speaking about security boundaries, which is security baseline.

What's a security baseline?

Kushagra: Right. So, as I said, boundary, when you talk about boundary, it's like the maximum limit, but baseline, with the word, if you go by the literal meaning,

it's sort of like the bare minimum things that you need to have. So it's sort of like a benchmark or a standard that one needs to implement.

Now talking specifically about, you know, security baseline and cloud environments. So I would say those are like sort of the bare minimum controls that need to exist no matter what. So it's sort of defining the baseline for you in the cloud.

So sort of safeguarding your resources, like, you know, not letting you have any public exposure, so on and so forth. Now, what's interesting is your boundary is sort of part of your baseline because your baseline might have, you know, some same configuration, default configuration, which you want to have by default, but then you also want like a boundary to it. Like what's the max the user can go in terms of permission, in terms of network control, and so on.

So baseline, I would say, is your top-level thing and like, boundaries, sort of a superset or a subset of it, if you may call it.

Host: I can relate to that. So last year we recorded an episode with Syed Shareef. We spoke about the IAM permissions boundary. That was very specific. But when you speak about security boundaries, you touched on different areas, right? Which makes sense. You would need boundaries from each of these areas, not just IAM you would need them from a network perspective, from a data perspective, and all the perspectives.

So how do you utilize the concepts of security baseline and boundary together to create a strong security foundation?

Kushagra: Right. So talking specifically about, let's pick one of the cloud environments like AWS. So as I said, for us, the boundaries, you know, like a subset of the overall baseline we have. So what's interesting is that AWS has this feature called IAM permission boundaries, as you call it out. So that's, I would say like that constitutes for like a substantial part of our baseline.

But in the baseline, you have, you know, default configuration that needs to go into every account. So talk about, you know, if you talk about AWS specifically, not turning off the public access blog, ensuring no one touches it. So sort of preventative controls.

So our baseline, it's split into different, you know, subsections. It could be a monitoring baseline. It could be a preventive control baseline. It could be, you know, controls that you put in your CI CD pipeline, like the whole shift left concept, as you call it. And all of these controls are different layers that together constitute your baseline. So that's how you actually at the end build it.

So, it's not just, you know, some specific set of controls. So, you know, compliance checkbox that you need to check, but you have it on every layer. You prevent certain things, you monitor what you're preventing. And then you have an additional sort of shift of controls where you sort of flag this early in the development cycle. And the whole thing together as a whole, we would call it a baseline.

So sometimes there's a misconception, right? Like, okay, we have these controls, we check these boxes, our baseline is ready. But how are you enforcing it? How are you monitoring it? And how you're like giving developers feedback early in the cycle. So it's like a whole process, to be honest.

Host: Yeah, I like how you structured it, like not just applying the controls. How do you enforce? How do you monitor? Because they also play a major role, right? You have to monitor to know the effectiveness of your controls. Otherwise, as you highlighted, it's just like checking the box. You just apply the controls and you are done. But unless you monitor, you cannot improve. And that also affects your overall security foundation anyway.

A follow-up question to that is cloud security… one of the key aspects of cloud security is building that foundation. And security baseline as you highlighted, plays a major role. There are many data sources that are used to define the baseline and boundary. And threat intelligence is one of them.

So how do you leverage threat intelligence to not only define the baselines but also continuously improve the baselines?

Kushagra: All right, that's a very interesting question. As I said before, defining the baseline is a never-ending process. So we have been working for years, we are working with today, it's part of the everyday job, I would say. But to your question, as I said, we have this huge concept of refinement of the baseline. So when you talk about new AWS services, existing AWS services, if you talk about any cloud, they keep on adding new services.

So for new services, it's easy, right? You have a new service, you evaluate it, you do threat modeling and you put it in the baseline in some sort of control. But then you have like, you know, new features to existing services being rolled out every other day.

So there's a constant thing for security engineers or your security teams to keep up with this place. So for us, what's interesting is we take in a lot of feeds. So of course you keep up with, you know, all the public announcements and all the features getting added to it. You review the IAM namespace.

Because Most of the controls that you can put in the baseline, I would say, fall on the IAM side. So the first thing that's very valuable to us is to review the IAM namespace. So if there's a new service, XYZ, review the whole list of actions, review what the service can do, or what are the permission sets. Because permission sets or the IAM permission sets would give you what the service is capable of. Because in terms of services, you will just have quite a lot fewer permission sets compared to a service that's fully configured by the end user.

That's like what I would say. Feed to is of course your threat detection teams, your cyber detection and response teams. So a lot of prevent, like to be honest, a lot of preventative baselines that we have was a reaction to what we got from our threat intel teams that, hey, this is being abused.

So when we talk about IAM Passwords for example, back in the day it was very, very… uncommon to hear about this. And then suddenly there was like a huge trend of, you know, IAM passwords being abused and how you can pass rules. So there's a constant, you know, like feeds from different sources, like internal to the company, external to the company, people are doing great work on public blogs, podcasts, like this one. So that's how you get to know and you sort of go with the process of refinement. So yeah, it feeds all together and then ends up in the baseline.

Host: Yeah, it feels like a continuous loop, right? You apply some controls, you monitor, and you see some attack happening or some threat intel that you get from inside or outside parties. And then you utilize that to improve your baseline again and then continue to monitor. So sort of like you're in an endless loop and that helps you optimize further and further your baseline.

Kushagra: Yeah, precisely. And to add to it, it's also interesting because it's important to have, you know, internal external audits. After all, that's sort of, you know, a reality check. Like not that we have a lot of findings, but you sort of get to know what, you know, because after, after a point of time, you need fresh eyes.

So that's where I would say external audits are very important as a company, like be it of any size that let's do an external audit, see what they come up with because that's sort of a very nice way to validate, what you're doing is right or what are the gaps or what are potential areas of improvement.

Host: Yeah, that's a very key point that you have highlighted. Often when you do internal audits, you have a limited set of data, right? Sometimes, you might see that your baselines are perfect based on that. So doing that external audit helps you, and gives you a different perspective. Yeah, absolutely.

Now, another question that comes to my mind is, let's say you have defined the baseline. It's not just you, right? There is a team which does this work. And then, often it falls under the security team that hey, the security team will define the baseline boundaries and all of that. But it helps to build a culture where not only the security but also the engineering team is aware of what you are doing and they understand the impact of it.

So beyond some of these technical controls or setting up the baseline, how can you promote a culture of security within the organization?

Kushagra: Yeah, that's a very good question. And I think most organizations struggle with, you know, bridging this gap in terms of building the culture. So, for me, what's important is that, as I always say, security shouldn't be an afterthought, right? So earlier, the development teams involved in security, the better it is.

So one of the easiest ways that I could think of is that, like, you know, we have architecture reviews and so forth. And it's always a trend that, you know, the security should be there. It could be that you don't have any inputs and it's like a very golden path architecture, but still having security in those meetings and those alignments and those sinkholes and reviews helps. So for me, what's also important is that security shouldn't be a grey area that, hey, you have this finding, resolve it. But you should also have internal awareness programs where you tell how this is being built.

So for example, at booking .com, we publish all the controls that we have per service, per cloud provider to end users saying, hey, these are the controls that would apply to your environment. This is how we are doing it. This is what it's checking. So it's not like a black box area, hey, you need to fix this, go to your ISU repository, change this permission to this, but you're telling them what the underlying issue is. And that's how, you know, the knowledge transfer sort of moves a bit on the shift left direction because developers would know, hey, this is a problem. So the next time when they do the same thing, they'll have a better understanding of it.

So be as open as you can, involve security the early as possible. Even if you're PO says, it doesn't matter if you have a production-ready design. So I think that really helps and builds a culture and it gives quite good benefits in the long run.

Host: Yeah, the keyword that I got from your answer is early, right? Engage with the security team early rather than once everything is ready, you want to roll it out. And that's when you bring in the security team. It would also give you a feeling that you are not valuing security that much. And the second thing is the opinion that you will get from security, you would feel like it's a roadblock, right? To your new feature that you want to roll out. So in like collaborating with the security team early has a lot of benefits as I'm reading from your response.

One of the things that you highlighted in the earlier responses is that security is not a one-time thing. You have to do it continually. You initially define, you monitor, and you improve on it. And another thing that you highlight, I'm just trying to connect two dots, right? Another thing that you highlighted is these cloud providers, they roll out new services every month or new features for existing services.

Now, let's say you have defined a security baseline. AWS rolls out a new service or a new feature in an existing service, and that doesn't align with your security baseline.

How do you handle those situations?

Kushagra: Right, so in here, I think the permission boundaries specifically talking about, so let's pick AWS help. Because what we do is we follow a safe list approach. So for example, here is the list of 50, or 100 services that are permitted to be used in our cloud environment or let's say in the production environment, right?

So this way you're not going to think of a mechanism where you say, hey, deny… these services, but allow the rest. Because if you say deny these services, and allow the rest, you're even allowing the new services without them being passed for the whole security review cycle, right? So this way you sort of control what you're permitting. So that's step one.

Step two is when you control what you're permitting, you can easily do threat handling of the service itself, add controls, and you know, see how good your coverage is and what the risk profile associated with that service. Because some service might be, you know, just feature additions. They might not have any security implications at all.

So this way there's always a parity with your baseline to the service being permitted to your cloud environment, right? Otherwise, you will end up in sort of a health situation where, you know, things are getting added, they are being permitted, they are being deployed and you have no idea of what's going on in your cloud environment. So I think this approach helped us.

But also sometimes what happens is now if you allow a specific IAM namespace or any service and new features are getting added, then you need to go back to the retro… retrospectively, you know, review the service of what's done, what's not, wasn't in scope back then, and then keep on refining the baseline. So that's where it's very important, you know, that it's not that once you've reviewed a service, full stop, we are secured, but you need to keep on seeing, okay, did any of the things change? Did any of the new things get added to the same service? Because it's like an ongoing process. So you should have review cycles for the same service, for example, or to your baseline.

So that also links back to the same thing where we say, you need to review the controls you have. So you need to see if they're working or not, right? Because sometimes there might be a control and it's obsolete, things got deprecated and it's no longer doing what it's supposed to be. So this whole testing should also exist in parallel. So you can patch things early rather than like it is an audit finding later on that this is a gap or a coverage issue.

Host: I like the inclusion-based approach, like you highlighted, right? That allowing services, only a list of services rather than saying that deny services. That way you have more granular control over which services are being allowed to, let's say your developers or the engineering team.

Do you guys use SCPs to define these or you guys have, you guys use more IAM granular permission sets?

Kushagra: Right. So in this case, we use permission boundary. But what's interesting is that you might ask that, hey, if you're allowing services, you're sort of blocking the experimentation part of it. So what if a developer wants to test out a service, a new service, right? But then it has to go through all these processes and these processes might take time, right? So what I spoke about at FoldCloudSec was also that we sort of have a mechanism of flavored permission boundaries, where we build dynamic permission boundaries on the fly.

These can be built at a per organization unit level, per account level, or you name it. So for example, today, if a dev wants to try something, you know, in a pre-product dev environment, we can build or allow a service or custom actions just for that specific account on the fly. And it's not that they reach out to us, you know, and we do something, we tweak the permission, it's all via infrastructure as code. So they can raise MR, the repositories available to the company.

There is it, we review it and it goes through the whole change process and it gets deployed. So that's what I said, like removing the grey area part of security where, you know, security is doing things for people. You need to empower developers. So using this way, you know, we use permission boundaries for services, but to your point as well, SCPs, we use it also for, you know, what we call non-negotiable controls. So things where you don't anticipate any deviation, any exception whatsoever, like totally non-negotiable that goes into the SCP for us.

And things where you need flexibility or you anticipate there would be exceptions or things changing constantly and constant iteration of deployment cycles that you put into the permission boundary and sort of finding the balance between these two. Because in the end, both of these are preventative controls, right?

Host: Right, right. So you have a good balance between SCPs where you have a hard no in a way, and you have the dynamic aspects of the permission sets where someone can experiment. Or you can move fast in a way. You don't have to wait for maybe a week for someone to approve that you want to use a new service, something like that. So that helps you with scale, right?

Any other such practices that you have seen other practitioners use to sort of not become a roadblock for your core business teams?

Kushagra: Right. So, recently I heard about, you know, someone building dynamic SCPs, similarly, right? So sort of interchangeably using the same methodology or the concept, but you know, what they were doing is they were building dynamic SPS and attaching it to per account level. And they had like a whole new based UI where, you know, developers can request taxes and they can tell the use case. It goes through like a whole flow, which was very impressive, to be honest.

So at the end, I think it's more about, you know, letting your developers know that there's a process. This is how it's done because we also have these environments called sandbox or testing environments where you have the complete freedom to test things out. And of course, they don't have any access outside that specific boundary that we have built. But that also helps them to move fast.

So a lot of practitioners also have this concept of separate org for testing and like all of these proof of concepts or, you know, sandbox environments, which is, I think a good thing because you're separating the whole tenant altogether. So you have different orgs or different account groups for it altogether, which I think is a good approach. But at the same time, I see the overhead of, you know, governing two organizations or two account groups.

So then I would say logical separation, which most of the customers are using either using SCPs dynamic SCPs permission boundary adds to the value.

And so another thing which I was about to mention is that also sometimes it could be that, you know, you need to move fast and SCPs and permission boundaries might not be the way. So I'm saying this because sometimes you don't have, you know, the granular level of things that you can implement using these policies. After all, you don't have condition key support or you don't have constraint support, for example.

So in this case, what's useful, which I see a lot of people doing including us is, you know, leveraging infrastructure as code checks. So, put it in the deployment pipeline because ideally, you have a single deployment pipeline to deploy into the cloud. If you don't, then you have another problem to tackle. But given you have that, then you can put the checks in a sort of flagging early in the dev cycle. Hey, this is a warning. It's being permitted in diverse sandbox environments, but then you move to prod, this would be a hard no.

So, you know, this way you also give them feedback early in the cycle, but you have different ways and you know, you're not just relying on SCPs, IAM, permission boundary you have different ways to implement controls because I think that's important if you want to also be cloud agnostic where you need to sort of move outside from the cloud pane and have controls which you can implement using other mechanisms.

Host: So dynamic SCP, I have never honestly seen anyone use that in practice, but I'm glad that you highlighted that. Most of the practitioners I have spoken with, define the SCP like a hard no, whatever is not allowed, and then use more granular controls for managing within an organization unit or an account. But yeah, I give it a try, like how we can leverage the dynamic SCP.

And you also highlighted how to define the baselines at different levels, right? Or levels or organization unit level, or even at an account level if you want the flexibility so that you are not impacting the developer's productivity, which is a key aspect, right?

Because business, the core purpose of business is to roll out new capabilities and enable the development team to move fast to help everyone.

So now, most of us nowadays follow agile processes, scrums, and agile processes. And as you become a larger organization, that means more and more frequent deployments. You mentioned that you use, let's say, infrastructure. Practitioners can use infrastructure as code to define not only the resources but also the function boundaries.

Let's say an enterprise customer has not only cloud but also legacy cloud deployments.

What strategies would you recommend when they are migrating so that they define the permissions boundaries in the right way?

Kushagra: Right. So yeah, I think that's a challenge for almost every enterprise, every customer, you know, because when they start building security wasn't, you know, the primary focus, but now it is right. And then the environment that you have currently is sort of the legacy environment, right? Because controls were not applied, so on and so forth.

So what's like an approach to that would be, as I said, you know, we have different flavors of the permission boundary. And the primary reason for that was, you know, because we have different regulatory or compliance scopes, but also not every environment is the same, right?

So my environment is not your environment. Every company has different environments and they serve different purposes. So using these, flavored permission boundaries, as we call it, you can, you know, have a completely different permission boundary for a specific environment, like be it your legacy environment or something that's a very, very different use case, like beta regulatory requirement as well.

And then using this permission boundary, you can be a bit more relaxed when the migration is happening because you need to move things a bit on the other side of the cloud. But as you start to move accounts, then you need to sort of go into the refinement cycle to make it more and more stricter to cater to the controls or the requirements you have in place.

So that's what I mean by flexibility when it comes to permission boundaries because you can be as flexible in terms of what's the maximum permissible limit, right?

And if there's a business case for your legacy environment to be migrated, then that's a way forward, right? Because you can have like a red cross later on to, you know, to like to see what areas could be improved. But at the same time, because I was also doing a lot of on-premise to cloud migration. And one of the things like back in the day was, you know, never do lift and shift, you know, you should also see what the cloud capabilities are or what you can reach from managed services, so on and so forth.

But I get that sometimes there's a business requirement to do lift and shift, which is totally fine. But I would say the key part is also, you know, to refactor how your environment maps to the cloud you're migrating to or where you're moving your whole infrastructure set up to.

So again, it's a matter of, you know, flexibility, you having the capability to deploy it. As I said, one of the core foundations before you, when you start listing on controls that you want to have is having centralized deployment mechanisms.

So how do you deploy to accounts at scale? Right. Because it's very easy when you have just a couple of accounts, account groups, so on and so forth. But for an organization, for example, like us, we have an excess of like two thousand AWS accounts. How do you start them? Right. So these core building blocks, I think are more important questions for you to start building the foundation. And then when you have challenges like this, you can like quickly deploy at scale and, you know, tweak things around.

But if you don't have this foundation, then you know, you're going back to the whole cycle of refactoring, but thinking how to deploy and it triggers, you know, like you're sort of back to like square one from scratch, you know, what to do and where to go.

Host: Yeah, yeah. I like how you defined that, like let's say you are moving from on-prem to a cloud. Ideally, you should not do a left-hand shift because the cloud has a different set of capabilities. Of course, there are some related capabilities. There are some unique capabilities that you should be aware of. But at the same time, if there is a business demand or something like that, it's OK to implement. It's OK to follow -hand shift. But as long as you set some good

security baselines.

Another thing that I got from your response is there is no one-size-fits-all security baseline for every account. Your sandbox might have a different requirement versus your QA versus your production.

Usually, the response that we get from practitioners is, well, the security baseline depends on many things. So my question to you is,

Is it possible to create a one-size-fits-all security baseline for a cloud environment?

Let's say I'm running a company, we have 10 AWS accounts. Do you see a possibility where I can have one security baseline versus having a different set of security baselines?

Kushagra: Right. So yeah, I remember I used this term, how you can build a one-size-fits-all baseline or boundary in the past. So my approach to this is, it has to be a layered approach, right? So when I speak about having a baseline, when I spoke about SCPs, for example, in terms of AWS, I mentioned these are non-negotiable controls hardening. So no matter which environment you're talking about, these needs to apply, right? So that sort of goes back to your, you know, say global level baseline, no matter what it applies to all the accounts in your org.

But then comes like, you know, this layered approach where you have favorite permission boundaries, where you say, hey, for Sandbox account, we have this permission boundary. For example, if an account is falling under PCI scope, you have this specific permission boundary. So the point being with -side split sole is that you shouldn't, you know, reinvent the wheel to have different mechanisms to have this baseline ready. There should be, you know, a standard deployment mechanism for us to start with and like sort of a boilerplate.

So what we do is we have the same template, same boilerplate for permission boundaries, but based on the context that you get like inputs, which environment it's going to be deployed into, which account it is, whether it's, you know, if it's a legacy environment, if you have one, and then it dynamically generates a permission boundary for that specific account or, you know, account group, for example.

So the thing is, you know, the template or the boilerplate that you have is sort of one size fits all. So now if a business requirement there is tomorrow, you know, to onboard a completely new environment or environment that falls under a regulatory scope, you don't have to think how you do that. You would just pass on this context to your boilerplate or the template you have and it materializes.

So in this, you have a sort of one-size-fits-all boundary. So the boundary differs from environment to environment. And on the top level, you have sort of this global baseline monitoring all accounts, preventing actions around the account like the… whole monitoring and preventative baseline that applies to everything. So these are like sort of the non -negotiable. So it's more of how you approach it because I've seen like some, some customers or some companies, for example, building, you know, siloed different permission boundaries. And after a point when you have 10 different versions of it, 10 different deployment mechanisms, and different ways of how the controls are managed, then it sort of goes into like something that's not maintainable right?

So again, back to your whole foundation of how you designed the baseline and how you thought about it.

Host: Right, right. And having a layered approach gives you a lot of flexibility, right? Like global versus context-specific sandbox or QA, you have different baselines. And also, it helps you group maybe your environments together. If you have 10 sandbox environments, maybe apply the global plus a sandbox-specific baseline. If you have a QA, you apply a different group.

But you still have a common sort of security baseline that you can apply, rather than creating one for every single account. As you highlighted, it's not maintainable after maybe five or 10 accounts. If you have a thousand accounts, there is no way you can manage it. One baseline per account, right?

Kushagra: Precisely.

Host: So the last question on this is, any other recommendations that you have in terms of finding a balance between the standardization and also any specific security requirements that may be a growing startup can utilize?

Kushagra: Right. So for growing companies, I would suggest that you know, there are quite a lot of, you know, benchmarks there, which you can find online. Like you can talk about NIST, CIS benchmarks, and so on.

So when you're building the baseline, you don't start, you know, thinking about everything. You think about, you know, the core foundation things that your security policy needs to have, right? What are the standards you want to talk about? You know, encryption at default, MFA for users, like the very basic things, right? You start listing them down from these standards, right?

So also, like when I talk about this, you list the standards in a very generic way is also because later down the line, you might want to follow a cloud-agnostic approach. You don't want to limit your controls to a specific cloud provider, right? So you start listing down the control of the requirements, like these standards or benchmarks, which you have a great starting point. And then you think, okay, which are the ones that you need to have like sort of going to your non -non-negotiable control set? So you have risk teams as well.

If you don't, then you can sort of get inspiration from these benchmarks to start with. And then that's your version 0.1 of the baseline, which you can sort of implement. So it's an ever-going iteration where you start small and then you sort of go into the direction where you are very granular because you also get experience of what you know.

But it's very important to have these things from the get-go. Because if you don't implement or you start implementing these controls later down the line. Then you're breaking, you know, production workflows. You're like going back into the iterative cycles of redeploying things, and so on and so forth. So that's not, you know, a good developer experience and it would waste more, you know, work hours than you would do if you did it right from the get-go.

So yeah, like these things, we use them a lot initially back in the day, you know, to start with the very foundation baseline. Like I think from 10 controls, you'll multiply 200 like over the years, but those 10 are the, you know, the foundation of the whole baseline.

Host: Right, right. One of the things that you highlighted earlier is you should not just think about a particular cloud, right? What if your workloads span across multiple clouds? So we got a question from Don Edwards from AWS, which was around multi-cloud setup. So the question is, when designing security architectures that work across multiple clouds, what parts should be common across all of them? and what parts should be designed for each specific plan?

Kushagra: Okay. Yeah, that's a very good question. So I would say if you have like a multi-cloud architecture, again, these generic requirements, which are non -non-negotiable, which are not, which are clouding need to be enforced everywhere.

Now, because a lot of people confuse implementation versus what the requirement is right. So how you implement something on AWS might be completely different from how you implement the same control on GCP, but that's a complete problem on the implementation there, right?

But the first thing that needs to happen is to map out the requirements, which are non -negotiable and should apply to everything. As I said, encryption by default, and so on.

The second step is that before you even go to the implementation side of things, see if these things can be built in. So you don't have to have like controls, you know, to sort of enforce it, look into default configurations or, you know, providing launchpads to developers where they can use like, you know, modules which have these defaults in them.

So you're sort of like again shifting left and then very specific cloud things. So as I said, like every cloud provider works in a very different manner. They have completely different IAM terminologies and how the authorized authentication layer works. But again, here, the first step before you even think about this is, you know, you need to have a very good visibility into your whole cloud footprint. So asset management, you should query every asset and know its configuration.

I think that's one of the core foundations, which most people miss, that you need to have a good, very, very, very good asset inventory to start with.

Once you have that, then you can come out with specific controls targeting services because one service from AWS would be very different from how it's working on GCP. And these specific, you know, cloud-specific things, you can then put it to your baseline, which is very cloud-specific and not, you know, cloud agnostic.

So again, sort of the global baseline concept that I spoke of, the layered approach, right?

Host: the layered architecture.

Kushagra: Because yeah, in here you cannot have a one-size-fits-all approach, but you can deploy things using a one-size-fits-all boilerplate or mechanism that you have.

Host: Yeah. So last year at Fwd: CloudSec, Kesten Broughton, I think he did a session on inventory. And that session was focused on GCP. But he was highlighting that your asset inventory plays a major role when it comes to security. Because if you don't know what assets you have, what is public, and what can be attacked, you cannot secure them.

And you highlighted that as well, right? Like, If you are in a multi-cloud environment, follow the layered approach. But at the same time, you need to understand what are your assets across all of them so that you can apply these security baselines.

Kushagra: Right. Indeed. I think visibility is one of the core components. And to be honest, a lot of controls that I've designed in the past, I looked at the resources deployed, which are insecure, look at the configuration and the reverse engineering, you know, to build control around it.

So if you have visibility, you know, you have this, these data points, you know, to like to do the reverse side of things rather than thinking from the other side, which, which helps, I think. So yeah, indeed. Visibility is the key and asset inventory, you know, yeah. it proves more.

Host: plays a major role. Yeah, precisely. And so that's a great way to end the security questions section.

Rating security practices.

Host: The way it works is I'll share a security practice, and you need to rate it from 1 to 5, 5 being the best. You can add context to why you gave a particular rating. So let's start with the first one.

Develop and regularly test an incident response plan to help quickly detect, respond to, and recover from security incidents.

Kushagra: I’d say that's a five. The reason I say it's a five is because as I touched upon earlier, you need to be on top of things that you're implementing. So you need to test them if they're working fine. But at the same time, you need to have processes of how you go about it. So it's not a one-time thing or something that you do proactively. So having these incident response plans, playbooks, and processes helps. And like, even if you don't have like a real incident, it's always good to know, run these tabletop exercises, do you know? see how your cloud is reacting to it. If you're tooling that you have, because you also have a lot of external tooling, how they are reacting to it. If your audio integrations are working fine.

Because at times these exercises lead to you finding gaps in your whole integration cycle. So it's very important to have a constant iteration of these things happening. Because also what's interesting is we sort of measure as well, how quickly you were able to detect it or how quickly our tools were able to detect it.

And that time can grow significantly over time or it can like reduce. So it's very important to have constant duration where you measure these things, right? So not only that you have this, but you also have data points or you measure it for post-mortem exercises.

So that's why it's like, I would say it's a must for an organization of any size. If you're smaller then it's easier, I would say if you're bigger then it takes time, but it's definitely what the time is.

Host: Yeah, agree. It adds a lot of value. Again, it goes back to that continuous improvement process, right?

The next one is always to lock your computer when you leave your desk, even if it's just for a short time. So I thought that it has become like a habit for folks, but what's your take on this?

Kushagra: Right. I mean, yeah, I would again give it a five because I think this is more of like, you know, a very useful thing or very basic security know-how that everyone needs to follow. Right. I mean,

I think every company, if you have like, you know, security of NS training when you join or you do the onboarding, I think this is present everywhere that, Hey, lock your computer. It's not that, not like, yeah, because if you're in public space and all, and if you have your laptop open, there might be consequences and you have had incidents like that. The reason I'm giving it a five.

Like also we have this thing at our company, which is called the cake culture. So if your laptop is open and your peer finds it open, you need to get the cake the next day as like, you know, sort of a violation of that. Some companies will have to wear a bunny coat and, you know, be ashamed in the office the whole day. So I think it again, to the security awareness and it's a must. So again, a five.

Host: That's a funny way to remind folks to not leave their laptop on the internet like log their laptops.

Kushagra: Well, trust me, you wouldn't wear that bunny coat again. It's a good one. You remember for life.

Host: I'm going to go ahead and close the video.

The last one is diverse practices are needed to move fast and deploy code to production. Security practices are not the most important right now.

Kushagra: Yeah. The lowest is one, right? So yeah, I think I would go extreme because as I said, security shouldn't be an afterthought, right? So involved early, even if it's, you know, like a POC. Also, some people have, as I said, like if you want flexibility or experimentation, headspace, build environments for developers, you know, like sandbox environments, so pre-prod, like which is very strict, no network access as such where they can experiment things freely.

So it's more of, you know, finding the ground between developers and security to let you do that. But using that as a premise of, you know, deploying into production without security practices, I think it's like a very frowned upon and bad practice in general.

So definitely there are ways it's more of, you know, communicating between teams to find the middle ground and, you know, build a safe environment where they can experiment. So you don't hamper the velocity, but at the same time, you're not exposing your company resources.

Host: Right, right. Makes sense. And before we end the podcast, the last question that I'd like to ask is any reading recommendations that you have for our audience. It can be a blog a book or a podcast or anything.

Kushagra: Okay. Yeah, I'm reading this book I'm halfway through right now. So it's called a split the difference. It's by Chris Voss. And it's not security-related. So it's more talking about, you know, negotiations and how you handle them in like, high crises because the author is like a former FBI agent and used to integrate, interrogate people.

The reason why I'm saying that is like, it has a very nice concept where he talks about, you know, the power of saying no, because there's always this notion security said no, right? So there's always like a space between a yes and no, there's always like some space of like, you know, finding the middle ground, as I said, but saying no leads to discussions or engagements. And that's how you reach the space between, you know, yes and no.

So it's a very good book, you know, to like for your real life, personal life, but also for your professional life of how you do stakeholder management because security is a lot of stakeholder management. So I think that's a very good read. I'm still halfway through, but I recommend it.

Host: I think you said that it's not related to security, but I feel like it is because of what you highlighted, right? As a security team member, you need to speak with different stakeholders and find that balance between saying yes and no, finding the right path is also a key skill you need to have. So even though it is not directly related to security, but I still feel it's part of how a day -to -day life of a security engineer or security practitioner.

Kushagra: Yeah, but definitely I agree. And I think it has really good lessons for, you know, people in any part of their career. Like if you're only in the career, then I think it's really valuable, you know, to see how human reacts to, you know, know and how you can like to go about it. It's a, it's a very valuable lesson. And as I said, like skill development at the end.

Host: So when we will upload the episode, we'll make sure to tag this recommendation so that our audience can go and they can also read and learn from it. So with that, we come to the end of the podcast. So thank you so much, Kushagra, for joining and sharing your learning with us.

Kushagra: Thanks a lot. It was a pleasure speaking with you and it was a very interesting discussion. I loved it. Thanks again.

Host: Thank you. Thank you. And for our audience, thank you so much for watching. See you in the next episode. Thank you.