Sep 17, 2025

Beyond the Hype: A Founder's Guide to Proactive Security & Leadership

TLDR;

Analysis of Business Risk and it’s Impact are key for successful Risk Management programs.
Assets Management, Training, Table Top Exercises are some of the key aspects of Risk Management.
For Cross Team collaboration and alignment, engage with Leaders on the Security Roadmap. This helps build trust and avoid last minute security mishaps.

Transcript

Host: Hi everyone, this is Purushottam and thanks for tuning into ScaleToZero podcast. Today's episode is with Ashish Gurg, a globally recognized leader in cybersecurity and AI security with extensive experience bridging emerging technologies, enterprise security, and business strategy. He's the founder of RigaCyber, an adjunct faculty at Dominican University, top 50 cybersecurity mentor in the US.

And a trusted advisor to Fortune 500 companies and startups navigating AI risk and compliance. He has also published many papers and holds patents in cybersecurity. Ashish, thank you so much for joining me in the podcast today.

Ashish Garg: Thank you so much for having me.

Host: Absolutely. I know that I did a very short introduction. If you want to add in, before we kick off, do you want to add anything to your journey?

Ashish Garg: I think the only thing I wanted to talk about is I did not start where I am today. I started more as an engineer, R &D, research and development scientist, engineer, building those security products and solutions. And then for first decade and a I was doing that. then last eight or nine years has been more on the practitioner side, leveraging those same products and tools of similar kind to build security programs, help companies and build maturity around their security programs and things of that nature. So that's the only thing I'll add, but yeah, it's been a long, journey.

Host: And we see a lot of security leaders have started that way. And the biggest advantage that I see is you have experience on being a user of security and now an expert in security. So you get advantage of both the areas. Hopefully we'll touch on that today during the podcast. Before we get into the security aspects, We generally ask this question to all of our guests and based on the role, based on the company, based on the industry, we get unique answers. So what does a day in your life look like?

Ashish Garg: It looks very different than it used to few years back. Running a business, helping customers, and building everything out is a very different aspect of your life. What's this? When you have a corporate job, know the goals are clear and you need to figure out the budget situation. You need to motivate the people working reporting to you. You need to have the board alignment and things of that nature. Right now, my day starts very differently. It could be just that we had a prospect pipeline and then we have to submit proposals or we have a deadline that we committed to submit the work to the customers, trying to understand where the marketing team is working. Where the sales is happening, where things are not working well, the website changes, content changes, our messaging if we are pivoting. So it's a very rewarding experience too because I have learned so much in the last couple of years compared to earlier because you have to do literally everything when you have your own company and you're trying to figure out, you have to figure out your own budgets anyway. There's no set budget for you anymore.

A very different day, but it's super exciting. The only big difference I would say is there's no boundary anymore. Work life, so I'm 24 by 7. Whenever anything is needed, I'm there. But I have to be there. So that's changed.

Host: Yeah, I can imagine. Running your own company brings in a lot of challenges, a lot of learning. And I'm glad that you're excited. You are doing day in, day out, and you are loving it, right? So that's the best part.

So for today's podcast, we'll focus on two things. One is fostering stakeholder trust, like one of the things that you just touched around alignment, keeping folks motivated and things like that. And the other is around risk management. So let's dive in, right? So generally, security is seen as a trust deficit business, whether it's with external stakeholders or internal stakeholders.

Can you share maybe an initiative or a philosophy that you live by that sort of helps you bridge that gap? And generally also another challenge that you might have seen, right? That security is not seen as everyone's responsibility. That, as an engineering org, I'll just give all of the security related things to my security team. They'll take care of it, right? Security is not often seen as that. So how do you bridge that gap? any philosophy or initiative that you have run to make security a shared responsibility for the entire organization.

Ashish Garg: Yeah, as a leader, you don't really have a choice. You have to make it a shared responsibility. You will never have. I have not met a single CISO or security leader who says I have all the budget I need. I have all the resources I need and I have all the support I would like to mature the program. It is always a shared responsibility. The challenge that you have to overcome is communication, the storytelling, the art of storytelling, such an important aspect of leadership.

