Interview with Awwab Arif

[00:00:00]

Pratik Roychowdhury: Hello, and welcome to another episode of Prosec Decoded, the podcast where we dive into how product security and AI are evolving in fast-paced enterprises. I’m Pratik Roychowdhury.

Chiradeep Vittal: And I’m Chiradeep Vittal. Today’s guest is Awwab Arif, an award-winning CISO and a respected voice in the cybersecurity community. He currently serves as SVP, Managing Director and Chief Information Security Officer at Bank of Hope. With over two decades of experience across information security, technology risk, and compliance, Awwab has built and led security programs at scale, aligning them with business goals while managing complex regulatory and threat landscapes.

He served in leadership roles at major financial institutions and actively contributed to the industry through advisory boards, speaking engagements, and peer councils.

Pratik Roychowdhury: Awwab brings a practitioner’s perspective on securing modern enterprises [00:01:00] today from policy and governance to real world implementation of security controls, threat modeling, and risk reduction at the pace of business. In today’s episode, we explore everything from threat modeling and remediation to emerging AI risks and dev sec collaboration.

Let’s jump right in.

All right. Awwab, welcome to the show. Great to have you on the pod today.

Hey, how are you doing?

Good. , So well, , let’s get started. , Maybe before we jump into the main content, , let’s , start a bit with your career journey. , Obviously you have led. As teams, , you have started off your journey more on the security engineering side and grew into an executive leadership.

Would love to hear about your career journey. What drew you into cybersecurity and what’s kept you here?

Awwab Arif: Yeah, definitely. , So yeah, , like you said, , I’ve been in the industry for a little while and basically my [00:02:00] career journey starts from engineering background. So I used to do a lot of server admin type of stuff, supporting smaller organizations with their, IT needs, getting their workstations off, set up and everything.

That’s where I started, but the reason I even started doing that was because as a child growing up in a household of engineers, both my uncles and my dad, they’re all electrical engineering background. All they did was, computers. So growing up, in the eighties, we’re surrounded with technology around the house.

ISDN modems back in 88, 89, were not that common. My dad was running one at the house to basically VPN into, and it was not to access internet. ‘cause internet didn’t exist back then. It was to actually access resources at the research company that he used to work at. So being surrounded with technology, that was like my safe zone.

I always enjoyed being there because my dad would show me [00:03:00] all these things. That’s where the attraction started, I guess, right towards technology. And then of course when I started my career initially I graduated with a business administration degree. So I was actually, going into the business side where I wanted to like, become just like you guys, a startup kind of thing where I can actually launch a business and, be my own boss.

But very quickly realized that, you need funding, you need this, you need that. So I was like, okay, maybe W2 is a way to go. So I started, looking for jobs and of course I could go into, living in New York at that time, I could have gone into the financial sector and done a lot of things there.

But technology being my, strong suit, I was like. Maybe I go into tech, right? And that’s where I started working in the technology industry. My full-time security specific job was at East West Bank. Prior to that, I was just like, Jack of all trades, do everything. ‘cause a lot of organizations [00:04:00] can’t afford to have too many engineers and too many different distinct job roles that you are going to be only responsible for this.

So I was literally doing everything for the other organizations. At East West Bank they were building out a security group. I was part of a team of three. We did not have a CISO back then. And it was like early program development sometimes they say that, right place, right time.

For me, that was a very good learning opportunity because I literally saw a program being put together from scratch. So I was able to absorb a lot of information and then a lot of the responsibilities that were maybe within IT started to basically be separated that we need this in line too. For instance provisioning deprovisioning of access, it was under IT. But we need governance, so we need some sort of, distinction in those roles. So we started separating those and, over the nine, 10, almost 10 years, and I was I was at East West Bank, it just one opportunity after another where, I [00:05:00] was able to step up and take on more responsibility. By the time I left East West Bank in 22 I had already been, serving as the CISO there for almost a year and a half, two years. And then I joined Bank of Hope and I’ve been here for a little over three years now. Doing the CISO job here at Bank of Hope. So, that’s in a nutshell, the journey.

Pratik Roychowdhury: Well, that’s actually a fascinating journey, and one of the things I was thinking of asking you is if it was not for cybersecurity, what would it have been? And you basically said it probably would have been entrepreneurship. Right?

Awwab Arif: Yeah. And, and to be honest, I haven’t given up on that. Okay. Okay. Yeah. But, but I have responsibilities.

