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

Having covered setting goals in our first blog, here we will discuss critical considerations and common mistakes that impact the overall outcome of CASB Audit.  CASB Audit is critical to an organization’s ability to discover Shadow IT, assess risk as well as its overall health. 

The most common mistake with CASB Audit deployments is incomplete data. Information systems are garbage in and garbage out; making sure that the plumbing is right is extremely important.   Extraneous or incomplete information often proves over time to become one of the largest obstacles towards reaching the expected outcome.  Data that lacks certain important context is often unhelpful.  Data that’s garbage will tend to conceal risk and it can cause costly rework in your Audit deployment later.

Visibility and Control - Logs

It is extremely important to ensure ALL relevant traffic logs are being fed into CASB Audit from all the available log sources.

Symantec CloudSOC supports multiple ways to deliver traffic logs to CloudSOC including several cloud-to-cloud, direct on-prem device to cloud and on-prem device to Symantec CloudSOC appliance to cloud options.  Symantec CloudSOC offers their SpanVA virtual appliance for free with CloudSOC for the on-prem device to on-prem appliance scenarios.

With the on-prem virtual appliance architecture, SpanVA collects and filters firewall and proxy logs from network devices and proxies then sends them to CloudSOC CASB for use with the Audit application to evaluate risk, i.e., Shadow IT. 

You should include every log that contains web traffic that is representative of every asset and business user, firewall logs, proxy logs, etc.  These traffic logs should, at minimum, consist of user, source IP, destination IP, destination URL, upload bytes, download bytes, referred URL, as-well-as allow or block status.

Don’t forget to verify that your logs contain traffic from your containers and server complexes. And make sure that key information is not being exported out of systems and applications into unauthorized cloud apps. How will anyone know it’s happening until it is too late if your organization does not have visibility and control?

Blocked status is equally important because reviewing blocked traffic can give key insights. For example, attempted access could indicate bad behaviors, such as a user digitally giving their 3 weeks’ notice before they officially give their 2 weeks’ notice. 

Approaching Privacy - Tokenization or Anonymization

Organizations that have specific privacy requirements should carefully consider whether to use “Tokenization” to replace factual usernames and IP addresses.   

SpanVA also provides support for Audit “Tokenization” - a feature that is documented in detail here: 

If CASB features such as API based policy enforcement (Securlets) or inline enforcements (gatelets) are ever going to be used, the CASB will have visibility to factual user information and therefore, tokenization is not a good fit.    

Additionally, with a tokenized Shadow IT Audit deployment, if the appliance that tokenized the data becomes unavailable the data can no longer be deobfuscated!   This is not the case with “Anonymization”.

Instead, your organization should consider a different feature - “Anonymization”. Anonymization allows an organization to use Role Based Access Control(RBAC) to decide if a CASB Data Protection Officer (DPO) user or other administrators should be able to see the factual user/IP information or if they should see a masked representation such as “anon-1111”.  This allows the organization to keep user identification information available when needed using RBAC. This greatly simplifies accessing CASB Audit as-well-as many other CASB administration related tasks and reduces overall deployment risks.    

One other important factor is if guest network traffic should be included or excluded from the log source.  SpanVA can apply both inclusion and exclusion filters to logs as they are processed and allows administrators to send the same logs to different data sources for different reporting purposes.

For instance:  

• One datasource including ONLY the guest network logs for visibility and risk purposes.
• One datasource excluding the guest network logs.

This prevents confusion or debate about where the traffic for a given app originated.  Also, the appropriate audit data source or sources can be selected based upon the reporting use case.

There are two main ways to get data into CASB Audit

1 - Configuration of IP locations and Audit Datasource(s) directly in CloudSOC.  This allows direct upload over SCP/SFTP to CloudSOC from pre-defined IP source address locations to the Audit datasource

2 - Configuration of a SpanVA Audit appliance and configuration of SpanVA Audit Datasource(s) in CloudSOC.  This allows upload over SCP/SFTP to your SpanVA from any locations your network firewall rules allow.  SpanVA can also receive other common formats such as syslog or FTP and even some firewall vendor proprietary formats.

IMPORTANT!  The first decision point for using either direct upload or a SpanVA datasource is if IP sources address logs are sent from is static and predictable or if they tend to be more-so dynamic.  

• CloudSOC’s SFTP and SCP services only allow uploads from locations registered in the CloudSOC portal – not just any IP.   
• SpanVA can permit log uploads from your dynamic addresses if your organization’s firewall policies permits the necessary access to the SpanVA.

Clearly there are many things to consider. But this is because it is critical to ensure we have a complete picture into the data that exists within your cloud environment. CASB Audit and SpanVA are essential to accomplishing this.  But there are still risks involved.  We'll cover those in our next blog.