WEBVTT

00:00:11.259 --> 00:00:13.980
Hello everybody and welcome back to another episode

00:00:13.980 --> 00:00:16.480
of the Everyday Defender podcast. My name is

00:00:16.480 --> 00:00:19.100
Koos and I'm joined here once again with my friend

00:00:19.100 --> 00:00:21.660
from Down Under, Chris. Hi Chris, how are you

00:00:21.660 --> 00:00:25.699
doing? Hey Koos, great to see you man. It's always

00:00:25.699 --> 00:00:27.280
great. It's like my favorite part of the month

00:00:27.280 --> 00:00:30.000
when I get to sit down and do this recording

00:00:30.000 --> 00:00:32.420
with you. So yeah, great to see you. Well, from

00:00:32.420 --> 00:00:34.100
the looks of it, you're not in Sydney right now,

00:00:34.100 --> 00:00:37.320
right? Yeah, no, I'm not in my regular dungeon.

00:00:37.960 --> 00:00:41.179
I'm actually in Brisbane at the moment. So just

00:00:41.179 --> 00:00:43.840
a little bit up the north coast of Australia.

00:00:44.000 --> 00:00:46.719
Well, I guess north from Sydney, up the coast.

00:00:47.159 --> 00:00:50.159
And yeah, I'm working with a customer over here

00:00:50.159 --> 00:00:53.840
for the week. So I didn't want to stall or delay

00:00:53.840 --> 00:00:57.060
the recording. So I've got a little makeshift.

00:00:57.579 --> 00:00:59.960
uh recording studio here with like the furniture

00:00:59.960 --> 00:01:01.939
being rearranged and whatnot so that i could

00:01:01.939 --> 00:01:04.480
actually sit down and have some sort of decent

00:01:04.480 --> 00:01:07.340
light yeah yeah that's right i was hoping for

00:01:07.340 --> 00:01:09.219
a little bit more hoping for some more sunshine

00:01:09.219 --> 00:01:11.359
as well but uh for some reason it just started

00:01:11.359 --> 00:01:12.980
raining this afternoon so that's why it's also

00:01:12.980 --> 00:01:16.060
like dark but hey what can you do well at least

00:01:16.060 --> 00:01:17.980
you don't have snow over there in wintertime

00:01:17.980 --> 00:01:20.840
so uh here it's much worse well we have a nice

00:01:20.840 --> 00:01:24.219
summer still actually yeah you guys have been

00:01:24.219 --> 00:01:25.540
having some pretty good weather over there in

00:01:25.540 --> 00:01:28.459
europe i think Yeah, yeah. Well, it's a little

00:01:28.459 --> 00:01:31.500
bit too good at some places. We had some very

00:01:31.500 --> 00:01:34.579
high heat. And even in the south of Europe, there

00:01:34.579 --> 00:01:37.780
are some problems with some fires going on in

00:01:37.780 --> 00:01:41.719
forests and everything. So that's not very good.

00:01:41.780 --> 00:01:44.219
So it's very hot in the south, over 40 degrees,

00:01:44.439 --> 00:01:47.920
45 degrees or something like that. MVP Renewal

00:01:47.920 --> 00:01:50.420
Week obviously was last week. Sorry, everybody,

00:01:50.480 --> 00:01:53.099
for your LinkedIn feed being spammed with all

00:01:53.099 --> 00:01:56.859
the updates. And to my surprise, I gained an

00:01:56.859 --> 00:01:59.079
additional category, which is the Identity in

00:01:59.079 --> 00:02:02.060
Access category. So apparently I talked way too

00:02:02.060 --> 00:02:05.159
much about Entra and Passkeys in the past. So

00:02:05.159 --> 00:02:07.879
Microsoft awarded me a second category. And well,

00:02:07.959 --> 00:02:10.000
I thought, let's stick to it. Let's talk about

00:02:10.000 --> 00:02:14.810
Entra ID, B2C and External ID today. since I

00:02:14.810 --> 00:02:16.830
was working with that recently for a client.

00:02:16.969 --> 00:02:18.789
And you, Chris, you're going to talk about patch

00:02:18.789 --> 00:02:21.449
management, am I right? Yeah, patch management.

00:02:21.569 --> 00:02:23.569
But yeah, firstly, congrats on the renewal, mate.

00:02:23.689 --> 00:02:28.629
I do firmly believe that you are one of the most

00:02:28.629 --> 00:02:30.710
deserving MVPs in the community. You really do

00:02:30.710 --> 00:02:34.289
work very, very hard for those renewals. So congrats

00:02:34.289 --> 00:02:37.870
on that coming through. for you. Talking about

00:02:37.870 --> 00:02:39.590
patch management and vulnerability management

00:02:39.590 --> 00:02:41.830
and all this stuff, I think it's very topical

00:02:41.830 --> 00:02:43.849
at the moment. There's obviously a lot going

00:02:43.849 --> 00:02:46.590
on when it comes to patching and patches and

00:02:46.590 --> 00:02:50.110
we've been saying for a while to everyone, patch

00:02:50.110 --> 00:02:53.530
your stuff. But I wanted to break into some of

00:02:53.530 --> 00:02:55.210
the nuances of that and some of the confusion

00:02:55.210 --> 00:02:58.030
that I see. Something I've been working on myself

00:02:58.030 --> 00:03:00.650
with my current customer a fair bit as well.

00:03:01.409 --> 00:03:03.550
Hopefully it'll be a fun topic. It's going to

00:03:03.550 --> 00:03:06.879
be a little bit more theory today. When I was

00:03:06.879 --> 00:03:10.039
putting the notes together for this, I realized

00:03:10.039 --> 00:03:11.879
that there's so much you could dig into when

00:03:11.879 --> 00:03:13.780
you start talking about the technology and everything

00:03:13.780 --> 00:03:16.860
behind it. So I figured today we'll just sort

00:03:16.860 --> 00:03:19.699
of crack it open and just talk a little bit about

00:03:19.699 --> 00:03:25.740
the theory and define what we're talking about.

00:03:25.960 --> 00:03:29.020
And then possibly as a follow -on or a part two,

00:03:29.099 --> 00:03:31.479
we'll dig into maybe the tech and the technology

00:03:31.479 --> 00:03:35.689
behind it. So watch the space. Already a little

00:03:35.689 --> 00:03:37.530
bit of a spoiler going on there. Well, it's an

00:03:37.530 --> 00:03:40.490
important topic and I think underlooked very

00:03:40.490 --> 00:03:45.409
much still in practice. Yes, definitely. Yeah,

00:03:45.449 --> 00:03:49.110
so I recently had to help a customer get their

00:03:49.110 --> 00:03:52.530
Entra ID B2C, business to consumer tenant, connected

00:03:52.530 --> 00:03:57.370
to our SOC, actually. And I knew what a B2C was

00:03:57.370 --> 00:04:02.020
and where it lived when I did my... Azure exams

00:04:02.020 --> 00:04:05.000
in the early days, for example. But I never really

00:04:05.000 --> 00:04:08.479
needed to interact with it before. And now I

00:04:08.479 --> 00:04:10.319
needed to look into how I'm going to connect

00:04:10.319 --> 00:04:13.259
it to the SOC. And I discovered that B2C was

00:04:13.259 --> 00:04:16.899
also now replaced by external ID, different product

00:04:16.899 --> 00:04:20.480
name. And I thought it was a good idea because

00:04:20.480 --> 00:04:23.759
I found some challenges. It's a little bit finicky

00:04:23.759 --> 00:04:26.300
here and there, setting things up. There are

00:04:26.300 --> 00:04:30.819
some pros and cons to each. So I thought it would

00:04:30.819 --> 00:04:33.959
be an interesting topic to bring along for today's

00:04:33.959 --> 00:04:40.360
episode. So first of all, what is B2C? If people

00:04:40.360 --> 00:04:43.259
do not know it, it's what Microsoft called Customer

00:04:43.259 --> 00:04:46.560
Identity and Access Management Platform or CM.

00:04:48.040 --> 00:04:51.319
This is introduced in 2016 already. So it is

00:04:51.319 --> 00:04:54.480
old. So it was part of my early Azure exams,

00:04:54.639 --> 00:04:57.230
I guess, back in the day. And it's meant for

00:04:57.230 --> 00:05:00.189
identities outside of your organization. So your

00:05:00.189 --> 00:05:03.389
customers signing into your web shop, perhaps

00:05:03.389 --> 00:05:07.670
if you're running some government services, maybe

00:05:07.670 --> 00:05:10.490
perhaps even citizens using some government portal

00:05:10.490 --> 00:05:13.629
or partners using your applications, that kind

00:05:13.629 --> 00:05:15.709
of thing. So identities you don't want to...

00:05:16.040 --> 00:05:19.439
bring into your workforce tenant for your employees

00:05:19.439 --> 00:05:22.579
and want to separate off in a separate container,

00:05:22.759 --> 00:05:25.819
so to speak. And in the past, it was even possible

00:05:25.819 --> 00:05:28.319
to connect third -party services like Google

00:05:28.319 --> 00:05:30.939
and LinkedIn and Facebook so people could bring

00:05:30.939 --> 00:05:33.879
in their own virtual identities and authenticate

00:05:33.879 --> 00:05:37.139
to your application, et cetera. And then Microsoft

00:05:37.139 --> 00:05:41.939
introduced in 2023 the next generation of B2C.

00:05:42.040 --> 00:05:45.180
And that's when they called it external ID. They

00:05:45.180 --> 00:05:48.959
did not rename B2C. It was actually a new product

00:05:48.959 --> 00:05:53.279
introduced in 2023. And I believe it became general

00:05:53.279 --> 00:05:56.579
available in 2024, I believe, from the top of

00:05:56.579 --> 00:06:03.339
my head. So for the B2C scenario. Just like B2C,

00:06:03.399 --> 00:06:06.519
you create an external tenant. So B2C went a

00:06:06.519 --> 00:06:09.120
little bit differently, but the external ID has

00:06:09.120 --> 00:06:13.579
a very similar look and feel. to what you're

00:06:13.579 --> 00:06:16.319
used to with the Entra portal, with the Entra

00:06:16.319 --> 00:06:19.199
page. So it looks like an additional tenant in

00:06:19.199 --> 00:06:21.519
your organization, but since it's an external

00:06:21.519 --> 00:06:24.259
tenant instead of a workforce tenant, there are

00:06:24.259 --> 00:06:27.279
some buttons which do not work and there are

00:06:27.279 --> 00:06:31.019
some limitations, and that is where the finicky

00:06:31.019 --> 00:06:34.779
part gets in as well. Have you worked with B2C,

00:06:34.800 --> 00:06:39.069
Chris, or XRID? Yeah, I've worked with BTC back

00:06:39.069 --> 00:06:41.329
in the day. I did some work with the scenario

00:06:41.329 --> 00:06:43.569
that we worked on was with a school, right? So

00:06:43.569 --> 00:06:46.550
they had a directory, their intro was, which

