Securing Horizon With Cloud Hosted Workspace ONE And Carbon Black

For over a decade VMware's VDI solution has served up on-premises Windows desktops to remote Windows and Mac devices.  While the original solution at its core has stayed relatively the same, the ability to secure Horizon sessions through a tightly integrated SaaS stack represents a dramatic shift.  Using cloud instances of Workspace ONE Access, UEM, Intelligence and Carbon Black customers wrap comprehensive security around an already stellar remote Horizon user experience.   The cloudiness of these offerings means this security is easily layered onto existing Horizon environments non-disruptively, with minimal on-premises footprint. 

Base Image Stolen From Andreano "The Moose With The Juice" Lanusse

This ideal remote access scenario begins with Horizon making virtual desktops and published applications available to the external world through Unified Access Gateway.  Authentication for these Horizon sessions is brokered by a cloud instance of Workspace ONE Access that enforces contextual authentication requirements through conditional access policies.  Workspace ONE UEM informs these policies with device posture insight, while also actively managing and securing these remote endpoint devices.  Additionally, Carbon Black provides Next-Gen Antivirus protection not only for Win10 or macOS endpoint devices, but also for the virtual desktops or RDS hosts remotely accessed through Horizon.   Finally, WS1 Intelligence pulls these solutions together, enhancing automation while further calibrating conditional access policies with information regarding anomalous or risky behavior. 

This post is a primer on how cloud instances of Workspace ONE and Carbon Black are layered onto Horizon deployments to beef up security for remote access.  It starts with a brief overview of Horizon remote access, then elaborates on the security enhancements provided by these cloud services.  I'll essentially break down and explain the image above with, yet, more stolen images!  Yes, for this post I've gathered some of the best images I've ever stolen, modified or otherwise used and abused in the name of love and technical clarity.  After using these images to illustrate the security enhancements enabled for Horizon from the cloud, I’ll move on to review VMware’s Secure Access, a key component of the Anywhere Workspace offering.  VMware Secure Access offers an interesting alternative to Horizon, one that extends the benefits of SD-WAN and SASE to a less centralized remote access deployment. 

Delivering Windows Desktops Or Published Applications Through Horizon

Stolen From Todd Dayton

The above graphic presents a rudimentary but conceptually useful breakdown of VMware Horizon.  To begin with, you have a desktop or RDSH image living within a VM, supported on the same vSphere technology used for traditional server workloads.  A Horizon Connection Server, very much the brains of a Horizon deployment, has full admin access to this vSphere environment, using those rights for provisioning and inventory purposes.  This Connection Server also acts as a broker for incoming connections, routing users to their assigned desktops or RDS hosts after they've been authenticated.  User's eventually view and remotely control their desktops or published applications through display protocols like Blast or PCoIP. 

So, to extend vSphere goodness to desktops we've had to bring the desktops to the vSphere infrastructure, with the desktop OS and supported apps shifting locality from the endpoint to the datacenter.  From there, the Windows desktop is essentially converted into a service that can be consumed from pretty much any device that has network connectivity to the Horizon environment.  The benefits of this model really start to pop when folks are mobile or shifting across various devices.  While your device and network location may change, your virtual desktop stays the same, maintaining the Windows desktop session state.  This leads to a consistent and reliable user experience often referred to as a "Follow-Me" desktop, a concept that's been breaking hearts and taking names in healthcare for over a decade. 

With doctors and nurses highly mobile within the walls of a hospital this "Follow-Me" desktop experience really shines, especially when combined with a badge access solution like Imprivata.  As a 13 year veteran from the mean streets of non-profit healthcare IT, I'd say this user experience is impossible to beat when supporting clinicians and is what drives a lot of VDI adoption in healthcare.  Here's a quick demo: 

High mobility, along with the need to share work areas, make clinicians uniquely suited to benefit from this model.  That said, if you're an office worker with a dedicated cubicle and a dedicated workstation tethered to it, and all your work is done within that cubicle, then the "Follow-Me" desktop lacks wow factor.  However, as soon as you throw in any kind of mobility, even if it's just between cubicles, the question of, "Why bother with Horizon?" starts to melt away.  Throw in remote access from home, possibly in a BYOD scenario, and the question is completely obliterated.  In those scenarios, a "Follow-Me" desktop, one that follows you from work to home, then back, makes for the most ideal Windows user experience imaginable. 

