Name: Think like a Hacker, Lead like a CISO
Uploaded: 2025-12-02T19:16:06.698Z
Duration: 1 h 12 s
Description: Think like a Hacker, Lead like a CISO

Transcript for "Think like a Hacker, Lead like a CISO": So things like a hacker, lead like a CISO, welcome to this webinar. My name is Maxime Shardon. I'm part of the product marketing team at Artemis. Today will not be about me. I have three really compelling speakers that will guide us through a principle, if you will, a business principle and also cybersecurity principle where as the c suite, we need to be as flexible, as proactive, as creative as the hackers. That will be the theme of today's webinar. Kind of requires us to understand and anticipate all the motivations, all the tactics, all the methods of cybercriminals in order for us, in order for our organization to be more resilient and more secure. I'm gonna be introducing my speakers of the day. We have Curtis Simpson and Des Ridley from armies, and we have our special guest, Jason Howard Crowell from ATMG. So in order of appearance, would you please introduce yourself and maybe also provide us a bit with with the background that you have so that we can understand the expertise that that you make to this conversation today? You bet. Thanks, Maxine. So with that, I am Curtis Simpson, CISO and chief advocacy officer at Armus. I've been here now for six years, but I've had over twenty five years in tech experience, mostly on the enterprise side of the world. Fortune 100, Fortune 1,000, building, participating within, and leading security and tech programs at scale. And considering the topic, I should probably mention the whole reason I got into cyber in the first place is I was a hacker at a very end. So you have both sides of the story. That's interesting for today's conversation. Thank you. Desiree, what about you? Hi. I'm Desiree Lee. I'm the CTO for data here at Armis. I've spent my career in IT and security, but I've been with Armis for the last six years, and that's been a really interesting journey. When I started, we were 150 people and I think about 5,000,000 a year in revenue, and now we are, about a thousand people and much more than that. So I've been here through major acquisitions, through major product launches. It's been fascinating. I've learned a lot, and I'm happy to be here today. Absolutely. Great to have you here. Thank you, Desiree. And, Jason, welcome to the team. How are you? I'm good, actually. Lovely to see you today. I'm Jason Haugrow. Originally from Scotland for my sins, based here in Austin in Texas. Much like Curtis, I've been doing this for about twenty odd years, both in enterprise IT, OT, and also, on this side of the fence in consulting. I've worked some of the large telecoms organizations. I've worked in one in gas. I've worked in luxury fashion. I've worked, pretty much everywhere in some respects in some shape or form. The KPMG, I look after two key facets. I look after our ability to cover our energy natural resources and chemical clients, which is obviously is a big area for us right now. And I also take care of, operational technology stack because I visit those two very, very, very, very good things. Been with the firm about five years, and I've been, been focusing on response and recovery too. So a lot of, hopefully, useful conversation topics to have today. Absolutely. And this is a great mix of expertise to to start the conversation. And if you allow me, I'll just share this this visual because I think it speaks to all all of us in all organizations. One of the most compelling, I would say, triggers to to move to a hacker mindset or a more proactive mindset is the concept of left of boom. You can always debate about the numbers. We can debate about the the actual cost of a data breach, but I think there's consensus about one thing. The cost is in the millions, and the consensus is that it's much more cost efficient to invest left of boom, that is before the attack occurs, than having to invest in the, in the right of boom, which is all of the work, all of the effort that you have to put once, the incident has occurred, once the attack has occurred. So, the cost itself is a great motivation to to start adopting a different approach. But what does that really mean, Curtis, maybe for you from from your experience? What would does that what would that really mean to think like a hacker? Why why do you think that mindset is really critical today? Yeah. I often describe the CISO role as a translation layer within the organization, both for the executives within the organization and other leadership and stakeholders, but also for the team itself. CISOs have to very much understand what's most important to the business, where is the business going strategically and operationally, and then understand where is the business most exposed in terms of how could attackers disrupt what matters most to the business, how are they actively trying to disrupt what matters most to the business. And then on both sides of that conversation, the CSO needs to be able to guide their teams on the priorities based upon, again, what matters most, understand from their team what attackers are going after, and then bring that information back to executives to help them understand what the risk level for the organization looks like, what they're doing to reduce that risk, and what gaps they have that are gonna need to be addressed. So you have to be able to think that way, but you also need to be able to, again, understand how to correlate how attackers could actually affect your business in a meaningful way. And it is sitting at that translation layer that I think is incredibly important to continue to drive the program in the right direction. Yeah. That's that's a translation layer, and we'll explore that definitely during the discussion. I just wanted to check maybe from a different perspective. Desiree, you as a CTO, How would that how would that, how would you read that as a CTO? Like, how can you be more proactive when it comes to strategic technology decisions? How can you have a hacker mindset as a CTO? Yeah. I think that the that one major thing that's changed in in the adoption of technology is that, let's take automation or or now in its current form, you know, AI. Previously, even though it was available, a lot of the time we did not adopt automation. We kept process manual, because there is a risk to uptime from automating. I mean, automation always comes with a risk. Right? And when we made the decision to not embrace automation for those processes, it was because our cost benefit analysis was much different than it is today. And the thing that's changed is that the attackers are all using AI. Right? They'll use anything that helps them. They don't have to worry about a trade off between uptime and, you know, an automate the benefit of automation. Right? They'll just use anything that makes them faster and more powerful. And the advantage is such for an attacker that's using AI against a defender who isn't, that the risk of an automation failure, you know, that 1% of the time it gets it wrong, Maybe it's even more than that and actually impacts uptime. Suddenly, that risk looks much smaller compared to the security risks that translates into a real business risk now that the attackers have AI. So what I think it does is it shifts it shifts that calculation. It allows the the business to accept the risk of automation where before they might not have, And then it enables us as technologists to to bring in technology to to make processes efficient, to make sure that things aren't falling through the gaps, and leverage the tools that are available today. Again, given that that equation is so much different now than it was even a year or two ago. I'll say that for a little bit to that. Actually, that's what you're absolutely right. But there's also a a secondary consideration with the pervasive deployment of AI tools inside enterprises, not just from the outside. I've seen a couple of cases recently where one of the first questions you asked your your Microsoft Copilot when you when you gained admittance to an environment or an organization is, hey. Is there any credentials? Hey. Anyone got any information around usernames and passwords? And you literally you pump it into the internal AI. And if the organization is running too quickly, which we often are because we see the cost benefit of cost reduction, but we don't see the cost benefit of of control security, that results in some interesting outcomes. So we've had a couple of situations recently where bad guys are getting persistence. First thing they've done when we've done the forensics is they've dug into AI to see what can we find from inside the house. It's remarkably easy if you don't take the time and trouble to secure it properly. Yeah. And I think there's a there's a difference here between, adopting tools that have leveraged AI, let's say, like security tools or infrastructure tools that have leveraged AI to to do automation, which does allow, a defender to respond faster. That's right. AI versus having chatbots that make, marketing content that someone is, you know, filling with, with proprietary information. Those are two very different applications of AI, and I agree one is one is very much full risk. The other one, where hopefully, the vendors are doing it right, not as much. You add a GenTIG on top of that right now. We're also seeing the next level of consideration. So automated vishing is the other one I've just started to see popping up from places, which is also fascinating. We didn't have that a year ago. We're gonna see more, I suspect. Mhmm. Definitely shift from hackers being more proactive and more creative than than the defenders. So, really interesting. So what what I would suggest for for today's conversation to give a bit more structure is why don't we look at a few items through the eyes of the hacker, and then we reconsider this and and think like how can the c suite, adopt a similar a similar approach to this just like the hackers do? And I've identified a few. We can discuss things obvious things like the attack surface. We can discuss the broader shifts to from reactive to proactive. But one important thing that I I think would be really interesting to our audience is how do you make the business case? If the attack surface is one thing, the shift to proactive is obvious. The business case is, might be obvious to the hacker. A hacker might think like it might exfiltrate data from this or this organization. There's potentially ransomware. There's the financial gain or there's another gain. But how as c suite practitioners, how do we build a business case, from our defense perspective? How do we sell this to the rest of the business? I think this is a really interesting conversation to have as well. But first things first, if you allow me, the attack surface. And during the introduction, I heard things like, wow. We we've we've started with, IoT security. Today, the attack surface is so broad, so I I use the analogy of of the iceberg because of oftentimes, we would only see the tip of the iceberg. There's all kinds of factors, all kind of vulnerabilities, all kind of security findings. And, obviously, the hackers look at this as a whole. So there's no point in us or or the c suite to think in silos. We need to consider the full, attack surface. And maybe, Desiree, this is one that that resonates with you as a CTO. How do you think organizations can adopt a similar mindset, see the attack surface as a whole from the hacker's perspective, make sure they can, proactively address all these vulnerabilities before they are getting started? How how can we build a similar strategy there? Yeah. You know, it it was interesting because I when I first started at Armis, we were IoT, OT, unmanaged device focused. I mean, this is six years ago now. And the the reason why we expanded in the first place was because not not as many clients as we expected were interested in that information, which was which was a curious thing. Right? You can here's a tool. It gives you all the, assets that are unmanaged on your network. It even gives you the vulnerability for those assets. You agree that the information is accurate and you still don't want it. Why? And when you dig into this, it's not because the security professionals don't think that that information is valid information and important information for making decisions in in their network. It's that they're already drowning in problems that have clear solutions, and they can't they can't handle those properly yet. So why do you wanna add a stack of new problems with unclear solutions on top of it? So I I think that a huge part of being able to to to keep up with security and to make sure you're looking at the whole attack surface is to ensure that the core practices in security are efficient, that they're, again, leveraging automation where it's possible, and that they're your your team feels like they have capacity to to do more because if they're drowning with the things that are, you know, they're drowning with servers that have patches and defined CVEs. You know, they're not gonna they're not gonna go look at a bunch of IP cameras where the only solution might be to rip them out and replace it. It it's a human problem. In this case, less a a tech problem. Is it fair to say that if we want to consider this full attack surface, then we need what you were saying. We need automation. We need efficiency to kind of present us a manageable list of items to tackle. What you're saying is that, otherwise, we will be drowning and the human factor will just is will be set up for failure? Yeah. I I I think that it's it's a relatable problem. So absolutely is the answer to your your question. And I think anybody, if you came into work every day and you were presented with a, you know, a a mound of problems that you made a just a a tiny dent and and got no credit for it because it ultimately was was, you know, a a percentage of fraction of a percentage of what you needed to do. I mean, it would be demoralizing, and and, of course, you don't want more. Right? You're already you're already looking at failure essentially in the way you defined it, and you don't wanna add on top of that. So I think I I can't even blame that. That's just a very human instinct. And so absolutely getting control of the day to day and making sure that you have a path to success is critical for making sure that things that are more esoteric or, you know, newer or harder to deal with are are actually brought to the forefront. So I've put in a couple of other thoughts to the attack surface piece, and it's it's interesting on two fronts. One is, historically, we deal with and so the board deal with the the implications of regulation far more speedily when they're forced to. And I think what we're starting to see, specifically, and this is kind of broader on the attack attack surface side. If you look at the changes to the NIST framework, if you look at the NIS two in Europe, you're seeing, increasing regulation kind of pushing the requirements to behave holistically. And that much as Sarbanes Oxley did, if you're that old and you remember that, sorry. I feel bad, because I do. When that came into being, we all had to run around trying to deal with what are controls, how the controls work. We know controls don't don't address breaches, don't prevent breaches, but they are important facet and layer. When you think about attack surface specifically, we're seeing a push in regulation towards the broader attack surface. So looking at your third parties, looking at your supply chain, looking holistically at it, and understand the implications. And that's driving a conversation on board, and it kinda ties into some of the bits and pieces, I think, that that we've we'll probably get into later. How do you educate the board? Which is my second point on this. When you educate a board, the board conversations are often very much around, let's stop looking backwards and let's start looking forward and understanding it, Indicatively, what proactively should we be doing? And that's a measurement around attack surface. So it's shifting away from traditional vulnerability management to context based vulnerability management because not all vulnerabilities are created equally. Not all mitigation strategies are created equally. But educating and understanding that's crucially important, I think. Those two things are definitely starting to to push the conversation. In the attack surface, if you go all the way down to the basics of it, it starts with the orphan stepchild that we all used to hate in the IT landscape, which was your ITSM solution. No one wanted to deal with asset management. No one really wanted to spend any time on it because it wasn't important. It wasn't fun. It wasn't cool. It wasn't clever. But it's crucially important, and it's the foundation to your ability to understand your attack surface. And that's definitely come back up hugely over the course of the last two to three years. You're now seeing a lot of connections from a from a client perspective between understanding what your IT assets and your OT assets actually are, the posture of where they are, what you have, and also what's the risk of those assets based on the implications to your ability to trade. Those two things are definitely coming up more and more, I think, but happy to debate. To add to what Desiree and Jason said, I I totally agree, and I think we're in an interesting inflection point. So, historically, where teams have felt overwhelmed is the more assets we identify, the more exposures we identify, and our best practices say if they're this level of a CV, they need to be addressed within this given period of time. So higher number means higher level of work, and we just feel constantly overwhelmed. The reality though is it's not just about the assets and the CPUs anymore. It's about the attack path to the assets that matter. Yeah. The challenge historically has been we haven't really been able to identify attack paths in a clear and continuous manner, but the technology has evolved to the point that we can now. So it is as you think about proactive execution and actually convincing your stakeholders within the organization to take action against the attack surface, it's no longer about this is a critical exposure, therefore we need to act. It's more so now about this is part of an overall attack path that could disrupt what matters most to our organization, and these are the actions that need to be taken. So as we think about the attack surface as a bunch of paths, two things that matter and then the actions that we need to think about to disrupt those paths, That's what I would argue has become the reality of analyzing the attack surface. But when you think about it that way, you need to understand everything first. You need to understand all the exposures against everything in the environment, and then you need to paint the paths on top of all of that context. That today is is the attack surface, and that, I think, is actually a powerful place to be. We're in a more effective position than we've ever been to actually drive the right actions and even drive the right conversation within the enterprise. Yeah. I'm taking the hacker's mindset here. Have you seen, like, from your experience or your conversations with customers, have you seen unexpected or maybe unexpected attack paths that were taken by hackers that are often overlooked? Can you give us maybe an example of of what people tend to forget? We see this all the time, and it goes back to these best practice based programs. So attackers generally know that we're gonna address critical vulnerabilities within, let's say, thirty days. We'll address high vulnerabilities within sixty to ninety days. We'll probably never get to medium vulnerabilities because we're always focused on the criticals and the highs. So in more recent years, attackers have been stringing together medium rated vulnerabilities from a CBSS score perspective because they know we never get to them, and they can string them together in such a way commonly that they can build that path and still execute against the outcome that they're looking for, whether it's disruption, what disruption for ransom's sake, whether it's data theft, the combination thereof, whatever that is. So I actually find that more often than not, these attacks are surprising organizations because they didn't exploit the things they thought they needed to focus on based on best practice, not based upon the attack pass again to disrupt or affect what matters most. And I and I think just to add to that, I I'm still surprised, but I shouldn't be because it's it's still very common, when enterprises are choosing what to fix based on CVSS scores. And when you look at the the CBEs that are being used to breach organizations, they're not, you know, eights, nines, and 10 CVSS or CVEs. I mean, there there are lows and mediums because the attackers know how orgs have functioned for the last twenty years, and they don't patch lows and mediums. So the the path in is often using it's exploiting, something that falls through the cracks based on based on a process that's not up to date for the environment today. Yeah. I certainly agree with that. I mean, the the other thing I'd add to to both of your points as much as there there's a there's a CV challenge. I agree with you wholeheartedly. We still look backwards. We don't look forward. So the whole how do you get agile and understanding the attack surface, it's still amazing to me the number of organizations that we work with who don't understand where they are in the hurt in that kind of sense. And I hate the fact that we still play cybersecurity as a hard game. Don't get me wrong. But we know bad actors. I mean, Maxine, it was something that you said in the beginning. They have a business case. They look at they literally will look at the cost of an effort involved in targeting an organization, whether it's retail, whether it's manufacturing. They'll literally look at it and say, what's the effort versus the likely reward? And often if they've had time to be persistent, which they tend to, they'll know what insurance policies you've got. They'll know what your capital income is. They'll even know what your budgets are for spends. I've seen that on a couple of occasions, and they look and plan the time to target. What's fascinating about this, I guess, to a degree is that we're we're looking at it from a look backwards on the vulnerability around score base. Whereas what we should be doing, just to your point, is actually focusing on where is the target on the attack. What's the attack chain of something Curtis you've highlighted time and time again? Understanding how people are using it, but sharing that insight, We still have this thing of, well, I can't share any of this with my peers because, you know, if they know that we know something that yeah. It's it's we know bad actor groups share intelligence way better than we do because they pay for it. But they're happy to pay for it because they get insight. Hey. This worked and so and so. Go use that. On this one, I think you might you might find that successful. Give me a finder's fee. They think completely differently. The conversations I have at board level is you're thinking about this in the same way that you would plan a football defense. What you need to be thinking about is, frankly, touch rugby, which is a completely different game. And if you're playing football and they're playing touch rugby, you got a completely different outcome. They're gonna win. And those changes are kind of things we're seeing more and more often. So those conversations also add to the mix, I think. Now I'm trying to to kind of summarize this section around the tax surface before we move to the next one. Is it fair to say that, historically, attack surface management and all these technologies have been focused on the asset part and the vulnerabilities part? Whereas today, it's much more than assets and vulnerabilities. There are all sort of security findings. We need to factor in the notion of all of these attack paths, and then we we can use technology to kind of present us with a manageable list of items to address so that we can secure our attack surface. That is kind of the conclusion, for me, if you will, the short summary of of the section of of the discussion. Yeah. The the way that I see those things fitting together is I I think that we're we're rounding out the dimensions that we need to prioritize effectively. There's the there's the asset component, how critical is it, you know, how high risk is it. There's the findings component, whether that's a CVE or a misconfig or or what have you. How critical is it, by by a measure that makes sense. And then that third component when we talk about attack path mapping, we're we're really assigning some kind of an environmental variable. So or dimension to prioritizing. And when you piece those three things together, you can really focus in on what matters. So when I think about managing an attack surface, it has all three of those components included because otherwise, you can't prioritize in a way that reflects real risk. Yeah. So I think the other thing that I would add that I find is something that not all teams have necessarily focused on in terms of closing the gap that Desiree is speaking to is that overlay of what actually matters to my business. What has a meaningful impact on my business when it's impacted? This is a key element of prioritization, and this is one of the reasons why we've been historically overwhelmed as we think about the attack surface. Random Linux servers, random cameras, random IoT, or even BMS assets may or may not matter until you actually apply the overlay of how do I run my business? What are the most meaningful impacts when an outage is experienced regardless of the cause? What are the targets that someone would likely go after? Teams really have to focus on integrating or when we talk about context, we need to include that element of the context. And our tooling needs to be thought of, configured as such that that context is being pulled into. How we're actually thinking about what that attack surface looks like. And Jason spoke to actually speaking to the board and relating to the board, and we'll get to this. But if you don't understand how the technology ties back to the business, not only can you not prioritize or think about the attack service in a meaningful way, you can't talk about it in a way that anyone else but you is going to care. And that is a material problem that security teams have in terms of bringing their value back to the organization in a way that they can understand and appreciate. And I I have one more thing to add to that because I think it's so important from a from an asset perspective, and it's exactly this business context element. This is it's critical that your tool supports it, but I can guarantee you that the team that's running that tool is unlikely to feel empowered to start assigning business criticality and context to assets because if something goes wrong and that asset wasn't high or critical, that stakeholder in the business is upset. So it it actually needs to be an executive driven program to assign business context and criticality to assets in a in tandem with the business stakeholders. And so I I think, like, that that detail can't be overlooked. It has to be popped down because nobody who's just approaching the technology from a tech perspective is gonna be empowered to make those assignments. And that's where it goes back to the CISO being that translation layer. Because it one of the things that I learned a long time ago was that somebody has this information. And you as the CISO are responsible for figuring out who is this somebody, where is it, and how do I pull it into what we do. Like, whether it's the BCP or Doctor organization or the IT organization who's had to figure out what their technology business management or landscape looks like, Somebody has this information. Having run major incident management functions at scale, as an example, I needed this information at my fingertips to understand how to manage major incidents that were impacting the organization, so I had it. Luckily enough, I was also the person running cyber at the time, so I was able to take the insights from one team and feed them into another. But, again, this is where navigating those political lines are super important, and as CSOs, we need to figure out where our translation layer is not working, and when we need to, and where we need to get information from to fuel that translation. Sorry. I cut you off, Jason. I'd be out here. No. You're perfect, Curtis. I'm I'm kind of saying really. I'm I'm looking for them to to disagree with because it's much more fun when we disagree. Right? But in fairness, I think I think you're right. The the the only thing I'd kinda add to this is contextually again. This ties back to our business case, and I know we're gonna get there, Maxime, so I don't wanna steal the thunder. But what we tend to find happening more and more often, certainly, at board level is you have a conversation around crown jewels. Not all things are created equally, and we know that. Not all assets are created equally, and if you have an understanding and I still am amazed at the number of organizations that I work with who struggle to articulate, one, what their crown jewel assets are, and two, understanding what they actually have in those crown jewels. So you debate at board level those conversations, and you're right. As you know, it's the same part of it. It has to be top down. And, normally, it's someone like a COO or a CFO who will say, oh, you know, what what if if that happens, what will we do and how will we do it? And that's part of the board education. I think it's translation and education kind of, if I can add to it, because it's the education and awareness piece of the conversation. Most boards that we get involved with from a response perspective have already been punched on the nose, and they're bleeding. And they understand they're bleeding and it hurts now, and they're trying to figure it out. We're trying to say be left a boom, learn more, be better, and be smarter, be more capable, understand it. The board need to understand that there's a preventative cost. And understanding that preventative cost comes back to being able to say, I understand the implications, which I know is good. Hopefully segues nicely into going proactive. But those conversations start with, do you understand what the cost of your business would be if you lost the ability to transact? And you're right. Someone knows it from a business continuity or resilience perspective or disaster recovery perspective. It's there somewhere. But if it isn't surfaced in the right way at the right time, I e now, you're always gonna be playing catch up in my opinion. Yeah. Thank you for adding that business context layer because I don't wanna have a silent conversation. It's not because I bring this as as three, separate themes here on the screen that we should stick to one or the other. It's just to give a bit of a structure. But the business context layer, as you mentioned, in the the light of the attack surface is super important, but will also be super important in on how you build that business case and investment. So, definitely, we'll we'll come back to that in in a minute. For the sake and the interest of time, I want to spend some time on the core concept of shifting from reactive to proactive. And this could be actually, interesting because from your experience and talking to customers and prospects, I'm sure you've seen some red warning lights. I mean, I can give you one that I heard before is that when hackers are using AI to attack us, we shouldn't build our defenses using spreadsheets. Right? This is the the red warning light is if an organization is using a spreadsheet to kind of, organize their their defense based off CVSS scores or other static scoring mechanism, then definitely, you know, something is is wrong there. And is there are there any other examples that you have seen where talking to customers, talking to prospects, you say, oh, this is a typical, classical case where organization are still very reactive in their approach? Yeah. I've got a couple that I can log in, and I'm pretty sure everybody else can too. So two obvious ones that we see time lost time. We touched on business continuity and disaster recovery planning, and those two components are important. But if they're not updated, they're not owned, they're not they're not proactive. Nine times out of 10, the first question I'll ask before I get into it in a meaningful way to test for productivity is, hey, guys. When was the last time you actually did a test? And what were the results of that test? And, normally, what you tend to see is, oh, we run a tabletop exercise once a year with, you know, people or what yeah. We'll we'll do a segment of x, and we'll do a component of y. They don't necessarily think about it in the context of, hey. You know, we've actually tested this appropriately, which is an indicator that you're not thinking about what could go wrong. Often, you can even start with the simple thing. They don't even have a disaster recovery plan that incorporates a a widespread cyber outage. So cyber impact, something like that, doesn't actually it's not listed, so it's not in the potential. So it's not even in the lexicon. So that's kinda one thing. The second thing I normally tend to do is I always ask a reasonable question. Can you show me your board metrics? As an ex CISO, I'm always interested to know what are you reporting. Nine times out of 10, what you see is the rear view mirror perspective, which is here's the number of instance we had last month, last quarter, last year. Here's the number of indications of compromise that we had. Here's the number of assets that we fixed. Here's the number of vulnerabilities we identified. Here's the number of things. And that's really important. Don't get me wrong. I'm not saying you don't do it, but it has to balance with what are we seeing out there? What's the radars what's on the radar that we should be worrying about? What are other organizations doing? What are our threat feeds telling us? What are bad actor activities indicating? What are the geopolitical considerations? That's the kind of thing that you tend to wanna see from a more proactive proactive business scorecard. And the other part is really simple. You talk about an incident, it's an abstract thing. If you talk about a loss of production with a value attached to it, which is what I ended up doing, we lost the ability to refine. We lost the ability to manufacture. We lost the ability to run code. That cost us a, b, c, d, and e. That becomes very real, and the CFO can then dig into that, which they often do because they love the numbers to say, okay. So if that happened and that's the consequence from that happening, what would the implication be? So those are kind of two or three things I tend to see. And the other one, which is the most embarrassing but basic, is do you know what your asset inventory actually looks like? Are you quantifying and managing it? Is it really truly evergreen? And we talked about spreadsheets. I'm still amazed at number of assets that I'll go to sites, and they'll have an engineer has an a spreadsheet or a word document with all the things that they captured or the not even them. The the third party that provides their support, or they want all that for us. I'm like, wait. How can your third party know about your assets in your industry? Well, just because they run it for us. Those are red flags for me. Yeah. There's any others? Completely agree with all of those points. And just to add on to something what Jason said, because I think that's very, extensive. I do think one of the challenges, we go back to some of what we're talking about before where we still see this proactive lens, is that rear facing perspective on things like patching. So the the what I find is still amazing to this day is we're looking at measurements like mean time to remediation. And when you talk about AI actually accelerating execution, what we're seeing today is AI actually rapidly identifying that something is now exposed, figuring out how to exploit that new exposure and then exploiting the exposure. Our MTTR measurements are dead in the water. They don't matter anymore. You know, it's so it's this odd situation that we're in. What we need to be, to Jason's point, really looking at is not only just patching because honestly, within large organizations and coming from an OT driven organization from much of my recent past, the challenge is is you commonly can't patch. And even when you can, it just takes too long. Trying to navigate through all the operations to minimize impact, etcetera, and going through change management processes can take a minimum of thirty days regardless of the criticality or severity. So what when you but if we start taking a step back and saying it's not just about the patch, and it's not just about following those best practices and reducing my MTTR. It is about understanding those attack paths and understanding how can I disrupt them? One of the the trappings again that we fall into all the time is we're not thinking about what we already have across our extensive set of tooling and capabilities across the enterprise and how to disrupt the attack path. That to Jason's point, threat actors are either already going after in our industry against similar technology or thinking about going after based upon the intelligence that we're seeing, and then using the tooling that we have to affect those attack paths and buying ourselves time to take the additional actions that are required. Because I go back to, I believe, what Jason said earlier. If we slow down attackers or make their execution difficult, well, honestly, more often than not, just stop and move on to a target where difficulty is low and success likelihood is high. So often we need to remember as we think like hackers, this general practice of, if we introduce a high level of friction through our proactive execution based upon attack path disruption. That's the way we need to think, not just about, I need to apply a patch. I need to to reduce my MTTR. AI is accelerating the need for this to get better. That's not really the way to think about it. I find that we constantly fall into that trap still to this. And I think the I I love what your your point that you just made, Curtis, but also the point about metrics overall. Because what I think is hard is as a technologist going to a a board or senior leadership and talking about attack paths. Because unless you're a technologist, it it might not mean anything to you. And what I think we're gonna see is that the the metrics that most organizations are currently looking out to the board are just they're not accurate anymore. What they what we to see is that the, the assets right in the business context and your success criteria and metrics that you track is not based on the entire environment as a as a whole, or even, you know, the the broad strokes of SLA, but but understands how critical the asset is and how critical the finding is. And I think that that half component needs to be reduced into a dimension that can be rolled up into a metric, and that metric needs to become, something close to industry standard because ultimately, people want to compare the metrics with their peers. So I think that there's some, market shaping that needs to be done. Still, we have to read on what those new metrics are. And then I think somebody in the organization has to be brave enough to switch to those metrics to explain to senior leadership and to the board why the numbers that they're seeing are changing, why this is better and more accurate instead of sleight of hand to make the, you know, the the high team security departments look good. And that is brave, not tongue in cheek. Like, that's a brave conversation to have. We're gonna need that to happen in every organization for us to actually drive towards low targets and have, you know, incentives be correct for the environment that we need. Yeah. And in terms of the shift to proactive, can you try and make that tangible? I I get your point, Curtis, like, like, making sure that we disrupt the attack path, making sure we produce more friction so that hackers would eventually go with a different target. Can we name a few examples of where technology helps us to to introduce that disruption? I can think of one that you gave at the beginning, Desiree, to say, automation in the past would be something where where we didn't really accept the trade off. But today, that that, conversation has has changed. We kind of accept more automation to take a more proactive stance and to disrupt those back path. Are there any other examples that we can share with the audience where where we can where technology can help us to achieve that proactive stance? Yeah. I can actually play off that note of automation in a very, tangible way in terms of what not only I've done in the past, but what we see in many OT organizations as an example. One of the challenges, for example, that OT driven organization space is you often have this very large IT footprint, a very large OT footprint, common integrations between the two. The challenge though in many environments is that one of the reasons why attacks move laterally through the networks without a lot of impediments is because communications are wide open. Historically, as we've integrated networks, as we've enabled communications between different systems, platform services, etcetera, we've generally said that everything moving from one system to another is acceptable. What we now have contextually through tooling in our landscape is the ability to understand what is actually happening, what ports and protocols are being used, how are these systems communicating with one another, how can I control these communications, And what we can now do automatically, ideally, is analyze that context, apply controls like segmentation controls, like, communication impediments through firewalls and tooling such as that to actually limit what communications are allowed between different systems, what services are allowed to communicate with one another? We can do this automatically now, and we can do it safely, which is the key. Historically, automation has been seen as a risk because we didn't have enough context to safely automate. We do now. We have enough context to understand how the business is actually functioning and what actions we can take to reduce the attack surface. So honestly and often, being proactive is about reducing the attack surface to the minimum footprint the business needs to function, but specifically in relation to the elements of the attack surface or those attack paths that relate back to those critical assets, those crown jewels as Jason said. It's about narrowing the communication against, around, within systems that matter most and the attack has to tie back to those systems that matter most. And those are some of the actions we can apply today. And often if we do that, when a new attack comes to light or a new, exploit comes to light that attackers are taking advantage of, we've commonly implemented some of those impediments in our environment to intrude their upon their ability to actually execute the attack. Therefore, we become less appetizing as the target, and it's easier to go after someone else who hasn't implemented some of those products. I think that's a really great example. And again and for in the interest of time, we'll we'll still have to cover the business case, and that's a really important one. So trying to wrap things up around this major shift to proactive is that, introducing friction, introducing disruption to these attack path is key. And we have the technology today. I think, for example, of the the segmentation that we can apply automatically and kind of discourage hackers to choose us as a target is a really compelling example. So thanks for sharing that. Historically, CFOs, COOs, they see cybersecurity. Well, I'd say historically, maybe it's still the case today. They see it as a cost center. Just another cost center. How do we flip that narrative? How do we make sure what metrics do we need to use to kind of demonstrate, ROI when it comes to cybersecurity? How do we communicate that to the board, to the decision makers? That is kind of the the last aspect that we wanna cover today, and I think your your experience will be very valuable here as well. So a couple of things I think we probably wanna just touch on in this space. The CFOs and COOs are are obviously the most important group in in many respects in terms of understanding the business case and the need. We touched on a lot of things already, so I'm not gonna go go back over those. But here's two things that are probably worth thinking about. The first one is that we're seeing a shift in things like the cyber insurance market, which are very much focused the focus of the CFOs. They understand the cost of cyber insurance. They understand general underlying insurance. And that changing market is also changing the way that they're reacting to cost reduction and the opportunity case that comes with it. So if you think about it in the context that cyber insurance is an expensive thing. It's got more and more expensive over the last seven, eight years. Claims have been challenged consistently, and we're seeing time and time again that there's a requirement that they've got tighter, let's just say. Insurers have woken up and smelled the coffee and recognized these things things differently. But we're also seeing, interestingly enough, is that where organizations have had issues, they can bring the cost of their cyber insurance down by deploying security capabilities. Those things are directly correlated. And the what that does, it actually helps the first part of a very simple business case for a CFO to say, if I'm spending 2 and a half million a year on cyber insurance, but if I deploy these solution sets, I can reduce that to 1,000,000, that actually gives you a bankable value. And when you discuss it as a business person, we've been the CISO or the cyber cybersecurity professionals, with the CFO saying, this is the actual cost avoidance that we can generally go after. That makes things much more interesting, and they're actually more prepared to invest if they actually understand the mechanics behind the bottom line. So that's one really good example I think that's useful to talk about when you talk about business cases. Where can we find the opportunity to reduce cost? I touched on it in terms of metrics a little bit. I think this one you also said the same thing, which is metrics need to be need to be brave with your metrics. It's no longer how many instance did we have. It's now how many what was the cost of those instance, the implications, and the impacts? What's the meantime for recovery? What are our resilience piece? So that's the other thing I wanna touch on a little bit. Business interruption risk is a big deal. We're seeing it more and more. We're also seeing I talked about regulation. Regulation is now forcing conversations around how can we be resilient and recognizing that you can't afford to spend resilience dollars everywhere. You need to be smart about what you do it. So what we're seeing is the conversation around the business avoidance and the interruption avoidance is actually one of the pillars for your ability to operate better. And that's a business case value you can play to. The third one, which is the last one for me, and then I'll I'll shut up. Very much around the ability of an organization to transform. We're seeing more and more transformation based conversations. We we know that a lot of organizations have a staggering tech debt. They have to transform the way they operate. We're seeing that with the way that the the integration with ERP and the changes to ERP transformations. And what we're doing is we're actually having a conversation at the beginning, which talks about and this is something that I've done contextually a lot. You ask the question, why do you have brakes in the car? Normally, the CFO and the board will say so you can stop. And the answer is yes. That's true. But if you have brakes in the car, you can actually go faster because you know that when you need to stop, you can tap that pedal and you will. That's what cybersecurity brings to you. That's the assurance that you need to have in place to be able to operate. So when we're doing transformation projects, and we're doing a fair few of those right now, the business case actually bakes in cybersecurity because it recognizes the size and scale of the disruption and the increase in the attack surface that you're gonna have because much like you do when you do a a factory shutdown or a turnaround, the number of people dealing with systems goes up exponentially, and the risk to your organization, therefore, also goes up exponentially. Those two things tend to drive a lot of very simple discussion around avoidance of risk. And CFOs absolutely do understand risk now. That's my thoughts. Yeah. And to add to what Jason said, my my experience with boards in the Fortune 100 space in particular is they very much think about the risk world and the likelihood and from a likelihood and impact perspective. And one of the things that I found resonates most and why I touched on the business context is being so important. It's not just in terms of how we prioritize our technical actions, but how we actually relate what we have done, what we're doing next, and what we can't do back to the board and a likelihood and impact perspective. And to Jason's point, and one of the things that I've seen work really well is when security teams really think about heat maps from a core or critical or crown jewel business system and capability perspective, whether that's new strategic capabilities that are being built out as part of that transformation, whether that's the systems that everyone knows matter most to the organization, being act able to actually paint a heat map based on the attack past that we know we're either already disrupting disrupting next or not disrupting. We need to be able to paint a picture to our boards that explains this is the heat map for the things that matter most from a likelihood and impact perspective. Here's the general, explanation of what I've done to introduce the trend that you're now seeing quarter over quarter to pull some of these things down from a lower likelihood, lower impact, or where's we're focusing next because these elements are still in that upper right hand quadrant where we don't want them to Jason's point. And what we also need to do and work with the right, whether it's teams or BCP and Doctor organizations, is quantify the quadrants of our heat map. So if something is in that upper right hand quadrant, we should be able to quantify not only what the likelihood is within a time frame, but what that impact actually is from a dollar perspective. So as we continue to spend money, resources, etcetera, and bring those elements of the business out of that upper right hand quadrant, we can justify the actions we've already taken, we need to take, and also explain what we don't have the capabilities to disrupt and why we need to invest because it is really that dollar figure understanding in terms of what is that impact gonna be, what's the likelihood of occurring within the course of a year or otherwise, and what does that investment need to be that board members, senior executives most understand and resonates with them most. That's where we need to be able to talk about what we're doing and why we're doing it. And I love that dollar value that you bring to the discussion because that that brings us back to the beginning or the opening of our webinar, which is to say all the dollars that you spend left of Boom are way more efficient than the dollars that you would potentially be spending right of Boom. Right? 100%. 100%. Well, we're near the end of the webinar. Is there any final thoughts you wanted to add, Desiree? I wanted to give you a chance as well on the business case. Yeah. I think that just just one point. I think the advice here was was great, so I won't add to that. But the, you know, the the problem that we face, the challenge that we face on the defending side is that the attackers are are unconflicted. Right? They have they have a purpose. The the purpose is to to breach or to hack, and they're not intention with that whereas, you know, there's no defender that's existing just to defend. Right? We there's an identity to the organization that has nothing to do with the the cybersecurity practices that it has. And I think that that's the that's the inherent tension that we deal with. Must be nice on the attack side to have, to to have no conflict there. But but that's the complexity of the problem for us is, of course, there are many other things that we want the organization to do and to focus on that that aren't, security related and making sure that everyone understands how how security can impact those other things that are more core to the identity of the business is is the challenge ahead of us. Well, thank you so much to the three of of you. I think we we were able to articulate some different viewpoints to really bring some expertise to the table. We we covered in a very smooth way. I think the transition from looking at that attack surface to the the eyes of the hacker, taking a more proactive stance and ultimately building the business case. So, again, thank you so much for for participating today. And with that, I would like to thank our audience and wish you a great rest of the day. Thank you.