Debunking Cybersecurity Misconceptions, with Michael Irwin

1 - > Aaron Bock: Welcome to the IT Matters podcast, hosted by 2 - > Opkalla. We're an IT advisory firm that makes technology easy 3 - > for your business. Our vendor-neutral technology 4 - > advisors work directly with your team to assess technology needs 5 - > and procure the best IT solutions for your organization. 6 - > On this podcast, expect high-level expertise from our 7 - > hosts, plus experience-driven perspective from the leading 8 - > experts on topics like AI, cybersecurity, industry-focused 9 - > IT solutions strategy, and more.

Now let's get into today's 10 - > discussion on what matters in IT. 11 - > Keith Hawkey: And welcome back to the IT Matters podcast, 12 - > hosted by Opkalla. At Opkalla, we help IT teams understand the 13 - > busy marketplace of technology strategy and services with a 14 - > data-driven approach. And on this podcast, we invite 15 - > technology leaders to discuss the challenges facing the modern 16 - > IT department.

My name is Keith Hawkey, technology and podcast 17 - > host of Opkalla, welcome to the IT Matters Podcast. Today's 18 - > episode is going to be a little different, in a good way, 19 - > because we're going to challenge some of the assumptions that 20 - > have become pretty standard across the cyber security 21 - > industry. We hear all the time, more spend, more tools, more 22 - > complexity, but at the same time breaches aren't slowing down, 23 - > and I think a lot of the technology leaders are starting 24 - > to ask a simple question: Are we actually getting better or just 25 - > getting busier?

I'm joined today by Michael Irwin, CISO for 26 - > Odyssey Logistics, who brings a perspective that I think cuts 27 - > through a lot of that noise. Michael has spent time inside 28 - > environments where the stakes are real and the constraints are 29 - > real and the decisions aren't made in a vacuum, and he's not 30 - > afraid to call out where he thinks the industry might be 31 - > getting it wrong. And in this conversation, we're going to get 32 - > into where cybersecurity investment might be missing the 33 - > mark, and how to think about trade-offs between operational 34 - > friction and real risk, and why it matters when you don't have 35 - > enterprise-level budgets or resources.

Michael, welcome to 36 - > the IT Matters podcast. 37 - > Michael Irwin: Thank you for having me. 38 - > Keith Hawkey: So, there, okay? Before we begin, there's a 39 - > little game that we play here to prime the session.

Have you ever 40 - > played Two Truths and a Lie? 41 - > Michael Irwin: Two Truths and a Lie. I have. Yes, 42 - > Keith Hawkey: the name is a little bit self-explanatory, so 43 - > I'll..

these are cyber security. Well, actually, today it's a 44 - > little less cyber security related, but it's tech related. 45 - > Okay, and let's see if you can guess what the lie is out of 46 - > these. So the number one AI powered holographic companions 47 - > were introduced that sit on your desk, talk to you, and help with 48 - > task, and even give you personal advice.

This was introduced at 49 - > the latest CES consumer electronics show this year. 50 - > Number two, a startup has created a device that lets you 51 - > upload your dreams and share them like videos with other 52 - > people. Number three, robot vacuums are being designed with 53 - > legs, so they can climb stairs and move between floors without 54 - > human help. Let me know if you'd like me to repeat any of these.

55 - > Michael Irwin: Well, I'd say in this day and age, anything AI 56 - > related is perfectly feasible, that somebody's selling a 57 - > product with it, right. So I don't want to go towards that 58 - > one. Let's see, the I think I had seen something about some 59 - > brain scan related imagery for dreams, or associating that, but 60 - > that would normally be where I jump to. But I think I'll stick 61 - > to the simple robot vacuum with legs.

I have one, and it rolls 62 - > around the house, and it's gotten smart, but legs it has 63 - > not gotten yet. 64 - > Keith Hawkey: Well, I'll have to say much to your amusement. 65 - > Robots do have legs now. Our robot back of the vacuum 66 - > apparently company named let's see Robo Rock unveiled devices 67 - > like the Soros rover, featuring a wheel leg design that can 68 - > actually climb and clean stairs, something traditional vacuums 69 - > have never been able to do.

70 - > Michael Irwin: Wheels and legs, though, that seems different, 71 - > though. I wouldn't call wheels legs, there's a trick, 72 - > Keith Hawkey: Maybe it was, maybe. A trick, and in addition, 73 - > the gaming component company Razor has come out with an 74 - > AI-powered holographic companion that it's actually very strange. 75 - > It sits on your desk, and you can talk to it much like I guess 76 - > an Alexa, but there's a visual component to it.