Original Image From: Using Horizon To Access Physical Machines

The path these remote Horizon sessions take to your trusted network from user's homes is provided and secured through Unified Access Gateway.

Providing Remote Access To Your Horizon Service

Remote Horizon access is enabled through Unified Access Gateway (UAG), a Linux virtual appliance that's typically deployed in a DMZ.  It acts as a gateway for your external Horizon users, ensuring all traffic from the remote endpoint device to the virtual desktop or RDS host is on behalf of a strongly authenticated user.  Below is a depiction of Blast, Horizon's display protocol of choice, as it traverses a UAG appliance after successful authentication.  Encryption of this traffic is handled end to end for the entire session through the Blast protocol itself. 

Now, as far as the initial authentication goes, there's various options with UAG.  The default authentication method is passthrough against Horizon's local AD environment by typing in an AD username and password.  However, when Workspace ONE mode is enabled on Horizon Connection Servers, UAG passes SAML traffic for authentication instead, ensuring all Horizon Blast traffic passing through the UAG appliance is for users that have been authenticated according to conditional access policies defined in Access.  Leveraging WS1 Access in this fashion provides admins with the most flexibility and widest range of options when it comes to securing remote access to Horizon.

Brokering Authentication For Horizon Using Workspace ONE Access

Conversations around Workspace ONE Access typically focus on the portal and SSO experience it provides for Horizon and 3rd party SaaS apps.  What's often neglected is how WS1 Access acts as broker for different authentication methods as someone initially logs into the portal or accesses a specific app.  Through conditional access policies admins enforce contextual authentication against the various security solutions WS1 Access has been integrated with.  Auth requirements for any particular app will be determined by the specifics of theses policies and a user's current context.  App access may be a simple SSO experience or as complex as MFA from a fully enrolled and compliant device.  For a deeper dive on conditional access polices and SAML check out this overview on youtube. 

Base Image Stolen From Peter Bjork

Several of the inbound authentication options detailed above are made possible through the deployment of a Workspace ONE Access connector in the customers trusted network.  This connector is key to an integration with an AD environment, syncing AD users to Workspace ONE access and providing the ability to authenticate to AD.  It also enables your tenants integration with on-premises resources such as your Horizon environments or security solutions that support RADIUS. Depending on the specifics of your deployment these WS1 Access Connectors may be the only necessary additional on-premises resources required for securing Horizon from the cloud. 

Now when it comes to integrating WS1 Access with 3rd party security solutions, SAML chaining allows for integration with popular names like Okta, Ping, Azure, as well as any other solutions that support SAML.   After configuring these 3rd party solutions as trusted IDPs for WS1 Access we can  leverage their authentication mechanisms for applications managed through Access.  Below is an example of this process for an Okta integration, something I'm seeing a lot of nowadays.  With a fully documented process for configuring Okta as an IDP, "Integrating VMware Workspace ONE With Okta,"  it's a very accessible option for Workspace ONE customers who already leverage Okta for MFA.  

WS1 Access is basically integration goo, allowing you to integrate Horizon, or any other SAML compliant apps, with whatever security solutions you already have in place.  By linking up with these 3rd party solutions we enjoy a richer set of conditional access policies, as we pick and choose amongst various auth requirements for Horizon across different use cases and scenarios.  This ability to integrate with the security solutions customers are already using to protect their environments makes WS1 Access truly compelling.  You end up with something a bit motley and Frankenstein-ish, or pickle-Rick-ish if you will,  but arguably that's sort of unavoidable when you're stitching together disparate solutions from across your enterprise.  

