Skyhook Introduction

Skyhook Framework

Skyhooks was developed to overcome the inability for Cloud based applications to send events [webhooks] directly into a ClearPass that was typically deployed on the Trust side of a corporate firewall. In short the service runs in AWS, ClearPass nodes running on-prem use extensions to open a persistent connection into Skyhooks to receive the events originally sent from a 3rd party cloud application specific for that customer/tenant, we’ll go into greater depth of the components. Recently the Skyhooks framework has been re-developed to ensure that security is at the heart of the framework and any concern around PII/GDPR are addressed. At this time we have over 100+ active customers utilizing this service. The new service we are moving to is internally referred to Skyhookv2, as part of the move from the original Skyhook service, the extensions currently in use will need to be re-factored to incorporate changes in the framework supporting data encryption for data-in-motion and data-at-rest.

So, what exactly is a webhook? A webhook (also called a web callback or HTTP push API) is a way for an app to provide other applications with real-time information. A webhook delivers data to other applications as it happens, meaning you get data immediately. Unlike typical APIs where you would need to poll for data very frequently in order to get it real-time. A number of the integrations we have can benefit greatly from a real-time view of other systems or certain workflows mean that without a real-time framework the integration is basically broken.

Here are two popular use-cases we have been developing recently.

1. Cloud based Guest/Visitor Integrations such as Envoy/SINE and soon TEEM Lobby-Connect rely on a real0-time iteration such that as events are created on the 3rd Party Guest, a webhook event is triggered to ensure the Cloud guest account is reciprocally created inside ClearPass Guest to allow the Guest to signing to the local guest WiFi.

2. Another workflow that benefits greatly from a webhook framework is MDM integrations. Historically CPPM has polled hourly by default, [some customer poll longer due to the size of their tenant DB], and retrieves endpoint data, ingests this data, parses it and ultimately writes this to the EndpointDb in CPPM. A number of the attributes we have are extremely relevant to the device and how the device should be treated when it access or is on the corporate network. i.e. If a user deploys a blacklisted application or they jailbreak/root the device, its appropriate to quarantine this device on the network. However if we allow a device on the network then the user installs the blacklisted application, CPPM does not know this device is now our of Corporate Security Policy, the MDM vendor know but historically has no way to let CPPM know. Having the MDM system send us a CPPM webhook notification allows us to have a real-time view on the current posture of a device and appropriate respond. The other huge benefits to this process allows a customer to effectively not POLL, as mentioned above the polling can take hours to complete for some of our largest MDM customers, utilizing webhooks to ’trickle-feed’ events through, m such as new-davie or device-retired again allows CPPM to maintain a real-time view of the tenants managed devices.

Also thats the overview and a couple of common use-cases, but what makes Skyhooks tick? So the starting point for this is the service which the 3rd party cloud applications send their webhooks to, this is a service in AWS called a lambda serverless compute, I think of it as a “service as a function”.

From AWS website:

“AWS Lambda lets you run code without provisioning or managing servers. You pay only for the compute time you consume - there is no charge when your code is not running.*

With Lambda, you can run code for virtually any type of application or backend service - all with zero administration. Just upload your code and Lambda takes care of everything required to run and scale your code with high availability. You can set up your code to automatically trigger from other AWS services or call it directly from any web or mobile app.”

So, thats Part1, your webhook message hits this service, then this data is written into a DB called Firebase, a product built by Google. at this stage data is stored & encrypted per application/customer. Part2 The extension that site on-prem running on ClearPass has a persistent connection to this DataBase and effectively retrieves the data per application/customer. There are per application/customer db keys that are used to encrypt the data in FireBase, these keys must be configured in the extension to allow it access, retrieve and decode the data.