WEBVTT
00:00:14.137 --> 00:00:17.268
Hi and hello to the latest session of Zero Downtime.
00:00:17.268 --> 00:00:22.011
My name is Jed Wallace and I'm a Senior Technical Marketing Manager here at Cohesity.
00:00:22.011 --> 00:00:29.293
Now today we're diving into one of the most critical and most targeted layers of modern
enterprise infrastructure, identity.
00:00:29.494 --> 00:00:33.656
know, identity has become the control plane of the business.
00:00:33.656 --> 00:00:37.027
If it's compromised, operations stop.
00:00:37.027 --> 00:00:39.838
Ransomware groups, they know it.
00:00:39.838 --> 00:00:41.825
Nation state actors know it.
00:00:41.825 --> 00:00:48.111
And yet many organizations still treat Active Directory and hybrid identity as uh just
infrastructure.
00:00:48.111 --> 00:00:53.887
So to unpack this, I'm joined by Guido from some Paris.
00:00:53.887 --> 00:00:58.391
He's a subject matter expert in identity security and resilience.
00:00:58.391 --> 00:01:02.595
uh Guido, would you like to do a quick intro for the audience?
00:01:02.839 --> 00:01:03.349
Happy.
00:01:03.349 --> 00:01:04.550
Thanks for having me here, Jed.
00:01:04.550 --> 00:01:06.341
It's a pleasure to be here.
00:01:06.442 --> 00:01:09.824
Yeah, Guido Grillenmeier from Germany, Frankfurt to be exact.
00:01:09.824 --> 00:01:10.454
I'm with St.
00:01:10.454 --> 00:01:20.852
Paris now for five years, and I'm uh one of our principal technologists um serving our
clients globally uh in the whole identity security space.
00:01:20.852 --> 00:01:24.425
And of course, uh identity security means cyber resilience.
00:01:24.425 --> 00:01:29.808
It's an area that I've worked in before at HP for 25 years before joining St.
00:01:29.808 --> 00:01:31.009
Paris and...
00:01:31.009 --> 00:01:33.226
Happy to be here on this podcast.
00:01:33.687 --> 00:01:35.448
Awesome, thank you so much.
00:01:35.448 --> 00:01:37.888
So with that, let's get into it guys.
00:01:38.409 --> 00:01:40.850
So let's start at a high level.
00:01:40.850 --> 00:01:48.312
I mean, it feels like we've officially moved from the perimeter uh security to like
identity is the new control plane.
00:01:48.312 --> 00:01:55.585
So from your vantage point, why are attackers so focused on after directory and hybrid
identity right now?
00:01:56.545 --> 00:02:06.593
Yeah, it's been like that for a while now, but finally the industry has caught up on the
thread that corporate identities is the thing that they must worry about.
00:02:06.593 --> 00:02:19.312
The reason that attackers go after your AD and other connected identity providers such as
Microsoft Entra ID is that these services literally hold the keys to the kingdom.
00:02:19.633 --> 00:02:26.146
And let's not forget before AD was released, now more than 26 years ago, the IT world
00:02:26.146 --> 00:02:29.626
was much more segregated from an identity perspective.
00:02:29.626 --> 00:02:38.586
You'll recall the different identity providers back in the day, NT, Domains, and Novell,
NDS, Banyan, you name it.
00:02:38.586 --> 00:02:41.406
And typically, small in scope.
00:02:41.606 --> 00:02:52.266
And the difference with AD is that it was the first flexible directory that was easy to
integrate apps to that scale to support the largest company on this planet.
00:02:52.266 --> 00:02:54.070
And with this, it became the
00:02:54.070 --> 00:02:57.412
de facto standard for centralized directory services.
00:02:57.613 --> 00:03:10.092
And then it's just fair to say that AD's success has turned it into a weakness since for
quite a few years now, attacks have learned to exploit it and utilize it in their kill
00:03:10.092 --> 00:03:10.792
chain.
00:03:11.363 --> 00:03:13.886
Yeah, that's great.
00:03:14.949 --> 00:03:20.678
you know, and that risk only compounds once you introduced into a hybrid environment, in
my opinion.
00:03:20.678 --> 00:03:22.921
So, yeah.
00:03:22.999 --> 00:03:24.299
Absolutely.
00:03:24.380 --> 00:03:32.284
It's basically, once you own the directory, it doesn't matter if it's in the hybrid
environment or on-prem.
00:03:32.925 --> 00:03:43.931
The attacker can assign themselves to a group, be it a cloud group, be it on-prem, that
assigns them the permissions to the actual business data that they're after.
00:03:43.931 --> 00:03:48.724
They might just be after that for reconnaissance, let's say espionage.
00:03:48.819 --> 00:03:52.807
but in the end they own your whole infrastructure.
00:03:53.303 --> 00:04:05.038
Yeah, mean, hybrid identity was supposed to give us flexibility, know, that cloud scale
modern authentication, but did we unintentionally expand the blast radius by connecting
00:04:05.038 --> 00:04:07.829
on-prem AD to intra ID, you know?
00:04:08.810 --> 00:04:11.501
So your thoughts.
00:04:11.749 --> 00:04:16.833
would say that that wasn't really intentional, but yes, it's happened.
00:04:16.833 --> 00:04:29.982
em The thing is, like I mentioned, em Active Directory is where it started, and the Cloud
Directory was initially called Azure Active Directory.
00:04:29.982 --> 00:04:35.842
So Microsoft built on the success story that they've had with AD and a uh
00:04:35.842 --> 00:04:40.646
product that IT companies, IT admins felt comfortable with.
00:04:40.646 --> 00:04:53.737
And now you basically needed to use that cloud version that was called Azure Active
Directory to use the new cloud offerings from Microsoft, Office, uh beginning with email
00:04:53.737 --> 00:04:58.281
and SharePoint and then later OneDrive and now Teams, everybody wants Teams.
00:04:58.281 --> 00:05:04.054
So folks went with that flow and without necessarily realizing.
00:05:04.054 --> 00:05:10.728
that this new cloud directory was a completely different technology that one needed to
care about deeply.
00:05:11.309 --> 00:05:13.680
Yeah, it's not just another database, right?
00:05:13.680 --> 00:05:25.387
what do you think the most common misconfigurations or in your mind blind spots that you
see between on-prem and cloud identity?
00:05:26.394 --> 00:05:28.935
Yeah, Jed, how long is this podcast?
00:05:28.935 --> 00:05:32.997
So seriously, exactly.
00:05:33.137 --> 00:05:39.819
It's a long list of dangerous things that we see in the wild when we do security
assessments for our clients.
00:05:40.280 --> 00:05:46.222
For both on-prem and cloud, it often begins with the lack of a proper tiering model.
00:05:46.222 --> 00:05:55.733
And this means to ensure proper segregation between privileged identities such as on-prem
your domain, admin, enterprise admin, or in the cloud, the global admin.
00:05:55.733 --> 00:06:00.526
and your normal office account that you serve the web with and do email and stuff.
00:06:00.526 --> 00:06:08.650
This is em often more an organizational topic than that just needs to be pulled through
properly.
00:06:08.650 --> 00:06:16.194
You don't need special technology much to get this working, but it still takes uh
concerted effort.
00:06:16.234 --> 00:06:23.904
In the on-print world, the risks through misconfigured certificate templates
00:06:23.904 --> 00:06:25.465
are clearly on the rise.
00:06:25.465 --> 00:06:36.014
We see that all the time and are also used more often by the attackers, just like they
continue to miss old but overprivileged service accounts whose passwords they can often
00:06:36.014 --> 00:06:37.985
crack through cover roasting.
00:06:37.985 --> 00:06:38.886
Yeah.
00:06:38.946 --> 00:06:48.234
And let me add something on those service accounts because it's just the right moment for
that because companies might have the root awakening.
00:06:48.234 --> 00:06:53.932
Microsoft is realizing, let's say, service accounts being used with old
00:06:53.932 --> 00:07:02.349
protocols RC4 for authentication and they are about to make a bold move on their goal to
decommission uh RC4.
00:07:02.349 --> 00:07:15.700
First step was done in January with some patches and then in April new patches are going
to force uh applications to actually use AAS, the service accounts used for that
00:07:15.700 --> 00:07:17.000
authentication.
00:07:17.002 --> 00:07:23.836
And I'm telling you, there are companies that are going to have a rude awakening for that
if they don't prepare.
00:07:24.567 --> 00:07:25.928
Yeah.
00:07:27.250 --> 00:07:28.271
Yes.
00:07:28.392 --> 00:07:35.069
Something's bound to break, you know, and often the AD team and the cloud teams, they're
not even the same people, right?
00:07:35.069 --> 00:07:38.443
So does that organizational gap increase the risk?
00:07:40.052 --> 00:07:54.206
I think it can em increase the risk, but as long as the teams are communicating with, you
know, about the same goal that they should have to close security gaps, that team
00:07:54.206 --> 00:07:58.327
separation mustn't always be an issue because it is different skills.
00:07:58.327 --> 00:08:03.929
Think about the whole AI topic is much more cloud bound than it is on-prem bound.
00:08:03.929 --> 00:08:08.851
And that's where the cloud guys need to worry about permissions given to
00:08:08.851 --> 00:08:14.777
those apps, those service principles that work with AI bots, et cetera.
00:08:14.777 --> 00:08:19.382
uh It's something that the AD folks know a little about.
00:08:19.683 --> 00:08:23.007
the AD is often seen as infrastructure.
00:08:23.007 --> 00:08:25.890
And cloud is often on the security side.
00:08:25.890 --> 00:08:30.154
But as long as they work together, they still have a chance, of course.
00:08:30.703 --> 00:08:44.143
Yeah, I always say when it comes to security is that all the teams need to be in
communication with each other or you're just gonna quadruple your time if you have to
00:08:44.143 --> 00:08:50.423
recover from an event, whether it's security related or a disaster.
00:08:51.143 --> 00:08:54.683
So let's say the worst happens.
00:08:56.923 --> 00:08:58.783
What do we do?
00:08:59.669 --> 00:09:06.260
What are your thoughts if say, you know, they get cratered and they need to bring it back
up and running.
00:09:06.260 --> 00:09:12.210
mean, your thoughts, it's, definitely the first, usually the first workload that has to
be, uh, become up and running.
00:09:12.210 --> 00:09:14.103
I mean, what are you hearing out there?
00:09:15.010 --> 00:09:27.757
em The important thing is that we need to distinguish between those different types of,
let's say, challenges when we talk about uh an AD or uh even a cloud directory being
00:09:27.757 --> 00:09:28.417
attacked.
00:09:28.417 --> 00:09:30.458
Most attacks uh happen on-prem.
00:09:30.458 --> 00:09:34.481
That's just the easier path for intruders these days.
00:09:34.481 --> 00:09:44.766
Now, there are updates that Microsoft also shares for Storm 501 that use on-prem Active
Directory to move into the cloud via
00:09:45.059 --> 00:09:49.979
the sync connection that is a known path.
00:09:49.979 --> 00:09:55.999
But nonetheless, a lot of attacks that we see happen on-prem and then is it just deleted
objects?
00:09:55.999 --> 00:09:57.939
Could also be an operational mistake?
00:09:57.939 --> 00:09:59.459
Those are easy to fix.
00:09:59.459 --> 00:10:05.479
Even a domain controller that goes down Active Directory is basically fairly resilient.
00:10:05.479 --> 00:10:13.762
But the true risk and challenge that clients have is what you just hinted at, a complete
00:10:13.762 --> 00:10:22.402
take down, a complete take down of an environment, ransomware attack style, everything is
encrypted, then what are you going to do?
00:10:22.402 --> 00:10:31.342
The first thing that you have to get back is the AD forest, which is a really complicated
process if you do it manually.
00:10:31.342 --> 00:10:32.682
It's well described.
00:10:32.682 --> 00:10:39.342
Microsoft has a good forest recovery guide that I believe if you print it out, you're
talking 160 pages.
00:10:39.382 --> 00:10:40.780
It's complete.
00:10:40.780 --> 00:10:46.994
But it's complicated, 29 steps that are much manual.
00:10:46.994 --> 00:10:50.756
And that if you don't practice it, just forget it.
00:10:50.756 --> 00:10:54.198
It will neither be fast nor will it be correct.
00:10:54.198 --> 00:10:59.401
And then you're still not sure that you didn't bring malware back from the backups that
you might have taken.
00:11:00.640 --> 00:11:06.225
I think what you're getting at is, you know, identity recovery is it's definitely a
completely different challenge.
00:11:06.225 --> 00:11:10.970
um you can't just restore domain controller like a virtual machine.
00:11:10.970 --> 00:11:16.225
You know, what other things can organizations do?
00:11:16.225 --> 00:11:20.320
You know, what are they misunderstanding about identity recovery, I should say?
00:11:20.320 --> 00:11:32.321
Well, if they don't think about it more, then they miss out on understanding em what's
even realistic from a recovery perspective, from a time perspective.
00:11:32.321 --> 00:11:44.382
you're taken down, every business owner that doesn't own the whole company but might be
responsible for a particular business apps in their company has an understanding of how
00:11:44.382 --> 00:11:46.911
quick he m
00:11:46.911 --> 00:11:51.423
and his team can bring that application back running.
00:11:51.423 --> 00:12:02.277
So he has a particular recovery time objective that you might say is in minutes, because
he might fail over to another machine, or maybe hours if he brings it back from some
00:12:02.317 --> 00:12:03.457
backup.
00:12:03.457 --> 00:12:06.428
But they forget the dependency chain.
00:12:06.428 --> 00:12:08.039
They forget the dependency chain.
00:12:08.039 --> 00:12:15.846
So an RTO, after being completely wiped out, of course, is totally different baby.
00:12:15.846 --> 00:12:21.669
than a singular failure of some business application.
00:12:21.669 --> 00:12:30.354
Most companies um need to think about how long do I even have the time that my business
can survive?
00:12:30.354 --> 00:12:39.078
um then thinking in addition to that, I need to bring my active directory back in that
time, maybe four to eight hours.
00:12:39.419 --> 00:12:45.088
That doesn't match nicely to the capabilities of
00:12:45.088 --> 00:12:48.064
you know, doing a uh manual recovery.
00:12:48.064 --> 00:12:57.800
So for a uh proper RTO, recovery of an AD forest can hardly be met without proper tool
that automates this whole process.
00:12:57.913 --> 00:13:03.593
So, mean, does it, that begs the question, are most recovery time objectives for identity
even realistic?
00:13:04.288 --> 00:13:12.903
Well, that's, that's, I think is something that, that companies that don't prepare upfront
will be hard pressed to find out that they're never realistic.
00:13:12.903 --> 00:13:13.283
Yeah.
00:13:13.283 --> 00:13:18.686
You need to practice even if you do it manual, I'm not totally against manual processes.
00:13:18.776 --> 00:13:22.388
um, but then, then you can't keep an RTO that's very short.
00:13:22.388 --> 00:13:33.326
Then you'll need to just accept, okay, we're going to have to deal with two, three, four
days of our outage because companies, once they get into this, they realize.
00:13:33.326 --> 00:13:36.968
that um without identity, nothing works.
00:13:36.968 --> 00:13:42.451
So I can't even continue the recovery of my other applications if I don't have my
identity.
00:13:42.492 --> 00:13:43.752
Exactly, exactly.
00:13:43.752 --> 00:13:45.844
Very often that's exactly the case.
00:13:45.844 --> 00:13:46.824
Exactly.
00:13:47.065 --> 00:13:57.349
So if Zero Town Time is the goal, what does true identity resilience look like before an
attack even ever happens?
00:13:58.113 --> 00:14:02.985
You know, Jed, I would say this is actually for any crisis.
00:14:03.165 --> 00:14:09.308
In a ransomware attack, like the one that we're sort of discussing, belongs totally into
this category.
00:14:09.308 --> 00:14:13.929
You want to spend a good amount of time to prepare upfront.
00:14:13.929 --> 00:14:24.454
uh Understand your most critical business apps and who operates them so you have an idea
um what you must concentrate on uh after you've been hit.
00:14:24.454 --> 00:14:25.824
And then consider
00:14:25.824 --> 00:14:28.596
the dependencies of those critical apps.
00:14:28.596 --> 00:14:31.198
What dependencies do they have?
00:14:31.198 --> 00:14:37.562
Where you find that most of your on-prem apps, you'll need to ensure that your AD is
operational.
00:14:37.562 --> 00:14:42.415
And then, of course, in parallel to that, name resolution, DNS, must work.
00:14:42.415 --> 00:14:44.316
And of course, you have to have network and machines.
00:14:44.316 --> 00:14:47.568
And all of those dependencies must be understood.
00:14:47.568 --> 00:14:50.818
And soon, you will have that defined.
00:14:50.818 --> 00:14:56.621
uh basis of your so-called minimal viable company.
00:14:56.841 --> 00:15:06.177
Of course, you want to do the same for your most critical cloud applications, understand
their dependencies and understand your backups.
00:15:06.177 --> 00:15:08.068
Where are they actually located?
00:15:08.068 --> 00:15:11.550
Because uh an on-prem backup is the first thing.
00:15:11.550 --> 00:15:19.314
If it's not well protected, and I know you guys have some cool solutions to protect it,
then that'll be the first thing that attackers take out.
00:15:19.599 --> 00:15:32.887
oh One of our oldest taglines is know your data, And what is, right, that means know where
it is, uh know how it's being backed up, what your retention is, all that other good
00:15:32.887 --> 00:15:33.397
stuff, right?
00:15:33.397 --> 00:15:35.458
Do you have three, two, one, right?
00:15:35.458 --> 00:15:39.250
Do you have multiple copies in different regions and all that other good stuff?
00:15:39.271 --> 00:15:39.735
So.
00:15:39.735 --> 00:15:41.935
doesn't go away for your identity backups either.
00:15:41.935 --> 00:15:43.515
No, does not.
00:15:43.515 --> 00:15:44.855
It absolutely does not.
00:15:45.435 --> 00:15:48.015
So, you know, kind of pivoting just a tad.
00:15:48.495 --> 00:15:50.535
You know, what are you seeing in the field?
00:15:50.535 --> 00:15:59.751
Like what identity-based attacks trends should, you know, security leaders and C-suite and
all those other folks, what should they be paying attention to this year?
00:16:00.577 --> 00:16:06.092
We've seen a lot in the wild and we're doing security assessments for many clients, large
and small.
00:16:06.092 --> 00:16:13.648
And I would definitely check out the vulnerabilities on my own certificate services if
they are AD integrated.
00:16:13.648 --> 00:16:17.942
That's a very common setup in many companies, AD integrated certificate services.
00:16:17.942 --> 00:16:21.345
uh No extra costs, et cetera.
00:16:21.345 --> 00:16:28.370
But in those, for example, you have over-missive settings in your certificate templates
that make you vulnerable.
00:16:28.380 --> 00:16:32.833
And they often go unnoticed and they're not really too difficult to fix.
00:16:32.833 --> 00:16:40.483
And there's three tools such as Locksmith or Purple Knight that help you fix them or not
fix them, but find them.
00:16:40.483 --> 00:16:51.323
Actually, Locksmith also has some cool features to fixing settings, although people always
should look uh at what's necessary for the fix and understand it.
00:16:51.423 --> 00:16:54.755
And let me just add to that, did I already mention tearing?
00:16:54.755 --> 00:16:56.406
Yeah, tearing.
00:16:56.406 --> 00:17:00.466
being one of the most important things to take care of.
00:17:01.036 --> 00:17:08.722
Now remind me in the audience, Purple Night, um even though that's your tool, it's a free
tool, right?
00:17:09.343 --> 00:17:10.424
Yeah.
00:17:10.424 --> 00:17:18.420
it, regardless if it's from some Paris, you know, it's used some kind of tool to identify,
you know, those vulnerabilities.
00:17:18.420 --> 00:17:19.730
Absolutely, absolutely.
00:17:19.730 --> 00:17:27.676
There's others, there's Pink Castle, there's good tools out there that people should be
utilizing much better than not using anything.
00:17:28.183 --> 00:17:36.919
So are attackers getting quieter or more patient, embedding persistence inside, AD instead
of like going loud?
00:17:39.082 --> 00:17:43.265
That's a difficult em one to sort of give a universal answer to.
00:17:43.265 --> 00:17:48.649
em We've seen, yeah, because we've seen both things.
00:17:48.649 --> 00:17:49.720
Jed, we've seen both things.
00:17:49.720 --> 00:18:01.518
There's the silent ones that do long reconnaissance before they either destroy or simply
gather the intelligence needed to spy on you for whatever development a company might be
00:18:01.518 --> 00:18:01.869
up to.
00:18:01.869 --> 00:18:04.980
I've seen this with turbines.
00:18:06.935 --> 00:18:14.228
developed in Germany and then rebuilt with plans that were stolen in, let's just say,
another country.
00:18:14.228 --> 00:18:17.824
I don't want to highlight any specific here.
00:18:17.824 --> 00:18:18.444
Exactly.
00:18:18.444 --> 00:18:25.089
em But there's also the class of those actors that are more or less fast and furious.
00:18:25.089 --> 00:18:30.033
They start their destruction as soon as they get the necessary privileges.
00:18:30.033 --> 00:18:36.617
But em what we've seen in attacks, and we've been involved in quite a few incident
responses to help clients
00:18:36.770 --> 00:18:42.990
revive them, is that the attackers, in any case, try to persist in AD.
00:18:42.990 --> 00:18:55.190
Be it just a single additional account that they add and add to a privileged group, it is
something that you have to take care of as you're, let's say, during or after the breach
00:18:55.190 --> 00:18:56.430
situation.
00:18:56.550 --> 00:19:06.006
And in the worst case, if you recover from your backups, that might still be that
compromised configuration in AD that you do need to fix.
00:19:06.006 --> 00:19:09.468
That's also something that is important to remember.
00:19:09.975 --> 00:19:20.237
Yeah, and identity attacks now happening, I mean, are they happening earlier in the kill
chain or than they were a few years ago?
00:19:21.022 --> 00:19:24.483
I wouldn't really say so that they're earlier.
00:19:25.464 --> 00:19:30.226
The typical attacker still gets into your environment as just a normal user.
00:19:30.267 --> 00:19:38.371
And it's just an employee uh that opens the wrong mail attachment or clicks on the wrong
link.
00:19:38.371 --> 00:19:44.919
uh The attacker then uh is that user in an identity, and that's normally.
00:19:44.919 --> 00:19:51.583
mean, not an admin, that would be like the jackpot if an admin were to click that link,
and then the attackers are really happy.
00:19:51.583 --> 00:19:52.143
Yeah.
00:19:52.143 --> 00:19:58.027
So, but em usually the attacker is just a normal user, that means a non-privileged user.
00:19:58.027 --> 00:20:07.659
And then he walks up that kill chain by first gaining local admin privileges, system
privileges through weaknesses on the box that he's running on.
00:20:07.659 --> 00:20:12.023
And then, you know, taking the kill chain by reconnaissance in AD.
00:20:12.023 --> 00:20:20.165
which unfortunately is extremely easy because Active Directory is open like a barn door
when it comes to read permissions.
00:20:20.165 --> 00:20:26.246
Everybody can read everything unless you've locked it down a lot.
00:20:26.246 --> 00:20:27.967
And that means also your weaknesses.
00:20:27.967 --> 00:20:32.788
So um the weakness that you find, the attacker will also find.
00:20:32.788 --> 00:20:35.109
So it's up to you to close that.
00:20:35.109 --> 00:20:41.510
Let me add one more thing because I would have to say there's of course that other type of
attack that has
00:20:41.942 --> 00:20:54.311
I'm not sure to say increased, but we've certainly noticed some big hits here where you
can just buy uh credentials, stolen credentials, hacked credentials on the dark weather.
00:20:54.311 --> 00:20:55.932
They're not expensive.
00:20:55.972 --> 00:20:59.295
I've never tried it, but I've read a lot about it.
00:20:59.295 --> 00:21:01.116
They're not expensive to get.
00:21:01.116 --> 00:21:09.324
And then if you do your homework to understand, what's that user's name, whose credentials
I have here, and you bound it,
00:21:09.324 --> 00:21:16.798
to maybe the company that the guy works on through social engineering and scavenging
LinkedIn, Facebook, and whatnot.
00:21:16.798 --> 00:21:22.081
You find out this guy works at Colonial Pipeline and he's actually an IT staff.
00:21:22.221 --> 00:21:34.308
Hey, I found in Colonial Pipeline, this example, unfortunately true, had an um
internet-facing unprotected remote access client.
00:21:34.308 --> 00:21:35.488
no MFA.
00:21:35.488 --> 00:21:37.069
The credentials were.
00:21:37.209 --> 00:21:38.530
Attacker was in.
00:21:38.850 --> 00:21:43.850
That's a very early identity attack of that type.
00:21:44.234 --> 00:21:46.097
So that actually is a good segue.
00:21:46.097 --> 00:21:57.014
So if we were to make this actionable, if you had to prioritize like three things an
organization should do this year to strengthen their identity resilience, what would they
00:21:57.014 --> 00:21:58.055
be in your mind?
00:22:00.404 --> 00:22:06.573
Yeah, I would say first to really get a better understanding of your own identity.
00:22:06.573 --> 00:22:07.880
all your passwords.
00:22:11.830 --> 00:22:13.291
No, truly.
00:22:13.371 --> 00:22:21.931
Get a better start with getting a better understanding of your own identity security
posture and maybe change all those passwords.
00:22:22.051 --> 00:22:28.491
But the free tools out there, we mentioned Purple Knight, Ping Castle, Locksmiths on the
certificate side.
00:22:28.491 --> 00:22:39.060
There's plenty of powerful free tools out there that give you a proper security score and
list the most critical issues that you should at least become aware of.
00:22:39.060 --> 00:22:47.414
Ideally, take some uh homework from and discuss in your teams, be it cloud, be it on-prem,
like, what should we do better?
00:22:47.875 --> 00:22:59.161
Second, in the context of what we've discussed, I really think that companies need to
think broader about the whole cyber resilience topic, not just try to protect as much as
00:22:59.161 --> 00:23:04.124
they can, but understand, how do I actually really prepare for the worst?
00:23:04.204 --> 00:23:07.498
And that means uh a true crisis.
00:23:07.498 --> 00:23:12.901
I we all do backups all the time, but what is it if I actually need to utilize them all at
once?
00:23:13.601 --> 00:23:16.103
You've been wiped out.
00:23:16.103 --> 00:23:29.570
And those that prepare and practice their crisis management processes and related tooling
are much better at surviving a cyber crisis than those that are hit unprepared.
00:23:29.570 --> 00:23:31.851
And I like to always compare that.
00:23:31.851 --> 00:23:36.614
em Like, when would you prefer to fall into a lake?
00:23:36.614 --> 00:23:39.836
after you've already learned to swim or before.
00:23:39.836 --> 00:23:43.879
So you want to learn to swim before you're hit.
00:23:44.259 --> 00:23:57.288
And then third, I'd actually take that cyber resilience step uh one step further and do
think about a minimum viable company and discuss how to operate such a model in your
00:23:57.288 --> 00:23:57.999
context.
00:23:57.999 --> 00:24:06.006
That takes too much for this podcast, but it is definitely taking up speed that companies
understand.
00:24:06.006 --> 00:24:08.315
This is something we should look at.
00:24:08.503 --> 00:24:12.326
Yeah, have a plan, have it written down, test that planned.
00:24:12.326 --> 00:24:15.188
That way you're prepared in case there is an event, right?
00:24:15.188 --> 00:24:29.139
So now for someone listening, um if they can only do one thing next quarter to really
reduce their risk, what should it be in your
00:24:30.550 --> 00:24:36.897
It really never hurts to focus on the first point I mentioned, understanding your identity
security posture.
00:24:36.897 --> 00:24:46.406
That's what also the attacker will check when they are inside your environment and check
for your weakest links and ideally do something about it.
00:24:46.506 --> 00:24:49.620
And uh did I mention tiering?
00:24:49.855 --> 00:24:53.458
Yeah, that's the new buzzword, right?
00:24:53.458 --> 00:24:55.839
So that's awesome.
00:24:56.701 --> 00:25:01.414
So I think the big takeaway here is identity isn't just infrastructure, right?
00:25:01.414 --> 00:25:03.536
It's, it's operational continuity.
00:25:03.536 --> 00:25:06.662
You know, if it fails, everything feels that you can't log in.
00:25:06.662 --> 00:25:09.010
You can't get in the building sometimes, right?
00:25:09.131 --> 00:25:11.653
So zero, zero downtime.
00:25:11.653 --> 00:25:14.475
It's not about avoiding the attack entirely, right?
00:25:14.475 --> 00:25:19.321
It's about being prepared and having the ability to recover cleanly.
00:25:19.321 --> 00:25:21.742
confidently and definitely without chaos, right?
00:25:21.742 --> 00:25:24.213
That's where that communication comes into play.
00:25:24.233 --> 00:25:26.695
So Guido, thank you for the insight.
00:25:26.695 --> 00:25:31.617
This was a great deep dive and definitely an important one these days.
00:25:31.797 --> 00:25:36.329
I want to thank everyone for tuning into Zero Downtime and we'll see you next time.
00:00:14.137 --> 00:00:17.268
Hi and hello to the latest session of Zero Downtime.
00:00:17.268 --> 00:00:22.011
My name is Jed Wallace and I'm a Senior Technical Marketing Manager here at Cohesity.
00:00:22.011 --> 00:00:29.293
Now today we're diving into one of the most critical and most targeted layers of modern
enterprise infrastructure, identity.
00:00:29.494 --> 00:00:33.656
know, identity has become the control plane of the business.
00:00:33.656 --> 00:00:37.027
If it's compromised, operations stop.
00:00:37.027 --> 00:00:39.838
Ransomware groups, they know it.
00:00:39.838 --> 00:00:41.825
Nation state actors know it.
00:00:41.825 --> 00:00:48.111
And yet many organizations still treat Active Directory and hybrid identity as uh just
infrastructure.
00:00:48.111 --> 00:00:53.887
So to unpack this, I'm joined by Guido from some Paris.
00:00:53.887 --> 00:00:58.391
He's a subject matter expert in identity security and resilience.
00:00:58.391 --> 00:01:02.595
uh Guido, would you like to do a quick intro for the audience?
00:01:02.839 --> 00:01:03.349
Happy.
00:01:03.349 --> 00:01:04.550
Thanks for having me here, Jed.
00:01:04.550 --> 00:01:06.341
It's a pleasure to be here.
00:01:06.442 --> 00:01:09.824
Yeah, Guido Grillenmeier from Germany, Frankfurt to be exact.
00:01:09.824 --> 00:01:10.454
I'm with St.
00:01:10.454 --> 00:01:20.852
Paris now for five years, and I'm uh one of our principal technologists um serving our
clients globally uh in the whole identity security space.
00:01:20.852 --> 00:01:24.425
And of course, uh identity security means cyber resilience.
00:01:24.425 --> 00:01:29.808
It's an area that I've worked in before at HP for 25 years before joining St.
00:01:29.808 --> 00:01:31.009
Paris and...
00:01:31.009 --> 00:01:33.226
Happy to be here on this podcast.
00:01:33.687 --> 00:01:35.448
Awesome, thank you so much.
00:01:35.448 --> 00:01:37.888
So with that, let's get into it guys.
00:01:38.409 --> 00:01:40.850
So let's start at a high level.
00:01:40.850 --> 00:01:48.312
I mean, it feels like we've officially moved from the perimeter uh security to like
identity is the new control plane.
00:01:48.312 --> 00:01:55.585
So from your vantage point, why are attackers so focused on after directory and hybrid
identity right now?
00:01:56.545 --> 00:02:06.593
Yeah, it's been like that for a while now, but finally the industry has caught up on the
thread that corporate identities is the thing that they must worry about.
00:02:06.593 --> 00:02:19.312
The reason that attackers go after your AD and other connected identity providers such as
Microsoft Entra ID is that these services literally hold the keys to the kingdom.
00:02:19.633 --> 00:02:26.146
And let's not forget before AD was released, now more than 26 years ago, the IT world
00:02:26.146 --> 00:02:29.626
was much more segregated from an identity perspective.
00:02:29.626 --> 00:02:38.586
You'll recall the different identity providers back in the day, NT, Domains, and Novell,
NDS, Banyan, you name it.
00:02:38.586 --> 00:02:41.406
And typically, small in scope.
00:02:41.606 --> 00:02:52.266
And the difference with AD is that it was the first flexible directory that was easy to
integrate apps to that scale to support the largest company on this planet.
00:02:52.266 --> 00:02:54.070
And with this, it became the
00:02:54.070 --> 00:02:57.412
de facto standard for centralized directory services.
00:02:57.613 --> 00:03:10.092
And then it's just fair to say that AD's success has turned it into a weakness since for
quite a few years now, attacks have learned to exploit it and utilize it in their kill
00:03:10.092 --> 00:03:10.792
chain.
00:03:11.363 --> 00:03:13.886
Yeah, that's great.
00:03:14.949 --> 00:03:20.678
you know, and that risk only compounds once you introduced into a hybrid environment, in
my opinion.
00:03:20.678 --> 00:03:22.921
So, yeah.
00:03:22.999 --> 00:03:24.299
Absolutely.
00:03:24.380 --> 00:03:32.284
It's basically, once you own the directory, it doesn't matter if it's in the hybrid
environment or on-prem.
00:03:32.925 --> 00:03:43.931
The attacker can assign themselves to a group, be it a cloud group, be it on-prem, that
assigns them the permissions to the actual business data that they're after.
00:03:43.931 --> 00:03:48.724
They might just be after that for reconnaissance, let's say espionage.
00:03:48.819 --> 00:03:52.807
but in the end they own your whole infrastructure.
00:03:53.303 --> 00:04:05.038
Yeah, mean, hybrid identity was supposed to give us flexibility, know, that cloud scale
modern authentication, but did we unintentionally expand the blast radius by connecting
00:04:05.038 --> 00:04:07.829
on-prem AD to intra ID, you know?
00:04:08.810 --> 00:04:11.501
So your thoughts.
00:04:11.749 --> 00:04:16.833
would say that that wasn't really intentional, but yes, it's happened.
00:04:16.833 --> 00:04:29.982
em The thing is, like I mentioned, em Active Directory is where it started, and the Cloud
Directory was initially called Azure Active Directory.
00:04:29.982 --> 00:04:35.842
So Microsoft built on the success story that they've had with AD and a uh
00:04:35.842 --> 00:04:40.646
product that IT companies, IT admins felt comfortable with.
00:04:40.646 --> 00:04:53.737
And now you basically needed to use that cloud version that was called Azure Active
Directory to use the new cloud offerings from Microsoft, Office, uh beginning with email
00:04:53.737 --> 00:04:58.281
and SharePoint and then later OneDrive and now Teams, everybody wants Teams.
00:04:58.281 --> 00:05:04.054
So folks went with that flow and without necessarily realizing.
00:05:04.054 --> 00:05:10.728
that this new cloud directory was a completely different technology that one needed to
care about deeply.
00:05:11.309 --> 00:05:13.680
Yeah, it's not just another database, right?
00:05:13.680 --> 00:05:25.387
what do you think the most common misconfigurations or in your mind blind spots that you
see between on-prem and cloud identity?
00:05:26.394 --> 00:05:28.935
Yeah, Jed, how long is this podcast?
00:05:28.935 --> 00:05:32.997
So seriously, exactly.
00:05:33.137 --> 00:05:39.819
It's a long list of dangerous things that we see in the wild when we do security
assessments for our clients.
00:05:40.280 --> 00:05:46.222
For both on-prem and cloud, it often begins with the lack of a proper tiering model.
00:05:46.222 --> 00:05:55.733
And this means to ensure proper segregation between privileged identities such as on-prem
your domain, admin, enterprise admin, or in the cloud, the global admin.
00:05:55.733 --> 00:06:00.526
and your normal office account that you serve the web with and do email and stuff.
00:06:00.526 --> 00:06:08.650
This is em often more an organizational topic than that just needs to be pulled through
properly.
00:06:08.650 --> 00:06:16.194
You don't need special technology much to get this working, but it still takes uh
concerted effort.
00:06:16.234 --> 00:06:23.904
In the on-print world, the risks through misconfigured certificate templates
00:06:23.904 --> 00:06:25.465
are clearly on the rise.
00:06:25.465 --> 00:06:36.014
We see that all the time and are also used more often by the attackers, just like they
continue to miss old but overprivileged service accounts whose passwords they can often
00:06:36.014 --> 00:06:37.985
crack through cover roasting.
00:06:37.985 --> 00:06:38.886
Yeah.
00:06:38.946 --> 00:06:48.234
And let me add something on those service accounts because it's just the right moment for
that because companies might have the root awakening.
00:06:48.234 --> 00:06:53.932
Microsoft is realizing, let's say, service accounts being used with old
00:06:53.932 --> 00:07:02.349
protocols RC4 for authentication and they are about to make a bold move on their goal to
decommission uh RC4.
00:07:02.349 --> 00:07:15.700
First step was done in January with some patches and then in April new patches are going
to force uh applications to actually use AAS, the service accounts used for that
00:07:15.700 --> 00:07:17.000
authentication.
00:07:17.002 --> 00:07:23.836
And I'm telling you, there are companies that are going to have a rude awakening for that
if they don't prepare.
00:07:24.567 --> 00:07:25.928
Yeah.
00:07:27.250 --> 00:07:28.271
Yes.
00:07:28.392 --> 00:07:35.069
Something's bound to break, you know, and often the AD team and the cloud teams, they're
not even the same people, right?
00:07:35.069 --> 00:07:38.443
So does that organizational gap increase the risk?
00:07:40.052 --> 00:07:54.206
I think it can em increase the risk, but as long as the teams are communicating with, you
know, about the same goal that they should have to close security gaps, that team
00:07:54.206 --> 00:07:58.327
separation mustn't always be an issue because it is different skills.
00:07:58.327 --> 00:08:03.929
Think about the whole AI topic is much more cloud bound than it is on-prem bound.
00:08:03.929 --> 00:08:08.851
And that's where the cloud guys need to worry about permissions given to
00:08:08.851 --> 00:08:14.777
those apps, those service principles that work with AI bots, et cetera.
00:08:14.777 --> 00:08:19.382
uh It's something that the AD folks know a little about.
00:08:19.683 --> 00:08:23.007
the AD is often seen as infrastructure.
00:08:23.007 --> 00:08:25.890
And cloud is often on the security side.
00:08:25.890 --> 00:08:30.154
But as long as they work together, they still have a chance, of course.
00:08:30.703 --> 00:08:44.143
Yeah, I always say when it comes to security is that all the teams need to be in
communication with each other or you're just gonna quadruple your time if you have to
00:08:44.143 --> 00:08:50.423
recover from an event, whether it's security related or a disaster.
00:08:51.143 --> 00:08:54.683
So let's say the worst happens.
00:08:56.923 --> 00:08:58.783
What do we do?
00:08:59.669 --> 00:09:06.260
What are your thoughts if say, you know, they get cratered and they need to bring it back
up and running.
00:09:06.260 --> 00:09:12.210
mean, your thoughts, it's, definitely the first, usually the first workload that has to
be, uh, become up and running.
00:09:12.210 --> 00:09:14.103
I mean, what are you hearing out there?
00:09:15.010 --> 00:09:27.757
em The important thing is that we need to distinguish between those different types of,
let's say, challenges when we talk about uh an AD or uh even a cloud directory being
00:09:27.757 --> 00:09:28.417
attacked.
00:09:28.417 --> 00:09:30.458
Most attacks uh happen on-prem.
00:09:30.458 --> 00:09:34.481
That's just the easier path for intruders these days.
00:09:34.481 --> 00:09:44.766
Now, there are updates that Microsoft also shares for Storm 501 that use on-prem Active
Directory to move into the cloud via
00:09:45.059 --> 00:09:49.979
the sync connection that is a known path.
00:09:49.979 --> 00:09:55.999
But nonetheless, a lot of attacks that we see happen on-prem and then is it just deleted
objects?
00:09:55.999 --> 00:09:57.939
Could also be an operational mistake?
00:09:57.939 --> 00:09:59.459
Those are easy to fix.
00:09:59.459 --> 00:10:05.479
Even a domain controller that goes down Active Directory is basically fairly resilient.
00:10:05.479 --> 00:10:13.762
But the true risk and challenge that clients have is what you just hinted at, a complete
00:10:13.762 --> 00:10:22.402
take down, a complete take down of an environment, ransomware attack style, everything is
encrypted, then what are you going to do?
00:10:22.402 --> 00:10:31.342
The first thing that you have to get back is the AD forest, which is a really complicated
process if you do it manually.
00:10:31.342 --> 00:10:32.682
It's well described.
00:10:32.682 --> 00:10:39.342
Microsoft has a good forest recovery guide that I believe if you print it out, you're
talking 160 pages.
00:10:39.382 --> 00:10:40.780
It's complete.
00:10:40.780 --> 00:10:46.994
But it's complicated, 29 steps that are much manual.
00:10:46.994 --> 00:10:50.756
And that if you don't practice it, just forget it.
00:10:50.756 --> 00:10:54.198
It will neither be fast nor will it be correct.
00:10:54.198 --> 00:10:59.401
And then you're still not sure that you didn't bring malware back from the backups that
you might have taken.
00:11:00.640 --> 00:11:06.225
I think what you're getting at is, you know, identity recovery is it's definitely a
completely different challenge.
00:11:06.225 --> 00:11:10.970
um you can't just restore domain controller like a virtual machine.
00:11:10.970 --> 00:11:16.225
You know, what other things can organizations do?
00:11:16.225 --> 00:11:20.320
You know, what are they misunderstanding about identity recovery, I should say?
00:11:20.320 --> 00:11:32.321
Well, if they don't think about it more, then they miss out on understanding em what's
even realistic from a recovery perspective, from a time perspective.
00:11:32.321 --> 00:11:44.382
you're taken down, every business owner that doesn't own the whole company but might be
responsible for a particular business apps in their company has an understanding of how
00:11:44.382 --> 00:11:46.911
quick he m
00:11:46.911 --> 00:11:51.423
and his team can bring that application back running.
00:11:51.423 --> 00:12:02.277
So he has a particular recovery time objective that you might say is in minutes, because
he might fail over to another machine, or maybe hours if he brings it back from some
00:12:02.317 --> 00:12:03.457
backup.
00:12:03.457 --> 00:12:06.428
But they forget the dependency chain.
00:12:06.428 --> 00:12:08.039
They forget the dependency chain.
00:12:08.039 --> 00:12:15.846
So an RTO, after being completely wiped out, of course, is totally different baby.
00:12:15.846 --> 00:12:21.669
than a singular failure of some business application.
00:12:21.669 --> 00:12:30.354
Most companies um need to think about how long do I even have the time that my business
can survive?
00:12:30.354 --> 00:12:39.078
um then thinking in addition to that, I need to bring my active directory back in that
time, maybe four to eight hours.
00:12:39.419 --> 00:12:45.088
That doesn't match nicely to the capabilities of
00:12:45.088 --> 00:12:48.064
you know, doing a uh manual recovery.
00:12:48.064 --> 00:12:57.800
So for a uh proper RTO, recovery of an AD forest can hardly be met without proper tool
that automates this whole process.
00:12:57.913 --> 00:13:03.593
So, mean, does it, that begs the question, are most recovery time objectives for identity
even realistic?
00:13:04.288 --> 00:13:12.903
Well, that's, that's, I think is something that, that companies that don't prepare upfront
will be hard pressed to find out that they're never realistic.
00:13:12.903 --> 00:13:13.283
Yeah.
00:13:13.283 --> 00:13:18.686
You need to practice even if you do it manual, I'm not totally against manual processes.
00:13:18.776 --> 00:13:22.388
um, but then, then you can't keep an RTO that's very short.
00:13:22.388 --> 00:13:33.326
Then you'll need to just accept, okay, we're going to have to deal with two, three, four
days of our outage because companies, once they get into this, they realize.
00:13:33.326 --> 00:13:36.968
that um without identity, nothing works.
00:13:36.968 --> 00:13:42.451
So I can't even continue the recovery of my other applications if I don't have my
identity.
00:13:42.492 --> 00:13:43.752
Exactly, exactly.
00:13:43.752 --> 00:13:45.844
Very often that's exactly the case.
00:13:45.844 --> 00:13:46.824
Exactly.
00:13:47.065 --> 00:13:57.349
So if Zero Town Time is the goal, what does true identity resilience look like before an
attack even ever happens?
00:13:58.113 --> 00:14:02.985
You know, Jed, I would say this is actually for any crisis.
00:14:03.165 --> 00:14:09.308
In a ransomware attack, like the one that we're sort of discussing, belongs totally into
this category.
00:14:09.308 --> 00:14:13.929
You want to spend a good amount of time to prepare upfront.
00:14:13.929 --> 00:14:24.454
uh Understand your most critical business apps and who operates them so you have an idea
um what you must concentrate on uh after you've been hit.
00:14:24.454 --> 00:14:25.824
And then consider
00:14:25.824 --> 00:14:28.596
the dependencies of those critical apps.
00:14:28.596 --> 00:14:31.198
What dependencies do they have?
00:14:31.198 --> 00:14:37.562
Where you find that most of your on-prem apps, you'll need to ensure that your AD is
operational.
00:14:37.562 --> 00:14:42.415
And then, of course, in parallel to that, name resolution, DNS, must work.
00:14:42.415 --> 00:14:44.316
And of course, you have to have network and machines.
00:14:44.316 --> 00:14:47.568
And all of those dependencies must be understood.
00:14:47.568 --> 00:14:50.818
And soon, you will have that defined.
00:14:50.818 --> 00:14:56.621
uh basis of your so-called minimal viable company.
00:14:56.841 --> 00:15:06.177
Of course, you want to do the same for your most critical cloud applications, understand
their dependencies and understand your backups.
00:15:06.177 --> 00:15:08.068
Where are they actually located?
00:15:08.068 --> 00:15:11.550
Because uh an on-prem backup is the first thing.
00:15:11.550 --> 00:15:19.314
If it's not well protected, and I know you guys have some cool solutions to protect it,
then that'll be the first thing that attackers take out.
00:15:19.599 --> 00:15:32.887
oh One of our oldest taglines is know your data, And what is, right, that means know where
it is, uh know how it's being backed up, what your retention is, all that other good
00:15:32.887 --> 00:15:33.397
stuff, right?
00:15:33.397 --> 00:15:35.458
Do you have three, two, one, right?
00:15:35.458 --> 00:15:39.250
Do you have multiple copies in different regions and all that other good stuff?
00:15:39.271 --> 00:15:39.735
So.
00:15:39.735 --> 00:15:41.935
doesn't go away for your identity backups either.
00:15:41.935 --> 00:15:43.515
No, does not.
00:15:43.515 --> 00:15:44.855
It absolutely does not.
00:15:45.435 --> 00:15:48.015
So, you know, kind of pivoting just a tad.
00:15:48.495 --> 00:15:50.535
You know, what are you seeing in the field?
00:15:50.535 --> 00:15:59.751
Like what identity-based attacks trends should, you know, security leaders and C-suite and
all those other folks, what should they be paying attention to this year?
00:16:00.577 --> 00:16:06.092
We've seen a lot in the wild and we're doing security assessments for many clients, large
and small.
00:16:06.092 --> 00:16:13.648
And I would definitely check out the vulnerabilities on my own certificate services if
they are AD integrated.
00:16:13.648 --> 00:16:17.942
That's a very common setup in many companies, AD integrated certificate services.
00:16:17.942 --> 00:16:21.345
uh No extra costs, et cetera.
00:16:21.345 --> 00:16:28.370
But in those, for example, you have over-missive settings in your certificate templates
that make you vulnerable.
00:16:28.380 --> 00:16:32.833
And they often go unnoticed and they're not really too difficult to fix.
00:16:32.833 --> 00:16:40.483
And there's three tools such as Locksmith or Purple Knight that help you fix them or not
fix them, but find them.
00:16:40.483 --> 00:16:51.323
Actually, Locksmith also has some cool features to fixing settings, although people always
should look uh at what's necessary for the fix and understand it.
00:16:51.423 --> 00:16:54.755
And let me just add to that, did I already mention tearing?
00:16:54.755 --> 00:16:56.406
Yeah, tearing.
00:16:56.406 --> 00:17:00.466
being one of the most important things to take care of.
00:17:01.036 --> 00:17:08.722
Now remind me in the audience, Purple Night, um even though that's your tool, it's a free
tool, right?
00:17:09.343 --> 00:17:10.424
Yeah.
00:17:10.424 --> 00:17:18.420
it, regardless if it's from some Paris, you know, it's used some kind of tool to identify,
you know, those vulnerabilities.
00:17:18.420 --> 00:17:19.730
Absolutely, absolutely.
00:17:19.730 --> 00:17:27.676
There's others, there's Pink Castle, there's good tools out there that people should be
utilizing much better than not using anything.
00:17:28.183 --> 00:17:36.919
So are attackers getting quieter or more patient, embedding persistence inside, AD instead
of like going loud?
00:17:39.082 --> 00:17:43.265
That's a difficult em one to sort of give a universal answer to.
00:17:43.265 --> 00:17:48.649
em We've seen, yeah, because we've seen both things.
00:17:48.649 --> 00:17:49.720
Jed, we've seen both things.
00:17:49.720 --> 00:18:01.518
There's the silent ones that do long reconnaissance before they either destroy or simply
gather the intelligence needed to spy on you for whatever development a company might be
00:18:01.518 --> 00:18:01.869
up to.
00:18:01.869 --> 00:18:04.980
I've seen this with turbines.
00:18:06.935 --> 00:18:14.228
developed in Germany and then rebuilt with plans that were stolen in, let's just say,
another country.
00:18:14.228 --> 00:18:17.824
I don't want to highlight any specific here.
00:18:17.824 --> 00:18:18.444
Exactly.
00:18:18.444 --> 00:18:25.089
em But there's also the class of those actors that are more or less fast and furious.
00:18:25.089 --> 00:18:30.033
They start their destruction as soon as they get the necessary privileges.
00:18:30.033 --> 00:18:36.617
But em what we've seen in attacks, and we've been involved in quite a few incident
responses to help clients
00:18:36.770 --> 00:18:42.990
revive them, is that the attackers, in any case, try to persist in AD.
00:18:42.990 --> 00:18:55.190
Be it just a single additional account that they add and add to a privileged group, it is
something that you have to take care of as you're, let's say, during or after the breach
00:18:55.190 --> 00:18:56.430
situation.
00:18:56.550 --> 00:19:06.006
And in the worst case, if you recover from your backups, that might still be that
compromised configuration in AD that you do need to fix.
00:19:06.006 --> 00:19:09.468
That's also something that is important to remember.
00:19:09.975 --> 00:19:20.237
Yeah, and identity attacks now happening, I mean, are they happening earlier in the kill
chain or than they were a few years ago?
00:19:21.022 --> 00:19:24.483
I wouldn't really say so that they're earlier.
00:19:25.464 --> 00:19:30.226
The typical attacker still gets into your environment as just a normal user.
00:19:30.267 --> 00:19:38.371
And it's just an employee uh that opens the wrong mail attachment or clicks on the wrong
link.
00:19:38.371 --> 00:19:44.919
uh The attacker then uh is that user in an identity, and that's normally.
00:19:44.919 --> 00:19:51.583
mean, not an admin, that would be like the jackpot if an admin were to click that link,
and then the attackers are really happy.
00:19:51.583 --> 00:19:52.143
Yeah.
00:19:52.143 --> 00:19:58.027
So, but em usually the attacker is just a normal user, that means a non-privileged user.
00:19:58.027 --> 00:20:07.659
And then he walks up that kill chain by first gaining local admin privileges, system
privileges through weaknesses on the box that he's running on.
00:20:07.659 --> 00:20:12.023
And then, you know, taking the kill chain by reconnaissance in AD.
00:20:12.023 --> 00:20:20.165
which unfortunately is extremely easy because Active Directory is open like a barn door
when it comes to read permissions.
00:20:20.165 --> 00:20:26.246
Everybody can read everything unless you've locked it down a lot.
00:20:26.246 --> 00:20:27.967
And that means also your weaknesses.
00:20:27.967 --> 00:20:32.788
So um the weakness that you find, the attacker will also find.
00:20:32.788 --> 00:20:35.109
So it's up to you to close that.
00:20:35.109 --> 00:20:41.510
Let me add one more thing because I would have to say there's of course that other type of
attack that has
00:20:41.942 --> 00:20:54.311
I'm not sure to say increased, but we've certainly noticed some big hits here where you
can just buy uh credentials, stolen credentials, hacked credentials on the dark weather.
00:20:54.311 --> 00:20:55.932
They're not expensive.
00:20:55.972 --> 00:20:59.295
I've never tried it, but I've read a lot about it.
00:20:59.295 --> 00:21:01.116
They're not expensive to get.
00:21:01.116 --> 00:21:09.324
And then if you do your homework to understand, what's that user's name, whose credentials
I have here, and you bound it,
00:21:09.324 --> 00:21:16.798
to maybe the company that the guy works on through social engineering and scavenging
LinkedIn, Facebook, and whatnot.
00:21:16.798 --> 00:21:22.081
You find out this guy works at Colonial Pipeline and he's actually an IT staff.
00:21:22.221 --> 00:21:34.308
Hey, I found in Colonial Pipeline, this example, unfortunately true, had an um
internet-facing unprotected remote access client.
00:21:34.308 --> 00:21:35.488
no MFA.
00:21:35.488 --> 00:21:37.069
The credentials were.
00:21:37.209 --> 00:21:38.530
Attacker was in.
00:21:38.850 --> 00:21:43.850
That's a very early identity attack of that type.
00:21:44.234 --> 00:21:46.097
So that actually is a good segue.
00:21:46.097 --> 00:21:57.014
So if we were to make this actionable, if you had to prioritize like three things an
organization should do this year to strengthen their identity resilience, what would they
00:21:57.014 --> 00:21:58.055
be in your mind?
00:22:00.404 --> 00:22:06.573
Yeah, I would say first to really get a better understanding of your own identity.
00:22:06.573 --> 00:22:07.880
all your passwords.
00:22:11.830 --> 00:22:13.291
No, truly.
00:22:13.371 --> 00:22:21.931
Get a better start with getting a better understanding of your own identity security
posture and maybe change all those passwords.
00:22:22.051 --> 00:22:28.491
But the free tools out there, we mentioned Purple Knight, Ping Castle, Locksmiths on the
certificate side.
00:22:28.491 --> 00:22:39.060
There's plenty of powerful free tools out there that give you a proper security score and
list the most critical issues that you should at least become aware of.
00:22:39.060 --> 00:22:47.414
Ideally, take some uh homework from and discuss in your teams, be it cloud, be it on-prem,
like, what should we do better?
00:22:47.875 --> 00:22:59.161
Second, in the context of what we've discussed, I really think that companies need to
think broader about the whole cyber resilience topic, not just try to protect as much as
00:22:59.161 --> 00:23:04.124
they can, but understand, how do I actually really prepare for the worst?
00:23:04.204 --> 00:23:07.498
And that means uh a true crisis.
00:23:07.498 --> 00:23:12.901
I we all do backups all the time, but what is it if I actually need to utilize them all at
once?
00:23:13.601 --> 00:23:16.103
You've been wiped out.
00:23:16.103 --> 00:23:29.570
And those that prepare and practice their crisis management processes and related tooling
are much better at surviving a cyber crisis than those that are hit unprepared.
00:23:29.570 --> 00:23:31.851
And I like to always compare that.
00:23:31.851 --> 00:23:36.614
em Like, when would you prefer to fall into a lake?
00:23:36.614 --> 00:23:39.836
after you've already learned to swim or before.
00:23:39.836 --> 00:23:43.879
So you want to learn to swim before you're hit.
00:23:44.259 --> 00:23:57.288
And then third, I'd actually take that cyber resilience step uh one step further and do
think about a minimum viable company and discuss how to operate such a model in your
00:23:57.288 --> 00:23:57.999
context.
00:23:57.999 --> 00:24:06.006
That takes too much for this podcast, but it is definitely taking up speed that companies
understand.
00:24:06.006 --> 00:24:08.315
This is something we should look at.
00:24:08.503 --> 00:24:12.326
Yeah, have a plan, have it written down, test that planned.
00:24:12.326 --> 00:24:15.188
That way you're prepared in case there is an event, right?
00:24:15.188 --> 00:24:29.139
So now for someone listening, um if they can only do one thing next quarter to really
reduce their risk, what should it be in your
00:24:30.550 --> 00:24:36.897
It really never hurts to focus on the first point I mentioned, understanding your identity
security posture.
00:24:36.897 --> 00:24:46.406
That's what also the attacker will check when they are inside your environment and check
for your weakest links and ideally do something about it.
00:24:46.506 --> 00:24:49.620
And uh did I mention tiering?
00:24:49.855 --> 00:24:53.458
Yeah, that's the new buzzword, right?
00:24:53.458 --> 00:24:55.839
So that's awesome.
00:24:56.701 --> 00:25:01.414
So I think the big takeaway here is identity isn't just infrastructure, right?
00:25:01.414 --> 00:25:03.536
It's, it's operational continuity.
00:25:03.536 --> 00:25:06.662
You know, if it fails, everything feels that you can't log in.
00:25:06.662 --> 00:25:09.010
You can't get in the building sometimes, right?
00:25:09.131 --> 00:25:11.653
So zero, zero downtime.
00:25:11.653 --> 00:25:14.475
It's not about avoiding the attack entirely, right?
00:25:14.475 --> 00:25:19.321
It's about being prepared and having the ability to recover cleanly.
00:25:19.321 --> 00:25:21.742
confidently and definitely without chaos, right?
00:25:21.742 --> 00:25:24.213
That's where that communication comes into play.
00:25:24.233 --> 00:25:26.695
So Guido, thank you for the insight.
00:25:26.695 --> 00:25:31.617
This was a great deep dive and definitely an important one these days.
00:25:31.797 --> 00:25:36.329
I want to thank everyone for tuning into Zero Downtime and we'll see you next time.