you have to make others believe in your vision. And that's the only way you can have that alignment. That's the only way you can have the shared responsibility. Making sure they understand security is not just a cost center, which it is, right, for all practical purposes, but it's also enabler, right? Enabler of your innovation, enabler of your trust that your customers have in your brand, right? It's also a very crucial component of business continuity. If you do get a breach, your continuity in the business, your revenue is going to be impacted. So that is a philosophy. You have to create those champions within your team and outside your team. They are the ones who are going to talk about exactly what you have been talking about. When more and more people talk about it, when this becomes a common boardroom conversation, that's when you understand that it is shared, the responsibility is shared, not just on paper.but in reality. So, I have multiple examples in the past where I started getting involved more and more in the product side, on the business side, aligning to what they need, what they may require. That does two things. One is it reduces the overhead and load on my team. Because if...a security review comes just before release and we are already busy with lot of other priorities. It becomes very stressful for everybody. So we can reduce that stress by keeping it aligned. We know it's releasing in three months, six months, right? And we can carve out time, assigns, prints and specific work. It also helps build more secure product and...builds a trust with those teams that you are working with. Because now they are not looking at you as a blocker or hurdle to the release, but as partners. And I think that changes the game completely. I have example from a Fortune 500 company. I did that. I have example from a pretty big mid-size company. Very different business models, very different domains they worked on, but the same philosophy works. I'm a firm believer that the earlier you get involved, the earlier you start talking about it. And you should never shut up about security because you should always talk about it. It's not a one time thing. not one and done ever. Things are evolving. yeah, those are the things I can mention from risk management perspective, having the visibility, translating your whatever security program you are building, right? That into a business risk, not just an IT and tech risk, because tech risk is a little bit more complex to understand from board. But when you talk about business risk due to security, I think that becomes a much broader conversation.

Host: I love a few points which you raised, engaging early in the product development cycle so that you do not... One thing is, as you gave the example,you are not... Like, release is tonight and you need to do a security review of the application. That is very stressful for the team. So engage as early as you can with the engineering or the product team so that the security is baked in right from...

early in the process. Communicate. think you use a very direct language, right? You should not shut up about security. And I love that because generally, unless you repeat something multiple times, it doesn't register, right? Now, another follow-up question to that is, when you work with different teams, some could be technical, some could be non-technical, some could come from, let's say, on-prem background, some have cloud background. Like, your board could have different expertise, your team could have different expertise. What are some of the communication strategies that you have used so that you can build that trust, you can make them understand it's a shared responsibility. It's not just about security, teams responsibility.

Ashish Garg: Typically when you are going higher up and communicating, two things stand out. You usually don't have much time and you still have to make a point and Mark Twain said, and this is a quote you'll hear me say a lot, I did not have time to write you a short letter, so I wrote you a long letter. So when you have to show something in a concise amount of time and number of words, it's a lot of work that's put in, right? It may show like a two slide deck to represent what you have done in the last six months or three months. And you may have only three to five minutes with the board explaining.

The risks, right? But that's where you need to shine. That's where your art of storytelling, art of clearly communicating where the risks are, what it means to the business, because that is what they care about. They may not care about your security program because they see a dollar sign in front of security. That's this is what we are spending. What does that dollar sign give them? What is the value that it's providing your entire program? Being able to communicate it, articulate in a way. It is technical enough for them to understand the impact, but non-technical and business-like enough to understand what it means to them personally as a board. So I think that's where I think it changes the entire conversation. And I think that's where we see a lot of misalignments because as security leaders, a of times we get very deep into the weeds and start talking too much technical stuff. Oh, this is not working. I have so many vulnerabilities. How do I do this? I need these tooling. Board doesn't understand what you're talking about. It's pretty gibberish to them. So you can translate into the language. They understand, okay, if there is a business impact, if we have this vulnerability, if there is a breach, there may be a $5 million of loss to the business within a day. And to reduce it drastically, can put $200,000 of tooling. have the resources to do. can put it as part of the workflow, have the correlation engine working well, detected early and potentially prevented. That is a language they understand. Dollars and business impact. So you just have to change the narrative to what they understand. Think of it this way, I'm not saying it in a derogatory way.