A WS1 Access deployment is only as interesting as the solutions it's been integrated with.  While support for SAML and RADIUS integrations with 3rd parties offer many alternatives,  where things get really exciting is with the built-in support for Workspace ONE UEM.  When looking at the Inbound/Outbound graphic above, mechanisms like, "Certificate," "Mobile SSO For Android," "Mobile SSO For iOS," and "Device Compliance," result from the integration between Workspace ONE Access and Workspace ONE UEM.

Informing Conditional Access Policies With Device Status Insight From UEM

When Workspace ONE Access and UEM are integrated Horizon access can be predicated on enrollment or even device compliance. This leads to a much more discerning, richer set of conditional access policies.  Essentially, we're taking WS1 Access conditional access policies and juicing them with UEM insight, leading to more informed polices to drive contextual authentication.

Stolen Image From Andreano Lanusse

This progression towards zero trust begins with the various certificate based authentication options supported by the integration of UEM and WS1 Access.   Going back to the Inbound/Outbound graphic of the previous section, the arrows for, "Mobile SSO for iOS," "Mobile SSO for Android," and "Certificates," for Win10 and macOS, are enabled through the integration of WS1 UEM and Access.   While these methods are enforced through Access, the certificates are delivered through UEM, effectively mandating device enrollment in UEM for access to Horizon.  Further, "Device Compliance," can only work in conjunction with one of these authentication methods.  So, in the case of modern management, we're talking about a combination of Certificate auth through WS1 Access, certs delivered through UEM, as well as UEM device compliance policies for Win10 and macOS.  

While device compliance policies wonderfully highlight the ability to interrogate devices with UEM, WS1 UEM enrollment actually MAKES devices more secure.  It's not just about interrogation, but also the ability to help the device course correct and achieve a secure posture.  The nitty gritty, under appreciated work that is, none the less, absolutely critical to security, like patching, firewall configuration,  device encryption and general configuration management falls right in the wheelhouse of WS1 UEM.  So along with vouching for the state of the device it's also literally making it more secure.  This management and control is further extended through an integrated deployment of Carbon Black, a Next-Gen Antivirus solution for Win10 and macOS.

Carbon Black

While UEM management addresses security concerns from the perspective of system configuration and maintenance, Carbon Black addresses security head on when it comes to fighting off hackers, malware and Ransomware.  Core to the suite is cloud based Next-Gen antivirus and behavioral EDR, with an option to fall back to more traditional signature protection.  Carbon Black's NGAV and EDR entail the application of machine learning and AI against data aggregated from millions of customer endpoints. We're talking over 500 TB of endpoint data, over 1 Trillion events a day, getting reported to and processed in the Carbon Black cloud.  This insight is then brought to bare when controlling behavior on endpoint devices.

While cloud is core to Carbon Black's security insight, it has the added benefit of making Carbon Black easier to deploy and manage.  For a typical customer there's zero on-premises infrastructure to be concerned with.  You have a cloud tenant to configure and an agent to deploy to your Win10 or macOS devices and that's the extent of your concern.   For Horizon VDI environments you can simply add the agent to your gold images and you're off to the races. For endpoint devices Workspace ONE UEM itself can easily distribute the agent to managed endpoints.  

Workspace ONE Intelligence and VMware Carbon Black: Automating Device Quarantine Feature Walkthrough

Even more exciting is the ability to trigger actions in Workspace ONE UEM based on threats detected by Carbon Black on managed endpoint devices.  So, for example, if a threat is detected on a device not only can Carbon Black respond, but additional measures can be automatically executed through WS1 UEM to remediate the endpoint.   This is made possible by WS1 Intelligence and the ruthless automation it can enable for  WS1 environments.  

Workspace ONE Intelligence - Gelling It Together Even Further

For this ideal remote access Horizon scenario, Workspace ONE Intelligence introduces ruthless automation while also informing conditional access policies with User Risk Scores and Login Risk Scores.  As mentioned above, we can trigger automated workflows within Intelligence based on threats detected by Carbon Black.  We can also trigger this automation based on device info gather from WS1 UEM, which includes over 200 data points.  Should you require data not collected by UEM out of the box, you can collect additional attributes using custom Sensors for your modern management scenarios.  Sensors enable this extensibility using PowerShell scripts on Win10 or bash, python and Zsh scripts on macOS.  

