Cybernomics Radio

#42 Is Cybersecurity a Technology Risk or a Business Risk? with Mark Nicholls, CEO @Information Security Group

• Bruyning Media • Season 2 • Episode 42

Share episode

Mark Nicholls discusses how to integrate cybersecurity throughout the development lifecycle rather than treating it as an afterthought with pre-go-live penetration testing. He explains that embedding security into early design phases requires both leadership commitment and proper resource allocation to overcome the natural friction between IT and security teams.

• Moving security activities earlier in the development lifecycle is crucial for effectiveness
• DevSecOps implementation remains relatively rare, especially in larger legacy organizations
• Many security teams lack capacity to participate in early design stages
• Where a CISO reports indicates organizational security maturity
• Less mature companies have CISOs reporting to CIOs, treating security as just a tech issue
• More mature organizations position CISOs outside IT, reporting to CEO or board
• Business risk assessment should be the ultimate measure of security effectiveness
• Australia's "Essential Eight" provides practical baseline controls compared to NIST or ISO
• Regulatory requirements for breach reporting are increasing globally

You can find Mark Nicholls on LinkedIn or at informpros.com for any questions or follow-ups.


Josh's LinkedIn

Speaker 1:

All right. So, mark, you are on the forefront, it seems like, with Information Professionals Group, on what's going on in the solution space, in the technology space, in building those companies, so you're the perfect person to talk to about this topic of the roles in cyber governance and assurance in technology, right? So when we're talking about assurance in technology, we're talking about security around technology, making sure that information is safe, that it's available when customers need it, when companies need it, that their data is protected and all the other stuff that we recognize in the cybersecurity and the IT space. Something that's been top of mind for a lot of people and that has been sort of on my mind this week is the convergence of IT and security.

Speaker 1:

The IT team, the guys who are exclusively almost exclusively focused on making things run today right. They set it, it works, kind of set it and forget it, whereas the attitude in cybersecurity is a little bit different. It's always moving, it's a nebulous concept. The threat landscape is always evolving, it's always changing, so there's a little bit of friction between those two teams. How do you help leaders and how do you see leaders in the field solving that problem of friction between the IT teams and the cybersecurity teams. I mean, what is the fix here? Is it a leadership issue? Is it a technological issue? How do you view this problem?

Speaker 2:

Yeah, look, ultimately, josh, it's all of those things right, but the key question probably is, where do you start? And you know, like we mentioned in that brief conversation earlier before we started this podcast about you know, often cybersecurity comes into play and there's a pre-go-live pen test gets thrown in there right, as if that's somehow going to be this sort of magic pudding to protect risk at the very end of the life cycle. And so the first challenge is how do you actually move some of those actions, activities, further up the life cycle and in doing so, how do you get the cyber perspectives and the technology perspectives working together? But you know we've solved these problems before. This isn't new If you look at the history of technology. How do you get business interests and technology interests actually aligned? How do you get architectural standards and enterprise architecture direction aligned with solving business problems in technology? All these challenges we've dealt with, obviously, in different organizations. They've dealt with them to varying degrees, right, some are even doing that not that successfully, some more successfully, and so they give us a pretty good read on how to start embedding cybersecurity back into the development lifecycle and further up the lifecycle, and there's a whole range of capabilities need to get developed.

Speaker 2:

Obviously, leadership is a key aspect to that. Recognizing that number one. It's important to do this. But, you know, throwing in the pen, test pre-go-live, yeah, it might protect a couple of risks, but there's probably a few things you could do in addition to that. And is it even going to be the most cost-effective, risk-effective way of dealing with it? Probably not. And so that's a first is recognition. That's the first step of any change is recognizing things need to change and then moving it up the life cycle. So, yeah, there's techniques around with DevSecOps and so forth DevOps, of course, but then DevSecOps, integrating security but, yeah, I would say that there's still quite rare implementations of that. Yeah, that's quite an advanced concept and in many organizations they're still not there.

Speaker 2:

