Kush Sharma joins Sean Martin on the Redefining CyberSecurity Podcast to explore the nuanced challenges of building a CISO office from the ground up, detailing his experiences across diverse sectors including government, private, and consulting. Tune in to this Part 1 of 3 Parts to gain actionable insights into managing enterprise risk, aligning cybersecurity with business objectives, and navigating complex bureaucratic processes.
Guest: Kush Sharma, Director Municipal Modernization & Partnerships, Municipal Information Systems Association, Ontario (MISA Ontario)
On LinkedIn | https://www.linkedin.com/in/kush-sharma-9bb875a/
____________________________
Host: Sean Martin, Co-Founder at ITSPmagazine [@ITSPmagazine] and Host of Redefining CyberSecurity Podcast [@RedefiningCyber]
On ITSPmagazine | https://www.itspmagazine.com/sean-martin
___________________________
Episode Notes
In the latest episode — Part 1 of 3 Parts — of the Redefining CyberSecurity Podcast on ITSPmagazine, host Sean Martin dives into a comprehensive discussion with Kush Sharma, a distinguished leader with vast experience across Accenture, Deloitte, the City of Toronto, and CP Rail. The conversation explores the intricacies of building a Chief Information Security Officer (CISO) office from the ground up, offering invaluable insights for current and aspiring CISOs.
Kush Sharma emphasizes the multifaceted role of a CISO, particularly the distinct challenges faced when establishing a cybersecurity program in various organizational contexts—government, private sector, and consulting firms. He points out that in governmental environments, the focus is typically on how to benefit citizens or internal staff while operating under tight scrutiny and budget constraints. In contrast, consulting and private sectors prioritize efficiency, quick deployment, and direct benefits to the organization.
A significant part of the discussion centers on enterprise risk management. Sharma highlights the importance of aligning cybersecurity initiatives with organizational objectives. From mergers and acquisitions (M&A) to digital transformations, CISOs must ensure that their strategies mitigate risk while supporting the broader business goals. Kush Sharma advises that during such major projects, security measures need to be integrated from the ground up, focusing on things like role-based access and the segmentation of business processes.
Additionally, the challenges of engaging with governmental bodies are explored in depth. Sharma explains the extensive bureaucratic processes and the need for consensus-building, which often lead to significant delays. Understanding these processes allows for better navigation and more efficient outcomes. Sharma also brings out the importance of understanding and acting upon business processes when integrating cybersecurity measures. For instance, in large-scale ERP implementations, it is crucial to map out detailed roles and ensure that security provisions are applied consistently across all integrated systems. By focusing on the distinct roles within these processes, such as AP clerks or accounting managers, CISOs can develop more granular and effective security measures.
The episode underscores that success in building a CISO office lies in strategic alignment, efficient resource allocation, and thorough understanding of both technical and business processes. For cybersecurity leaders, this conversation with Kush Sharma offers crucial guidance and real-world examples to help navigate their complex roles effectively. Be sure to listen to the episode for a deeper dive into these topics and more. And, stay tuned for Parts 2 and 3 for even more goodness from Sean and Kush.
Top Questions Addressed
___________________________
Watch this and other videos on ITSPmagazine's YouTube Channel
Redefining CyberSecurity Podcast with Sean Martin, CISSP playlist:
📺 https://www.youtube.com/playlist?list=PLnYu0psdcllS9aVGdiakVss9u7xgYDKYq
ITSPmagazine YouTube Channel:
📺 https://www.youtube.com/@itspmagazine
Be sure to share and subscribe!
___________________________
Resources
___________________________
To see and hear more Redefining CyberSecurity content on ITSPmagazine, visit:
https://www.itspmagazine.com/redefining-cybersecurity-podcast
Are you interested in sponsoring this show with an ad placement in the podcast?
Learn More 👉 https://itspm.ag/podadplc
Building a CISO Office: Mastering Enterprise Risk Management and Aligning Cybersecurity with Business Goals | Part 1 of 3 | A Conversation with Kush Sharma | Redefining CyberSecurity with Sean Martin
Please note that this transcript was created using AI technology and may contain inaccuracies or deviations from the original audio file. The transcript is provided for informational purposes only and should not be relied upon as a substitute for the original recording, as errors may exist. At this time, we provide it “as it is,” and we hope it can be helpful for our audience.
_________________________________________
Sean Martin: [00:00:00] And hello everybody, you're very welcome to a new episode of Redefining Cybersecurity here on ITSB Magazine. This is Sean Martin, your host. As you know, if you listen to the show, I get to talk to cool people about cool stuff. And, uh, it doesn't get much cooler than the role itself, the CISO role. Right. To where everything kind of comes together and hopefully it connects back to the business.
So we, so we can enable the business to operate securely. And, uh, unless you're, unless you take a role at a, at an, at an existing company, um, you're, you're starting to start in the program from scratch in many cases, especially startup organizations are a number of those. And even if the company has been around them for a while, it doesn't necessarily mean they have a cyber program.
So we're going to talk about what it takes to. Get a program running, get a CISO office in place, get all the, uh, the budgeting and the planning and the approvals and [00:01:00] the support you need to be successful. And I'm thrilled to have Kush Sharma on. How are you?
Kush Sharma: I'm doing well. Thank
you
for inviting me to speak to the community.
I appreciate it.
Sean Martin: Yeah, my pleasure and I'm excited for the community. We had a chance to catch up the other day and, and, uh, you have quite the, quite the breadth of experience and a lot of insight. Now you're on, you're out speaking as well. And, uh, If I recall correctly, we, it was, well, certainly for me, it was difficult to figure out what do we focus on first because there's so much involved, right?
And you have so many experiences. Um, but as I alluded to at the beginning of the show here, that, uh, we'll focus on what it takes to build a, build a program and build a CISO office. And, uh, we'll see where that conversation goes. It's going to be fun. Um, hopefully there are. CISO's listening that, uh, can take a few nuggets, maybe comment with their own nuggets.
And certainly there are folks, [00:02:00] practitioner and management roles that want to be a security leader that, uh, hopefully will find this valuable as well. So Kush, maybe a few words from you, um, some of the things you're up to and, and what you're, yeah, your current role, what you're up to at the moment.
Kush Sharma: Yeah, no worries.
I was, uh, Working for, uh, Accenture and Deloitte for many years, for about 15 years, traveled the world, did many projects, then I went into industry to get that experience. So I built up the organization at Saputo, then at the City of Toronto as their inaugural CISO, and then at CP Rail as, uh, as their CISO, uh, intern.
And then I started my own firm. Night Spectre focused on executives, focus on boards, mayors, counselors, politicians, and advising them on matters of cybersecurity. So very strategic. And I'm on the speaking circuit as you could, uh, as you well imagine. Uh, and, uh, I'm just ramping up [00:03:00] for, you know, specifically podcasts and other community events so that I can give back, to do a lot of, uh, a lot of volunteer and charity work for various, uh, community members.
And so I'm excited to be here, excited to talk about the experiences. Uh, hopefully it helps the community and strategizing on how to get a budget, how to start up an organization, etcetera. So thank you again, Sean, and thank you, community, for having me.
Sean Martin: Yeah, it's, uh, it's my pleasure, and I'm, I'm excited for this.
Let's, um, let's start at the, at the city, the city of Toronto. Um, my, my perspective, and this comes from, uh, From trying to sell to, uh, when I worked for a vendor, trying to sell to public sector, I know that budgets are always under scrutiny and they're always tight. And, uh, they often get discounts, uh, [00:04:00] from being operating in the public sector and schools and things like that.
Um, which to me says it's probably harder to put a plan together and to get approval and to get budget and to operate, uh, In alignment with the plan and budget because of all that scrutiny and pressure. So maybe we start there and I don't know one. Is that a correct assumption to, uh, maybe give us an overview of kind of the early days of your work at the city of Toronto.
And we'll, we'll go from there.
Kush Sharma: Yeah, so I think your assumption is correct. It is a challenging environment from a government perspective. And so, uh, You know, I was on the other side, like yourself, couldn't understand why things took so long. And then when I became a government official. I kind of understood all the nuances and all the processes and all the approvals that need to be [00:05:00] done and many times I think it's, you know, based on consensus as opposed to one person making a decision and so you have to understand that.
Certain, at least from the local level, certain obligations need to be met and one is being, uh, registered with, excuse me, potentially with a government agency. So many, at least on the local level, for sure, you have to sign up as a lobbyist or someone who wants to do business with that specific city, for example, or, uh, you know, a state or provincial government in Canada.
Uh, and federal, you know, there's many, uh, RFPs out there, but you might need to be part of a certain, uh, criteria or group. And so you have to do your research first to understand the, the initial requirements just to actually get your foot in the door to actually speak with someone or to actually present something.
Now, the mistake that most vendors make is they called [00:06:00] individuals directly, and that's a big no no in government. And so that can be seen as bribery, collusion, all kinds of things, right? So the individual would be hesitant on replying to your emails, speaking with you, going for a coffee, dinner, lunch, et cetera, because many of the rules in many governments state that you cannot accept that.
Um, specifically meals, right? So if you're trying to buy lunch for someone, it's not going to happen because usually the rule is like 2 or something,
you
know, minimal to avoid. Forget about a day ago. Yeah. So, I mean, there's creative people out there, but generally speaking, I think you have to understand that you have to do your research because not every, uh, town, not every village, not every city is the same.
They have different rules. Uh, the, the provincial or state governments have different rules than the local governments. And then the federal governments, obviously, are a lot more [00:07:00] stringent and a lot more, uh, due diligence is done before you even get to bid, right? They're going to check everything, right?
They're going to check your, if you have insurance, if, if you're, if you're viable for a certain amount of years, how many employees you got, they might do background checks on you because those are more sensitive, uh, projects that you might want to bid for. Okay. So understanding that first and then coming up with the game plan, uh, is probably a better, better approach in use of your time.
Sean Martin: So while we're here, and we can kind of work our way back up and then wherever it goes from there, we'll see, but, um, while we're on this process of engaging, um, between the program and the provider, um, Your experience working for an advisory firm versus for public sector versus for private sector. Um, do the [00:08:00] requirements change in terms of how you look at the program and how you define what you're trying to accomplish?
Um, is one more. Outcome focused one more technical focused one more. Yeah, here's your budget kind of make it fit focused. Well, I don't know what what what is your thought on that? Different, uh, different experiences there.
Kush Sharma: Yeah, I think from a, from a government perspective, number 1, you're trying to figure out.
How this is going to actually benefit the citizens or the staff or. Uh, the internal mechanism, right? So when you're in government, you're trying to, uh, you have a limited budget first, and you're trying to figure out how much of this can I do and how much scope do I have and how many individuals or am I, am I going to cover with this amount that I have?
And so that focus is always, how is it going to benefit that end user? The end user being the citizens. [00:09:00] Uh, of that, uh, locality or, uh, the internal staff if it's some kind of internal deployment of an application. And so if you customize, if you're trying to sell, you have to customize the outputs to, to those specific, uh, groups and the benefits to those specific groups.
As opposed to, hey, this is the best thing. It could automate 10, 000 things because maybe they might not want all the automation or if they do. And as part of the package, their focus and will be okay. How can we deliver X, Y, Z? The fastest to that specific internal staff member to a vendor onboarding into a city, let's say, or, uh, deploying a technology.
So citizens could use services with 1 or 2 clicks instead of going to websites, registering, et cetera. So you have to think about that from a government perspective. And you have to. In government, you have to understand that it is [00:10:00] not just one body. They have to work together. So the cyber folks have to work with the IT folks, have to work with the specific business, like, let's say, parks and recreation.
They have to convince The people on the technical level, management level, and then leadership level. Right. And then what happens in government many times, it just can't get approved by individual because usually those type of projects are above the threshold that they can approve something. So then they have to write a briefing, then they have to go speak with procurement and the finance group, right, to, to fill out the administrative paperwork, then they have to go to council.
Right. If it's a like a local government, for example, for something larger, and then they have to get that approval. So there's multiple, um, stakeholders that have to agree to it because then you would need resources from them. You can't just implement a software solution independently. So if you're not getting in this example, parks and recreation, let's say we're implementing a tool that [00:11:00] can allow families to quickly.
See which pools are open and register for the pool. Let's say so, uh, you have to work with all the rec centers, for example, in the city. I mean, that's massive. It's gonna be hundreds of them. You got to work with the back end folks and manage all those current systems, right, to implement the new one. You got to have a steering committee with multiple stakeholders to ensure that everything goes smoothly because that is completely, you know, public facing and if something goes wrong with that implementation, people are not going to be able to book to go to the pool and that's going to cause a lot of issues operationally and then it's going to get rounded up to the council.
Okay. Once it gets brought up to the council, it's going to come back to the leaders in the organization. And so you have to understand that, that, um, governmental process, the bureaucracy. And then once you understand it, then you can kind of maneuver through it and weave through it quicker. I think, [00:12:00] you know, if you're doing something for the first time, it's going to be a little bit challenging.
You're going to have to have a lot of patience. To go through that, that process now from a, uh, like a firm perspective, or if you're building your own, they're more about the direct efficiencies, right? Okay. You're going to save you money. We're going to do this fast. So we're going to come in. We're going to improve all this technology.
We're going to, you know, improve all the infrastructure. You're going to be more secure. So they're thinking about it from more of an efficiency perspective, right? Uh, what are the key benefits we can derive out of what we currently have or supplementing with something new, right? Um, so they're, they're looking at it like a program management perspective.
How fast can we put this in? Because they know there's limited budgets in the world of consulting. You have to do things pretty quickly. You have to have, you know, high level expertise and you got to put it in fast. If you don't do it, there's, right, the longer you wait, and the longer, there's more delays, then there's a higher chance that that project will get stopped or [00:13:00] paused.
And so you're not gonna, you're not gonna get your revenues in that you have projected. So you want to do things pretty quickly. Based on what the client says. And we see in, in certain cases in government projects I've been on in consulting, I mean, they're paying 20, 30, 50 million for implementation of the software.
They do two thirds of it. Probably. I think that in that case, we were at 20 something million. And then all of a sudden political decision came in. Everything stopped. They just scrapped it. All that work, right. Uh, for the last few years was just halted, never got implemented, nothing happened. So that's, you know, no, a little bit of a wastage of taxpayer money there, but for whatever decision that was made.
Right, because it took so many years, uh, instead of, you know, the original plan. He got, he just got stopped. So these things happen all the time. And so from the, from an advisory [00:14:00] perspective, you're not concerned about the technical at all. You're concerned about, okay, does this even make sense? Right. Have we looked at all the options?
Do we actually have the right leaders in the room that can make the key decisions before you even start anything? Do we have buy in from, right? The business, uh, I. T. security leadership, the finance office, procurement on board, right? Do they have people to help with the procurement and all of those cycles?
So we're looking at it from a strategy perspective. Does this make sense? Is it going to make the organization better? Is there going to be more governance of the organization? And then what are we going to get out of this? Are we getting the intended objective, right? Are we getting cost savings? Are we getting some insights out of it?
So the advisory pieces really doesn't even make sense. Do we have the right number of resources? Uh, is this really going to be X amount of dollars as they say it is? Non government projects, it's going to be, you [00:15:00] know, probably, you know, at least a quarter to half times more. And if it's completely inefficient, then it'll be double, triple the price,
you know,
with some of the larger infrastructure projects.
So whatever number they give you is likely, you know, double it, triple it, and that's probably what your real budget is.
Sean Martin: And having, uh, I like that you say you look at it from a program management perspective. That's how my brain works. So, um, When you're looking at it that way, so what you described was a 30, 30 million project.
You got two thirds of the way through, you didn't make it to the quote unquote end. I don't know if it, and you said it was scrap, so you didn't say whether or not, uh, that case where hypothetical or not, did, did you achieve 20 percent of something or I'm sorry, two thirds of something or, or was it 0 percent return?
What I would, what I'm hearing is maybe [00:16:00] a plan to say, if you know it's a big undertaking, maybe you bring it together in blocks that are achievable and attainable and where you get some benefit out of them along the way. So you're not scrapping a huge big thing at the end. You never make it to the end.
Kush Sharma: Yeah, you're correct. So ideally you would phase it out. And so any large digital transformation that I've done. Uh, so these are probably like between 100 million and a billion, like larger projects, right? So the larger ones have 3, 000, 5, 000 people on them, like it's, it's massive. Like it's like a small, you know, army of people doing the work and it's basically re transforming global organizations, right?
You're looking 5, 10, 15 different countries and multiple, you know, hundreds of sites, etc. So, um, when you're looking at it from a digital transformation perspective, whether it's cybersecurity, IT, business, it doesn't matter. [00:17:00] Uh, then you have to take that piecemeal approach and you have to prioritize what comes first, second, third, fourth, fifth.
And ideally, what I usually do is we go for the quick wins first. So we don't, the folks that are resisting the sites that are extremely large and complex, we don't do first. We bite off the small pieces. So the stakeholders that are that are really in need of it and are putting their hands up to say, yes, I want this technology.
We go with them 1st, and then we prioritize by site also, or by location, whatever, whatever the circumstances. So if 5 people put up their hand. And the 1st site is only 100 people and the 5th site is 20, 000 people. Well, we're going to go with 100 people, right? And the other approach I usually take is. If it's a cyber project or a cyber transformation, then we, we do the first pilot with the cyber team, right?
It's our own technology. We're implementing it. It's going to change how people log on, for example, or something. So we usually [00:18:00] do it with the security first, work out the bugs. Second is the IT team, because they're really technical and they're going to get into it and tell you all the loopholes. They're going to tell you all the things wrong with it.
So then we fix all of that. And majority of the technical issues are then fixed. And then we do a business unit after that. Now, in terms of what was saved. So that example of the 30 million that was scrapped, that's a real, real life example with one of the governments I worked in. Um, and so what happened was it was scrapped.
So it was like, it was put on, well, it was put on hold indefinitely. So it wasn't like the project ended. The definition was indefinite hope. Uh, but what, what they could leverage was all the data that was cleansed. Right? Because we had to go to all these different sites, get the data, re transform the data, uh, make sure there's integrity in the data.
We had to cleanse it, classify it, et cetera. A whole, you know, a lot of work. So they had that data set. Now, if they used it or not, I have no idea [00:19:00] because we left, we also, uh, in that case had developed all the architectures for them, right? From infrastructure, security, business, et cetera. So that could be leveraged for future projects, even if it wasn't the same technology, because the concept is the same.
And then all the security controls and the matrices that we built could be leveraged. All of the change management materials and the training material, not the training, but the change management materials could be leveraged. Um, so they're, they had, although they didn't implement it, um, and there was, there's no specific output because the definition of the outputs weren't achieved.
They did have the initial data sets and architectures and documents that we created, um, you know, from, from mobilization all the way to testing. So, so, you know, they can, they can definitely leverage that. So it wasn't zero, but, uh, from a production [00:20:00] perspective, nothing, nothing was.
Sean Martin: Can you, can you describe to me, cause everything, everything, when you were, you were painting the picture of the, of the transformation.
And rightfully so, it was about supporting the, well, driving outcomes and benefits to the citizens, right? And supporting the users that, that make that possible and building up the environment to support that. Um, and of course, managing, defining, and then managing that to a budget and some timeline. You didn't mention the word risk, and I'm just wondering how and where that fits in.
So. Big picture, some, some transformation moving from on prem to the cloud or, uh, from one CRM to another or whatever it is, ERP to another, whatever, um, where, where does [00:21:00] risk fit into that conversation from a, an experience perspective successfully? Where does it fit in?
Kush Sharma: Yeah, I think, I think, uh, CISO, especially technical ones.
Uh, have this idea about risk, which is which is the technical risk. So it's not wrong. It's right. We deal with that every day. But when we're looking at enterprise risk, it's a different conversation. And so enterprise risk is the holistic controls. Right across. So, for example, do you, do you do human resource checks when you hire employees?
You know, something like that nature, which is a holistic control. And so, uh, security control on the enterprise level might be, do you, you know, do you, uh, do you onboarding, offboarding, and do you check for those, right, uh, access controls? So, when they're onboarding, do you have the right set of role based access, so these previews, and when they're terminating, do you actually remove all the access, for example?
So that would be like an enterprise level control [00:22:00] that would fit into a risk as opposed to, um, you know, firewall rules are not configured and you want to have a SIM and it results in no, no log correlation, which results in we cannot detect threat actors in an efficient manner. So those are completely two different things.
We have to keep them separate. So when I go into a larger project, first, we have to get the lay of the land and we can talk about that. But from a risk perspective. I look at it from a, uh, organizational objective and goal setting perspective, and I look at risk that way, as opposed to technical risk. So we can get into the technical risk conversation once they decide on the actual, uh, software that they want to implement or hardware they want to deploy.
So once we know what technology the business wants, then we can get into those conversations and do the threat risk assessments, PIAs, and all that good stuff, cloud security assessments, pen tests, all of that,
right?
Even before that, Uh, [00:23:00] what I realized is everything I do as a CISO, I have to map to whatever the objective of the project is or the company.
So if they're doing a merger and acquisition, that's going to be their number one priority. If they're doing a digital transformation and, uh, let's say there's five countries, right, for example, and one of the countries is the most important in the first year. Let's say hypothetical. So, so if they have two of those things going on, that was a real life scenario.
Um, so then I know everything I have to do has to be aligned, uh, to that M& A and to that, uh, specific, you know, country, because that's where they're deploying the first solution set. And so if I don't do that from a risk perspective, then I'm jeopardizing my budget, I'm jeopardizing my reputation as, uh.
CISO office. I'm mismanaging my resources when it comes to humans, when it comes to software, [00:24:00] technology, et cetera, procurement, uh, hiring maybe additional people, right, for that skill set. So I'm always going to focus on, on those two things. And what happens usually is, A lot of security folks get, get really caught up and right.
And you know, they're excited about it. I understand about the technology. Oh, I got X, Y, Z end point protection. I got network. Oh, I got cloud protection. Now what I could tell you, the executives don't care specifically about them. They care about is my MNA going to be successful with no breaches so that I can actually acquire this company and how you do that, Kush, you let me know.
You're the expert. But what my objective to you is. No breaches during an M& A. Absolutely not. Tell me how much it's going to cost me to protect that. So what happens in this case, is I would focus all of my, so I would look at it from a business risk perspective, right? So if I'm another business [00:25:00] unit, not like a technical office, that's how I see it.
So I'm another business unit, and my job is to protect the other units and protect any kind of major investments in the company. That's how I see it as. Microsoft Mechanics And so if I look at it, okay, M& A, boom, that's number one. Okay, how are they going to set up the architecture for the M& A, right? Uh, how long, what is the transition period?
What is, what are the government regulations? What is the mandate from the government in terms of timelines? Because the government will give you a timeline. If you don't meet it, the deal's out. And so, and then I have to understand what are the infrastructure folks doing, where are the business folks doing, what is legal doing, what is compliance doing, internal audit, external audit, communications, various business units, right?
Could be 10, 15, 20 of them. So I have to, uh, and then third party risk, right? But that's really security function. So I have to look at all of these aspects that are outside of security as a My team will look at the technical stuff, i. e. [00:26:00] whatever is in my wheelhouse, my team will look after. They'll do all the technical stuff, they'll do the advising, etc.,
and flip it to me. My job is to make sure that risk is managed. Now, sometimes, if a new network needs to be built, for example, between the two, if the government says you're not allowed to share information until we sign and we say you're good to go, right, and you're legally one company, many times that's what happens.
And so you have to now build another network real quick in the middle that communicates with the two, and you might even have a third party managing that because they don't want, uh, in case the deal doesn't go through, you don't want to share that confidential information because your competitor is technically still.
And so now you have to put up an entire security orchestration in the middle real quick, and that's what you're, then I would allocate all money, resources, and I would ask for more budget for specific technologies that can secure that. Right? So that my objective of not ensuring that there's no breach is met.
That is the objective that they [00:27:00] want. The one thing. Now, the second in this example, which is a real example, in this, we, there's one country that, uh, is priority for the digital transformation. So they purchased the software. If someone did this, but now they want to deploy and they want to do, it's the first one is very important.
It's a small, smaller country, smaller site, limited scope, but it's the first one. So we have to make sure that throughout the project phases, right, that the security is set up in different ways in the different environments. So within Trick Training, Sandbox, excuse me, Dev, QA or test environment, pre prod and prod all have different security configurations if you do it right.
What most people do is they give the same configuration from the sandbox all the way to testing, right? And then that's where the problems come in. And we've seen a recent attack in the news now where they were going into the test environment. To get into and breach production because the there is always [00:28:00] you have to send the configuration And everything you've built into production from test And many companies don't have pre staging so they send it directly So there's no free pre fraud where it's still contained And so these are the problems that occur now if you do it right and set up the security, right the dev teams the training teams The QA teams, the business teams doing all of their testing, all of the configuration will not be impacted, right?
They can do their work and nothing, you know, everything's happening in the background, right? So they'll be happy. Then when it comes to production, you have to make sure there's stringent controls. Just like, you know, just like any other organ, any other production system. And so then that transfer is a little bit easier.
Then you would focus specific resources for that. And usually those are technical softwares, like, I dunno, like SAP or Salesforce or Ariba or one of these big ones, right? So in one, so then you need specialty skill sets because you'll not be successful. [00:29:00] Uh, some of the mistakes that CS that have not worked on the business side of the house.
So these large ERPs. They think that you could take one person from their cyber team and put them into that role. No, the architecture is completely different for security. And if you take someone from the ERP space for security and put them in SecOps, they're not going to understand. So it's vice versa.
Completely different skill sets. There's some, obviously, concepts, they're both CISSP certified, etc. But, uh, in order to deploy correctly, you need experts in Salesforce security, in SFE security, in Ariba security, etc. And so you need to make sure you take your budget, and bring people that know those systems.
And could get into the nuances of those and be able to challenge the business, challenge IT right to say, no, this is not the proper way to deploy something. These are the specific controls that are coming within the system. And these are the recommendations from the vendor of which X, Y, [00:30:00] Z, we're not doing and we need to do this.
And so then it becomes that second level conversation of risk, right? Risk for the operational risk. And so when you have those experts, uh, so you've already convinced leadership, you've dealt with their risk, you've built the credibility and the trust from the, from a higher perspective. And then now you go down to the operational perspective and you need to redo that cycle and build that trust.
And that comes with people that know what they're doing and not someone that's a student or someone has two years experience and you put them in a big ERP. That's a recipe for disaster, a recipe for failure for CISOs. And then all of the goodwill that you've earned on the leadership level will get lost immediately.
Right. Because your technical people cannot deliver.
Sean Martin: So how, how do you get a handle on the, the, the scope for some of that stuff? And, and no, I mean, [00:31:00] yeah, if you're looking at Salesforce or something, um, you'll, you'll know pretty quickly if you have somebody on staff that, that knows, I guess we're talking.
The security teams will know the network security and the endpoint security, maybe some app security if it, if you have some bespoke stuff. Um, but when you get into those other systems, you need systems and business logic and things like that. How do you get to that level? And I guess it's your responsibility as a CISO to have that view.
Right for the, for the enterprise risk. So how do you, how do you get a handle on that and communicate that to the right folks to say that this is a part of all of this, here's how it all lines up. It's not the, not the technical controls that, that you would normally hear me speak to, but, um, we need, we need support for these other areas.
So it looked like, [00:32:00] yeah,
Kush Sharma: I think, uh, this is a little bit difficult one because usually, uh, when they do the RFP. They usually, like on these larger ones, and if especially if it's Greenfield, have no experience, they hire a firm to write the requirements, and then they put it out to the street, and then another firm bids, right?
Uh, other firms bid, and someone wins, and then they implement based on that scope, and they have some scope negotiations. The challenge is that the security folks are not usually there, or if they are, it's the network security person, or if it's, it's a SecOps person, or, uh, you know, they're doing code security.
Right. So, you know, so these, those folks can handle those areas. So the architecture discussions, they can handle the, do we do scanning on the code? They can handle, do a VM assessment, do pen test against, right? The traditional cyber. Function. But they're not going to be able to scope out. Okay, we need X, Y, Z [00:33:00] modules that are security modules within this application, this enterprise application, right?
So when you're deploying, for example, I don't know, like a Microsoft stack, right? And then you have all of the security tools that come with it. Well, you need a Microsoft security expert to know, understand those tools. You can't take somebody from the sock and put them in there and say you're a Microsoft expert now, right?
What they're not good. Can they ramp up? Of course, but you don't have time for that. So the same thing from the enterprise security perspective, right? With these big RPs. So how do we go about it? So one, uh, we have to understand the scope, right? So the scope will be what type of systems are being implemented.
Number one. Um, so, for example, uh, Are you implementing a CRM system, an analytic system, the core system, which module like HR, accounts payable, accounts reasonable, sales distribution, which industry you're in, right? So there'll be specific nuances for that, like freight, time and materials for HR. [00:34:00] So first you get a handle on.
What is, what are the specific systems and then the modules within those systems that they're implementing? How many countries are they implementing to? What is the timeline from start to finish of this entire implementation? High level, what is the cost, right? So, you know, if it's, uh, 10 million, usually these are 100 million, 500 million.
So if we just take 10 million, or even a million dollars. Let's say, right, we're going to be looking at at least 5%. Uh, that's on the low end. There's somewhat something big like this, but 7 to 10 percent is a good, good number to be successful in security because that's how much work there is. Um, and then so you, so you understand the scope, you understand a little bit about the budget, you understand the number of sites, the number of countries, uh, you have to understand the number, obviously, number of systems, but then within those systems, what's the key is how many processes are in school.
So that comes from the business. So business is going to say, well, my [00:35:00] accounts receivable processes and scope and within accounts receivable XYZ subprocess are in scope. So you have to understand that because you're building security based on the organization itself, and you're doing role based security, lease privilege.
And in order to do that, you have to understand what's in scope from a process perspective, and you have to understand what the roles are in that process. So for example, AP clerk, AP manager. Supervisor, director of accounting, I don't know, whatever it is. So now you have to understand that this is all business, right?
Nothing to do with security. So now you understand the tech piece. Now you understand how many processes and which processes. So you're getting this idea in your head of how big this thing is going to be. And then you're going to understand how many roles there are. Meaning a function that someone's doing, like a job, right?
So now we're saying, okay, now we have, Okay. Uh, I don't know. 100 jobs, right? Across every one of these processes, [00:36:00] right? Director, supervisor, analyst, etc. We add up all the jobs for all the different areas, for all the business processes, for all the technologies, for all the different entities in the organization.
Now you get to a number. You're like, oh my, like, I have to build all security for all of these roles. Each role is a separate role. I have to build each one of these in addition to the technical architecture, in addition to scanning, in addition to reviewing the code, in addition to pen testing, and all the traditional stuff in the risk assessments, PIA assessments, etc.
Now I have to actually build the granular privilege based access in the actual application. So, making sure that if Kush Sharma is AP clerk, he cannot do anything outside of the AP clerk. And only those specific transactions or functions, uh, that you're performing are available to that person and it has to be seamless.
So whether they're in the HR system, the [00:37:00] CRM system, the time and material system, the core system, et cetera. Now it could be, usually there's 25 to 50 systems in these projects, at least, right? Combined together as one big system. And so you, where, wherever they go, you have to make sure it's the same access.
And if they try to go somewhere, like a AP clerk tries to go to CRM, it's going to say access denied. Right? So you have to, you have to not only now look at these roles, but you have to look at the specific business process and how it cuts through the different and integrates with other processes and other systems, particularly because you're, you're going to do the technical work in the systems as opposed to a process.
And now you have a view of, Oh my God, this AP clerk is going to take, you know, out of the, let's say a hundred systems. This one person is going to go to 55 systems. Okay. Now you have to map that out. It's like, Oh my God, it's like this one person, 55 systems. How am I going to do this in a [00:38:00] streamlined way?
Because I cannot keep redoing this times a hundred roles times 55, right? Now we're getting into. into a, into a scale that we cannot maintain. It's not efficient. So we have to have now those discussions with the business directly and say, well, hold on, we did an analysis. This is what you're saying in your documents that this person is going to do.
And they're going to go to these 55 systems out of the 100. Now we looked at the manager of accounting. So we have AP clerk. Now we have manager and the manager is doing 80 percent of the same transactions or work effort that you have in this role for analysts. So what's going on here? So is, is if the manager is supposed to do management work, why are they have all these transactions that are operational that this XYZ person has to do, right?
The clerk. And so now you have to get into those conversations directly with the business. Now, what, what the mistake, most kind of technical security teams do is they [00:39:00] go to the IT folks to make these decisions. Well, the IT folk is not the one that's running the accounting, they're running the processes for, you know, help desk and service tickets.
So you go to them for those specific accesses, you need to go directly to the business and say, this is the analysis. And out of these, let's say 10 accounting roles. Co op student, AP clerk, manager, supervisor, et cetera, director, VP. I've done analysis and draw a little box. Hey, 75 percent of these transactions are exactly the same in all of your 10 roles.
This doesn't make any sense, right? Is that what you do today? No, we don't do that today. So why are you doing it tomorrow? So let's go through this and you're basically helping them redesign and make the process more efficient inadvertently. I love that. I love that. That's the value that
Sean Martin: Yeah, that's the value.
This is amazing. So, so what, [00:40:00] um,
who owns those documents? You, so you said they're, so they hire a firm. Is that, is it a product manager? Is it a solution business owner who owns the documents that, that, that says, this is what we want to build is, this is how it's going to be delivered. This is the outcome we want to achieve. These are the scenarios and stories that, that we want to enable.
Um, who does that? And then how do you, as the CISO, um, analyze that to then provide this, this feedback?
Kush Sharma: So, uh, in terms of who does it, it's multiple, uh, people in the organization. So, uh, IT would do all of their IT processes. Security, right? And if we're, we have new processes, like a termination, for example, or compliance, uh, enrollment of users, Change of users, for example, et cetera, right?
Reviewing controls in an automated fashion. You know, we have our own [00:41:00] processes and security. And so you would go to those specific owners. So you would have, let's say, procure to pay, order to cash, right, business processes. And you would have business process leads. So it would be some executive from order to cash.
And you have to understand, when you're doing a transformation, that's usually decentralized. All right. And you're trying to bring it together in the transformation. That's why you do the transformation. And so then, uh, the business processes have to be the same globally. That's the hardest challenge. So they put, they usually split it by processes.
So order to cash. So they take like a person who knows most of the processes for order to cash. And currently it might be all decentralized or different. They call it different things. The names are different. They use different tools. Right. They, they, they're, uh, one country does it X, Y, Z way in terms of cost accounting versus, I don't know, profit based accounting or something.
So then first, the [00:42:00] business identifies these folks that have a good understanding of the global scene and that have the influence, uh, because that's very important to get to have influence as a leader, right? To make sure everyone does the same thing. That's very hard to change people that doing things for 30, 40, 50 years.
Now they have to go to a new system. So second is we're going to be looking at, um, we're going to be looking at all of their documents. So order cache would be from a business perspective, right? Not technical architecture. That is a different team. Program management, the PMO office manages this whole thing.
Right? They're making sure everyone's doing what they're supposed to do. So the ultimate owner's PMO, however, the individual documents are by stream. So security, infrastructure, change management, training, order to cash, procure to pay, sales and distribution, et cetera, whatever the, whatever you call it in your organization.
So now we take the documents. So they'll have business process. Uh, uh, business process, narratives and, and visual [00:43:00] diagrams. You know, they'll have definitions of the, what the new roles will be. So AP clerk in the future, we'll do X, Y, Z, like a job description. Uh, then usually what they do is they take that new kind of design process.
So they'll have multiple documents for that, and then they'll, uh, beside them in each step of the process of the new process, they'll have the specific transaction or. You know, whatever it's called in the system, the authorization listed. So it'll say something like in SAP, you know, ME21N, which is a code for purchase orders, right?
So this, this person will be doing this specific code in the system. So Ariba is different. It might be like a button that they click. So we, the name of the button might be there. They're going to this screen. Some applications work on screens. Okay. It depends on how it works. So the screen URL might be there.
And then you have to go to that, you have to open it up, take a look, okay, what are all the [00:44:00] tables? What are all the fields, et cetera? And then you have to go back to them and say, okay, what's the field that they're clicking actually, right? Because this, this is like 10 things on the screen. What do I secure?
Do you need all of them secured or not? Can I actually do it? And you have to do the investigation now. So now you take all of this data, extract it, put it into a database, then you do all your queries. And then the queries will show you the duplications, the issues, the sensitive access that people have been given, right?
Uh, some of the controls even could be pulled out. So they might, they might, uh, like three way match, right? You have to do in business for invoicing perspective and receivable. So you have to make sure that no one could commit a fraud or no one could commit a collusion. It's called segregation of duty analysis.
And so this is something technical cyber people don't do, but if you're a business person, then you have to do the segregation of duty analysis, it's actually mandated by law, uh, in many countries. Uh, so that came out of the SOX [00:45:00] regulation in the U. S. and then many other countries adopted their own variation of SOX.
And in there it says you have to have, um, uh, you have to have, management has to oversee and have some control over financial reporting. So that equals IT systems, which enable those processes. And hence you have to have certain rules of the road put in from a financial and risk management perspective.
So you're looking at cosal, right? As, as Covid and COSO as those frameworks. So we look at NIST and we look at ISO and all Mitre. They look at COSO and covid. And so you need to integrate all of those together and those deal really with business process controls. Reconciliations, data integrity, data validation checks.
Segregation of duties, leave privilege, et cetera.
Sean Martin: So, Kush. Okay.
Kush Sharma: I kind of said a lot there, but, uh,
Sean Martin: Now you said, you said a lot of stuff, which has my mind going a hundred miles an hour. Do you have more time?
Kush Sharma: Yeah, of course. Let's, let's do it.
Sean Martin: So let's, [00:46:00] so let's pause here. We're not really going to pause, but I'm going to pause here.
This is going to be the end of part one. And, uh, I'm going to start a part two. And, uh, for those listening and watching, um, you can catch the part two, uh, soon and, uh, Kush and I are going to keep going. So I'm going to sign off for part one. We'll see you on the next one.