- Hi, everyone,
thank you for joining us today.
In this session we'll be going through
how you can get connected with
Wandera APIs and data streams.
Today we'll be covering what integration
points are available for you
to connect to Wandera datasets,
and the key differences between them,
how you can do this in practice
and what use cases
you may want to do this for.
My name is Milind Patel.
I'm a product manager here at Jamf
and I joined Jamf through
Jamf's acquisition of Wandera.
I'm responsible for our Mobile Threat
Defense product,
though, as well as Threat Defense.
I've also had the pleasure of working
with our engineering teams
to build data streams and our risk API.
If you have any questions about APIs or
integrations relating to threat defense,
data policy, or private access,
please add them to the chat
and I'll do my best to answer them
as we go through this presentation.
So what is Wandera?
Wandera has been a leader in Mobile Threat
Defense and data policy since 2012.
Over the years, we've been consistently
rated as a leader within the MTD space
by analysts
and trusted by reputable organizations
in both the public and private sector
to protect their devices and their data.
Wandera was acquired by Jamf
in July of this year,
adding a great new set of capabilities
for you to protect, manage,
and connect your users to the apps
and the data they require
to be productive.
With Jamf Threat Defense,
you can provide endpoint protection
for your mobile devices.
With Jamf Data Policy,
you can provide content filtering,
and implement data usage controls.
And with Jamf Private Access,
you can provide your users with secured
access to business applications
using Zero Trust network access
technology.
In this session, we'll cover
the data integration points
specific to these products.
And when you hear the term Wandera
anywhere, it will be used
to refer to the technology
pertaining to these products.
For more on this, check out the session
Introducing Wandera by Michael Covington.
For detail on any product specifically,
there's a deep dive session
for Jamf Threat Defense, Jamf Data Policy,
as well as Jamf Private Access
that you can check out.
We have three means of helping you
to connect your data;
data streams, a risk API,
and an integration with AWS S3.
Today we'll be covering data streams
and the risk API.
The S3 integration is often used by
our customers with specific data retention
or data handling requirements.
But that requires us to give you
a helping hand right now.
Don't hesitate to reach out if this is
something that you'd be interested in.
First, let's talk data streams.
Our data streams are all about
letting you know what's happening
as soon as it happens.
Currently, this is done by
a SAP encoded syslog over TLS.
This has allowed us to support a wide
range of third party security solutions
up until now.
In Q4, we'll also be adding support
for sending HTTP events in JSON format,
in order to support more plug and play
integrations than ever before.
And we will continue to add these new
capabilities as we discover
new use cases that you care about.
We currently have four data streams.
For Threat Events Stream
which hosts all threat detection events
flagged by Jamf Threat Defense
across multiple attack vectors.
The Network Traffic Stream,
which hosts all network traffic events
captured by a security cloud.
If you've chosen to add a cloud proxy
or secure DNS traffic vectoring element
to your deployment.
The App Insights Stream for any app
vetting insights into the applications
installed on your mobile devices,
and the devices stream for visibility
into your mobile devices state
and the latest state of the devices.
The latter two, the App Insights Stream
and the Devices Stream,
are currently only available
to our partners.
However, if you're interested
in integrating with them,
definitely reach out to your account rep
or myself in order to discuss this
further.
So where can you send the data?
Right out of the box you have
documentation available for you to start
connecting your data streams
to popular third party solutions,
such as Splunk, Azure Sentinel,
Microsoft Cloud App Security,
and many more.
If you have a more custom use case,
you can easily set up a syslog
or HTTP receiver in your own environment
to be able to start ingesting
these events.
We only require that this is encrypted
with TLS so that your server is able
to present a certificate
known by a known public CA.
We do this to ensure that your traffic
and your data can be encrypted
and kept secure while in transmit.
And we're more than happy to work with you
to help you maintain the best
security practices possible.
Now let's get on to setting this up.
Here we have an example with
a Network Traffic Stream
which hosts web traffic log data.
If you already have a syslog
or HTTP receiver capable
of receiving these messages,
then the setup on RADAR,
our admin console, is super simple.
First, just tell us where this data
should be sent by adding
the destination hostname and port.
Second, test the configuration
to make sure that we're able
to establish a connection
and there's no issues with the config.
Finally, just enable the stream
and save everything.
From this point,
the Network Traffic Stream will start
to send the log data
to a configured third party
or on-prem server.
And this will all happen in real time.
We've kept the basic setup process
as many customers will only need
to do these steps,
and you can get set up very quickly
and easily.
Aside from this,
we also have many optional
configuration options to add
further security and supportability
to the streams.
On the security side,
by enabling client authentication
and adding the Wandera CA
to your receiving server,
you're able to ensure that only messages
coming from the work Wandera data streams
are accepted.
You can also take this further
by only allowing inbound connections
from our IP addresses
with your network access control policies.
If you've chosen to use a syslog option,
you can choose the event framing
that is used for these messages.
By default, this uses
[indistinct] counting.
However, some older tools
may not support this,
so you can switch easily
to non-transparent-framing
where it's required.
Lastly, you can customize
your log messages to select the exact
data points that you care about.
This helps with saving costs on data,
but also with data privacy
as you don't need to choose
between all data and no data.
Another option to make this easier to
ingest this data is the ability to rename
the field names to some other values.
By doing this, it can often make it easier
for your third party system
to index and map the incoming data.
So what are we actually streaming?
As you can see,
the Network Traffic Stream understandably
is the busiest one,
processing over 4,000 events on average,
for a customer with
about 100,000 active devices.
The other streams are comparatively
much lower, though still generating
a lot of useful events
for insights into new threat detections,
risky or unwanted applications
being installed,
or simple device state changes.
As mentioned earlier,
all of this is then sent securely,
while making sure that we're able
to recover and repush any messages
if we detect that your event receiver
is down.
Getting everything configured
is all well and good.
But what's the point of it all?
Generally, each organization
and their teams will have
their own unique use cases
that they care about.
Some of the most popular ones
that we encounter, though,
are consolidating data to provide
unified reporting and reporting on
all of their assets and data,
responding to threat detections
with further action,
ensuring employees are using approved
and secure applications,
and discovering new underlying threats
and risks.
If you're interested in learning more
about some of the security use cases
that I mentioned,
check out the session here
where I'll be talking about
what you can do with the data
once it's in your sim or other SOC tool.
Finally, our Risk API
is a bidirectional REST API
that can be used
for accessing device risk data.
While the data streams allow you
the ability to send events in real time,
this API allows you to access
and affect the device risk state.
An API is essentially
an intermediary that allows
two applications to talk to one another.
In this case,
your custom applications
or your third party tools, and Wandera,
through the Jamf security cloud.
A RESTful API design determines
what the API looks like, and allows
developers to easily work with different
APIs that follow the same principles.
In the simplest terms,
this works by an application making
a request to another application,
and receiving a response based on that
in return.
The Risk API currently consists
of three distinct endpoints.
The first, the login endpoint
allows you to authenticate
your application before it's able
to access your data.
This is crucial in keeping
your data secure.
The second, the devices endpoint,
allows you to obtain information
about your devices that are deployed
with Wandera capabilities.
The third, the override endpoint,
allows you to override
the current device risk
based on any context that you wish to use.
This is often used for conditional access
with Jamf private access.
Now on to the fun part, using the API.
Getting started is simple.
Just head to RADAR
and navigate to Integrations,
then the Risk API.
Here you're able to generate a new API key
or revoke an existing one.
When you generate a new API key,
you'll be asked to name it
for easy identification in the future.
Once you've done this,
you'll be given an application ID
and an application secret.
Make sure to note down the secret
as it will not be visible again.
Once you've got your basic credentials,
you can call the login endpoint
to get your token.
You can do this by making a call to
the login endpoint using basic auth,
with the application ID as your username
and the application secret
as your password.
This will give you a JSON web token,
or JWT,
which will authenticate your other calls.
For security reasons,
each token is only valid for 15 minutes,
and will need to be renewed simply by
following the same steps all over again.
Once you have your token, you're ready
to start making calls to other endpoints.
For example, when calling
the GET Devices endpoint,
you will set the authorization type
to bearer token with the value being
the token you received
from the previous login endpoint.
A successful call here will result
in a 200 status code,
and you can see that you're able
to see your requested data.
Now let's take a look
at what the response shows.
Each device record will show
the device identifiers and the risk state,
deployment and activity status,
as well as the sync status with a UEM,
like Jamf Pro,
if this is a managed device.
Finally, in the response,
you can also see pagination information
if the return data set is large
and needs to be split up.
You can navigate through the pages
by using the endpoint parameters
page and page size
in order to retrieve all of your data.
Now let's see it all in action.
Here's a demo showing you how
a simple script will cull the login
endpoint to get the token,
cull the devices endpoint,
run through the paginated responses
to get data on all of your devices,
and output the high risk devices.
Once this is done,
this can be extended to take specific
action for these high risk devices,
or forwarded elsewhere as it's required.
The Override Endpoint works similarly
to the Devices Endpoint that we just saw.
However, this one allows you
to change the data,
specifically the risk state of a device.
With this endpoint,
you'll need to provide a payload
telling the API what needs to happen.
In this example, we're setting the risk
of the list of devices to low
with the source being manual
as we're setting it.
You can include multiple device IDs here
if you need to make a bulk change.
And a successful cull here will result
in a 204 no content response,
telling you that the payload was accepted.
Another cull with a slightly different
payload will reset everything
back to normal.
Here we set the source to Wandera,
meaning that for the listed device,
we want to have the risk calculated
once more by Wandera's
risk calculation algorithms.
What can you do with the Risk API?
You can use it for
automated risk assessment.
You can use it for compliance reporting
if you have specific requirements
in that area,
or you can use it for conditional access
to sensitive corporate applications.
What does this look like
in practice, though?
Let's take a look at a demo showing you
how powerful the Risk API can be
when used with Jamf Private Access
and risk based access policies.
Here we'll create a risk based access
policy for Google Apps,
and define the policy to block
any high risk devices
from accessing these Google applications.
Let's see this in action.
As with all risk API steps,
we start with creating an application,
which will give us an application ID
and secret.
For now we'll use the one that
we've already set up before.
Now we'll create a risk based
access policies for Google applications.
Within this policy,
we'll define that only applications
which are medium risk or below
are able to access this application.
So high risk devices will not be able
to access Google Apps,
such as Gmail, Google Drive,
and others.
If we go to the security screen,
we can see what the current state
of this particular device is
that you see on the left hand side.
We can see that it's medium risk,
so it should be granted access
to Google applications like Google Drive,
and the device is able to access
confidential data within it.
Now let's use the API to adjust the score
to mark the device's high risk.
First we'll use the login endpoint
to get the token.
And then we'll use the token in order to
authenticate ourselves against the second
endpoint in order to override the current
device risk and set this to high.
If we refresh the page,
we should now be able to see this change
being reflected on the security screen.
Now that the device is high risk,
let's see what happens
when the device tries to access
the same resource once more.
As it's a high risk device,
we should expect that this device
should no longer be able to access
confidential data within Google Drive.
And we can see that it's blocked
from doing so.
Depending on the admin's policy,
the user at this point would also receive
a push notification to let them know
why they weren't able to access
a particular resource.
Now let's take it back
and revert the change.
And once more, start using
the Wandera's risk calculation
and see if the device is able
to access the resource now
that it's back to being medium risk.
So if we go again to Google Drive
and try to access
the confidential document,
you should see that the device
is now able to do that.
I'm afraid that is it for this session.
I hope this session gave you insights
into how you can connect with Wandera
data streams, and the Risk API
and it gave you some inspiration
for your own use cases
that you'd like to power through them.
Wanting to thank you all
for attending today.
Don't forget to hit the like button
and subscribe if you want more content.
Thank you.