Where I see it, there is probably in smaller organizations and particularly smaller organizations that can operate greenfield really stand up best practices from the beginning. Longer term, older organizations and those that are bigger tend to be quite entrenched in their practices and that can be hard to change, and that's, of course, where stronger leadership is required and also some persistency to be hard to change, and that's, of course, where stronger leadership is required and also some persistency to be trying to change these things over a long term because not everything will work and eventually building capability and building new culture and new practices and so, but right at the restart, cybersecurity can inject themselves if they've got capacity. Cybersecurity can inject themselves if they've got capacity. And I would say, even with good intent, those organizations that I see struggling is because they just don't have the cybersecurity capacity. They're dealing with the back end of the life cycle, doing what's mandatory, almost compliance-based activity, just to be able to write the right boxes to get things live, and so do they have the capacity to actually operate up in the early stages of the lifecycle. That can be really difficult for them. So again, there's a challenge for leaders in allocating personnel, allocating resource maybe different types of resources as well to be able to inject themselves early stages of the life cycle.

Speaker 2:

So back when solutions are being talked about, when they're being architected, there's a cybersecurity element in there and that can be incredibly beneficial, of course, because right there you can start architecting solutions to go well, is there a way in which we can isolate some of that traffic from certain environments?

Speaker 2:

Or is there a way in which we can isolate some of that traffic from certain environments?

Speaker 2:

Or is there a way in which we can actually move any personalized identified information off of that solution and do things in a different way? You can start thinking about cybersecurity as a design problem or a design challenge right at the very beginning, and by doing that then you're also embedding some of those capabilities into the development and architecture teams who are actually doing that upfront design work. They learn and they're building capability, and so it's a really beneficial thing to do if organizations can do it. One is do they have the cybersecurity architecture expertise, which is a bit more senior, to be able to apply and do they have the capacity to do it? But that would be the first step that they should probably try to do get in front of the lifecycle at the very beginning, and then they can be involved on the way through, very much like an architecture review board or an architecture assurance board does that around enterprise architecture standards. They define cybersecurity architecture standards and then they embed that into the lifecycle. So that's really the place where every organization should be able to get to.

Speaker 1:

It's very efficient. It reminds me of a conversation that I had yesterday with a fellow named Dave Brown, and Dave brought up a really interesting idea, and it's a way to so he was summoned by the Joint Chief of Staff to. The request was to bring down the cost of cybersecurity, right. Joint Chief of Staff said something like anything in the budget that's over 3% or anything that's over 3% of the budget is a line item, so he has to manage that budget. So he said cybersecurity is right there, right over the 3% line, and he was like okay, how do I get that under the 3% line? And similar to what you were saying, at least what I'm hearing.

Speaker 1:

His idea was that you embed cybersecurity into the technology and so when you're embedding cybersecurity into these projects and into the software, then it becomes integrated and just as a part of the process right. Then it becomes integrated and just as just a part of the process Right. So you can streamline the process. We reduce the, the, the. You maintain the capacity for cybersecurity to operate and function properly, but you got the costs Right so they're able to get below that three percent. It wasn't a line item and the Joint Chief of Staff didn't have to worry about it, right? No-transcript.

Speaker 2:

So, yeah, it's always a good question about governance is, you know, who has control of the purse string, so to speak, right, like who has control of the budget? And ultimately that needs to be aligned in the ideal organization. That needs to be aligned with the accountabilities and the KPIs, right, so it's fine. I'm sure some of your audience members have had situations where they might be accountable for some KPIs, but they know that they've got a lot of difficulty actually controlling that. They may not have any budget to be able to drive it either, and that doesn't make it impossible, but it does make it more challenging. And so ideally, that's firstly on the budget is yes, budget is important, but also making sure it's aligned with KPIs and performance expectations to drive the right behaviors. And so I think it depends though, in answering that question, I think it depends on the maturity curve as to where an organization is at. So it may well be in the initial stages, because you do need a particular drive and you do need a focus. Then you might actually have the CISO who has actually got accountability for driving certain inputs into the software development lifecycle early stages of investments, for instance and they've got to be able to have a scorecard of some kind that goes yeah, we've verified that design or we've approved that architecture or whatever it is. Whatever that accountability is, you have something to verify that they're actually injecting their expertise and having that influence as early as possible. Now, is that going to be great? Long term, probably you want to move to a different model. Long term, you probably want to move to having your software developed managers, cios, potentially even much more directly accountable for the extent to which their solutions are maintaining standards in terms of cybersecurity practice Right, and they might get an incremental budget as part of their KPIs to be able to do that.

Speaker 2:

