WEBVTT
00:00:00.160 --> 00:00:06.320
Welcome to the Talos Takes Podcast, where we discuss Talos' latest research and security news.
00:00:06.320 --> 00:00:10.400
This podcast is for everyone, from the C suite to the frontline.
00:00:10.400 --> 00:00:13.919
Hello and welcome.
00:00:13.919 --> 00:00:19.679
We are living in a time where the ground beneath our feet is constantly shifting.
00:00:19.679 --> 00:00:28.879
With AI being used to uncover vulnerabilities at an unprecedented speed, the gap between the known and the unknown is closing.
00:00:28.879 --> 00:00:32.159
And it's a race that defenders are finding harder to win.
00:00:32.159 --> 00:00:35.920
What happens when the adversary knows your environment better than you do?
00:00:35.920 --> 00:00:39.600
How do you defend against a threat that hasn't even been named yet?
00:00:39.600 --> 00:00:49.920
I'm your host, Amy Ciminnisi, and today I'm joined by Pierre Cadieux, threat intelligence lead, to dissect this topic and give security practitioners practical tips.
00:00:49.920 --> 00:00:51.439
Pierre, thanks for joining.
00:00:51.840 --> 00:00:52.240
No problem.
00:00:52.240 --> 00:00:53.039
Happy to be here.
00:00:53.520 --> 00:00:55.520
So let's dive right in.
00:00:55.520 --> 00:01:01.200
As I said, we're operating in a world where threats are increasing in both speed and complexity.
00:01:01.200 --> 00:01:11.519
With Claude Mythos and recently announced Fable, we're seeing AI being used to uncover previously unknown vulnerabilities very quickly.
00:01:11.519 --> 00:01:22.879
We've heard from a lot of our threat source newsletter authors and blog writers that time from disclosure to exploitation has uh shrunk immensely.
00:01:22.879 --> 00:01:25.680
Can you kind of speak to this challenge a little bit more?
00:01:26.560 --> 00:01:26.959
Sure.
00:01:26.959 --> 00:01:50.400
Um we've always seen this type of a risk in security since as long as I've been in the security industry, um where adversaries are aware of vulnerabilities at the same time over for the defenders and then are enabled to exploit them rapidly.
00:01:50.400 --> 00:02:12.560
And this requires a lot of infrastructure and commitment by the adversaries to have a willingness to leverage new found threats and and uh vulnerabilities immediately and not just sit on them, not wait for them to be uh leveraged by others, and to have the the dynamic capability to create those exploits and to then leverage it for purpose.
00:02:12.560 --> 00:02:25.759
So um a lot of our adversaries have focused on this kind of tooling over the years, and sometimes it's been a slow trickle, sometimes there have been spikes where adversaries have access to um an exploit ahead of defenders and are able to then leverage us.
00:02:25.759 --> 00:02:34.960
But with those things you just mentioned with regard to the AI development and identification of threats, we have to expect that this is going to accelerate.
00:02:34.960 --> 00:02:41.120
We have to expect that the passive defense is no longer really a successful option.
00:02:41.120 --> 00:02:49.759
If we're going to be defending infrastructure of any complexity, of any business sensitivity that requires uptime, that requires availability, et cetera.
00:02:49.759 --> 00:03:07.439
It's our responsibility as defenders to be aware of this and to create those contingency plans and understand the assets under our purview, as well as the technologies we have at our advantage, the logs that we have availability to, and how those might be leveraged to identify things that we aren't aware of yet.
00:03:07.439 --> 00:03:14.560
This is similar to some other times where we've seen a knowledge shift where the adversaries have a significant advantage potentially.
00:03:14.560 --> 00:03:24.800
I would say that uh defenders also have a significant advantage if they are leveraging the same tools to identify risks within their environment and then take the appropriate actions to mitigate them.
00:03:24.800 --> 00:03:27.199
But that last part is the hard part.
00:03:27.199 --> 00:03:29.280
Knowing about a vulnerability is great.
00:03:29.280 --> 00:03:32.479
Fixing it or mitigating it, that's where it really counts.
00:03:32.879 --> 00:03:36.240
We often hear the advice to just patch.
00:03:36.240 --> 00:03:40.639
Um, but patching is a much more complex process than just hitting a button, right?
00:03:40.639 --> 00:03:44.719
So, what what are those critical steps in the patching life cycle?
00:03:45.280 --> 00:03:50.560
Early in my career, I also was of the well, they should just patch kind of uh camp.
00:03:50.560 --> 00:04:01.599
And on paper, it sounds if you have an environment that you understand explicitly, you know the risks you're getting into when you commit a change to your code, to your environment, to the way things behave.
00:04:01.599 --> 00:04:13.199
One of the challenges of this is if we have custom applications, custom code, custom devices, or maybe little uh like unique devices.
00:04:13.199 --> 00:04:16.639
And I'm gonna specifically talk about like medical devices at this point in time.
00:04:16.639 --> 00:04:22.079
I've worked as a consultant a number of times for healthcare organizations throughout the world at various capacities.
00:04:22.079 --> 00:04:36.240
And 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 or Linux-based operating system, but it may then incur vulnerability.
00:04:36.240 --> 00:04:45.600
You can't just patch that without the vendor being involved and without the vendor validating the uh the installation and the change, and then you validating that it still works in your environment.
00:04:45.600 --> 00:04:47.600
So you need a test environment to test it against.
00:04:47.600 --> 00:04:53.199
Otherwise, you may have adverse situations where you've created a risk to the availability of this device.
00:04:53.199 --> 00:04:59.920
And now I mentioned one device is used more for kind of detection work when you're talking about the medical side of things.
00:04:59.920 --> 00:05:10.639
But if we also had something that's also like an insulin pump or something else that directly impacts a um healthcare uh situation for a patient, that's even more sensitive.
00:05:10.639 --> 00:05:13.199
Conversely, you just look about like ATMs.
00:05:13.199 --> 00:05:16.319
ATMs also often run embedded versions of operating systems.
00:05:16.319 --> 00:05:21.759
You can't just patch it necessarily because it has to be vetted by the vendor, you have to figure out how you're gonna deploy it.
00:05:21.759 --> 00:05:24.959
They're often air gapped, hopefully, uh, et cetera, et cetera.
00:05:24.959 --> 00:05:35.360
So there's a lot of considerations about the logistics of actually applying the patches, and there has to be a level, an appropriate level of testing based on the business sensitivity of your environment.
00:05:35.360 --> 00:05:37.519
I'm gonna repeat that again real quick.
00:05:37.519 --> 00:05:40.480
We need to have an appropriate amount of testing for patches.
00:05:40.480 --> 00:05:48.720
You can't just deploy a patch without testing it because it may behave differently in your environment than what the vendor who's deployed the patch may understand.
00:05:48.720 --> 00:05:58.639
You may have a more specifically configured environment or expectations of things working in a certain way that may be changed or altered unexpectedly during a patching.
00:05:58.639 --> 00:06:12.399
Over my many years of dealing with patching vulnerabilities and that sort of stuff, I've seen that happen many times where you deploy a patch and everything looks great except for this one thing, which is maybe like the canary in the coal mine, and it is now not going to work until something else.
00:06:12.399 --> 00:06:17.360
You need a revision of the patch or you need to roll the patch back, and it will still remain vulnerable.
00:06:17.360 --> 00:06:19.279
And you need to think of other mitigations.
00:06:19.279 --> 00:06:21.120
How can I protect this device?
00:06:21.120 --> 00:06:22.560
How critical is this device?
00:06:22.560 --> 00:06:23.680
Do I need to leave it online?
00:06:23.680 --> 00:06:25.279
Can I take it offline?
00:06:25.279 --> 00:06:30.959
If it's critical, how do I protect it against these attacks that are possibly going to be happening to it?
00:06:30.959 --> 00:06:39.040
And you have to think about its role in your business, you have to think about its sensitivity to the information that it has and the ways of accessing it.
00:06:39.040 --> 00:06:40.079
Is it internet-facing?
00:06:40.079 --> 00:06:40.959
Is it internal only?
00:06:40.959 --> 00:06:42.319
Is it unrestricted network?
00:06:42.319 --> 00:06:44.319
Is it a restricted user list, et cetera?
00:06:44.319 --> 00:06:48.720
Those sort of things will help to reduce the likelihood of someone casually finding it.
00:06:48.720 --> 00:06:53.600
But if it is an edge device or an interfacing device, there's a consideration there you have to make.
00:06:53.839 --> 00:06:54.639
Oh my God.
00:06:54.639 --> 00:07:00.879
I'm just thinking about the sheer scale of asset management that has to happen there.
00:07:00.879 --> 00:07:02.000
That's crazy.
00:07:02.000 --> 00:07:06.720
How can people make it more sustainable for themselves to do this?
00:07:06.720 --> 00:07:09.439
You know, it's a monumental task.
00:07:09.680 --> 00:07:10.160
It is.
00:07:10.160 --> 00:07:18.399
Um, a lot of it goes back to some of the fundamentals that I've been working with and trying to promote for 30 years now.
00:07:18.399 --> 00:07:36.000
One of the easiest fundamentals is uh the idea of change control, having some sort of process for, and a lot of executive uh environments have that have a very strict mandate for compliance, have some sort of a change review board, whether it's an automated or email-based process or it's a virtual process through like Jira or something.
00:07:36.000 --> 00:07:40.560
There's a process where you submit these changes, someone reviews them and authorizes them and says approved.
00:07:40.560 --> 00:07:42.879
That way you have some tracking about what was changed when.
00:07:42.879 --> 00:07:44.000
So you can roll back.
00:07:44.000 --> 00:07:46.480
Also, you know what was changed, by who, when.
00:07:46.480 --> 00:07:53.519
And if you see a change out of a cycle, you know that you need to track this down and find out why this was deployed, patched, whatever.
00:07:53.519 --> 00:08:06.160
In environments where there's a high sensitivity of data integrity and of security of the environment, big like financial institutions, et cetera, this is usually the way that they handle that sort of thing.
00:08:06.160 --> 00:08:15.439
It's slow a little bit, but it provides you the window for the discussion, the review, the testing, and the approval that need to happen for this sort of thing to happen.
00:08:15.439 --> 00:08:23.279
One of the things that I'm gonna also mention, which I've started to talk about a little bit here, is that this is not necessarily a technology problem.
00:08:23.279 --> 00:08:28.079
This is a or a technology is a technology problem, but it's not going to be solved with technology.
00:08:28.079 --> 00:08:30.959
It's gonna be solved with people and process.
00:08:30.959 --> 00:08:43.440
So if you think about those three aspects of the stuff we do, 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.
00:08:43.440 --> 00:08:49.759
So establishing those governance processes is crucial to having the oversight to answer your question about the asset manager.
00:08:49.759 --> 00:08:50.799
How do you do this?
00:08:50.799 --> 00:09:00.639
You have to have some sort of a gate where purchases of software, hardware, et cetera, are tracked and logged internally in a central location.
00:09:00.639 --> 00:09:18.559
There needs to be some sort of a uh validation capability, which exists in many different software uh tools, to look for assets on your environment that you are aware of and that you aren't aware of, and to match those up with users, with business needs, et cetera, and to identify those systems that don't fall into those categories.
00:09:18.559 --> 00:09:23.279
This is also very useful in the event of an investigation or an incident or hunting.
00:09:23.279 --> 00:09:27.919
You can find very easily which systems are related to this big important financial app.
00:09:27.919 --> 00:09:32.399
Oh, hey, it's these 14 systems here, these 10 over here, these seven over here.
00:09:32.399 --> 00:09:33.759
And this is how they're connected.
00:09:33.759 --> 00:09:36.480
If you have that, you know the scope of what you're dealing with.
00:09:36.480 --> 00:09:43.120
And you see something outside of that, you can easily say, this doesn't make sense or this is unexpected, and then focus on that.
00:09:43.120 --> 00:09:48.799
Having knowledge of that for many of our defenders would be an improvement on where they often sit today.
00:09:48.799 --> 00:09:56.240
And thinking about the vulnerability leads to compromise, you need that map so that when you get to the compromise phase, you know how you're defending yourself.
00:09:56.480 --> 00:09:59.759
Yeah, I feel like that kind of answers my next question.
00:09:59.759 --> 00:10:02.080
So I'll I'll just kind of say it.
00:10:02.080 --> 00:10:08.240
Many organizations operate under the assumption that they know their own network better than the adversary.
00:10:08.240 --> 00:10:20.799
So, like when we think about worst case scenarios, what you just said, I guess, is how people should be adjusting their strategy when they realize that you know someone else knows their environment better.
00:10:20.960 --> 00:10:21.279
Yeah.
00:10:21.279 --> 00:10:35.519
And in a time, over the past like 10, 15 years, I've seen a big shift towards uh, and it's always been a race condition between new technology coming out and our our ability collectively as an enterprise to deploy it.
00:10:35.519 --> 00:10:38.159
Hey, this new thing came out, I want to deploy it today.
00:10:38.159 --> 00:10:49.279
And this has created a challenge within the internal IT organizations, speed of evaluation, validation, security controls, and deployment of things that are new that the business is asking for.
00:10:49.279 --> 00:10:59.279
The time to deployment for a lot of these applications and tools has shrunk, where there's an expectation that we can deploy this within days or less of this new thing coming out.
00:10:59.279 --> 00:11:03.120
The reality of the evaluation process and the testing is higher than that.
00:11:03.120 --> 00:11:20.080
So often this creates a need for parallel IT capabilities, what we often refer to as shadow IT, where a business organization has people that do IT-related tasks and deploy technologies outside of the governance that's deployed by most of the IT organization or the enterprise.
00:11:20.080 --> 00:11:22.480
This is not uncommon in many places.
00:11:22.480 --> 00:11:29.279
And this is one of those things that you know, if the need arises, business will find a way, sort of thing.
00:11:29.279 --> 00:11:34.159
Uh, in this case, the need arises, someone who says, okay, we'll just buy the thing and deploy it.
00:11:34.159 --> 00:11:36.480
This is a way of doing it.
00:11:36.480 --> 00:11:50.320
This creates a lot of risk because you're not necessarily conforming to the organization's security problem uh program or following the configuration guides and the configuration requirements, and not maybe deploying the monitoring tools, not deploying it in a secure environment.
00:11:50.320 --> 00:11:52.000
And this creates a huge risk.
00:11:52.000 --> 00:12:04.399
I don't know how many times I've seen environments that were created as a test environment or as a temporary thing that became production and lasted forever and were never meant to or scaled to be production and should never have gone that way.
00:12:04.399 --> 00:12:05.600
That happens all the time.
00:12:05.600 --> 00:12:07.759
And the changes in technology are very rapid.
00:12:07.759 --> 00:12:14.960
We have to expect that what is an asset today will become a legacy thing tomorrow, and there'll be a new one or new five things deployed.
00:12:14.960 --> 00:12:19.759
And who owns it, who's assigned to it, what business purpose it provides, those change dynamically.
00:12:19.759 --> 00:12:32.559
A laptop that I was assigned um a year ago may now be running a localized LLM on it and be running as my own little AI thing that my rest of my team is using and send its data back to our larger corporate environment.
00:12:32.559 --> 00:12:34.559
That's a risk if it's not managed correctly.
00:12:34.559 --> 00:12:38.799
And so there needs to be some governance, especially about the creation and deployment of new tools.
00:12:38.799 --> 00:12:42.639
And I'm not focusing just on LLMs, but that's one of the new tools out.
00:12:42.879 --> 00:12:46.720
Yeah, and don't put just the default settings on it, please.
00:12:46.720 --> 00:12:47.600
God, please.
00:12:47.600 --> 00:12:49.519
Yeah, you got to make sure that you adjust it.
00:12:49.840 --> 00:12:50.000
Yeah.
00:12:50.000 --> 00:12:53.360
Default settings are almost always vulnerable out of the box.
00:12:53.360 --> 00:13:01.919
There used to be a metric, a time metric that we used to track for how long would it take to compromise a default install of Windows on the internet?
00:13:01.919 --> 00:13:07.120
How long would it be put on the internet and how many days, weeks, months would it take for it to be compromised?
00:13:07.120 --> 00:13:10.480
Last time I remember that's being done, it was like six hours.
00:13:10.480 --> 00:13:19.120
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.
00:13:19.120 --> 00:13:19.840
Yeah.
00:13:19.840 --> 00:13:21.519
I bet that number is much slower.
00:13:21.519 --> 00:13:21.919
Yeah.
00:13:22.080 --> 00:13:22.799
Oh my God.
00:13:22.799 --> 00:13:30.720
So, like when an unknown threat or a zero day emerges, the pressure to react is ginormous.
00:13:30.720 --> 00:13:36.240
I mean, within your team, and then also you have people pressing you for information.
00:13:36.240 --> 00:13:39.679
What does a prepared organization look like?
00:13:39.679 --> 00:13:47.120
Maybe, you know, take me through the first period of time, maybe hour, several hours or day after a disclosure.
00:13:47.360 --> 00:13:47.600
Yeah.
00:13:47.600 --> 00:13:50.159
And a lot of this starts obviously before the disclosure.
00:13:50.159 --> 00:13:58.000
So there's a lot of assumptions I'm going to mention here that I would hope that an environment that is mature and prepared for this would have in place.
00:13:58.000 --> 00:14:00.559
So you mentioned before knowing your environment.
00:14:00.559 --> 00:14:02.320
It's important to know your environment.
00:14:02.320 --> 00:14:08.240
At least have an inventory of your top and number of critical environments.
00:14:08.240 --> 00:14:10.960
This is our main business maker, money maker.
00:14:10.960 --> 00:14:13.200
This is our system that our customers use.
00:14:13.200 --> 00:14:16.960
This is the back-end service thing that does the shipment of our product.
00:14:16.960 --> 00:14:18.879
This is the thing that an engineer uses.
00:14:18.879 --> 00:14:21.200
Those might be the top three different environments.
00:14:21.200 --> 00:14:33.039
Each of those contains assets, servers, cloud hosted systems, software as a service systems, et cetera, knowing what those are and then who's members of this team, who the owners are of the various assets.
00:14:33.039 --> 00:14:38.480
Having that mapped out ahead of time helps you link things together when you're seeing activity.
00:14:38.480 --> 00:14:48.480
And so being having that understanding, even if it's just for the most critical system or the top N number of critical systems in your environment, gives you a leg up in your detection process.
00:14:48.480 --> 00:14:52.080
And also when you have to ask about can I patch this device, you know who to ask about it.
00:14:52.080 --> 00:14:54.559
You could say, hey, I see you're the owner of this device.
00:14:54.559 --> 00:14:56.480
I have this critical patch that's coming out.
00:14:56.480 --> 00:14:59.279
Can you help work with me to test it andor deploy it?
00:14:59.279 --> 00:15:00.879
So that's one of the first things.
00:15:00.879 --> 00:15:03.200
Understand what the vulnerability actually is.
00:15:03.200 --> 00:15:19.039
And so reviewing the vulnerability information, the text, not just the number as far as the provided CVE difficulty or you know, the uh the uh likelihood, uh, often that's listed out appropriately based on sort of a generic uh assessment.
00:15:19.039 --> 00:15:25.600
If you have environmental configuration things that may reduce that, you can consider that as an uh an altered thing.
00:15:25.600 --> 00:15:30.799
So this is you know meant for if this was on an internet-facing system, this would be a 10, for instance.
00:15:30.799 --> 00:15:36.159
But on systems with restricted access and an isolated network, et cetera, this falls lower.
00:15:36.159 --> 00:15:43.440
And so maybe you can then deprioritize that or have mitigations in place that can help to answer the question to your executive leadership.
00:15:43.440 --> 00:15:44.399
Did you know about this?
00:15:44.399 --> 00:15:45.360
Yes, we did.
00:15:45.360 --> 00:15:46.559
What do we do about it?
00:15:46.559 --> 00:15:51.440
Well, we've got controls in place and we'll patch it within the normal patch cycle at the end of the month.
00:15:51.440 --> 00:15:53.039
Oh, okay, that sounds good.
00:15:53.039 --> 00:15:55.360
And we're gonna have additional monitoring, for instance.
00:15:55.360 --> 00:16:06.159
We're gonna spin up additional monitoring looking for this specific traffic at our edge and at our network uh egress points and maybe across uh various different uh monitoring positions within our network.
00:16:06.159 --> 00:16:11.519
That helps you have that heightened level of visibility during the time where you may be vulnerable.
00:16:11.519 --> 00:16:16.000
And so in case something does happen, you can be ready to take action when you see this.
00:16:16.000 --> 00:16:21.440
I think part of it's also gonna be if you believe that you have been compromised by that, doing your own hunting.
00:16:21.440 --> 00:16:36.399
And again, if you have that map of those systems and the environments and how they interconnect, you can then have a more targeted hunting capability and say, I'm gonna target the financial system, I'm gonna look for any indications of any compromise here that may have started with this vulnerability or related to this vulnerability.
00:16:36.399 --> 00:16:37.919
That's important again to know.
00:16:37.919 --> 00:16:48.799
But if you also have a mapping across those critical systems, you can say this vulnerability does not come into play or does not impact these systems because they don't use that technology.
00:16:48.799 --> 00:16:51.039
That's also a good piece of news.
00:16:51.039 --> 00:16:54.639
Or each of them use this technology, maybe in different ways.
00:16:54.639 --> 00:16:59.120
This one is deployed in a in a test environment over here, but it's not in production.
00:16:59.120 --> 00:17:02.720
They can prioritize accordingly based on the risk there.
00:17:02.720 --> 00:17:16.319
That's one of those things that again requires partnership with the business owners to understand the governance requirements, the compliance requirements, regulatory issues, et cetera, so that you're prioritizing correctly.
00:17:16.319 --> 00:17:24.480
This is the hard work of IT security and is is not as fancy and fun as finding a malicious actor and doing this cool stuff.
00:17:24.480 --> 00:17:29.200
But this is the stuff that keeps an environment safe when there's unknowns out there.
00:17:29.440 --> 00:17:34.240
And often often a very thankless portion of it as well.
00:17:34.240 --> 00:17:35.279
Yeah.
00:17:35.519 --> 00:17:40.640
Yeah, I I've done uh GRC consulting for a number of years, so you're 100% right.
00:17:41.599 --> 00:17:50.240
Finally, I I really want to touch on the internal pressure that people are facing, maybe from their leadership.
00:17:50.240 --> 00:18:02.559
It's one thing to, you know, look at the release CVE and fully understand these threats, but you know, it's a whole other game to explain them to executives who just want to know if they're safe or not.
00:18:02.559 --> 00:18:12.720
So, like, how how should we as defenders be communicating this reality of unknown threats and the need for this resilience to the leadership teams?
00:18:13.039 --> 00:18:28.559
A part of it is establishing leadership as a stakeholder in any security program and security plan, making sure they understand the process you go through to defend the environment and what you would do in a situation where you have an unknown vulnerability or a new vulnerability being disclosed.
00:18:28.559 --> 00:18:50.319
Walk them through that process so they understand where they will get updates, what they should expect, and the diligence for doing as far as evaluating the threat, looking across our business critical systems, validating if they are impacted or not, considering mitigations, considering testing and deployment, and validating that they are okay with the timeline on a nominal vulnerability.
00:18:50.319 --> 00:18:54.799
And then explaining that we also have a capability of doing an emergency deployment.
00:18:54.799 --> 00:18:56.720
But that creates a different risk.
00:18:56.720 --> 00:19:00.960
If you deploy without testing, you could be bringing the whole environment down.
00:19:00.960 --> 00:19:13.920
But if they accept that risk, then they put their little executive stamp on it, then perhaps we have to take action on that with that notification that they are accepting the risk and this is done at the behest of the CEO or whatever.
00:19:13.920 --> 00:19:18.319
But having a backup plan and being a way to roll that patch back is crucial.
00:19:18.319 --> 00:19:25.599
If there's a patch that you can't roll back, making that clear to them as well, like we aren't testing or we're doing extra testing on this because we can't roll it back.
00:19:25.599 --> 00:19:35.759
We deploy it, it changes things fundamentally, and we will have to revert back to a disaster recovery backup or to rebuild our whole environment, not just roll the patch back.
00:19:35.759 --> 00:19:37.519
That also changes the metric.
00:19:37.519 --> 00:19:43.920
Some patches are indeed like that, where they change uh something significantly to the point where you have to actually rebuild an environment.
00:19:43.920 --> 00:20:04.400
So being clear with your executives, I realize that they're not going to understand all the technical details behind the vulnerabilities, but they do understand timelines, they do understand commitments, and they also, if you have again in the security program, you have a periodic change review process that they are part of and they have visibility into and they can participate in.
00:20:04.400 --> 00:20:06.960
I think that uh helps along the way.
00:20:06.960 --> 00:20:16.880
Again, this is administrative requirements and work that need to be established, but bringing them in as partners is crucial for them accepting the process you're doing.
00:20:17.440 --> 00:20:18.319
Exactly.
00:20:18.319 --> 00:20:43.359
And I mean, this is going slightly off topic, but I'm thinking about an episode that I did several months back now, where if leadership is frustrated with the pace and you know, they they just want things to get done and they want to know if they're safe, like point to you know, all of the trails that you've previously left.
00:20:43.359 --> 00:20:52.400
And I mean, thinking about budget and headcount and things like that, like this is an area where you can advocate for yourself and for your team.
00:20:52.799 --> 00:21:04.799
I percent I mentioned before people processing technology, and this is where you need to, as a leader of a defense organization, you don't just spend all your whole budget on technology, you don't spend it on people or the process.
00:21:04.799 --> 00:21:09.039
You need to have an equal share across all those peep those features.
00:21:09.039 --> 00:21:12.240
You need people to execute the process against the technology.
00:21:12.240 --> 00:21:17.119
So this is a chance for you to say, you know what, to do this in a way that's gonna be meaningful.
00:21:17.119 --> 00:21:22.640
I need some some people who are experienced defenders who have done this vulnerability management type of stuff in the past.
00:21:22.640 --> 00:21:32.400
I need them to be uh here on the team to help to evaluate this one's gonna be dedicated to the financial services system, this one's gonna be dedicated to our shipping system, et cetera, or maybe they're on a rotation or whatever.
00:21:32.400 --> 00:21:34.559
And you know, you'd make those arguments.
00:21:34.559 --> 00:21:47.119
I think that in my mind at least has a lot more of a place now in this conversation because we know that there's this wave of incoming unknown or soon-to-be-known threats that are about to hit or will be hitting over time.
00:21:47.119 --> 00:21:53.440
I think ramping up a vulnerability management process is appropriate for any environment uh that's as a defender.
00:21:53.440 --> 00:22:20.160
And that also includes refreshing and re-evaluating your disaster recovery plan, refreshing and reevaluating your incident response plan, making sure your leadership knows the roles that they have in these things, and that they know the process for getting a status check from you, the security team, on these vulnerabilities and giving them a more periodic readout of here's the vulnerabilities we evaluated over the past week, here's our plans for deployment and testing.
00:22:20.160 --> 00:22:22.480
Please validate that you're on board with this.
00:22:22.480 --> 00:22:24.319
And again, involving them in the process.
00:22:24.319 --> 00:22:30.640
Executives don't necessarily like to spend a lot of time thinking about security risks, but they'd rather be informed than be in the dark.
00:22:30.880 --> 00:22:32.799
Well, Pierre, thanks so much for joining me.
00:22:33.039 --> 00:22:33.440
Certainly.
00:22:33.440 --> 00:22:35.200
There's a lot to be said on this topic.
00:22:35.200 --> 00:22:39.839
And so we may have to revisit it down the road as well and come back to see how things are going.
00:22:39.839 --> 00:22:48.319
Um, but uh I encourage all defenders to take a deep breath, think about their relationship with their business leaders, business owners, and then to refresh this.
00:22:48.559 --> 00:22:49.920
Yeah, absolutely.
00:22:49.920 --> 00:22:59.359
And I'm sure everyone here at Talos wants to thank you for all the work that you do in keeping people in your organization safe.
00:22:59.359 --> 00:23:01.680
Um and thank you so much for listening.
00:23:01.680 --> 00:23:05.519
We'll see you again in two weeks for a new episode.
00:23:05.519 --> 00:23:08.160
And until then, stay safe out there.
00:00:00.160 --> 00:00:06.320
Welcome to the Talos Takes Podcast, where we discuss Talos' latest research and security news.
00:00:06.320 --> 00:00:10.400
This podcast is for everyone, from the C suite to the frontline.
00:00:10.400 --> 00:00:13.919
Hello and welcome.
00:00:13.919 --> 00:00:19.679
We are living in a time where the ground beneath our feet is constantly shifting.
00:00:19.679 --> 00:00:28.879
With AI being used to uncover vulnerabilities at an unprecedented speed, the gap between the known and the unknown is closing.
00:00:28.879 --> 00:00:32.159
And it's a race that defenders are finding harder to win.
00:00:32.159 --> 00:00:35.920
What happens when the adversary knows your environment better than you do?
00:00:35.920 --> 00:00:39.600
How do you defend against a threat that hasn't even been named yet?
00:00:39.600 --> 00:00:49.920
I'm your host, Amy Ciminnisi, and today I'm joined by Pierre Cadieux, threat intelligence lead, to dissect this topic and give security practitioners practical tips.
00:00:49.920 --> 00:00:51.439
Pierre, thanks for joining.
00:00:51.840 --> 00:00:52.240
No problem.
00:00:52.240 --> 00:00:53.039
Happy to be here.
00:00:53.520 --> 00:00:55.520
So let's dive right in.
00:00:55.520 --> 00:01:01.200
As I said, we're operating in a world where threats are increasing in both speed and complexity.
00:01:01.200 --> 00:01:11.519
With Claude Mythos and recently announced Fable, we're seeing AI being used to uncover previously unknown vulnerabilities very quickly.
00:01:11.519 --> 00:01:22.879
We've heard from a lot of our threat source newsletter authors and blog writers that time from disclosure to exploitation has uh shrunk immensely.
00:01:22.879 --> 00:01:25.680
Can you kind of speak to this challenge a little bit more?
00:01:26.560 --> 00:01:26.959
Sure.
00:01:26.959 --> 00:01:50.400
Um we've always seen this type of a risk in security since as long as I've been in the security industry, um where adversaries are aware of vulnerabilities at the same time over for the defenders and then are enabled to exploit them rapidly.
00:01:50.400 --> 00:02:12.560
And this requires a lot of infrastructure and commitment by the adversaries to have a willingness to leverage new found threats and and uh vulnerabilities immediately and not just sit on them, not wait for them to be uh leveraged by others, and to have the the dynamic capability to create those exploits and to then leverage it for purpose.
00:02:12.560 --> 00:02:25.759
So um a lot of our adversaries have focused on this kind of tooling over the years, and sometimes it's been a slow trickle, sometimes there have been spikes where adversaries have access to um an exploit ahead of defenders and are able to then leverage us.
00:02:25.759 --> 00:02:34.960
But with those things you just mentioned with regard to the AI development and identification of threats, we have to expect that this is going to accelerate.
00:02:34.960 --> 00:02:41.120
We have to expect that the passive defense is no longer really a successful option.
00:02:41.120 --> 00:02:49.759
If we're going to be defending infrastructure of any complexity, of any business sensitivity that requires uptime, that requires availability, et cetera.
00:02:49.759 --> 00:03:07.439
It's our responsibility as defenders to be aware of this and to create those contingency plans and understand the assets under our purview, as well as the technologies we have at our advantage, the logs that we have availability to, and how those might be leveraged to identify things that we aren't aware of yet.
00:03:07.439 --> 00:03:14.560
This is similar to some other times where we've seen a knowledge shift where the adversaries have a significant advantage potentially.
00:03:14.560 --> 00:03:24.800
I would say that uh defenders also have a significant advantage if they are leveraging the same tools to identify risks within their environment and then take the appropriate actions to mitigate them.
00:03:24.800 --> 00:03:27.199
But that last part is the hard part.
00:03:27.199 --> 00:03:29.280
Knowing about a vulnerability is great.
00:03:29.280 --> 00:03:32.479
Fixing it or mitigating it, that's where it really counts.
00:03:32.879 --> 00:03:36.240
We often hear the advice to just patch.
00:03:36.240 --> 00:03:40.639
Um, but patching is a much more complex process than just hitting a button, right?
00:03:40.639 --> 00:03:44.719
So, what what are those critical steps in the patching life cycle?
00:03:45.280 --> 00:03:50.560
Early in my career, I also was of the well, they should just patch kind of uh camp.
00:03:50.560 --> 00:04:01.599
And on paper, it sounds if you have an environment that you understand explicitly, you know the risks you're getting into when you commit a change to your code, to your environment, to the way things behave.
00:04:01.599 --> 00:04:13.199
One of the challenges of this is if we have custom applications, custom code, custom devices, or maybe little uh like unique devices.
00:04:13.199 --> 00:04:16.639
And I'm gonna specifically talk about like medical devices at this point in time.
00:04:16.639 --> 00:04:22.079
I've worked as a consultant a number of times for healthcare organizations throughout the world at various capacities.
00:04:22.079 --> 00:04:36.240
And 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 or Linux-based operating system, but it may then incur vulnerability.
00:04:36.240 --> 00:04:45.600
You can't just patch that without the vendor being involved and without the vendor validating the uh the installation and the change, and then you validating that it still works in your environment.
00:04:45.600 --> 00:04:47.600
So you need a test environment to test it against.
00:04:47.600 --> 00:04:53.199
Otherwise, you may have adverse situations where you've created a risk to the availability of this device.
00:04:53.199 --> 00:04:59.920
And now I mentioned one device is used more for kind of detection work when you're talking about the medical side of things.
00:04:59.920 --> 00:05:10.639
But if we also had something that's also like an insulin pump or something else that directly impacts a um healthcare uh situation for a patient, that's even more sensitive.
00:05:10.639 --> 00:05:13.199
Conversely, you just look about like ATMs.
00:05:13.199 --> 00:05:16.319
ATMs also often run embedded versions of operating systems.
00:05:16.319 --> 00:05:21.759
You can't just patch it necessarily because it has to be vetted by the vendor, you have to figure out how you're gonna deploy it.
00:05:21.759 --> 00:05:24.959
They're often air gapped, hopefully, uh, et cetera, et cetera.
00:05:24.959 --> 00:05:35.360
So there's a lot of considerations about the logistics of actually applying the patches, and there has to be a level, an appropriate level of testing based on the business sensitivity of your environment.
00:05:35.360 --> 00:05:37.519
I'm gonna repeat that again real quick.
00:05:37.519 --> 00:05:40.480
We need to have an appropriate amount of testing for patches.
00:05:40.480 --> 00:05:48.720
You can't just deploy a patch without testing it because it may behave differently in your environment than what the vendor who's deployed the patch may understand.
00:05:48.720 --> 00:05:58.639
You may have a more specifically configured environment or expectations of things working in a certain way that may be changed or altered unexpectedly during a patching.
00:05:58.639 --> 00:06:12.399
Over my many years of dealing with patching vulnerabilities and that sort of stuff, I've seen that happen many times where you deploy a patch and everything looks great except for this one thing, which is maybe like the canary in the coal mine, and it is now not going to work until something else.
00:06:12.399 --> 00:06:17.360
You need a revision of the patch or you need to roll the patch back, and it will still remain vulnerable.
00:06:17.360 --> 00:06:19.279
And you need to think of other mitigations.
00:06:19.279 --> 00:06:21.120
How can I protect this device?
00:06:21.120 --> 00:06:22.560
How critical is this device?
00:06:22.560 --> 00:06:23.680
Do I need to leave it online?
00:06:23.680 --> 00:06:25.279
Can I take it offline?
00:06:25.279 --> 00:06:30.959
If it's critical, how do I protect it against these attacks that are possibly going to be happening to it?
00:06:30.959 --> 00:06:39.040
And you have to think about its role in your business, you have to think about its sensitivity to the information that it has and the ways of accessing it.
00:06:39.040 --> 00:06:40.079
Is it internet-facing?
00:06:40.079 --> 00:06:40.959
Is it internal only?
00:06:40.959 --> 00:06:42.319
Is it unrestricted network?
00:06:42.319 --> 00:06:44.319
Is it a restricted user list, et cetera?
00:06:44.319 --> 00:06:48.720
Those sort of things will help to reduce the likelihood of someone casually finding it.
00:06:48.720 --> 00:06:53.600
But if it is an edge device or an interfacing device, there's a consideration there you have to make.
00:06:53.839 --> 00:06:54.639
Oh my God.
00:06:54.639 --> 00:07:00.879
I'm just thinking about the sheer scale of asset management that has to happen there.
00:07:00.879 --> 00:07:02.000
That's crazy.
00:07:02.000 --> 00:07:06.720
How can people make it more sustainable for themselves to do this?
00:07:06.720 --> 00:07:09.439
You know, it's a monumental task.
00:07:09.680 --> 00:07:10.160
It is.
00:07:10.160 --> 00:07:18.399
Um, a lot of it goes back to some of the fundamentals that I've been working with and trying to promote for 30 years now.
00:07:18.399 --> 00:07:36.000
One of the easiest fundamentals is uh the idea of change control, having some sort of process for, and a lot of executive uh environments have that have a very strict mandate for compliance, have some sort of a change review board, whether it's an automated or email-based process or it's a virtual process through like Jira or something.
00:07:36.000 --> 00:07:40.560
There's a process where you submit these changes, someone reviews them and authorizes them and says approved.
00:07:40.560 --> 00:07:42.879
That way you have some tracking about what was changed when.
00:07:42.879 --> 00:07:44.000
So you can roll back.
00:07:44.000 --> 00:07:46.480
Also, you know what was changed, by who, when.
00:07:46.480 --> 00:07:53.519
And if you see a change out of a cycle, you know that you need to track this down and find out why this was deployed, patched, whatever.
00:07:53.519 --> 00:08:06.160
In environments where there's a high sensitivity of data integrity and of security of the environment, big like financial institutions, et cetera, this is usually the way that they handle that sort of thing.
00:08:06.160 --> 00:08:15.439
It's slow a little bit, but it provides you the window for the discussion, the review, the testing, and the approval that need to happen for this sort of thing to happen.
00:08:15.439 --> 00:08:23.279
One of the things that I'm gonna also mention, which I've started to talk about a little bit here, is that this is not necessarily a technology problem.
00:08:23.279 --> 00:08:28.079
This is a or a technology is a technology problem, but it's not going to be solved with technology.
00:08:28.079 --> 00:08:30.959
It's gonna be solved with people and process.
00:08:30.959 --> 00:08:43.440
So if you think about those three aspects of the stuff we do, 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.
00:08:43.440 --> 00:08:49.759
So establishing those governance processes is crucial to having the oversight to answer your question about the asset manager.
00:08:49.759 --> 00:08:50.799
How do you do this?
00:08:50.799 --> 00:09:00.639
You have to have some sort of a gate where purchases of software, hardware, et cetera, are tracked and logged internally in a central location.
00:09:00.639 --> 00:09:18.559
There needs to be some sort of a uh validation capability, which exists in many different software uh tools, to look for assets on your environment that you are aware of and that you aren't aware of, and to match those up with users, with business needs, et cetera, and to identify those systems that don't fall into those categories.
00:09:18.559 --> 00:09:23.279
This is also very useful in the event of an investigation or an incident or hunting.
00:09:23.279 --> 00:09:27.919
You can find very easily which systems are related to this big important financial app.
00:09:27.919 --> 00:09:32.399
Oh, hey, it's these 14 systems here, these 10 over here, these seven over here.
00:09:32.399 --> 00:09:33.759
And this is how they're connected.
00:09:33.759 --> 00:09:36.480
If you have that, you know the scope of what you're dealing with.
00:09:36.480 --> 00:09:43.120
And you see something outside of that, you can easily say, this doesn't make sense or this is unexpected, and then focus on that.
00:09:43.120 --> 00:09:48.799
Having knowledge of that for many of our defenders would be an improvement on where they often sit today.
00:09:48.799 --> 00:09:56.240
And thinking about the vulnerability leads to compromise, you need that map so that when you get to the compromise phase, you know how you're defending yourself.
00:09:56.480 --> 00:09:59.759
Yeah, I feel like that kind of answers my next question.
00:09:59.759 --> 00:10:02.080
So I'll I'll just kind of say it.
00:10:02.080 --> 00:10:08.240
Many organizations operate under the assumption that they know their own network better than the adversary.
00:10:08.240 --> 00:10:20.799
So, like when we think about worst case scenarios, what you just said, I guess, is how people should be adjusting their strategy when they realize that you know someone else knows their environment better.
00:10:20.960 --> 00:10:21.279
Yeah.
00:10:21.279 --> 00:10:35.519
And in a time, over the past like 10, 15 years, I've seen a big shift towards uh, and it's always been a race condition between new technology coming out and our our ability collectively as an enterprise to deploy it.
00:10:35.519 --> 00:10:38.159
Hey, this new thing came out, I want to deploy it today.
00:10:38.159 --> 00:10:49.279
And this has created a challenge within the internal IT organizations, speed of evaluation, validation, security controls, and deployment of things that are new that the business is asking for.
00:10:49.279 --> 00:10:59.279
The time to deployment for a lot of these applications and tools has shrunk, where there's an expectation that we can deploy this within days or less of this new thing coming out.
00:10:59.279 --> 00:11:03.120
The reality of the evaluation process and the testing is higher than that.
00:11:03.120 --> 00:11:20.080
So often this creates a need for parallel IT capabilities, what we often refer to as shadow IT, where a business organization has people that do IT-related tasks and deploy technologies outside of the governance that's deployed by most of the IT organization or the enterprise.
00:11:20.080 --> 00:11:22.480
This is not uncommon in many places.
00:11:22.480 --> 00:11:29.279
And this is one of those things that you know, if the need arises, business will find a way, sort of thing.
00:11:29.279 --> 00:11:34.159
Uh, in this case, the need arises, someone who says, okay, we'll just buy the thing and deploy it.
00:11:34.159 --> 00:11:36.480
This is a way of doing it.
00:11:36.480 --> 00:11:50.320
This creates a lot of risk because you're not necessarily conforming to the organization's security problem uh program or following the configuration guides and the configuration requirements, and not maybe deploying the monitoring tools, not deploying it in a secure environment.
00:11:50.320 --> 00:11:52.000
And this creates a huge risk.
00:11:52.000 --> 00:12:04.399
I don't know how many times I've seen environments that were created as a test environment or as a temporary thing that became production and lasted forever and were never meant to or scaled to be production and should never have gone that way.
00:12:04.399 --> 00:12:05.600
That happens all the time.
00:12:05.600 --> 00:12:07.759
And the changes in technology are very rapid.
00:12:07.759 --> 00:12:14.960
We have to expect that what is an asset today will become a legacy thing tomorrow, and there'll be a new one or new five things deployed.
00:12:14.960 --> 00:12:19.759
And who owns it, who's assigned to it, what business purpose it provides, those change dynamically.
00:12:19.759 --> 00:12:32.559
A laptop that I was assigned um a year ago may now be running a localized LLM on it and be running as my own little AI thing that my rest of my team is using and send its data back to our larger corporate environment.
00:12:32.559 --> 00:12:34.559
That's a risk if it's not managed correctly.
00:12:34.559 --> 00:12:38.799
And so there needs to be some governance, especially about the creation and deployment of new tools.
00:12:38.799 --> 00:12:42.639
And I'm not focusing just on LLMs, but that's one of the new tools out.
00:12:42.879 --> 00:12:46.720
Yeah, and don't put just the default settings on it, please.
00:12:46.720 --> 00:12:47.600
God, please.
00:12:47.600 --> 00:12:49.519
Yeah, you got to make sure that you adjust it.
00:12:49.840 --> 00:12:50.000
Yeah.
00:12:50.000 --> 00:12:53.360
Default settings are almost always vulnerable out of the box.
00:12:53.360 --> 00:13:01.919
There used to be a metric, a time metric that we used to track for how long would it take to compromise a default install of Windows on the internet?
00:13:01.919 --> 00:13:07.120
How long would it be put on the internet and how many days, weeks, months would it take for it to be compromised?
00:13:07.120 --> 00:13:10.480
Last time I remember that's being done, it was like six hours.
00:13:10.480 --> 00:13:19.120
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.
00:13:19.120 --> 00:13:19.840
Yeah.
00:13:19.840 --> 00:13:21.519
I bet that number is much slower.
00:13:21.519 --> 00:13:21.919
Yeah.
00:13:22.080 --> 00:13:22.799
Oh my God.
00:13:22.799 --> 00:13:30.720
So, like when an unknown threat or a zero day emerges, the pressure to react is ginormous.
00:13:30.720 --> 00:13:36.240
I mean, within your team, and then also you have people pressing you for information.
00:13:36.240 --> 00:13:39.679
What does a prepared organization look like?
00:13:39.679 --> 00:13:47.120
Maybe, you know, take me through the first period of time, maybe hour, several hours or day after a disclosure.
00:13:47.360 --> 00:13:47.600
Yeah.
00:13:47.600 --> 00:13:50.159
And a lot of this starts obviously before the disclosure.
00:13:50.159 --> 00:13:58.000
So there's a lot of assumptions I'm going to mention here that I would hope that an environment that is mature and prepared for this would have in place.
00:13:58.000 --> 00:14:00.559
So you mentioned before knowing your environment.
00:14:00.559 --> 00:14:02.320
It's important to know your environment.
00:14:02.320 --> 00:14:08.240
At least have an inventory of your top and number of critical environments.
00:14:08.240 --> 00:14:10.960
This is our main business maker, money maker.
00:14:10.960 --> 00:14:13.200
This is our system that our customers use.
00:14:13.200 --> 00:14:16.960
This is the back-end service thing that does the shipment of our product.
00:14:16.960 --> 00:14:18.879
This is the thing that an engineer uses.
00:14:18.879 --> 00:14:21.200
Those might be the top three different environments.
00:14:21.200 --> 00:14:33.039
Each of those contains assets, servers, cloud hosted systems, software as a service systems, et cetera, knowing what those are and then who's members of this team, who the owners are of the various assets.
00:14:33.039 --> 00:14:38.480
Having that mapped out ahead of time helps you link things together when you're seeing activity.
00:14:38.480 --> 00:14:48.480
And so being having that understanding, even if it's just for the most critical system or the top N number of critical systems in your environment, gives you a leg up in your detection process.
00:14:48.480 --> 00:14:52.080
And also when you have to ask about can I patch this device, you know who to ask about it.
00:14:52.080 --> 00:14:54.559
You could say, hey, I see you're the owner of this device.
00:14:54.559 --> 00:14:56.480
I have this critical patch that's coming out.
00:14:56.480 --> 00:14:59.279
Can you help work with me to test it andor deploy it?
00:14:59.279 --> 00:15:00.879
So that's one of the first things.
00:15:00.879 --> 00:15:03.200
Understand what the vulnerability actually is.
00:15:03.200 --> 00:15:19.039
And so reviewing the vulnerability information, the text, not just the number as far as the provided CVE difficulty or you know, the uh the uh likelihood, uh, often that's listed out appropriately based on sort of a generic uh assessment.
00:15:19.039 --> 00:15:25.600
If you have environmental configuration things that may reduce that, you can consider that as an uh an altered thing.
00:15:25.600 --> 00:15:30.799
So this is you know meant for if this was on an internet-facing system, this would be a 10, for instance.
00:15:30.799 --> 00:15:36.159
But on systems with restricted access and an isolated network, et cetera, this falls lower.
00:15:36.159 --> 00:15:43.440
And so maybe you can then deprioritize that or have mitigations in place that can help to answer the question to your executive leadership.
00:15:43.440 --> 00:15:44.399
Did you know about this?
00:15:44.399 --> 00:15:45.360
Yes, we did.
00:15:45.360 --> 00:15:46.559
What do we do about it?
00:15:46.559 --> 00:15:51.440
Well, we've got controls in place and we'll patch it within the normal patch cycle at the end of the month.
00:15:51.440 --> 00:15:53.039
Oh, okay, that sounds good.
00:15:53.039 --> 00:15:55.360
And we're gonna have additional monitoring, for instance.
00:15:55.360 --> 00:16:06.159
We're gonna spin up additional monitoring looking for this specific traffic at our edge and at our network uh egress points and maybe across uh various different uh monitoring positions within our network.
00:16:06.159 --> 00:16:11.519
That helps you have that heightened level of visibility during the time where you may be vulnerable.
00:16:11.519 --> 00:16:16.000
And so in case something does happen, you can be ready to take action when you see this.
00:16:16.000 --> 00:16:21.440
I think part of it's also gonna be if you believe that you have been compromised by that, doing your own hunting.
00:16:21.440 --> 00:16:36.399
And again, if you have that map of those systems and the environments and how they interconnect, you can then have a more targeted hunting capability and say, I'm gonna target the financial system, I'm gonna look for any indications of any compromise here that may have started with this vulnerability or related to this vulnerability.
00:16:36.399 --> 00:16:37.919
That's important again to know.
00:16:37.919 --> 00:16:48.799
But if you also have a mapping across those critical systems, you can say this vulnerability does not come into play or does not impact these systems because they don't use that technology.
00:16:48.799 --> 00:16:51.039
That's also a good piece of news.
00:16:51.039 --> 00:16:54.639
Or each of them use this technology, maybe in different ways.
00:16:54.639 --> 00:16:59.120
This one is deployed in a in a test environment over here, but it's not in production.
00:16:59.120 --> 00:17:02.720
They can prioritize accordingly based on the risk there.
00:17:02.720 --> 00:17:16.319
That's one of those things that again requires partnership with the business owners to understand the governance requirements, the compliance requirements, regulatory issues, et cetera, so that you're prioritizing correctly.
00:17:16.319 --> 00:17:24.480
This is the hard work of IT security and is is not as fancy and fun as finding a malicious actor and doing this cool stuff.
00:17:24.480 --> 00:17:29.200
But this is the stuff that keeps an environment safe when there's unknowns out there.
00:17:29.440 --> 00:17:34.240
And often often a very thankless portion of it as well.
00:17:34.240 --> 00:17:35.279
Yeah.
00:17:35.519 --> 00:17:40.640
Yeah, I I've done uh GRC consulting for a number of years, so you're 100% right.
00:17:41.599 --> 00:17:50.240
Finally, I I really want to touch on the internal pressure that people are facing, maybe from their leadership.
00:17:50.240 --> 00:18:02.559
It's one thing to, you know, look at the release CVE and fully understand these threats, but you know, it's a whole other game to explain them to executives who just want to know if they're safe or not.
00:18:02.559 --> 00:18:12.720
So, like, how how should we as defenders be communicating this reality of unknown threats and the need for this resilience to the leadership teams?
00:18:13.039 --> 00:18:28.559
A part of it is establishing leadership as a stakeholder in any security program and security plan, making sure they understand the process you go through to defend the environment and what you would do in a situation where you have an unknown vulnerability or a new vulnerability being disclosed.
00:18:28.559 --> 00:18:50.319
Walk them through that process so they understand where they will get updates, what they should expect, and the diligence for doing as far as evaluating the threat, looking across our business critical systems, validating if they are impacted or not, considering mitigations, considering testing and deployment, and validating that they are okay with the timeline on a nominal vulnerability.
00:18:50.319 --> 00:18:54.799
And then explaining that we also have a capability of doing an emergency deployment.
00:18:54.799 --> 00:18:56.720
But that creates a different risk.
00:18:56.720 --> 00:19:00.960
If you deploy without testing, you could be bringing the whole environment down.
00:19:00.960 --> 00:19:13.920
But if they accept that risk, then they put their little executive stamp on it, then perhaps we have to take action on that with that notification that they are accepting the risk and this is done at the behest of the CEO or whatever.
00:19:13.920 --> 00:19:18.319
But having a backup plan and being a way to roll that patch back is crucial.
00:19:18.319 --> 00:19:25.599
If there's a patch that you can't roll back, making that clear to them as well, like we aren't testing or we're doing extra testing on this because we can't roll it back.
00:19:25.599 --> 00:19:35.759
We deploy it, it changes things fundamentally, and we will have to revert back to a disaster recovery backup or to rebuild our whole environment, not just roll the patch back.
00:19:35.759 --> 00:19:37.519
That also changes the metric.
00:19:37.519 --> 00:19:43.920
Some patches are indeed like that, where they change uh something significantly to the point where you have to actually rebuild an environment.
00:19:43.920 --> 00:20:04.400
So being clear with your executives, I realize that they're not going to understand all the technical details behind the vulnerabilities, but they do understand timelines, they do understand commitments, and they also, if you have again in the security program, you have a periodic change review process that they are part of and they have visibility into and they can participate in.
00:20:04.400 --> 00:20:06.960
I think that uh helps along the way.
00:20:06.960 --> 00:20:16.880
Again, this is administrative requirements and work that need to be established, but bringing them in as partners is crucial for them accepting the process you're doing.
00:20:17.440 --> 00:20:18.319
Exactly.
00:20:18.319 --> 00:20:43.359
And I mean, this is going slightly off topic, but I'm thinking about an episode that I did several months back now, where if leadership is frustrated with the pace and you know, they they just want things to get done and they want to know if they're safe, like point to you know, all of the trails that you've previously left.
00:20:43.359 --> 00:20:52.400
And I mean, thinking about budget and headcount and things like that, like this is an area where you can advocate for yourself and for your team.
00:20:52.799 --> 00:21:04.799
I percent I mentioned before people processing technology, and this is where you need to, as a leader of a defense organization, you don't just spend all your whole budget on technology, you don't spend it on people or the process.
00:21:04.799 --> 00:21:09.039
You need to have an equal share across all those peep those features.
00:21:09.039 --> 00:21:12.240
You need people to execute the process against the technology.
00:21:12.240 --> 00:21:17.119
So this is a chance for you to say, you know what, to do this in a way that's gonna be meaningful.
00:21:17.119 --> 00:21:22.640
I need some some people who are experienced defenders who have done this vulnerability management type of stuff in the past.
00:21:22.640 --> 00:21:32.400
I need them to be uh here on the team to help to evaluate this one's gonna be dedicated to the financial services system, this one's gonna be dedicated to our shipping system, et cetera, or maybe they're on a rotation or whatever.
00:21:32.400 --> 00:21:34.559
And you know, you'd make those arguments.
00:21:34.559 --> 00:21:47.119
I think that in my mind at least has a lot more of a place now in this conversation because we know that there's this wave of incoming unknown or soon-to-be-known threats that are about to hit or will be hitting over time.
00:21:47.119 --> 00:21:53.440
I think ramping up a vulnerability management process is appropriate for any environment uh that's as a defender.
00:21:53.440 --> 00:22:20.160
And that also includes refreshing and re-evaluating your disaster recovery plan, refreshing and reevaluating your incident response plan, making sure your leadership knows the roles that they have in these things, and that they know the process for getting a status check from you, the security team, on these vulnerabilities and giving them a more periodic readout of here's the vulnerabilities we evaluated over the past week, here's our plans for deployment and testing.
00:22:20.160 --> 00:22:22.480
Please validate that you're on board with this.
00:22:22.480 --> 00:22:24.319
And again, involving them in the process.
00:22:24.319 --> 00:22:30.640
Executives don't necessarily like to spend a lot of time thinking about security risks, but they'd rather be informed than be in the dark.
00:22:30.880 --> 00:22:32.799
Well, Pierre, thanks so much for joining me.
00:22:33.039 --> 00:22:33.440
Certainly.
00:22:33.440 --> 00:22:35.200
There's a lot to be said on this topic.
00:22:35.200 --> 00:22:39.839
And so we may have to revisit it down the road as well and come back to see how things are going.
00:22:39.839 --> 00:22:48.319
Um, but uh I encourage all defenders to take a deep breath, think about their relationship with their business leaders, business owners, and then to refresh this.
00:22:48.559 --> 00:22:49.920
Yeah, absolutely.
00:22:49.920 --> 00:22:59.359
And I'm sure everyone here at Talos wants to thank you for all the work that you do in keeping people in your organization safe.
00:22:59.359 --> 00:23:01.680
Um and thank you so much for listening.
00:23:01.680 --> 00:23:05.519
We'll see you again in two weeks for a new episode.
00:23:05.519 --> 00:23:08.160
And until then, stay safe out there.
