Presenters:
Transcript:
Good afternoon everyone. Thank you so much for joining us again this afternoon on day two. We have an exciting session for you next. Our presenters are Stuart Clark and Nicholas McBride. They have a great session for us today of the rise of the security enablement function and model for partnering with the business. Thank you all for joining. Thank you for that introduction.
So this is the second day of the conference, and we've been going to a lot of talks, and seems like one of the common themes of those talks is the future of not only the EU secon security conference, but also what is the future of cybersecurity look like? Coincidentally, that happens to be a central theme to the topic that we want to present on today.
We want to discuss the rise of the security enablement function and how our vision for the cyber security, the future of cyber security is one of enabling business through security. So we'll start off some quick introductions. My name is Nicholas O. You have my face up here, so have some cats instead. That's all I got. That's all I got.
Okay. You guys will learn a little bit more about us as we go through here. I'm. I'm Stuart Clark. Probably, competing for the world's, title of the worst selfie taker. You'll often find me in hotel gyms wearing a t shirt that proudly proclaims, human interaction is overrated. Which is true in most cases. Current non-work project.
I completed a Starlink mini off grid, waterproof set up. I can do about 14 to 15 hours, off grid. And the reason that I have that is my wife cannot have more than five minutes anywhere in the world now without having internet access. So that's a little about me. So what we're looking to talk about today, basically is cyber security.
It's often viewed as by business as a cost center or a money sink. Some businesses, you know, they might say, hey, we've got to mitigate risk, so maybe we need some cybersecurity or they're like, well, we think we should have it. So yeah, we should probably do something with it, but we don't really want to spend any money on it.
That said, we think that cyber security has a larger function that can play in a business, which is actually enabling the business and its objectives. So today, what we want to do is that not there we go. We want to introduce you to the enablement mindset. We want to start generating conversation about the future of cyber security and where enablement fits into that.
And we'd like to present you with some of the lessons that we've learned so that hopefully you guys can build upon that in your own organizations. Full disclosure, though we may be wrong on some of this. But at least we run with confidence and we have a PowerPoint to prove it. So this all starts, for me, at least when I started working at Optum, Stuart brought me in and he had this idea about how we were going to run the cybersecurity program, and he said, it's protect.
It's enable and engage. And I want to let him speak about that. Yeah. So protected enabling engage. Those are the three pillars of our cybersecurity program. And not only our cybersecurity program, but our security program. I'll talk about that in a minute. And so whenever I'm talking to anyone in the organization protect enable engage it's catchy. It's short and and it's meaningful.
But what is enablement? And so we've kind of defined it and we'll talk about first principles in a minute. But enablement is creating the conditions where security doesn't just protect the business, but actively drives innovation, Ebit growth and customer trust. And so you guys see, I'm a shirt today that says Ebit, Ebit, a defender, Ebit a defender, however you want to pronounce it.
And this is less about like the statement and more about how I relate to the business. And so I wear the shirt just to let the CFO and CEO know that we care about such things, because that's what they care about. And that's just a little measure that that we do drive on a daily, basis to understand our customers.
And we have a lot of customers, we're going to dig into, first principles, a little, a little bit, because we need to go back and understand why does cyber security even matter matter in the context of it. And we kind of pulled back the covers, for what we were doing with security and cybersecurity in general.
And we went back to first principles. And those first principles are there, the fundamental truths that guide all, of the decisions that we make? A really good, reference is cybersecurity first principles, a reboot, a strategy and tactics by Rick Howard. And so we, we we took part of his work and, and we used it, pretty much verbatim directly and translated it into our security program.
But we added an element that's not there that, that we're going to be able to share with you, as we go through this.
So before we actually look at the first principles, I wanted to to, really relate to you. Why? I feel like the, the, understanding of the Golden Circle and understanding our why is really important in relation to cybersecurity. The, this is a paradigm that was popularized or, by Simon Sinek. Right. And, it you can read it from the outward, from, from inward, out from why how what or from out in what how, why?
And if we think about it, it's really easy and I'll use I'll use myself as an example. I'll go from the outside in, which is the way we, we typically relate to the world today. What? I'm in charge of a converge security program at, at apt. We have six different lines of business, and I'm responsible for, converge security program that includes industrial, physical, and cyber security components.
That's what I do. How do I do it? Well, I liaise with team. I liaise with other business units. I have a security roadmap, and I manage in some days I wonder what value I'm adding at all. That that's another matter. And so we hear those things all the time. They're not they're not necessarily interesting that they, they appeal to the, to the, neocortex part of the rational side of our brain.
Moderately interesting. But I would challenge us to really go a level deeper and think about why we do what we do. And it really changes the conversation. And that's why, if you look at the if you look at the circle and you start with Y and go out, it can be much more effective, because for me, what do I get up, every day?
Why have I been doing cyber y? Why have I been a CSO for 20, 20 plus years or however long I've been doing security, which is which has been a long time. What drives me right. And, we have organizational first principles, but I really went back and thought about that holistically. My, my entire career has been in security, whether it was my genesis in law enforcement to my transition to the technology world.
But the fundamental thing for me, the reason that I get up every day and go to work and what gets me motivated is the absolute necessity that good over evil is going to win. Good is going to win. We cannot let evil win. Evil is going to have days, right? We all know that. But good over evil for me.
And that drives me right. And it's really, it's really it elicits an emotional response in me and why that's relevant not only when you're, you know, talking about your message, but why is it relevant directly to the enablement function in cybersecurity programs? Because there's an ancillary to that that's really important. That's actually driven by emotion as well and not by the, the, logical side of our brain.
And that's because that's why is where trust lives. If you think about it, trust it for us as cybersecurity professionals is really hard to measure. How do you quantify trust? How do you how do you know if you trust someone, you feel it right and if you feel it, feeling is an emotion, right? So you actually have to tap into that side, of, of, of the spectrum to really understand, and be able to start quantifying what that feels like and know how to how it, how it works in relation with others.
Right. And so I lead with good over evil. That's what we're about. Some days we some days we don't meet that goal. Some days evil wins, some days we win. But net, but but the net is that we're always going towards that goal of defeating evil. And for me that works. And in and I use that with every customer that I come in contact with.
And it's really a core principle that's big, deep within me. And it works and it drives it drives better trust conversations. Back to first principles. So we talked about boiling back like what are we trying to accomplish? And this is we have operate operationalize this, but we have also, you know, made it easy for, leadership to consume customers, to consume.
So at the end of the day, reducing probability of material impact due to a cyber event, that's job one like that is that is what we do. Job one. And there are, you know, five components that go into that from resilience to intrusion, kill chain, zero trust, automation and AI. And risk forecasting and all of these things. We've we've, adapted from, Mr. Howard's book slightly, but they all ring true.
So that's our that's the first principle. Protect is always job one and we always lead with that. But as important, the our second first principle is strategic enablement as a, as a value driver within the business. This is all unique to our security programs. Adapt them right. And we look very much like a corporate security organization that you'd find at any mid large enterprise.
And so, we have some unique business factors, that, that go into this, but we, we like to see, to be seen as advisors, empowering internal teams and customers to design and deliver secure solutions. We deal with compliance, obviously, but we deal with compliance on the front end, right? Compliance is a is a starting point.
It's not it's not the end goal. And then we're open to brainstorming, right? Somebody has a crazy idea, and we're having a bad day. The first thing we want to do is tell them 100 reasons why it won't work. We work very hard not to have that mentality and be open to be open to that conversation.
And let them be heard so that that's a that's a key. That's a key point. For us book to bill ratio. This is a CFO and CEO metric that we that we map directly. Book to bill is, is, after you when a customer or a client, and you sign the paper, how soon do they pay?
And we want to shorten that window. And security can sometimes get, sometimes get in the way. Security questionnaires, compliance. You know, requirements, whatever. But we work very hard to help reduce that window for, for the business. And then just thinking of ourselves as a center of excellence, what we can do, like speaking here today in the community, we empower everybody in our team to think about, about our cyber practice as a, as a, center of excellence within, within the organization and outside of the organization as well.
So why enable trust? Trust by default and not exception. Sometimes hard, customers, regulators and partners demand it. Enablement turns trust into a competitive advantage. And we've seen that. Right. If I can have a conversation with somebody that, trust me, it's a much easier conversation. Again, how do you measure that? I don't have a metric for trust.
I guess I could have like a sliding scale. And, you know, some days it's like up and, you know, so it's not a hard, fast metric, but it is, it is important. Security is no longer just protect kind of talked on that. It's critical growth function. Partnership create speed. This is this is for us decreasing that book to bill or decreasing the time that it takes for us to, to operate within the context while still being within our risk tolerance.
And this is more for me. I'm thinking like it's a survival mechanism. I'd like we might as well do this. Well, because we're going to get these security questionnaires and we're going to be tasked by customers to prove our compliance and that sort of stuff. Why don't we have a formal way of actually, you know, taking this, information and actually turning into a differentiator for us because at the end of the day, it makes us look better.
And then, especially in security, I have this question. In a world, of abundance, why does it feel like we're always starting? Not enough time, not enough resources, not enough team, not enough whatever it is. And you step back from that and look at it and say, how do we reframe the problem? And sometimes it's hard, but we try to have an abundance mindset instead of a scarce scarcity mindset.
Although, all of that is a challenge at times.
So why now? So if you look at, if you look at the graph, you'll see a yellow, a yellow line on the bottom that's, you know, kind of like growing slowly, literally leaner. So that word thank you, he, he says works for me sometimes that I can't say, linear. So so that's the way that's biology.
That's human biology. We can only adapt. So fast. Right. The the blue line is the X is supposed to represent the exponential growth of technology. Right. And we're stuck right in that middle, in that middle area like, you know, we're like biology. You know I could have been you know, I was born in the 60s, right? And I could still be living in that world.
But technology is way, way, way, way past that. And so how do we keep keep up? From my time as a first responder, I do know one thing, which is, the the like the first truth is that if you can't help yourself, then you can't help others. And so what that means to me is you need to you need to make sure that you have the your own personal firewall in place from your role and from your job and sometimes from the world.
It's so soft. It's the soft things that you're doing. It's, meditation. It's the walking. Whatever you do to disconnect those things are so important, on a day in, day out basis, because your, your you're not helping anybody if you come to work and in a state of mental angst because you can't keep up. And it's a shared common human problem right now.
So it'd be really interesting to understand how other organizations are and people are helping, solving for this, business is moving faster than controls, right? We see it in AI all the time. We could have a sideline on AI, and there's been a lot of talk about that. We're seeing it every day. We deal with it on a constant basis.
And two years ago there was very little conversation. Conversation about at all. It's become kind of, you know, obviously a, very much a, driver in the business and very much in the security queue now as well. I'm sure you guys, involved understand that, budget and talent pressure. And they will get more value for the same, resources because we we think about ourselves as a center of excellence.
We, we put more time and energy into budget around training conferences and those things for our staff, and for, our overall security program. And we get the value from that. And obviously, this, risk is visible at the board level. We have to show, that impact on revenue, resilience.
Thank you. Stuart. Yeah. So how does this actually look like? When we're going through and building that enablement function, how do we actually do it? We've kind of boiled it down. We've got five things here that we think are important to that. And we'll kind of dive into each one. So starting with the service portfolio definition, this is one of the very first things you have to do.
Basically you need to define who's your customer. Right. If you don't know your customer, how can you enable them. Question or who that might be. It could be your employees. It could be your leadership team. It could be the board. It could be owners of the company. If you're depending on who ownership is, it could even be your customer's customer.
But first we have to know who our customer is. The second thing is we have to align to the business goals. So we have to know what matters most to our customer. In the case of a business, it's probably revenue. So what revenue or what do they care about? If it's revenue, how do we support the revenue that they care about?
What KPIs or metrics today track Stuart mentioned earlier adapt one of our big metrics is book to Bill. So how do we support the book to bill ratio. Last thing there is, if you don't know what it is your customer cares about, just listen to them. They'll talk about it all the time. They'll it'll constantly come up in conversation, figure out what they're talking about all the time.
That's probably what they care about. Then you can start to align your security program to that. The third thing you need to do is define your service catalog. You know your customer. You know what they care about now, what can you offer them? So examples of this could be services. Maybe you provide services to the company. Maybe you provide them with tooling.
Maybe you provide them with advice or guardrails. The one thing you want to make sure you're not doing is providing them with blockers, outages and pain.
The last thing is to make it a statement. So here's a couple that we actually use adapt them. So the very first one we offer cyber security contract review services to our proposals team in order to reduce the book to bill ratio. So we've got who our customer is proposals team what they care about. Book to bill ratio what we provide cybersecurity contract review services a couple other examples there.
We do offer security protection services to our business so that they don't have to deal with a material incident that comes back to function. One, which is protect. But through protect we also enable business because outages are not a business enabler. The second part of our enablement approach is to engage with the business. One of the things that we've identified as very helpful is what we call security liaisons.
These are people who are not part of your corporate security function or cybersecurity function, but they are able to speak with you, and they kind of provide you insight into different functions of the business. It could be people in physical locations. It could be people within different business units. There are people you can talk to and understand what their business unit or their location cares about and what's going on.
It's important to identify your security liaisons early and empower them. You don't. You want to give them ownership, not just a list of tasks to do. You want to make them feel like they own their security liaison function. It's amazing what happens when you deputize somebody as a security liaison. Oh, so sometimes you get the intended result and sometimes you're getting more than you bargained for.
Yeah, it is a balance.
The second thing for engaging the business, I'm sure we've all heard this term before. It's shifting left. Now in this case, we're not talking about shifting left in a technical term, but more in a process term. It's getting involved early so that you don't have to audit later. How do we get involved in the decision making process and provide the cybersecurity lens and viewpoint before we have to come back later and throw some duct tape on it?
Third thing is stakeholder presentations. This is probably the one we're most familiar with. We all have to give, presentations to the board, to leadership, to the risk function of the business. Have to try and make them care about cybersecurity. But when we are engaging with them, we need to make sure that we speak their language. When we're talking to a risk officer, we talk in terms of risk.
When we talk to the CFO, we talk in terms of revenue and ROI. When we talk to the CEO, we talk about strategy and vision and where it's going. Making sure that we speak their language, make sure that we are touching on what they value the most.
Yeah. Oh, the other piece there, one of the things you can do is to actually be proactive. So try and start conversations with security. You go and sit down. You've got leadership. You're having a company wide meeting whatever. Try and start off with a security moment. Try and get some security in the conversation from the get go so that it's on people's mind.
Don't wait for them to ask you about it. And I would I would just say in this example of EBITA, right, that I, that I use when I'm talking to the CFO, he's under no assumption that I actually really can deeply go with like one on one with him around EBITA. Right? I know, I know it well enough to know that it's important, and I know the basics around it, but I'm not a financial guy.
In fact, I went to, I went into law enforcement because I thought there was very little math. That's another story. There's actually quite a bit of math and law enforcement. I learned to program so I didn't have to learn math. Yeah, exactly. 50 calculator. But but it's not. Yeah, it's not necessarily just about like what you know, but the fact that you're just communicating with the business that, hey, I understand this is important to you.
And it's kind of that empathy. There. It really works. Trust. Yeah. Last piece about engaging with the business. Honestly, it's probably the most difficult piece that we do. We don't always get it right. That's it. It is about persistence. It's about showing up every day. It's about using every conversation as an opportunity to shift the mindset from no to enablement.
Use those opportunities they're given to you every day.
Third part of our enablement approach is building what we call guardrails. It's basically defining what is the security approach, what falls within bounds of acceptable for our risk tolerance, and what falls outside of that. What are the absolute cannot dos versus what can we do potentially? You can see here we asked AI for guardrails and it gave us a fence.
Maybe that says something about the guardrails we need on AI. Typical. First thing when it comes to guardrails is define what your core security principles are. Fortunately for us, they haven't really changed since 1974. It's about separation of privilege. It's about least privilege. It's about, keeping design simple, making sure that the less complex it is, the less attack surface there is, the less opportunities for things to go wrong.
The second thing is to use smart risk taking. I'm sure a lot of us hate risk. We'd rather just secure everything as much as possible. Then we go down the rabbit hole. Hey, can we just unplug everything? It's all air gapped. That's fully secure, right? Not exactly conducive to running a business. So what we have to do instead is take that risk approach.
We define what our risk appetite is. And ideally your risk appetite would match with the businesses. Now unfortunately in cases where your business risk appetite is we'll accept anything. It's fine. That's probably not the right approach, but trying to get more alignment there, helps you work with the business when it comes to those risks. The last part is using policies and processes as kind of an accelerator.
So one thing that we look at doing and that we currently do is having pre-approval workflows. So say for example, somebody wants to install something or do something. How can we put guardrails in place that prevent them from doing what we don't want them to do from a technology perspective? And what processes can we put in place so that when they are doing it, it is done in the manner we want?
Most important, when it comes to pre-approval workflows or any sort of enablement through policies and processes, is making sure you have the ability to audit. You have to be able to monitor in case someone goes outside of your guardrails, and you can kind of guide them back within it. Fourth piece is your feedback feedback loop. So as Stuart was saying earlier, how do you how do you quantify enablement?
It's not a hard metric. It's not the number of vulnerabilities. Ultimately it is about trust. So, you know, how do you measure or quantify feeling very difficult to do. That said, when it comes to metrics, they are everywhere. We all know about, you know, number of alerts, taken care of, number of vulnerabilities, time to remediate vulnerabilities, all of these hard metrics.
But if you keep looking and kind of expand your, horizon a little bit, there's metrics all around you. You just have to look for them. Some that we have found are time to approve requests to time to approve requests, which speaks directly to that reduced book to bill ratio, number of projects secured in cases where cyber security is part of securing that project.
And just general feedback from other business units or other teams within the business, that could be a metric. One thing you might look at is does your leadership avoid you when they see you coming? Or do they come in and actually say hello to you? That's a trailing indicator of their trust in you and your team.
And I'm not going to say how it goes. Most days. We. Another, piece of feedback is you got to ask yourself about your services. Are they relevant to your customer's need coming back to that service portfolio definition, who's your customer? What do they care about? Are the services you provide to them relevant to what they need? Or are you just going down this lens of security for security sake and ignoring your customer's needs?
Along with that, you have to make sure that you're responsive, when your customer asks you a question. So when your business unit needs you to do something for them, whether it's enable an application or add a new user, is it languishing in the backlog for a month, or are you getting that done within 24, 48, 72 hours?
And speaking of that, those are metrics that we measure, right? And so we have a formal process for intake for security requests. We manage it like any other, security request that comes in. So we can actually track our responsiveness to those to those specific, requests. Another piece is to focus on storytelling with your metrics. When we talk about metrics, one of the ones I struggle with is actually number of vulnerabilities.
You have this huge number, and it looks very scary, but is that actually a good measure of your security team or its effectiveness, or is it something that you're showing for vanity sake? Hey, we did all these things. Look at what we did. But does that actually matter to the business and what it is they're trying to do?
Think about a metric is it's a number. It's the story that you tell with the metric that actually matters. There's a lot of, you know, probably a whole different talk there on the value of perception versus reality, something that we deal with on a daily basis. The last piece is building a culture of trust. So trust is the foundation of everything that we do as a cybersecurity team within a company.
Who will take your advice if they don't trust you, who will use your services if they don't trust you? When building trust, three things that we find key. Be transparent. Tell a company what you're doing. Tell them why you're doing it. You're going to have the same conversation. A lot of times I still have people ask me, why do I have to rotate my password?
Yes, it's the 100th time I've had to give it this year. But I still tell them, here's my password. Rotation is important. Here's why we do it. Every single time I have that conversation. It helps change their perception of the cybersecurity team from making them arbitrarily do something that is a pain point to, hey, there is a reason for this and it helps you out because of why we do it.
So be transparent is more than sending an email that says we care very much about your security. Yes. But right? Yes. It's one of the things that we do from an enablement function with our customers when we when we fail, we we're, we're more than, we're more than an email. Right. So we're actively engaged with every customer that cares about what happened.
Why and what our mediation is. It's a lot of work, especially when you have major incidents that happen and the time to resolve those. The customer satisfaction is, well, sometimes ongoing for years, apparently. But, it does it does help. Speaking of what Stuart just mentioned, that comes into our next point, which is about do your actions demonstrate your understanding of the customer?
It's not just sending that email saying, hey, we care about your security. Do your actions demonstrate that your actions match your messaging? Or are you just saying all the pretty words? That's how you build trust is by not only saying it, but then doing what you say you're going to do. All of this comes back to when the business trusts you.
They are more likely to assist you with your number one function, which is protect, so that you can assist them with the number two function, which is enable. Question that we had some fun debating about. This is whether or not saying no is ever appropriate. Somebody comes to you with a request. We want to do X, Y or Z is no ever the appropriate response.
My take on it is it's probably not. Maybe you're just not thinking hard enough about how to phrase this response, and this comes back into trust. So when you say no, your customer just hears, I'm not giving you what you want. What if we instead change that to no, but we can do something else in a more secure manner.
So for example, your CEO brings in his personal laptop and says, I want to connect it to the corporate network. And you say, no, he's not going to like that very much. But if you say no, but you can put it on the guest Wi-Fi, he's much more likely to be comfortable with that and not lose trust in you or your team.
Other examples, is when somebody comes in, they say, hey, we want to give an AI bot for global admin. That way it can read everything and be our knowledge base, and we can just chat with it. And all the employees will have everything at their fingertips. And natural language. It's AI, it's awesome. Can we say this is real?
I mean that that that really happened. It's really happened. It has maybe happening. Yes. Okay. And the way we could do this is we could just say no, no global admin. And the story, or we can say no, but we can give you an AI chat bot that has read permissions to limited sections of our data. And here's how we can do it, which is the next step.
It's not just saying no, but you can't do this. It's here's how you're taking what the customer wants and you're giving them a solution for it, even if it's not the solution. They originally came to you with. It's really kind of tricky, especially with AI, depending on what what our customers are wanting to do and who our customer is.
Right? Because they just like ten, generally have a really high level of what they want to do with it. Right? And and they want us to solution solve, which we can do that, but we have limited context in the business. So sometimes it's a tough conversation to understand and define, like where our line ends and their, their responsibility began.
Just something we're still yeah, it's interesting to I mean, it really kind of brings to mind how we all wear different hats all the time. It doesn't matter what your role is in cybersecurity. In this case, you're actually doing a little bit of security architecture, whether or not that's your job title. Yeah. So what we wanted to talk about is some actual wins that we have experienced.
So one of our first ones is we revamped our approval process. So this is related to cybersecurity questionnaires or things related to project proposals. We were able to reduce that from a month or longer down to about two weeks average. So pretty significant increase that increased speed on the turnaround is a metric that our customer definitely cares about.
The faster we respond, the faster they can bid on the work, the faster they can get the work. The faster they can book it, the faster they can bill it. So we're directly supporting a metric that the business cares about. A month seems like a very long time to do as a starting point. Yeah, that's because it was sitting in my inbox right now.
Okay. We got now got a large piece was, they were they were missing context. You know, I don't know if you guys have experienced this, but the business unit sends you a questionnaire and they say, hey, fill this out and you go, great. In what context? What's what's involved? What's the scope? Are we using our Azure Environmental.
We're using our on prem environment. Are there printers. Are there workstations? I cannot just answer this blankly, especially in a larger organization or a more complex organization. You can't just say, yeah, everything meets the requirement. You have to really kind of look at that scope. And so gaining context, part of what we put into our process is giving them questions and form so that they can prefilled information that we need in order to turn that around faster.
Second thing that we've done is building ownership into it functions. So we would run into situations where we know who's responsible for the operating system, and we know who's responsible for the application, but who's responsible for the Dot. Net framework that the application runs on was unclear. So you go to the OSS person, say, hey, we need to patch this.
And they say, that's not my not my job, and go to the application person. They say, it's not my job. You say, well, who owns Dot net? And they go.
So instead, we went and we conducted a RACI exercise. We took all of the IT functions and we went through and we put down who was responsible, who's accountable, who has ownership. And the thing about ownership is when people feel ownership over something, they are more likely to care about it. Nobody cares if somebody else's stuff gets hacked, but they do care if theirs got hacked specific to AI.
One of the things that we've done relatively recently is we make sure that we have a human in the loop, which means that we have a human accountable for the output. Right. It's about the policy thing, and it's something to work on from an education, an engagement perspective. It's very important that, you know, that that, the human actually be accountable for whatever machine generated output.
Nothing has changed. Right. And that seems blatantly obvious, as I say it today, but it's been non-obvious in conversations to this point. I think. Stuart, I think you were going to speak about this one.
Yeah. One of the things we did and coming in and I've been building security programs for decades now, it seems, and we, and after, we moved cybersecurity from it and brought it under legal. And so I report to general counsel, it's, it's it's a role that I'm relatively familiar with. I've done this before.
Reporting to a lawyer. I don't know if any. Anybody report to a lawyer here? I'm not a lawyer. And so I try not to get in, long arguments with them because they'll beat me down. But anyway, very, very interesting. And really, the appropriate thing, what we found about changing the alignment is when we have a major incident where legal, is involved and they get involved early these days, it's great to have that straight line of communication, and they're built into our into our processes.
The downside of it, sometimes, not reporting to it, you lose that, kinship and, you know, you risk putting security out on an island. And that's why you that's why this relationship thing, relationship building that you have to keep in place all the time is really critical. We're a little bit unique, and we're a project company, and we've got six different lines of business, and, we have limited opportunity to actually build our hours for advisory work.
So if you go back and look at our enablement first principles, then we do have a way to actually directly generate revenue for, for them, although it's not a, not a big line of business. Our we're like I said, we're a project company and we could be called on any time in our proposal to be a CSO or be as, a, security analyst or and we're all like, it's like we have a cadre of resources that we bring to bear on, on projects that we that we bid on.
And when.
Talked a little bit about this, guardrails for adoption shifted security last, got the business, got more effective. It's a work in progress. We're we're still we're still navigating as I as everybody is really. And leadership does avoid this in the hallways, but not for the reasons that we're not helping enable them. Most of the time.
So one of the challenges that we face is, firefighting versus deep work. And what we mean by that is deep work is where we get things done. This is where we write policies, where we write write processes. This is where we evaluate tools and do configuration. And yet on a day to day basis, we're constantly getting hit with the latest fire.
Hey, we've got a project. Hey, we want to install something. Hey, user, need you to disable this because they want to do something. Probably dumb, but the request comes through. We have to evaluate, being able to balance between those two. Firefighting versus deep work has been a real struggle for us.
Compliance versus an enablement. Compliance drives, most security programs today. It's a starting point for us, not the finish line. We talked a little bit about that, converged security ownership. We're a little bit unique in that we have run a converged security program. So we take advantage of the other, personnel resources that are on the physical industrial side to help, help mature our cyber side.
Our cyber security program is the least, developed and mature of of the, of the three areas when we came on board about three years ago. And that's changed now. And obviously, there's competing business priorities, different business years, different different goals. Business units fight, for resources and those sorts of things. And how do you how do you not get drug into political, quagmires?
It happens. And then cultural resistance, can you change culture? One of the things that stands out to me there is, kind of a quote, you know, we had we had to become storytellers to survive. And that comes back to those metrics, right? We're not just throwing numbers out. We need to be able to tell the story, and we need to be able to tell that story in a way that the business cares about.
These are true stories, right? True story. We're not telling fairy tales. This is day to day. Yeah. So final reflection cybersecurity without an elements. Just survival, not success. How do you shift from. No we talked about that. It's it's difficult. Right. It's very much a work in progress, but it's. No, no. And or but and, listening is key.
Reframing security as a growth engine, not a cost center. Work in progress. But that's the that's the mindset and the methodology. And just having the mindset and methodology helps, and then lead culture change or risk irrelevance. Are you just rearranging deck chairs on some someone else's Titanic. That was the reason I bring that up is cultural change.
Obviously for people that have been through, it is really hard. And there may be problems that we can't solve. There may be problems that I can't solve. These are systemic thing, problems within the business that are never going to change. And, we refer to those as gravity problems. Like, you can jump up and down and, but you're not going to escape gravity without a Herculean effort.
And so we tend to either have workarounds or we deal with problems that are anchor problems. But if the problem is too large at your organization and you can't work around it, I would say go somewhere else. Just just a thought. Regulation and compliance will always chase technology. I hate that because we spend so much time on compliance.
And what is compliance? It's a check. It's a check box that occurred in the past. What good is that? Right. Well, there is value in it. But from a cybersecurity practitioner's perspective, we, we we recognize that. And we put that is we use compliance as a, as a conversation starter not to finish. You know, you start right.
Start with compliance and say okay yeah we can start here. But there's so much more to do. Yeah. And security programs that, thrive are the ones that lead with why likes that that emotional response, as we've discussed and build value with an enablement mindset. And, everybody that's what we had for you today. We have a few minutes for questions, sir.
I may have missed it, but what are your thoughts on this? After years of reporting with the Chief Risk officer? So that's a value. It's a I think the way I put that is it's it's good essentially. Right. My biggest thing is that cybersecurity should never be reporting to it, because we always have a different lens. There will inevitably hit a day where it says, but the user wants it, and we say, but it's not secure.
And if you're reporting to it, they're going to override that. And so that's not a good check and balance. I have a different answer. It depends on your and so in our in our case our chief, we have a chief risk officer. But he deals with project risk primarily and doesn't deal with enterprise risk which is kind of non-obvious.
Right. And so in that case, it's a little less useful for him to have that direct reporting relationship because we're, you know, we don't have that enterprise risk management program. Now. We do involve him steering committee and, and, in those in those areas. So he does have visibility into what's going on. But but it's not a direct reporting relationship.
Any other questions. Fantastic. Awesome. Thank you everybody. Appreciate this for the presentation. We appreciate you. We will have one more session in about 15 minutes. Mark Stewart.