I have, kids that I gotta make sure go to school. Absolutely. But the moment that responsibility is gone, I, I’ll be back in the market looking for, some entrepreneurship.

Pratik Roychowdhury: That sounds great. Obviously entrepreneurship, Chiradeep and I, we are living through it. It’s, [00:06:00] it’s quite exciting.

And I guess, so is cybersecurity right now. Oh yeah. But I, I, yeah. But I would like to also hear about as you moved from a more hands-on role to a more strategic executive leadership role, how has your view of cybersecurity in general, and maybe some things about product security that you have seen, how has it evolved over the years?

Awwab Arif: There’s definitely a big evolution and sometimes you have to also check yourself to say that, Hey, am I getting way too involved in the weeds? Because, wherever you came from is your strong suit. So engineering being the strong suit, sometimes you wanna go to the nitty gritty and start working with the engineers to develop the solution.

But then you have to also remember that, hey, maybe you have to allow them that flexibility to be able to do their own, thinking and coming up with solutioning. And yeah, you could question it, you can, sit down and have a discussion on how they approach something and how they are addressing certain criteria.

So that was definitely one of [00:07:00] the learning experience for me, where I had to distance myself from the day to day and getting way too deep into the weeds. The other thing that, my mentor, Mitchell Sherman, who used to be the CISO at East West Bank, taught me, was communicating to the executives in the business in their language. Being an engineer, I would get way too excited and I’ll start talking about technology and it’s going over their head. And honestly they don’t need to understand that, deep, technological understanding to be able to say yes or no to a certain initiative that you’re trying to push.

They need to understand what the risk is. How does that impact the business? How does it, improve or enhance the user experience? And basically they, that’s enough for them to be able to make a decision. So that was something that, he would always remind me that, hey, that email that you just sent you could have written it from a business perspective rather than a technologists. So I would always [00:08:00] take those notes, go back. So I had a lot of good people around me, at East West Bank our CFO was very good at providing feedback. Our CEO was very, good at sending me feedback and making small little adjustments. So that was another area where I had to really learn the difference of being an engineer and being a, executive in the cybersecurity space.

Chiradeep Vittal: Yeah, I think, uh, what, what a lot of what you said resonates with me. I too grew up in a family of engineers and communicating up to executives was a lesson I had to learn early in my career. But let’s talk about product security, and let’s start with definitions. When you hear product security, what comes to mind and what does it mean in the context of your organization, fast moving, modern engineering organization?

Awwab Arif: Yeah, so product security and I, gave you some thought in regards to being work. Working in a financial institution, it’s a little bit different than, maybe someone that is [00:09:00] in the technology space. In banks, typically we’re not developing a technological product.

Our products are usually business centric, customer centric, where , those solutions, when they’re being developed, it could be that they’re not even doing the development in-house, they’re actually working with a third party and, acquiring a solution that’s already prebuilt. So we look at it a little bit different, than if it was a company that was actually developing technology in-house. Because when you’re developing technology in-house, there is a whole ideation stage, where people are discussing the idea how they’re gonna deliver that particular product. So being involved in that helps you understand exactly what the product will do and then how you can actually, bake in the security to the solution. When you’re doing the other aspect where, you are basically acquiring a technology from a third party, a lot of those details are now missing, because you are basically purchasing a technology, so you have to put the [00:10:00] security on it.

It’s not baked in. Yeah. Yeah. So it’s bolt on versus baked in. So Bo both things apply in our world in the banking industry, especially in the mid-size banking industry because we do some development where, things are being built from scratch within the organization.

At East West Bank, we were launching the digital banking platform. So a lot of that development was happening in house. So, that whole stage of ideation, baking in, talking about SDLC, talking about coming in with security controls upfront, ahead of time, so that way even the developers have an idea that, okay, this is what, the security team wants.

So how can we bake this into our product as we’re building it? Whereas, the other component requires a lot of contractual agreements. So third party risk management plays a big role where we have to be embedded with them to, put in appropriate language in the contract that gives us if, let’s say we are not allowed to pen [00:11:00] test their product, can we at least get a third party attestation, like a SOC 2, type 2, a penetration test summarized executive report that shows us that, hey, 10 things were identified and they were fixed within this time period and validated. So that way we have some sort of understanding that their product that we are purchasing is being, vetted from a security standpoint. So yeah, there, there’s two ways we look at product security.