It sits in like 77 - > a little box, and you can adjust the looks, and it speaks to you. 78 - > They are calling it Project Ava. 79 - > Michael Irwin: Oh, 80 - > Keith Hawkey: and to my knowledge, you might have 81 - > knowledge that I don't. I don't think there's been major news of 82 - > a startup that has a device that captures your dreams quite yet.

83 - > However, honestly, I might just not be read in on that 84 - > information yet. Well, 85 - > Michael Irwin: no, I think I read something about like brain 86 - > activity during dreaming and sleeping and tracking that, but 87 - > certainly you're not going to have a video of what that dream 88 - > was, I'm sure. So, no, that's interesting to hear. 89 - > Keith Hawkey: Yeah, I'm sure.

I'm sure it's coming, coming 90 - > very soon. So, let's, you know, a lot of what this episode is 91 - > about is challenging assumptions that are industry-wide within 92 - > the cybersecurity landscape and industry, and it's gone through 93 - > a tremendous amount of change over the last five years, last 94 - > decade. Before we start, there, Michael, can you tell us a 95 - > little bit about how did you get into it? How'd you get into 96 - > cybersecurity?

A little bit about your journey, and kind of 97 - > where you got, how'd you get to where you are now? 98 - > Michael Irwin: Sure, yeah, my really, my entire career path 99 - > has been IT oriented, so I kind of started my career in managed 100 - > service provider space, small, midsize consulting, or IT 101 - > consulting, which I think is pretty common. Ultimately, at 102 - > that time, was looking for an organization that I could really 103 - > establish roots at, and something that I could see the 104 - > long-term value of the work that I was doing, rather than kind of 105 - > jumping into each fire, as I was kind of going customer to 106 - > customer, and so that landed me at a media company in 107 - > Washington, DC.

So it's an ABC Seven affiliate, but also a 108 - > media company that focused on political media, and I started 109 - > with them kind of as a consultant, as somebody that was 110 - > helping during the transition of a previous employee, and just 111 - > was able to find an opportunity there, and that was something 112 - > that I kind of grew through the help desk space, really, and 113 - > more IT generalist at the beginning, but the track of help 114 - > desk management leading into IT director kind of roles, and then 115 - > really building a cybersecurity program at that organization 116 - > within kind of the efficiencies that we found within the IT 117 - > budget allowed us to really align those two things, I was 118 - > there for about 12 years, and then ended up transitioning to 119 - > another organization when I moved down to Charlotte, North 120 - > Carolina.

So, obviously, logistics were headquartered 121 - > down here. I always, I always enjoyed the fact that 122 - > cybersecurity is really industry agnostic. I was kind of curious 123 - > about the idea of can I replicate the things that I did 124 - > in this organization, and can I bring value with that to 125 - > another, and that was kind of one of the things that I was 126 - > looking for coming here. Obviously, Odyssey Logistics is 127 - > a much larger organization, we're a global multi-multimodal 128 - > logistics provider, and so we had a lot of presence kind of 129 - > around the world, including in the United States.

So, bigger 130 - > teams, kind of bigger budget opportunities, kind of bigger 131 - > scope of responsibility, and I think all of that was an 132 - > interesting challenge, and what, what I found was much of my 133 - > roadmap at an organization that was significantly smaller in a 134 - > different industry really resonated in this one. Also, it 135 - > added a lot of value, they had the similar challenges, they 136 - > might have been at different stages of maturity, kind of in 137 - > their technology journey, but really a lot of close alignment, 138 - > and I think that was really eye opening to me, how a lot of 139 - > those kind of simple things were able to land in such a good way.

140 - > So that's kind of how I found myself here. I was brought in to 141 - > build a security program, primarily, but early on was kind 142 - > of given responsibility for the IT operations function as well. 143 - > Keith Hawkey: And you've said the cybersecurity industry as a 144 - > whole has failed, despite record spend and tooling, what do you 145 - > mean by that? What, what are we measuring wrong exactly?

146 - > Michael Irwin: Yes, man, at the end of the day, it's kind of the 147 - > nature of the function, right? Cybersecurity is asymmetrical in 148 - > general. We have to protect everything, and a bad actor has 149 - > to find the one thing that we didn't protect. So, the odds are 150 - > kind of set against you to begin with, but I think what you look 151 - > at is, you have a lot of conversations around budget 152 - > opportunity, team size, resource challenges, alert fatigue, like 153 - > there's all these conversations about the challenges in the 154 - > space where generally, and everyone would say they don't 155 - > quite have enough cybersecurity budget right now, but generally 156 - > speaking, cybersecurity budgets have grown annually.

