NOTE: Rather than read this post, you can come see this use case presented live at our upcoming Worldwide User Conference in Las Vegas. My colleague Andrew Gerber from Wipro will be reviewing this and a few other recent use cases we have worked on together.
For the past 14 years (yes, I am old) I have worked out of a home office. This means that during my workdays, I can freely receive YouTube cat video links from my high-school ex-girlfriends, grab some carrot sticks and hummus from the kitchen, and watch as many of them as I care to using my trusty copy of Internet Explorer 6. The reason I can do this? No pesky corporate web proxy monitoring my outgoing browsing activity, thank you very much.
But for those in the corporate world, there’s all sorts of infrastructure deployed specifically so that you can’t get your fix of YouTube, and various other non-essential sites. Web traffic is generally funneled through a “restrictive corporate Internet proxy.” There’s good reason for this of course – companies like to limit personal use of corporate resources, and want to ensure that employees aren’t accessing content that could be considered offensive and/or potentially harmful. And, modern proxies can do things like cache content, limit bandwidth, and scan for viruses in addition to the standard content filtering. (By the way – the logs from those proxies are chock-full of great information, and if you aren’t feeding them into Splunk, you should. We have code and documentation to help you onboard logs from Websense, Bluecoat, Palo Alto, and many other vendors).
These days, if you want your fix of cat videos at work, you’d probably just fire up your iPhone 6 Plus with LTE connection and prop it up on your desk using one-half of yesterday’s tuna sandwich as a stand. But another method to usurp the corporate proxy, and one that is pretty commonplace, is “off net browsing.” Corporations often provide a “guest wireless network” for use by visitors, contractors, vendors, and so forth. Often, this guest network is less restrictive than the corporate network, simply because of the needs of the computing population that uses it. For example, in a hospital, it is common to offer a guest network for use by patients and families. More services and sites may be available via this unsecured network than on the hospital’s regular “corporate” network. It’s the same thing for many retail locations.
The bottom line is, even if you have one of these guest networks readily available in the same physical location as your corporate employees, they shouldn’t be jumping onto the guest network to get their fill of cat videos, or anything else. It’s potentially quite dangerous to the corporate-owned laptop or desktop being used to do this: i.e. Jimmy drops off the corporate network, associates his laptop with the guest network, browses to “http://www.SeeKittyPerformTheLambada.biz” and is immediately entertained, then infected with a piece of malware. Not knowing his laptop is infected, he then re-associates it with the corporate network, and now you have an infected client sitting on your LAN.
How can we monitor this behavior? Enter Splunk (four paragraphs to get to the heart of the matter? Really? Sorry. 
)
Recently I spent time at a local customer that wanted to monitor this behavior across their environment. Users that leverage the guest network excessively should be reprimanded, especially if they haven’t taken the appropriate security skills assessment. In order to create a dashboard that reports on this behavior, we brought the following data into Splunk:
- DHCP log events from Fortinet firewalls servicing the “Guest” network
- Log events categorizing Guest browsing activity from Fortinet firewalls
- Log events categorizing Corporate browsing activity from Palo Alto devices
- DNS log events from Microsoft DNS servers categorizing DNS lookups across the environment
Splunk allows us to correlate all of these sources together over time. We can, for example, find a MAC address of a corporate resource showing up on our guest network. Using lookups, or using authentication data found in the logs already, we can determine which employee has associated with the guest network. Next, we can connect that MAC address to the IP address given on the guest network, and determine what sites they have visited on the guest network. We can correlate these pieces of information with the same types of data found in our corporate web proxies, to get a feel of the sites that an employee has tried to visit (hence the need to move to the guest network). And finally, we can correlate the employee name, or asset MAC address, with identity and asset databases to determine whether or not the employee has attended security skills training.
Here’s a walkthrough of a dashboard called, appropriately, “Off Net Jumpers.” We start with a dashboard panel of off-net jumping activity. The corporate assets seen moving from corporate IP address space to guest IP addresses are plotted over time.
How do we determine that an asset has moved from “corporate” to “guest?” We look at the firewall logs, which log DHCP requests and happen to have the IP address of one of our corporate networks, as well as the MAC address, showing up on our guest network. Note that in the search, we are eliminating hosts that are known to be mobile, and we are further limiting the hostnames to only ones that meet the pattern for our corporate standard.
Next, a panel detailing these jumpers, all with corporate-assigned IP addresses, hostnames, and MAC addresses.
This is a drilldown panel. Clicking on a row will give us the details of that “jumper” in the panels below (using the new panel tags available in SimpleXML in Splunk 6.1+). The appearing panels look like this:
We can see the jumper at IP address 10.248.30.80 tried to go to a lot of YouTube links, under the category of “streaming media” on our corporate site (and they were blocked). These logs came from Palo Alto devices. On the left, we see the DNS requests that the system has been making (blurred to protect the innocent). And at the top, the name (corporate AD login or owner of asset) of the jumper – in our case this was in the DHCP request, but this just as easily could come from a lookup against the MAC address and a corporate database (CMDB) or from authentication logs.
The searches above do one more thing – they retrieve the Guest IP address of the “jumper” based on MAC address seen in the DHCP requests from the same logs. In this case, it was 192.168.200.62. We can then use this guest IP address to search for which sites have been accessed by this IP address during the same timeframe of the jump. And we can see that YouTube was in fact passed:
And finally, based on the jumping activity found in the first few panels, we now scope to just that one asset, to determine how many times over the past 7 days this device has been seen moving from our corporate network to our guest network. This search could be turned into an alert, or a e-mailable report to a superior, or or into a lookup against a database containing training records, to ensure that this individual has (or has not) attended security training. This allows us to link Splunk capabilities to prove our adherence with one of the 20 Critical Security Controls (#9 – Security Skills Assessment).
If you want to hear more about how this was accomplished, my colleague Andrew Gerber will be detailing this use case, and several others, at our upcoming .conf2014 in Fabulous Las Vegas. What? You haven’t signed up yet? What are you waiting for? If you’re coming…I will see you there.
Please bring me some carrots and hummus from the buffet.