Avatar

Cisco Identity Services Engine (ISE) is commonly associated with use as a network access policy, BYOD and AAA platform. But to do its job in network policy, ISE collects a great breadth of telemetry about network users and devices. Whether a device is trying to access the network or is already connected, ISE knows specifics about:

  • What the device type is (e.g., iPad Air 2 running iOS 8.1.2)
  • How it is connected to the network (e.g., enterprise Wi-Fi)
  • From where (e.g., access point in “California/SanDiego/Building 2/Floor 3/South”)
  • Security and compliance posture of the device (e.g., Antimalware operating and up to date? PIN lock configured?)
  • Who the user is on the device…or if it even has a user (e.g., printer)
  • What policy and AD/LDAP group the user belongs to (e.g., “IT Admin” authorization group)
  • Related session IP address and MAC address

While ISE primarily uses all this telemetry to establish network policies, it also shares it for use by other IT platforms. By doing so, ISE helps these platforms become more identity and device aware and thus more effective in a variety of ways. And this is where Splunk comes in.

See the related Splunk blog post on working with Cisco ISE data

Splunk specializes in consuming this sort of data. Splunk essentially vacuums up any sort of data you point at it and enables its users to “ask questions” of that data. But data becomes most valuable when put in the proper context. And for most network and security data brought into Splunk, ISE data provides that context by providing identity and device awareness that helps Splunk users answer questions like “Who is that event associated with…and what endpoint were they using?” Answering basic questions like this can change an event from a mystery that requires manual investigation to an actionable, or better yet, ignorable event in short order.

For example, think about a typical event generated from network or security data. Usually you get something like:

Event: Inbound SQL Slammer

Status: No action taken

Target IP Address: 36.37.38.104

Port: TCP 80

Source IP Address: 172.45.176.86

Source Geo-Loc: Canada

An event like this creates more questions than it answers. Fundamentally I need to figure out if this is an event that has caused or will cause damage. To answer that, having basic information like “who” the targeted user is, “how valuable” that user is and what “type of device” was targeted will get me a long way in deciding what, if anything, I need to do about this potential security breach. So what would that look like in an event?

Event: Inbound SQL Slammer

Status: No action taken

Target IP Address: 36.37.38.104

Port: TCP 80

Username: jfishman

Network Policy Group: IT Admins

AD/LDAP Group: IT Super-Users

Endpoint Group: Corporate Laptops

Endpoint Type: Lenovo Y50

Endpoint OS Type: Windows 8.1

Source IP Address: 172.45.176.86

Source Geo-Loc: Canada

The data in italics is what Cisco ISE would bring to this equation. And what does it tell us? That I care about this security event? Why? Because it is associated with a high-value user in the IT group and a device that would be subject to this attack. So instead of a mystery to be researched I now know from looking at data within my Splunk system that I have an event to deal with. But in reality ISE could bring more useful data to bear…posture, network access type, network location…all of which would simplify moving from suspicion of an event to conviction of what it is.

So all of this nets out to a basic result: customers can extend the monitoring and analytics use cases with Splunk with less human intervention and evaluate what security events require immediate attention more accurately and quickly. That is “enhanced visibility” in a nutshell.

Look for another blog on Splunk & ISE integration in the coming weeks, where we discuss how to use Splunk to take network remediation actions on network and security events by leveraging ISE’s reach into the network.