How to Make the Most of Symantec CloudSOC CASB (Part 3)

In our last blog we discussed a number of details about CASB Audit implementations that are often overlooked.  Today we’ll look into other considerations and possible risks and help clarify what implementing a healthy gold standard Audit deployment looks like.

Understand and reduce the risks

The primary objective of any Shadow IT audit program is to help organizations identify and stop data exfiltration risks related to unknown/untrusted or uncontrolled (unsanctioned) cloud Applications. This is achieved through the CloudSOC Audit component in Symantec CASB.

CloudSOC Audit is used to uncover and help control Shadow IT adoption and use. It provides visibility for all the apps used in your organization and the Business Readiness Ratings (BRR) and service comparison for almost 38k cloud applications. It allows administrators to review newly adopted applications and even create a custom application for virtually any URL that is not part of the CloudSOC Audit database and assign BRR ratings.  This is important if your organization uses industry insights and wants to leverage this knowledge within your audit program.  CloudSOC Audit contains features that allow customizations by application or category and provides the ability to request additions or suggest updates to the Audit interface to help maintain your data. 

A truly successful Shadow IT Program requires a strategic and disciplined approach of blocking or managing risk of unnecessary or risky Shadow IT Applications. It is not enough to simply mark an application blocked or to do a one-time import of known URLs for the application into the proxy or firewall for blocking.  The action needs to be monitored on an ongoing basis to make certain the app stays blocked.  New URLs will spring up. We recommend using more than just the “Blocked@NWDevice” tag that's built into CloudSOC. We also recommend using a verified blocked tag with a date and a tracking ticket and other related structure to facilitate periodic controls reviews for these applications.  

Overcoming Shadow IT Challenges

Mature organizations know that official cloud application adoption is a GRC (Governance Risk and Compliance) related decision. The problem for fast-moving businesses is it rarely ends up being this simple.  The context of data involved, application risk and business partner involved weigh heavily on these decisions. Another way to say this is that the primary challenge with Shadow IT is rarely ever as simple as making a clear-cut “all or nothing” (allow or block) decision that impacts user access across the board.  All but the riskiest applications will require judgment calls that need to be made by GRC and implemented by administrators. The primary source of friction with these judgment calls is tools.  Traditional Endpoint and SWG (web filtering) approaches often rely upon simple block or allow (by URL) rules.  This approach does not work well in today’s cloud application centric world because of multi-tenanted cloud applications that use the same URLs for all of their tenants. Devoid of purpose built, application aware, cloud application proxies, administrators are forced to implement access rules that greatly exceed GRC authorized use.

There is a middle ground - trust but verify.  Always perform further inspection of this traffic because it is allowed and still extremely risky. The decision to permit a cloud application needs to rely upon a level of inspection that is aware of context.  Who the user is, what application is involved, what data is involved, how the data is being shared, and so-on. Symantec’s specialized approach to cloud security can even help squash threats stored in your cloud applications (referred to as Living-off-the-land or LotL) All of these and more are decision attributes that must be taken into account.  Items like the cloud service user and data or threat or application activity are key.  Inline capabilities are necessary to manage this and will be covered extensively in a later blog article. 

Implement a Strong Audit Program

A successful CASB Audit implementation positions both GRC teams and Audit administrators so they can monitor the day to day use of applications. It’s important to review the categories of applications users access with a burning question in mind — why?  For instance, why are users utilizing a VPN from the company network?  Why is a remote login tool that’s not sanctioned by the company being used by end users?  Or why was there a 5TB upload to an AWS bucket (or Azure blob) from a critical server when that is not officially used by the company?  Every environment is different and portrays its own unique characteristics and challenges.  Understanding the risk from both a data import/exfiltration and threat perspective are critical business functions that must be completed on a regular cadence and continuously reviewed as your program matures.  All of the subsequent key processes start with CASB Audit and will evolve as the audit program matures.

The moment a new cloud application is discovered it needs to move into the next phase - the decision to officially sanction (or replace) the application.    The transitional state where the business is actively using an application but has not officially sanctioned a cloud application and does not have robust controls to reduce risk is a disruptive state for both the business and the audit program.  The new application needs to immediately feed requirements into later steps that formalize adoption status, policy and risk management.   With Symantec CloudSOC our Securlets and Gatelets are critical for this.  They will be covered in upcoming articles in this series.

Final Thoughts 

Most CASB implementations cannot focus exclusively upon the audit program unless it is present solely to ensure zero cloud adoption.  Overall log collection and CASB application settings health checks can help your GRC and Administrators govern the tools that govern your cloud adoption.  Your CASB solution’s integrations and architecture become increasingly critical in next steps as your business needs shift from visibility to granular controls. Consider all areas when initially choosing a CASB Audit solution to avoid needing to start over in another tool.  The tool selected must be able to start simple and advance as your organization’s needs evolve.  Your CASB also needs to elastically scale and offer market leading data loss prevention and threat protection to successfully control your cloud adoption risk.

The next step most organizations usually take for more control is to leverage their sanctioned cloud application’s APIs.  CloudSOC “Securlets” (Sanctioned Cloud Application Tenant API connections) are the topic we will dive into in our next blog article in the series.