Using Cisco Umbrella with Cisco WSA and Splunk for private reporting

Sometimes having a effective and innovative solution goes in a confrontation with the local country requirements. Especially when we want to deploy as cloud based security service.

Using a cloud security service will one the one hand address quite nicely the need for better security and easy deployment , on the other hand a CxO must also follow local privacy laws and deal with the agreements between the company and workers unions. This can very often lead to delays, discussions and even preventing a solution from being installed. This short post should give you an idea how to use a cloud based Security Service and at the same time, provide granular local logging without compromising privacy.

In a customer environment we faced the following situation:

 

• The customer was using a Cisco WSA as a Web Security Gateway
• The customer was looking for additional security layers against threats from the web
• They were concerned about sending Usernames and IP addresses to a cloud service

 

To provide an additional security layer, we decided to take a look at the Umbrella Service from Cisco (umbrella.cisco.com). This service provides security at the DNS Layer, being able to detect requests to malicious domains and block them right away before anything else needs to be filtered.

In case a malicious request is detected, Cisco Umbrella delivers a block page back to inform the client that his request could not be fulfilled.

So, for our deployment, the already installed Web Proxy is a nice point to start an evaluation. Just set the proxy to resolve the external URLs via the Cisco Umbrella Servers. This is especially nice for a first test because it does not require any other changes in the client or network infrastructure.

All the logs are sent towards a Splunk server, running the Splunk provided app for the WSA.

https://splunkbase.splunk.com/app/1747/

 

On the Cisco Umbrella portal you need to define your networks from where usually the DNS requests are sent.
In our case, it is not a full network but actually only the proxy IP address:

Fortunately, the block pages that are sent back from Cisco Umbrella are well known IP addresses:

To be referenced on this link here:

https://support.opendns.com/hc/en-us/articles/227986927

 

On the WSA side of things we need to enhance our log files to also include the destination IP.

The variable to get the destination is “%k”

This is enabling us to see the actually requested IP address.
In case Cisco Umbrella declares a Website as “malware” we will see the respective block page IP mentioned above.

 

Working with IP addresses only is not so nice, so we want to create a “nicer” report on Splunk.

First, within the Splunk app, extract our destination IP:

This gives us a new variable “dst_ip”.

 

Define a new lookup with a lookup table containing the different categories of malware and the block pages:

So we are getting now another variable called “odnstype” that we can use in our reports, which is easy to do in the SPLUNK system

Some examples how to use it from a simple diagram showing our malware requests:

Or showing a detailed drill down who requested malware sites and is potentially infected, comparing it with the Web Category of the URL and the Web Reputation Score:

So, in summary, what did we achieve?

• we are using the Cisco Umbrella Service as an additional Security layer with minimum impact on the deployment because we only activated it on the Web Security Appliance (WSA).
• The Cisco Umbrella Cloud sees only the IP address of the proxy but no internal IP addresses and no usernames
• The local Splunk server has all the information that is needed to track down infected client without compromising privacy on the outside of the company network