The data collected within the Intelligence data lake drives ruthless automation that ensures Win10 and macOS devices are properly configured.   This data is also leveraged to generate User Risk Scores and Login Risk Scores ingested by conditional access policies.  In this manner, WS1 Intelligence Risk Analytics enable WS1 Access to calibrate contextual authentication with data regarding anomalous or risky behavior.   

VMware Anywhere Workspace 

Cloud instances of WS1 and Carbon Black offer existing Horizon customers a clear path forward for enhancing security.  However, if Horizon isn't viable but you still have a remote use case you'd like to enhance with the security capabilities  discussed so far, then you probably want to check out VMware's Anywhere Workspace. Workspace ONE and Carbon Black are core to the Anywhere Workspace solution and can enhance VMware Secure Access with some of the same benefits they lend to Horizon. Secure Access marries together Workspace ONE with VMware's SASE solution based on SD-WAN by VeloCloud, offering an alternative that overlaps with remote Horizon access but, more notably, enhances connectivity and security for remote endpoints from the cloud. 

Where Secure Access first differs from Horizon is that instead of providing remote connectivity to a desktop or RDS host back in the datacenter, you're running applications locally on your modern managed Win10 or macOS devices. Workspace ONE UEM can provision these applications as well as provide them remote access back to your trusted network through Workspace ONE UEM's Per-App VPN.  With this model a TLS session is automatically established back to your trusted network for specific applications based on device compliance policies.  This is ideal for a traditional client/server application running locally on your endpoint or perhaps a browser hitting an internal site.  Per-App VPN has always distinguished itself from traditional VPN solutions by limiting VPN connectivity to specific defined apps, rather than the whole device.  Further, it simplifies access because there's no need for a user to manually launch a VPN client. Instead, a TLS session is automagically established on behalf of the users when the enabled app is launched.

Deploying VMware Workspace ONE Tunnel: Workspace ONE Operational Tutorial

Per-App VPN has been part of the AirWatch portfolio for over half a decade, supporting modern management use cases for years.  Secure Access innovates by delivering this Per-App VPN capability through VMware's SASE offering, merging WS1 with VMware's SD-WAN solution. (Velo-Cloud). With this model instead of supporting Per-App VPN through VMware Tunnel on a UAG appliance sitting in the customers DMZ, the VMware Tunnel Service is hosted on behalf of the customer within SASE PoPs.   In a nutshell, VMware Tunnel is hosted as a service, in containers, simultaneously across various SASE PoPs.  Per-App connections are routed from the Tunnel app on endpoint devices to the closest SASE PoP, with most users able to find one within 10 milliseconds of latency.  Once traffic hit's this PoP the benefits of VeloCloud SD-WAN are extended to this VPN access, with optimized connectivity to corporate data centers as well as SaaS and cloud service providers.    

Along with enhancing network connectivity we're getting security enhancement from within the SASE PoP through Cloud Web Security.  This new offering introduces features like SSL inspection, URL filtering and content filtering.  So with the VMware Secure Access model you're not only farming out management of VPN concentrators or UAG instances, you're also moving traditional security security services from on-premises to the cloud.  Running these services within the SASE PoPs circumvents the need for hair pinning internet traffic back through your on-premises network for inspection, certainly a boon for remote performance.  

Though there's overlap between Horizon and VMware Secure Access capabilities, they are very different solutions with different strengths and caveats.  If you're looking to offer a highly curated Windows experience, particularly one that supports a traditional client/server app hosted internally, Horizon is compelling.  All that nitty gritty, unsexy, and persnickety Windows management, in particular customization of Windows applications, is centrally handled and managed by Horizon in a model that's over a decade old. Further with Horizon itself supporting SAML, you're extended the full breadth of WS1 Access capabilities when protecting legacy Windows applications. That said, VMware Secure Access is certainly an intriguing proposition, offering optimized connectivity to corporate networks and the cloud while moving security services closer to remote users.  Ideally, as a customer I'd want Horizon around for the more meticulous Windows requirements, while leveraging Secure Access for everything else.  

 

