Security debt and prioritizing risks with Aakash Yadav

TLDR;

• Security program should be risk driven rather than compliance driven. So risk assessment is the key for designing a good security program.
• Continued reevaluation of the risks in your risk matrix is the key to prioritization. It also helps in addressing security depth.
• Prior to using any open source software, do a security review in terms of support from the contributors. How big is the community release frequency and how engaged is the community for that open source software?

Transcript

Host: Hi everyone. Thanks for tuning into our Scale to Zero show. I am Purusottam, co-founder and CTO of Cloudanix. Scale to Zero is a forum where we collect questions from curious security professionals and invite security experts to the show so that we can learn about their journey and also get the security questions answered. Our goal is to build a community where we learn about security together and leave no security questions unanswered. So with that, let’s get started with today’s episode. For today’s episode, we have Aakash Yadav.

Akash is a security analyst at Launchdarkly, where he designs and manages the Enterprise Information Security risk program, performs supply chain risk assessments, performs continuous security threat assessments, and also supports the security and privacy compliance efforts. Prior to that, he was a staff security risk analyst at Opta Agash. It’s wonderful to have you here. Thank you so much for joining me in this show.

Aakash: Yeah, it’s a pleasure to be here. Thanks for having me.

Host: Absolutely. So the way we do the show is we have two sections. The first one is focused around security questions, and the second one is around the rapid fire. So let’s start with the first section, which is focused on the security questions. Right.

And I want to start the discussion with security risks and how those are measured. Right. So most organizations follow a risk matrix-based approach with two dimensions. One can be probability of the risk and the other is the impact of that risk. Right? And it sometimes feels incomplete because there can be multiple security risks which fall into the same category. Let’s say you have multiple criticals or multiple highs and prioritization in that case can be a challenge. So according to you,

How should organizations quantify their risks and how should they use that for their prioritization?

Aakash : Yeah, that’s a really good question and a question that is really close to what I do on a daily basis.

The first thing that you should understand is around the risk matrix. It’s great, it’s amazing, but it does not give a lot of quantitative information about what risk you’re talking about. Like you said, it’s likelihood versus probability. Right. So the impact, what’s going to happen and how is it going to impact us when we say for a particular vulnerability or a finding or a particular risk that we identified in the organization, it’s a high risk. What does the high mean? That’s the quantification that’s missing, what I think is missing in the current tool level or the two degree matrix where we do not really get a lot of information about what does high mean. So for me, the way I have spoken about this, the way I try to use it is a little bit of modification still.

You can use it in a two by two matrix or a three by three matrix, but adding more information, right. So there’s a book, how to Measure Anything in Cybersecurity, that I really loved reading. It was recommended by my current manager and it fortified a couple of thoughts that I always had.

There are situations in which people say, hey, you know what, we have identified this risk, but we cannot really pinpoint what’s the impact because we don’t have enough information. I mean, that’s not really true. You always have information. You always know that something is a high because of a particular reason. How did you decide it’s a high? Right? So the way I look at it is reducing the unknown. As also stated in that book, you reduce your unknown by getting a little bit of more information and creating probabilities and plotting the probabilities over the occurrence of at a particular time period. This would help you decide what priorities you need to put on a particular risk.

And risk is a moving target. It cannot just be high and just left as a high. You always need to keep evolving the risk and keep updating the risks and how you quantify them. So that’s I think what’s missing and what’s important for organizations to understand is the risk. Being classified as a high does not give a lot of value. You need to add more quantification tools. What’s the impact over a particular time period? How does it impact and what does it impact? You need to understand these questions before you can start using risk to prioritize your work or building your OKRs or your quarterly goals or yearly goal or a five-year goal.

Host: Makes sense. And thank you for sharing the book recommendation. I’m pretty sure viewers will love that as well.

One of the things that you highlighted was like continuous reevaluation. It’s not that you marked a specific risk as high today and it would be the same a year down the line, right? So that makes a lot of sense. Right?

Now, let’s say you do the quantification, you know, what is the prioritization? Every organization has a risk appetite and what happens is you often start with your criticals when you go to your highs, your mediums, and you follow that order, right, in that most of the times, the ones at the bottom, like medium or minor or low, they’re not addressed and they fall into security data. Right? So we received this question from a fintech startup and they’re curious. This is very similar to technical debt, right, or engineering debt, where you develop some feature and then you put that in the backlog for addressing that later and that affects overall quality, reliability and performance of the systems. So,