00:06:46.550 --> 00:06:48.529
is where their sort of faculty or the teachers

00:06:48.529 --> 00:06:51.129
and students lived. And then they also needed.

00:06:51.439 --> 00:06:53.160
identities for the parents so the parents would

00:06:53.160 --> 00:06:56.560
live in the b2c tenant um yeah it was complicated

00:06:56.560 --> 00:06:59.040
stuff man just even provisioning and all of those

00:06:59.040 --> 00:07:01.139
workflows you had to really write a lot of your

00:07:01.139 --> 00:07:04.019
own or customize your own stuff there there wasn't

00:07:04.019 --> 00:07:06.980
a lot of stuff out of the out of the box so i've

00:07:06.980 --> 00:07:09.000
not worked with the external id part of it or

00:07:09.000 --> 00:07:12.000
the new version of it so keen to keep to hear

00:07:12.000 --> 00:07:14.139
your findings here and you know what you come

00:07:14.139 --> 00:07:17.980
up with Yeah, so since I have a lot of discussions

00:07:17.980 --> 00:07:20.920
with clients who want to onboard our manage detection

00:07:20.920 --> 00:07:23.579
and response services, and they come up with

00:07:23.579 --> 00:07:25.819
all kinds of things that are important to them,

00:07:25.899 --> 00:07:28.560
and they want to bring them into our services.

00:07:28.720 --> 00:07:31.240
And sometimes we have to figure out some custom

00:07:31.240 --> 00:07:34.319
lock ingestion stuff for it. But it was actually

00:07:34.319 --> 00:07:37.060
the first time a large customer came with a B2C

00:07:37.060 --> 00:07:39.860
offering to us and wanted to connect that as

00:07:39.860 --> 00:07:42.300
well. And it makes sense, right, in theory, because

00:07:42.300 --> 00:07:45.370
the tenant handles sign -ins. to their customer

00:07:45.370 --> 00:07:47.889
-facing applications. So if somebody's trying

00:07:47.889 --> 00:07:51.129
to abuse accounts over there or, I don't know,

00:07:51.250 --> 00:07:54.470
reset a password or something, you want to know

00:07:54.470 --> 00:07:57.670
of this in the SOC. So it makes sense from a

00:07:57.670 --> 00:08:00.810
security standpoint that the customer is really

00:08:00.810 --> 00:08:03.449
wanting to protect the identity part of their

00:08:03.449 --> 00:08:06.860
application. The problem with B2C, however, is,

00:08:07.000 --> 00:08:09.399
well, first of all, I cannot enroll it anymore.

00:08:09.620 --> 00:08:12.620
So when I first heard about this, I was like,

00:08:12.720 --> 00:08:14.920
okay, let's set it up and try to figure out how

00:08:14.920 --> 00:08:17.339
it all works. You cannot do that anymore. Since

00:08:17.339 --> 00:08:21.860
external ID has replaced it, B2C is still working.

00:08:22.680 --> 00:08:25.879
And I believe it is retiring. Yeah, the support

00:08:25.879 --> 00:08:30.850
will be there until 2030. Customers running B2C

00:08:30.850 --> 00:08:33.429
still have some time, but eventually they need

00:08:33.429 --> 00:08:36.529
to migrate to external ID. But the problem is

00:08:36.529 --> 00:08:38.690
with this customer, they weren't able to migrate

00:08:38.690 --> 00:08:41.950
just yet due to some custom workflow stuff going

00:08:41.950 --> 00:08:44.889
on. More on that later. So they asked me, well,

00:08:44.950 --> 00:08:47.470
we're sticking with B2C for now, so just see

00:08:47.470 --> 00:08:50.269
if we can make it happen. But another problem

00:08:50.269 --> 00:08:53.149
was with B2C is that Microsoft recently stripped,

00:08:53.289 --> 00:08:56.009
actually recently in March this year, stripped

00:08:56.009 --> 00:08:59.159
a lot of the security features out of B2C. So

00:08:59.159 --> 00:09:02.639
in the past, your B2C environment was protected,

00:09:02.840 --> 00:09:06.080
could be protected with P2 security features,

00:09:06.220 --> 00:09:09.019
just like your workforce tenant. So all of the

00:09:09.019 --> 00:09:11.679
identity protection features were there, but

00:09:11.679 --> 00:09:15.779
Microsoft stripped them down in March to, I don't

00:09:15.779 --> 00:09:19.240
know, maybe even force companies to migrate to

00:09:19.240 --> 00:09:22.220
external ID eventually. But the thing is, because

00:09:22.220 --> 00:09:25.139
you don't have any insights like the risky users,

00:09:25.320 --> 00:09:28.590
risky sign -ins, for example, and... in conjunction

00:09:28.590 --> 00:09:32.090
with conditional access you could say if a user

00:09:32.090 --> 00:09:35.269
appears to be risky based on microsoft telemetry

00:09:35.269 --> 00:09:37.289
and everything you could determine if the user

00:09:37.289 --> 00:09:39.409
is risky we don't want to allow them on the application

00:09:39.409 --> 00:09:42.190
for example you can do that any longer because

00:09:42.190 --> 00:09:45.929
the features were stripped down so i looked into

00:09:45.929 --> 00:09:48.850
this and yes you can connect your sign -in logs

00:09:48.850 --> 00:09:52.350
and audit logs from b2c to sentinel and then

00:09:52.350 --> 00:09:56.370
you can create some kind of detections um but

00:09:57.039 --> 00:09:59.779
Obviously, with KQL queries, you aren't able

00:09:59.779 --> 00:10:02.460
to replicate the full set of identity protection

00:10:02.460 --> 00:10:05.659
functionality. So the added security benefit

00:10:05.659 --> 00:10:08.860
is relatively slim, in my opinion. So, yeah,

00:10:08.980 --> 00:10:11.240
so I had a discussion with a customer about this.

00:10:11.820 --> 00:10:14.799
It might be interesting anyway to do at least

00:10:14.799 --> 00:10:18.960
do some form of identity -based use cases on

00:10:18.960 --> 00:10:21.700
those logs from B2C. But eventually, I would

00:10:21.700 --> 00:10:24.500
always advise to look into the path of migrating

00:10:24.500 --> 00:10:29.090
to external ID. The thing is, however, external

00:10:29.090 --> 00:10:33.490
ID looks like the successor of B2C. So I was

00:10:33.490 --> 00:10:36.230
actually assuming that all the P2 security features

00:10:36.230 --> 00:10:39.669
were back and live again in external ID. But

00:10:39.669 --> 00:10:41.649
that's not the full story, unfortunately. So

00:10:41.649 --> 00:10:43.730
Microsoft did bring a lot of security features

00:10:43.730 --> 00:10:46.210
in external ID. So now you can also leverage

00:10:46.210 --> 00:10:49.029
passkeys, for example, which is obviously a great

00:10:49.029 --> 00:10:54.379
addition. But the risk state, the risk determination,

00:10:54.740 --> 00:10:57.159
the identity protection stuff, it's still not

00:10:57.159 --> 00:10:59.679
there. So it's still stripped. And well, I'm

00:10:59.679 --> 00:11:01.759
not sure if it's coming back eventually. It doesn't

00:11:01.759 --> 00:11:04.559
look like it. So that's actually a shame. So

00:11:04.559 --> 00:11:06.980
that was actually a very powerful thing you can

00:11:06.980 --> 00:11:11.129
do. But like I said with pass keys and a conditional

00:11:11.129 --> 00:11:13.970
access you can even enforce some very strict

00:11:13.970 --> 00:11:19.190
MFA to your external ID users much more so that

00:11:19.190 --> 00:11:25.450
you could do with B2C. Let me see. So the only

00:11:25.450 --> 00:11:30.350
thing I encountered next is when you wanted to

00:11:30.350 --> 00:11:34.269
connect the logs from B2C or external ID it works

00:11:34.269 --> 00:11:37.769
the same matter actually. You have to connect

00:11:37.769 --> 00:11:41.350
your diagnostic settings to a Log Analytics workspace

00:11:41.350 --> 00:11:44.730
running Sentinel. But the thing is a B2C or an

00:11:44.730 --> 00:11:48.230
external ID tenant cannot have an Azure subscription

00:11:48.230 --> 00:11:50.870
attached to it. So that external tenant is a

00:11:50.870 --> 00:11:53.009
separate entity. You can actually go into the

00:11:53.009 --> 00:11:55.009
tenant switcher in your Azure portal or your

00:11:55.009 --> 00:11:57.970
Entra portal and switch to the external ID tenant.

00:11:58.149 --> 00:11:59.990
But from there, you're unable to connect any

00:11:59.990 --> 00:12:02.629
Azure subscription. So you wouldn't be able to

00:12:02.629 --> 00:12:06.129
deploy a Log Analytics workspace to select. as

00:12:06.129 --> 00:12:09.090
a target for the logs. And the way Microsoft

00:12:09.090 --> 00:12:12.110
worked around this is by leveraging Azure Lighthouse.

00:12:12.269 --> 00:12:14.309
I'm not sure if you're familiar with that, Chris,

00:12:14.470 --> 00:12:17.379
Azure Lighthouse. Yeah, so... We use this as

00:12:17.379 --> 00:12:20.580
well in our services where you delegate permissions

00:12:20.580 --> 00:12:24.019
from one tenant on Azure resources in another

00:12:24.019 --> 00:12:27.240
tenant. So Microsoft leverages Azure Lighthouse

00:12:27.240 --> 00:12:29.620
as part of an onboarding wizard. So when you

00:12:29.620 --> 00:12:32.659
go into the external ID tenant for the first

00:12:32.659 --> 00:12:35.259
time, you're greeted with a wizard asking you

00:12:35.259 --> 00:12:37.080
to set up a couple of things. So one of the things

00:12:37.080 --> 00:12:40.000
it asks if you want to send some logs somewhere.

00:12:40.399 --> 00:12:43.740
And when you just go through that wizard. you'll

00:12:43.740 --> 00:12:47.019
eventually encounter an option to send it to

00:12:47.019 --> 00:12:49.460
log analytics workspace. It will automatically

00:12:49.460 --> 00:12:52.200
provision a resource group, a workspace, and

00:12:52.200 --> 00:12:54.360
the Azure Lighthouse delegation to get access

00:12:54.360 --> 00:12:56.860
on that to store the logs. But it all happens

00:12:56.860 --> 00:12:59.399
in one sweep. And in the end, yeah, you have

00:12:59.399 --> 00:13:02.100
a separate workspace. But in my case, I wanted

00:13:02.100 --> 00:13:05.960
to use an existing workspace already containing

00:13:05.960 --> 00:13:08.340
my analytic rules and my other sign -in logs.

00:13:08.620 --> 00:13:10.879
And it wasn't an option to do that because obviously

00:13:10.879 --> 00:13:13.139
in the pull down menu, I couldn't select any