Final Thoughts

A couple months ago I presented this best case scenario for remote Horizon access to a session full of jaded, cynical and curmudgeonly IT veterans.  As we digested the current state of the entire VMware EUC stack regarding remote access, I think our collective experience was similar to a parent who has just realized, "holly cow, my baby has grown up and baby is bad!"  While VDI over the last 5 years, at its score, has stayed largely the same, albeit with tons of polish and stability enhancements, the methods for securing its remote consumption have very much changed and evolved. A decade ago it was all about, "slap a horizon client on whatever you want, no data will be at rest on that remote device, so, don't worry, be happy." Fast forward to 2021, we can now ensure that a device remotely accessing Horizon is absolutely secure and virus free, while authenticating a user from that device according to a wide range of contextual authentication options. This is all achieved leveraging mature and proven solutions delivered from the cloud, services that not only radically improved remote Horizon security but are also the foundation of VMware's new Anywhere Workspace offering.  

VMworld 2021 Announcements 

Several VMworld 2021 announcement regarding futures certainly shore up the already impressive story covered in this post.  Continuous authentication, enhanced conditional access policies and support for Horizon on SASE show a lot of promise and further reenforce overall confidence in the VMware remote access vision.  Additionally, cloud driven enhancements for simplifying on-premises Horizon management further elucidates a general trend of, "if you can't bring desktops to the cloud, bring cloud services to the desktops."  I only failed to mention these announcements till now because, as a drearily sane engineer from healthcare IT, if a technology wasn't at least 6 months old, I just couldn't take it seriously.  Along those lines,  everything covered in this post up till this section is grounded in the here and now of what is GA'd and available.  Yes, there are some shiny improvements on the way, but there's plenty to be accomplished with the stack as it stands today. 

Ruthless Automation With Workspace ONE Intelligence

A common description of Workspace ONE Intelligence goes like this: it allows you to aggregate, correlate and automate. While this is accurate, I'd like to reverse the order, emphasizing the solution allows you to automate, targeting this automation based on data aggregated in the Intelligence cloud.  WS1 Intelligence enables ruthless automation and that truly distinguishes it as solution.   It provides the ability to trigger automated responses across iOS, Android, Win10 and macOS devices anywhere in the world.   We can finely tune and customize these actions within a WS1 UEM environment and, further, potentially extend this automation to any 3rd party solution that supports a REST API.   

This post begins by exploring the built-in automation capabilities of WS1 Intelligence for WS1 UEM, Slack, and ServiceNow.  Through Intelligence, "Workflows," actions across these environments can be chained together to formulate a wholistic response to targeted incidents or state changes.   Next, this article will review how custom connectors not only allow us to finely tune these triggered responses, but also extend the reach of Intelligence automation to 3rd party SaaS apps that support a REST API.   To that purpose I'll explore the use of Postman in the creation of these custom connectors, using ServiceNow as a model. Finally, I'll circle back to the data within Intelligence that triggers this glorious and ruthless automation. 

Built-In Automation For WS1 UEM

Common tasks executed through the WS1 UEM console can be automated through WS1 Intelligence.  Out of the box there are 28 built-in actions for UEM available within the Intelligence Workflows, anything from removing apps or profiles to enterprise and device wipes. Further, as a catch all, there's the option to TAG devices, which opens up the possibility to achieve anything normally accessible through policies and smart groups.  Below is a partial screen shot of the UEM automations built-in to Intelligence.  The official documentation enumerates these 28 options under the section, "Automations For Workspace ONE Intelligence." 

For those familiar with Workspace ONE UEM, another way to think of Inteligence is as an advancement of device compliance policies. Through device compliance policies we've always had the ability to trigger a handful of actions based on a handful of device properties.  A compliance engine drives the enforcement of, "closed-loop workflows where a user can have resources after becoming compliant again."   While device compliance policies are great at enforcing compliance, again, they're narrowly focused on a handful of device properties and actions. 

