[MUSIC]
SARAH HANDLER: Hi, everyone.
My name is Sarah Handler.
ETAN BASSERI: I'm Etan Basseri.
SARAH HANDLER: Today we're going to discuss
how you can build the SoC of
the future using Identity Protection APIs.
So we're going to kick off by discussing what
is Azure AD Identity Protection?
Azure AD Identity Protection enables you to protect,
detect, and remediate your compromised identities.
When we discuss compromise and risk,
what we're referring to is
the likelihood that a bad actor has knowledge or
control of the identities credentials
and may be using it for nefarious purposes.
At the heart of Identity Protection are
the signals that power our risk engine.
Our data science team creates
heuristic-based detections that
integrate into our machine
learning system for best-in-class risk detection.
We also integrate signals from
security researchers within Microsoft,
third parties, and law enforcement.
This rich risk data is used to
evaluate both in real time and offline,
whether users and workload identities are compromised.
To best protect your organization's identities,
we then provide reporting
and automatic remediation capabilities.
You can view this data using
our Identity Protection blade in the Azure portal,
other first party security tools and yes,
our APIs, to more
rapidly respond to identities when they are at risk.
You can configure policies to automatically block,
require MFA or require
a secure password change when
a risky sign in or identity is detected.
It's important to understand
the hierarchy of risk in identity protection.
When we think about what makes a user risky,
there is a pyramid of risk.
So let's look at user identities.
At the bottom, we have risk detections.
These are specific anomalies that we detect
that indicate that that user might be compromised.
For example, we might detect atypical travel patterns,
unfamiliar sign-in properties or leaked credentials.
Most of our types of risk detections can be traced to a
particular sign-in during which
we observe the suspicious behavior.
These create risky sign-ins.
For a sign-in to be risky,
it means that it has one or
more underlying risk detections.
Both risky sign-ins and risk detections
contribute to the overall user risk,
which represents the overall likelihood that
that particular identity is compromised.
At each of these layers,
we have a corresponding report in
our portal experience as well as an API.
ETAN BASSERI: The hierarchy for workload
identities is very similar to what we have for users.
We have individual detections on the workload identity,
such as a leaked credential and
those compound together to workload
identity overall account risk.
Sarah, how do we choose the right interface
when we have so many options to get this risk data?
SARAH HANDLER: Before we dive into details on
our APIs, it's important to understand the different ways
that you can retrieve identity protection data.
First up, our APIs.
These are best for when you want to retrieve
the most current information about
an identity's risk or when you want to perform
bulk operations that can
be challenging to do in a portal.
The Azure portal is fantastic for identity admins and
security personas who want to investigate in a portal.
The same information available here is also in our APIs.
Diagnostic settings enable you to stream risk data.
For instance, when there's
a new risky user or risk detection,
this would be sent to your storage account or event hub.
This is also helpful if you want to use
log analytics to create
visualizations on top of your risk data.
Microsoft Sentinel is a scalable cloud native security
information and event
management and security orchestration,
automation, and response solution.
You can combine the identity protection data with
other first and third party data sources for analytics,
workbooks, investigations, and hunting.
Finally, we will soon be releasing
Identity Protection integrated
into Microsoft 365 Defender,
a unified pre and post breach enterprise defense suite,
that natively coordinates detection,
prevention, investigation, and response.
So what can you do with the APIs?
Let's start with risky users.
Risky users provide access to
Azure AD users under identity risk.
You can use this API to get a user's risk history,
confirm a user is compromised,
and dismiss risky users.
A cool thing about this is that you can confirm a user
is compromised even if they've never been risky before.
Next up, you have risk detections,
which returns details on a specific risk detection.
This goes back 90 days of data.
This is super helpful if you're
interested in a specific type of risk detection,
such as unfamiliar sign-in properties
or risk detections of a specific level.
Finally, we have risky sign-ins,
which returns details on the risk state, level,
event types, and details on a particular sign-in.
This is helpful to understand
why a sign-in was prompted for risk
based policies by looking at
the risk level during sign-in property.
You can also use this to understand why risk was
remediated or elevated by looking at the risk detail.
Let's take a look at this demo.
So we're going to start with risk detections.
When I first queried this API,
I get a lot of results.
So I'm going to narrow it down by
filtering to get risk detections where
the risk level is medium
and where the risk state is at risk.
I'm going to get just
where their source is Identity Protection.
By receiving those just with risk state at
risk I'll exclude those that have been dismissed.
I'm also only interested in
those detections coming natively
from Identity Protection,
not the integrated signals.
I see that this user, Martin,
has some interesting risk detections.
So now I'm going to retrieve
his risk history to dive deeper.
I see a number of
suspicious looking events and
I want to confirm him as compromised,
moving his risk level to high
so that the user risk policy will kick in.
The confirm compromise action succeeded.
When I immediately retrieve his risk again,
I can see that his risk level is still
medium but isProcessing property has flipped to true.
That means that the risk engine is
processing some sort of change to the risk.
After waiting a few minutes I queried again and
isProcessing is back to
false and the risk level is now high.
The risk detail indicates why this
has changed because I confirm them as compromised.
Finally, I want to look at some risky sign-ins.
So I'm going to query the API and
filter on risk state as at risk.
Again, there's a lot of results.
So I want to narrow this down.
I'm going to add filters for risk level
aggregated or offline risk is
high and I'm interested in sign-ins
where we detected the password spray detection.
This is a much shorter list.
If I want to look more deeply at
a particular risky sign-in,
I can retrieve the sign-in
record specifically for that request ID.
ETAN BASSERI: So let's shift gears over to
risky workload identities for a second.
Now, in addition to user compromise,
we now address risky workload identities.
These are identities that are either
connected to an application or
a service or some other non-human account
that exists within Azure AD.
Now, there's two ways that we look at that risk.
The risk can come from behavior.
That is behavior of the service principle,
which is the security principle with
an Azure AD that can acquire a token for
the application or something related to the app object,
the application object that manages
the credentials or even other properties.
Those service principal risk detections and
risky service principles mirror
what we do for users in many ways.
We've simply added the
term service principle in front of them.
Let's go into the demo and we'll show you what we mean.
We'll start with the risk detections.
You'll notice that it's actually the same permissions
as users that we have for doing this read operation.
Now here I get lots of results from the past 90 days,
but let's filter them out and maybe I want to see it
for just a specific workload identity.
I can see all the individual alerts for
that identity but here's one for leaked credentials.
This means that Azure AD has
identified a leaked credential
in a public GitHub repository.
With that type of exposed credential,
I definitely want to take action to remediate it.
Now let's look at account risk by calling
the Risky Service Principal Collection
and filter on a specific service principle.
One thing to note is that there are
specific permissions for this collection.
Those are IdentityRiskyService Principal.Read.All
and IdentityRiskyService Principal.Write.All.
The first one lets you read
the risk state of the workload identity.
The second one lets you either dismiss risk or
confirm compromise of that identity
using a post operation.
So we have the specific object ID
of the account that we want.
I can see that it's at risk and
the state is not processing.
Now, let's say I determine during my investigation that
the account either was not
compromised or it has been remediated.
This is where I want to dismiss the risk.
So I make the call,
I get a 204,
which means it was successful.
If I make a get call on that account,
I can see that the risk is now processing,
and if I wait a few minutes,
that property will update and
the risk will now be dismissed.
Sarah, what are a few other notable APIs that we should be
aware of as we're looking to
secure our identity infrastructure?
SARAH HANDLER: There are some other important,
complimentary APIs that can
help you be successful with identity protection.
Conditional access and named locations.
The conditional access APIs allow you to easily
create policies that can be triggered by sign-in risk,
user risk, and workload identity risk.
You can configure these policies to block,
require MFA or prompt
a secure password change when
these types of risk are detected.
This is super important to ensure that
our customers and you are
quickly responding when we do detect risk.
The other component is using
the API to set named locations.
Named locations allows you to configure
certain locations and mark them as trusted so
that we take that feedback and can cut down on
the false positives for
atypical travel and unfamiliar sign-in properties.
If you're noticing a lot of noise in identity protection,
this can be a great step to cut down on it.
So Etan, what should we do next?
ETAN BASSERI: Let's talk through some
takeaways. First of all, there are five key collections
to be aware of within graph for
interacting with Identity Protection.
Some of them allow you to read information,
some of them you can write to.
It's important to know how to interact with
each one depending on what goal you have.
If it's all about just collecting
all the alerts you need to get the risk detections,
if you want to be able to dismiss and confirm compromise,
then you need to be reading and writing
against risky users and risky service principles.
Now, conditional access is a very important aspect
here because while it's really important to have
the risk detections and all the risk reporting,
where this all really comes to
life is with conditional access and risk
based policies and conditional access
where you can in real time,
in many cases, control access and
contain compromise by using that automatic engine.
SARAH HANDLER: The most important thing is that
you can get started right now with these APIs.
We have robust documentation on how to use these APIs,
we have a number of sample scripts for
common tasks that you might want to
do with our identity protection data.
You can subscribe to updates
about identity protection, including our APIs.
Thank you so much for joining us today.
ETAN BASSERI: Stay safe.