00:13:13.139 --> 00:13:15.700
other workspaces because they weren't there and

00:13:15.700 --> 00:13:18.340
there was no delegation set up to the other resource

00:13:18.340 --> 00:13:21.299
groups. So when people encountering this and

00:13:21.299 --> 00:13:24.059
hearing this, you have to set up an Azure Lighthouse

00:13:24.059 --> 00:13:27.000
delegation beforehand or afterwards manually

00:13:27.000 --> 00:13:31.240
and delegate permissions to your resource group

00:13:31.240 --> 00:13:33.919
containing your Sentinel workspace. with the

00:13:33.919 --> 00:13:36.539
external ID tenant. And then when you go into

00:13:36.539 --> 00:13:38.820
the wizard, then you can actually select that

00:13:38.820 --> 00:13:41.440
existing workspace from the pull -down menu and

00:13:41.440 --> 00:13:43.740
it will skip all the other steps. The thing is,

00:13:43.759 --> 00:13:47.100
however, if you completed the wizard, I had a

00:13:47.100 --> 00:13:50.220
very hard time to find that wizard again. For

00:13:50.220 --> 00:13:52.700
some reason, it's buried somewhere in the menu.

00:13:52.840 --> 00:13:54.779
So I put it in the show notes where you can find

00:13:54.779 --> 00:13:57.740
it. So it took me a while to figure that out

00:13:57.740 --> 00:14:00.759
since I already completed it the first time and

00:14:00.759 --> 00:14:03.629
then wanted to correct it afterwards. I made

00:14:03.629 --> 00:14:05.629
things a little bit harder. So that's why I thought

00:14:05.629 --> 00:14:08.629
I'd bring it up this week. And then eventually

00:14:08.629 --> 00:14:10.669
when you have your logs, your sign -in logs and

00:14:10.669 --> 00:14:12.769
your audit logs into Sentinel, they look very

00:14:12.769 --> 00:14:15.490
similar to the things you're used to from your

00:14:15.490 --> 00:14:19.990
workforce tenant. And you can apply detections

00:14:19.990 --> 00:14:22.850
on that, like maybe some brute force attempts

00:14:22.850 --> 00:14:26.409
or maybe some MFA abuse or maybe some changes

00:14:26.409 --> 00:14:30.740
to accounts being done. But again, it's still

00:14:30.740 --> 00:14:35.220
not P2 identity protection. So I think you still

00:14:35.220 --> 00:14:37.779
should also look into enforcing pass keys or

00:14:37.779 --> 00:14:41.179
some proper MFA for those external users as well.

00:14:42.820 --> 00:14:46.720
However, the problem, however, migrating from

00:14:46.720 --> 00:14:49.179
B2C to external ID isn't that easy. And this

00:14:49.179 --> 00:14:51.679
customer already brought it up in one of my first

00:14:51.679 --> 00:14:55.289
conversations with them. It has something to

00:14:55.289 --> 00:14:58.129
do with the identity experience framework, some

00:14:58.129 --> 00:15:01.870
kind of XML policy stuff going on into B2C. Maybe

00:15:01.870 --> 00:15:04.129
this rings a bell with you, Chris, when you set

00:15:04.129 --> 00:15:06.309
it up. Oh, no. Okay. Well, since you mentioned

00:15:06.309 --> 00:15:08.370
it, it was kind of hard to set it up B2C in the

00:15:08.370 --> 00:15:10.470
early days. Apparently, there's a lot of custom

00:15:10.470 --> 00:15:13.009
stuff you can do, which you cannot do any longer

00:15:13.009 --> 00:15:15.669
with external ID, and you have to figure out.

00:15:16.629 --> 00:15:19.950
some new custom authentication extensions instead

00:15:19.950 --> 00:15:22.190
of that. And that was actually the reason why

00:15:22.190 --> 00:15:25.850
this customer is a little bit blocked on migrating

00:15:25.850 --> 00:15:28.210
right away. And then even if you want to migrate,

00:15:28.509 --> 00:15:31.269
it's not a simple toggle, unfortunately. It never

00:15:31.269 --> 00:15:34.149
is, I guess, where you can just migrate into

00:15:34.149 --> 00:15:36.509
external ID. You actually have to set up your

00:15:36.509 --> 00:15:39.350
external ID separately from your B2C. You have

00:15:39.350 --> 00:15:42.389
to take an inventory first of all your applications,

00:15:42.629 --> 00:15:44.889
your user flows, your identity providers, everything.

00:15:45.580 --> 00:15:48.720
then obviously you have to create all your users

00:15:48.720 --> 00:15:51.559
into the external ID. There is no way to sync

00:15:51.559 --> 00:15:55.000
password hashes to the external ID, so you have

00:15:55.000 --> 00:15:58.159
two options. You either ask everybody to reset

00:15:58.159 --> 00:16:00.759
their password once they land on the external

00:16:00.759 --> 00:16:05.940
ID, or there is actually a quite clever password

00:16:05.940 --> 00:16:10.679
hash harvesting workflow thing available. I'll

00:16:10.679 --> 00:16:12.940
put a link in the show notes, but this is where

00:16:12.940 --> 00:16:16.460
your app... connecting to B2C and external ID

00:16:16.460 --> 00:16:20.259
is able to if your user is successfully logging

00:16:20.259 --> 00:16:23.059
in from B2C, it is actually capturing the hash

00:16:23.059 --> 00:16:25.820
and storing it through graph in the external

00:16:25.820 --> 00:16:28.779
ID for the same user. So if you have it running

00:16:28.779 --> 00:16:31.879
in parallel for a while, you'll probably bring

00:16:31.879 --> 00:16:35.740
over most of the frequently used accounts automatically.

00:16:36.539 --> 00:16:41.919
So it's quite involved. Unfortunately, and there

00:16:41.919 --> 00:16:45.059
are some challenges with it, but I think if you're

00:16:45.059 --> 00:16:47.899
listening and you're using B2C, please consider

00:16:47.899 --> 00:16:50.759
looking at external ID because of the security

00:16:50.759 --> 00:16:54.799
features and the fact that B2C will be end of

00:16:54.799 --> 00:16:58.740
support in 2030. Yeah, this is going to be an

00:16:58.740 --> 00:17:01.480
interesting process and journey for a lot of

00:17:01.480 --> 00:17:03.980
orgs, right? Because if you think about the B2C

00:17:03.980 --> 00:17:08.480
use cases, it's almost always unmanaged. identities

00:17:08.480 --> 00:17:12.279
from from consumers or outside parties right

00:17:12.279 --> 00:17:14.420
yeah it's really really difficult if you've gone

00:17:14.420 --> 00:17:17.180
and invested time into building something like

00:17:17.180 --> 00:17:20.680
this and then now you've got to you know do stuff

00:17:20.680 --> 00:17:23.000
or change stuff right that's uh it's definitely

00:17:23.000 --> 00:17:25.779
an interesting one for sure yeah and i also had

00:17:25.779 --> 00:17:27.819
some conversations with the customer that maybe

00:17:27.819 --> 00:17:31.039
not relying only on protecting these identities

00:17:31.039 --> 00:17:33.220
is the proper way to do because like you said

00:17:33.579 --> 00:17:36.319
it is out of your control, right? So those customers

00:17:36.319 --> 00:17:38.480
have their own identities. They log in from their

00:17:38.480 --> 00:17:41.279
own endpoints, not managed by your organization.

00:17:41.519 --> 00:17:44.519
They're coming from Tor browsers or VPNs or all

00:17:44.519 --> 00:17:47.119
over the world, whatever. So I think you should

00:17:47.119 --> 00:17:49.539
assume that everything that's landing on your

00:17:49.539 --> 00:17:52.900
front door could be potentially problematic.

00:17:53.900 --> 00:17:56.779
So enforcing a proper MFA would be one thing,

00:17:56.779 --> 00:17:58.960
but the second thing obviously would be also

00:17:58.960 --> 00:18:01.819
to protect the workload. workloads in the back

00:18:01.819 --> 00:18:04.299
end. And obviously with Defender for Cloud, with

00:18:04.299 --> 00:18:06.579
Defender for Containers, with Storage, with App

00:18:06.579 --> 00:18:09.220
Security, you have a lot of ways, databases,

00:18:09.619 --> 00:18:12.180
you have a lot of ways to protect the front end

00:18:12.180 --> 00:18:14.319
and the back end services. And I think that's

00:18:14.319 --> 00:18:17.200
perhaps even more important than focusing solely

00:18:17.200 --> 00:18:20.039
on these identities, to be honest. There's a

00:18:20.039 --> 00:18:22.480
reason, obviously, why you split them up from

00:18:22.480 --> 00:18:25.019
your workforce tenant in the first place. So

00:18:25.019 --> 00:18:29.599
maybe just leave it there. Yeah, that makes sense.

00:18:29.819 --> 00:18:33.099
Yeah. So it was quite a journey figuring out,

00:18:33.160 --> 00:18:37.440
especially because B2C wasn't able to get recreated

00:18:37.440 --> 00:18:42.339
nowadays anymore. So it was a little bit touching

00:18:42.339 --> 00:18:45.440
around in the dark here and there. But yeah,

00:18:45.559 --> 00:18:48.720
it was a fun project. The lighthouse stuff and

00:18:48.720 --> 00:18:52.960
the wizard got me off board a little bit, off

00:18:52.960 --> 00:18:55.960
guard a little bit. But yeah, well, eventually

00:18:55.960 --> 00:18:59.619
it was... We managed to solve it and I learned

00:18:59.619 --> 00:19:03.200
a thing or two. So that's always good. I think

00:19:03.200 --> 00:19:05.980
I still have a BTC tenant or directory kicking

00:19:05.980 --> 00:19:08.240
around in my tenant because of the work that

00:19:08.240 --> 00:19:11.039
I had previously done. But you're right. It's

00:19:11.039 --> 00:19:13.619
always difficult when you've got to try and replicate

00:19:13.619 --> 00:19:15.680
something so you can come up with a solution,

00:19:15.740 --> 00:19:18.940
but you can't actually build the thing. So always

00:19:18.940 --> 00:19:20.420
challenging. But yeah, it sounds like it was

00:19:20.420 --> 00:19:24.039
a fun experience and something interesting to

00:19:24.039 --> 00:19:28.069
learn for sure. I noticed you've got a ton of

00:19:28.069 --> 00:19:29.609
links in the show notes again, which is really

00:19:29.609 --> 00:19:32.509
cool. So, you know, folks can kind of find more

00:19:32.509 --> 00:19:35.069
detailed information anyway. Indeed. I didn't

00:19:35.069 --> 00:19:37.109
want to go into all the weeds of the stuff and

00:19:37.109 --> 00:19:40.289
all the migrating. So, yeah, I put a bunch of

00:19:40.289 --> 00:19:44.109
links in there. And, yeah, I hope it's informative

00:19:44.109 --> 00:19:47.750
for people listening, running B2C. Yeah, very

