Welcome to the Azure Security Podcast,
where we discuss topics relating to security, privacy,
reliability, and compliance on the Microsoft Cloud Platform.
Hey everybody, welcome to Episode 67.
This week is just myself, Michael and Sarah.
I'm going to guess, Bronwyn Mercer,
who's here to talk to us about privilege access.
But before we get to Bronwyn,
why don't we take a quick lap around the news?
Sarah, why don't you take things off?
Okay. So, yeah.
So, first, I've got one bit of,
it's news and also an ask to folks.
So, you may know that at Ignite,
we announced the preview of Defender for DevOps.
So, we're actually asking folks to go and try the preview
and actually give us your feedback on it.
So, we'll put the link to the questionnaire
in the show notes.
It can be anonymous as well,
so you don't have to give us your details.
But please give us your free and frank,
the good and the bads about it if you've had a play.
If you haven't, then please go download the preview
and have a go with it,
because the product group for Defender for DevOps
would love to hear your feedback.
So, yeah.
As I said, I'll put the feedback link in the show notes.
And if you've had a play and you want to tell us
what you think, please do.
And that's just, that's me for this week, Michael.
Very cool.
Hey, I've got a few items.
So, the first one is,
and this is actually really good to see actually.
So, as your resource manager, so I'm starting next year,
we'll start deprecating older versions of TLS.
So, TLS 1.0 and 1.1.
You may think, oh, you know, no one's using TLS 1.1 or 1.0.
You'd be surprised.
It amazes me how, from a compatibility perspective,
we have to have like a long, long lead time
to deprecate some of these things.
Yeah, it's a hard problem.
So anyway, that's gonna be linked to that in the show notes.
Another one is back to TLS.
So, application gateway now supports TLS 1.3
and TLS 1.3 Cypher Suite, which is great to see as well.
On a, one of my favorite sort of services in Azure
is Azure Key Vault and Azure Managed HSM.
So, Azure Managed HSM now has the ability
to offload TLS traffic to Managed HSM.
So, there's a library that we've produced.
So, in your code, you can actually do the crypto
inside of Managed HSM, which is actually kind of nice
because that way it reduces one of the performance bottlenecks
certainly in the, you know, the initial kind of handshake
of the TLS communication.
On a personal note, my book with my colleagues,
Heinrich and Simone is finally out.
That's finally done.
I've got my, I've got it in my pinkies right now.
So, designing and developing secure Azure Solutions
is now available for order.
It's great to finally have it done.
Also, on a sort of personal note,
so last week I was in Seattle
and I talked at a SQL Database Conference,
which is actually the first time I've ever actually
spoken to a, what, database, like a pure database conference,
which was actually a lot of fun
because, you know, here's the security guy talking about,
well, security in general, like security discipline
to a database audience.
And it was very well received and I got a lot of feedback
and also, you know, I learned a heck of a lot at the same time.
Also, while I was there, we released SQL Server 2022.
So that's now generally available.
I'll provide a link to a YouTube video
hosted by Anna Hoffman.
She's in the SQL Server team called Data Exposed.
And towards the end, I talk about some of the features
that are in SQL Server 2022 from a security standpoint.
So that's all the news I've got.
So with that, let's hand it over to our guest.
So as I mentioned this week, we have Bronwyn Mercer,
who's here to talk to us about privileged access.
So Bronwyn, first of all, welcome to the podcast.
And second, why don't you give our listeners
a little bit of an overview of what you do?
For sure. Thanks so much for having me.
It's a real privilege to be here
and to be part of a podcast, which I listen to myself.
But to introduce myself as Michael mentioned,
my name is Bronwyn Mercer
and I work as a security architect
in Microsoft's consulting services team.
So I get to work with organizations all around Australia,
New Zealand and APAC.
So I'm based in Sydney, Australia
to help them implement Microsoft technologies.
And what that means is making sure that I help those customers
to bake in security by design.
I've also worked in Microsoft's Compromise Recovery team,
which is a really interesting team
that works with customers to recover them
when they experience a serious cyber attack.
So I bring all of that experience
from recovering customers
into now the proactive side of security
and help customers to defend against
real life examples of breaches.
So yeah, it's really interesting.
And I get to use a lot of cutting edge technologies in my work
and I get to work with organizations
who are pushing the boundaries of what's possible in technology.
So excited to share some stories about privileged access.
It's something that I encounter in every customer
regardless of whether we're working on a identity-based solution.
There's always some element of privileged access
that we have to look at.
I'm Fran, I'm gonna say let's go back to basics
and just level set for the audience.
What is privileged access?
What are we talking about when we say privileged access?
Just so we're all on the same page.
Yeah, it's a good question.
I think there's multiple layers of privileged access
in any environment.
When we talk about privileged access at Microsoft,
we have some models around privileged access.
So our enterprise access model,
which is on our securing privileged access guidance.
And that includes layers like the admins
who have control over your identity systems.
So classic one is like Active Directory
and Azure Active Directory.
If you have admin access at that layer,
you basically have control over the whole environment
since most organizations integrate all of their systems
with a centralized identity access management system.
And then we have administrative access
or the ability to make foundational changes to a service
in a specific application or service.
So that could be maybe your SQL server
since I know Michael likes databases.
So there's those different layers in the environment.
I consider, we used to have this thing called the tier model
in on-prem environments.
And tier zero is really the most privileged type of access,
which is the first one I talked about,
which is your admin access in your identity system.
And then we had tier one,
which is admin access within a specific service,
like a business application.
And then tier two is your admin access
at the user device level.
So maybe it's like your intern admins
who can influence your device security.
So admin access is just a bucket
that encompasses all those different levels
of sensitive, high-privileged access
across different types of systems in your environment.
Let's jump into the fun bit, which is,
and I'm sure people who are listening
can probably think of their own as well,
but can you give us some examples
of some bad privilege access setup
or maybe no privilege access setup?
What are the things you've seen out there in the wild?
I've seen some pretty shocking things.
I'm not gonna lie,
especially in my days working in compromised recovery
where most of the time companies who were breached
had really poor privilege access management processes.
So I've seen things like companies
with 100 domain admins in their active directory
and similar numbers of admins in global admins
in their Azure Active Directory.
I've seen things like, for example,
attackers targeting an on-prem Active Directory,
they gain that level of high-privileged access
and then they remain persistent in that environment
for a really long time, funneling out information
like sensitive government information
or sensitive corporate information
and using that for competitive purposes outside.
And then once they've got that foothold
in the on-prem environment, generally they can then pivot
into cloud-based environments like Azure or AWS
and basically try and take control
across the entire enterprise estate.
So one particular example I can think of
which I always remember is there was an attack
on an Australian organization
and they basically the attacker was able to fish a user
through their on-prem device.
They then enrolled a malicious application into Azure AD.
So application registrations,
if you don't have that locked down,
anyone can pretty much register an application into Azure AD.
And then once they had that application enrolled
with a high level of privileges,
they were able to, it was actually an email application.
So they were able to steal all of this email data
out of the organization's email systems
and unfortunately for this organization,
they use their email mailboxes as a way
to store sensitive citizen data
and the attacker registering the application
and being able to get email data
meant that they had access to a lot of sensitive data
of Australian citizens and they were able to use this data
for things like fraud.
So that attack started in the on-prem environment
and then they were able to pivot into the cloud
through an app registration.
And what we see is a lot of organizations,
they start with on-prem and then they build out
their cloud estate and you also have this high level
integration between on-prem and the cloud
through things like your identity synchronization
between Active Directory and Azure Active Directory.
So I guess the lesson learned from this particular cyber attack
which I was involved in responding to was
if you have sensitive information stored in the cloud,
if your cloud systems are production,
like you've got real workloads sitting there,
you need to make sure that you take a conscious effort,
a conscious approach to securing both your on-prem
and your cloud systems, especially that privileged access,
lock down things like application registrations
which provide high levels of privileges
to your sensitive data and look at your whole environment
holistically rather than just one or the other.
So that, yeah, that was a really interesting breach
that I got to respond to a few years ago.
So I have a little tale.
I was working with a customer,
we're going through a threat model,
we're designing something out and I was looking at
sort of a storage account that was being used in Azure
and we asked some questions about the mitigations
and sort of network accessibility to the storage account.
And we found out this storage account
was actually holding relatively sensitive information
and it was probably accessible to the internet.
So we're on the call and next thing,
one of the developers is like,
hang on a minute, let me go and check.
So he went to go and check from his laptop,
he's actually sharing his laptop screen
and he actually connected to production
from his general purpose laptop.
And so I sent a message to the person
I was mainly working with to say,
hey, you know what I think I said about
the storage account possibly being accessible
to the internet, that kind of pales in comparisons
compared to what I just saw, which is,
some, you know, Joe six pack developer
connecting to production from his general purpose laptop,
rather than from a device which is designed
specifically for sort of admin access,
like to these higher levels of essentially sensitivity.
So yeah, that's kind of one of my favorite little stories
and unfortunately I see that quite a bit.
What about, have you seen that quite a few times?
I definitely have.
I think a lot of organizations like this jump host type pattern
for privileged access.
I think it doesn't help sometimes
that some of the standards that exist out in the industry
recommend having that sort of pattern
where you maybe you browse to a secure environment
and then you do your administration from that environment.
And I think that's now being misconstrued
as you can use a less sensitive device
to access a more sensitive environment
from which you do your administration
when in fact we wanna maintain a level of integrity
all the way from the hardware based device
to that sensitive administration environment
to your sensitive systems.
So I'm sure you're aware Michael
of the concept of a privileged access workstation
which is that secure hardware device
that you use to then go and do your administration.
And that should be hardware, not software
so that the attacker can't take control
of the device you're using to do your administration
and add things like a key logger onto that device,
for example, and capture your session.
The whole access path has to be secure.
I can think of a couple of stories too, Bron
around some of this.
But would you say there's,
I mean, obviously you've just given us some examples
as did Michael, would you say there's any
like typical mistakes that people make?
Obviously you've shared, you know,
people having far too many admins
and you know, with high privilege admins.
But are there sort of common misconceptions
or mistakes people make
that you've seen around privileged access?
I think the jump host one is pretty common.
I also see organizations using a PAM type solution
as a alternative to having a poor based device.
So maybe they'll browse up to a PAM
from their regular user workstation
which means you're accessing a sensitive environment
still from a less sensitive or less secured environment.
So what I've done working with customers
has been looking at ways that we can implement pours
and you would access a PAM from a pour,
but it's not either or it's not,
like you need to have a secure device
and a PAM solution if you wanna use
a PAM solution especially for managing
quite sensitive systems in your environment
like your identity systems.
So there's probably more patterns that I see
like there's some kind of anti-patterns.
The UK equivalent of the ACSC in Australia,
they have some quite good privileged access
anti-patterns published on their website.
So I definitely recommend checking out those
and they include things like browse up patterns
for privileged administration.
And that's probably one of the places
that I would go to have a look at some of those,
some models and patterns.
I guess in terms of more broader privileged access,
one of the other things would be having too many admins
who are permanently assigned privileges.
So today we talk about just in time access
when it comes to privileged access.
And I think tools like PIM that are built into Azure
make that really easy, but often in on-prem environments
it can be quite tricky to implement
that kind of just in time access,
especially if you don't have a third party technology
or a PAM solution in your environment.
And just for anyone who's listening,
can we just recap what those acronyms are?
Just some...
For sure, so a PAM solution is privileged access management,
which can perform a few different functions
like password vaulting, it can do session management,
it can do just in time access to certain roles
in your environment as well.
Yeah, and for those of us who aren't in Australia,
the ACSC, in fact, you know what, Brod, I know who they are
and I can't remember what the acronym stands for right now.
So I just looked up the UK equivalent
is the National Cyber Security Centre.
And in Australia we have the Australian Cyber Security Centre,
which is our proper organization.
It's kind of like the NSA in the US.
Yeah, I was just about to say, it's probably...
Yeah, the US equivalent is probably like the NSA
or something similar.
So essentially, government agencies that help with cyber
and give out guidance and...
That sense, yeah.
And obviously most countries have them, I think, nowadays.
So, well, we've already kind of gone into this a bit,
but, Brod, what is the solution to privilege access?
I mean, obviously that's a big question
and there's many things you can do,
but in simple terms, what would you say
is the best thing folks can do here?
Yeah, good question.
I mean, there's some really simple things you can do
for your organization that make a huge difference.
Things like making sure you have multi-factor authentication
enabled, least privilege,
making sure that people don't have permanently assigned permissions.
But Microsoft actually has some really good guidance
published online, which is our Securing Privileged Access Guidance,
and we used to refer a lot to the model I mentioned earlier,
which is the tiered administrative guidance.
So, we used to refer to the tiered administration model,
which provided the levels of separation
within your Active Directory environment
to make sure that admins weren't logging on to lower tier systems
or less secure systems
and exposing their credentials to those systems.
Nowadays, we have a revised version of our privileged access model,
which is called the Enterprise Access Model,
and some concepts like we want to make sure that we have
high integrity workflows throughout the privileged access process,
making sure you have a secure device,
which is the same level of integrity as the system that you're accessing.
And by that, I mean, you can't tamper with that device,
and so you have a high level of confidence
that the person who's accessing the sensitive system
is who they say they are,
and the device hasn't been tampered with by an attacker.
So, I would definitely recommend having a look at the Enterprise Access Model.
In fact, I actually had a chance to work with a customer earlier this year
on a Greenfield Azure deployment,
and one of the questions the customer had was,
how do we set up our Azure environment
using all of the Microsoft best practices for privileged access management?
So, this was an amazing opportunity to apply those Enterprise Access Model concepts
to setting up privileged access from scratch
using completely cloud-native technologies
without any of the tech debt which we so often encounter
when we're working in on-prem or hybrid environments.
So, what that solution looked like was,
I mentioned privileged access workstations.
We did have pause, and they were completely cloud-managed.
They were managed using Intune,
and we had policies applied to those pause to harden them
to make sure that they had a certain level of integrity, as I mentioned,
and as part of the access into the environment,
we were using conditional access to evaluate the posture of the device.
Does it meet certain compliance policies? Is it fully patched?
Does it have a low risk score according to Defender for Endpoint?
Has the user authenticated using Windows Hello for Business?
All of these signals come together in something
that very much resembles our Zerotrust model,
and that evaluation happens using CA, the Admin Accesses, Azure,
and then in order to access their roles like Global Administrator,
they then use PIM and they have workflows to approve their access
to those privileged roles.
In addition, those accounts which they're using to log on to their device
and access Azure are all cloud-only accounts for privileged access.
So, we're not using any synchronization.
I mean, this environment is cloud-native anyway,
so we didn't have any of the on-prem dependencies,
but that's probably one of the best examples I've seen of an organization
who has set up their privileged access according to Microsoft's public guidance,
and we've used Zerotrust as a foundation,
and we've implemented all of the cloud-native controls
across the privileged access workflow.
And they're really enjoying it so far
because all of their administrators are distributed all across Australia,
and some of them are overseas as well,
and they don't need to worry about things like,
am I on the organization's network?
Like, am I within the trusted IP range of the organization's network?
That doesn't matter anymore.
It's all about, is your device secure?
Have you authenticated using strong authentication?
Windows Hello for Business is great
because it balances the usability and the security aspects.
And then, are you elevating your privileges just in time
and having that access approved?
So that combination has enabled that customer to be very productive
in their privileged access workflows.
So highly recommend having a look at our public guidance,
and I've actually been working on some updates to that guidance
to help with providing some of the lessons learned
from the projects I've worked on through my consulting engagement
so that we can help customers to see those success stories
because I think sometimes if you just read the documentation,
it can be a little bit abstract and you need some good examples.
So keep a look out on our public docs,
like our Securing Privileged Access Docs for updates,
hopefully coming soon.
That's super cool.
I will definitely need to look at that.
So I know that you did sort of just allude to this before
you were talking about a customer that was totally greenfield,
but when you've got a completely greenfield solution,
let's say it's ideal case with zero tech debt,
what would be your like, where would you start if there was zero tech debt?
What's the best thing to do?
Obviously, yeah, you've been lucky enough to work with some customers like that.
Don't think I've ever worked with customers with zero tech debt.
That's very exciting.
What a unicorn.
It was an amazing opportunity and I definitely take those learnings
into my other customers, most of whom are hybrid.
I think the general type of organization that I work with
still has a lot of on-prem infrastructure
and usually they're still running all of their identity systems
out of Active Directory rather than using Azure AD as the master.
That's pretty uncommon in my experience.
But where I would start if I was setting up from scratch is,
I mean, from my experience on that customer,
we started with firstly having separate admin accounts which were cloud only.
So we had on microsoft.com accounts in that customer's tenant.
We had conditional access policies.
So we had a baseline set of conditional access policies for access into the tenant.
We didn't start with pause.
That was a piece that came along later.
But at the very start, when we were building the tenant,
we did have CA policies to evaluate things like multi-factor authentication.
That was priority number one to look at things like where those logins were coming from.
So it was an Australian based customer.
So all of our admins were coming from Australia.
And I think we also had some perhaps device registration requirements,
but it was fairly minimal at the beginning.
We did also set up PIM at the beginning as well.
So we didn't have everyone with global administrator privileges.
It should be pretty rare that you need to have people who are using global admin every single day.
If you're delegating privileges properly, you can request that access and then use it as required.
We also set up PIM for some of the high privileged as a resource roles,
so as our back roles like contributor and owner.
It should be pretty rare as well that you need to have those kind of privileges,
especially in a production environment.
If you're using DevOps type processes to deploy your infrastructure.
So in this case, we were using Azure DevOps to deploy all of our infrastructure.
And so most of the infrastructure updates were coming through the pipelines.
So yeah, at least privilege all the way, I'd say.
Fair enough.
I mean, least privilege is pretty, well, we've been preaching least privilege for a long time, right?
And I think the thing is though, you need to keep watching it.
So it builds up over time.
So even when that system went live, we did have to do another call of user access because even if you have great processes,
you still need to trust that verify and go back and do those regular user access reviews.
There's like a process component as well that you need to look at to operationalize your privileged access management in your environment.
Well, in one of my previous roles, one of my previous employees, we used to do the privilege access review manually.
It took a really long time.
It was something people dreaded doing.
We actually got third party people contractors in to come and do it, which I'm sure was very expensive.
And the great thing is now at least we can, we have tools to make it a lot easier, but it is still iterative, right?
We've still got to keep doing it, keep reviewing it, which I think is your point, right, Bron?
Exactly.
Yeah, I think one of the things about deploying systems in the cloud is it's not just a one-time activity.
You have to have that mindset of continuous optimization.
It's like optimization in a security sense, making sure that you improve your security processes and also like your overall governance, your cost management.
All of the elements are going to running a environment that's well architected.
There's definitely a process component and I think that aligns with agile methodologies, things like continuous security, continuous optimization, all of those mindsets apply to security in the cloud.
And I guess the other aspect of security in the cloud is that vendors like Microsoft are continuously releasing new features and things that you can enable to help you with your security.
So I think of things like Entra, for example, which has come in and provided a bunch of new features that you can use.
If you were just using the features that you used one year ago in the cloud, you're already behind because you're not using all the benefits that you get from your licensing.
So even just reviewing what's available to you from a licensing perspective is extremely valuable.
So you might not need another third party product because Microsoft will introduce something that's included in your E5 licensing bundle, for example.
So it really is that iterative process where you keep building up your capabilities over time.
Yeah, there's a lot going on there.
And even for those of us that work at Microsoft, it can be hard to keep up with everything that changes, right?
Because the rate of change is so quick.
Ron, it has been a pleasure.
But what we always ask our guests before they leave is if you could leave our listeners with one thought, what would it be?
I would say it's all about the process and the technology.
So make sure you have both of those components considered as part of your security strategy.
I guess when it comes to privileged access, make sure you are reviewing your processes
because things like what I mentioned earlier with 100 domain admins or 100 global admins,
that's not just technology weakness, it is also a process weakness.
Make sure you are reviewing regularly how many people have that sort of high level of access in your environment
because that's going to be what an attacker is going to abuse to remain persistent in your environment if they get in.
And today we say it's not just a matter of if, it's a matter of when.
So do think about the technology and the process aspects and try and balance security and usability.
That would be the main things that I would say.
It sounds like a bit of a cliche, but it is all about making sure that your security controls are highly usable and fit for purpose, especially for your business users.
Yeah, I couldn't agree more.
Thank you ever so much, Bron, for joining us this time and thanks everybody for listening.
If you're in the US, enjoy the holiday period that is coming up.
And well, if you're listening to this relatively close to when we release it and stay safe and we'll see you next time.
Thanks for listening to the Azure Security Podcast.
You can find show notes and other resources at our website azsecuritypodcast.net.
If you have any questions, please find us on Twitter at Azure Set Pod.
Background music is from ccmixter.com and licensed under the Creative Commons license.