Chiradeep Vittal: And so, and when you walk into, let’s say a brand new organization, how do you assess the maturity of their product security program? Are there any standard examples where you’ve seen it done well?

Awwab Arif: Yeah it’s a developing space. So we, we always keep talking about shifting left, and then once we get to that, then we realize that there is further left, we can go. Yeah. And then we start shifting. So I wouldn’t say that, like I’ve been to an organization where it was like, yeah, they had done it and there is no room for improvement. I [00:12:00] think what it comes down to is having a good relationship with your development team, with your engineering team, so that way there is always a constant dialogue on how we can make things better. An example I can give you is, and developers and engineers can definitely relate to this, is that if security is not being consulted early on as early as possible, what ends up happening is that they have developed something.

Now they’re coming to you for approval, which is part of the change management. You are like, well, I need this, this, this, and this to go in. Now all of a sudden they didn’t bake in enough time to be able to go remediate or address some of these issues. They’re gonna be delayed on their project. So they started to bake in some time. They were like, okay, you know what? We need to have information security do their review. So we’re gonna allot, this many weeks where, one week is the ideation stage where we’re talking to them and, getting all the requirements set, maybe another week or two when , they’re able to actually test those controls to make sure that they are in place, allowing [00:13:00] themselves a little bit of time for remediation and then a validation stage for us.

So they started baking all this into the project timeline. Now with Agile, you can’t do this. When you, because this is waterfall. It works. You bake in a couple of weeks, couple of days here and there, and then, you’re able to meet your deadlines. But when it comes to Agile and you’re pushing an update every week, now you need a faster approach.

So then we started to automate a lot of these things. We’re like, okay, you know what? You already know the set of controls that are documented in our SDLC standards. So, you are going to work with that, but then we’re also going to give you access to our, SaaS solution, for example, where, we’re scanning the code, giving you live feedback , within your IDE as you are writing the code so you can address those issues as they arise.

And you will have an idea that, hey, once I send this for a, a dynamic scan for a DAST scan and for a security team’s review, all the identified issues at least have been fixed, right? So now there might be [00:14:00] minor things that information security might come back with. So you don’t have to , really rush and spend a week doing some development so that.

Agile methodology definitely changes your, perspective on how you are doing product security. So we were able to accomplish that with our digital banking team at East West Bank, where they were using Agile as their development strategy. Whereas, or the traditional development that was happening at East, west or even at Bank of Hope was more waterfall.

Chiradeep Vittal: Yeah, so certainly, , tooling and then, , a rigorous, well-defined process seems to be the cornerstone of a good product security program. And you mentioned shift left and, uh, one of the things that we’ve heard a lot about is threat modeling and, uh, but haven’t seen or experienced good threat modeling, uh, done in a, continuous fashion myself.

And the other one is, uh, red teaming, which is like, once all [00:15:00] the tooling, all the SAST and DAST has gotten through the listing out the issues and it’s been fixed. Now you wanna do and actually test it out in real world scenarios and see if it’s actually robust enough to handle real world attacks.

So where do you see the role of threat modeling and red teaming in a product security strategy?

Awwab Arif: So threat modeling is more on the left to me, whereas the red teaming and pen testing becomes more towards the right, because the product is almost ready now. It, maybe it’s in UAT stage, where the business is testing for functionality.

But you are also doing your security assessment to make sure that these products are not vulnerable. So yeah, threat modeling I think is a very important thing, because the thing is that if you’re developing a application that is going to be hosted internal to the organization, no public footprint, then maybe your approach to security is going to be different. We are not gonna be as stringent [00:16:00] in fixing all the issues before it goes into production as you would be talking about a public facing application. So from that standpoint, I would say that threat modeling definitely helps because then you understand, okay, you know what, these particular types of threats are not relevant, given the condition that this product is going to be in. So we don’t need to focus all of our energy trying to fix everything, but these are the threats that are relevant to this particular product. So let’s focus the energy, get that done. We can still fix the other stuff, but it’s not going to be the highest priority.

I I talked about the, the agile methodology where time is so narrow, the window. Depending on how quickly they’re releasing, they could be releasing every three days so now you have to squeeze all of this within three days period, if it’s one week, you have to do it within one week.

So threat modeling becomes extremely important there because then you’re having the developers [00:17:00] focus on things that matter and then they can spend their time fixing the other issues in the next release. Because it’s not relevant, but you still wanna address those. So it, it helps with prioritization, being able to establish SLAs where they are able to meet that expectation.