Most 157 - > organizations are spending more than they ever have. Most 158 - > organizations are building cybersecurity departments or 159 - > functions that maybe lived inside of an IT operation 160 - > function historically, and so the function is growing. There 161 - > is no shortage of tools and services in the space that you 162 - > can buy to solve your challenges, and so you're 163 - > spending more, you have access to more technology, you have 164 - > access. More resources, but breach incidents grow and grow, 165 - > right?

And the breaches you hear about aren't at every small mom 166 - > and pop shop, but they are organizations that might be ISO 167 - > 27,001 compliant. They might have a SOC two type two. So, if 168 - > you have these mature organizations that are still 169 - > experiencing breaches, and you assume that they likely have 170 - > more adequate funding and resources to monitor what's 171 - > going on, like, how does that reconcile, right? And I think a 172 - > lot of it is, we're measuring effort, we're not measuring 173 - > outcomes, we're still looking at kind of identity, is still that 174 - > perimeter that we're dealing with, we're still looking at 175 - > this castle concept in a lot of ways, we're dealing with a lot 176 - > of legacy infrastructure, and I think a lot of that is that 177 - > misalignment between cybersecurity and technology, 178 - > much of the risk we deal with in this space lives in the legacy 179 - > world, and if you have a technology roadmap that's not 180 - > focusing on that, or you're not focusing on the kind of the 181 - > housekeeping basics of stale accounts, or permissioning 182 - > creep, or configuration problems, if you're not focusing 183 - > there, but you're focusing on that new tool, you're likely 184 - > missing the mark of where the majority of the trouble is.

185 - > Keith Hawkey: Yeah, I think you're exactly right. Just wait 186 - > for Gartner to come out with a new three or four letter 187 - > acronym, and to start a buying cycle for said tooling, and a 188 - > lot of that's laying on top of where the real risk lies, which 189 - > is a lot of the maybe traditionally on on-prem 190 - > infrastructure, some of the, some of the policies, the holy 191 - > grails of organizations that new IT leaders don't really want to 192 - > touch, because they're afraid to break certain things.

You, you 193 - > shared an experience where delaying MFA implementation led 194 - > to a major incident. Can you walk us through that decision 195 - > process, like what pressures were at play, and what you would 196 - > do differently today? That's a kind of personal antidote we had 197 - > spoken about, but I'm sure that would resonate with some of 198 - > these cyber security leaders out there. 199 - > Michael Irwin: Sure, I mean, this story is pretty 200 - > straightforward, and hopefully for most people listening now, 201 - > like this isn't still an active problem, because these controls 202 - > have been needed for quite a long time.

But earlier on, when 203 - > I was dealing with this issue, what it boils down to is the 204 - > usage of multifactor authentication alongside the 205 - > usage of single sign on as a larger initiative, so getting 206 - > away from distinct username and passwords for each service, more 207 - > central identity management, ensuring that you have the right 208 - > password policies, ensuring that you have multi factor 209 - > authentication for everything, and the expansion of that effort 210 - > is something I think a lot of organizations have are either 211 - > actively going through today or have dealt with in the past, and 212 - > during this time we were expanding on single sign on in 213 - > that, in our, in that particular moment, there was a lot of 214 - > friction relating to kind of user experience challenges, and 215 - > so users had a particular understanding of what they 216 - > wanted to do, what they thought was appropriate, what might 217 - > impact their productivity, they had preferences on what tooling 218 - > they got to use, or collaboration suites, and so it 219 - > was a very kind of user experience oriented culture 220 - > there, and they preventing any interruption to productivity 221 - > culture, and so with that, we rolled out single sign on.

We 222 - > had documentation and training around how to enroll your MFA 223 - > device, how to log in. That was all great. As we went to expand 224 - > that functionality, we ran into a particular function, so VPN 225 - > connectivity, that is something that traditionally didn't use 226 - > multifactor authentication. You might be using simple username 227 - > and passwords in order to integrate that functionality 228 - > into that same single sign on system, maintaining the same 229 - > ease of use that customer or that employees were 230 - > experiencing.