So I think these things evolve and it's all about what's fit for purpose for that organization at the time to drive the right behaviors, and that's going to be based on where the weakness areas are. But there's always a good case, when there's a key weakness and low maturity, of actually having somebody who's very focused and an evangelist, an advocate, to drive that, but knowing that there is a stepping stone and that this is a stepping stone whereby executives that are in place at the moment will have additional things added to their accountabilities over time, and so this is an opportunity for them to learn and embrace that as opposed to no. This is something which can be dismissed over a period of time, so I've just got to outlast. That can be sometimes a behavior in some organizations with a lot of inertia, and difficulty to change is that executives do try and outlast new initiatives like this right, and I think I'll just ignore this problem until it goes away.

Speaker 1:

Until it goes away, yeah.

Speaker 2:

So that's where it has to be evolving and it has to change over time. But having an initial sort of targeted pursuit by one or more individuals, knowing that's going to transition into executives as part of their standard operating arrangements has to be part of the mix.

Speaker 1:

This is going to be a little bit controversial and I don't want people to come after me. I'm just asking the question. Okay, so, because let's assume that we're embedding cybersecurity more and more into software and into these systems, does that mean that the CSO, the CISO, ciso, however we want to call them CISO? Actually, I never heard CISO before and that's why I love, I love, I love, I love the different versions of this. I've heard CISO, ciso, ciso. Okay, so we'll go with CISO today. Should the CISO then, at that point, report to the CIO Because everything is being embedded into the technology, right? Everything is being embedded into the software, into the processes, into the tool sets. Or should those two functions have their own budget? Should it be separate? I know that's not a totally fair. You can say that. You know. A caveat with that is that every organization is different. You know, all things being equal, you know it would have a different universe, but what do you think about that?

Speaker 2:

Yeah, josh, I have a very clear view on this, and I think it's a good indication just where certain roles are positioned in organizations. It's a good indication of their maturity of thinking about that function. And so the CISO, cso, whatever we're calling it that's another good example of where you can get a read on the maturity of an organization, not in a judgmental way, but just where they are in their journey. You can get a read on that based on where they position some of these roles. And so you take a SISO number one. Of course, they don't have one. That's probably the perfect example of a low level of maturity around information security is they don't have a SISO, and so somebody else within, probably the CIO's organization, is kind of wearing another hat as an add-on to whatever function they're doing there, and that could actually be the CIO themselves, but in some cases that's what happens, and so that's a first level of maturity and then the second level yeah, they do have a SISO, and typically that's reporting into the CIO. Now what's the internal messaging of that? The internal messaging is that the SISO and that risk is very much a technology risk and therefore it's appropriate that they're sitting under the CIO. However, is cybersecurity really a technology risk? Yeah, it is, but at a bigger picture, it's actually a business risk, and there's a lot of business risks that organizations face, and cybersecurity is one element of that. I mean, ultimately, the only way of assessing what you're doing in cybersecurity whether it's right or wrong or well-targeted or not is how is it impacting on your business risk, how is it impacting on your availability, your integrity and so forth of your business conditions? And so that's the next level of maturity that I see in organizations where they go, actually the SISO.

Speaker 2:

Yes, it is a technology risk, but it's also beyond that. There's a business risk element. We're going to move it out from under the CIO, because that understates its relevance, and we might even move it out into, maybe if there's a chief audit and risk area and we might move it out there and, in fact, risk area and we might move it out there and in fact, we might even have it as a direct dotted line reporting through to the CEO or in some cases, it's actually reporting directly to the board as well, because some of these risks that we're facing from a cybersecurity perspective are actually very board relevant risks and things that we need to be on top of as a board. And so those reporting arrangements that you can see in organizations, I think are a really good reflection of how that organization thinks about this risk and how mature they are on their journey about thinking about it. And then part of that, of course, is what's the type of CISO that they might need?

Speaker 2:

Right, because, as we talked about with KPIs and driving different performance before then, certain roles are going to be fit for purpose for where that organization is and what they need at that time. And so a CISO that can actually sit within a CIO's organization and start to build out that initial view around what a CISO does, it's probably going to be a very different CISO that's sitting out alongside the CIO and making regular reporting up to the board. And so, yeah, I think there's again maturity of organizations, and by looking at organizations you can tell how they think about some of these things.

Speaker 1:

So, would you say, the greater the maturity of the organization, the more likely it is that they will have a CISO who is at the helm and reporting to the board, or at least reporting to the CEO.

Speaker 2:

Yeah, correct, okay, yeah correct and outside of the technology. I mean sometimes, yeah, they might have like a chief risk and audit type function which reports directly into the CIO, and I have seen CISOs sitting in there. I mean one organization that took a very good maturity journey over a number of years and their CISO actually helped them take that journey. They started down on the CIO and then they moved up into the chief risk and audit role and then they themselves became the chief risk and audit officer as well as SISO, so they had a joint role and they were reporting directly to the board as well as to the CEO, more kind of broadening our topic a little bit right.