Because the biggest challenge that, a lot of security teams run into is you do your SAST scan, your DAST scan, you dump a whole load of vulnerabilities on the developers. And then you have your SLA established, but no prioritization. So the developers are like, this is a lot , where do you want me to start? Where do you want me to end? And, the way the, the whole structure goes is that vulnerability remediation, although important, but it’s definitely not from a developer standpoint a priority to them because their mandate is to develop the product and launch it and deliver to the business. Their, mandate is not to fix security issues. Of course, from a organizational standpoint, you can make that a requirement that, [00:18:00] hey, as a developer you have to make sure that you’re developing secure product and deploying. But at the end of the day, the business unit is not gonna, be happy if it’s completely secure, but it doesn’t do what they asked for it to do.

So the, that, that’s like always a challenge. So being able to threat model. Prioritize, establish SLAs with the developers. It helps them address the issues and keep the, machine moving.

Pratik Roychowdhury: So Awwab, I think on a slightly related topic, but something that you and I, we have talked in the past about quite a bit is remediation and you also referred to that just just a little bit ago.

One of the things is that we have constantly been hearing that, don’t keep finding problems. Just find solutions to that and that remediation becomes quite beneficial. So maybe I’d like to hear your thoughts on remediation, the value of it. Why is it critical, and maybe why is it so challenging?[00:19:00]

Awwab Arif: Yeah, so just like I said if you’re developing, a hundred issues and sending it to the developer without any prioritization or even how to remediate, then it becomes a challenge for the developer. Not only do they have to figure out the, the solution, they have to then test it.

Then, of course prioritization is part of that equation that, okay, I have a hundred issues. These are the a hundred possible solutions, and this is, my testing strategy. But which one do I fix first? Of course there is criticality assigned to each vulnerability, and they can start with that, but the criticality of each vulnerability alone is not enough.

So to Chiradeep’s point, when you bring in the threat modeling, now you’re able to add another dimension to that and say, okay, yeah, it’s a critical vulnerability, but because you’re not public facing, I’m not going to count it as critical. I’m gonna lower the priority on this. You can fix this later.[00:20:00]

But there is a authentication issue where, it doesn’t matter if it’s public or internal. If you can’t distinguish and authorize a user properly, then you’re going to have accountability issues in terms of who made this change, who made this wire transfer or whatever the situation might be.

So in that case, that needs to be fixed because from threat modeling perspective, we’re gonna raise that. So even if it was, a high, now we’re gonna make it critical because it’s a, a bigger issue and it needs to be fixed immediately. But the component that you were bringing to the table Pratik and is becoming more and more relevant because I’ve run into a lot of service providers or, products that are being developed from security startups that are focusing on this.

How do you remediate this vulnerability? Because now developers don’t have to spend all this time trying to figure out a solution if we can actually give them a solution alongside the detection of the vulnerability. [00:21:00] So with the use of AI a lot of products I’ve come across I’m not sure if you guys wanna mention any names here on the podcast because these AI solutions are able to actually go to these, sub stacks and all these other places where, people are kind of discussing these things, pulling that information together and giving you a code that you can then go and, implement to remediate the issue. So now your window of research shrank.

Because you are being presented, Hey, these are the three possible solutions. So you don’t have to go scour the net, call your buddies and ask, Hey, how did you address this? Have you come across this kind of issue? So that being presented to you now you have to just focus on the testing piece.

You apply the fix, you test it in your dev environment. If it works great, you move to production. So I think that piece is definitely a key component in improving our remediation [00:22:00] timeline and helping our developers actually get their job done in a very efficient way.

Pratik Roychowdhury: Right. And, and remediation the way at least I was thinking about it as more in terms of a, you can remediate something in the code.

So, if you find a vulnerability, fix that in the code. The other is when you have put that application in production, how do you put in the compensating security controls and somewhat remediate that.

Awwab Arif: Yep. And that definitely is part of that, security team of course without this automated remediation, options. Security teams would sit down with a developer and offer them, okay, you know what, if the code route is not available to us, then what are some of the mitigating or compensating controls we can put in to be able to protect against this particular vulnerability? So yeah that’s definitely part of the equation and that is being presented as part of the solution.

So code is not the only way I use that as an example, but these [00:23:00] AI based solutions are also coming back and saying, Hey, you might want to consider X, Y, Z.