00:19:47.750 --> 00:19:50.710
cool. Thank you for sharing that. I'm sure there

00:19:50.710 --> 00:19:52.970
are some folks out there that are going to run

00:19:52.970 --> 00:19:54.950
into this at some point. So very cool. Yeah,

00:19:54.950 --> 00:19:57.690
and like I said, especially the whole lighthouse,

00:19:57.890 --> 00:19:59.930
the wizard thing, it was kind of weird. So I

00:19:59.930 --> 00:20:03.589
hope people hearing this, they don't stumble

00:20:03.589 --> 00:20:07.450
upon the same issues as I did. Yeah, fair enough.

00:20:07.890 --> 00:20:11.890
So we need to patch our stuff. Is that right?

00:20:12.750 --> 00:20:15.069
We need to patch our stuff. I was going to say,

00:20:15.130 --> 00:20:17.369
another thing that should be topical for folks

00:20:17.369 --> 00:20:20.769
or top of mind for folks is patching. And I think

00:20:20.769 --> 00:20:23.609
we've definitely mentioned it before, talking

00:20:23.609 --> 00:20:25.470
about patching things, making sure things are

00:20:25.470 --> 00:20:28.089
updated. And I understand that that's not always

00:20:28.089 --> 00:20:31.190
as easy as just auto -updating things, right?

00:20:31.250 --> 00:20:32.930
Especially when your organization gets larger,

00:20:33.170 --> 00:20:36.490
it becomes a little bit more difficult to automatically

00:20:36.490 --> 00:20:39.089
deploy massive amounts of patches to things.

00:20:39.990 --> 00:20:42.740
Software can be nuanced. Different folks use

00:20:42.740 --> 00:20:44.539
different software. You patch one thing, you

00:20:44.539 --> 00:20:47.059
break something else. All of these things, they

00:20:47.059 --> 00:20:51.039
happen in large environments, right? But I think

00:20:51.039 --> 00:20:57.500
that we're in a place now where attackers are

00:20:57.500 --> 00:21:00.720
getting so good at reverse engineering patches

00:21:00.720 --> 00:21:04.980
and CVEs and stuff that we can't be lagging so

00:21:04.980 --> 00:21:08.160
far behind that patching cycle. I mean, I don't

00:21:08.160 --> 00:21:10.720
know if you've worked... I imagine you did work

00:21:10.720 --> 00:21:13.640
in large environments back in the day when, you

00:21:13.640 --> 00:21:16.119
know, patches hit. There was a test environment

00:21:16.119 --> 00:21:18.880
and you take weeks to go from, you know, the

00:21:18.880 --> 00:21:21.500
patch actually becoming available, putting it

00:21:21.500 --> 00:21:23.779
in the test environment, having people test it,

00:21:23.819 --> 00:21:26.519
report, blah, blah, blah, blah, before you eventually

00:21:26.519 --> 00:21:28.680
would push that patch into production. We can't

00:21:28.680 --> 00:21:31.359
do that. You can't do that nowadays any longer.

00:21:31.579 --> 00:21:34.430
You know, you're almost better. better off breaking

00:21:34.430 --> 00:21:36.470
things in the production environment by getting

00:21:36.470 --> 00:21:38.069
the patches out there. And I'm not saying go

00:21:38.069 --> 00:21:39.690
and do this, I'm just saying you're almost better

00:21:39.690 --> 00:21:43.930
off because you can't rely on it. So if you haven't

00:21:43.930 --> 00:21:48.390
been following along, I have some stats here

00:21:48.390 --> 00:21:51.049
from this is just Microsoft patch Tuesday for

00:21:51.049 --> 00:21:54.329
the last couple of months. So in June we set

00:21:54.329 --> 00:21:59.049
a record with 198 CVEs that were patched across

00:21:59.049 --> 00:22:03.400
Microsoft patch Tuesday. 32 of those were critical

00:22:03.400 --> 00:22:08.440
and at the time, which is June of 2026, that

00:22:08.440 --> 00:22:11.140
was the largest release of patches in the history

00:22:11.140 --> 00:22:15.480
of Microsoft Update patching program. The previous

00:22:15.480 --> 00:22:18.559
record was I think from sometime in October 2025.

00:22:20.259 --> 00:22:22.640
Now fast forward, this was June, fast forward

00:22:22.640 --> 00:22:25.440
to July which was last week we had Patch Tuesday

00:22:25.440 --> 00:22:29.980
for July and again that record was broken. This

00:22:29.980 --> 00:22:35.380
time More than 600 CVEs were patched, 60 critical

00:22:35.380 --> 00:22:38.740
vulnerabilities. There were three zero days of

00:22:38.740 --> 00:22:41.380
which two of them were actively being exploited,

00:22:41.519 --> 00:22:44.460
right? And I think one was an ADFS thing and

00:22:44.460 --> 00:22:46.119
there was something on SharePoint as well. And

00:22:46.119 --> 00:22:49.140
there were actively exploited privilege escalation

00:22:49.140 --> 00:22:53.319
vulnerabilities. So we're seeing this sort of

00:22:53.319 --> 00:22:59.240
avalanche of updates and patches. The reason

00:22:59.240 --> 00:23:01.599
behind it is maybe quite obvious and maybe it

00:23:01.599 --> 00:23:04.720
isn't, but it's because of AI, right? And AI

00:23:04.720 --> 00:23:07.019
sort of powered vulnerability scanning, right?

00:23:07.099 --> 00:23:09.779
We've heard, I'm sure we've all heard of Mythos

00:23:09.779 --> 00:23:13.779
by now and how amazing Mythos is at finding vulnerabilities.

00:23:14.720 --> 00:23:16.700
Microsoft obviously have MDash, which I guess

00:23:16.700 --> 00:23:19.440
is what they use for something similar or to

00:23:19.440 --> 00:23:22.460
do the same thing. But, you know, I'm just talking

00:23:22.460 --> 00:23:26.480
specifically Microsoft here. if you think about

00:23:26.480 --> 00:23:30.900
that sheer number 622 CVEs in one patch release

00:23:30.900 --> 00:23:37.359
attributed to AI scanning and AI actively looking

00:23:37.359 --> 00:23:41.740
at things through the code base. Now the challenge

00:23:41.740 --> 00:23:45.779
here is that the bad guy also has access to these

00:23:45.779 --> 00:23:49.640
tools in many instances. And so we've gone from

00:23:49.640 --> 00:23:54.319
a place where a CVE would happen, the vendor

00:23:54.319 --> 00:23:56.900
would release a patch, the bad guy would take

00:23:56.900 --> 00:23:58.740
the patch, reverse engineer it to figure out

00:23:58.740 --> 00:24:01.099
what the flaw was, and then start attacking the

00:24:01.099 --> 00:24:03.980
flaw, right? To try and get hold of folks that

00:24:03.980 --> 00:24:07.799
haven't yet patched. There was a time there,

00:24:07.859 --> 00:24:10.460
like that time to exploit was fairly long because

00:24:10.460 --> 00:24:12.380
they would wait for the patch, they would reverse

00:24:12.380 --> 00:24:14.480
engineer it, and then they'd try and find targets.

00:24:14.740 --> 00:24:17.180
Well, we're at a place now where the bad guy

00:24:17.180 --> 00:24:19.359
has the same tools that the good guys have. they

00:24:19.359 --> 00:24:21.240
can also scan the code base. They can also look

00:24:21.240 --> 00:24:23.339
for stuff, right? And look for vulnerabilities.

00:24:23.500 --> 00:24:27.240
And so you have this like massive narrowing of

00:24:27.240 --> 00:24:31.279
this sort of time to exploit. And it's a real

00:24:31.279 --> 00:24:35.420
problem. So given all of this background and

00:24:35.420 --> 00:24:37.200
all of those things, I really, I kind of wanted

00:24:37.200 --> 00:24:39.660
to, I guess, ask the question, right? If you're

00:24:39.660 --> 00:24:42.240
responsible for patching your estate today, let's

00:24:42.240 --> 00:24:44.619
say you're in the server team or you're in the

00:24:44.619 --> 00:24:46.579
EUC team and you're responsible for patching

00:24:46.579 --> 00:24:51.059
your endpoints. how confident are you that those

00:24:51.059 --> 00:24:55.700
622 CVEs that were identified and patches were

00:24:55.700 --> 00:24:57.480
released for last week, how confident are you

00:24:57.480 --> 00:24:59.000
that all that stuff is patched and up to date

00:24:59.000 --> 00:25:02.420
today, right? I would say to say that a lot of

00:25:02.420 --> 00:25:04.000
folks are probably scratching their heads going,

00:25:04.119 --> 00:25:06.119
I might want to go and check that or maybe I

00:25:06.119 --> 00:25:07.940
should go run a report. And that's probably the

00:25:07.940 --> 00:25:10.319
right answer because you want to be sure, right?

00:25:10.779 --> 00:25:14.069
One of the things I found over time is that there's

00:25:14.069 --> 00:25:16.289
a bit of confusion between sort of the concepts

00:25:16.289 --> 00:25:18.789
of patch management and vulnerability management

00:25:18.789 --> 00:25:21.369
and sort of where they sit within, I guess, the

00:25:21.369 --> 00:25:23.869
maturity framework of an organization. And I

00:25:23.869 --> 00:25:25.349
thought, you know what, it'd be a good idea to

00:25:25.349 --> 00:25:27.809
kind of lay the foundation, talk about these

00:25:27.809 --> 00:25:33.250
things and, you know, help folks, I guess, understand

00:25:33.250 --> 00:25:35.690
where these things sort of sit and play and where

00:25:35.690 --> 00:25:37.470
they all sort of fit together, right? And if

00:25:37.470 --> 00:25:39.509
you're not looking at the show notes, I have

00:25:39.509 --> 00:25:42.980
the... The classic meme of Spider -Man, two Spider

00:25:42.980 --> 00:25:45.160
-Men pointing fingers at each other. Because

00:25:45.160 --> 00:25:47.140
to me, that's often how this feels. It's like,

00:25:47.200 --> 00:25:48.640
well, patch management points at vulnerability

00:25:48.640 --> 00:25:50.460
management, who's pointing back at patch management,

00:25:50.539 --> 00:25:55.059
right? So if we break it down just a little bit.

00:25:55.140 --> 00:25:56.960
So vulnerability management really is that sort

00:25:56.960 --> 00:26:01.839
of ongoing process where you're identifying and

00:26:01.839 --> 00:26:04.099
assessing, prioritizing and remediating these

00:26:04.099 --> 00:26:07.140
weaknesses, right? It's an ongoing sort of cyclical

00:26:07.140 --> 00:26:10.090
thing where you're constantly looking at... scanning

00:26:10.090 --> 00:26:13.490
your devices, looking for what vulnerabilities

00:26:13.490 --> 00:26:21.390
exist, figuring out whether they are vulnerable

00:26:21.390 --> 00:26:24.789
or is it a misconfiguration? Is it an actual