We weren't able to do that immediately, so it had 231 - > some native functionality built in, some email based time codes, 232 - > things like that, but didn't yet support the integration with our 233 - > existing identity provider, and so what we chose to do was say 234 - > rather than teach something else, rather than teach this new 235 - > way of logging in, we're going to upgrade our firewall, we're 236 - > going to upgrade that firmware, we're going to get that 237 - > compatibility, and then we're going to roll out the way that 238 - > we intended to, it's effectively looking for the perfect solution 239 - > instead of progress, and in our case that decision, which really 240 - > was just a delay of a few months, ultimately resulted in a 241 - > large-scale incident that required quite a lot of kind of 242 - > effort and financial resources to remediate, and ultimately was 243 - > handled all right, but it's one of those things that you have to 244 - > kind of go back and think, if I had prioritized differently, 245 - > would this incident have happened?

I'm a big proponent of 246 - > not looking back with the same sort of perspective and saying, 247 - > you know, there's something we did do that didn't allow an 248 - > incident to happen. So, when you flip priorities, you can't just 249 - > say that it wouldn't have happened that way. That benefit 250 - > of hindsight, I think, doesn't favor people in this space very 251 - > well, and so I think that's one that I try to look back at, is 252 - > whether I'd make the same decision, and in my case, I 253 - > think what the way I approach things today is more in a 254 - > vacuum, it's more risk-focused, it's saying if the worst were to 255 - > happen, what's the impact of this thing, this control that 256 - > we're trying to.

Impact really taking all of the other factors 257 - > out of it and saying what's the what's the right thing to do 258 - > first and then starting to look at how you can kind of modify 259 - > that and fit into a larger strategy but when when you're 260 - > looking at something purely from the angle of satisfaction I 261 - > think you miss some of the the signs of higher level of urgency 262 - > relative to the risk you're actually dealing with, 263 - > Keith Hawkey: And those are those are great points, Michael.

264 - > It actually goes, flows into the same vein of other points that 265 - > you've argued that proactive disruption is much, much 266 - > preferred than reactive chaos. I actually love that, that way of 267 - > phrasing, proactive disruption is better than reactive chaos, 268 - > which is much of what an IT or cyber security leader is dealing 269 - > with today. A lot of them are reactive in the chaos, and some 270 - > are, I think, are a little bit too slow to engage and make the 271 - > case for that proactive disruption, whether it's 272 - > password rotations, whether it's service accounts or restarting 273 - > aging infrastructure.

How do you decide when to accept that 274 - > operational pain today versus the risk to tomorrow? Do you 275 - > have a framework that you work off of? 276 - > Michael Irwin: I wouldn't call it a framework necessarily, but 277 - > I think a general principle is that if we're nervous to touch 278 - > it, then we need to touch it, right? It gets this idea of if 279 - > there's uncertainty like that, need that means we need to act, 280 - > and ultimately, if we're going to take the hit, I'd rather take 281 - > it on my own terms.

So, if we have change management 282 - > procedures and we're evaluating what the outcome might be if 283 - > something bad happens, we understand what rollback 284 - > procedures we have, or we can control it. We have the ability 285 - > to fill in the gaps on that uncertainty more proactively, 286 - > and so I would say it's less of a framework, so much as you are 287 - > developing policies and program guidelines that force you to 288 - > touch everything. You need to audit and evaluate the 289 - > infrastructure you have.

You need to do proactive patch 290 - > management and vulnerability management on infrastructure 291 - > that will require restarts, you need to be rotating passwords on 292 - > service accounts that have maybe been around for a long time. You 293 - > need infrastructure to do that more automatically. You need to 294 - > be able to have those processes in place that require you to run 295 - > into these problems, because ultimately, when an incident 296 - > happens, the first thing they're going to do is have you restart, 297 - > reset everything, every password in the organization.

They might 298 - > be accounts you don't know where they live, right? They're going 299 - > to have you segment off areas of the network to avoid kind of 300 - > lateral movement or sprawl. And if you don't know what 301 - > infrastructure exists, you're going to have a hard time doing 302 - > that. You need to install endpoint protection on anything 303 - > you might be missing, or you need to give an incident 304 - > response vendor access to see logging and material from all of 305 - > your assets.

If you don't know where those things are, you're 306 - > going to have a hard time, right? So, this element of 307 - > understanding what your entire environment looks like 308 - > proactively, even if it makes you nervous, it's always going 309 - > to be a better solution than waiting for the reactive event 310 - > that then you have to act. I think most companies are 311 - > generally weary of production impacts. They're weary of any 312 - > business outcome that's negative, and I think part of 313 - > this is just it's a messaging problem, a communication 314 - > problem.