Pratik Roychowdhury: And while you’re talking about AI one of the other things that we keep hearing, and there are two schools of thoughts. One is, hey, do not do any kind of auto- remediation.

Just give me, recommend me solutions. And the other is that yes, I, there is so many things to be done that, yeah, do a bunch of auto- remediation. So I would like to hear your perspectives on that and see what has been, what has worked well with you.

Awwab Arif: Yeah, so automated remediation is a organizational risk appetite question.

Organization to organization you will run into different things. Some organizations are a little bit more, open to the risk and they will say, Hey, I would rather have efficiency in terms of being able to push these, remediation out automatically. And some organizations, they’re a little risk averse where they don’t want to have an outage or [00:24:00] some sort of operational issue because the change was automatically pushed out. And to have that little bit of a gatekeeping, if you wanna call it. So it’s like semi-automatic where it will literally have everything ready for you, but a engineer or a developer will review it and say, yep, I agree.

Push. And then they would just approve that push. So it’s semi-automatic. And I don’t think I’ve come across in any situation opposed to the semi-automatic, but I have definitely come across places where they were like, no, no way we’re going to do a fully automated push. Because it was just not the organization’s way of doing things.

Pratik Roychowdhury: It’s almost like the self-driving levels. You want some sort of cruise control, but you do not want complete at autonomous.

Awwab Arif: That’s a good one. You don’t. That’s a good one. Yeah. I can’t trust a computer to drive me. Right.

Chiradeep Vittal: Yeah. Yeah. Speaking of AI, you know, we are seeing it [00:25:00] reshape both the attacker and defender side, and what are some of the more interesting ways that you have seen AI being used? In cybersecurity.

Awwab Arif: There are a lot of good use cases. And then of course, like you said, threat actors are also using it. And the, I think the challenge that, the quote unquote good guys run into is. We have to do things by the book. Mm-hmm. So we can’t just jump in, head in and just, explore.

Whereas on the threat actor side, they don’t have any of those guardrails. They don’t have a policy or a standard to follow and, and, say, Hey, this is not ethical. Or maybe there is this compliance issue or some legal concern. They just go head in. So I think that definitely is one area to keep in mind when we talk about AI. In terms of the use cases for AI, there is a lot of good stuff that we’re coming across. And because of this really big push towards AI, we’re seeing a [00:26:00] lot of startups, a lot of, even existing vendors that we use product services that are going in that direction.

So keeping the compliance, the legal, the security and all those, different risks in mind, we have to, of course, review and approve each one of the use case. The use case that comes to my mind right now that we were recently looking at was taking 40, 50 pages of documentation, and analyzing it according to the local laws, federal laws, and making sure that all the check boxes from a law perspective are presented within that 40, 50 pages of documentation. And it is relevant if something is missing, what is missing. That just speeds up the process to a point where, if a human was reviewing those documents to make sure that, we are in compliance, or new account that we’re opening meets all the requirements, [00:27:00] would take them maybe half an hour, 45 minutes, an hour to review. And then they have to check. According to the local law where the customer is, so Hawaii, California, New York, all states have different requirements, checking against that law and then understanding what is missing and what is required for them to be able to open an account or maintain an account with us would be hour, maybe even more of time by one analyst. This system can do it within seconds. You’re literally scanning all this document. Pushing it into the product and it’s spitting out and saying, Hey, these two pieces of information is missing, please request the customer to submit that.

Now of course, the individual is still reviewing all of that. Yeah, the material that is being presented by this AI solution. But you cut down , hours worth of time to 30 seconds. So efficiency, you can’t argue that. There are of course, legal and compliance related concerns that you would still have that, how [00:28:00] accurate is this AI platform?

So we have to, of course, do some KPIs on the backend to keep checks on that. And at some point, if it’s good enough, we could just fully automate that. And say, you know what account opening or maintenance wise, if all the boxes are checked and we know for a fact that it’s a hundred percent accurate in making this assessment, then human intervention is no longer needed at that point.

Chiradeep Vittal: Yeah, absolutely. And uh, certainly we feel that, um, structured or unstructured documents is one place where AI really shines. Um, a lot of the, uh, structured use cases, SQL will still beat AI, but, uh, nothing beats uh, AI when it comes to unstructured documents. And you did mention that. Mm-hmm. Using, using. AI in the product. Right. So, flipping the lens, when your developers are choosing to use AI to, improve business [00:29:00] processes or, reduce account opening time or whatever, what are the security risks that those teams should be thinking about?

