Welcome to the Everyday Defender podcast.
I'm your co-host Chris Goosen and I'm joined by my co-goose, Koos.
Hey Chris, how are you doing?
Doing great, doing great.
Hey, I figured co-parties are everywhere, right?
So you may as well have a co-goose if you're going to be doing a podcast.
Then it's three geese in a podcast, right?
That's right.
In today's episode, we're very, very excited today to be talking about MFA.
I had some thoughts about MFA.
I've been working sort of with customers in that MFA space for a while now, but recently
I kind of rethought, you know, went through this process of just reflecting a little bit
on the state of MFA and I thought it'd be good for us to share, for me to share that
with you.
We'll talk about MFA and some guidance around there.
And then Koos, you had some some Parsky's news and things you wanted to talk about,
right?
Yeah, I recently dabbled into Parsky's FIDO2 enrollment.
So I ran into a couple of challenges there I wanted to share.
Excellent, excellent.
I'm sure that I'm sure there's going to be some really, really valuable information there.
So what else have you been doing the last the last couple of weeks?
Well, I was actually involved in a rather large security breach at one of the customers.
So that was kind of tough.
Unfortunately, they weren't finished with putting everything in Microsoft security stack
just yet.
And well, what a coincidence that they just targeted and entered some kind of VPN tunnel
with a too easy to guess password, you know how it goes.
But it was very unfortunate.
So I was kind of busy with that one, to be honest.
Yeah, well, it's it's always unfortunate when when these things happen, because for one,
for guys like us who are kind of helping respond to these things, it's really valuable information
right often.
So so there's there's a level of real interest there.
But it also is devastating for the customer, right?
And for the environment that you're working in.
So I can definitely understand that.
That's that's yeah.
And it's also a bit like though I told you years ago to stop doing that.
Why are you still but yes, we all know how it goes.
But essentially, bottom line, we learn from it, the company learns from it.
And I hope I can share some details later so that others can also learn from their mistakes.
That's awesome.
Fantastic.
Well, while you were doing that, I've been on holiday or vacation, I guess, for our American
listeners.
So I haven't been doing a whole bunch of anything.
So it's been well, I say that.
But I also I haven't been doing a whole lot of IT tech work, right?
I you know, I do I live on a farm.
So this kind of always something to be done around here.
We've got we've got some alpacas down in the paddock.
So there's always there's always some sort of animal related stuff.
But other than that, I haven't really been doing too much.
But you're able to wind down doing that, right?
It's been good.
But I think it's going to you know, things start kind of getting crazy again towards
the end of the year.
And it was good.
It was a good unwind.
I think we all need to take some time for our mental health and all of that every now
and then just to to unwind.
Yeah, I'm glad to succeed.
So into it, I guess, let's get into to MFA.
And so, you know, one of the things I was thinking about this a little while back, you
know, we've I think we've all been talking about MFA and telling customers, telling anyone
who will listen that MFA enable MFA on everything.
Right.
I think that's that's kind of been the message now for probably a whole like a decade.
We've been here and say that.
Right.
Sadly, though, I I still see organizations, you know, that don't have any MFA.
Right.
Nothing.
Not just, you know, pockets, but zero.
And almost always the excuse is that there's a particular business case or a particular
use case that it prevents them from from from deploying MFA.
So they they pause the whole project for everyone because they're trying to solve, you know,
for a very, very small group of people.
And I feel like that's a that's a real problem.
So one of the things I kind of wanted to talk about a little bit was, you know, well, MFA,
is it is it still relevant for us today?
Do we really care?
Is it an unachievable sort of utopia that we will never get to?
And I think, you know, for me, definitely, I think that we definitely still care about
MFA.
MFA is more relevant now than it's ever been before.
Right.
And I know we have all these kind of shiny new things like pass keys, which we'll get
to a little later.
But I think MFA is still really, really critical for a lot of environments, all environments,
really.
And I don't think it's an unachievable utopia.
I think that there are some things that can be done in every environment that that can
help secure that environment.
So I really wanted to kind of break into this a little bit.
And, you know, like I said, I think instead of saying go out and configure MFA, what I
wanted to do today was talk a little bit about here's how you can go out and configure MFA.
Here are some things you can do to look at that MFA deployment.
So if we start with where should we be right now, like what is our baseline or at least
where should everyone be?
Right.
So depending on who you ask, you may get some different opinions here.
Personally, I think that you should be in a place where you have MFA for everyone.
It doesn't matter whether they're an information worker, end user or admin, privilege user.
They should, everyone in the environment should have some form of MFA.
I don't really mind what it is.
Right.
I mean, obviously, we know that certain MFA factors are better than others.
Right.
So, you know, weak, fish resistant, FIDO2, very strong and everything in between.
It doesn't really matter.
As long as you're at that place where you have MFA for everyone, I think you're in a
fairly good place.
But as with everything, I think there's a lesson here that your MFA deployment is not
set and forget.
It's not something you're going to just set up, walk away from, and that's the end of
it.
Right.
So, habits, all of these sort of the tactics and techniques continue to change.
So we need to continue to evolve and mature the way that we deploy these things.
And so what I wanted to talk about here is how we do that practically within the night
bar.
Right.
Personally, I think that there's the way that you want to be deploying these things and
deploying MFA is with conditional access.
Now to do that, you need at least an entry ID P1 license in your M365 environment or
when you enter environment.
I understand that not everyone has that, but, you know, if you have a small business license
with M365, small business premium, you'll have that too.
If you don't have P1 at all, I would strongly urge you to think about that because conditional
access is very, very important tool in your security arsenal.
Right.
So if it's just for MFA, but there are a lot of other things you can do with it with conditional
access.
And I think it makes a lot of sense for you to be considering that and planning towards
that in your next true up.
But let's assume you have at least entry ID P1.
What you want to be doing here is I think you need at least two policies for your MFA
deployment.
Why two?
Well, I'm going to tell you.
The first policy that you need is one that applies MFA to all users across the org.
So you're actually going to scope that to your cloud apps and you're going to apply
it to the all users setting, right.
In the environment.
That's pretty simple one, pretty self explanatory.
The second one, and I think this is the one that a lot of organizations kind of miss is
you want one that applies to your admin roles as well.
So you want a conditional access policy that applies and is scoped to the admin role itself.
Not a group that contains the admins, not the individual users who are admins, but to
the role itself.
That way anything that assumes the role of an administrator, global admin or any of the,
I don't know, there's like a hundred admin roles, right.
Any one of those roles within the tenant will then be forced for MFA.
And one of the reasons why we want to do this as a separate policy is that you can then
start maturing that and you can start hardening that.
So what you could do is when while the rest of the organization is maybe using the authenticator
app for their MFA, you can start looking at the administrators and saying, hey, we think
that we want to do some fishing resistant MFA here, right.
And I'll talk about a fish resistant MFA in just a second, but you can then apply that
fish resistant MFA only to admin roles.
And already then what you've done is you've taken that next step to hardening the environment
just a little bit more and you've taken that sort of next, the next level of maturity.
So two policies, one for all your users, one for your admin roles.
And if you can start looking at how you implement a fish resistant MFA for those admin roles,
right.
And by that, we mean you want something that is FIDO, FIDO2, that's FIDO2 tokens.
I have some of these ones that I use.
I personally, I'm a very big fan of these token two tokens.
I think the price point on them is great.
I really like using them.
They come in different form factors.
So you can, if you want to put credit card thingy in your wallet, that's great.
This is not an ad for token two, by the way.
We can mention the YubiKeys and all the other ones as well.
So it was not sponsored by.
Not sponsored by token two.
But that's great with conditional access Chris, focusing on the roles is much better than
focusing on groups, right.
Because we all know how it goes.
People are added into groups, removed from groups.
And now that you're scoping on a role, you know that you cover all of the admins all
of the time, right?
100%.
That's it.
From that perspective, then it doesn't matter if someone's trying to slip themselves into
an elevated role or what have you, whatever happens, you're now forcing that fish resistant
MFA on the admin roles, right?
So I love it.
You're probably going to have to exclude the directory sync role if you're running inter
ID connect.
Otherwise, your inter ID connect will not sync because it's also going to be expected
to MFA.
But you know, that's something that you want to deal with.
So back to those fish resistant MFA.
So we mentioned FIDO.
Anything that's PKI based as well, I think is pretty good, right?
And I think, of course, you're going to talk about pass keys and stuff in a second.
But you know, that's kind of where you want to be going.
Pass keys, Windows Hello for Business falls into, I think, that category as well.
Those types of sort of hardened fish resistant MFA methods, right?
So I think that really is what you do.
Now you may be asking, okay, two policies, this interesting.
I've heard folks talk about many baseline conditional access policies.
You'll get different opinions from different folks in the industry.
And they may be, you know, they're perfectly valid opinions.
Every environment is different.
So you may need more policies.
I like the two policy approach because it's a really easy baseline to configure.
It also aligns very well with the CIS benchmarks.
So I use the CIS benchmarks a lot when I do assessments of customer environments.
And CIS 4.0, two policies, that's kind of their recommendation with fish resistant MFA
on the admin roles.
So you'd be getting yourself CIS compliant if you did that straight away.
And I'm happy to see that Microsoft is now also starting and forcing their customers
to apply MFA, right?
With the Azure portal and more stuff is on its way.
Because I still see companies excluding just too many users or entire groups with lots
of users.
Like you said before, because they just think it's a hassle to onboard the MFA if it's an
authenticator app or SMS or whatever.
They don't want to put that burden on their users and they just exclude those users.
And well, soon you cannot find, not sure what the deadline is or already passed or later
this month.
It's the exact date, but soon you won't be able to exclude that any longer.
That's right.
I mean, that secure future initiative is coming for you, right?
So better be prepared with it.
And I think that you bring up a very good point because when it comes to exclusions,
what about those break glass emergency accounts, right?
We've been saying for years, you need to break glass accounts, you need to make sure that
they have strong passwords, that the passwords are stored in a safe, that type of thing.
We've also been saying for years that those accounts should be excluded from MFA.
Well, that's no longer the case, right?
We're at a place now where even your break glass accounts need to have MFA.
Obviously, you don't want to have MFA registered on one person's device in that instance, because
if Johnny or Jane are on a beach in Aruba and that MFA is needed, that's never a good
place.
So this is one of those things, again, where FIDO2 tokens makes perfect sense because you
can keep the token in the safe as well.
You want to think about your processes around all of this, right?
Don't just sit and forget that you've got a process there of managing those accounts,
the passwords, testing the logons occasionally.
You also want to then obviously be testing those tokens, making sure that that stuff
works, that there's a well understood procedure and process for how do we actually use these
things?
How do we develop this and use these accounts?
So all of those things need to be documented and thought about as a process, right?
Really, really important.
So regarding the break the glass, Chris, I actually recently discovered a feature in
a password vault from Keeper.
We use Keeper at the company as a business solution for a lot of our passwords.
And I actually discovered that Keeper provides a way to provide a OTP based MFA method inside
Keeper.
And the great thing about that is if you share those credentials with other people which
should have access to the break the glass account, they can actually pull out the OTP
from Keeper, put it in the login.
To be honest, technically it's not the most secure and best solution because you still
have a dependency on the Entra ID MFA service.
So people at Microsoft will tell you that the FIDO2 key is even better.
And I would agree with that.
But like you said, the FIDO2 key is living in a safe.
Now you should also think about the process.
How can we enter that safe?
Who has the key to that safe, right?
A whole bunch of challenges might arise.
And that's why I do think that although it might not be on the top of the list regarding
the securest way, I think it's secure because it has a different additional dependency.
There might be an issue with Microsoft services while causing the OTP MFA not to work.
But I still think it's much better than SMS or Authenticator from the CEO on the beach.
That's right.
And I think that's a really good point because again, just small gains here, small things
that you do add up over time.
So don't let perfect be the enemy of good with this.
If today your break glass accounts are there and they're excluded, the next really good
step could be something like that.
I know Bitwarden does the same thing you can have in password vault OTP as well.
There are other solutions as well that you can look at.
Think about these things.
And the important thing is to revisit these things.
If you're going to do this today, next year or in the next six months, whenever you're
looking at all of your security again, look at these things and see if there's a better
solution or if there's a better option available for you.
So yeah, I hear the argument a lot of times as well at customers that they don't want
to enforce an Authenticator app, for example, on mobile phones because they're privately
owned devices and some employees don't want to mess with business apps on their privately
owned devices.
Right.
I think it might be not a popular opinion, but then go for SMS MFA.
It's even better than no MFA.
And especially where phone companies make it harder to copy SIM cards nowadays.
I think, well, of course it's still a risk and other MFA is better, but it's better than
nothing.
Again, a hundred percent.
And these are the types of things that I think we come up with.
Real world example is I was working with a customer not too long ago and this exact thing
came up.
This customer, most of their users belonged to a U.S. based customer.
Most of their users belonged to a union.
And as part of the union, they do not allow the use of personal devices for work activities.
Their stance on this is very much that if it's going to be used for work, workers to
provide it.
For the company or for the organization, very large expense to be providing phones for everyone.
But you can provide these things to people for relatively, it's relatively affordable
compared to providing someone a new iPhone every few years.
And you're right, this happens.
I think in Europe where you are, it's quite common to either be provided a work phone
or not be expected to use it at all.
I know I worked for a Swiss company before and it was the same thing.
The company just said, you will use our phone.
It's secured by our policy.
And if you want to access anything outside of the office, this is what you use.
So I think that's one of the reasons why the iPhone SE is doing so well in Europe as well.
Right, they still make that thing.
It's a portable iPhone and it has a very long support period.
So that's probably the choice that most companies are making.
Fair enough.
I mean, look, if you're really just using it for Teams email and authenticator, there's
probably not, you probably don't need a great hunking phone.
So look, I think to summarize and some takeaways here, and obviously, folks, we're going to
put all of this information in.
We'll link this to the blog, to our blog, and we'll be able to kind of read all this
information.
So don't worry if you haven't summarized all of this while we've been talking.
But some takeaways here that I kind of wanted to leave you with here is if you don't already
have MFA deployed, I think it's really, really important to start somewhere.
If you have a particular use case, a particular group of users or whatever you that can't,
there's no immediate solution for, that's okay.
Work on that in the background, but continue to deploy your MFA across the org to other
folks.
I think it's really, really important that your admin accounts are very well secured.
Look at that Fisheries system MFA.
And then make sure you limit exclusions.
I think it's far too easy in environments where, especially where you have a lot of
admins, it becomes very, very easy for folks to just start excluding and excluding from
policy.
It's not a good place to be unless you absolutely have to.
So yeah, not all or nothing.
And it's really not all said.
It's not said and forget.
This is something that you want to, as with all your security configurations and processes.
And we're going to talk a little bit later in the episode when we look at our community
tool spotlight, we'll talk about some tooling to kind of help you with some of the sort
of continuous improvement stuff.
But yeah, MFA, it's not going anywhere, I don't think.
But Kos, why don't you tell us about Parsky's and kind of what you've been up to in that
space.
Yeah, thanks, Chris.
MFA is actually, it should be a no brainer, especially when you see that the password
attacks are still the most popular attacks and main reasons why adversaries are entering
your company's organization, the company's network.
But although the password attacks are still the most popular attack factor, we also see
a rise in phishing for MFA.
So called adversary in the middle attacks, where an adversary is in the middle between
you and the authentication.
And they actually are able to phish your session token.
So you think you're authenticating to the portal, to your application, but you're actually
sending out the authentication key to the adversary, which can steal your token.
And as long as the token is valid, they can authenticate as you and probably register
an additional MFA method, for example, so that they have some kind of persistence and
can keep coming back.
I was really scary.
Like I've seen some of the tooling that they use for that.
Yeah, it's I mean, you know, you'd be able to convince most folks to.
Yeah, I also want to encourage people to start messing with those tools as well.
One of the most popular ones is Evil Genics, probably well known in the community.
It's an open source tool you can run as a proxy between and simulate this kind of attacks
where the user sees a Microsoft online dot com URL, but the O is a zero or something
like that.
So with a slight change, they'll probably won't notice that all kinds of impressive
demos with that.
And indeed, it makes you think the next time you connect to Starbucks Wi Fi, is it really
the Starbucks Wi Fi or am I connecting to a spot in somebody's backpack?
Right?
Well, don't ever connect to the Starbucks Wi Fi.
That's the easiest solution there.
But now I hear what you're saying.
And, you know, I think it's an interesting concept because these tools exist.
And if you bury your head in the sand and ignore them, it doesn't mean they're going
to go away.
Right.
And I think Merrill Fernando from Microsoft sort of posted on LinkedIn or X the other
day and he was wrestling with the issue, right?
Is how much information do you provide folks?
Because when you provide them enough information, they can either choose to use that information
as in a good way as a defender to protect their environment.
Or that same information can also be weaponized and used in a bad way.
Right.
And I think it's one of those things is if you just ignore it, it's not going to go away.
So I think it's really good to be talking about the tools that are being used, getting
folks across that stuff and familiar with it so they know how to defend against it.
Yeah.
And again, I still stand by my earlier remark.
If your only MFA option right now due to all kinds of policies you have in a company is
SMS MFA, it's even better than none.
But I would strongly encourage looking into the pass keys as an MFA method.
Or if you're already using MFA with your authenticator app, look into pass keys as well.
So pass keys is a pair of cryptography keys, right?
Like you mentioned earlier, as a PKI based authentication where the private key is protected
on the device by a pin or biometric authentication with a fingerprint or something like that.
And pass keys you can use as a passwordless login as well.
And you're probably seeing a lot of sites popping up lately providing you the option
to register a pass key, GitHub, Google.
Google is annoyingly good at that.
It pops up all the time.
And if you're not paying attention, you just generate pass key.
Yeah.
And the other day I had a look and I had all these pass keys and I'm like, I don't even
remember where I generated these things.
So they were annoyingly good at pushing that out.
Yeah.
And then especially when you're using a password vault, if you're either using Apple's own
iCloud key chain or something, or one password or LastPass or Keeper or whatever, you can
store those pass keys in your password vault and you don't even need to know a password
to authenticate to that website, right?
So there are actually two types of password pass keys.
So these are the cloud syncable pass keys we're talking about, but Microsoft is currently
not providing those types of pass keys just yet.
They might in the future.
I don't know.
So currently they only offer device bound pass keys, which means that the pass key is
bound to a physical device, either a FIDO2 key, which is also a pass key.
You held them up in front of the camera earlier.
We're familiar with those.
But recently Microsoft also provided you the option to register a device bound pass key
inside their authenticator app on your phone, which essentially makes your phone a FIDO2
key, if you will, so to speak.
And the way that that works, you scan a QR code from your screen with the authenticator
app and then you authenticate.
And I was like, this is kind of peculiar, right?
Why is this phishing resistant?
How can a attacker not generate a QR code, which I need to scan?
But the problem is, well, the solution there lies in the fact that the device you're authenticating
with needs to be in a close by proximity of the actual authentication.
And that's also why Bluetooth is used on your smartphone, for example, or with a FIDO key,
you physically bring it to the computer, right, and stick it in.
And that's why Bluetooth is also required on the device.
And although it is the safest method of MFA right now, pass keys, it also comes with a
couple of limitations, of course, because that makes sure that we won't run out of work,
Chris.
Well, I was just going to ask you how ready for prime time is this?
Because just to take a second here, I think we talked earlier about MFA and deploying
the authenticator app.
Well, if you've already done the work to deploy the authenticator app to your end users and
they are already using it, that makes it a little bit easier for them to then adopt something
like pass keys, right?
So again, there's that sort of maturity that can be done.
Yeah, I have to put a caveat here is that it's still in preview, the pass key through
authenticator app.
So that might already be a reason companies will probably stay away from it until it becomes
GA.
But there is now a seamless onboarding method from the authenticator apps for like you said,
it's very easy to onboard.
But still, there are a couple of challenges there.
And I would say a FIDO key, a physical keys is already more maybe perhaps a proven technology.
Again, I mentioned the Bluetooth requirements on the authenticator app, which can be a problem
in companies where they want to restrict Bluetooth connections, for example, from your laptop.
And Microsoft has written interesting guides for that.
And we will link them to the show notes, of course, where they help you restrict Bluetooth,
but allow the authenticator app smartphone connection, for example, through an Intune
policy deployment, for example.
But when I was at the company I worked for, we were actually enforcing the phishing resistant
MFA strength.
That's what Microsoft calls it inside the conditional access.
And we actually ran into a completely different issue.
And I wanted to highlight that as well today.
We had external contractors logging on an Azure Virtual Desktop environment.
And the Azure Virtual Desktop environment is a trusted environment.
Those devices are compliant.
And thus from there, they can authenticate into all the company apps.
And with conditional access, we check device compliance, we check risk status, all those
kinds of things.
But the thing is, when those external contractors were using a Mac, and they were using the
remote desktop connection client by Microsoft to connect into the Azure Virtual Desktop
environment, that client does not support Web of N. And that's actually the name of
the protocol used to do passkey authentication, which makes it impossible to do a seamless
phishing resistant MFA connection on the remote virtual desktop machine with a FIDO key stuck
into the local MacBook, for example.
Interesting.
Yeah, that is a challenge.
That is.
And of course, Microsoft will tell you, well, you can onboard the Mac and use how do you
call it, a system level, a single sign on or something like that with Intune.
Of course, you can do that.
And then you can use the FIDO key locally on the machine.
That's no problem for Mac as well.
But if you are relying on a remote desktop connection in between, you're kind of screwed
actually.
Interesting.
And obviously, in a contractor scenario, that's why you would have that, right?
Is you have contractors bringing their own devices and you want to put them on their
remote desktop because...
Yeah.
So this is still a major downside.
And I also noticed that even Windows users using the remote desktop connection app from
the Windows Store, which is funnily enough, exactly the same as the MSI you download and
install.
It looks the same, has the same icon, but the Windows Store version also does not come
with WebAuth and redirection abilities.
And this probably has something to do with the fact that those Windows Store apps run
in a kind of containerized sandbox-like process on the machine.
And that's why they cannot reach out to the USB port or the Bluetooth connection to process
that.
Okay.
That's interesting.
Wow.
Yeah.
So if you're running into those issues with Windows, make sure to download the MSI version
of the remote desktop connection.
And for Mac, I'm really hoping Microsoft is able to figure out an updated connection for
Mac users as well, because this customer actually had to hand out Windows laptops now to those
external contractors to make sure that they're able to authenticate to their resources remotely.
Wow.
Yeah.
And look, there's nothing worse than telling a Mac guy that he has to use Windows.
I know how it feels.
Sacrilege, because that's happened to me before, so I understand.
But I would also like, it's 2024, right?
Are we still having the Windows versus Mac discussion from the 90s?
That's right.
Well, apparently we do.
Yeah.
Okay.
And another thing I also noticed, I'm a big fan of one password.
Although I am stuck into the Apple ecosystem with a lot of my devices and photos and everything,
I tend to like the idea that my passwords and everything are still in a third party
company, right?
In this case, I've chosen for one password.
But the thing is with iOS, when you use one password to automatically fill in the passwords
for you and the pass keys, for example, and you want to enroll the pass key on the Microsoft
Authenticator app, you have to make the Authenticator app the primary application to fill in the
passwords for you, because otherwise Authenticator app will not pop up being able for you to
complete the authentication request.
Luckily, iOS 18 solves this issue, and I know it's already out now for a couple of
weeks, but when I was struggling with these issues, iOS 18 was still in beta, and iOS
18 now allows you to select multiple password providers.
And I believe this wasn't an issue on Android devices.
So also keep in mind, if you're running into it, do this issue, update to iOS 18.
Interesting.
That's good info.
I think that being able to use multiple password managers and all that, I think it's important.
And I think the adoption of pass keys, I think, is only going to continue to grow once we
can actually properly sync them.
Because I think the FIDO Alliance is actually, they're working on actually allowing it as
part of the actual, what do you call it, the standard, right?
To allow the synchability and make it a little bit more open for everyone to be able to sync
these things.
So yeah, good to know.
I used, like you, most of my stuff is Apple too.
I use BOOKWARDEN as my password manager.
I also like to have that third party thing that's just outside, right?
Just keeps things kind of nicer from a cleaner, I guess, from that perspective.
So very, very nice.
Any closing thoughts on pass keys here?
Well, yeah, I think I already gave that away, I guess.
I think it is, especially FIDO 2 keys is the way to go, in my opinion.
But again, if you want to stick with SMS for now, do that instead of don't enabling it
at all.
But also be aware of some potential downsides with the FIDO 2 keys.
You have to hand them out.
Also a thing you have to remember, if you really want to enforce phishing-resistant
MFA on all users, you also have to think about an additional step when you onboard new users.
Because if you have a new user and he or she authenticates for the first time to your environment,
normally you would receive a pop-up asking you to register your authenticator as an MFA
method.
For FIDO 2 keys, pass keys, that is unfortunately not yet possible.
And since you are forcing the conditional access policy to require an MFA method with
a phishing-resistant strength, you cannot register.
So you have an egg problem.
So the way you can work around this is by registering a temporary access pass with a
new user for the first time.
It can be a one-time valid, for example.
They authenticate with the temporary access pass, and then they register the FIDO 2 key,
and that will be the authentication method for all future authentications.
Yeah, but also take a look at Evolgenics and how scary and easy it is for adversaries to
phish your session tokens.
And yeah, I think this should really be on your list of to-dos.
Yeah, absolutely.
Thank you.
I think that's great.
We have that in the show notes, so we can definitely refer to that.
One of the things we want to do with the show as part of providing this information to folks,
I think, is we want to highlight a lot of the really good work that's coming out of
the community.
And there's a lot of work being done by MVPs and just folks in the broader Microsoft and
security communities to help everyone get more secure.
One of the things I think for this week that we wanted to talk about, or the thing for
this week that we want to talk about, is a project called Maester.
Now, if you are into inter-ID at all, then you probably follow Meryl Fernando on the
socials, and you'll know that he is not an AI bot, but in fact, a very, very smart fellow
that works for Microsoft.
He's actually based here in Melbourne, in Australia.
Now, part of a project that Meryl's been involved in, and he's not the only one, he seems to
be the face of the project, but I know there's Fabien and a bunch of other guys that are
folks that are involved in this project, is called Maester.
What it is, is it's essentially an easy button for being able to run continuous testing on
your M365 environment.
It's a PowerShell module that allows you to run a bunch of tests against your environment
and basically see the output and outcome of those tests.
You can run those tests as a one-off to see, draw a line in the sand and see where you
are, or if you really want to take your set ops to the next level, if you will, and look
for things like configuration drift and all of that.
You might run this on a continual basis occasionally every now and then, just to see if there has
been any conflict drift in your environment and look at how you could improve it.
I wanted to bring that up today.
If you haven't come across it, well, firstly, you've got to go follow Merrill, at Merrill.
Merrill has great content, but also Merrill posts about Maester and the Maester project
a lot.
There are a ton of other MVPs associated with that.
Sorry, guys, I don't have everyone's names to hand, so I'm not trying to discredit you
in any way or not give you the credit where it's due.
I know this has been a really big community project.
But out of the box, there are a bunch of tests already available.
So the Scuba framework, which is the American CESA agency, has sort of provided that.
There's a bunch of community-built tests for entry and conditional access and things like
that.
I think there are 36 or 37 tests already just out of the box.
Because it's built on Pesta, the Pesta test framework, you can actually go and actually
create your own tests, write your own tests.
So if you're a consultant like I am and you work with customers and there's particular
things you want to check for, you can build those tests yourself.
Or if you work internal to an organization and your environment has some quirks and you
want to build some special tests to look for things like that, you can do that too.
So great project.
Like I said, easy button for continuous testing in your environment.
Called Maester.
Maester.dev is the website.
We will have this information and a link to sort of introduction, intro YouTube video
and the show notes for you to take a look at.
Yeah.
Really great effort.
Yeah.
That brings us to the end of the show.
Man, time flies when you're having fun, right?
Or talking about security.
So you know, a good few interesting few weeks coming up.
We've got Ignite coming up here in, well, next week, actually.
So I'm not sure when we'll publish this.
Probably will be after Ignite.
But we have Ignite coming up.
So in future episodes, there may be some information about what happened at Ignite and some important
takeaways from Ignite.
Definitely.
So be sure to look out for that.
Kost, what do you got?
Anything interesting coming up here in the next couple of weeks?
Well actually, I have a visit to Stockholm coming up.
I'm actually going to ESPC in Stockholm and I was asked to speak there about building
your security data lake with Sentinel and Azure Data Explorer.
So I'm really looking forward to that one.
Yeah, very nice.
We'll definitely share that talk and content once it's all done and does it as well.
So that's some really, really good information.
Summarize it a bit in a future episode.
Yeah, perfect.
Well, thank you folks for listening.
Be sure to like, subscribe on your favorite podcast platform.
You can also catch us if you like video and you like to look at us when we're talking
to you.
You can catch us on the Cloud Architects YouTube channel.
All of the information available in the show notes and associated blog posts.
If you have any tips or sorry, not tips, suggestions, things that you want to see, things that you're
fighting with, grappling with in your environment or things that you're just not sure about,
reach out to us and we'll see what we can do to build an episode around it or to kind
of get you that info.
But until next time, thank you very much for listening and Goose and Goose signing off.
See you next time.
Bye bye.