everythingpossible - Fotolia

CASB market dynamics, from a customer perspective

The CASB market is changing. Learn how the fluctuating threat landscape has led to a use case evolution and operational changes for the CASB in the enterprise.

Everyone knows that cybersecurity is a rapidly changing field, but some aspects change more quickly than others. Shifts in the markets can reflect disruption, changes in product usage, or the evolution of noteworthy features. From a customer's point of view, understanding these changes informs purchase decisions, helps realize optimal value from already-deployed products and assists for using features.

It is particularly useful to pay attention to the market for cloud access security brokers (CASB). Unlike some security product markets, the CASB market has been highly dynamic over the past few years -- and for good reason. In their "Market Guide for Cloud Access Security Brokers," Gartner predicted that by 2020 85% of large enterprises will deploy and use CASB -- up from 5% adoption in 2016.

The CASB use case evolution

The use case for CASB has evolved, although the intent of CASB has always been to provide a mechanism for enforcement of an enterprise's security goals in the cloud.  Use cases for CASB have typically supported situations where security measures are not implemented natively in the cloud service. This includes discovery or identification of unexpected, "shadow" cloud usage that has expanded with the proliferation of cloud use.

As compelling services such as SaaS emerge, the users' desire to employ them increases and brings about shadow adoption. Discovery is now a core feature offered by many CASB products to help alert customers of shadow operations so they can take action to either control, track or layer security controls onto it.

A CASB also allows the addition of security controls to cloud services in situations where the cloud provider doesn't, or in situations where explicit control is advantageous for the enterprise. These security controls include encryption, authorization and authentication, identity federation, DLP and auditing and logging capabilities.

Some CASBs have adapted their features to allow API integration, allowing customers to employ existing security tools in addition to, or instead of, those provided natively by the product. This is core to the CASB value proposition. Likewise, identity federation and authentication features have improved as cloud services have evolved, in some cases allowing fine-grained access control decisions within a cloud service itself.

CASB operational changes

In addition to the where and why the CASB is used, there have also been changes in how it works. Historically, CASB technologies have operated in one of two ways: either through API integration or proxying. API integration is straightforward: The CASB leverages the API feature-set provided by the cloud provider to build and deploy enhanced security features. For example, if customers want encryption or enhanced logging, the CASB leverages APIs provided by the cloud service provider to effect the desired functionality. This works best when the cloud services provider offers a flexible API to work with in the place.

By contrast, proxying relies on a device between the endpoint and the remote cloud service that is configured in such a way to either channel all web traffic through it (forward proxying) or to intercept and operate on traffic to a particular service (reverse proxying).

One recent evolution is the expansion of API integration approaches in addition to or, in some cases, instead of proxying. There are a few reasons for this, but one of the primary ones is research that highlighted potential issues with HTTPS interception.

For example, US-CERT issued guidance about security issues arising from man-in-the-middle techniques used for HTTPS inspection. The alert is worth a read for current or potential future CASB customers, and notes that unless the entity in the middle implements everything exactly right, the session can be drastically weakened. Likewise, if the solution does not appropriately implement all checks such as certificate expiry and revocation checking, the chance of certain types of attack increases and the overall security of the session is reduced.

Because of this, the ability to support API rather than proxy-based integration has become a decision factor for some customers when making a purchase. This leads to competitive pressure among CASB solution providers to support alternative strategies. In the early days of the CASB market, API approaches were less common than proxying. But today, more are supporting mixed-mode operation or API-based alternatives. Technical challenges to this have been reduced as cloud providers add API enhancements and as large cloud services onboard more customers using CASB solutions.

The point is that the CASB market has been an exceedingly dynamic one over the past few years. The independent players in what was a niche space a few years ago are now joined by names like IBM, Cisco, Microsoft, Symantec and Palo Alto after several mergers and acquisitions. The changes in the CASB marketplace is likely to continue given the features we've seen emerge, as well as the evolutions in technical operation and growth. This is always good news for CASB customers.

Dig Deeper on Cloud Security Management and Cloud Operations Security

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

Where is your opinion in the debate for making the business case for CASB?
Cancel

-ADS BY GOOGLE

SearchSecurity

SearchCloudComputing

SearchAWS

SearchServerVirtualization

SearchVMware

ComputerWeekly.com

Close