If you're trying to explain cybersecurity to a five year old or a eight year old, right? Middle school or 10 year old. You cannot really talk to them about vulnerabilities and TLS versions and all, right? They don't understand anything. And I'm not saying it in a derogatory way. It's just that you have to talk, speak to the language of your audience. And if you are able to do that effectively, and it takes a lot of effort, but if you're able to do it, I think you will have.

better responses and more alignment with business. And that generally means you will be able to get some of the budget that you're looking forward to.

Host: Yeah, you're absolutely correct. Like this happens a lot with engineering as well, right? Like engineers are not very good at communication or using the language that the other stakeholders can understand. So you often get into very deep technical explanations, which then goes nowhere, right? In a way. So I love that advice where when you are presenting, understand who your stakeholder is when you are presenting. tailor your language so that it's understandable for them rather than going deeper into technical, which doesn't help anyway. One of the things that you touched on is around more preventive, proactive actions. What can you do so that board or your stakeholders see the value of it and maybe they give you the budget, the resources that you need. When it comes to like risk management programs, what are some of the like hurdles that you have seen when moving to more preventive or proactive security posture, any non-technical misconceptions or cultural hurdles that you have noticed.

Ashish Garg: In terms of building a proactive security program or kind of differentiating it with the stakeholder.

Host: building a proactive security program.

Ashish Garg: I think. One thing I keep coming back to when we talk about proactive is asset management. It may sound very counterintuitive, but a lot of times you don't have visibility into what you even have in an environment, especially for large enterprises. You can have the qualitative approach, you can try to build a quantitative approach, but if you don't have your assets sorted out, you do not have that visibility. You are protecting certain things very well, but that you're not protecting everything. don't, you're not comprehensive enough. You're deep enough, but you know, horizontally, you're not able to cover that. Building Proactive also means you are looking into the controls, not just from what NIST provides or other frameworks provide, but also looking from what your business needs. Not all controls are applicable to you.

But the ones that are applicable to you, if you're able to prioritize them and have them implemented, you have, okay, do I have this control? What is the efficacy of this control? Is it working as expected? And lot of enterprises struggle with that, not because they don't have the motivation, it's just harder to manage those, right? Harder to figure out.

Those controls also have to keep evolving, right? What you need, because you may have acquired a business you know, external business that changes your direction a little bit and changes your perspective on the control. So being productive that way, training, lot of the training awareness, doing those tabletop exercises when something like that happens, an incident happens, who is responsible, how to handle it. If you're just being reactive and when something happens, you start scrambling to make it work, it just becomes very, very difficult. So you have to...

Also, look more from SDLC processes if you're building a lot of code. Having things scanned, you already know that the risk of us deploying this is going to be lower because we scan, we fix the major problems, Your vulnerability management program, it's a very hard problem as you go enterprises, you have multiple geographic locations, on-prem infrastructure, cloud, hybrid, external third party integrations, third, you know, lot of consultants working for you. So it just becomes...much harder with the devices and assets. So, those are some of the things I think, building a proactive risk management program requires more stakeholders. It's not just you, it's pretty much never just you, You always have to align with people, provide the value to them. What we talked earlier, right? Having that communication strategy. You are making everybody aware, that's very very important. More people get aware, more they will be aligned with you because nobody wants to lose their job or have the business not perform well because you you are in that company, you are trying to build the right program to the best of your abilities. So just making them aware could help quite a bit.

Host: Yeah, and also like to your previous point, right? If you have made your other stakeholders aware, they are not thinking about security as just a department ownership, right? It's a shared responsibility. So everybody might want to contribute and help improve the overall security posture, whether it comes from a preventive mode or reactive mode.

Now you mentioned about some of these hurdles. Do you have any tricks that you use to overcome these hurdles? Any solutions or any advice that you have for our audience?

Ashish Garg: hurdles with stakeholders?

Host: Yeah, like setting up the mindset of proactive risk management programs and things like

