More Effective Threat Visibility Using Identity and Device-Type Context

Following my previous blog post about identity and device aware IT platforms making IT operations easier and more effective, I wanted to delve a little deeper into a specific element of the IT infrastructure: Security Event & Information Management (SIEM) and Threat Defense (TD) systems.

See a brief video on ISE and SIEM/Threat-Defense Integration

SIEMs are a standard part of any enterprise security architecture. In fact, many Cisco customers I talk with actually have more than one SIEM system installed because different vendors focus on different areas of security monitoring, such as policy/regulatory compliance, forensics or active threat detection. And then there are what I call “threat defense” systems, which are laser focused on detecting the most difficult cyber threats… an area of even further specialization.

But all of these systems have something in common. They rely upon data they collect from other systems to comprise their view of security events. And, with few exceptions, that data is based upon the common networking 5-tuple: source/dest IP address, source/dest port, and protocol. What’s missing here? Well, many things, but most notably and information answering the basic questions that arise around most any security threat event:

Who is the event associated with?

Is this person “important” from a security perspective? (e.g. do they have access to valuable information or systems?)

What type of device is the threat associated with? Is it a device that represents a higher risk (e.g. BYOD device)? Is it a device that sheds light on the nature of the threat event (e.g. a “printer” accessing the data center… definitely anomalous behavior bearing closer scrutiny)

Has this device had any security posture failures making it more vulnerable to attack or control?

Some SIEM/TD systems have links to Active Directory or LDAP to provide some identity information, but those are not good sources of real-time association of IP address-to-user and have no knowledge of device types or posture. So where to source this identity and device-type intelligence?

That is what Cisco ISE integration with SIEM/TD platforms accomplishes. ISE has a real-time session repository of every user and every device on the network. Doesn’t matter if the device is wired or wireless, has a user behind it or is just a machine like a printer. ISE will track each of these devices and users in real time and capture a variety of information including what IP address they are at, who it is, device type, MAC address, authorization group, network location, and so on. This real-time session repository can then source SIEM/TD platforms with reliable, accurate identity and device information.

So that is great. We’ve connected some dots—security event in SIEM/TD system with user, device-type, posture status, user authorization level, etc. from ISE. Now, how does that make threat visibility from SIEM/TD platforms more effective? Let us count the ways…

The “who, what, where, how” of a security event: This is the ability to see, from a consolidated view in the SIEM/TD console, not just an IP address of a security event, but who the user is, what access that user has on the network, what device the event is associated with, the posture of that device and even where on the network the device was during the security event. This information is critical to assessing the severity of a potential threat event or to a forensics investigation associated with a breach or compliance issue.

Device-driven security analytics: How do you adapt your SIEM/TD system for the BYOD onslaught? For the most part, customers haven’t been able to. But with device profiling information coming for ISE, the SIEM/TD system can now build analytic policies based on the type of device a potential security threat is associated with. For example, mobile devices may be considered higher risk than IT-owned and managed laptops. As such, using its new device-type awareness, SIEM/TD analytics can be configured to assign higher severity to events associated with mobile devices.

Identity/authorization-driven security analytics: Similar to the above, event severities can be driven based on the type of user and based on contextual information delivered by ISE to the SIEM/TD platform. For example, guest users may have different analytic policies with lower alarming thresholds for certain types of events. Or suspicious events associated with IT admins, who have the keys to the systems’ kingdom, may have an escalated severity assigned. Or user groups with access to critical information may be scrutinized more closely.

Scrutinize devices with security posture failures: If an endpoint has a posture failure and is generating suspicious security events, that is generally more suspect. ISE posture data utilized by SIEM/TD platforms connect these dots without any human intervention.

User, user group and device based reporting: Having a list of IP addresses for a policy or regulatory compliance audit is OK. Having all of that automatically associated with users, user role, and type of device makes reporting easier, more useful, and more convincing.

So all of this nets out to a basic result: customers can serve more use cases with the SIEM/TD systems they have in place, with less human intervention, and evaluate what security events require immediate attention more accurately and quickly. That is “more effective threat visibility” in a nutshell.