Netskope leads the CASB market with a versatile deployment architecture that includes several out-of-band and inline proxy deployment modes. From day one, customer use cases have been the blueprint for guiding what deployment options to develop and bring to market. For customers that are focused on sanctioned, IT-led cloud services like Office 365 and do not have a requirement for real-time control, our out-of-band API deployment method is chosen. Netskope’s API Introspection is being used by some of the largest Office 365, Google, Box, and Slack deployments in the world.
For customers that want real-time control of users on unmanaged devices accessing a sanctioned, IT-led app suite like Office 365 then deployment options are focused on a reverse proxy architecture. Netskope also has hundreds of customers using a reverse proxy to safely enable access to sanctioned cloud services from unmanaged devices. If the use case is centered around real-time visibility and control of both sanctioned and unsanctioned cloud services from managed devices, we developed a number of forward proxy options. Hundreds of the largest enterprises in the world that have deployed Netskope inline to secure millions of users accessing thousands of cloud services in real time and Netskope processes an order of magnitude more cloud transactions via this method than any other cloud access security broker. Here is a recap of the deployment modes Netskope currently supports and the use case coverage of each.
We continue to innovate when it comes to deployment architectures with the recent addition of traffic steering via GRE. The next development is taking some of the inline characteristics of real-time control and applying that to an out-of-band deployment method. How can you possibly achieve real-time control if you are not inline? This is where leading cloud service providers like Microsoft and Box see the value of real-time control and have APIs that are designed to achieve this by enabling Netskope to approve or deny a user’s activity based policies set within Netskope. The API essentially “waits for a verdict” before it allows the action to complete, and it all takes place without the need to be in the flow of cloud traffic. The result is decreased risk and alleviate the discomfort security teams have with the “hold-your-breath moment” they currently experience through standard APIs. Here are a couple of example scenarios where this plays out:
Prevent sharing of sensitive data in OneDrive externally
This takes place when the user selects a file containing sensitive data in OneDrive and clicks on the share button and attempts to share the data with someone outside of their company domain. With typical CASB deployments via API, you would have to wait for the share to be created and then remove the share sometime afterward. This presents a window of opportunity for sensitive data loss to unauthorized users. With the new API approach, the user would not be able to create the share in the first place.
Prevent upload of sensitive data to OneDrive
This takes place when a user performs an upload of sensitive data to OneDrive. With typical CASB deployments via API, you have to wait for the upload to complete before you can scan the uploaded content to see if it matches a DLP policy. The time between the upload activity and scan varies depending on the combination of scanning interval and web hooks implementation, but there will always be a window of opportunity for sensitive data loss. Inline CASB deployments can prevent the upload in real-time without noticeable latency.
With the new API approach, this is addressed by waiting for a response back from the CASB before the upload operation is committed. This provides the benefit of eliminating the window for sensitive data loss, but potentially at the expense of user experience given the latency introduced during the wait period.
The promise of real-time control without the requirement to be inline may sound too good to be true and in some ways it is. Like many good things in life, there are a few trade-offs. First, the app needs to be an IT-led, sanctioned app since administrative access is always required for a CASB to use an API from cloud service providers. The app must also support this functionality via API and currently only a limited number of vendors such as Microsoft and Box have anything publicly underway. Last, but certainly not least, there is the potential for user experience impact in scenarios where the time between the user performing the operation and the API waiting for the CASB to respond is too long. We will surely learn more details as this next generation of APIs progress.
Given the limitations, we believe that existing inline deployment methods will continue to persist in large customer environments that demand real-time visibility and control. This includes covering users that are on-premises, mobile, and remote, and accessing cloud services from both managed and unmanaged devices. All with no trade-offs tied to real-time activities, app coverage or user experience. That being said, we are excited about this new deployment mode. The future looks bright for cloud security.