Ashish Garg: Yeah, I think what helped me quite a bit is having a regular meeting with all the stakeholders that are needed to be part of their journey with me. Understanding what their business priorities are, understanding how it aligns with your business priorities. I used to actually share my roadmap of next 18 months, two years with my stakeholders. So this is what we are trying to build. This is what we are trying to do. Where do you see misalignment? Does it align with what you're trying to release and say, no, no, what you're doing has no significance because first three months what you're trying to do, they're trying to release something and you're trying to fix something or mature another program that doesn't align. So since I am going so early, I can actually adjust my roadmap or ask them to adjust their roadmap. I can take that to my leadership and saying this is what business plans to release. This is going to be a half a billion dollar revenue impact, for example, and we are not looking at doing this right now. So I would like to adjust my plan or understand if there is a, you know, potential to change, you know, understand what the business can do on their end if you don't have budget. It did a few things for me. First of all, it helped build that trust and relationship that we are not obstructing what they are doing.

We are not, you know, hurdle to their releases. We really want to enable for a good reason that we want to make sure business is trusted by the customers. There is no breach. The architecture they're building is secure. Couple of times it happened and this this happened organically as a byproduct of these conversations. I did not have budget to support certain initiatives they had, but they did. They had the budget so they were able to help.

buying certain tools and services that was needed to release their products on security side. So that was a game changer for me. Of course, you don't want to misuse it and assume they will be paying for it. But there are instances when the business aspect is big enough that they would be definitely happy to and their budgets are usually higher and CFOs are more open to the product side because that is what is building revenue. They are not really cost center. They are revenue generators. So.

Host: And this shows that there is alignment, right? Alignment in the organization. And also security is seen as a shared responsibility. That's where others teams stepped in saying that, hey, you don't have a budget. That's OK. We can maybe afford a tool. And that helps with the security roadmap that you have put together. Actually, I love that you share. security roadmap with the rest of the maybe organizations so that they also see how it can be adjusted if it needs to be or how they should maybe adjust their roadmap. That's amazing actually, sharing the roadmap with the rest of the team. So we spoke about bridging the gap between security teams and leadership, right? Like how do you tailor your conversation or how do you show them the value and things like that? So this question came from Yurtam Perkel. What he's trying to ask is how do you recommend to bridge the gap between security teams and other stakeholders in the organization, like developers or engineering? So we spoke about leadership. Now let's say if you are...bridging the gap with security or product. Do you have any recommendations?

Ashish Garg: Yes. So the one example I was giving was actually with the engineering team where I brought it up with my engineering peer. And I started having this bi-weekly meeting with them, understanding what are you doing, just more to understand what you're doing without any agenda, without any imposition on the security side or without taking more work from them. Just as two leaders, let's talk. I'll tell you what I'm working on these two weeks, what I did last two weeks, three weeks or if it is monthly, that's fine too. I used to do bi-weekly and then you help me understand where you are. And it takes time, it takes few months, but you build that trust.

So what started happening is they started coming to me, okay, we are thinking of this new project we just got budget for. We don't know all the details yet, but this is the rough timeline we are thinking and we will need, for example, certificate management system or we may be needing this scan report evaluation or we need security architecture. It will be a very common thing, right? Because that's what you start with lot of times. And so that was very good. then another thing is reviewing that time they drop those guards and they are willing to talk to you more about how they are currently managing, let's say their SDLC process.

And we found they were using multiple tools and they had a custom tool that nobody knew and there's like one guy managing and maintaining. And I was very scared because if that person leaves, nobody knows how to run it. And without that, there's a lot of risk to the business. So we started aligning, understanding, and figured out if there is a way to consolidate everything, all those three, four different brand, you know, vendor tools into one consolidated tool or a platform, have a dedicated resource from their side to manage, maintain, and half a resource from my side to review those report and see if there is any adjustment needed. And we take care of all the security architecture review of it, it solves their problem or not. So define what you guys need, define what security needs, make sure we have a solid single roadmap for the SDLC process and we work together. Roles and responsibilities, very, very important to, especially when you're building proactive security. It's so important to know who's going to do what whenever anything happens. You are talking about that. You're talking their language. They start talking your language. And you are an enabler in that case. But that's what happened. We migrated our stuff to cloud-based, so it was easier for people to... You can actually see the metrics much easier. The updates are a little bit easier for you to get them.

And then you can hold the vendor accountable for any kind of challenges because you can see the visual and you can connect with them. So managing vendor partnership was another big deal there because that was all broken. So making sure that they understand what they are responsible for, what we are counting on them for, and also sharing what our biggest challenges are. So if they have products and features and updates, they can actually align and help us.

