Netskope
The Netskope platform uses Active Directory, single sign-on or SSO brokerage mechanisms to steer traffic through a customer’s Netskope cloud gateway appliance. The Netskope CASB acts either as a forward proxy, a tokenizer and/or reverse proxy to cloud app destinations, depending on how a cloud application works. Some cloud apps, such as Office365, can need all three interactions, depending on the type of “sub-app” chosen, within Netskope’s construction.
This functionality is divided into progressive gradients of products for billing purposes. You can start with simple log discovery of what cloud apps are being used, by whom, when, and perhaps what’s being done. You can impose rules as the next gradient. You can add significant DLP, then add encryption features, and malware filtration. Or you can buy the full meal deal, which is what we tested.
Netskope, like other CASB products, becomes deeply enmeshed into your infrastructure. There are three major components used in the process of Netskope CASB, including an on-premises gateway appliance, an organization-specific cloud admin portal, and possible client-side agents. Although client agents aren’t required, they’ll provide greater access when present. The portal works with client agents and browser add-ins, or without them.
The SSO can be an Active Directory link, or another SSO service that understands SAML 2.0 — and nearly all of them do. Netskope has relationships with several SSO providers as “partners.” SSO is connected to Netskope as a proxy authenticator, and conversations are then managed by the SecureForwarder VM, itself based on an Ubuntu Server platform.
CASB control is asserted in the gradients we described through steered traffic mechanisms. Traffic is steered through the SecureForwarder appliance (or appliances, depending on the architecture chosen to be deployed). We used one gateway for testing, but the others can work somewhat autonomously, indeed you could use different encryption for geographic controls.
Access can be achieved via browser-enabled agents, or on mobile devices through a Netskope GoScope gateway. When a mobile device is under control (e.g. routed through the gateway), maximum features are available, we found. When an unmanaged device is used for access, it’s up to administrators to determine by cloud app, if access is allowed, and if possible (by features of the cloud resource) what accessibility will mean in terms of control and access.
Gateway interactions come usually via the SecureForwarder VM/software appliance, but since it is based on Ubuntu Server, it can also be deployed as a discrete server with the GoScope Secure Forwarder instance. We installed an OVA SecureForwarder appliance in our testing. We found the docs a bit wanting, but were able to eventually connect the SecureForwarder to our cloud test resources via Active Directory Federation Services and Windows WSAdmin. This said, Netskope seemed eager to help us.
Many supported cloud apps can have additional DLP rules applied to them, including an important one: if we can’t inspect the data, invoke a rule to sequester/jail the payload to be dealt with by an administrative type (of which there are three levels). This might be at a file level, or at a field level, or we found designed-in using FINREG or HIPAA data field examination, including “something like this, near something like that” logic. The possibilities are extensive, and administrative time sunk into astute design will likely pay well. We found filters understandable to design and deploy.
In execution, Netskope Introspection is a highly programmable administrative bot-like proxy process that scans supported applications for data using aforementioned DLP rules and triggers specific to the supported cloud app. As it doesn’t have quite the encryption power of CipherCloud, it does have very flexible rules that will be familiar to Unix/Linux programmers.
After installing the SecureForwarder VM onto a VMware substrate, we connected our Active Directory, and also WSAdmin services for Office365 cloud services. It’s a simple, three-step process. Client access was transparent; we did this through a browser agent which proxied an Office365 connection. When we had installed Secure Forwarding services, we constructed the platform to a supplied Ubuntu-based VM with three ports: management, input/ingress, and output/egress. DNS infrastructure needs to be in top shape for the scheme to work.
Once communicating with the Netskope GoSkope portal, it’s possible and normal to have GoSkope examine local log files, from which it extracts information about app communications, sources and most destinations. It’s now an interloper, forward or reverse proxy as the destination app needs.
Steered traffic can be “introspected” for apps Box, Google Drive, One Drive, SharePoint, Dropbox, Salesforce, Egnyte, and Service Now. We saw no delays, but we didn’t hit it with 2,000 concurrent diverse power users, either, and our net connections are fast. Their cloud-based proxies are load balanced, and can be homed to specific GoSkope processing sites based on speed, or by jurisdiction.
A feature called Skope-IT in the online GoSkope portal contains the reporting nervous system of the platform. Inside, we could look at application and connection events, as well as the audit and infrastructure logs. Events or conditions needing administrative action were easy to find, and can be sorted by date, user, user location or activity.
Events, alerts, quarantined items, legal holds, malware finds, and incidents (and their severity) can be easily found through sorting, or the results of a query field action. This may be Netskope’s finest “secret sauce”— rapidly usable and obvious administrative action productivity possibilities.
At the top “full meal deal” resource license, we also had access to Netskope’s ongoing research into specific cloud app ratings. There are a vast number of cloud apps (taken from logs) that have ratings applied by Netskope, as part of its audit capability. This list can also be re-rated based on an organization’s re-estimation of the values used, so as to derive a rating based upon the new assessment.
This permits administrative blocks and restrictions to be imposed on access deliberately based upon the ratings then derived to the resource. It’s the source of much pride at Netskope, and we were surprised to see name brand cloud apps rated in the way they were — some highly secure, others we believed to be highly rated, were not. You can drill into the values and decide to change them. If we had a legal department, we might be arguing with them over ratings, and they might win.
Overall, Netskope is an increasingly sophisticated menu, and if you take all of the courses offered by their waiter, think about the architecture and then program it to suit your needs, it’s an excellent CASB dinner, and the check might be hefty at the end.
Summary
CipherCloud represents extreme depth in encryption mechanisms. Netskope has high programmability, and shares with Bitglass, very good administrative controls. Were we to offer a suggestion as to which one is most flexible with the greatest variety of possible cloud app protections, Netskope barely edges its competitors, but out of the box, Bitglass is likely the fastest route to reasonable protection.
Each product is also dependent on third party platforms, such as SSO, external DLP providers, and organizational firewall/IDS/IPS schemes/threat protection to work in concert with each other. Will traditional firewall and security providers subsume CASB, or will the reverse become true? At this point, we don’t offer a guess. In all likelihood, CASB is a category that because it must rapidly evolve to keep up with cloud apps, will likely digest other categories.
How we tested cloud access security brokers
We used server resources at our NOC at Expedient in Indianapolis, consisting of several VMware and Hyper-V servers on HP, Lenovo, and Dell platforms as hosts for gateway VMs described in the review. In turn, we accessed accounts at Salesforce (including some product-sponsored accounts in the cloud in AWS), as well as Office365 and Box to be used as proof-of-concept examples.
Our circuits included VMs of Windows in the NOC, running through our Extreme Summit Series 10GB switches, to Expedient’s network core. These connections also served as proxies for our VPN, and Windows and Mac clients running in our lab, connected via Comcast broadband circuits to the NOC.
We setup configurations as proof-of-concepts to understand the administrative procedures necessary to install and administer the apps, and store at least one record in the chosen apps. We examined and/or tried as many features in as many configurations as possible, after initial installation.
Tom Henderson runs ExtremeLabs, in Bloomington, Ind. He can be reached at kitchen-sink@extremelabs.com.