What are your thoughts on security debts and how do you define it, how do you measure it and how can you use that for better prioritization?

Aakash: Right. Yeah, I mean, security debt is something that’s not going away and I don’t think it can ever go away. Right. There is a lot of demand for security folks and there are not a lot of security folks who work on these projects. And then there are so much of findings, there’s so many findings that you get on a regular basis. It’s not humanly possible to resolve all of them. And if someone says you have zero security, that I highly doubt that’s the real case. So it’s not going away. The way I look at it is, as I said during the first question, it’s continuously evolving process. Once a risk has been identified as a medium or a low, does not necessarily mean that is always going to be a medium or a low.

So if you talk about engineering, if a particular feature is put in a backlog or technical debt, it could be because five out of 1000 customers asked for it. But what if in the future that feature is now being requested by 50% of your customer base, you change and you bring that debt up, right? So similarly, in security debt, you’ve got to continuously evolve and continuously keep checking the debt that you have created. Right? As I said, it’s not going to go forward and it’s not going to go towards zero ever. But you got to continuously keep looking at your debt and making sure that there is nothing that changed in the environment in which you operate, because of which so probably a medium became a high. And a lot of times it does happen that you have put up a vulnerability in the lower because of a particular situation. But then the technique used for that particular vulnerability is now being actively exploited. You should go back and bring it up and make sure you do a re analysis or reassessment of whether that actually is still a medium or still a low and then bring it up.

So that’s my take on security debt and keep going back, making sure that the security debt actually is something that you do not before which the risk is pretty low.

Host: And I think one of the things that you touched on and which is very true for not the security debt, right. Even for engineering debt, is you will never get that to zero. You’ll never have a situation where your technical debt is zero. Right. So accepting that and also the continuous reevaluation so that if something which was low maybe a month ago, if that attack vector is being used, we hear about that more and more. Maybe the priority has gone up and you sort of address that. Right?

Aakash: Exactly. Yeah. I mean, that’s what risk registers are for. You keep track of all the debt added to the risk register and continuously use the risk register to ensure that the lows remain low and lows, not actually turn high and you completely forget about them.

Host: Yeah, absolutely. So I want to take this one step further. Right, so generally setting up the security programs like governance or risk management or compliance is difficult in a single organization. And when you add the complexity of, let’s say, mergers and acquisitions, then it gets multiplied. Right. So,

What are the challenges you have faced while working across multiple organizations to set up a security program and how did you overcome them?
And I would add one here actually, which is like what advice do you have for security leaders who might go through it in future or are going through it as well?

Aakash: Yeah, so the biggest challenge that I faced was changing people’s mindset that if you are the acquiring company, if you are the bigger fish in the deal your program is supposed to be or would be better than the company that is getting acquired. I mean, it could be the case, but you also got to be open that it probably isn’t the case.

So it’s basically opening up to the idea of you will probably learn a little bit more from the organization and you probably also need to adjust your programs to ensure a smoother transition of their company into yours. So that’s one challenge that I faced which was very difficult for myself to understand in the beginning, but quickly understood as I saw new companies come in, new technologies being used, new better processes that move security to the left, is what I would like to say.

The recommendation that I would have for individuals who are getting into security M and A or integration on a broader term would be keeping an open mind and not expecting the company to fit 100% into your process from day one. It’s not going to happen, it never happens. And if you try to do it, you’re probably missing a lot of things. It’s coming from experience. And I’m not just talking about something that I’ve read somewhere. It’s coming from experience.

The M and A that I did, I expected with them to match completely to the program that we already had, which at the end we had to change the approach and we had to decide to let them run parallel till the time we could actually merge the two programs together to make the program better. That’s the idea that M and A should have. You should make the overall security program better for both the companies. It’s not that you’re moving one company up and letting the other company stay at a particular level. They’ve all bought them together and it will be a successful security program coming out of a more than an acquisition.

Host: Makes sense. I think the highlight for me is the mindset, right? Like you should not have a mindset that the company which is getting acquired, its program will be overridden entirely. Rather it’s more of a collaboration between maybe both organizations to find the best security program which will work for both organizations.