If you're working with an executive team or a sales 315 - > team or folks that are responsible for kind of customer 316 - > experience, if they understand what that impact would look like 317 - > in the worst of scenarios. It's better to understand why you're 318 - > willing to kind of risk it a little bit more in the better 319 - > ones. And obviously, the more you do this, the more you do 320 - > this over time and track what you're doing, this problem 321 - > starts going away.

So, really, this issue at its core is a 322 - > legacy problem, one that comes out of programs maybe aren't 323 - > mature or haven't had that kind of formal focus, but it's a 324 - > solvable one, where you stop dealing with that same level of concern. 325 - > Keith Hawkey: And you've had exposure working in a multitude 326 - > of industries, Michael, and I can imagine that the, the, you 327 - > know, the receptive nature of making change, particularly 328 - > disruptive change, can vary somewhat industry to industry.

329 - > How does referring back to cybersecurity? You've worked in 330 - > both media and logistics environments. How does the 331 - > threat intent change based on industry, and how should 332 - > defensive posture adjust accordingly? 333 - > Michael Irwin: Yeah, I mean, threat intent changes 334 - > everything, right?

So, ultimately, your defenses should 335 - > mirror what the attacker actually wants to achieve, and 336 - > so you need to look at it. In my example, media, we generally 337 - > focused on persistence and integrity issues, so we would 338 - > deal with sophisticated actors that are trying to maintain 339 - > control in your environment, perhaps for the purpose of 340 - > modifying content that we're publishing, as an example, that 341 - > is, by its nature, very quiet. It's something that isn't going 342 - > to be the big noisy disruption that's obvious.

And so, when 343 - > you're looking at that, you need to protect that content, you 344 - > need to detect subtle manipulations, and things you 345 - > need to really focus on long-term access, things that 346 - > are harder to detect, it. It really requires more visibility 347 - > laterally across your infrastructure. When you look at 348 - > logistics, I think it tends to be more financially motivated or 349 - > disruption motivated, and so it's going to be louder. It's 350 - > going to be more obvious.

You might have an employee 351 - > compromise of an account that you see negative effects of that 352 - > same day. In media, you might have an employee compromise of 353 - > an account that you see the effects of six months later, 354 - > right, and so that nature of I can't remember what the exact 355 - > statistic is right now, but there's a very lengthy multiple 356 - > months period of time on average that it takes organizations to 357 - > discover breaches, and a lot of that relates to what they're 358 - > trying to actually achieve, and so when we think about 359 - > logistics, ransomware disruption, the ability to 360 - > recover, protect backups becomes a significantly more important 361 - > control.

I mean, all of them are relevant across the board, all 362 - > the controls and the areas that you might deal with, but if 363 - > you're dealing with priority, if you're dealing with budget 364 - > limitation, it's important to understand kind of where the 365 - > most important component is. 366 - > Keith Hawkey: And you've also suggested that the majority of 367 - > breaches stem from a narrow identity-driven attack path, 368 - > which is the talk of today. If you walked into a billion-dollar 369 - > organization tomorrow, what are three foundational controls that 370 - > you would audit first?

371 - > Michael Irwin: So that I would audit first is generally always 372 - > going back to what causes an incident, what leads to a 373 - > breach. So we're thinking about number one, if I'm going into an 374 - > environment, there's an understanding of how well do 375 - > they know their own environment. I've gone to organizations, or 376 - > I've worked with groups before, that would say, "Oh yeah, we 377 - > have our EDR solution deployed across all of our devices. 378 - > Great, that's a great statement to hear.

And you have a modern 379 - > next-gen EDR, perfect. Now the question becomes, where's your 380 - > asset inventory? Right, do you actually.. well, we don't have 381 - > that, or there's uncertainty in that space.

So, if you don't 382 - > know the assets you're trying to protect, why are you certain 383 - > that you've deployed them everywhere? That generally leads 384 - > to a, at a minimum, 10, 20% gap in coverage at a lot of these 385 - > locations. That ultimately leads to an incident. So, when you're 386 - > thinking about what an organization might have what I 387 - > would be auditing that awareness of their own environment, and 388 - > really proving that awareness beyond just checking the box is 389 - > critical.

From there, once you know what your environment looks 390 - > like, you again, you go back to where your problem is going to 391 - > be. You're dealing with employee training and employee access 392 - > issues. So, on training, that's obvious. You can do phishing 393 - > simulations, you can have employee awareness training, you 394 - > can measure how well they're behaving.