Compliance policies are still relevant, however, in terms of pure range of actions, Intelligence takes automation to the next level, allowing folks to automate pretty much anything that can be done from the UEM console.  Further, these actions can be triggered by an extensive range of attributes collected in the Intelligence cloud, with hundreds of UEM gathered device traits to choose from, let alone information gathered from Sensors or Trust Network partners.   

So along with a wider range of actions we also gain the ability to drive this automation with information from the Intelligence data lake.   Further, these actions can transcend the WS1 environment, extending to 3rd party apps that support REST APIs, starting with the built-in connectors for ServiceNow and Slack. 

Built-In Connectors For ServiceNow And Slack 

Along with WS1 UEM, there's built-in actions for ServiceNow and Slack.  For ServiceNow there's options to create incidents and tickets, while for Slack you can send messages to channels and users.  Enabling these integrations is simply a matter of adding base URLs and credentials to preconfigured connectors, so existing ServiceNow and Slack customers can quickly extend WS1 Intelligence goodness to these solutions.   As you leverage these built-in automations within, "Workflows," there's options to populate fields with relevant variables from WS1 Intelligence, as illustrated in the image below.  

For a wonderful overview of enabling these built-in connectors check out this video in Tech Zone, VMware Workspace ONE Intelligence: Connectors - Feature Walk Through. It not only reviews the process of authorizing these connectors but also introduces WS1 Intelligence Workflows, the mechanism for defining automated responses to changes within your environment.

Chaining Automations Together With Workflows 

Through WS1 Intelligence Workflows IT departments define automated responses to events within their Workspace ONE environments.  These can include actions through UEM, ServiceNow, Slack and any 3rd party solution they've developed a custom connector for.  Workflows not only streamline responses and resolutions but also enable proactive remediation before a user has been impacted by challenges.  For example, consider a situation where someone is running low on disk space.  Instead of having a user slowly experience performance degradation Intelligence can proactively trigger a series of actions. 

In the example above, when a device has less than 2 gigabits of storage the user is sent an email notification through WS1, a ticket is automatically created in ServiceNow, and a message is sent to the IT team through Microsoft Teams.  This not only saves time for staff but also spares the user from performance degradation.   The video below includes a demonstration of Workflows and also provides a general overview of integration options between Workspace ONE and ServiceNow.

The integration with Teams in the video above was made possible by a sample custom connector that interacts with a Microsoft REST API.   It's a great example of the extensibility made possible by custom connectors. 

Sample Custom Connectors

Similar to the built-in connectors for Salesforce and ServiceNow, you can create custom connectors for other 3rd party applications that support REST APIs. In a nutshell, if you can execute a task in a 3rd party app with a single request through Postman there's potential to automate that process through WS1 Intelligence.  Sample custom connectors are available from the VMware Sample Exchange, under the description, Workspace ONE Intelligence Custom Connector Samples.  These sample json files,  collections that have been exported from Postman, can be directly imported into WS1 Intelligence to integrate with solutions like Jira, Salesforce and Remedy.   For instance, the messaging to Microsoft Teams shown in the demo video above is achieved through a direct import of one of these samples.   

While you can import these samples directly into WS1 Intelligence as is, you can also import them into Postman to take them for a test spin or tweak them out according to your needs. 

Postman, a REST Client that allows you to easily develop and test out REST API calls, is what Workspace ONE Intelligence itself uses behind the scenes to execute actions defined for connectors. Fortunately, the free version of Postman available at postman.com has all the features you need to create your own custom connectors. There's an excellent overview of the tool at https://learning.postman.com/, though I'm also quite fond of this short and concise ServiceNow oriented post in ServiceNow Communities. Given the ubiquity of REST APIs throughout the Horizon and Workspace ONE stack it's a nifty tool to have lying around. 

Creating Your Own Custom Connector 

Creating your own custom connector begins with developing calls to the 3rd party solution's APIs through Postman.  Once you have a request successfully tested you perform an export from Postman to a JSON file that's imported into Intelligence.  After the import's complete you'll have access to the call within the Intelligence Workflows interface.  Further details are provided in Workspace ONE Intelligence Custom Connector Samples and within the official guide under the section, Custom Connectors.  To illustrate the whole process from start to finish the following is an example customization for ServiceNow.  