Awwab Arif: So your question is in regards to the developers using AI to write code. Is that where you’re

Chiradeep Vittal: Not write code, but , like you mentioned the feature, which reduces account opening time because it does that analysis, which a human would do.

Awwab Arif: Got it.

Chiradeep Vittal: And so they’re making an API call to an LLM saying, Hey, can you analyze these documents for us?

Awwab Arif: Yeah, so that would be a different use case, because the example I was giving you, this would be a third party solution that’s doing the analysis. So we wouldn’t be sending our documents over to that, but, we could use copilot as an example. Yeah. Microsoft.

If you are a E five, E three, licensee subscribe to them, you have access to copilot. And of course if you wanna upgrade to the professional version and or enterprise version, whatever it’s called, they change their names a lot. You can always license that out. That would be a good example of what you were [00:30:00] just referring to.

So in terms of security there, the concerns that we would have from an information security standpoint is where is this data being stored? When you’re uploading all these documents. How long is it stored there? Is this going to be something that is, being used to train the larger model and then output to other people outside of the bank.

So if it’s public and it’s training their larger model, then of course we would have restrictions on what kind of documents you can upload. So in terms of classification of the document, we would say, okay, public documents are okay to be uploaded because this particular platform stores data and it has basically the ability to train the larger language model with that data that you’re inputting. And we don’t know how long it would be stored,. It might be indefinite. So in those cases, maybe public documents are uploaded. Now, if the use cases where they wanna [00:31:00] upload something that is

internal or confidential restricted, then we might want a platform that is not training a larger model. Maybe it’s even hosted by us. And not by a third party. So those kind of considerations come into play for that type of use case.

Chiradeep Vittal: Yeah. Sounds like a lot of the basic data hygiene that you are already practicing, you need to take it up a notch.

Awwab Arif: Yeah. Every time, like, and that’s a good point, Chiradeep. Every time , a new technology solution, anything that comes our way. Cloud, couple of years ago, about 10 years ago when it was the big thing, everything was going into the cloud and cloud storage and OneDrive and Google Drive and all this was , just and everywhere and people who are just uploading stuff in these platforms. The thing that I reflect back on is that the fundamentals never change. Yeah. The data hygiene, the authentication, the authorization, all those components are pretty, what [00:32:00] do you call it, common across all of this.

Now, how do we apply that changes. When we used to have the structural organizations where, it was like a fortress, everything was inside, we were doing same type of stuff, but in a very different way. Cloud becomes now you have to okay, I can’t do firewalling around everything, so maybe I have to do something around access control. The accounts that are there maybe multifactor becomes more prominent. Because we have this particular application hosted in the cloud, accessible from anywhere. Maybe some IP filtering goes into place. So I think the fundamentals stay the same, it’s just that how do you apply them kinda morphs. So with AI I wouldn’t say there is something very unique on how we would secure it. All those ideas and fundamentals have existed in the past is just applying them in a way to be able to protect the organization.

Pratik Roychowdhury: I guess switching gears a little bit into one of the topics that we have heard time and [00:33:00] time again is how do you how do people come together, which means the development and security team.

There is some amount of friction sometimes because you want to enforce policies, but you don’t want to slow down innovation. Any thoughts or perspectives on how organizations can tackle that problem of dev sec collaboration. What are some of the best practices you think could work well?

Awwab Arif: Yeah, there’s no magic answer for that, but what I would say is I think what has worked for us is having empathy. Understanding what the developers main, target or task is . And then also explaining to them why it is important to have this partnership with information security team.

A lot of times because people are busy, they will just, write some scan, automated scan and send a automated report over to the developers. I think that’s not the best way to do it [00:34:00] because what ends up happening is that they’re like, man, these guys are just sending us stuff without even reviewing.

They don’t even understand what the issue is. They just bought the scanner and the scanner is just giving me this report. I think sitting down with the development team as you’re selecting the solution having them being part of selecting the solution because they have their own, things that they might wanna know about before you go and purchase the solution.

Then working with them to develop the report. In a fashion that they can understand and they can prioritize, they can, go and take actions. That definitely builds synergy. I’m not saying it’s gonna make things very, fluid, but it will definitely make them better. Where the development team at least understands that, hey, these guys are not just tossing out a port over and having us fix it because you had done all that due diligence, working with them, allowing them to be part of a decision that your team is ultimately [00:35:00] responsible for selecting the tool report frequencies, how the report is, presented to them. Do they want their tickets in, jira, do they want their tickets through snow?

