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 78.
This week is just myself, Michael and Gladys.
Mark is busy this morning and Sarah is no longer in Singapore.
She's actually in Norway this week at the NDC conference, which is a software developer
conference.
And with us this week, we have two guests.
We have Marcelo and Neil, who are here to talk to us about the latest and greatest news
in entry permissions management.
But before we get to our guests, why don't we take a little lap around the news.
Gladys, why don't you kick things off?
I wanted to talk a little bit about things that we were discussing yesterday in Build.
I don't know if a lot of people had time to watch it, but there was a lot of awesome news
in there.
In particular, the co-pilot type of services that we are providing.
As we know, the volume and velocity of attacks require us to continuously create new ways
to enable defenders to disrupt attackers' infiltration attempts.
By bringing together a set of capabilities, whether it is Microsoft or different partners,
this cross-service collaboration enables a lot of knowledge to be captured.
Coupling these signals together with, we keep talking about the over 65 trillion daily signals
that Microsoft has as part of the threat intelligence and the power of AI, Microsoft is enabling
defense of the machine and speed and scale.
So this technology elevates the human strengths.
We have to understand that security co-pilot doesn't always get everything right.
AI-generated content can always contain mistakes.
But since security co-pilot is a closed-loop learning system, which means it is continuously
learning from users and giving them the opportunity to give explicit feedback, it is continuously
improving.
With security co-pilot, basically you have a prompt bar and you could ask in natural
language questions such as, are there incidents in my enterprise that provide me a summary
of a particular vulnerability and so on.
So there's a lot of information and a lot of videos that we're providing as part of
Build.
I'd recommend going either to our website that we have some links to the demos and the
content or go to the Build website and watch the videos.
The next thing that I wanted to talk about is protected actions in Azure AD.
They're in preview, this feature.
Something that an administrator wants to update the conditional access policies.
You want to make sure that that administrator is not compromised or has not been hit by
phishing attack.
So now there's capability to first make sure that the administrator satisfied the phishing
resistant MFA policy.
In other words, they are using a stronger authentication methods like FIDO2 and Windows
Hello.
So now you have the capability to enforce that before they are able to make changes.
And last, again, if you didn't have time to attend to the Build, go and do so.
There's a lot of announcement, especially about Microsoft Entra capabilities, some of
which we're going to discuss in a little bit.
Yeah, it's funny, I was watching the broadcast yesterday from Microsoft Build and there's
one figure that stood out to me.
Scott Guthrie quoted that 46% of new code these days is written using AI.
I absolutely believe that.
Just looking at customers that I'm working with and also just people that I interact
with on a daily basis, a lot of people are using the likes of ChatGPT and GitHub Copilot
and Visual Studio Copilot to help them write just little bits of code or little snippets
of code that take a lot of drudgery away.
So that's a very interesting figure.
Also, just if anyone's interested, I actually recorded a couple of videos for Build on SQL
Server and Azure SQL Database, obviously around security.
One is on basically threat modeling and how to build threat models around SQL Server and
Azure SQL Database.
The other one is all the cryptographic controls that are available in both Azure SQL Database
and in SQL Server.
But onto my news, first one is that Ledger is now in preview in Azure SQL Managed Instance.
Ledger is the way that we can provide cryptographic guarantees around the integrity of data.
That's why it's called Ledger.
It's somewhat similar in the way it works with blockchain, but it's symmetric algorithms
rather than asymmetric.
And so the actual security guarantees actually come from using immutable storage at the backend
for the series of hashes, which is called a Merkle tree.
So that's available in preview today.
Also in preview is Red Hat Enterprise Linux 9.2 is now supported on AMD confidential VMs.
We talked about AZZI confidential VMs some weeks ago, but the nice thing is you can now
run this instance of the operating system in one of these confidential VMs where the
root of trust is all the way down into the actual chip, into the CPU itself, and no one
has access within Azure or Microsoft has access to the internals of your confidential VMs.
Everything that runs in there is isolated and encrypted while it's running.
On the topic of confidential VMs, we now have the ability to support Azure Data Explorer.
Very, very early on in the podcast, we actually talked to the folks who run Azure Data Explorer
or ADX.
And it's essentially a more cost efficient way of storing log analytics data.
The nice thing about ADX as well is that it's your data, right?
You can store it in your own storage accounts.
Well, now you can use AMD confidential VMs to store that data and run the code that queries
that data.
So that way, if you've got confidential log data, again, the trust bound is all the way
down into the CPU.
So Azure operators don't have access to it at all.
Still on the topic of confidential computing, we now have in general availability.
We talked about this being in preview prior to this, but confidential containers in Azure
container instances are now supported.
So again, you can now run your containers in what's called the trusted execution environment.
And once again, the router trust is all the way down into the CPU.
Second to last one is Azure Key Vault access configuration has been updated.
We're now preferring the Azure RBAC model.
Now, if you're not familiar, Key Vault actually supports two access control models.
The historical one, like the old one, which is called the Key Vault access model.
The granularity was at either keys or certificates or secrets.
And that was it.
So you could put a policy on an individual key, for example.
With Azure Key Vault RBAC, you can.
And so that is now the preferred model.
We're recommending that for multiple reasons.
So for example, the central access management for admins, integration with privileged identity
management, deny assignments, much more stringent access permissions.
So it's really good to see that.
And I would definitely prefer that over the original and frankly old Key Vault access
model.
And the last one, which really caught my eye from yesterday, one of the announcements
at Build was Azure content safety.
And so this is available as part of Azure AI as a new service.
And it will do things like analysis of content to basically give you a reading as to how
potentially unsafe this content is.
So for example, racial slurs, sexual content, violence, self-harm, hate, all that sort of
stuff.
And so it will flag that for you.
All right.
So now I've got the news out of the way.
Let's turn our attention to our guests.
As I mentioned at the beginning, we have two guests, Neil and Marcelo, who are here to
talk to us about entry permissions management.
Gentlemen, welcome to the podcast.
If you'd like to take a moment, would each of you like to introduce yourself to our listeners?
Thanks, Michael.
My name is Neil Walker.
I'm on the Intra Global Black Belt team at Microsoft.
I'm based just outside of the Boston area.
I've been with Microsoft for just about two years now.
And I came to Microsoft from a company called Cloud Knox Security, where I was the director
of solutions architects there.
And I came to Microsoft via the acquisition of Cloud Knox.
So Michael, I appreciate you having me in this morning.
Hello, everyone.
Thank you for the invitation, first of all.
Well, I'm Marcelo Di Iorio.
I'm like Neil.
We have the same role, different regions and countries.
I joined Microsoft in 2008 when I was in Argentina.
I'm now in Spain.
I'm living in Madrid.
I went through different roles during these years.
But yeah, I'm now working as a GBB for entry permissions management.
Guys, can you tell us a little bit about Microsoft entry permissions management?
We have spoken a little bit before.
Sure.
So entry permissions management is, I mean, you know, to throw another acronym into the
acronym stew, right?
It's Cloud Infrastructure Entitlement Management.
So CIEM is a multi-cloud offering.
So we're not just an Azure solution, right?
This covers Azure, AWS, Google Cloud today.
And ultimately, what we're striving to do, what we're striving to draw out of customers'
environments is activity, right?
So we're looking at those AWS, Azure, Google Cloud environments.
And we want to be able to provide a unified view and highlight every action performed
by every identity against every resource, right?
We want to do that by looking at some of that historical activity.
So when we talk about the use cases, right, remember, we're doing a look back into all
of that historical activity that these identities have utilized.
So when we draw out some of those use cases, we're going to show use cases that really
revolve around things like excessively permissioned identities, inactive identities, super identities,
right?
So we categorize all of these findings that we draw out by doing an analysis of all of
the historical activity.
And we make recommendations as to how you can effectively least privilege these identities
in the environment, right?
So at a higher level, right, you'll hear me constantly emphasize that we're modeling activity,
right?
That's what's different about cloud infrastructure entitlement management, that it's not just,
you know, from a zero trust perspective, right?
When we think about least privilege, our perspective is, well, how can you have least privilege
if you're not actually focusing on what's been used, right?
If Michael has a high risk permission that he's never used, why does he have it?
How could he be least privileged, right?
So from our standpoint, again, you'll hear Marcelo and myself talk about and emphasize
the use of these activity-based insights to make the recommendations in EPM.
One thing that I would like to add is that a typical question from customers when we
explain or when we do these kind of introductions to a solution is that, are you going to replace
PIM or is this going to replace PIM, I mean, privilege identity management?
And the answer is no.
These are very different solutions.
I mean, first of all, PIM is not multi-cloud as EPM is.
And the second is that even when you can do things like, for example, you can create custom
roles with custom permissions, PIM is not multi-cloud and you don't have an easy way
to have visibility on the permissions that you are using from those custom roles.
And that's where you can benefit from EPM.
So this, I would say this is the typical question from customers and these are the main differences
between these two solutions.
When I look at permissions management, I start kind of getting overwhelmed and I'm like,
okay, in the past, this has taken a lot of effort.
So can you tell us how would you go into reducing those permissions?
And maybe even talk how we interface with other services that Microsoft has.
Neil, do you want to go first?
Yeah, no, I can take that.
So from a least privilege perspective, when we make recommendations around how we would
actually go about least privileging, and I know Gladys, you framed this in the context
of if we're going to least privilege a user or a group, keep in mind this extends way
beyond human identities.
I just want to make sure that we emphasize that as well.
This isn't just human identities.
We're looking at service principles, managed identities, applications, AWS roles, Lambda
functions, GCP service accounts.
We look at all of the identities and we're looking at those historical usage patterns.
So when we talk about least privilege, one of the remediation strategies, and again,
this is just one strategy that you can take, is when you look at, let's just take a managed
identity for example.
In a lot of cases and a lot of use cases, those identities should have really a fixed
set of permissions that they're using on a recurring basis.
In certain use cases, those permissions may not change.
So when you look at those identities and we talk about least privileging, if we look at
the activity, we look at those usage patterns of the identity and we see that they have
high risk permissions assigned that they've never used.
When we talk about least privilege, what we can do, one of the steps that we can do is
that we can look at the actual activity that they've used over time.
So for example, we can do a 90 day look back, look at what the identity has actually been
using, take that activity and create a role with just those permissions that they've actually
been using.
And we can do that with various levels of automation that we can talk a little bit further
down the road in the conversation around what remediation looks like.
But from a least privilege standpoint, it's whether you're looking at a user, a group,
a service account, an AWS role, a resource, regardless of what you're looking at, one
of the strategies and technologies that we'll provide is take the activity, basically take
the use permissions that we've seen used over time, create a custom policy or role, depending
on what cloud we're looking at, and be able to effectively least privilege the identity
with that strategy.
Just one interesting thing that I used to explain as part of what Neil was saying is
that you can, of course, create roles, custom roles with your specific permissions or the
permissions that you need to use.
And of course, you can apply these to human, non-human identities, et cetera.
But we also have something called templates.
And I used to explain about this when we go through these permissions on demand or just
in time capabilities.
It's basically about doing requests for permissions that you may need.
I mean, templates in this case, which are similar to roles, I would say.
But the main difference, let's say, is that when you create a template, that template
is going to be part of like a library that you have in the solution on EPM, and that
you can use as part of your requests when you request something.
For example, you can create a template that contains the permissions that you need for
everything related to virtual machines deletion.
Let's say that someone from your organization deletes virtual machines on a monthly basis,
for instance.
Well, this user can request these, or you can create a request for these, for example,
to assign this template to the user on a specific day and time.
For example, if the user is going to delete virtual machines every Friday morning, for
instance, you can create a request that is going to be that where the result is going
to be that we are going to provision that request.
Sorry, we are going to provision those permissions by creating a custom role and for a specific
amount of time, let's say, for example, for an hour.
And after that period of time, we are going to deprovision that.
And this is an interesting way to do things similar to PIM, let's say, again, from EPM,
where you don't have to worry about long-standing permissions.
So, you bring up long-standing permissions and that sort of stuff.
But one thing that always interests me is when you look at access control, there are
really two parts to it.
There are the actual objects themselves that you are trying to protect, and you may use
some access control lists or RBAC or ABAC or whatever policies or whatever technology
you have to apply those policies.
But then you also have principles, users, processes, and so on that have certain rights
on the box or roles or privileges depending on what environment you are running in.
Do we look at both?
Does Entra look at both?
Like you look at objects and say, these objects have a way to permissive access control, as
well as looking at principles and saying, yes, these principles have way too many privileges.
Does Entra Permissions Management actually look at both and give you information about
both so you can take appropriate action?
Yes.
If you go to the analytics dashboard, you can see that, well, I think that Neil mentioned
something about this at the beginning.
We have visibility on human and non-human identities.
That means normal users, I mean human identities, privilege and non-priorities identities, and
also service principles or managed identities.
So if you go to the analytics dashboard, you will see that you have visibility on the activity
of any kind of account in reality.
And you can right size them in the same way.
And even before finishing my response, in terms of these requests or just in time or
permissions on demand, you can do the same.
I mean, you can create requests for both human and non-human identities.
It's going to be exactly the same.
Let's say that you are using a managed identity or a service principle that is being consumed
by an application that is, again, going to delete virtual machines or going to do some
kind of automation.
You can create a request for this identity.
And if you know when this identity is going to use those permissions, you can specify
the date and time where you would like to assign these permissions.
Could be a role, the template, et cetera.
You used the term there, right sizing.
So what does that actually mean in this context?
So right sizing is a term we use when we talk about remediation.
So right sizing could be, and I want to emphasize could be.
Marcelo and I aren't suggesting that, OK, we're going to analyze every single user and
create a custom role based on their activity for every single user.
But right sizing is just a general term just to have a better fit set of permissions.
One of the strategies to do that could be an activity-based role or policy.
In certain use cases, that can make sense, right?
Especially when we're talking about groups and service principles, AWS roles, and some
of the other identities that lend themselves to those activity-based roles or policies.
But right sizing just really means to find a better set of permissions, right?
You have high-risk permissions that you're not using, right?
Why leave those permanently assigned?
You're just opening yourself up to unnecessary risk and not being used, take them away, right?
Whether you use, whether you downsize that role, downsize that policy or create an activity-based
policy or role, that's what we mean by right sizing.
This leads perfectly to a question that I have, because you said that you're not going
to create a role for every user, right?
So how do you prioritize?
How do you operationalize this?
Again, you don't want to, in an organization that had hundreds, thousands of users, you
don't want to create a role for each of these users.
How do you bring it together so it's an enterprise-ready type of solution?
Yeah, that's a great question, Gladys.
So from an operational perspective, I'll answer that question in two different ways.
So basically, we assess your Azure subscriptions, your AWS accounts, your Google Cloud projects.
We assign risk.
And this goes to your point, Gladys, when we talk to organizations, you need a way to
prioritize these candidates for least privilege, these candidates that need attention, right?
Because to your point, whether you're a single cloud or you're multi-cloud, you've likely
got thousands, if not tens of thousands of these identities, human and non-human in your
environment, right?
How do I prioritize this?
So from our standpoint, it all starts by modeling risk.
So every subscription project account gets an overall risk score, right?
Within those accounts, projects, subscriptions, right?
Every identity has a risk score.
And when we talk about operationalizing it, it starts with identifying the risk, right?
Where do I start?
Right?
Well, the data is going to dictate that, right?
So when we look at the data, we're going to assign risk, right?
Let's just say you have an Azure subscription.
It has a risk score that's in the red.
I don't have a visual to support this, but we do gauge that risk score.
So if you have a risk score that's in the red, you look at the subscription and you
can see, well, what's contributing to this high risk, this risky subscription that I
have out there?
If I look at that, you know, we're looking at elements like inactivity, right?
Do I have completely inactive service principles, users, groups, functions, right?
Whatever the use case is, so we then will break this down in very prescriptive recommendations,
identifying what those highest risk identities are.
And then from an operational perspective, right, it really is dependent on the personas
in the organization.
And what I mean by that is, you know, every organization is different in the sense that
you're, you know, you could have security teams, cloud infrastructure operations teams,
identity teams, right?
And so depending on the use cases and depending on who does what at the organization, we can
make sure that we're funneling those alerts, those reports, all of that guidance to the
appropriate personas at the organization to take action, right?
But it starts by prioritizing the risk by using this risk score, making sure that, and
then as you remediate, right, we'll actually show you how much progress you're making against
the risk, right?
You may have a subscription that, okay, well, from a risk score perspective, right, and
the scales to 100, okay, on day one, you may have a subscription that has a score of a
90, okay?
That's got significant risk.
And then as you start to remediate, as you start to operationalize this, you'll see over
time, right, whether it's on day two, day 20, day 30, right, you're monitoring that
risk score, right, and you're going to watch it go down as you're addressing these by making
sure that the appropriate personas at the organization are getting the appropriate data
and they're doing their part to least privilege these identities, right?
Whether it's using our automated tools or they're using even a manual framework to start
with, right, to least privilege these identities.
So I know that was a long-winded answer, but we are very prescriptive in operationalizing
this once you see the data, once you see the recommendation and roll-up reports, it's not
as daunting as it sounds.
So I mentioned that I've been seeing a lot of documentation out there of changes and
of course, after we acquired the service, we kind of aligned it more to our type of
capabilities.
So what kind of new features or new capabilities have you added lately to the product?
One of the most requested additions or features or capabilities is the Azure AD integration.
We are dividing these releasing different phases, let's say.
We are in phase one.
This is in public preview now.
And well, this first sprint is giving you some visibility into different roles and service
principles and more things around Azure AD.
That's the number one feature capability requested by customers, at least, let's say, in my experience
and the experiences from colleagues.
The other thing is that we recently announced the availability of PDF reports.
So if you go to reports, you can export, you can create PDF reports with that.
I would personally say with an excellent or very good executive format.
I have many customers using these reports for internal presentations.
Let's say, for example, if there are customers that want to promote the solution internally,
they create these reports and use them as something that they use to present the results.
Results first, if we are going through a POC or risk assessment, and second to catch the
attention from the decision makers.
I think there are a couple of additional things.
Neil, do you remember if we have some more news?
Yeah, I think the big thing that you're going to see over time is what Marcel alluded to
around the Azure AD insights is just remember this was purpose-built for infrastructure.
So we're doing an analysis on infrastructure in Azure, in Google Cloud, in AWS, and we've
extended those capabilities by now doing a deeper inspection into Azure Active Directory.
We have an initial phase in preview today where we're showing you the same perspectives
that we're showing you at the infrastructure level.
We're showing you from the Azure AD perspective as well, showing you your global administrators,
your service principles, and giving you more insights specifically from Azure AD outside
of the infrastructure.
You're going to see more and more features added to that Azure Active Directory insights
moving forward as well.
And then lastly, what I wanted to say is you'll also see some upcoming announcements in the
near term around some third-party integrations that we have coming up as well.
A lot of the workflows that Marcel described, you may not necessarily want to drive some
of those elevation workflows through the EPM console.
We want to give you the flexibility to be able to drive some of those workflows through,
let's just say, an ITSM platform.
So you'll be seeing in the near term here some announcements around some upcoming APIs
and connectors so that you can make use of the data, make use of the workflows outside
of the EPM console.
And like I said, some of those are going into preview in the coming weeks, and we'll share
that data and more definitive target dates as we make those announcements.
All right.
Let's bring this episode to an end.
So General, one thing we always ask our guests is if you had one final thought to leave our
listeners with, what would it be?
I'd like to share one final thought around Entry in general.
So when your listeners leave this call and they go out and they start doing some homework
around Entry Permissions Management, some of the other elements, you're going to run
into, well, Entry isn't just Permissions Management.
Right.
It's a family of products that we've rebranded as part of the Microsoft Identity Portfolio.
Right.
So as you're doing that homework, if anyone has any, I just want to make sure that I allude
to the fact that in addition to Permissions Management, there's other elements, identity
related, AAD, verified ID, identity governance, workload IDs.
Right.
These all make up what is the Entry family.
What we've been talking about today is specifically Entry Permissions Management.
Just keep in mind, if as you're doing your analysis and you're doing your reading, if
you have any questions specifically on any of the other elements in the stack, I know
most of the listeners are probably somewhat familiar with Azure Active Directory, but
if anyone has any questions on anything else you stumble on, verified ID, IGA, workload
IDs, again, it's just something we can reach out and help you provide additional context
around those as well.
So.
One more thing is that this is something that I used to tell to my customers, don't think
that you are the exception.
Unfortunately, many, many customers, when we enable, for example, when we do a POC or
risk assessment, we see that the situations in terms of permissions gap is not good.
We recently announced the availability of, there's a document called, well, I don't know
if this is the exit title, but it's something like State of Cloud Permissions for this year,
2023, where we say that 1% of the permissions assigned are being used.
So this is a reality.
This is something that I'm seeing in all my customers, no exceptions.
So my advice for the people that are listening to these podcasts is that give it a try.
Try to take this seriously because you can't imagine how many permissions you could have
assigned or your identity would have assigned by the fact of, for example, having a single
role assigned.
So why not to give it a try and see what your situation is?
You know, when I'm building threat models with customers or even internally, we always
get back to two critical aspects.
And one is permissions on objects and privileges slash roles slash capabilities that principles
like users or processes have.
I don't think anyone can really underestimate the value of tooling like Entra Permissions
Management for understanding what your security posture is around authorization and access
control.
So gentlemen, thanks so much for joining us this week.
And to all our listeners out there, we hope you found this useful.
Stay safe and we'll see you next time.