Aakash: Yes. And especially if people want example change controls, right, change controls that different. Organizations are always different. They’re never the same. So if you try to change the change control for the company that you require and bring them onto your program, the process is going to break and it’s going to be difficult for you to get your, let’s say, compliance programs.

Host: Makes sense. Yeah. And even I feel it is the same with engineering as well. Right. That processes would be different between organizations. So there would be your mindset having a learner’s mindset and having that mindset will definitely help when you are going through it.

One of the things that you highlighted, right? Like shift left when it comes to security. So my next question is around that. So adoption of open source software has been there for the last decade or so, but recently it has received a lot of attention, especially around supply chain security after the attacks on solar Winds or Twilio or PyPy and there are many more. Right. So we got this question from a first-time security leader who’s curious, like

How should they tackle the challenges with supply chain security and which should they get started?

Aakash: Yeah, so this is a really good question, especially as I said, during this period where supply chain is at the top after fishing, I would say. But yeah, it’s something important that we should all address and let’s address the elephant in the room. We do not do a really good job at doing that. Open source software are great they are amazing. It’s good to have open source software that gives power to individuals to manage rather than having enterprises managing those applications. The risk is significant because it’s definitely in your critical infrastructure most of the time, these open software, open sources and it’s more about getting the mindset. Again, it’s all about the mindset. It’s not just a security team’s responsibility to secure the organization, it’s the whole organization’s responsibility to secure themselves. So when an engineer wants to use an open source software, it needs to be reviewed to ensure that it has proper support, it is maintained regularly and it is a good community supporting it rather than just one individual who could probably go wrong.

Stop supporting it or just stop the enterprise. The software itself, just doing the source code, no one’s stopping them. So those are the things that you should definitely look at and keeping an eye on updates. It’s one of the things that is really important in open source software because most of the times these are not auto updates, these are updates that you go to manually set up. And so for example, change the version, update the version, get the most recent version and make and keep an eye of the changes that are happening in the version and have a proper change management control that reviews the update that you’re doing. So it’s an amalgamation of all the controls that you can build around supply chain. It’s not one control that’s just going to be like, hey, you know what we are. And you cannot ask the engineer not to use open source. I mean, if you do that, you’re restricting the growth of your organization as a whole.

So that’s my recommendation. Allow it, but be vigilant on what you’re allowing and make sure you continuously keep an eye on what’s happening with that tool. Just don’t install and forget about it if you’re doing that. God bless.

Host: Yeah. So continuous review of it and also having those metrics, the support system and the community, those are important when you are picking the, let’s say open source library and also continuously reevaluating them so that you know you are using a safe code and also you are in safe hands. Right,

Aakash: Right.

Host: Makes sense. So one of the things that you also mentioned as part of the responses, there are two major trends in a way going on in cyber security. Now is one is the phishing attack and the other one is supply chain security. And with these now most of the security folks have sort of woken up and they have started taking these seriously as well, right? But when we speak with organization, we see that there are basic mistakes still being made. You might have observed them as well. Right? So there are few questions here.
One is

What is one thing that organizations are doing wrong and they are not aware of it?

What is one thing organizations are doing wrong and they’re aware of it, but they are not addressing it?

And the third one is one thing that organizations are doing wrong but they think they will not get caught or they can get away with it?

Aakash:Yeah, that’s a good question. It makes me think for a second. But the way I look at it is I can use one instance and answer all of these three questions. Is security compliance programs there are organizations who use security compliance as the framework or a backbone of building the security programs maybe this is more in line with the second question is probably they know about it, but they’re like, okay, let’s not fix it because it’s working. And also with the third one is probably they know about it and they know that security compliance is not something that you should base your security program on, but you should base it on security risk. Right. Even though GRC is coupled together governance, risk and compliance. What I think and the way I look at security programs is building it on top of risk. Right. You need to understand what your risks are.

