Cloud Application Instance Awareness Using Netskope
Background
Around 2012, firewall providers added application identification and control into their technologies, and while this capability was initially well received, risk appetite and working conditions have changed. Since then, organizations have looked to become more agile, reduce outages and remove themselves from the constant cycle of upgrading on-premises applications by adopting SaaS services like Microsoft 365. While the prevalence of SaaS services was increasing, the initial approach firewalls took at identifying, classifying and enforcing policies against cloud applications struggled to keep pace.
Using the legacy application identification and enforcement model to identify and classify applications, many organizations had to take the binary approach of deciding to allow or deny the use of an application. In today’s hybrid and distributed environments this approach doesn’t allow organizations to limit user activity depending on the instance of the application, regardless of whether the application is sanctioned or unsanctioned.
Wait, Isn’t a SaaS App, Just a SaaS App?
For many firewall and secure web gateway product manufacturers, the answer to this question is yes. For Netskope the short answer is no, and the longer answer is the SaaS app and type of application is just the starting point. For many applications, Netskope can not only identify the application, but it can also identify the instance of a SaaS app, allowing for more granular policy controls instead of the traditional binary approach.
While some applications offer instance details in the URL, others do not, even if they’re part of the same suite. Take, for instance, Outlook Online and SharePoint Online. With SharePoint Online the instance can be identified in the URL, but this isn’t the case for Outlook Online. Organizations determining instances of SaaS applications shouldn’t rely on URLs, as tech companies can decide to move to a more general address (without soliciting input), potentially leaving the enterprise reacting to a service being blocked.
Instance identification is one of many areas where Netskope differentiates itself from the competition. When Netskope is inline for all web and cloud traffic, it can identify instance details for popular applications like Google Workspace, Microsoft 365 and Box, regardless of whether the applications are personal or business versions. Netskope can identify instance details from the user’s session by inspecting API calls and JSON responses.
Diving Into the Details
The above screenshot shows the application details for Outlook online that Netskope captures. As you can see, my access to outlook.office.com was identified as a greystreetlabs instance and is what is set within the M365 tenant. Also, Netskope performs classification of the category and application, which allows organizations the traditional approach of allowing/denying the use of a site/application based on the category or application.
In this screenshot, you’ll also notice Netskope offers the ability to create your own instance name for use within the Netskope console. While Netskope identified my OneDrive for Business instance as greystreetlabs, I created a custom instance name that can be used within Netskope’s real time policies for granular control to reduce DLP false positives.
To demonstrate Netskope’s granular control based on applications instances, we’ll walk through an example of how the controls translate into policies. The scenario is as follows:
- Dave is an employee of Grey Street Labs and needs to share data with a partner called Acme Find. Acme Find has shared a OneDrive for Business folder with Dave for collaboration.
- Dave will also need the ability to download from Acme Find’s shared folder.
- Grey Street Labs has other business partners that need to share data with Dave, but there’s no need for him to share his own data with these partners.
For simplicity, in this example all organizations use M365/One Drive for business; however, Netskope can identify instances for a variety of applications and limit access and functionality in a similar fashion.
Let’s Look at an Example
In policy #1, any Grey Street Labs user is permitted to upload into and download from their sanctioned instance of OneDrive for Business if the files don’t contain malware.
In policy #2, I’m restricting uploads to Acme Find’s OneDrive for Business to Dave and ensuring the data he’s uploading to their instance has no PCI data.
In policy #3, Dave is allowed to download from any instance of OneDrive for Business if it doesn’t contain malware; however, he will be unable to upload data to OneDrive for Business instances other than Grey Street Labs or Acme Find.
The combination of these policies allows Grey Street Labs to provide their users access to sanctioned cloud applications without disrupting partner business processes, reducing DLP false positives when it makes sense and ensuring malware isn’t being introduced into the environment.
Conclusion
Netskope’s instance awareness functionality in their Cloud Inline and Next Gen Secure Web Gateway fills the void between basic allow or deny policies, permitting granular controls across SaaS apps. The level of specificity within policy definitions is impossible to implement without the capability to build controls based on the instance level classification for the application.
Gloss