CASB Evolution: The Transition Between Education of the Problem and Education of the Solution

At just over twelve months into my career at Skyhigh Networks, I’m seeing a key transition occurring in the Cloud Access Security Broker (CASB) market: the change from education of the problem to education of the solution. Gartner is now projecting a $500m+ market within the next two years and there is a wealth of vendors, marketing and innovation occurring.

When I started at Skyhigh Networks, I remember multiple conversations with customers, partners and former colleagues where there was disbelief of the fact that most enterprises are using over 1000 cloud services. Fast forward to today and while the education message is still relevant, the conversation appears to be shifting to “what should I do about the 1000+ services my employees are using.” In this subtle change in the market, several approaches and technologies have begun to emerge and in this post, I wanted to offer my perspective on the trends I am now seeing in the CASB space. 

Before evaluating the validity of the different CASB approaches, one must first consider the impact cloud has on our way of thinking about IT, security and risk. To become fully aware to their organization using over 1000 cloud services, a CIO or CISO needs to first become comfortable with the fact that their existing technology investments are almost completely blind to cloud usage. They also need to become comfortable that cloud usage has become an uncontrolled problem on their watch. I believe the ability to respond to this realization of the problem (and evolve) will make or break many CIO and CISO careers over next two to three years. Some will seek to try to control, block and disable employees and their cloud usage - and likely fail, others will seek to enable, learn and leverage cloud to drive change and productivity - and likely thrive.

So if current architecture approaches are blind to cloud, what is the solution? Are all CASB vendors solving the problem in the same way or are there differences? If so, what is working and not working? In analyzing the market, I see four main trends emerging:

• The Legacy Model– use agents on every device and appliances
• The Leverage Model– integrate with existing infrastructure components and investments to make them cloud aware
• The API Model– connect to CSP APIs to deliver near real time capabilities
• The Inline Model– Get in the path of CSP traffic to exert the most control

Let us review each approach in more detail: 

The Legacy Model

Having come from the APT and security world, I understand why a technology that deploys as an endpoint agent or appliance could be seen to be initially attractive to a CIO or CISO - it fits the mold of how other network security solutions are being sold. The promise of monitoring all users, off network or on network makes for an attractive looking marketing slide – problem solved! But behind the attractive marketing lies a fundamental problem, none of these solutions can possibly hope to scale to cover the cloud. Cloud erodes the traditional perimeter and how do you deploy an agent on a contractor’s laptop for example? What about partners interacting with your cloud based partner portal or other cloud services? What about customers? How will the agents interact with existing agents such as DLP and endpoint protection? How will the agent interfere with cloud services that require me to pin to a particular device, such as DocuSign? In my opinion, agents and appliances fundamentally miss the cloud awareness stage I referred to earlier. Fighting cloud with a legacy approach only makes you weaker, much like fighting APT with signatures did a few years ago.

With the legacy model you also have an inherent problem of user privacy, scalability and causing friction with users (not to mention helpdesk tickets). To effectively monitor cloud using this approach the CASB vendor must "see" all the traffic, which exposes huge privacy concerns. To maintain user privacy many CASB vendors, who use this approach, are stuck with deploying an appliance on premise, which only adds to the cost and begins to erode scalability, particularly when you consider consolidating reporting across sites and locations. This type of solution also has be highly available, increasing on premise costs when the goal was to move to the cloud.

The Leverage Model

With most organizations spending significantly on upgrading their IT and security systems over the last five years, many have new technologies inline between the user and the cloud already, such as a Firewall and Proxy but also things like DLP and existing control agents. The leverage model seeks to use these existing investments and fill the gaps to make them cloud aware. We know for example that proxy vendors are not accurately tracking cloud services, which is why Skyhigh checks and maintains daily a registry of over 15,000 cloud services.

The leverage model though needs to work both ways, the CASB has to be able to push back updates to the technologies that are in line with the user to allow the organization to make policy decisions, at Skyhigh we call this “closed loop remediation.” This remediation ability has the power to make the proxy or the firewall more cloud aware, which can add significant value and improve the ROI of both the CASB and the other devices by extending the range of use cases they can support.