The compliance programs ask you to do risk reviews, but how many times and how many organizations actually use the risk programs, the risk assessments to build their programs or use the risk as an input to create new projects, reduce the risk because that’s the ultimate goal of security. Right. You got to reduce the risk rather than just having a security program as a short sell where customers or vendors come in and they tell us about a security program and we send them the software report when we do security reviews, software post is great, you pass the audit, but what value does it add? How do I know that the programs that you have set closely align with how your business runs, closely aligns with how your infrastructure is set up? Right. So that’s my thought process is the one thing that company, an organization is doing and they’re wrongly doing or not aware of is running a security compliance program that drives the security program. One thing that they know about but they are avoiding fixing it or trying to get away with the idea of what we won’t get caught, let’s continue doing it, is using the security compliance program to run their security program and something that they probably can repeat about the second question.

Host: Second was they’re aware of it but are not fixing it. And the third one they wouldn’t get caught.

Aakash: Yeah, the second one is they are aware that, okay, you should not probably security compliance, the software program is not something that’s going to secure your product, but it’s going to add enhance your product is something that they’re aware of. They tend to ignore it.

Host: Yeah, I think you’re spot on that that your security program should not be compliance driven, rather risk driven. Right. Like you measure to assess the risks and then you sort of create your security program. Totally agree on that.

Aakash: It’s important for people to really put emphasis on security risk rather than just having it as an item to pass compliance. It’s not bad that compliance has its role in security, but I think when you set up a program and you want to mature a program, a compliance program will only take you a particular step. You got to take the next step and add risks to it so that you can actually get quantifiable results of why you should take a particular project before we take something else.

Host: Yeah, makes a lot of sense. So yeah. Thank you so much for these amazing insights. Right. The book recommendation that you had, I highly recommend our viewers to go through that book and read through it. But yeah, this is amazing for me.

Rapid Fire:

Host:Now let’s move on to the rapid fire section.

Aakash: Great, looking forward to it.

Host: So the first question is a one liner quote that keeps you going.

Aakash: A one-liner that keeps me going is can I believe in this, is creativity is great, but you get your technique right first. You can go creative how much ever you want, but if your technique or if you don’t understand the underlying technique of how to get to something good, you’re not going to grow. So that’s what I believe in. Even when, for example, running the risk programs, I’ve creatively grown because I feel I understand how risks should be quantified or how risks should be used to run a program.

Host: I love that, technique is more important than creativity.

If you were a superhero of cybersecurity, which power would you choose to have in you?

Aakash: I would love to have foresight of anything that’s going to happen to the company that I’m working for. That would save a lot of heartburn to a lot of people and a lot of departments for sure.

Host: I think everybody would want that power of fortune. What’s the biggest lie you have heard in cyber security?

Aakash: That we have zero security debt. The biggest lie that I have heard is that our security program is perfect. A security program can never be perfect. There are always going to be situations where you can leak or attackers are getting really smart. They can get in and cause havoc in the organization. Yeah.

Host: And there can be new attack vectors which come up every day. Right. So you can never be 100%. Makes sense. Which animals from animal Kingdom do you relate to the most?

Aakash: I relate to an otter, the most. I like to have fun wherever I do, whatever I do. And otters, if you look at them, they’re having fun. They’re going around tumbling in the water and really living a great life. I love that, doing that and I recommend all my colleagues who do that as well. It’s life is short. Have fun and enjoy what you do.

Host: Makes a lot of sense. The last question is what advice would you give to your 25 year old self starting in security and why?

Aakash: Going back, I would say or anyone, basically anyone starting in security. Don’t give up security. Could you go to an organization and the organization is like, hey, you have smart individuals. They are really smart. And security, you look at them and you feel like, okay, you don’t know anything. Just keep in mind that they were in your shoes when they started. So don’t give up. Keep trying and keep exploring because that’s how you would build your career and you will make a niche for yourself.

Host: Yeah. Makes a lot of sense to learn that mindset will definitely help.

Yeah. Thank you so much, Aakash. It was a very good discussion. At least there were many things I learned as part of the discussion. Looking forward to learn more from you in future.

Aakash: Absolutely. I enjoyed the conversation and yeah, more than happy to answer many more questions over LinkedIn. I like helping people and thanks for having me. I think this is a really good platform to help people. Thank you for having me again.

Host: Yeah, thank you for your kind words. And to our viewers, thank you for watching. Hope you have learned something new. If you have any any questions around security, share those www.scaletozero.com. we’ll get those answered by an expert in the security space.

See you in the next episode. Thank you so much. Bye