00:26:24.789 --> 00:26:27.890
CVE? Are there vendor patches available? Things

00:26:27.890 --> 00:26:29.730
like that. Then you want to sort of prioritize

00:26:29.730 --> 00:26:33.910
those things and remediate them and sort of go

00:26:33.910 --> 00:26:36.230
through this whole sort of process. And why this

00:26:36.230 --> 00:26:39.940
matters is because As I said before, the time

00:26:39.940 --> 00:26:43.119
to exploit keeps shrinking. We're getting to

00:26:43.119 --> 00:26:47.299
this place now where it's a race between Microsoft

00:26:47.299 --> 00:26:49.960
and the other vendors and the bad guys to get

00:26:49.960 --> 00:26:53.519
to the export first because they no longer need

00:26:53.519 --> 00:26:55.779
to wait for us or wait for the good guys to release

00:26:55.779 --> 00:26:58.019
patches to be able to reverse engineer them.

00:26:58.059 --> 00:26:59.619
They can just go and find the exports themselves.

00:27:01.579 --> 00:27:08.619
Also, we have this challenge where... In some

00:27:08.619 --> 00:27:11.079
cases, and in many cases, we can't patch everything,

00:27:11.319 --> 00:27:15.980
right? This is a process and it's a process where

00:27:15.980 --> 00:27:18.140
we have to look at what we have available. We

00:27:18.140 --> 00:27:22.339
have to look at prioritizing the things that

00:27:22.339 --> 00:27:25.059
need to be patched based on how critical they

00:27:25.059 --> 00:27:28.480
are. to our business, not necessarily how critical

00:27:28.480 --> 00:27:31.619
they are based on a CVSS score. So if you're

00:27:31.619 --> 00:27:34.720
not familiar with the nomenclature, a CVE is

00:27:34.720 --> 00:27:38.619
essentially the vulnerability database that lists

00:27:38.619 --> 00:27:42.519
a critical vulnerability. And a CVSS score is

00:27:42.519 --> 00:27:45.460
the severity of that vulnerability as a score.

00:27:45.619 --> 00:27:48.559
I believe that score is out of 10. So anything

00:27:48.559 --> 00:27:52.460
9 .8 and above usually is very bad. It's pretty

00:27:52.460 --> 00:27:55.519
difficult to get a 9 .8. 9 .7, whatever the case

00:27:55.519 --> 00:28:00.440
is, or 10 CVSS score. Now, oftentimes what happens

00:28:00.440 --> 00:28:03.180
in organizations is, and I think we're just human,

00:28:03.240 --> 00:28:06.960
right? We assume we find a list of 622 vulnerabilities,

00:28:07.359 --> 00:28:10.519
go and find the ones that are the highest priority

00:28:10.519 --> 00:28:12.859
based on their CVSS score and go and patch those

00:28:12.859 --> 00:28:15.640
things. That's a good approach, but that doesn't

00:28:15.640 --> 00:28:17.759
necessarily always ring true in all the environments,

00:28:17.880 --> 00:28:21.119
right? Because you may have an environment, for

00:28:21.119 --> 00:28:24.430
example, that is an OT environment. where you

00:28:24.430 --> 00:28:32.630
run controllers and IoT type devices, that environment

00:28:32.630 --> 00:28:36.670
may have concerning controls that actually help.

00:28:36.849 --> 00:28:40.029
So for example, your OT environment may not have

00:28:40.029 --> 00:28:46.009
internet access. So a CVSS score of 9 .8 in an

00:28:46.009 --> 00:28:48.009
OT environment that doesn't have internet access

00:28:48.009 --> 00:28:52.390
may not be as high a priority for you. as a CVS

00:28:52.390 --> 00:28:56.029
score of seven or eight in an internet -facing

00:28:56.029 --> 00:29:00.250
environment, right? So you kind of have to prioritize

00:29:00.250 --> 00:29:03.569
these things based on what is relevant to you

00:29:03.569 --> 00:29:05.190
and your environment and what other controls

00:29:05.190 --> 00:29:09.289
exist. The other reason, I think the final point

00:29:09.289 --> 00:29:12.410
of why this is important and why vulnerability

00:29:12.410 --> 00:29:14.369
management is such an important thing for us

00:29:14.369 --> 00:29:18.750
is it's about compliance and guaranteed if you

00:29:18.750 --> 00:29:21.609
look at frameworks like CIS, Or if you're buying

00:29:21.609 --> 00:29:23.730
cyber insurance, I'm sure pretty much everyone

00:29:23.730 --> 00:29:26.549
is buying cyber insurance these days. And I don't

00:29:26.549 --> 00:29:28.690
know if anyone has personally been responsible

00:29:28.690 --> 00:29:33.329
for purchasing a cyber insurance program or policy.

00:29:33.470 --> 00:29:35.450
I've been through that process a couple of times

00:29:35.450 --> 00:29:38.569
now. The questionnaires that you fill in can

00:29:38.569 --> 00:29:41.250
be kind of intimidating and almost certainly

00:29:41.250 --> 00:29:42.710
they're always going to ask and they're going

00:29:42.710 --> 00:29:44.970
to assume that you have some form of vulnerability

00:29:44.970 --> 00:29:50.400
management process whereby you're managing. the

00:29:50.400 --> 00:29:52.700
vulnerabilities and you have a process to update

00:29:52.700 --> 00:29:57.859
things in a way. So an easy way to think about

00:29:57.859 --> 00:30:00.900
this and the distinction between vulnerability

00:30:00.900 --> 00:30:03.119
management and patch management is that vulnerability

00:30:03.119 --> 00:30:07.319
management is that decision layer. How do we

00:30:07.319 --> 00:30:09.720
figure out what's vulnerable, how bad it is,

00:30:09.880 --> 00:30:12.880
and come up with some sort of determination as

00:30:12.880 --> 00:30:15.259
to what are we going to fix first, what are we

00:30:15.259 --> 00:30:16.440
going to fix second, what are we going to fix

00:30:16.440 --> 00:30:21.140
third. That sort of decision layer, that's vulnerability

00:30:21.140 --> 00:30:23.740
management. And typically in a large organization

00:30:23.740 --> 00:30:26.740
or in a mature organization, that's a cyber function,

00:30:27.039 --> 00:30:32.019
right? Patch management is the action of actually

00:30:32.019 --> 00:30:35.519
patching things and remediating things. And we'll

00:30:35.519 --> 00:30:39.220
talk about it in just a second where the remediation

00:30:39.220 --> 00:30:42.079
doesn't have to be necessarily patch it, right?

00:30:42.140 --> 00:30:43.720
Because patch it may not be an option. There

00:30:43.720 --> 00:30:46.920
may not be a patch. It's that remediate action.

00:30:47.400 --> 00:30:49.740
which is handed off. And typically that's something

00:30:49.740 --> 00:30:52.700
where that gets handed off to an IT team or a

00:30:52.700 --> 00:30:56.319
operational team, which is under IT, your server

00:30:56.319 --> 00:30:58.619
team, your EUC team, et cetera, who actually

00:30:58.619 --> 00:31:04.220
action that. So in essence, your patch management

00:31:04.220 --> 00:31:08.599
is a component of a holistic vulnerability management

00:31:08.599 --> 00:31:10.640
program that you have within your organization.

00:31:10.980 --> 00:31:15.460
And you'll typically find, when I work with customers,

00:31:16.029 --> 00:31:18.150
You can find this in various forms of maturity,

00:31:18.430 --> 00:31:21.490
right? Smaller companies or companies that are

00:31:21.490 --> 00:31:23.289
just sort of, they've just started or they've

00:31:23.289 --> 00:31:25.589
just built their infrastructure, they're worried

00:31:25.589 --> 00:31:27.630
about patching. Patching is the thing, right?

00:31:27.750 --> 00:31:29.690
So that's where you start. Let's make sure we

00:31:29.690 --> 00:31:32.329
can get everything patched. And as the company

00:31:32.329 --> 00:31:35.390
sort of matures and their processes mature and

00:31:35.390 --> 00:31:37.710
they potentially climb the ladder of compliance

00:31:37.710 --> 00:31:40.569
and all of these other things, what you find

00:31:40.569 --> 00:31:43.630
is that that matures into... going from that

00:31:43.630 --> 00:31:46.569
very tactical let's find and patch things to

00:31:46.569 --> 00:31:49.710
let's build out a like a framework for ourselves

00:31:49.710 --> 00:31:52.829
whereby we have now we're stepping into this

00:31:52.829 --> 00:31:56.869
vulnerability management arena where we have

00:31:56.869 --> 00:31:59.950
this process right and I've sort of listed the

00:31:59.950 --> 00:32:04.289
I guess what I see the the five steps of this

00:32:04.289 --> 00:32:06.289
process to be and I've listed them sort of in

00:32:06.289 --> 00:32:08.269
a linear fashion. But if you think about it,

00:32:08.289 --> 00:32:11.109
it really should be more cyclical in a circle.

00:32:11.470 --> 00:32:17.990
But you're discovering is your first phase. Discover,

00:32:18.190 --> 00:32:20.730
I've called it. And what that is, it's asset

00:32:20.730 --> 00:32:24.250
discovery and inventory. You can't secure something

00:32:24.250 --> 00:32:26.950
if you don't know about it. So you have to actually

00:32:26.950 --> 00:32:31.029
have some sort of inventory of all of the assets

00:32:31.029 --> 00:32:33.650
in your estate. What service have you got? Where

00:32:33.650 --> 00:32:35.829
do they live? What operating systems are on those

00:32:35.829 --> 00:32:38.579
servers? what applications are on those servers,

00:32:38.740 --> 00:32:42.039
right? Similarly with desktops and your client

00:32:42.039 --> 00:32:45.599
fleet. How many Windows 10 devices have you got?

00:32:45.660 --> 00:32:48.279
How many Windows 11 devices? What version? How

00:32:48.279 --> 00:32:52.500
many Windows XP devices do you got? Yes, hopefully

00:32:52.500 --> 00:32:56.279
none, but yes, that's exactly right. Server 2003?

00:32:58.440 --> 00:33:01.720
Yeah, that's right. So no, but that's an exactly,

00:33:01.859 --> 00:33:04.019
that's a very good point, right? Because again,

00:33:04.200 --> 00:33:07.680
if you're a... a smaller business or a smaller

00:33:07.680 --> 00:33:11.079
company and you've got 20 employees and all 20

00:33:11.079 --> 00:33:13.539
of those employees have laptops that they bring

00:33:13.539 --> 00:33:15.660
into the office every day, it's really easy to

00:33:15.660 --> 00:33:18.519
walk around and go 1, 2, 3, 4, 5, 20. Okay, everyone's

00:33:18.519 --> 00:33:21.599
got a Mac. When you start having 20 ,000 users,

00:33:22.059 --> 00:33:26.240
it gets really difficult to keep track on stock.

00:33:26.799 --> 00:33:33.380
And just a really random example of this is About

