>> Hi, I'm Jeremy Dallman,
a Principal Program Manager on
the Microsoft Graph Security API team.
Today, I'll be giving you a short overview about
the security API for Microsoft Graph,
that was released as a public preview at RSA, 2018.
At build 2018, we will be
spending a lot of time with developers
and partners to showcase how
Microsoft Graph can be used
to improve enterprise security,
and help our partners build
better solutions for our customers.
Today, security operation centers
rely on a number of tools to triage,
investigate, and remediate threats.
Those tools offer specialized experiences and
insights that help the security
analysts get their work done.
This often includes threat protection solutions
that alert on potentially malicious activity,
offering their own views into related activities,
things like ticketing and incident management solutions.
Third intelligence dashboards, that can be used to
hunt or investigate threats, and likely many more.
This library of disconnected solutions,
often leads to disconnected alerts,
slowing investigation and remediation.
Although security operations exist
to protect the business,
they often lack the ability to
bring business context into
the investigation to help
them understand the full scope of the threat.
Finally, this increasingly complex organization
and ease of access to
relevant data often slows
mitigation or enforcement of security policies.
To address these challenges,
we have released a public preview of
the Microsoft Graph Security API to provide
a unified gateway to your security data
across Microsoft and partner security services.
The security API provides a unified language,
to standardize all security alerts
from across your security operations.
It also provides access to business data,
through the Microsoft Graph.
Data like identity information
from Azure Active Directory,
device information from Intune,
and productivity data from Office 365.
This business data can be leveraged
to enrich security alerts,
bringing business context into
security investigations through a common API surface.
Finally, the security API does more than
just improve access to security alerts,
and enrich them with business context.
Our primary vision for this API is to make
security operations more effective,
and efficient in addressing security threats.
To help us achieve this vision,
we're also using the same API to
enable security run books
for investigation and remediation.
These features to improve security automation
will reduce time to response,
and give security operations teams the ability to
programatically mitigate
threats and set protective policies,
through the security API.
Let's take a quick look at how
the security API will fit in the Microsoft Graph.
Unlike many other graph entities,
security federates queries for data from
multiple security providers
depending on what you've licensed.
The data never leaves your environment.
Security Graph API serves as a broker
between all of the Microsoft security products,
and other security ecosystem partners who
listen for queries from the Graph API.
Because the Graph is authenticated to
your domain through Azure Active Directory,
only people with the proper permissions
can get responses or
take actions on your security data
using the security API.
The security API lives alongside
the other Graph services
bringing alerts, security profiles,
the security inventory that
the providers identify in your environment,
and our automation entities for
taking actions and managing configurations.
These entities can be called along with
other Microsoft Graph entities like users,
or groups to provide rich security insights,
and establish new data relationships
to enhance your investigations.
All of this will be accessible through
the same rich developer ecosystem of the Microsoft Graph,
spanning 10 different SDKs and code samples.
Our public preview of security API is already being
used to build new security solutions
from several partners.
Whether in MSSPs wanting to leverage
the graph to streamline integration,
a SIEM using the graph as
a single integration point to connect more easily with
Microsoft's security solutions through
our Azure Monitor integration,
or in ISVs who exposes
their alerts alongside Microsoft alerts.
Adding to customer security inventory
or automated mitigations,
we have many partners building
exciting new solutions using the security API.
For example, PwC uses alerts
from the Microsoft Graph to deliver improved visibility,
and protection to their managed security customers
through their secure terrain platform.
Anomali leverages the alert metadata
to correlate alerts with
their threat intelligence providing
earlier detection and response.
And paloalto networks has built
a proof of concept solution,
that combines both threat data
from both our alerts and integration of
their own products to provide
a simple and efficient way for SOC analysts to detect,
investigate, and automate response through
a single interface using the Graph API.
Now, let's walk through
each of the security API entities,
to look at some practical examples of how
the Graph Security API can simplify
some common tasks in security operations.
We've already talked quite a bit about what you
can do with alerts in the graph.
But let's dive a little deeper.
Querying for all alerts from
providers in the graph is as simple
as a short call using our C# SDK or a REST API.
The results of this query can be filtered similar to
any REST API and surfaced in whichever dashboard,
or user experience you prefer
giving you the ability to manage,
correlate, or enrich these alerts as needed.
One of the challenges we have heard from customers is
the time consuming task of keeping security alerts
in sync across all of your SOC systems
as you manage them through
a ticketing or other management platform.
For example, if a SOC analyst
assigns an alert to herself,
and changes the status in a management dashboard,
they often need to go back and then
manually update alert in multiple places.
With the security API,
you can programmatically update that alert with
a simple patch that writes back to the alert provider,
keeping alert updated seamlessly.
I also want to take some time to talk briefly about
our SIEM integration through Azure Monitor.
The security API does not
ingest raw logs or reason over them like a SIEM.
The API works exclusively at the alert level.
However, the security API is part of
the consolidated SIEM integration story
through Azure Monitor,
where there are already connectors for Splunk,
QRadar, ArcSight and SumoLogic.
Security API customers will only need to integrate
once using the SIEM connector they
already have established in security monitor.
The Azure event hub customers
will build off Azure Monitor
listens for a security alerts through the API.
The Azure event hub customers will build off
as your monitor listens for security API
alerts seamlessly delivering them to
your integrated SIEM for triage
and management in that familiar interface.
You can get more detailed documentation,
on connecting to your SIEM in
the Microsoft Graph Security API documentation
that will link at the end of this presentation.
The next piece of the security API,
we will look at is called securityProfiles.
SecurityProfiles represent the inventory
maintained by security providers.
These can be hosts, users,
file, apps, or IP addresses.
For example, Windows Defender ATP
can provide host securityProfiles.
Azure Active Directory could
provide user securityProfiles.
A CASB solution could provide
app securityProfiles and so on.
This gives customers and developers
the ability to correlate alerts
with the underlying inventory associated with the events.
For example, this first simple query asks all of
my security providers what they know about
a user based on the user's securityProfile.
The query goes out to all graph connected products,
and returns any information each provider knows
about this user, janedoe@contoso.com.
This information could be used to determine the extent of
a threat that might result from
this user's account being compromised.
You can also query security providers to get
their context that they might be providing.
For example, if you can query security providers for
risk scores associated with the host or a specific file,
this query will return
any information your security products
know about the item specifically, in your environment.
SecurityProfiles can also be
used to address compliance questions.
For example, a simple query to
all of my hosts requesting their current platform
and OS version can give me
invaluable data on the patch state of my machines.
Some partners are also using this sort of
query to identify outdated apps on
their managed mobile devices to track
potential risks and bring your own device environments.
You will see later how our automation capabilities
can then help those companies,
and force proactive policies
to keep those applications updated.
Next, we'll dive into our security automation features.
The value of simple integration
in enrichment of alert is clear.
But we believe you should be able to address
a threat as fast as possible once you understand it.
We've created two security automation capabilities
to make this possible.
The first is our actions entity.
Actions are performed by providers
against the securityProfiles that they have identified.
This gives customers the ability to programmatically and
directly invoke a specific action
onto their assets in their environment.
For example, in this first sample,
we have a server id that is managed by MCAS,
the Microsoft CASB solution.
Because MCAS has the ability to restrict
access on any services running on its server
that can expose that capability to
the security API allowing
their customer to programmatically restrict
access on this host using a simple REST call.
Here, when a detection shows that someone is
attempting to ex-filtrate data
from one drive on the server,
MCAS gives the security organization
the ability to immediately
block access to one drive on that server.
Shutting down the attack,
and protecting that data.
Similar actions can be taken by any number
of other security Graph API providers.
You can programmatically block
an IP address on a firewall.
Reset the passcode on
one or multiple devices include using Intune.
Revoke access to a specific file for
a specific user using Azure Information Protection,
or disable communication to or
from a server using Azure Security Center.
These simple programmatic actions do not
require moving between connected systems.
They save you time,
and speed your time to response
and your time to protection.
The last security API namespace
we will discuss is configuration.
Similar to actions, configurations can be invoked through
the API to take action on your security products.
However, unlike actions, it does
not apply to a specific piece of inventory.
Configuration is a universal way to enforce or
set security policies for each security product.
Intune may expose the capabilities to enforce
new IoS device policies to the graph so
users can programmatically manage their IoS devices.
This simple post allows you to
push a specific policy with all of
its defined parameters down
onto all managed devices through Intune.
Similarly, the API can be used to enable
automatic provisioning of a new monitoring agent
across all managed Azure Security Center tenants.
The simplicity of setting configurations in this way
will not only improve operational efficiency,
but could also help you proactively
protect your organization from threats.
At RSA 2018, we announced our public preview of the API.
During Microsoft's build 2018,
we will be introducing the API to
our broader Microsoft developer and
partner ecosystem through hands on labs.
You now have access to code samples,
in both C# and Python,
and the ability to integrate and
query for alerts from Azure Security Center,
Azure Active Directory, Intune,
and Azure Information Protection.
We have also documented
our SIEM integration with Azure Monitor to
help you integrate security API
alerts directly into your SIEM.
Finally, we have established developer communities in
both Microsoft tech community and
Stack Overflow to provide
further guidance and answer your questions.
In the fall of 2018,
we will make the API generally available.
At that time, we will have on board the rest of
Microsoft's security products as
providers as well as
a number of third-party ecosystem partners.
We will release the final documentation
on securityProfiles and
our automation capabilities
around Actions and Configurations.
Finally, we will be fully integrated with
the Microsoft Graph's catalog of SDKs and
code samples to make it even easier for
other developers to build on top of the security API.
You can get started right away.
Visit our developer portal,
ask questions on Stack Overflow,
check our samples in GitHub.
We have a space there where the community
is contributing more and more samples every day.
Thank you for taking the time to learn more about
the Microsoft Graph Security API, and happy coding.