Below is a request to ServiceNow that will create a new task under, "Service Catalog."  It's based off of ServiceNow's Table API and it's sc_task action for adding catalog task records.   Accordingly, within Postman I've entered in the proper URL for this call along with parameters and authorization.  

When this request is successfully sent a new task is created within ServiceNow.  With the logic validated and tested you can begin the export process by saving this successful response as an example. 

Also, be sure to add the header, Content-Type: application/json, or else the import process into WS1 Intelligence will fail.  

Finally, with the collection selected in the Postman interface choose export and go with Collection v2.1 as the export type. 

Next, you want to take this JSON and import it into WS1 Intelligence. From within the Intelligence console navigate to Integrations --> Workflow Connectors.   Click on the option, "Add Custom Connector."  You'll be prompted for a custom connector name, as well as for a base URL and authorization for ServiceNow.   Once you provide this information you'll have an option to import the JSON that's been exported from Postman.   

After a successful import you'll see the imported action.  You can also test out the imported action as part of the import process. 

Going forward you'll have this action to choose from when developing Workflows within WS1 Intelligence.

 

To recap, if you can automate a task in a 3rd party app with a single request through Postman, there's potential to automate that process within WS1 Intelligence. That's not to say you can do anything and everything available in the 3rd party app's REST APIs. You're restricted to a single request, quick outbound calls without any kind of back and forth or chaining of request, so your mileage may very. However, a good friend of mine pointed out that a lot of times the 3rd party applications offer customizations of their services that allows you to push this trickier logic over for them to handle. A great example of this are the options in ServiceNow to create custom APIs.

ServiceNow Options 

A few features of ServiceNow in particular make it well suited for integration with Workspace ONE Intelligence. To begin with there's the ability to create custom REST APIs and web services.  Earlier I mentioned that WS1 Intelligence is limited to leveraging single calls from Postman, without the ability to chain multiple calls in a collection.  Well, we can fill in the gap by creating custom services in ServiceNow, allowing for the handling of complex logic on the ServiceNow side of the equation.  A wonderful example of this is detailed in the blog post, "WS1 And ServiceNow," by David Pacold.  In this post David offers a recipe for populating ServiceNow with device asset information from WS1 by creating a system web service in ServiceNow that's fed asset information from a WS1 Intelligence connector.   

Another benefit to ServiceNow adoption is its REST API explorer.   This utility, built right into ServiceNow console, facilitates the exploration and testing of REST API calls.  It provides the ability to test calls in real time while providing guard rails, if you will, as you explore the APIs functionality.  For example, to explore the Table API demonstrated in the previous section, you can open REST API explorer and select the api from an easy to use drop down menu.  Then, after choosing the REST operation type, it guides you through the different parameters that can be used by the API call.  

Further, after selecting the parameters, you can test out the call directly from the utility with the results displayed at the bottom.  If the results are desirable, you can copy the syntax of the command directly from explorer into the body of your request within Postman.    

Given the convenience the REST API explorer offers, a clear path forward when working with ServiceNow is: 

REST API Explorer —> Postman —> Collection_Export.json —> Custom_Connector

With a well documented Rest API, a Rest API Explorer, and various options for creating custom services, ServiceNow is an ideal candidate for WS1 Intelligence integration.  Fortunately, while ServiceNow provides a stellar example of what's possible, very arguably other 3rd party solutions will offer similar advantages.  The question of, "what can we automate in 3rd party solutions using WS1 Intelligence," boils down to, "well, what kind of REST APIs are available from these 3rd party solutions and what kinds of customizations do they support?"  Further there's the question of, "well, how comfortable and familiar are you with working with the REST API's of these 3rd party vendors?"  If the answer is, "very," well, there's a lot of potential for creating rich automations an integrations between Intelligence and that 3rd party app. 

Okay, Now Let’s Talk About Data