That's all one 395 - > component, but you can also look at, are they using single sign 396 - > on? What does their password policy look like? Do they have 397 - > MFA enabled for everyone? When you look at MFA these days, it's 398 - > not as straightforward as a simple code that you need to 399 - > present, but rather, are you protecting sessions?

Do you have 400 - > proactive awareness of session behavior that's an anomaly, 401 - > something that might signal a token theft in an environment. 402 - > There's a lot of organizations that are checking all the right 403 - > boxes, but they, un, they, they kind of miss the understanding 404 - > of the underlying ways that bad actors are using these accounts, 405 - > and they're bypassing them, and so it's really a moving target 406 - > that we have to hit. But outside of that, you look at endpoint 407 - > protection, right?

So, I, I tend to not be as infrastructure 408 - > focused at the beginning. I'm much more user focused, much 409 - > more user device focused. So, even thinking about things like 410 - > segmentation, I think there's a lot more value in segmenting a 411 - > user population from one another than there is segmenting, say, 412 - > resources in the data center. One might be more important.

A 413 - > lot of people talk about what the crown jewels are, the most 414 - > important assets, and that's all true, but access to those things 415 - > generally starts with that user device. It's going to be the 416 - > email they click on, the malware they download on a computer, and 417 - > where they can get from that device laterally is what that 418 - > bad actor is going to be following. So, really sticking 419 - > to the common causes of incidents is what's going to 420 - > move that the needle, particularly in ROI, and is 421 - > really achievable with low investment.

I mean, it's a 422 - > people and process problem more than it is a technology problem. 423 - > So small, mid-sized businesses that are trying to kind of keep 424 - > up with this changing world in this space, that's an area that 425 - > you can really add a lot of value for limited budgets. 426 - > Keith Hawkey: Yeah, and following up with some of the 427 - > security tooling that you're referencing between EDR asset 428 - > inventory, you also suggested that much of the industry 429 - > messaging is geared toward the enterprise space, not the mid 430 - > market.

Like, what's.. I mean, you've.. I'm sure you've 431 - > listened to dozens and dozens, and maybe even hundreds of 432 - > cybersecurity tooling pitches in your career. What, what 433 - > cybersecurity advice sounds impressive, but it's really 434 - > irrelevant for most mid-size organizations.

435 - > Michael Irwin: So, I think anything that is pitching you at 436 - > this kind of re-architecting of the way your business operates 437 - > as this prerequisite is always always kind of makes your alarm 438 - > bells goes up. Obviously, in this day and age, AI is a big 439 - > center of that, right? There's a lot of assumptions that are 440 - > being made with the value that certain tools in that space 441 - > might be able to provide. Another big one is that there 442 - > are a plethora of products that will say we.

Will give you full 443 - > visibility into your network. We'll show you all of the 444 - > traffic, we'll inspect all the packets, we'll show you all the 445 - > vulnerabilities, we'll give you all this information. And that 446 - > sounds great if you have a large team to actually act on those 447 - > recommendations, but if you don't, and you're expected to 448 - > provide them, and you have a PowerPoint presentation with a 449 - > bunch of green, yellow, and red check boxes that you're trying 450 - > to kind of show posture to another group, it's not really 451 - > impressive if you can't act on it, right?

And so it's funny, 452 - > one of the thoughts I have, and kind of hard to say where the 453 - > right answer is, but if you have 100 vulnerabilities and you 454 - > can't solve them all, like, do you want to even know, right? Is 455 - > it valuable to even know a vulnerability exists if you 456 - > can't remediate it. It's kind of like, did a tree really fall in 457 - > the woods if you weren't there to hear it, right? It's that 458 - > kind of idea.

459 - > Keith Hawkey: Yeah. 460 - > Michael Irwin: And so I think, because of that, what especially 461 - > small or mid-sized companies need is focus. They need focus 462 - > on what is actually being compromised. They need focus on 463 - > things that small changes that make the most large scale value.

464 - > So, if we're talking about upgrading or patching something, 465 - > something that affects multiple devices, not one. You're really 466 - > looking for something that you can actually act on. So, even in 467 - > my own space, an area I always look for is what organizations 468 - > are providing a tool, and they also have a managed service 469 - > component. CrowdStrike, as an example, as an EDR solution, has 470 - > a managed services component to their licensing that you can 471 - > provide that's actually doing some of the work for you.