00:33:33.380 --> 00:33:37.019
a year ago, I did a project with a very large

00:33:37.019 --> 00:33:40.220
mining company here in Australia. And one of

00:33:40.220 --> 00:33:42.859
the things we were doing was it was a separation

00:33:42.859 --> 00:33:45.799
project where the mining company had sold off

00:33:45.799 --> 00:33:50.640
a mine asset. So everything at a particular mine

00:33:50.640 --> 00:33:52.940
was being sort of separated from the rest of

00:33:52.940 --> 00:33:54.680
the network, right? So we also had to do a very

00:33:54.680 --> 00:33:57.900
robust sort of asset discovery piece to figure

00:33:57.900 --> 00:34:01.039
out which assets, you know, software, hardware,

00:34:01.140 --> 00:34:04.440
everything else. belongs to that mine so that

00:34:04.440 --> 00:34:08.420
we could separate that those assets um and we

00:34:08.420 --> 00:34:10.239
thought we had done a really good job of figuring

00:34:10.239 --> 00:34:13.119
out exactly what belonged where until the day

00:34:13.119 --> 00:34:16.400
came where um or the week came where we were

00:34:16.400 --> 00:34:19.380
starting to cut over workstations from one domain

00:34:19.380 --> 00:34:23.440
to the next and people would turn up um you know

00:34:23.440 --> 00:34:25.719
to the to the build room and they'd have like

00:34:25.719 --> 00:34:28.739
three laptops and we're like you are you're you

00:34:28.739 --> 00:34:30.599
know according to the asset list you only have

00:34:30.599 --> 00:34:33.099
one laptop It was like, oh, these are my two

00:34:33.099 --> 00:34:35.079
old ones. They were just in my drawer, right?

00:34:35.519 --> 00:34:38.639
Or folks would go, you know, be off shift for

00:34:38.639 --> 00:34:40.820
two weeks and the laptop would just sit in the

00:34:40.820 --> 00:34:43.340
drawer and then they'd forget about it or whatever

00:34:43.340 --> 00:34:46.400
the case may be. So that asset discovery piece

00:34:46.400 --> 00:34:48.400
can be really difficult. It sounds simple, but

00:34:48.400 --> 00:34:51.019
it can be really, really difficult to keep track

00:34:51.019 --> 00:34:53.920
of assets, what you have, where they live, and

00:34:53.920 --> 00:34:55.619
make sure that stuff gets updated, right? If

00:34:55.619 --> 00:34:57.559
you get a new laptop, you need to make sure that

00:34:57.559 --> 00:35:00.059
the laptop that was assigned to you before either

00:35:00.059 --> 00:35:02.739
gets retired. or gets updated to the new person

00:35:02.739 --> 00:35:04.380
who's going to get it, right? So that sort of

00:35:04.380 --> 00:35:05.980
asset discovery, right? Really, really important.

00:35:06.639 --> 00:35:09.719
Then the second part of this is assess. So you

00:35:09.719 --> 00:35:12.940
want to look at actually assessing the vulnerabilities,

00:35:13.179 --> 00:35:14.960
right? And this is kind of where you run scans

00:35:14.960 --> 00:35:16.599
and stuff like that. And there are a bunch of

00:35:16.599 --> 00:35:18.960
tools that you can use that will scan the environment

00:35:18.960 --> 00:35:22.719
for assessments and it will query the CVE database

00:35:22.719 --> 00:35:25.440
to look for vulnerable software and sort of give

00:35:25.440 --> 00:35:28.510
you the reports around that. misconfigs, all

00:35:28.510 --> 00:35:30.530
of those types of things just kind of shows up

00:35:30.530 --> 00:35:33.489
in that sort of assessment phase. So then you

00:35:33.489 --> 00:35:35.090
end up with a list. And if you've ever run a

00:35:35.090 --> 00:35:37.090
vulnerability scanner in a large environment,

00:35:37.309 --> 00:35:39.269
I'm sure you understand that you come up with

00:35:39.269 --> 00:35:41.250
a list and it says, you know, you have 10 ,000

00:35:41.250 --> 00:35:43.849
vulnerabilities, right? Because it will find

00:35:43.849 --> 00:35:47.329
absolutely everything that is potentially deemed

00:35:47.329 --> 00:35:49.610
to be vulnerable. And this is where the prioritized

00:35:49.610 --> 00:35:51.809
phase, which is sort of phase three in this process,

00:35:51.969 --> 00:35:53.730
becomes really important because this is where

00:35:53.730 --> 00:35:55.150
you start looking at things and you go, okay.

00:35:55.639 --> 00:35:57.699
Well, we've got 10 ,000 vulnerabilities. How

00:35:57.699 --> 00:36:00.320
many of those are things that we need to worry

00:36:00.320 --> 00:36:03.000
about today? And how many of those are things

00:36:03.000 --> 00:36:06.219
that we can worry about next week? And you have

00:36:06.219 --> 00:36:09.199
to sort of do that risk -based scoring to understand

00:36:09.199 --> 00:36:13.119
how do we tackle this problem? Because we can't

00:36:13.119 --> 00:36:15.099
just run after everything. We have to prioritize

00:36:15.099 --> 00:36:16.460
things that are going to be really important

00:36:16.460 --> 00:36:18.440
to us. And I talked about the example before

00:36:18.440 --> 00:36:21.420
of... an OT environment perhaps where you have

00:36:21.420 --> 00:36:23.920
compensating controls, that may actually mean

00:36:23.920 --> 00:36:26.360
that the risk of that thing is lower than you

00:36:26.360 --> 00:36:29.239
may think, right? Or what have you. Or you may

00:36:29.239 --> 00:36:33.900
find that it's, you know, there's a CVSS of something

00:36:33.900 --> 00:36:35.539
that's eight and it's a remote code execution

00:36:35.539 --> 00:36:37.579
on a product that you have that's internet facing.

00:36:38.000 --> 00:36:40.579
Well, that thing better shoot up to the top of

00:36:40.579 --> 00:36:42.139
your list all of a sudden because you need to

00:36:42.139 --> 00:36:44.159
get a hold of that thing and get it sorted and

00:36:44.159 --> 00:36:46.739
updated pretty quickly. So that prioritization

00:36:46.739 --> 00:36:49.480
seems simple, but... you need to really spend

00:36:49.480 --> 00:36:52.639
the time to have the robust rules in place to

00:36:52.639 --> 00:36:55.019
help you prioritize where you're going to spend

00:36:55.019 --> 00:36:57.440
your time immediately. What stuff can you afford

00:36:57.440 --> 00:37:01.059
to spend less time on or do later or what have

00:37:01.059 --> 00:37:03.900
you, right? And that's where you sort of hand

00:37:03.900 --> 00:37:06.159
that off into step four, which is that remediation.

00:37:07.059 --> 00:37:09.159
Typically, the folks that run the vulnerability

00:37:09.159 --> 00:37:12.699
management program are security and governance

00:37:12.699 --> 00:37:15.039
folks. They're not the tactical people on the

00:37:15.039 --> 00:37:18.699
ground who are going to go patch machines, crawl

00:37:18.699 --> 00:37:24.420
under desks and find that one PostgreSQL server

00:37:24.420 --> 00:37:26.260
that someone set up 10 years ago and it's been

00:37:26.260 --> 00:37:29.940
running under a desk. So you hand this off to

00:37:29.940 --> 00:37:35.239
your tech team to go and remediate. This is where

00:37:35.239 --> 00:37:37.219
that sort of happens. And typically you want

00:37:37.219 --> 00:37:41.360
to have this be a tracked request. An email that

00:37:41.360 --> 00:37:43.980
says, hey you've got these risks, go fix them.

00:37:44.659 --> 00:37:46.900
That's not really a good service management approach,

00:37:47.000 --> 00:37:48.880
is it? You kind of want to have this be tracked

00:37:48.880 --> 00:37:51.780
in some sort of request whereby the team has

00:37:51.780 --> 00:37:53.699
this on their radar and they can go. And then

00:37:53.699 --> 00:37:56.820
the remediation in itself can be one of three

00:37:56.820 --> 00:37:59.380
things typically, right? You patch it. So in

00:37:59.380 --> 00:38:01.880
most cases, if we're talking about the Microsoft

00:38:01.880 --> 00:38:05.260
approach and Patch Tuesday, there's a patch for

00:38:05.260 --> 00:38:07.840
it. So the patch already exists. So the easiest

00:38:07.840 --> 00:38:11.800
thing is go patch it, right? Or you mitigate

00:38:11.800 --> 00:38:15.260
it. So again... Maybe there isn't a patch or

00:38:15.260 --> 00:38:18.760
maybe in order to patch that thing, you have

00:38:18.760 --> 00:38:21.840
to reboot, you know, I don't know, a nuclear

00:38:21.840 --> 00:38:24.400
turbine or something, right? Well, you can't

00:38:24.400 --> 00:38:27.000
go just do that. There's got to be a little bit

00:38:27.000 --> 00:38:30.400
of a process to it. You may be able to disable

00:38:30.400 --> 00:38:32.900
a feature or maybe you isolate that thing on

00:38:32.900 --> 00:38:35.059
the network or some sort of workaround until

00:38:35.059 --> 00:38:39.059
such time that you can patch it. Or maybe you

00:38:39.059 --> 00:38:41.019
just accept the risk, right? If you have to reboot

00:38:41.019 --> 00:38:44.260
a controller that runs a turbine, And the downtime

00:38:44.260 --> 00:38:46.099
of that turbine is going to cost the business

00:38:46.099 --> 00:38:50.880
$10 ,000 a minute. Is it worth the downtime,

00:38:51.059 --> 00:38:54.219
right, to fix the risk? Now, this is where risk

00:38:54.219 --> 00:38:57.260
people and lots of smarter people than me come

00:38:57.260 --> 00:39:00.039
into play to help sort of make that determination

00:39:00.039 --> 00:39:03.219
as to whether we document the risk, accept it,

00:39:03.260 --> 00:39:06.400
and move on, or whether we pull the trigger and

00:39:06.400 --> 00:39:10.139
we patch it, right? But that's part of this vulnerability

00:39:10.139 --> 00:39:14.110
management process that, as a business, you kind

00:39:14.110 --> 00:39:17.110
of need to work through. And then the last part

00:39:17.110 --> 00:39:19.250
of this is just reporting. It's great to say

00:39:19.250 --> 00:39:23.289
something's been patched because we ran the executable

00:39:23.289 --> 00:39:25.789
or we pushed the update in SCCM or Intune or

00:39:25.789 --> 00:39:28.130
whatever, but you really need to be able to report

00:39:28.130 --> 00:39:31.070
success on this. It has to be reported green.

00:39:32.110 --> 00:39:36.030
Sometimes a reboot is required again or there's

00:39:36.030 --> 00:39:39.550
some reason why the patch doesn't apply or land

00:39:39.550 --> 00:39:42.260
or it requires something else or... whatever