understand how to integrate their own products. A lot of times they have four products, so go figure it out and say, no, you have to align with our roadmap because we want these things to work very well together. We don't have too many operational people. You have to help us. So operational costs are reduced for us. We just don't want to waste too much money just operating something that could be operated with half a resource and we don't know how to hire more. So a lot of those things help.

This is in a way proactive, but it is also very smart in my mind because that frees up a lot of your resources for other things that you want to do on the right of the boom. You know, something happens. Do you have enough people to handle?

Host: Yeah. And you are also not fighting fires all the time, right? If you have done enough proactive controls, you have put in enough proactive practices and things like that. Yeah. So one of the things that you mentioned about the building that stakeholder trust and things like that. And when you are reporting to your leadership or board, you focus, you tailor your conversation and things like that when you do that. So, how do you show progress? How do you measure and report on building that trust? Are there any qualitative or quantitative indicators that you use to show to the board that, we are building trust with our team so that they can join forces in the security programs that we are building? How do you show that value to the board?

Ashish Garg: Yeah, so there are ways to do that quite a bit depending on the size of the organization, size of the security program, the risks they have and the resources they have. Typically, the simplest way would be to have some kind of metric I was talking about, right? You have a five million loss if you get breached and the site is down for a day and this is 200k that you can put in and this is the roadmap was going to look like to reduce that risk. So the lost revenue part could be good. Compliance is a good risk to address with board as well. A penalty for being non-compliant. could be a very important thing or it may not be. If you're in financial industry, healthcare, it's a pretty big deal to even run the business. There's potential fines, but if you are not, maybe there's a data security related stuff, it could be a business aligned risk. So making sure of that. If you do get breached, so you lost some revenue.

How will you recover? How much will the recovery cost? Do you have any kind of retainers from a ransomware perspective, for example? Do you know what to do? You don't have that program. That is a risk you want to report to board, telling, OK, if you do have a ransomware attack, we don't have backup and recovery systems in place. We don't have people to test it out. We don't have a business continuity plan report that we update regularly. We don't do any testing on our infrastructure recreate. We don't have a secondary site for our data. All those are the business impacts that you should be definitely quantifying. Talk to stakeholders, understand the revenue model, understand what it takes to lose that revenue or gain that trust, right? Have a lot of red, green, yellows in your slide because that's a very easy language to understand for humans. Reputational damage, right? We talked about the brand damage could be there. Some part of it you can do very data driven, right? You can quantify very easily. Some of this could not be. If you lose one table or one database out of 10, right? And it has specific information. It's a little hard to really quantify to the business, right? In terms of revenue. But you can make an attempt. There are Models for risk framework like FAIR, right? Factor Analysis of Information Risk that can do that quantitative risk analysis for you. But it's mostly for more mature organizations that have all the data to feed into it. If 200 people companies tries to do it, maybe it's possible, but I don't know if there's enough value for them. there are ways to quantify. are…

But more important, I still think is you understanding the business rather than business and security. Security needs to understand the business, align with it, and then help them understand the security risks. It's the other way around. So you understand business and then you bring back the security to them rather than expecting them to understand the security risks.

Host: Makes sense. Makes sense. So I want to slightly pivot. So you recently participated in a podcast called the Decloked podcast and you spoke about the value of mentoring in cybersecurity. I love this topic because in security we are like there are very few people who are in cybersecurity compared to like whole engineering product and all of that. And often

folks while entering into the cybersecurity space, they feel a little scared because it's a vast area. Where do I go in? How do I go in? What area should I focus? So there is a lot of need for mentoring. So you moved from engineering, product engineering to security, right? You're a security leader right now. So can you maybe share some cultural or mind shifts you had to go through? while transitioning from product engineering to security.

Ashish Garg: Quite a bit, quite a bit. mean, when you are building a product versus when you're leading a team, you're talking primarily just individual contributor versus the leadership journey, or is that what you're referring to or more on the security transition? First one, okay. So yeah, that's a huge difference because when you are part of a team and you're delivering, you have specific modules, specific tasks assigned to you or you took on and then you're delivering. A lot of times you do not have to think about the broader perspective of business or even that product because you are one piece of let's say there are 100 people working you are one of them. When you start leading I think the biggest challenge is you get compressed from all sides is what I'm going to say right. You're not just trying to be involved technically trying to help.