I should also discuss user privacy in this model and the good news is that this approach is very friendly to maintaining privacy, since the integration of the existing technology with the CASB vendor affords a point in the process where privacy can be easily protected. Skyhigh, for example, leverages a mechanism where user data is tokenized on premise before reaching the Skyhigh cloud, so nothing is leaving the organization that would cause privacy concerns and Skyhigh doesn’t store the user information in the clear.

The legacy model and the leverage model are typically used to monitor overall cloud usage, the next set of solution architectures are generally focused on the cloud services approved and procured by the organization.

The API Model

The API model seeks to use the existing functionality offered by the CSP, to monitor activities happening within the CSP in near real time. For solutions like Box, this could be things like access, uploading/editing/downloading of a file and collaborating with other users. Typically, the more enterprise focused the CSP, the greater the richness of their API model. The nice part about the API model is it is usually low risk and can yet still offer significant functionality. The down side is that it is reactive to user actions, meaning that even if the API action call is received, such as upload of a file, it is happening after the event has actually occurred. This can be problematic for countries with strict rules on data being in the cloud and also makes things like encryption/decryption of data and access control more challenging.

The Inline Model

The final option, the inline model, seeks to place a CASB solution in the path of traffic going to the cloud service provider and act as a proxy for the user accessing the service. This model facilitates the greatest control over the access and usage of the service, providing the ability to restrict access to only approved devices, encrypting (and decrypting) structured and unstructured data, detecting compromised accounts and providing real-time action reporting. 

Inline solutions are deployed in the cloud or on-premise. The cloud deployed options offer great flexibility, while also still providing satisfaction of data sovereignty requirements. On-premise deployments tend to become challenging to manage for three main reasons 1) all the traffic going to the CSP being covered has to be routed to an on-premise location, which can severely impact performance 2) the organization has to deploy enough redundancy to successfully prevent downtime from failures with the on premise solution, which is costly and 3) the organization has to ensure that their on-premise solution is continuously updated as the CSP changes schema's and adds new functionality. The cloud deployed version seeks to remove these barriers by addressing scalability and upgrades with a managed service approach.

Conclusion

So what conclusions can be drawn from the evolution of the CASB market? Well, one thing is certain, cloud is not going away and employees clearly want to use cloud services. It’s also clear that many vendors are flocking to provide solutions in the CASB market, each with their own powerful marketing team. This provides a challenging problem for CIOs and CISOs to try to balance the many facets of the discussion, so I have three pieces of advice:

1. Cloud breaks traditional network architecture frameworks

Think beyond the same old rinse and repeat models, cloud is different. Think about the change over the last three years with respect to AV and APT, that situation caused a mind shift in how we think about security, cloud is a more disruptive driver and so needs a more disruptive embracing approach.

1. Understand your business and user profile, determine the best cloud strategy and roadmap

If you are a mostly an office bound worker business, then a CASB provides an opportunity to take a more conservative approach to cloud. If you are a business with most of your knowledge workers office bound or monitored, with some off network staff, then you should take extra steps to safeguard your IP, monitor shadow IT to discover cloud opportunities such as storage, collaboration etc. and take a more opportunistic approach to cloud. If you are business with knowledge workers off-network, then I believe these organizations are better pursuing an aggressive cloud strategy. Providing cloud services that are more enterprise ready, more easily controlled and monitored is likely to be more effective than trying to fight the rising tide of cloud usage. 

1. Protect to the level of your data sensitivity, understand shadow IT first, then protect with API and then inline if needed

By making smart decisions about cloud, organizations can very easily increase productivity, decrease risk and increase user happiness with IT. This triple win is facilitated by first understanding what employees are trying to do and why they are not using IT in the first place. Having gained a perspective of unmet demand, consolidate services and initiate pilot schemes with proper controls, drive users to the cloud services you approve and see how they work. 

Overall, the CASB market is fascinating, it’s more than just a another security tool, it certainly has powerful security abilities but the value of a CASB is realized with greater ROI when it is leveraged across the enterprise, allowing a CIO to have discussions with business leaders on the cloud usage within individual departments, allowing Vendor Management to both select better cloud services and also monitor their usage to accurately purchase correct license counts, allowing audit and risk to better manage govern policies and providing an Executive Team or Board with key optics on business performance and technology management.

I would welcome your feedback on this post, the CASB market place is one of the most competitive and fast growing I have ever witnessed!

Mark