Talos Takes · 2026-06-18 · 23 min
Key moments - from our scoring
Substance score
38 / 100
Five dimensions, 20 points each
AI-accelerated vulnerability discovery is collapsing the time between disclosure and exploitation, forcing defenders to abandon passive patching strategies. Pierre Cadieux, Talos threat intelligence lead, walks through the real mechanics of patch management - explaining why organizations can't simply 'just patch' medical devices like MRI machines, insulin pumps, or ATMs without vendor validation and extensive testing in environments that mirror production. The episode tackles asset inventory as foundational defense, change control processes using tools like Jira, and the shadow IT problem: when business units deploy technologies faster than IT governance allows, creating blind spots adversaries can exploit. Cadieux emphasizes that patching is fundamentally a people-and-process problem, not a technology one, and that defenders must know their own networks better than attackers do - which requires centralized asset tracking, proper change review boards, and realistic testing timelines. Essential for security practitioners managing complex, mixed-legacy environments who need practical frameworks for when, how, and whether to patch.
Medical devices running embedded operating systems require vendor validation before patching, followed by testing in a lab environment that mirrors production, because patches can unexpectedly break critical functionality or patient safety systems. Deploying patches without this process creates availability risk that may outweigh the vulnerability risk itself.
Shadow IT occurs when business units deploy applications and technologies outside the IT organization's governance and security controls to meet urgent needs faster than formal evaluation processes allow. This creates risk because these systems lack proper configuration guides, security monitoring, and may have originated as temporary test environments that became permanent production systems.
Organizations need a centralized asset inventory that tracks all hardware and software purchases, then validate it against actual systems in the environment to identify unknown or unauthorized assets. This map allows defenders to quickly scope the impact of vulnerabilities and spot unexpected connections when investigating incidents.
Change control processes - whether email-based, Jira-driven, or through a formal change review board - create a record of what was changed, when, by whom, and enable rollback if needed. This tracking helps defenders detect unexpected patches deployed outside normal cycles and provides the review window necessary for testing and approval.
Default settings on any application - including local LLMs deployed on laptops - are almost always vulnerable out of the box and may not align with organizational security baselines or data handling requirements, especially when systems send data back to corporate networks without proper controls.
Our reviewer’s read on each dimension, with quotes from the episode.
The episode covers real ground on patch management complexity, shadow IT, and asset inventory but is padded with broad statements and standard practitioner advice. The one genuinely concrete data point - the 6-hour default-Windows compromise metric - stands out, but most of the runtime is occupied by well-worn guidance any security-aware operator would already know.
Last time I remember that's being done, it was like six hours. You put a a default configured box on the internet, and within six hours, someone, not you, now has ownership of it and is doing bad things on it.
we have to expect that the passive defense is no longer really a successful option
The episode recycles thoroughly standard frameworks - people/process/technology, know your environment, change control, executive buy-in - without offering contrarian or first-principles perspectives. The AI angle (Claude Mythos, Fable) is name-dropped but never substantively examined.
people, process, and technology, technology problems have to often be solved with a combination of technological solutions reviewed by people through a process that's established
a lot of this goes back to some of the fundamentals that I've been working with and trying to promote for 30 years now
Pierre Cadieux is a legitimate multi-decade practitioner (Talos threat intelligence lead, GRC consultant, healthcare security experience) who clearly has hands-on depth, but he is not an especially high-profile or uniquely positioned operator and his insights reflect that of a capable mid-career security professional rather than a field-defining expert.
I've been working with and trying to promote for 30 years now
I've worked as a consultant a number of times for healthcare organizations throughout the world at various capacities
There are useful concrete device-level examples (MRI machines, ATMs, insulin pumps running embedded OS) and one specific metric (6-hour default install compromise), but there are no named companies, no breach case studies, no dollar figures, and no cited research - most scenarios are illustrative hypotheticals rather than documented real events.
there are very specific devices, let's say an MRI machine, which may be network aware and may sit on there and may be running a shadow version or small version of a Windows-based operating system
it was like six hours. You put a a default configured box on the internet, and within six hours, someone, not you, now has ownership of it
The host's questions are open-ended and functional but consistently surface-level, eliciting broad answers rather than pinning down specifics or challenging claims. Emotional reactions substitute for probing follow-ups, and there is no productive disagreement or pushback at any point.
Oh my God. I'm just thinking about the sheer scale of asset management that has to happen there. That's crazy.
What what are those critical steps in the patching life cycle?
Computed from the transcript - who did the talking, and the words that came up most.
If you're tired of being told to "just patch," we understand. The threat landscape is evolving at breakneck speed, with AI-driven tools enabling adversaries to uncover and exploit vulnerabilities before defenders even know they exist. In this episode of Talos Takes, Amy sits down with Threat Intelligence Lead Pierre Cadieux to discuss how to defend against these unknown threats. We move past the simplified advice of "just patch everything" to explore the logistical, technical, and business realities that make patching a complex, high-stakes operation rather than a simple button click. From the necessity of testing your patches to the importance of building strong partnerships between security teams and business leadership, this episode breaks down the things defenders often miss that build true resilience in organizations.
Transcribed and scored by The B2B Podcast Index.
1 - > Amy Ciminnisi: Welcome to the Talos Takes Podcast, where we 2 - > discuss Talos' latest research and security news. 3 - > This podcast is for everyone, from the C suite to the 4 - > frontline. 5 - > Hello and welcome. 6 - > We are living in a time where the ground beneath our feet is 7 - > constantly shifting.
8 - > With AI being used to uncover vulnerabilities at an 9 - > unprecedented speed, the gap between the known and the 10 - > unknown is closing. 11 - > And it's a race that defenders are finding harder to win. 12 - > What happens when the adversary knows your environment better 13 - > than you do? 14 - > How do you defend against a threat that hasn't even been 15 - > named yet?
16 - > I'm your host, Amy Ciminnisi, and today I'm joined by Pierre 17 - > Cadieux, threat intelligence lead, to dissect this topic and 18 - > give security practitioners practical tips. 19 - > Pierre, thanks for joining. 20 - > Pierre Cadieux: No problem. 21 - > Happy to be here.
22 - > Amy Ciminnisi: So let's dive right in. 23 - > As I said, we're operating in a world where threats are 24 - > increasing in both speed and complexity. 25 - > With Claude Mythos and recently announced Fable, we're seeing 26 - > AI being used to uncover previously unknown 27 - > vulnerabilities very quickly. 28 - > We've heard from a lot of our threat source newsletter authors 29 - > and blog writers that time from disclosure to exploitation has 30 - > uh shrunk immensely.
31 - > Can you kind of speak to this challenge a little bit more? 32 - > Pierre Cadieux: Sure. 33 - > Um we've always seen this type of a risk in security since as 34 - > long as I've been in the security industry, um where 35 - > adversaries are aware of vulnerabilities at the same time 36 - > over for the defenders and then are enabled to exploit them 37 - > rapidly. 38 - > And this requires a lot of infrastructure and commitment by 39 - > the adversaries to have a willingness to leverage new 40 - > found threats and and uh vulnerabilities immediately and 41 - > not just sit on them, not wait for them to be uh leveraged by 42 - > others, and to have the the dynamic capability to create 43 - > those exploits and to then leverage it for purpose.
44 - > So um a lot of our adversaries have focused on this kind of 45 - > tooling over the years, and sometimes it's been a slow 46 - > trickle, sometimes there have been spikes where adversaries 47 - > have access to um an exploit ahead of defenders and are able 48 - > to then leverage us. 49 - > But with those things you just mentioned with regard to the AI 50 - > development and identification of threats, we have to expect 51 - > that this is going to accelerate. 52 - > We have to expect that the passive defense is no longer 53 - > really a successful option.
54 - > If we're going to be defending infrastructure of any 55 - > complexity, of any business sensitivity that requires 56 - > uptime, that requires availability, et cetera. 57 - > It's our responsibility as defenders to be aware of this 58 - > and to create those contingency plans and understand the assets 59 - > under our purview, as well as the technologies we have at our 60 - > advantage, the logs that we have availability to, and how those 61 - > might be leveraged to identify things that we aren't aware of 62 - > yet.
63 - > This is similar to some other times where we've seen a 64 - > knowledge shift where the adversaries have a significant 65 - > advantage potentially. 66 - > I would say that uh defenders also have a significant 67 - > advantage if they are leveraging the same tools to identify 68 - > risks within their environment and then take the appropriate 69 - > actions to mitigate them. 70 - > But that last part is the hard part. 71 - > Knowing about a vulnerability is great.
72 - > Fixing it or mitigating it, that's where it really counts. 73 - > Amy Ciminnisi: We often hear the advice to just patch. 74 - > Um, but patching is a much more complex process than just 75 - > hitting a button, right? 76 - > So, what what are those critical steps in the patching 77 - > life cycle?
78 - > Pierre Cadieux: Early in my career, I also was of the well, 79 - > they should just patch kind of uh camp. 80 - > And on paper, it sounds if you have an environment that you 81 - > understand explicitly, you know the risks you're getting into 82 - > when you commit a change to your code, to your environment, to 83 - > the way things behave. 84 - > One of the challenges of this is if we have custom 85 - > applications, custom code, custom devices, or maybe little 86 - > uh like unique devices.
87 - > And I'm gonna specifically talk about like medical devices at 88 - > this point in time. 89 - > I've worked as a consultant a number of times for healthcare 90 - > organizations throughout the world at various capacities. 91 - > And there are very specific devices, let's say an MRI 92 - > machine, which may be network aware and may sit on there and 93 - > may be running a shadow version or small version of a 94 - > Windows-based operating system or Linux-based operating system, 95 - > but it may then incur vulnerability.
96 - > You can't just patch that without the vendor being 97 - > involved and without the vendor validating the uh the 98 - > installation and the change, and then you validating that it 99 - > still works in your environment. 100 - > So you need a test environment to test it against. 101 - > Otherwise, you may have adverse situations where you've created 102 - > a risk to the availability of this device. 103 - > And now I mentioned one device is used more for kind of 104 - > detection work when you're talking about the medical side 105 - > of things.
106 - > But if we also had something that's also like an insulin pump 107 - > or something else that directly impacts a um healthcare uh 108 - > situation for a patient, that's even more sensitive. 109 - > Conversely, you just look about like ATMs. 110 - > ATMs also often run embedded versions of operating systems. 111 - > You can't just patch it necessarily because it has to be 112 - > vetted by the vendor, you have to figure out how you're gonna 113 - > deploy it.
114 - > They're often air gapped, hopefully, uh, et cetera, et 115 - > cetera. 116 - > So there's a lot of considerations about the 117 - > logistics of actually applying the patches, and there has to be 118 - > a level, an appropriate level of testing based on the business 119 - > sensitivity of your environment. 120 - > I'm gonna repeat that again real quick. 121 - > We need to have an appropriate amount of testing for patches.
122 - > You can't just deploy a patch without testing it because it 123 - > may behave differently in your environment than what the vendor 124 - > who's deployed the patch may understand. 125 - > You may have a more specifically configured 126 - > environment or expectations of things working in a certain way 127 - > that may be changed or altered unexpectedly during a patching. 128 - > Over my many years of dealing with patching vulnerabilities 129 - > and that sort of stuff, I've seen that happen many times 130 - > where you deploy a patch and everything looks great except 131 - > for this one thing, which is maybe like the canary in the 132 - > coal mine, and it is now not going to work until something 133 - > else.
134 - > You need a revision of the patch or you need to roll the 135 - > patch back, and it will still remain vulnerable. 136 - > And you need to think of other mitigations. 137 - > How can I protect this device? 138 - > How critical is this device?
139 - > Do I need to leave it online? 140 - > Can I take it offline? 141 - > If it's critical, how do I protect it against these attacks 142 - > that are possibly going to be happening to it? 143 - > And you have to think about its role in your business, you have 144 - > to think about its sensitivity to the information that it has 145 - > and the ways of accessing it.
146 - > Is it internet-facing? 147 - > Is it internal only? 148 - > Is it unrestricted network? 149 - > Is it a restricted user list, et cetera?
150 - > Those sort of things will help to reduce the likelihood of 151 - > someone casually finding it. 152 - > But if it is an edge device or an interfacing device, there's a 153 - > consideration there you have to make. 154 - > Amy Ciminnisi: Oh my God. 155 - > I'm just thinking about the sheer scale of asset management 156 - > that has to happen there.
157 - > That's crazy. 158 - > How can people make it more sustainable for themselves to do 159 - > this? 160 - > You know, it's a monumental task. 161 - > Pierre Cadieux: It is.
162 - > Um, a lot of it goes back to some of the fundamentals that 163 - > I've been working with and trying to promote for 30 years 164 - > now. 165 - > One of the easiest fundamentals is uh the idea of change 166 - > control, having some sort of process for, and a lot of 167 - > executive uh environments have that have a very strict mandate 168 - > for compliance, have some sort of a change review board, 169 - > whether it's an automated or email-based process or it's a 170 - > virtual process through like Jira or something.
171 - > There's a process where you submit these changes, someone 172 - > reviews them and authorizes them and says approved. 173 - > That way you have some tracking about what was changed when. 174 - > So you can roll back. 175 - > Also, you know what was changed, by who, when.
176 - > And if you see a change out of a cycle, you know that you need 177 - > to track this down and find out why this was deployed, patched, 178 - > whatever. 179 - > In environments where there's a high sensitivity of data 180 - > integrity and of security of the environment, big like financial 181 - > institutions, et cetera, this is usually the way that they 182 - > handle that sort of thing. 183 - > It's slow a little bit, but it provides you the window for the 184 - > discussion, the review, the testing, and the approval that 185 - > need to happen for this sort of thing to happen.
186 - > One of the things that I'm gonna also mention, which I've 187 - > started to talk about a little bit here, is that this is not 188 - > necessarily a technology problem. 189 - > This is a or a technology is a technology problem, but it's not 190 - > going to be solved with technology. 191 - > It's gonna be solved with people and process. 192 - > So if you think about those three aspects of the stuff we 193 - > do, people, process, and technology, technology problems 194 - > have to often be solved with a combination of technological 195 - > solutions reviewed by people through a process that's 196 - > established.
197 - > So establishing those governance processes is crucial 198 - > to having the oversight to answer your question about the 199 - > asset manager. 200 - > How do you do this? 201 - > You have to have some sort of a gate where purchases of 202 - > software, hardware, et cetera, are tracked and logged 203 - > internally in a central location. 204 - > There needs to be some sort of a uh validation capability, 205 - > which exists in many different software uh tools, to look for 206 - > assets on your environment that you are aware of and that you 207 - > aren't aware of, and to match those up with users, with 208 - > business needs, et cetera, and to identify those systems that 209 - > don't fall into those categories.
210 - > This is also very useful in the event of an investigation or an 211 - > incident or hunting. 212 - > You can find very easily which systems are related to this big 213 - > important financial app. 214 - > Oh, hey, it's these 14 systems here, these 10 over here, these 215 - > seven over here. 216 - > And this is how they're connected.
217 - > If you have that, you know the scope of what you're dealing 218 - > with. 219 - > And you see something outside of that, you can easily say, 220 - > this doesn't make sense or this is unexpected, and then focus on 221 - > that. 222 - > Having knowledge of that for many of our defenders would be 223 - > an improvement on where they often sit today. 224 - > And thinking about the vulnerability leads to 225 - > compromise, you need that map so that when you get to the 226 - > compromise phase, you know how you're defending yourself.
227 - > Amy Ciminnisi: Yeah, I feel like that kind of answers my next 228 - > question. 229 - > So I'll I'll just kind of say it. 230 - > Many organizations operate under the assumption that they 231 - > know their own network better than the adversary. 232 - > So, like when we think about worst case scenarios, what you 233 - > just said, I guess, is how people should be adjusting their 234 - > strategy when they realize that you know someone else knows 235 - > their environment better.
236 - > Pierre Cadieux: Yeah. 237 - > And in a time, over the past like 10, 15 years, I've seen a 238 - > big shift towards uh, and it's always been a race condition 239 - > between new technology coming out and our our ability 240 - > collectively as an enterprise to deploy it. 241 - > Hey, this new thing came out, I want to deploy it today. 242 - > And this has created a challenge within the internal IT 243 - > organizations, speed of evaluation, validation, security 244 - > controls, and deployment of things that are new that the 245 - > business is asking for.
246 - > The time to deployment for a lot of these applications and 247 - > tools has shrunk, where there's an expectation that we can 248 - > deploy this within days or less of this new thing coming out. 249 - > The reality of the evaluation process and the testing is 250 - > higher than that. 251 - > So often this creates a need for parallel IT capabilities, 252 - > what we often refer to as shadow IT, where a business 253 - > organization has people that do IT-related tasks and deploy 254 - > technologies outside of the governance that's deployed by 255 - > most of the IT organization or the enterprise.
256 - > This is not uncommon in many places. 257 - > And this is one of those things that you know, if the need 258 - > arises, business will find a way, sort of thing. 259 - > Uh, in this case, the need arises, someone who says, okay, 260 - > we'll just buy the thing and deploy it. 261 - > This is a way of doing it.
262 - > This creates a lot of risk because you're not necessarily 263 - > conforming to the organization's security problem uh program or 264 - > following the configuration guides and the configuration 265 - > requirements, and not maybe deploying the monitoring tools, 266 - > not deploying it in a secure environment. 267 - > And this creates a huge risk. 268 - > I don't know how many times I've seen environments that were 269 - > created as a test environment or as a temporary thing that 270 - > became production and lasted forever and were never meant to 271 - > or scaled to be production and should never have gone that way.
272 - > That happens all the time. 273 - > And the changes in technology are very rapid. 274 - > We have to expect that what is an asset today will become a 275 - > legacy thing tomorrow, and there'll be a new one or new 276 - > five things deployed. 277 - > And who owns it, who's assigned to it, what business purpose it 278 - > provides, those change dynamically.
279 - > A laptop that I was assigned um a year ago may now be running a 280 - > localized LLM on it and be running as my own little AI 281 - > thing that my rest of my team is using and send its data back to 282 - > our larger corporate environment. 283 - > That's a risk if it's not managed correctly. 284 - > And so there needs to be some governance, especially about the 285 - > creation and deployment of new tools. 286 - > And I'm not focusing just on LLMs, but that's one of the new 287 - > tools out.
288 - > Amy Ciminnisi: Yeah, and don't put just the default settings on 289 - > it, please. 290 - > God, please. 291 - > Yeah, you got to make sure that you adjust it. 292 - > Pierre Cadieux: Yeah.
293 - > Default settings are almost always vulnerable out of the 294 - > box. 295 - > There used to be a metric, a time metric that we used to 296 - > track for how long would it take to compromise a default install 297 - > of Windows on the internet? 298 - > How long would it be put on the internet and how many days, 299 - > weeks, months would it take for it to be compromised? 300 - > Last time I remember that's being done, it was like six 301 - > hours.
302 - > You put a a default configured box on the internet, and within 303 - > six hours, someone, not you, now has ownership of it and is 304 - > doing bad things on it. 305 - > Yeah. 306 - > I bet that number is much slower. 307 - > Yeah.
308 - > Amy Ciminnisi: Oh my God. 309 - > So, like when an unknown threat or a zero day emerges, the 310 - > pressure to react is ginormous. 311 - > I mean, within your team, and then also you have people 312 - > pressing you for information. 313 - > What does a prepared organization look like?
314 - > Maybe, you know, take me through the first period of 315 - > time, maybe hour, several hours or day after a disclosure. 316 - > Pierre Cadieux: Yeah. 317 - > And a lot of this starts obviously before the disclosure. 318 - > So there's a lot of assumptions I'm going to mention here that 319 - > I would hope that an environment that is mature and prepared for 320 - > this would have in place.
321 - > So you mentioned before knowing your environment. 322 - > It's important to know your environment. 323 - > At least have an inventory of your top and number of critical 324 - > environments. 325 - > This is our main business maker, money maker.
326 - > This is our system that our customers use. 327 - > This is the back-end service thing that does the shipment of 328 - > our product. 329 - > This is the thing that an engineer uses. 330 - > Those might be the top three different environments.
331 - > Each of those contains assets, servers, cloud hosted systems, 332 - > software as a service systems, et cetera, knowing what those 333 - > are and then who's members of this team, who the owners are of 334 - > the various assets. 335 - > Having that mapped out ahead of time helps you link things 336 - > together when you're seeing activity. 337 - > And so being having that understanding, even if it's just 338 - > for the most critical system or the top N number of critical 339 - > systems in your environment, gives you a leg up in your 340 - > detection process.
341 - > And also when you have to ask about can I patch this device, 342 - > you know who to ask about it. 343 - > You could say, hey, I see you're the owner of this device. 344 - > I have this critical patch that's coming out. 345 - > Can you help work with me to test it andor deploy it?
346 - > So that's one of the first things. 347 - > Understand what the vulnerability actually is. 348 - > And so reviewing the vulnerability information, the 349 - > text, not just the number as far as the provided CVE difficulty 350 - > or you know, the uh the uh likelihood, uh, often that's 351 - > listed out appropriately based on sort of a generic uh 352 - > assessment. 353 - > If you have environmental configuration things that may 354 - > reduce that, you can consider that as an uh an altered thing.
355 - > So this is you know meant for if this was on an 356 - > internet-facing system, this would be a 10, for instance. 357 - > But on systems with restricted access and an isolated network, 358 - > et cetera, this falls lower. 359 - > And so maybe you can then deprioritize that or have 360 - > mitigations in place that can help to answer the question to 361 - > your executive leadership. 362 - > Did you know about this?
363 - > Yes, we did. 364 - > What do we do about it? 365 - > Well, we've got controls in place and we'll patch it within 366 - > the normal patch cycle at the end of the month. 367 - > Oh, okay, that sounds good.
368 - > And we're gonna have additional monitoring, for instance. 369 - > We're gonna spin up additional monitoring looking for this 370 - > specific traffic at our edge and at our network uh egress points 371 - > and maybe across uh various different uh monitoring 372 - > positions within our network. 373 - > That helps you have that heightened level of visibility 374 - > during the time where you may be vulnerable. 375 - > And so in case something does happen, you can be ready to take 376 - > action when you see this.
377 - > I think part of it's also gonna be if you believe that you have 378 - > been compromised by that, doing your own hunting. 379 - > And again, if you have that map of those systems and the 380 - > environments and how they interconnect, you can then have 381 - > a more targeted hunting capability and say, I'm gonna 382 - > target the financial system, I'm gonna look for any indications 383 - > of any compromise here that may have started with this 384 - > vulnerability or related to this vulnerability.
385 - > That's important again to know. 386 - > But if you also have a mapping across those critical systems, 387 - > you can say this vulnerability does not come into play or does 388 - > not impact these systems because they don't use that technology. 389 - > That's also a good piece of news. 390 - > Or each of them use this technology, maybe in different 391 - > ways.
392 - > This one is deployed in a in a test environment over here, but 393 - > it's not in production. 394 - > They can prioritize accordingly based on the risk there. 395 - > That's one of those things that again requires partnership with 396 - > the business owners to understand the governance 397 - > requirements, the compliance requirements, regulatory issues, 398 - > et cetera, so that you're prioritizing correctly. 399 - > This is the hard work of IT security and is is not as fancy 400 - > and fun as finding a malicious actor and doing this cool stuff.
401 - > But this is the stuff that keeps an environment safe when 402 - > there's unknowns out there. 403 - > Amy Ciminnisi: And often often a very thankless portion of it as 404 - > well. 405 - > Yeah. 406 - > Pierre Cadieux: Yeah, I I've done uh GRC consulting for a 407 - > number of years, so you're 100% right.
408 - > Amy Ciminnisi: Finally, I I really want to touch on the 409 - > internal pressure that people are facing, maybe from their 410 - > leadership. 411 - > It's one thing to, you know, look at the release CVE and 412 - > fully understand these threats, but you know, it's a whole other 413 - > game to explain them to executives who just want to know 414 - > if they're safe or not. 415 - > So, like, how how should we as defenders be communicating this 416 - > reality of unknown threats and the need for this resilience to 417 - > the leadership teams?
418 - > Pierre Cadieux: A part of it is establishing leadership as a 419 - > stakeholder in any security program and security plan, 420 - > making sure they understand the process you go through to defend 421 - > the environment and what you would do in a situation where 422 - > you have an unknown vulnerability or a new 423 - > vulnerability being disclosed. 424 - > Walk them through that process so they understand where they 425 - > will get updates, what they should expect, and the diligence 426 - > for doing as far as evaluating the threat, looking across our 427 - > business critical systems, validating if they are impacted 428 - > or not, considering mitigations, considering testing and 429 - > deployment, and validating that they are okay with the timeline 430 - > on a nominal vulnerability.
431 - > And then explaining that we also have a capability of doing 432 - > an emergency deployment. 433 - > But that creates a different risk. 434 - > If you deploy without testing, you could be bringing the whole 435 - > environment down. 436 - > But if they accept that risk, then they put their little 437 - > executive stamp on it, then perhaps we have to take action 438 - > on that with that notification that they are accepting the risk 439 - > and this is done at the behest of the CEO or whatever.
440 - > But having a backup plan and being a way to roll that patch 441 - > back is crucial. 442 - > If there's a patch that you can't roll back, making that 443 - > clear to them as well, like we aren't testing or we're doing 444 - > extra testing on this because we can't roll it back. 445 - > We deploy it, it changes things fundamentally, and we will have 446 - > to revert back to a disaster recovery backup or to rebuild 447 - > our whole environment, not just roll the patch back.
448 - > That also changes the metric. 449 - > Some patches are indeed like that, where they change uh 450 - > something significantly to the point where you have to actually 451 - > rebuild an environment. 452 - > So being clear with your executives, I realize that 453 - > they're not going to understand all the technical details behind 454 - > the vulnerabilities, but they do understand timelines, they do 455 - > understand commitments, and they also, if you have again in 456 - > the security program, you have a periodic change review process 457 - > that they are part of and they have visibility into and they 458 - > can participate in.
459 - > I think that uh helps along the way. 460 - > Again, this is administrative requirements and work that need 461 - > to be established, but bringing them in as partners is crucial 462 - > for them accepting the process you're doing. 463 - > Amy Ciminnisi: Exactly. 464 - > And I mean, this is going slightly off topic, but I'm 465 - > thinking about an episode that I did several months back now, 466 - > where if leadership is frustrated with the pace and you 467 - > know, they they just want things to get done and they want 468 - > to know if they're safe, like point to you know, all of the 469 - > trails that you've previously left.
470 - > And I mean, thinking about budget and headcount and things 471 - > like that, like this is an area where you can advocate for 472 - > yourself and for your team. 473 - > Pierre Cadieux: I percent I mentioned before people 474 - > processing technology, and this is where you need to, as a 475 - > leader of a defense organization, you don't just 476 - > spend all your whole budget on technology, you don't spend it 477 - > on people or the process. 478 - > You need to have an equal share across all those peep those 479 - > features.
480 - > You need people to execute the process against the technology. 481 - > So this is a chance for you to say, you know what, to do this 482 - > in a way that's gonna be meaningful. 483 - > I need some some people who are experienced defenders who have 484 - > done this vulnerability management type of stuff in the 485 - > past. 486 - > I need them to be uh here on the team to help to evaluate 487 - > this one's gonna be dedicated to the financial services system, 488 - > this one's gonna be dedicated to our shipping system, et cetera, 489 - > or maybe they're on a rotation or whatever.
490 - > And you know, you'd make those arguments. 491 - > I think that in my mind at least has a lot more of a place 492 - > now in this conversation because we know that there's this wave 493 - > of incoming unknown or soon-to-be-known threats that 494 - > are about to hit or will be hitting over time. 495 - > I think ramping up a vulnerability management process 496 - > is appropriate for any environment uh that's as a 497 - > defender. 498 - > And that also includes refreshing and re-evaluating 499 - > your disaster recovery plan, refreshing and reevaluating your 500 - > incident response plan, making sure your leadership knows the 501 - > roles that they have in these things, and that they know the 502 - > process for getting a status check from you, the security 503 - > team, on these vulnerabilities and giving them a more periodic 504 - > readout of here's the vulnerabilities we evaluated 505 - > over the past week, here's our plans for deployment and 506 - > testing.
507 - > Please validate that you're on board with this. 508 - > And again, involving them in the process. 509 - > Executives don't necessarily like to spend a lot of time 510 - > thinking about security risks, but they'd rather be informed 511 - > than be in the dark. 512 - > Amy Ciminnisi: Well, Pierre, thanks so much for joining me.
513 - > Pierre Cadieux: Certainly. 514 - > There's a lot to be said on this topic. 515 - > And so we may have to revisit it down the road as well and 516 - > come back to see how things are going. 517 - > Um, but uh I encourage all defenders to take a deep breath, 518 - > think about their relationship with their business leaders, 519 - > business owners, and then to refresh this.
520 - > Amy Ciminnisi: Yeah, absolutely. 521 - > And I'm sure everyone here at Talos wants to thank you for all 522 - > the work that you do in keeping people in your organization 523 - > safe. 524 - > Um and thank you so much for listening. 525 - > We'll see you again in two weeks for a new episode.
526 - > And until then, stay safe out there.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.
Vibe Coding vs. the CISOSimplifying Cyber · on Shadow IT85 / 100
AI Is the Biggest Distraction in Sales: Why the Hard Work Is Still HumanDisambiguation · on Shadow IT73 / 100
This CIO is Making Her Entire Enterprise AI-Ready | 29M Students, Cambium Learning GroupCXO Spotlight · on Shadow IT71 / 100
Unwrapping Account Based Marketing | B2B Marketing Shepherd Rajesh Kumar | EP 07B2B Marketing Shepherd · on Shadow IT66 / 100
Safe AI implementation for Florida Special DistrictsAI for Good · on Shadow IT61 / 100
S3E33 - Andy Sen, CTO of AppDirectKeeping IT Real · on Shadow IT60 / 100From evasion to detection: A guide to analyzing COM-based threats90 / 100When synthetic logs don’t lie: Generating coherent attack stories for better detection85 / 100The trust paradox: How attackers weaponize legitimate SaaS platforms94 / 100It's not you, it's your printer: State-sponsored and phishing threats in 202586 / 1002025's ransomware trends and zombie vulnerabilities87 / 100