deliver the product, you're also doing people management. Everybody in your team, I'm going to say, is going to be very different from each other, right? That means you need to understand their language. You need to understand what they are looking to get, right? You need to also motivate them. So your job is towards the business to deliver, but your job is also towards them to grow their career. And it's so important to understand the balance there, because if you take one stance on one side, you are going to upset a of people regardless whether you go towards your team or away from your team. So it's a very, very delicate balance. lot of mentoring you mentioned earlier comes into play as well because mentoring but also understanding, right? think having gone through this whole process multiple times during my career, I think what I have learned is you always want to listen to people and understand both sides. You make decisions the way It's important to business, but you have to understand what you are doing. Knowing what your charter is going to do to somebody on a professional level, personal level, how will they take it and how will they be motivated to achieve more than what you want them to. Right. I am a big believer of servant leadership, so I do not really like to just do any kind of micromanagement. I believe that if you motivate people enough. They will do what you want them to do and they will do what they want to do, which is what you want them to do, right? It has to be something that they are willing to do. Aligning to the vision that you have or the company has or the business has, I think is the most important thing because if they don't align with that, they probably are in the wrong place, unfortunately, because they chose the wrong company, they potentially chose the wrong thing to work on. But once that alignment comes, all you have to do is tell them what they are doing. How does it fit into the full entire puzzle? So don't let them be a number there. Tell them how what they are doing is impacting the bottom line for the business. How it is changing the perspective of the team they are part of. How it is helping company protect itself a little bit better. How did something they built help reduce, prevent a breach?

Those stories are very important for them and for you as a leader because those are the ones you will go and take to the board to get more budget for the product, resources and the bonus for everybody, right? If I can be really blunt about it, that's where the whole thing is, right? Security has to create its own value and you know, that leadership is not just to build business value by products or managing those people, but making sure those two parties are actually working very well together with the glue or the lubrication whatever you want to call it to make sure they're working together and sticking together.

Host: Yeah, so it shows me that how passionate you are about mentoring and how passionate you are about building that alignment in the organization because it's all about that alignment, right? If all the stakeholders are aligned, that's when you are moving in the right direction in a way. So one of the questions that Mel has asked is around this and he's my understanding is he's trying to tie the your passion of mentoring with the risk management, proactive risk management that you work on a lot, right? So his question is, how do you tie your passion of mentoring and teaching to educating boards and stakeholders in the best way to proactively manage risk?

Ashish Garg: Yeah, that's a very interesting question. you think about it, I think the way I look at it, first of all, I'm extremely passionate about mentoring. One thing that Mel probably didn't talk about is I'm also extremely passionate about getting mentorship. I love getting coaching and mentorship. I'm not afraid to say that. I just think it's such an important and such an underrated thing, right, for people, but coming back to the mentoring and board and education, I one thing a mentor does, and I have had a lot of mentors in my life and I'm grateful for them, one thing that mentor does, it simplifies things for you. Any complex tasks for you, certain things are really a big bother. You don't know how to navigate certain things. Mentor comes and simplifies it for you. Today it looks like this, tomorrow it's going to look like that complexity goes away in your mind because you are able to think through more clearly because of that mental. So simplifying that complex concept into something that you can understand, right? You may be juggling with four or five different things and you think they're interconnected. Maybe they are not, right? Just decoupling, right? Could help. And that's exactly what you do with, with a board, I was mentioning earlier that if you start talking to them about vulnerability management, they don't understand what the heck does that mean? But when you say, okay, this means there could be an exploit and business impact. Now suddenly you have the impact. So connecting dots properly rather than trying to mingle things. I think that's what mentorship teaches you. And you can leverage that.

You are also empowering the board. suddenly rather than same, same as mentees, right? When you are talking to your mentee, you're talking to them about what they don't know yet and what the trend is going to look like. I was talking to somebody who came to me for mentorship and I was telling them that how you're thinking about your career journey today is going to be very different in three to five years because the market is changing so much. The trends are changing so heavily. Even business leaders, security leaders are having a hard time understanding what is the current flavor of AI today, how the market is moving, how the changes are happening. So keep that in mind. Keeping track of those is more important than going in just one direction and not thinking. We are going to see more generalists going to be more successful than specialists is what I feel right now based on what we see. Because you have to know a lot more about a lot more different things rather than just knowing one thing anymore.