00:39:42.260 --> 00:39:44.380
the case may be. So, you know, you need to follow

00:39:44.380 --> 00:39:46.019
the process through. And the only way you know

00:39:46.019 --> 00:39:48.519
about that is by looking at sort of robust reporting

00:39:48.519 --> 00:39:51.599
to understand that you've verified it, it's been

00:39:51.599 --> 00:39:54.960
validated, and things are sort of as, you know,

00:39:54.960 --> 00:39:58.980
as you intended. So I'm going to kind of leave

00:39:58.980 --> 00:40:00.679
it there for now. I just wanted to really just

00:40:00.679 --> 00:40:04.559
define, you know, patch management versus vulnerability

00:40:04.559 --> 00:40:06.719
management, what these things are, and sort of

00:40:06.719 --> 00:40:09.940
break down what, you know, vulnerability, typical

00:40:09.940 --> 00:40:13.250
vulnerability management. process looks like.

00:40:13.489 --> 00:40:17.929
And like I said, this is a constant sort of ongoing

00:40:17.929 --> 00:40:21.829
thing within your business and it's really important

00:40:21.829 --> 00:40:26.449
that if you are today still just patching and

00:40:26.449 --> 00:40:29.050
you're just tactically running after patches,

00:40:29.389 --> 00:40:32.010
I think the Americans would say whack -a -mole.

00:40:32.150 --> 00:40:34.130
I don't know if you ever know what that is guys,

00:40:34.190 --> 00:40:39.059
but you know the game where it pops out. That's

00:40:39.059 --> 00:40:40.719
really what you're doing is you're playing whack

00:40:40.719 --> 00:40:42.239
-a -mole, right? If you're just running after

00:40:42.239 --> 00:40:46.000
patches. And even a small environment can be

00:40:46.000 --> 00:40:50.320
really, really cumbersome to stay ahead when

00:40:50.320 --> 00:40:51.940
you have that. And we're only talking about Microsoft

00:40:51.940 --> 00:40:54.739
stuff here now. When you layer in third -party

00:40:54.739 --> 00:40:57.480
software, right? Think about that. Like you've

00:40:57.480 --> 00:41:00.739
got a large organization with third -party software.

00:41:00.920 --> 00:41:02.739
Where are those packages coming from? Who updates

00:41:02.739 --> 00:41:05.179
them? How do they get pushed out? How are they

00:41:05.179 --> 00:41:07.190
deployed in the first place? it can get really,

00:41:07.250 --> 00:41:09.389
really complicated. And I think probably what

00:41:09.389 --> 00:41:12.010
I'll end up doing for next episode or at least

00:41:12.010 --> 00:41:13.909
for another episode in future is I'll break down

00:41:13.909 --> 00:41:16.510
a little bit more some of these phases and look

00:41:16.510 --> 00:41:20.650
at some of the technology and maybe some technical

00:41:20.650 --> 00:41:23.409
processes that you can use. Because the answer

00:41:23.409 --> 00:41:26.090
isn't always go buy all of Defender because all

00:41:26.090 --> 00:41:28.110
of Defender can do some of this stuff. There's

00:41:28.110 --> 00:41:30.369
other ways that you can look at it. There's other

00:41:30.369 --> 00:41:32.409
tools around as well that complement things that

00:41:32.409 --> 00:41:37.840
you may have. And if you've got four users working

00:41:37.840 --> 00:41:39.800
out of coffee shops all day, you're probably

00:41:39.800 --> 00:41:41.800
not using SCCM, right? You might be using something

00:41:41.800 --> 00:41:45.000
else. So I'll sort of dig into the technical

00:41:45.000 --> 00:41:47.460
nuances of this, I think, in a future episode

00:41:47.460 --> 00:41:50.139
to talk about some of the technical challenges

00:41:50.139 --> 00:41:52.780
here. But I think for now, I really wanted to

00:41:52.780 --> 00:41:54.340
just sort of share something that I've been thinking

00:41:54.340 --> 00:41:57.000
about a lot, which is how do we, from a process

00:41:57.000 --> 00:41:59.780
perspective, govern this? And how does this scale,

00:41:59.900 --> 00:42:02.349
especially when we have... you know larger organizations

00:42:02.349 --> 00:42:05.369
where we have lots of assets and lots of things

00:42:05.369 --> 00:42:08.710
yeah and you're probably going into this in more

00:42:08.710 --> 00:42:12.449
detail than in the next episode but uh when i

00:42:12.449 --> 00:42:15.489
look at threat and vulnerability threat and vulnerability

00:42:15.489 --> 00:42:18.289
management and defender It's a very powerful

00:42:18.289 --> 00:42:23.269
reporting tool to give you insights in what your

00:42:23.269 --> 00:42:27.349
organization is doing. We also, for our company,

00:42:27.469 --> 00:42:30.309
we're frequently assessing those reports monthly

00:42:30.309 --> 00:42:33.690
with our customers to zoom in on. But even if

00:42:33.690 --> 00:42:35.849
you patch applications, a lot of applications

00:42:35.849 --> 00:42:39.989
come with all kinds of packages inside or modules

00:42:39.989 --> 00:42:42.469
inside which can contain vulnerabilities. And

00:42:42.469 --> 00:42:46.010
I'm always amazed by... For example, we had a

00:42:46.010 --> 00:42:50.050
customer last time where they were running thousands

00:42:50.050 --> 00:42:53.730
of Firefox 1 .0 on their endpoints. And what

00:42:53.730 --> 00:42:56.130
it appears to be, it was part of the installer

00:42:56.130 --> 00:42:59.789
of some kind of Zebra printer they installed

00:42:59.789 --> 00:43:03.920
in the logistics department, right? You have

00:43:03.920 --> 00:43:07.300
a lot of vulnerabilities going on there while

00:43:07.300 --> 00:43:10.840
you think you are fully patched, but some kind

00:43:10.840 --> 00:43:13.139
of third -party supplier brought some malicious,

00:43:13.480 --> 00:43:16.320
well, potentially abusable software into your

00:43:16.320 --> 00:43:18.820
company. That's a really good example, too, because

00:43:18.820 --> 00:43:24.920
my Mac that I use at Arenco is managed through

00:43:24.920 --> 00:43:27.019
Defender, and we have our SecOps team that kind

00:43:27.019 --> 00:43:28.639
of looks after that. And I get a report every

00:43:28.639 --> 00:43:31.300
week, like a vulnerability report that they email

00:43:31.300 --> 00:43:35.230
me. of things that need updating, right? It's

00:43:35.230 --> 00:43:37.349
sort of like an internal workflow that we have

00:43:37.349 --> 00:43:40.010
looking at all of our endpoints. And if you've

00:43:40.010 --> 00:43:42.809
got stuff that needs updating, aka you haven't

00:43:42.809 --> 00:43:45.210
been running your updates often enough, then

00:43:45.210 --> 00:43:48.389
they will email alert you. And I received an

00:43:48.389 --> 00:43:51.250
alert, an email telling me about some package

00:43:51.250 --> 00:43:52.949
on the Mac. And I can't remember what it was,

00:43:53.010 --> 00:43:54.690
but it was something I looked at and I was like,

00:43:54.750 --> 00:43:56.550
no, I don't have that installed. This must just

00:43:56.550 --> 00:43:58.820
be a mistake. So I deleted the email. And then

00:43:58.820 --> 00:44:00.460
like the next week, I got the same thing. And

00:44:00.460 --> 00:44:01.860
I was like, nah, and I deleted it. And then the

00:44:01.860 --> 00:44:03.920
third week, I got the same thing. And eventually,

00:44:04.159 --> 00:44:06.219
I pinged one of the guys, the SecOps guys on

00:44:06.219 --> 00:44:08.579
Teams. I was like, hey, man, I'm getting this

00:44:08.579 --> 00:44:11.739
email telling me about this package that I supposedly

00:44:11.739 --> 00:44:14.400
have that's vulnerable. I don't know. I've never

00:44:14.400 --> 00:44:16.159
used this thing in my life. I don't know. I don't

00:44:16.159 --> 00:44:18.440
have it installed or anything. And we kind of

00:44:18.440 --> 00:44:20.380
dug into it eventually. And actually, it was

00:44:20.380 --> 00:44:22.500
Security Copilot that gave us the information.

00:44:22.699 --> 00:44:27.400
It was a package that was installed as part of...

00:44:27.500 --> 00:44:30.440
another installer. And so it's buried inside

00:44:30.440 --> 00:44:32.699
the contents of another thing. So it doesn't

00:44:32.699 --> 00:44:35.119
show up in my applications folder. It was buried

00:44:35.119 --> 00:44:38.219
somewhere else. And that thing, even though the

00:44:38.219 --> 00:44:40.920
main package wasn't vulnerable or was updated,

00:44:41.800 --> 00:44:45.219
its reliance on this other thing meant that I

00:44:45.219 --> 00:44:48.039
was still getting flagged. So yeah, it's a tough

00:44:48.039 --> 00:44:50.280
problem to do, especially when you're at scale,

00:44:50.380 --> 00:44:53.190
for sure. Yeah, and when you look at, I think

00:44:53.190 --> 00:44:55.989
there are two examples that come to mind, Log4J

00:44:55.989 --> 00:45:00.869
and SolarWinds. Those were very famous for actually

00:45:00.869 --> 00:45:03.909
being able to be abused in the same way because

00:45:03.909 --> 00:45:06.329
they were packaged with other software, actually.

00:45:06.510 --> 00:45:11.570
Yeah, no, 100%. So, yeah, definitely, hopefully

00:45:11.570 --> 00:45:15.590
this is on folks' mind. I think we are going

00:45:15.590 --> 00:45:19.679
to have... continue to have an onslaught of updates

00:45:19.679 --> 00:45:22.820
for not only for windows but for everything for

00:45:22.820 --> 00:45:24.800
the next little while and you know if you listen

00:45:24.800 --> 00:45:27.980
to um to steve gibson and security now i'm a

00:45:27.980 --> 00:45:30.179
big fan so i listen to to that every week and

00:45:30.179 --> 00:45:32.480
you know steve has this theory about for the

00:45:32.480 --> 00:45:34.039
next six or seven months we're probably going

00:45:34.039 --> 00:45:37.179
to see very very high numbers of updates and

00:45:37.179 --> 00:45:39.619
patching and stuff because of ai but eventually

00:45:39.619 --> 00:45:41.619
we're going to find that ai is going to catch

00:45:41.619 --> 00:45:44.800
all of the all of the vulnerable software right

00:45:45.289 --> 00:45:47.809
And so things will taper way down again and we'll

00:45:47.809 --> 00:45:52.690
be good and closer to a place where software

00:45:52.690 --> 00:45:54.909
is perfect because AI is starting to write so

00:45:54.909 --> 00:45:58.050
much of our code and it's also finding all the

00:45:58.050 --> 00:45:59.969
vulnerabilities, right? But at least for the