Speaker 1:

What do you think in building policy, what is the most appropriate measurement of a company's or any organization's cybersecurity posture? Is it risk? Is it maturity? Is it some other KPI? But how do they know that they're governing well and that their policies are working?

Speaker 2:

Yeah, it has to be ultimately business risk, business risk assessment. And so you know I know one service that we do and I know a number of organizations do. It is like a threat and risk assessment, and so the starting point for that is you know what is a risk appetite for that organization, you know what is their risk matrix, what are their consequences and likelihood risk matrix look like, and you know what risks are they not willing to tolerate and which ones are they comfortable with. And then looking at their cybersecurity landscape and going right, well, what is the threats that they're facing here, what level of controls do they have in place and what's the likelihood and consequence of these things occurring? And if they're all below tolerance, fantastic Green light, they're doing a good job.

Speaker 2:

Yeah, they could probably look at optimization of cost and there might be spend that they're misdirecting. Potentially there could be risks there that they're pushing right down to very low levels and they might be paying a high premium for that that they could avoid. There might also be things on the future horizon that they might be concerned about escalation and they might be worthy of looking at additional investment in those areas to preemptively cut those off before they manifest, but, in essence, the risk landscape is where every organization should be focused, and that's also the basis under which the conversations with the board and chief executives should take place as well. It's not a technology issue as such, but what does this mean to our business? What are the potential scenarios here that could be life-threatening to our organization and therefore be above our risk tolerance levels? What are those things that we need to be focused on? That should be the exact same scorecard. If you're going to pick one, that's the one you'd pick.

Speaker 1:

So let me get this straight. I want to make sure that I need to visualize this a little bit, because when we talk about risk and cybersecurity, automatically my brain goes to a heat map or a risk register or something like that. Right, it would be a heat map or a risk register, or I'm already thinking of the way you know our five by five grid and all that. Yeah, Are you saying that the business should if we were to picture it this way, should the business have a risk register that includes all of the business risks, and cybersecurity is a part of that? Or are you saying that the business risk is cybersecurity risk and so there's no distinction between the two?

Speaker 2:

Yeah, so there will be some risks that are specific cybersecurity related, cybersecurity events. But a risk has two parts to it. It has the event and it has the outcome. And so the event could be a cybersecurity incident or it could be other incidents, incidents but the outcome should always be in some kind of business impact, because that's how you can create a level playing ground for assessing what's important and what's not. And so, okay, we've got an outage, for instance, or we've got a breach, or we've got some loss of data or whatever the case may be. Well, what does that look like in terms of business implications? And then you've got the measuring stick for how important is that event and how much do we need to try and avoid that event from happening and how much are we willing to spend on avoiding it happening? And so, yeah, the risk landscape has to include those cybersecurity events, but put in the context of what it means for the business areas, yeah, All right, just to wrap things up, the last question is I guess is kind of I don't know.

Speaker 1:

To me it's a little, it's kind of fun, I don't know, maybe because I'm a nerd and I like cybersecurity and governance and I'm really interested in the differences in governance styles between entities, specifically between countries. Right, so you're in Australia and I'm in the US. What is the preeminent measuring rod or framework or standard that you're using in Australia?

Speaker 2:

Yep, so yeah, look, nist is referred to here. A number of organizations do use NIST as their standard. Probably more common would be the ISO 27000 suite. That would be the more common baseline standard. But the most commonly promoted standard is what's called the essential aid. The Australian Cyber Security Centre has an essential aid. You would probably consider that to be a base standard and it's really targeted at the massive companies out there who should be doing the minimum. It's targeted also at government departments, local government, government-owned entities and the minimum that they should be doing.

Speaker 2:

And it's a curious mix of specific technical standards in terms of admin patching, certain governance standards. It's a little bit of a blend of things. They're all very important, but it's not as broad and all-encompassing as, say, an ISO 27000 or a NIST. It's very practical and I think in that way it makes it accessible for many organizations to go. Yeah, I think we can actually achieve that. We understand exactly what's necessary.

Speaker 2:

Iso 27000 and NIST. You do need to put a lot of investment into thinking about what's appropriate for your organization and then filtering it down to what is appropriate. This is much more practical and almost prescriptive really, and so it's very common. It's promoted by government agencies, as in the regulated government agencies, it's meant to be complied with every government agency, and also it's encouraged that every private company in Australia meets that standard as well, and so I think, in terms of initial standards, it's actually quite a good one for organizations to get to and then build on from there, and I'd encourage your US listeners to actually have a look. It's very easy to access Australian Cyber Security Center, central 8.

Speaker 1:

And, coming on the heels of the SolarWinds fiasco, we know that their CISO got in hot water right. A lot of trouble got hauled off to jail. I shouldn't laugh at that. I don't even know why. It's not funny. It really is not funny, but it's indicative of what the SEC is doing and how they're cracking down on the accurate reporting in cybersecurity. So if you tell lies, you're going to be held accountable, especially with the SEC rule that requires four days to report a material incident. Is there such a governing body in Australia, and are the rules as strict as they are here?

Speaker 2:

Yeah, it's a moving target, isn't it? Globally regulations, and it's the same in Australia. Josh, it's a moving target here in Australia and so there is definitely reporting obligations here as well, on breaches, reporting obligations on loss of data and on ransomware, for instance. Is everybody reporting? I would doubt that. Are the rules onerous for non-reporting? Yeah, there is some penalties there, but how do people find out that there's non-reporting? That would be the key question. How do people get caught? Yeah, I think it's a moving feast here at the moment ASIC, the Australian Security and Intelligent Security.

Speaker 2:

I can't remember what the I stands for feast here at the moment. Uh, asic um, the australian security and intelligent uh, security. Um, um, I can't remember what the I stands for. Basically, it's a very similar to your sec. Um, you know, they have prosecuted organizations for, or cyber security standards. Uh, they haven't thrown anyone in jail and it's normally fines against the company, and I don't think there's ever been a case of penalties against any individual.

Speaker 2:

But I think some of these things is going to be a matter of time, right, like you know, there's always going to be some poor behaviors. There is across all of society. So, you know, cybersecurity actors aren't any different to that. Cybersecurity actors aren't any different to that and more a question of, as the regulations ramp up and they're only going in one direction. They're getting more onerous and higher standards all the time. I don't have any examples where they're being loosened, so they're always going to get tougher and then eventually there's going to be better detection methods of actually finding these things out and then being able to bring prosecutions to bear. So, yeah, it is probably only a matter of time, but there are no prosecutions individually that I'm aware of here.

Speaker 1:

Is there anything, before we wrap up, that you just want to get off your chest and you want to get out there? I just want to get off your chest and you want to get out there. I just want to give you some time to get a pretty good rant on um, on organizations.

Speaker 2:

Um, you know, just trying pen testing in at the back end and um and and thinking that's great, or uh, and hopefully I weren't too judgmental there, josh, on talking about the maturity of different organizations, every, every organization is on their journey, right? They all have to start somewhere. So it's not a judgment, it's just an observation, and this is the nature of change, right? Is that the key part is actually recognizing where you are and that might have been fit for purpose for what you needed to be at that time. But there's always a time to move on from that and it's important when organizations actually realize that.

Speaker 1:

In order to move these conversations forward, we have to have different opinions, and not every opinion is going to be popular and not everybody's going to buy into every opinion. But I firmly believe and this is the mission of this show it's to share information, share different opinions so that we move the needle and we're all moving in the right direction. So I hope that no one looks at that and goes, you know, thinks for a moment that that's judgmental. It's an opinion, it's a valid opinion and we need more voices like yours in the security market. So, mark, with that, I appreciate your time today. Thanks again for being so gracious with your time. If people want to find you, how can they find you?

Speaker 2:

You can go to informprosecom very easy way and contact us through there. Jump onto my LinkedIn page. Just put in Mark D Nichols and you'll find my LinkedIn pretty easily. And, yeah, very happy to take any questions or inquiries or follow-ups.

Speaker 1:

And you guys can find me also at LinkedIn. So Josh Brewing or linkedincom slash Josh Brewing. You can also find us on YouTube, the Security Market Watch YouTube channel. Please subscribe, hit like, drop comments, talk to me, shoot me a message If you'd like to be on the show as well, and your mission as well is to further these conversations in the way that we've done today here, mark and I. Please feel free to drop me a note. I'd love to have you on the show and keep moving these conversations forward. Thank you for watching. I'm Josh Bruning and Mark. Thanks again for being here today. Thanks, josh, appreciate it.