So you can empower those mentees and your board with the knowledge, right? They don't understand, they don't know. And then you can leverage that, remove that complexity and do that. You also...think one more thing is the collaboration. I always tell to my team in my company and even when I was in a large enterprise is that collaboration and interacting is such an important piece of what you do because you may be duplicating work or you may have a gap in what we are doing as a team. But if you communicate and collaborate, you can actually leverage somebody else's skills that are better than you or faster than you and they can do the same with you. So I think those things come with lot of mentoring and same thing for board. can talk about how connecting with IT arranging leaders with security and making it a single plan of action for the business could reduce a lot of costs and improve the security quite a bit. those are the things I think could be very helpful, even building security strategy within your team, right? Could be extremely useful to have that mentorship mindset.

Host: So you touched on some of the trends. we'll definitely talk about that. Like what are some of the upcoming trends, what folks should be aware of or should get their hands dirty and things like that. But before we do that, so one of the things in the same podcast, the Decloak podcast you said, and you said this in the introduction as well, right? That you have so many things going on. There is a little bit of a lot of complexity, a lot of chaos and things like that.

and you are making the best of it, right? You're enjoying it while you're doing it. So do you have a piece of advice that you would like to give to security leaders who feel when they get into a similar scenario, they feel overwhelmed or burnout because of some of this like overwork or chaos? What would you advise?

Ashish Garg: Two things, and again, I I have a lot of mentors who I respect so much and learn from them. Two things I would say are extremely crucial the higher up the ladder you go, the more seniority you have. One is you have to protect your time. Because if you are trying to do everything yourself, you will burn out very quickly because there is so much more than you can handle. So, definitely delegate, protect your time, delegate that task. Second thing before you can do that, you have to prioritize what is something that only Ashish can do or Ashish can do really well, but there are things that Ashish sucks at and somebody else can do a better job. Those are the ones you want to delegate. You want to find somebody who can help you do that. Those things, because burnout happens not just based on number of things you have to do, but also, when you're trying to do something you're not very skilled at. That means you're trying to learn, figuring things out while you have to still meet a deadline. And that is a sure shot formula for burnout. So you have to learn to prioritize and delegate. think those are the most important things as a leader you can do.

Host: Yeah, I think there is a matrix right where it says delegate and I'm delegate do it.

Ashish Garg: Yeah, if it is, if it is, is it, is it crucial or critical? Is it needed right now? Then you do it otherwise. Like there's a two by two matrix. Yeah. So it's, it's. Yeah.

Host: Metrics, yes. I'm not able to recall the name of it, but yeah, you're right. Like based on that, you put things in those boxes and you're right. Like delegation is one of the superpowers that you need to have, right? There is no way you can do everything. So you need to find who in your team can take certain things off your plate so that it protects your time. I think that's how you started, right? And that's key.

Now coming to the trend. So you have seen the cloud migration or moving from on-prem to cloud. Now we are talking about a new technology called AI. What's the, like from a security perspective, like what impact do you see? What emerging technology trend you see that folks should be aware of, folks should play with and folks should get familiar with.

Ashish Garg: I think understand the business use of AI. If you are inside the organization, when you're adopting AI, and this was a topic a couple of days back in Executive Roundtable as well, most of the companies are under the pressure to adopt AI without understanding, because there is not enough time. Your competitors are doing, you have to show that you are AI enabled. The business cases are not defined as well as they should be. And that generally means you are putting a lot of pressure on the rest of the team. IT has to deploy it, figure out the infrastructure, the compute, the memory, and the interactions with other applications. And then security is really involved at the late stage where things are already deployed. And security doesn't understand what is the business alignment here, what is the business use case, and what are we trying to protect, right? Is it the data? Is it the infrastructure? Is it the vulnerability in the LLM models you have? So, ISC, so that is a challenge right now, right? That's from an option perspective, but AI as a technology, I'm a firm believer. I think we are going through the phase where in last two years, we have seen a lot of things where… A lot of products were started talking about AI without really understanding whether AI is needed for them or not. And we saw some companies dying out. We see some new use cases coming through and we'll continue to see that we are in a transient phase for next couple of years in my mind, before we start thinking about AI embedded into let's say Apple App Store when it came, right? People are generating any apps they wanted, right? And some of them became really popular. Some of them died out. So you're seeing that kind of thing. At some point, you'll start seeing more standardized approaches. Your Google search will probably be replaced with a Gemini search, where you get a lot more enriched data. And that's a good use case. A lot of your... So AI with cybersecurity, think there are AI for cybersecurity and then cybersecurity for AI, right?