Other 472 - > managed socks service providers might do the same thing, right. 473 - > So, there's different players in that space that say we won't 474 - > only tell you when there's a problem or there's a risk, but 475 - > we will help you solve them, or we will help you weed out the 476 - > noise. Those are things where you have a lot more value, and I 477 - > think oftentimes presentations or conferences that are geared 478 - > towards larger organizations, generally because they have 479 - > larger budgets to pay for the products that they're being 480 - > pitched.

Those sort of things often assume a level of 481 - > resource, a level of maturity, a level of documentation, a level 482 - > of things that have already been achieved in order to be 483 - > successful, but they kind of gloss over that at times, and so 484 - > it's, it's difficult to look back and say, oh yeah, it's 485 - > great, you're referencing a problem that we know exists, 486 - > this is a risk we're concerned about, your tool sounds great, 487 - > but I have 10 other things I need to do before I can even get 488 - > there, right?

And I think that's where that message gets lost on 489 - > smaller audiences. 490 - > Keith Hawkey: Yeah, I couldn't tell you how many, how many 491 - > demos that I'm on. It feels like weekly that the whatever name 492 - > your cybersecurity vendors is requesting the client completely 493 - > re-architect their their network design and I give kudos to some 494 - > of these AI advancements, like, like you said, that really, 495 - > where these cybersecurity vendors make their money and 496 - > differentiate themselves is the services that they attach to the 497 - > tooling, because I have a lot of, I have a lot of clients, 498 - > quite frankly, that they just can't handle the alerts that the 499 - > mid-market IT teams are lean, and more information really 500 - > isn't bliss.

Yes, it actually just causes them more headache 501 - > and heartburn because they can't get to everything. So, you know, 502 - > having there are some innovations in the AI agent 503 - > space that we are seeing with cybersecurity that hopefully can 504 - > help remedy some of the log ingest some of the tasks, some 505 - > of the especially the level one, level two tasks that don't 506 - > require network changes, don't require like fundamental changes 507 - > to the existing ecosystem that can help, hopefully, save the 508 - > day to some extent with that increased visibility.

509 - > Michael Irwin: Well, it's interesting, though, because I 510 - > mean, I think one of the challenges that we have in the 511 - > space is cybersecurity. Obviously, there's stress, 512 - > there's burnout. I think what people don't talk about enough 513 - > is there's a lot of imposter syndrome, right? There's a lot 514 - > of people that they're in a role, they're responsible for 515 - > something that they don't know they don't necessarily have 516 - > confidence that they know what the right answer is, and you 517 - > look at that in the example of AI.

Let's say AI as a concept is 518 - > now talked about everywhere, people are trying to bring it 519 - > in, your board, your leadership wants to bring this technology 520 - > in, you're tasked with protecting it, and this is 521 - > something that is new within the last year or two, right, 522 - > depending, I mean, not new conceptually, but new as far as 523 - > kind of public favor goes, and so you're now tasked with not 524 - > only understanding this thing that is new and everybody's 525 - > trying to learn opportunities for, but also understand and 526 - > articulate the risks involved with it, the potential gotchas, 527 - > the configuration mismanagement, the how to do that in a safe 528 - > way, and like you need to do all of that at the same time, and I 529 - > think when you look at that concept, and you say I have 530 - > alerts that are generated problems that are generated from 531 - > a tool, I have some AI integrated function of that, 532 - > that is now telling me what to do, it's maybe translating 533 - > something, and that's where I've seen a lot of success is taking 534 - > a technical alert and translating into.

Simpler 535 - > language, because many of our teams are lower or mid-career 536 - > people. They may be focused on their past experiences, they 537 - > don't have the technical knowledge of some of the stuff 538 - > they have to learn. And so that balance of AI is helping you 539 - > move faster, maybe it's telling you how to remediate it. To what 540 - > degree, or are we there yet, that we trust the answer it's 541 - > providing, right?

Especially with a team that can't 542 - > necessarily vet that, or is missing some of that, and I 543 - > think that leads to hesitancy, and so I think when you run into 544 - > that space, is the idea that there's certainly opportunity, 545 - > without a doubt, there's certainly value that these sort 546 - > of approaches have for organizations, but when you are 547 - > using it as a fix for what is an underskilled or under-resourced 548 - > team, I think there's often this fork in the road, or this kind 549 - > of mid intersection point, where they come back together, and 550 - > you're going to kind of run into that same problem.