Working with them on all those pieces. And then of course, allowing the ability to have discussion on things where you mentioned earlier Pratik, that all the solution is not always to go and make a change in the code. There is sometimes some compensating and mitigating options that are on the table.

So if the developer comes back and goes, Hey I get it. There is a way to fix this in the code, but it’s gonna take me three weeks to get to it. And I understand it’s a critical issue. Can we do something else? Working with them and putting that mitigating or compensating control basically gives them that understanding that, hey, these guys are not just tossing work over.

They do understand and they have some empathy. I think that definitely helps build the better relationship and a more cohesive [00:36:00] yes, I guess remediation program or application security program.

Chiradeep Vittal: And I think, cybersecurity is so vast and multifaceted that, even just a little thing like human collaboration becomes a critical part of cybersecurity, that it makes or breaks the whole program.

And if you. If you, if a new CISO came up to you and says, Hey, this is my first go at this, this is my first time as a CISO, what would your number one piece of advice be?

Awwab Arif: That’s a tough one. It’s very situational. So I’ve had these kind of conversations with folks that were , offered a position to take on a CISO role.

Myself a lot of my, friends and mentors, would tell you that when I was presented with the opportunity to be the CISO at East West Bank, I actually took that as a temporary year old. I did not want to take that responsibility because I [00:37:00] understood what it comes with. There is a lot of liability, there’s a lot of responsibility that comes with that.

So I took that as a temporary role. And then once I, felt comfortable, I had the right support around me, from the executive team, I actually decided to stay permanent. But my deal was that if I don’t like it, I go back into my role of just managing the engineering and the operations group, and then someone else takes care of the rest of it.

But yeah, when people come to me the biggest thing that I tell them is, figure out what kind of support you’re gonna have around you. Because a CISO’s job becomes almost impossible if management is not supportive. If they see that as just a, operational thing that they have to do is a checkbox, and they don’t see it as a critical component of the organization, then it’s very difficult. So I think that would be, if I had to give one advice, that would be the main advice that, figure out what kind of support you’re going to have if you take that role on. Number of issues, [00:38:00] regulators, internal audit, external audit, all of that is outside of your control.

You are gonna get issues. You are going to have people come in and say, Hey, you’re not doing this right or you’re not doing that. All of that from organization to organization is gonna be different, but if you have the support, you will be able to fix those issues. So I think that support is the key component.

Chiradeep Vittal: Okay. And, uh, looking ahead, what part of cybersecurity are you most optimistic about and is there anything that keeps you up at night?

Awwab Arif: I think that part I lost a long time ago. I go to sleep very well because typically it’s just you’re so tired, you pass out. So nothing is keeping me up at night.

My kids are a little bit older too, so that’s not keeping me up at night either. Now the optimistic part I think , a lot of, we were talking about AI a lot, a lot of the stuff that we do, especially when it comes to [00:39:00] operations, and sure, the you and I actually even had a discussion in the past, I, I believe it was like almost a month ago, where we were talking about doing pen test in automated fashion using AI and doing it constantly. All that stuff is the optimistic part because if I can get. Continuous monitoring of my control sets, of vulnerabilities that might be, exposed to my organization, my whole vulnerability management program changes because now I’m not going to say that, Hey, we have these SLAs and you have to fix everything within these SLAs.

And there could be 10,000 vulnerabilities being announced every patch Tuesday by Microsoft. But with, a continuous pen testing program, what you could do is you could say, okay, whatever is showing up on this report has to be fixed within 24 hours. Everything else we will relax the SLAs for.

So I think tho those things are very optimistic. In terms of being able to take actions [00:40:00] quickly, being able to remediate issues quickly because we have this set of technology in front of us. Those are some of the optimistic things.

Chiradeep Vittal: Okay. Yeah. Awwab this was an incredibly thoughtful conversation.

Uh, thank you for joining us and sharing such grounded insights from the field.

Pratik Roychowdhury: Thank you, Awwab. It was a lot to learn and I’m sure that our audience will learn a lot from this. So thank you for your time.

Awwab Arif: Thank you for having me.

Pratik Roychowdhury: And to our listeners, if you enjoyed this episode, don’t forget to subscribe, share, and check out more conversations on ProdSec.tv.

We’ll be back with a more real world perspectives at the intersection of product security and AI. Until then, stay secure and keep building.