So cybersecurity for AI is what we talked quite a bit about, you know, the data exfiltration potential, the vulnerabilities in the LLM models themselves, a lot of shadow AI they're talking about, but people are using it without you knowing, and you don't know what data they're putting in there, how they're using it, what infrastructure it touches upon, what data it takes to train model while you're using it, whether it's your data versus, you know, somebody else's data, the plagiarism.

But I do see, so that is one part that's happening quite a bit. And the trend there is, think we will start seeing more regulations and compliance and controls where we, that's the only way we will be able to standardize, think, right? Because no two companies are really doing similar things, but compliance doesn't really solve the problem. It at least puts everybody on a standard standing. And then, from AI for cybersecurity, I see huge impact in not on the proactive side, protection side, but on the incident response side. I see quite a bit of enrichment of data. We are talking potentially about SOC analysts, level one maybe kind of completely replaced or mostly replaced with AI, which can connect to that can connect to a lot of your applications and data sources and reach that cheap ticket that you created incident ticket. So the analyst comes, he doesn't have to spend two hours to to get the data. already there. You get all the logs, right? You have all that stuff. You're also seeing the approaches where detection is much faster because you can embed a lot of that intelligence in some of your applications. So before even they go to the log management system like a SIM solution, you can actually detect certain things and block certain things. My dream is to see some kind of automatic segmentation of network or at the least a zero trust model that is driven by AI to block certain accesses, right? On the fly based on the behavior. I think that is where I see a huge value. Especially for huge large enterprises that have a massive difficulty in identifying their assets, patching their systems, restricting the accesses. So I think that is where I would like to see it. Somebody has to solve it, hopefully. Somebody will be looking into it already.

Host: No, that's a very good use case. And before I talk about that, I think you said a very important thing, right? During the first few years, most folks were just trying to play with AI, just trying to do something without even knowing what exactly they're trying to achieve. Like it was more like we have a solution now we are trying to find a problem. versus starting from a problem, right? So it makes sense. Another thing is, unless you have the use case nailed down, you would often be just wondering what you are trying to figure out, right? You're just experimenting without a clear end in a way. So yeah, that also makes a lot of sense. So.

This is a great way. I know that you shared a use case, the SIM use case as well and the SOC use case that you mentioned. Hopefully somebody is building it already so that we'll have a solution soon. So yeah, that's a great way to end the podcast. But before we do, I have one last question. Do you have any learning recommendations for our audience? It could be a blog, it could be a book, it could be a podcast or anything that you would want our audience to take away from this.

Ashish Garg: There are way too many books to be very frank with many too many people but I think Brian Krebs have a blog Ross Hallulik. I think I really respect what he writes very open so I read his blogs and he's a friend so I mean it's just amazingly how he wrote his he wrote a book and then now he writes his blogs very detailed blogs another thing I would recommend for anybody newcomer would be to if you do not have a degree in cybersecurity, at least try to get a certification. It doesn't really get you a job per se, but it helps you understand the security management piece quite a bit, how different components work, so CISSP, CISM. I think I'll close it on this note. It's not the unavailability of resources; it's the willingness of the person to spend time and effort.

There's so much available free of charge to learn today. All you need is a computer and internet, right, or a public library. It's just you need to be willing to learn and you should be spending effort and time to do that. What, yeah.

Host: Yeah, that's a great point because most of the times it's not about resources, right? If you try hard, you will get a ton of resources. It's about your willingness. Yeah, you're absolutely correct. And yeah, that's a great note to end the podcast. Thank you so much Ashish for joining and sharing your knowledge, how you have transitioned, what leadership principles you have been using and how can those be utilized by our audience to build a better security program.

Ashish Garg: Thank you so much. It was really nice to talk to you.

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