And I think 551 - > that's the piece that, when we talk about people, process, and 552 - > technology, what I often find is, in this, at least in the 553 - > sense of AI, is that it's technology in search of a 554 - > problem. Traditionally, we've looked at technology as we have 555 - > a problem, we have a process, and we're looking for technology 556 - > to be something that will help with scale, it'll help with 557 - > efficiency, it'll add value that way, but you're starting from 558 - > the focus of a problem.

I think when you go back to that and you 559 - > think about in the cybersecurity space, a focus on people and 560 - > process, you focus on administrative housekeeping, you 561 - > focus on best practice and kind of cleaning up what you have, 562 - > and then you identify something that has too much volume for 563 - > your small team to handle, that becomes a great use case to 564 - > leverage that AI or that kind of optimization technology into the 565 - > mix to make you better, but at that point you're coming from a 566 - > point of awareness and strength, you're not trying to fill a lack 567 - > of awareness with it.

Right, I think that's a distinction that 568 - > often will drive whether or not you're successful in using it. 569 - > Keith Hawkey: I feel like we could talk about this for hours, 570 - > Michael. I really appreciate the antidotes and the conversation 571 - > that we had today, challenging some of the assumptions in the, 572 - > in the cybersecurity industry. Just, just leaving here, if you 573 - > were going to have a message to a let's say a green behind the 574 - > ears cyber security, formerly it getting into the cyber security 575 - > world leader, what what message, if it could fit on a billboard, 576 - > would would you share with with this individual?

577 - > Michael Irwin: I think the main story is that you will be tasked 578 - > with solving problems that you didn't create, and that's the 579 - > nature of the business. And so, what that means is there might 580 - > be more than you can handle, but you can continue focusing in a 581 - > methodical way, and you can always make progress, right, 582 - > whether it's small budgets or big budgets. If you have an 583 - > understanding of everything that needs to be done, and you 584 - > prioritize and really align with the business based on where they 585 - > are kind of financially or economically, you'll be able to 586 - > continue making progress, and what you really find is a lot 587 - > more success with that same business seeking funding if you 588 - > are understanding of the financial position they're in, 589 - > so if you're in a lean budget year, that's the time to look 590 - > for high ROI people in process work, right?

If you're in a 591 - > higher budget year, something that has a little bit more 592 - > capacity for new tooling, maybe that's a good opportunity to 593 - > look for those high value but higher dollar investments that 594 - > you have. So not being able to do the high dollar investment in 595 - > a lean year doesn't mean that you can't be successful, it 596 - > means that you need to be aligning to what the business 597 - > needs in that moment, and there's always work that can be 598 - > done, and I think when you look here, what really moves the 599 - > needle in protecting against incidents is just that, and the 600 - > only other thing, because I think it's important, is don't 601 - > overlook culture, right, because when you think about people, 602 - > when you're talking about AI, when you're thinking about this 603 - > work, the inevitable bad days that you'll have, focusing on 604 - > positive culture and work-life balance and really supporting 605 - > the people on your team moves the needle more than anything 606 - > else.

607 - > Keith Hawkey: Yeah, very well said, Michael. How can you, how 608 - > can our listeners get in touch with you? 609 - > Michael Irwin: So I'm available on LinkedIn, so you can search 610 - > and find me there. I generally accept invites from whoever, 611 - > whoever asks, so I'm not, not particularly limiting on that 612 - > front, but I'm pretty active in the Charlotte CISO community, so 613 - > I'm a lot of events in this space, some of the Gartner Apex 614 - > Assembly things, there's various things that are going on, so I 615 - > tend to be in those spaces, but yeah, always reach out, and I'm 616 - > happy to chat, I do a lot of mentoring for individuals, 617 - > particularly coming from kind of IT backgrounds, or looking to 618 - > get into cybersecurity, so I'm always open to chat if anybody 619 - > wanted to speak about anything.

620 - > Keith Hawkey: We'll make sure to include that information in the 621 - > show notes. Michael, thank you immensely for joining the IT 622 - > Matters podcast. Thank you. We will catch you guys next time.

623 - > Michael Irwin: All right, thanks. 624 - > Aaron Bock: Thank you for listening, and we appreciate you 625 - > tuning into the IT Matters Podcast. For support assessing 626 - > your technology needs, book a call with one of our technology 627 - > advisors at O P K A L L A.com.

That's opkalla.com. If you found 628 - > this episode helpful, please share the podcast with someone 629 - > who would get value from it, and leave us a review on Apple 630 - > Podcasts or on Spotify. Thank you for listening, and have a 631 - > great day.