Loader Image

Increasingly, organizations are currently exploring the use of Cloud Access Security Brokers (CASBs) as an integral component of their Cloud Security & Risk Management Strategy.  This is because the employees of these organizations are using more and more Cloud Apps and confidential data is increasingly being sent to and stored in the Cloud.  Thus, CASBs as a Governance Control have become essential for governing the usage of Organization traffic to the Cloud.

Initially, CASBs were only used to provide visibility into unsanctioned Cloud traffic (Shadow IT) of an organization.  This is usually referred to as CASB 1.0.  As CASBs evolved to provide mechanism for advanced features such as Data Security & Access Control, Compliance, Threat Protection & Enterprise Integration, CASB 2.0 came into being.  However, the usage of CASB 2.0 functionality is still limited to just a few Cloud Apps while, in reality, an organization might be using hundreds or even thousands of Cloud Apps.

This presages a coming wave of CASB 3.0 which is focused on enabling a holistic CASB Governance Strategy and not just the use of a CASB tool to manage a few Cloud Apps.  Such a Strategy-driven CASB Initiative requires organizations to have a structured process that comprises the following four phases

  • Cloud Traffic Audit & Analysis
  • CASB Vendor Selection
  • Cloud Apps Onboarding
  • Continuous CASB Governance

Let us go through each phase in detail.

Cloud Traffic Audit & Analysis

Most organizations start the vendor selection process even before they have the awareness of the Cloud Apps that need to be protected by a CASB and the use cases for these Cloud Apps.  The absolute first requirement for any CASB project is to have a Cloud Traffic Audit which provides Visibility into the Cloud traffic of your organization and then, carry out a thorough analysis of your organization’s Cloud Apps.   Such a Cloud Traffic Audit might produce an inventory of hundreds or thousands of Cloud Apps.  Thus, the results of the Cloud Traffic Audit need to be analyzed through a defined process that determines and limits the Cloud Apps that must be governed through the CASB.

CASB Vendor Selection

The second phase of the CASB project entails the finalization of Use Cases and the requirements for selecting a CASB tool.  This would be followed by the organization’s procurement process to finalize the CASB vendor.  This procurement process would include steps such as RFIs, RFPs, Proof of Concepts and Pilot projects.  However, it must be emphasized that the selection of the CASB should not be vendor driven but be based on the CASB Use Cases that have been finalized through the first phase of the CASB Initiative.

Cloud Apps Onboarding

After a CASB vendor is selected, the third phase of the CASB project will begin.  This is a critical phase of the whole project in which a limited number of critical Cloud Apps will be onboarded onto the CASB tool.  This onboarding will include the customization of the risk profile for each Cloud Apps, development of the policies that govern that specific Cloud App and the education of the users of those Cloud Apps.  This onboarding might also include blocking of various High-risk Apps and the transfer of data and usage to other Cloud Apps in a similar category.  Finally, it would include the monitoring and management of these Cloud Apps on an ongoing basis.

Continuous CASB Governance

The final phase of the CASB project would be Continuous CASB Governance.  This phase must describe a procedure for the selection, onboarding and management of new Cloud Apps in the organization.  Organizations should envisage a scenario that entails the monitoring, management and governance of thousands of Clouds Apps through the CASB tool.  Only through developing such a holistic approach can organizations truly benefit from CASBs and ensure that their data is protected from the emerging threats brought about by the paradigm shift in business & technology models that have become prevalent due to the use of the Cloud.