00:45:59.969 --> 00:46:02.690
next little while, I think until the end of the

00:46:02.690 --> 00:46:04.329
year or so, we're going to be seeing lots of

00:46:04.329 --> 00:46:07.989
patches coming thick and fast. And we really

00:46:07.989 --> 00:46:09.429
need to make sure that we're in a place where

00:46:09.429 --> 00:46:11.849
we can actually get these things deployed out

00:46:11.849 --> 00:46:14.800
to our endpoints in our state. very, very quickly.

00:46:15.320 --> 00:46:19.380
Yeah. Yeah, I saw some recent announcements on

00:46:19.380 --> 00:46:22.579
MDash recently as well. It might be a fun topic

00:46:22.579 --> 00:46:27.260
to perhaps combine in our next episode to see

00:46:27.260 --> 00:46:29.920
what Microsoft is doing to bring AI to the table

00:46:29.920 --> 00:46:33.820
to be more secure on your patch and vulnerability

00:46:33.820 --> 00:46:36.840
management. Yeah, absolutely. No, I think so.

00:46:36.920 --> 00:46:39.179
I think so. Won't be the first time or the last

00:46:39.179 --> 00:46:41.420
time that we talk about this for sure. Yeah.

00:46:42.059 --> 00:46:45.219
So you brought a very fun community project this

00:46:45.219 --> 00:46:49.039
month, Chris. Yeah, I think this one's a little

00:46:49.039 --> 00:46:51.780
bit of fun this month. So we're not looking at

00:46:51.780 --> 00:46:55.159
someone's application or GitHub project this

00:46:55.159 --> 00:47:00.840
month. I've been talking to my friend Micah a

00:47:00.840 --> 00:47:04.019
fair bit over the last few weeks or a few months.

00:47:05.119 --> 00:47:08.219
If you don't know Micah, he's a security MVP

00:47:08.219 --> 00:47:11.780
based, he lives in Seattle, so based out of Seattle,

00:47:11.920 --> 00:47:14.340
out of the US. And one of the great things about

00:47:14.340 --> 00:47:18.019
Micah is Micah is always building stuff. There's

00:47:18.019 --> 00:47:20.739
not a time that I bump into Micah or see Micah

00:47:20.739 --> 00:47:22.860
where he doesn't show me something cool and something

00:47:22.860 --> 00:47:25.199
awesome. He's always building stuff. His imagination

00:47:25.199 --> 00:47:28.219
is insane. But anyway, he's been working on this

00:47:28.219 --> 00:47:31.900
little... security, it's like a Microsoft security

00:47:31.900 --> 00:47:35.219
related quiz game called Who Wants to be a SISO?

00:47:36.000 --> 00:47:39.639
And it's sort of, he hasn't really announced

00:47:39.639 --> 00:47:43.119
it yet, but he shared it with myself, with me

00:47:43.119 --> 00:47:47.239
and Nick, Nick Blank, a week or so ago. And I

00:47:47.239 --> 00:47:49.920
did speak to him this morning. He was happy for

00:47:49.920 --> 00:47:51.760
me to share this, you know, on the recording.

00:47:52.480 --> 00:47:57.329
But essentially, I think he built it for... If

00:47:57.329 --> 00:47:59.550
you're running a booth or something at a conference

00:47:59.550 --> 00:48:02.250
and you have a very large screen, you know, you

00:48:02.250 --> 00:48:04.690
can sort of get people to be interactive with

00:48:04.690 --> 00:48:06.250
what you're doing. But I think this works really

00:48:06.250 --> 00:48:08.929
well as, you know, like a fun version of Kahoot.

00:48:09.130 --> 00:48:13.269
I know lots of folks do the Kahoot quizzes as

00:48:13.269 --> 00:48:15.690
an icebreaker or something where, you know, if

00:48:15.690 --> 00:48:19.030
you're doing a meetup talk or something, we have

00:48:19.030 --> 00:48:21.110
a big screen and folks are, you know, so you

00:48:21.110 --> 00:48:23.550
have the ability to start this up on a big screen

00:48:23.550 --> 00:48:26.139
and then players can join. you know, with their

00:48:26.139 --> 00:48:28.280
phone or whatever and sort of answer the quiz

00:48:28.280 --> 00:48:31.380
questions and stuff. It's so well done. It is

00:48:31.380 --> 00:48:34.360
incredibly well done. A lot of fun. And because

00:48:34.360 --> 00:48:37.599
it's Microsoft and topical and sort of built

00:48:37.599 --> 00:48:39.099
by someone in the community, I thought it'd be

00:48:39.099 --> 00:48:41.539
really cool, cool one to share. So I've got a

00:48:41.539 --> 00:48:43.380
link on it. You know, who wants to be a Sizer

00:48:43.380 --> 00:48:46.420
.com. I think it's .com anyway. Yeah. Let me

00:48:46.420 --> 00:48:47.880
click the link. Yes. Who wants to be a Sizer

00:48:47.880 --> 00:48:50.199
.com. You can play it by yourself too. So if

00:48:50.199 --> 00:48:52.239
you just, there's a sort of solo player mode,

00:48:52.360 --> 00:48:55.519
if you want to just play it by yourself. But,

00:48:55.519 --> 00:48:58.460
yeah, a really fun thing. Just, you know, think

00:48:58.460 --> 00:49:01.739
about it for your next meetup or whatever. The

00:49:01.739 --> 00:49:03.139
next time you have a large meeting and you want

00:49:03.139 --> 00:49:04.760
to just, you know, break the ice or whatever,

00:49:04.940 --> 00:49:07.900
it's a really fun one. It looks really professional

00:49:07.900 --> 00:49:11.800
as well. Oh, yeah. No, he's put a lot of time

00:49:11.800 --> 00:49:14.900
into it. It's pretty awesome. Yeah, it's a lot

00:49:14.900 --> 00:49:17.920
of vibe coding, but also AI -generated graphics,

00:49:18.059 --> 00:49:22.050
I assume. But it looks really cool. Yeah, we

00:49:22.050 --> 00:49:25.369
had Micah talk to us on the Cloud Architects

00:49:25.369 --> 00:49:29.090
podcast a few weeks ago. And we had an episode

00:49:29.090 --> 00:49:32.210
about vibe coding specifically. And we talked

00:49:32.210 --> 00:49:34.809
about some of the tool sets and the things that

00:49:34.809 --> 00:49:37.570
he platforms that he uses and stuff. And I think

00:49:37.570 --> 00:49:39.489
this was one of the things that came out of that.

00:49:39.610 --> 00:49:43.409
So really, really fun. I've linked Micah's LinkedIn

00:49:43.409 --> 00:49:45.289
as well. He's one of those cool guys in the community

00:49:45.289 --> 00:49:49.880
that he's always open to being, you know. folks

00:49:49.880 --> 00:49:51.820
to reach out to and connect with so you know

00:49:51.820 --> 00:49:53.739
if you if you like what he's done say hi to him

00:49:53.739 --> 00:49:57.179
and and uh yeah that's um that was what i wanted

00:49:57.179 --> 00:49:59.460
to share for for this this week's community project

00:49:59.460 --> 00:50:02.400
um i will say on the topic of on the topic of

00:50:02.400 --> 00:50:04.739
community projects i have been working on connect

00:50:04.739 --> 00:50:07.360
365 i know we talked about it a few episodes

00:50:07.360 --> 00:50:10.519
ago um i've been working on it really really

00:50:10.519 --> 00:50:13.980
pleased with sort of what um where it's going

00:50:13.980 --> 00:50:15.880
in the direction that we're going so i'm hoping

00:50:15.880 --> 00:50:18.159
by next I'm trying to keep myself accountable

00:50:18.159 --> 00:50:20.179
here. So hopefully by next episode, next month,

00:50:20.320 --> 00:50:23.320
I will be able to share more about the next gen

00:50:23.320 --> 00:50:29.699
Connect 365 and where we go with that. Very cool.

00:50:29.800 --> 00:50:32.139
And I think it's fun to have a community project

00:50:32.139 --> 00:50:37.199
for a change, which isn't used on our day -to

00:50:37.199 --> 00:50:40.739
-day basis or highly technical. It's a fun showcase

00:50:40.739 --> 00:50:44.659
of what AI is bringing us and some positive things

00:50:44.659 --> 00:50:48.400
as well. And let's link the Cloud Architects

00:50:48.400 --> 00:50:51.119
episode with Micah talking about this as well

00:50:51.119 --> 00:50:54.800
in the show notes. Yeah, good call. Good call.

00:50:54.880 --> 00:50:57.059
We'll do that. That episode is live, so we can

00:50:57.059 --> 00:51:00.139
link that one for sure. Cool. So then I guess

00:51:00.139 --> 00:51:02.159
it's time to wrap up again, Chris, don't you

00:51:02.159 --> 00:51:04.719
think? Yeah, time flies when you're having fun,

00:51:04.820 --> 00:51:08.800
doesn't it? It is. Well, it's 9 a .m. in the

00:51:08.800 --> 00:51:12.159
morning, so I'm about to start my workday, and

00:51:12.159 --> 00:51:15.980
I think you're rounding it off there in Brisbane.

00:51:17.019 --> 00:51:18.400
Rounding it off in Brisbane. I think I've got

00:51:18.400 --> 00:51:21.280
a few emails and Teams messages to reply to,

00:51:21.380 --> 00:51:23.820
but it won't be long now before I go grab some

00:51:23.820 --> 00:51:28.579
dinner and settle in. Yeah, always good to see

00:51:28.579 --> 00:51:30.039
you, as I said before, it's my favorite part

00:51:30.039 --> 00:51:32.300
of the month. So thank you for making the time

00:51:32.300 --> 00:51:34.239
and thank you folks for listening. Obviously,

00:51:34.340 --> 00:51:37.960
as I said, please, if you have any questions

00:51:37.960 --> 00:51:40.000
or comments or anything like that, please find

00:51:40.000 --> 00:51:43.199
us on the socials. We are pretty much, LinkedIn

00:51:43.199 --> 00:51:45.679
is probably the best one, but grab us on LinkedIn

00:51:45.679 --> 00:51:47.980
or GitHub or anywhere else. Or leave a reply

00:51:47.980 --> 00:51:51.059
on your podcast platform, Spotify, Apple Podcasts,

00:51:51.059 --> 00:51:53.519
whatever you're using, we'll pick it up from

00:51:53.519 --> 00:51:57.099
there as well. Yeah, yeah. very much so so yeah

00:51:57.099 --> 00:51:59.059
we're always interested in any sort of comments

00:51:59.059 --> 00:52:01.699
or suggestions or anything like that if not um

00:52:01.699 --> 00:52:05.000
coast we'll see you uh see you again uh you know

00:52:05.000 --> 00:52:07.039
next month and um thank you folks for listening

00:52:07.039 --> 00:52:09.860
thanks everybody for listening have a great day

00:52:09.860 --> 00:52:11.059
bye