Navigating Threat Modeling and Vulnerability Management Challenges with Kalyani Pawar
Host: Hi everyone, this is Purushottam and thanks for tuning into the ScaletoZero Podcast. Today's episode is with Kalyani Pawar. Kalyani is an AppSec engineer at heart and navigating the dynamic world of startups. After working for a couple of Fortune 500 companies, she now works at a Series F unicorn called ZipLine and their focus is to secure drones and infrastructure. It's wonderful to have you in the show. Kalyani, for our viewers who may not know you, do you want to briefly share about your journey?
Kalyani: Sure, yeah. So hey everyone, my name is Kalyani. You can also call me Kaylee if you prefer not to butcher my name. I...
Currently, I work at this amazing company, a drone company called Zipline. I run the application security and vendor security side of things at Zipline. My past career has been really diverse, starting from like adversity emulation, pen testing, then compliance, then vulnerability management, and then now it's application security. The beautiful part about working at a startup is that I get to wear multiple hats, and I get diverse exposure and everything do. So yeah, it's been a fun nearly half a decade now. It's been fun so far. Yeah.
Host: Lovely. So you have touched many areas of security. So I'm pretty sure we'll get to learn a few of those today. So I start with asking, what does a day in your life look like? I always get like different answers for different people, even though they do similar jobs or something like that. How does it look like for you?
Kalyani: So day in my life. There's a lot of context-switching that happens throughout the whole day. Say one moment I'll be doing API security, one moment I'll be threat modeling something, another moment I'll be doing manual source code reviews. But the intent at the end of the day is to create a secure code and make sure that secure code makes its way into production. It should not be buggy, it should not contain a bunch of vulnerabilities that and then obviously dealing with the monster of vulnerability backlog where you know you use different metrics, different prioritization techniques and sit down and develop a strategy about how you're going to tackle this backlog. Sometimes I mean I would say I'm guilty of like onboarding different tools because I feel like it would automate and make my job easier but
The sad part about some of the tools is that they produce a lot of false positives and so I end up spending a lot of my time again sifting through true positives and false positives and making sense of them and then trying to explain it in a language that the developer would understand. And yeah, just simplify works for everybody so security could be easily accessible to everyone. That's what my day-to-day looks like.
Host: So one thing that you mentioned at the start thing, right? Context switching. And that applies to everyone, like especially in the remote world that we are in. One moment you are working on something, the next moment somebody pings you on Slack, and then the next moment you are doing something else, right? You have no idea where you were before you got onto that Slack call.
Kalyani: Yeah. Yeah. And yeah, sure. And I think this major problem I have is one, that they'll be like, oh, this is urgent. We want to push this within two weeks. So now let's get security review done. Or others would be that, oh, we don't have time for this in our current sprint. You know, these common stories that you keep hearing,
We're focused on creating functionality and feature. We don't have time for security. So I think it's about like changing that mindset that people have towards security, that it's not a chore, it's not some extra task. It is a beautiful craft that could be involved in your SDLC. So yeah, that's another part of the job.
Host: Yeah, and we'll talk about like the mindset and all of that today. So we have few topics to talk about, right? So let's start with threat modeling. So most organizations use some sort of software development lifecycle, right, for building applications. According to you, like how soon should threat modeling be introduced into the SDLC
Kalyani: Have you baked before? Ever baked a cake or something? Okay, so I'm a baker. So that is like a best example I can come up with. So when you're baking a cake, when do you add sugar? Beginning itself, right? You don't add it at the end and then expect that it's gonna taste delightful. Similar thing with threat modeling. You want to do it as early as possible, preferably in the design and requirements stage, requirements and design phase. Why?
Because so there's multiple factors associated with it. The cost factor, for example, there's this technical term that we use in the industry called shift left, which means it is less clear and easier to fix something the earlier that you discover about it in the whole development cycle. Imagine you have highly vulnerable code. It makes its way to deployment. It's post deployment. People are already using that app. You can only imagine how many resources now we have to dedicate to fixing that.
Vulnerability, which we could have caught very much early on in time.
Another thing I want to point out there is that, you know, a lot of people, they just look at the application system design, the whole design, and they get overwhelmed by it, the whole diagram overwhelms it. My suggestion is to scope it as much as possible, and make it as, as scoped as possible. Maybe you can just focus on the authentication part of the application. How are you authenticating this? Try to zoom into the whole aspect that you're trying, this whole feature that you're trying to target and make it as detailed as possible.
And this process is obviously continuous, you know. For example, if you are, if you are baking something, okay, and you made the whole batter, it's ready to go in the oven, you still, you still do a taste test, right, to see if it is meeting your requirements or not, right.
So it's, it's the whole...cycle about making those constant checks in your whole pipeline. It is a whole process of doing threat modeling in different phases, not just early, but through different phases of SDLC so that you do catch vulnerabilities, whatever is vulnerable, whatever looks sus to you. You can figure that out.
And also, it's a whole process where you will evolve over time and you just keep, you just go through iteration, through iteration until you reach a desired...until you reach the desired outcome, and you're like, okay, this is good enough. I'm satisfied with the product of this threat model.
Host: I had never imagined to use a baking analogy for security. So thank you for doing that. At least now I can use this when I am speaking with the folks that, hey, we don't want security right now. Maybe we'll do it later. I can talk to them about baking. But one thing that you mentioned that definitely makes a lot of sense is having a very
Kalyani: Yeah. Yeah!
Host: But one thing that you mentioned that definitely makes a lot of sense is having a very detailed understanding of your components, let's say, right? And let's say zoom into a particular area which you are trying to address and look at the threat model of that, and then go from there rather than looking at your entire architecture and getting overwhelmed.
Sometimes maybe it's, some of those things are maybe not in control of you or your team, then it gets overwhelming, right? How do I interact with the other team? How do I get the… information from them and stuff like that. So a follow up question that I have on this is, how can I use threat modeling? Let's say I decided that we'll start from the beginning. How can I use threat modeling to detect the problems earlier?
Kalyani: Okay, so first thing, involve everybody that should be involved in a threat model. For example, involve people from the business use case, involve people from the developer use case, involve people who have security knowledge, not just security knowledge, they can be apps like SME, but they should have some kind of offensive persona and defensive persona.
So that is one thing you… you find those people before you start threat modeling.
The next thing is make your data flow diagrams as detailed as possible, because that is what you're going to keep looking at throughout your whole cycle. The more features that you add onto it, the more confusing it's going to get. So make a beautiful, concise DFD for it.
Then sit down and you can figure out what are my user stories, what are my use cases, how many, say, it could be something as basic as, oh, we have, it is a shopping app, we have people who are selling their things, so the seller admin, and then his group of sellers. So you want to think about these use cases as you're talking through threat model. You want to brainstorm all these ideas. And then...
What I like about threat modeling is that you can come up with a checklist and template.
For example, my background mostly has been in startups where they don't have a mature security program.
So you have to, you've got to start somewhere. And what I like about
The first threat model is not the best. People are throwing in random ideas like, hey, we have something like an admin module in there. Should we be having it? Do you think an attacker could have access to it? Things like that. You will hear some really amazing ideas from developers and you'll be like, yeah, that's cool, but let's not give access to everyone. So yeah, so if you're, say you're focusing on authentication.
Things that you learn through a threat model about how your application can be attacked, can be exploited from an authentication perspective, make a checklist of that. Once you make a checklist of that, you can make that template and circulate it to more teams.
So for example, a big problem that I've been facing, and it's not just me, it's a lot of engineers, security engineers out there, is that you're in an organization where there are just like 200 developers being supported by one AppSec engineer. It's a very common story. This checklist, this template, if I can apply it to team A, I can also pass it on to team B, right?
And another aspect I want to touch on while we're talking about this is that scalability. Startups are always going to be fast-paced, maybe large organizations too. They're always going to be fast-paced. So this one AppSec engineer cannot support these 200 developers.
So the way I would suggest tackling this is maybe assign an owner of the feature. Now, if they are going to ship the feature from start to end, they have to come to you with their security questions, make them the owner rather than you being the owner.
And then, you know, you will get overwhelmed and burnt out by looking at so many applications and trying to deliver security. And, you know, scaling will be difficult. So try to make the developer the owner of this whole process.
And you know what it'll do? It'll not just help you with scaling, it'll also help you with like training and education. They will learn. It'll be like through osmosis, they're gonna learn new ideas about like, oh, how I can secure my app. Oh, this is not a, this is a vulnerable package. I should not use it. Or, oh, this is how my code can be exploited. This is how a malicious intent person is gonna input something really bad and cause like a…
So think of it as a learning opportunity for them. And then also another opportunity for growth.
Um, yeah. Yeah.
Host: Right. So few things I really liked about what you said, right? One is the first version of your threat modeling would always be not perfect. Let me put it that way, right? But you should be OK with it. Because if you aim for perfection, you will never start. Right?
So that is one thing I really like. Yeah, you have to start somewhere.
The second thing is the checklist. And it makes a lot of sense particularly if you have many teams and you have limited a number of engineers, right, security engineers in the team.
And the last one is, and the most important one is involving other teams as well. So like, yeah, like few weeks back, we had a guest, Dustin Lehr, he speaks a lot about security champion program, where he says that you collaborate more with other team members and try to find a champion in other teams so that they help push your agenda. Like from a security team's perspective, you work with them so that the security agenda moves forward. So yeah, it makes a lot of sense. So you mentioned... Go ahead. Yeah.
Kalyani: I have found success in the security champion program as well. Because say if I found something that looks sus to me, I would take it to the manager. And I'd be like, hey, since you're like the lead for this team, I think this looks wrong. Maybe you should fix it.
And then there's that whole pushback that, hey, I don't have this bandwidth for this in this current sprint or something like that. In that situation, having a champion on the team is easy because you can let go, talk to them, that, hey.
This is a problem. And then they speak the developer language to the manager and explain that, Hey, if this gets exploited, uh, you could leave it, it could lead to like unauthorized access to a database or something like that. So having those champions is so essential.
Um, yeah, God bless them. You know, like when I go to conferences, uh, and like security-focused conference and I see developers attending it, I feel like they're doing really amazing job by, you know, supporting, um, the whole security community by educating themselves.
Host: Absolutely. One thing that you mentioned, right, like particularly for startups, when you have limited resources, or maybe you don't have any security teams, particularly for threat modeling, there are many models also, right?
There is CVSS, Stride, VAST, there are many models. Let's say I don't have a security expert in the team. It's very difficult for me to understand what's the right model, what's the right way to implement. How should I go about it?
Kalyani: Sure. So first thing to remember, there is no one size fits all agenda with threat modeling. There's no one size fits all.
You will have all these different models and you have to find something that tailors your needs. Now, if they don't have a security person who's going to explain to them how threat modeling works, they're obviously inevitably going to go on the internet and figure out what threat modeling is.
Now, I pulled up the definition of threat modeling the other day and it was like...
Threat modeling works to identify, communicate, understand threats and mitigations within the context of protecting something of value. It is a process for capturing, organizing, and analyzing all information. It is a structured representation of information that affects the security of an application.
It is so complicated. This whole definition is so complicated. You don't want to just be like, this seems so complicated. I don't want to waste my time on it. I'm just probably like...
Host: and also it's very high level right, it's not very specific yeah.
Kalyani: It's very high level. Yeah, it is very high level. But if you don't have security guidance on your team, there's just three to four basic things that you want out of your threat model. Threat model is not some huge monster. It is as basic as, you know, what, what is my system? How standing my system, what can possibly go wrong with it? What can we do about it? And am I in a good enough space now that I figured that this is what is wrong with my system.
That's as simple as it gets. That is what threat modeling is.
So talking about Stride, it is very foundational in its character. If you are someone without any background in security and you want to just like go ahead with like, hey, what are different attack vectors? What are different impacts that can happen if this gets compromised?
So you start thinking about like Stride from like spoofing and...tampering and all the whole stride mnemonic, it was a crony perspective. Now, pasta on the other hand is for someone who has figured out their technical requirements, their business requirements, wants to bake in GRC since the beginning. So that is what pasta is. There's others like attack trees and octave and et cetera, et cetera. But what...This is confusing enough.
This whole thing that we spoke last two minutes is confusing enough. But what you've got to understand here is, first, what is your product? What is it doing? What is its context? How are we delivering features in it? What kind of features are we delivering in it? Those, answer those basic questions about your product. Next step, start with something as foundational as Stride.
Since you don't have the backup for security, start with something as foundational as Stride. And then...you continuously grow and learn through it. There will be a point where you'll feel like, oh, I'm now comfortable doing pastime. So in the beginning, start with something as simple, as basic as Stride. You don't want to overcomplicate this.
This is a very foundational basic model to threat model. So do that. And again, learn as you grow because you cannot expect on a really complex microservice that you're going to use Stride because there's obviously more ways that this can be exploited.
So keep your requirements, business requirements in mind and then you choose which model works for you the best. Yeah.
Host: So one follow up question to that is, like if I am either not security, if I do not have a security mindset, or if I don't have enough engineers or security team in my security team members, do I need to do it on a continuous manner? Can I do it once and then just use the findings for eternity?
How should, like what's the right mindset and how should that be instilled in an organization?
Kalyani: Yeah. So I get this question a lot. Or in fact, an answer that, oh, no, we did in the beginning the threat modeling thing. I don't think we need it anymore. But the answer that I give them is that, have you been on a beach in summer and you're building a sandcastle? OK, a sandcastle. And then there's waves coming. It's windy. There's seagulls and all of that.
How are you just going to make a sandcastle and just like leave it out there in the process when you're building it.
You have to keep in mind that oh you're a little away from water or you're behind the rocks or something but this is not where a lot of seagulls are flying. So you are trying to continually do at different phases right. Foundational phase then one bucket phase two bucket phase you're constantly assessing the threats when you're doing it or even
I feel like as humans, we have threat modeling since the beginning of time. You walk into darkness, you're threat modeling around, you're looking at what threats I have here. Should I even walk into this dark alley or not?
So it is a continuous process. But I want to like talk about how do I inspire a developer to do threat modeling.
So many ways to do it. First, make them understand that security is a journey, it's not a destination. You celebrate the small wins. Say today they found out that this data flow looks really vulnerable, it's unencrypted. And so I want to put in some kind of encryption for it. Celebrate the fact that they are doing it.
Maybe give them props, maybe tell their leader about it. Maybe in your sync with them, with the whole team, celebrate their wins. And also...make them understand that the landscape is always going to be changing. It's not going to be constant, right?
Depending on how fast or slow your organization is developing, they're going to use different tools at different times. There's going to be some containerization, some new package being involved. Some something new is going to keep happening. So your tech keeps changing.
If something is changing, security cannot be static at the same time. It will have to change in tandem with whatever is being developed. And, and it does just not just that also like there's new attack vectors every day right there's a new oh today there is lock for jish uh lock for shell uh vulnerability and it is going to happen there's no there's no stopping this wave of attack vectors that's going to happen so once you understand these basic things these three four basic things that i just spoke about it gets easier to then continually threat model as you go forward in your whole process, in your whole life cycle.
So yeah, it's getting those two across. Yeah, yeah.
Host: Yeah, I mean, again, another good analogy, that how you should not think about it as a one time activity, rather it's a more of a continuous process.
So one of the things that you highlighted towards the end of your answer is the vulnerabilities, right? No matter how much threat modeling you do, there are external factors, right? Let's say there is a vulnerability to your operating system or your network's setting, something like that. So is there a way to get rid of all of these vulnerabilities? Is there a cheat code that I can use so that I don't have to think about those? I just do threat modeling and I'm all good.
Kalyani: There is no cheat code. There is no magic trick. If there was one, I wish I knew. Okay, so I think vulnerability management is like dealing, like we were discussing earlier, it's like you have this huge backlog of vulnerabilities and you're trying to like knock them off one by one.
But if you have, say, the number of vulnerabilities is in six figures, at that point, you possibly just don't want to touch this monster at all. Right?
You just want to quit your job, go somewhere else. But I think, so there's a certain strategy that you want to follow with vulnerability management. Understand where your organization is, how mature your security program is, and then find out different metrics that work for you.
For example, one of them, and I'm not talking about like CVSS score or risk scores, because they're not tailor-made to your organization. It is not applicable.
Some of them are not even applicable to you. So you can look at metrics, like how easy it is to exploit this vulnerability.
How is it a zero-day? Is it being attacked in the wild? Or how hostile my threat environment is? Is this a public-facing website? Is it something that has no encryption on it? Is it just talking openly to the whole internet, things like that?
Or it could be something like, what impact is this going to have if exploited? How is it going to impact my business? You want to think about all these different factors when you're trying to build that program.
You can device your own algorithm in...with a combination of all these three and then come up with something like, Hey, now if this is the score for, um, for, for a particular vulnerability, this is critical. This is highly critical. This is like a seven or drop everything, fix it right now.
Understand the different levels that will be generated from this algorithm, different levels of severity that will be generated. It could be something like, Oh, this is a set one. We can wait for like seven days to fix it or, Oh, this is something that does not have a huge impact.
if, or this is something that is so walled off from the whole world that it is very difficult to get to this instance, for example.
So, understand where your organization is with it. Develop those metrics, develop the scores, and then use an efficient tool. This is very important. Use a very efficient ticketing system. And I'm not just saying like just spin up like a board and then create tickets on it.
I'm saying, make it, say if it's a Kanban board, make it like, hey, this is something discovered. Then you create this whole ticket for them, give these all these metrics to them, then justify that why it's vulnerable. You don't want to just create a ticket for someone and then it is lost in the black hole of their backlog because they're like, well, security says we have to do something, but I don't completely understand what we're doing. So I'm just gonna put this in the back. We don't have time for this. So.
I think it's about building that algorithm for yourself, for the whole organization, and then going from there. And it just, again, like I said, security is a journey, not a destination. You might have all these vulnerabilities and it's never going to come down to zero.
We can only come with an effective strategy to combat or to tame this monster. Then another, yeah. Yeah, so that's how your volatility management program should be ideally. Yeah.
Host: Okay, so one of the things with not just threat modeling, also with vulnerability management, right? You need to have buy-in from, not just from other teams, but also from, let's say, your upper management so that they invest in it, right?
So similarly how we spoke about like threat modeling, it cannot be a one-time activity. It has to be a continuous process.
Similarly, vulnerability management also is a continuous activity.
So how do you educate your other teams and the upper management that it is important so that they continue to invest in? How do you show that to, let's say, your upper management?
Kalyani: Right. So a couple of things here. I will discuss something with upper management. If it is absolutely like it's a dumpster fire or going to lead to a dumpster fire. That's the only time I would take it up to upper management. But if I want like a team lead to understand the severity of something.
Most times it's just about having a conversation with them explaining that, hey, this looks vulnerable and this is the risk code for it and I think we should resolve this within 30 days or something because we don't want it lying around. We don't want this vulnerability lying around forever.
So you try to explain it to them and it is as easy as having a conversation. Now most of the times I have received a pushback or not, no developer buying for something.
In that situation, what you can do is just like, write down a simple exploit for it. Show how you can exploit it and then tell them, Hey, if I can exploit it, I'm pretty sure anyone else can exploit it. It's just, we're like a moving target right now. So, uh,
Yeah, so make them understand with facts, with numbers, rather than just like going to them and then panicking them that, oh, you know, you have like a thousand vulnerabilities in your infrastructure. That's not the way to go.
Host: Yeah, it doesn't make sense because they don't understand that language, right? In a way, they are showing the impact.
Kalyani: Yeah, yeah, yeah. Exactly. They have access to the tool. They can see it too. It's just about understanding what this means and how I can, how I can like deal with it, how I can reduce this vulnerability. So that, and I think there's two things I also want to add here. One is that try to run a very blameless culture, like a blameless post-mortem. If something.
If something is broken, don't go like, oh, I know this person's team, they didn't take responsibility last time, but this is why it is broken right now. Try to do it in a blameless way because there's no point crying over spilled milk, right? So one.
And two is celebrate again. Celebrate that win. You know, remediating vulnerability is not, it's no fun. That part of the job is no fun. So celebrate the fact that they got time out of their schedule and they're working on it. Try to reward them in a certain way. Yeah, like give props to them, discuss them, show them as an example.
Host: And I think the celebrate wins doesn't only apply to security, it applies to every area, right? Especially with the remote world that we are in, we are so disconnected, it makes more sense to celebrate these wins because we are, as you said initially, right? We are context switching, we are working on so many things at the same time, we generally don't spend enough time to celebrate the wins. So that definitely makes a lot of sense.
Kalyani: Yeah. Yeah.
Host: So another area that I'm curious about is, so when it comes to threat detection, or when it comes to app security, we do threat modeling, we do vulnerability management, let's say, there is also a pen testing that we get done, or we do threat research or vulnerabilities research, we do bug bounties and all of that. When it comes to cloud, how do they play a role?
Kalyani: How do they play a role? So there's, okay. What I like about cloud is that it feels like the wild west of modern digital era. Like so many limitless opportunities, so much to do with it, but also like with great power comes great responsibility. So with respect to say, Threat modeling or setting up security configurations.
I think your work starts from there. I think security misconfiguration is like number six on OWASP Prop 10 right now. You want to make sure that things that you are deploying in the cloud are configured correctly. You want to make sure that your path is encrypted. It is not just sending, it is blocking public access, things like that, and security misconfiguration.
Second thing would be… focusing on say data security aspect of it, like are my keys managed properly, things like that. Then there's also, so when you say things like pen testing, the first and foremost requirement from a pen test is that it should be a beautifully written report so that I can understand what is the problem here, how are we exploiting it and how can we fix it, right? If they were able to exploit it, then it's...
I'm pretty sure like this is if it's like an internal pen test, they were able to expert pretty sure someone we are a moving target, someone else is going to do this in the near future. So understanding your pen test report, what is being written in it. It could also be like having a conversation with your pen tester and going like, so I know this is vulnerable, but I don't know how to fix it. Can you tell me how to fix it? That. Preview set.
Host: Yeah, or even how to reproduce it, right? Like how do you do it? So, yeah, yeah.
Kalyani: How do you produce it? Again, with DevOps and Agile and Picture, you're deploying code at 1,000 miles an hour. So paying attention to new technologies that you're introducing in your infrastructure at the same time. You can talk about containerization, making sure that you're not running communities with root-level privileges, things like that. Then what else can we talk about?
I also want to add in that you have to be approachable. As a security person, you want to be deemed as approachable because one, this is say you are educating your developers. Now they have an idea of what looks sus, what looks wrong. So they come up to you and they're like, hey, I think this looks wrong. Should we sit and maybe fix this right now?
You know, they're only able to do this when they feel that you are approachable enough that you can sit, understand the problems and discuss them, discuss these problems with them. So try to be approachable.
So I feel like all, it's like multiple domains to like cloud security here. Yeah. And also like We don't take logging and monitoring seriously for some reason. It's like, oh, this part that I've deployed looks great. It is serving the function that it was supposed to do.
But then you also want to introduce good logs in it because you want to know in the future that if this gets exploited, who exploited it? Is it like an insider threat? Is it something externally done? So in the future, you don't make these mistakes again and again. Yeah.
Host: Right. Yeah. That makes a lot of sense. One of the things that you highlighted earlier is like, along with threat modeling vulnerability management, you also need to have GRCs or compliance and all of that in place, right? As one of the pillars of your security program. For a, let's say startup or a mid-size organization, what's the right time to invest in a holistic security on top of compliance?
Because compliance families like it's a shock to our eyes or HIPAA, they ask, they sort of generally recommend to follow some of the best practices, but they do not cover the entire spectrum of security, right? So how, how to determine what's the right time to invest in overall security posture.
Kalyani: Yeah. So I'll give you another analogy here, another example. When you're building a house, you make sure your foundation is strong. You make sure this is good wiring, good plumbing, all of that.
When you make the house, when you start living in the house, you want to do more with it. You want to be like, oh, I want motion detecting lights, or I want a good camera system installed, or I want like this fancy furniture.
Think of that foundation as your compliance, your SOC2, your ISO or your whatever jurisdiction or business you belong in. There are different compliance requirements for each. That is your foundation. It should only serve as a bedrock. Everything that you build on top of it is additional layer of security. Why do we want to do it?
- because there will be new threats every day, new attack vectors every day. You are… sometimes these compliance requirements are not always up to date with what is going on with the current threat landscape. One.
- is that with the... So if you are, since we're in the business of tech, we're trying to sell a certain product, right? When you're selling it to someone, they want to make sure that this is secure. If I involve this thing in my network, is it going to cause harm to my network? Is it secure enough to be a part of my network? So...
Imagine someone just going like, hey, is MFA enabled? And you were like, well, it was not right now. But that's a really basic thing. That's something basic. Your business needs something as basic as MFA being enabled.
So compliance does a very good work of setting up that foundation, like all those basic requirements that your security program should need. But you are responsible for building on top of it. And it could be another thing could be like,
Since it's a business, it's always going to be changing. There can be different types of data that has been handled. Yesterday, maybe it was health data. I'm also dealing with financial data. So you want to make sure that you are evolving with the business at the same time. The way the business is growing, your security program should grow at the same time.
And again, educate your team, not just like developers, but everybody outside of developers, because employees are usually like the first line of defense. So… educating them. That is another aspect that you want outside of compliance as well.
Host: Okay, makes a lot of sense. Like have a foundation as a starting point and then keep adding on top of it as you sort of scale, as you hire more engineers or hire more security team, you start adding more layers so that your security is improved based on that. Yeah, makes a lot of sense.
Summary
Thanks Kalyani for the fun conversation. Here are a few important points which stood out for me;
- Detailed Understanding on particular capability with overview of entire architecture is very important from a Threat Modeling perspective.
- Create Checklists to scale security in an organization. Involve all teams, and when possible invest and nurture a security champions program.
- Security is a journey not a destination. Celebrate small wins. We often miss to do this. They make a lot of difference.
So we generally do the podcast in two sections. We cover the security questions.
The second section is around rating security practices.
Rating Security Practices
So the way it works is I'll share a security practice and you rate them from one to five, one being the worst and five being the best. And if you want to add context why you have given a particular rating, that will help also.
Kalyani: Okay. Okay.
Host: So the first one is always lock your computer when you leave your desk even if it's just for a short time.
Kalyani: I will rate this four. The reasoning being different things. One, that sometimes you're like, oh, I'm just gonna take, I'm just gonna go use the restroom and I'll be back in like a second, in like a minute or two, right? But.
Sometimes you're like, oh yeah, I think I need coffee as well since I'm already away from my desk. Let me go get coffee So the amount of time you're away from your desk. It keeps increasing There's no set answer for how long i'm going to be around my desk, right?
Two, is that you never know people's intentions. Some of them can be like this disgruntled employee who was, it could be like an insider threat to you. They could be like, oh, this person's laptop seems open. Maybe I should, you know, do something, have access to documents I'm not supposed to have access to. Right?
And then think about defense in depth. We… as InfoSec, we try to put all these defenses, like, oh, I'm going to use an IDS. I'm going to use an intrusion prevention system or something like that. I'm using all these complex things, but this one small aspect of physical security is something that they could not take care of. You understand, there's all this amazing defense strategy that we're building, but this really small teaming up. Yeah.
Host: Hehehehe, But you are not doing the basics right in a way right? Yeah.
Kalyani: You're not doing the basic, then you're essentially again leaving yourself exposed, right? So, that's why I would give this a 4. And I see this happen a lot, like people just unlock the... They trust everyone around them. Everybody is a good human. Yeah.
Host: Yeah, yeah, yeah. Makes sense. So the next one is grant users unrestricted access to systems and application, which could lead to unauthorized access and data breaches, right?
Kalyani: Yeah, zero. I'm going to go with a zero for this. Because, huh, OK. So they'd be like, I don't have time to implement different access controls or the different levels of privileges here. But why should someone who is just supposed to place a certain order have access to the PII of the PII of the PII.
Host: Okay.
Kalyani: of the person, right? Why do they need to have that? They need to follow the principle of least privilege. If you can do what you can do with your current level of permissions, you don't need other set of permission. This is unnecessary because say everybody in your org has admin access. It only takes one employee to get compromised to have access to all admin files, right? That's why I would just go with, I'm not going to grant everybody admin access. We are going to have different levels of permissions for everyone.
Host: Makes sense. The last one is DevOps practices are needed to move fast and deploy code to production because we want to move fast, right? Now, setting up security tests would slow down the dev practices.
Kalyani: Yes. So I hear this argument a couple of times and my only response to them is that it seems like resource utilization to you right now, but imagine a future where we get breached. That you small, it is like a huge price you're paying for the small effort that you could have done. It's just a small test that you had to do. You didn't do that and you're paying a huge price.
And not just are we paying a huge price, it is also like a huge dent in our reputation because we weren't doing our jobs correctly. And there are so many tools out there.
There's so many automated CICD checks. If they say that an image is vulnerable, do not push this to prod. There's so many tests. I would say that tests are a good investment of time because you know how good or bad your code is right now, how dirty it is and what needs to get fixed for it to be in a production ready state.
I would not think of testing as time consuming. Also, another thing is that you can, now there's so many tools outside out there that you can use so many open source tools. You can also like ask ChatGPT.
I'm not saying rely directly on ChatGPT's response, but you can ask that, hey, this is my vulnerable code. Can you create a test case for this? And it can, it can. I'm not saying it will, it can. It has the ability to give you a good test, again.
Since you are a security person or you are a developer, it is your, you are the owner of this feature. It is your responsibility to verify that piece of information and not fall for the sense of security that the tools are giving. So I would say testing is a good investment of time, longer term for sure.
Host: Makes a lot of sense. And yeah, that's a great way to end the episode. Thank you so much, Kalyani, for joining and sharing your knowledge with us. It was lovely to speak with you. Yeah, thanks so much for coming.
Kalyani: Thank you so much. I'm honored to be here. Thank you.
Host: Absolutely. And to our viewers, thanks for watching. Hope you have learned something new. If you have any questions around security, share those at scaletozero.com, and we'll get those answered by an expert in the security space. See you in the next episode. Thank you so much.