Now that it's clear what type of automation is possible and at stake, lets talk about driving this automation with data from Intelligence.  If there's a single theme or thesis for this entire post, it's this: we leverage data from WS1 Intelligence to drive and trigger glorious and ruthless automation.  Exploring Widgets within dashboards makes this clear. 

To illustrate, say you want to target an automation against a specific set of windows 10 devices. You might start with a simple widget that filters out devices from your environment by focusing on enrolled windows 10 devices that have checked in within the last 28 days.

Now, you have a very simple widget that targets these active Windows 10 machines.  If you wanted to target all these devices you could view the widget, click the automate button, then pick and choose from the automated actions.   However, if you wanted to narrow the results down, you could could leverage the group by function within the widget to subdivide the displayed results by a wide range of options.   

For instance, by choosing to group by encryption status, I have broken down the results into 2 sets of active Win10 machines, those encrypted and those that are not.   

As I click through this visualization, perhaps drilling down into the unencrypted devices, again, I have the option to associate automations with this subset of the original query.   

So the widgets give us a useful way to absorb the data in a more visual way, shifting away from one dimensional reporting.  Further as you crawl through the data you can add automations along the way.  To my mind, this is a wonderful example of not only the data made available intelligence, but ways in which the solution allows us to sift through the data and finely target automation.  

Sources Of Information For The WS1 Intelligence Data Lake

With automation driven by information from the Intelligence data lake a natural question to ask is, "well, just what information is in there?"  Out of the box there's a boat load coming from several datasources, as detailed in the TechZone article, "Workspace ONE Intelligence Architecture."  From WS1 UEM alone there's over 200+ data points last I counted.   Then there's WS1 Access for any applications integrated with the Workspace ONE portal through SAML.  For any internally developed apps that have the Workspace ONE Intelligence SDK embedded there's additional app analytics made available from the solution formerly know as Aptelligent.  Further, there's Common Vulnerabilities and Exposures (CVE) and Common Vulnerability Exposure System (CVSS) information pulled in on a daily basis about Windows 10 and macOS.  Finally, there's the extensibility afforded through Sensors, allowing you to pull custom information from Win10 and macOS using scripts.  Once collected, this information then becomes viewable and actionable form the WS1 Intelligence console, complementing the already extensive device information provided by UEM.   

Also, as depicted in the drawing above, we can populate Intelligence with threat information collected by security partners of the Trust Network.   This Trust Network partnership currently includes about a dozen partners, though Carbon Black is arguably the crown jewel.  Carbon Black can provide next generation antivirus protection and insight across both Windows 10 and macOS.  As with the rest of the data ingested by intelligence, this threat data can be used to drive automation through Intelligence, starting with WS1 UEM itself but also extending to any other enabled connectors. 

While I think WS1 Intelligence has potential to benefit most use cases, to my mind, modern management is where it shines brightest.   As someone who got clobbered by one worm after another throughout the 2000's, the ability to trigger a coordinated response to threat detection alone is extremely compelling.  The range of visibility across modern managed devices is impressive as well.   When you take the normal visibility offered through UEM, then enhance it with Sensors and Carbon Black, you're getting an awful lot of insight and perspective.  If security is top of mind for Win10 and macOS users this stack is hard to beat. 

Conclusion 

Over the last couple years I've slowly been won over by WS1 Intelligence.  I must admit, initially, I was a little bit cynical about the solution.   The earlier marketing material sounded to me like to the INXS song, Mediate. "It does everything that ends with, 'ate'! "  In my snarkier moments, I'd compare it to a Don King promotion.  "You will aggregate, correlate, automate then absolutely fustigate your IT challenges!!!  I don't care if your name is Kate or Nate!  It will be the greatest data lake that no one can imitate!  If you are into endpoint management it is your fate!!!"

However, the acquisition of Carbon Black, the introduction of Sensors and increased relevance of modern management have made WS1 Intelligence advantages much more obvious.  Increasing SaaS adoption and the introduction of custom connectors have also enhanced its overall appeal.  The ability to automate ruthlessly across managed devices and SaaS landscape is a downright intoxicating proposition that speaks to the souls of most techies I know.   We live for this stuff.