Analyzing User Behavior is the Beginning. How It's Applied is What Really Matters.

Posted by Eran Cohen on Mar 3, 2017 2:59:40 PM
Find me on:

Think about this statement: “Half of the people you know are below average.” In simple terms, it means that statistically most of the people you know are considered to have average intelligence, or just below or above the line. Does this mean they are dangerous? Does it mean you should reconsider your friendship? Let’s not jump to conclusions just yet.how-to-see-better.png

In IT security, we use a person’s behavior to help us to identify what is normal or abnormal behavior and as a way to detect and prevent threats. As we may find one person’s behavior or appearance to be anomalous, or different, that doesn't make them dangerous by any means.

The context of the act is more important and writing an automated playbook to mitigate this isn’t going to work out of the box because it is still static and scripted response. It is equivalent to when you’re talking to a customer service representative who says “I’m glad I could help” when they didn’t solve your issue at all. It’s just written in their playbook to say or write...

Context and understanding isn’t in the playbook, which mostly is used to answer the “knowns” that it was built for. Understanding the context of the data within data is more important than adding even more data because for most cases we already hold enough information that allows us to determine if the anomalous behavior is really bad or not.

Reconciling this into a meaningful insight is what makes intelligence--and much different than a machine that connects 1+1 and tells you its 2. From an IT Security perspective, the ability to flag anomalous behavior in the true context that makes it suspicious is critical for getting around the clutter of false positives. What we need to be even more concerned about are the false negatives where something is classified as good when it’s actually bad.

Yes, it is confusing. And although we may prefer to ignore or repress, we know that there are adversaries in our network.

I believe there is no question these days whether to use User and Entity Behavior Analytics (UEBA) or not. It is obvious that it's an essential part of the security toolbox, however it is wrong to think that UEBA stands on its own. It’s just the beginning.  

Like other realization steps, we are seeing that UEBA technology on its own is peaking in the industry and both customers and vendors are realizing that the application of this technology is what matters. For example a behavioral firewall is an application which uses UEBA technology to enable real time security and enforcement. Many vendors may know how to detect anomalous behavior but as a consumer of this technology you not only want to be able to make it actionable, you want to verify if an anomaly is actually bad.

To be practical, here are 6 capabilities that enterprise should be looking for to properly detect and automatically respond to suspicious behavior:

  1. Logical and cognitive analysis that examines context.

    A good solution needs to understand context of one activity within the context of another and another and another. For example: user behavior can be legitimate but when it is done in volume over time even when it looks like low risk, this may lead to another inspection.
  1. Verify the chosen algorithm isn't static or statistic only.  

    You want it to adapt itself to the environment it lives in. As it is often said "no two networks are born the same.”  For example the system will need to conduct a peer list that is dynamically associated with the examined entity because abnormality is relative. What may be considered abnormal in one culture (or industry vertical) may be normal in another. In this example the way peer groups are defined is extremely important. You want to confirm the list relies only on dynamic elements such as network proximity and network usage with metadata from the Active Directory and solely on metadata and memberships.   
  1. The system must examine multiple attributes at once.

    Essentially this is the context of the activity. It is not done in a vacuum and you want to ensure it is examined appropriately. For example the role of the involved entities may influence the results of their activity.  
  1. Engage with the end users.  

    This is important for two primary reasons. The first reason which is not talked about enough is visibility of your controls. Hackers and rogue insiders will prefer to abuse unwatched areas. The second reason is that it brings concrete value because engaging with end users is like crowd sourcing intelligence that feeds back into the system which makes it more precise.
  1. Unknowns are the ones you are looking for.

    Detecting the “Snowden” is easy now that it’s clear what he did but detecting a “Snowden” requires the sensitivity and intelligence required to detect the unknown. Hackers and malicious insiders will take advantage of system weaknesses to get their goals. Know the network flaws by constantly assessing the strength and understanding the security posture of your organization across multiple dimensions. Combine diverse detection methodologies so they can discover the unknowns in case they happen.
  1. Flexible adaptive response.

    You need a solution that adjusts and responds to anomalies according to the context of the activity and isn’t a static scripted response. Be sure the measure used is appropriate to the activity and the surrounding context. For example, you may want to take a real time active response to validate and stop a threat when the severity is high and an offline notification when its low. Be sure the solution allows you to take actions in real time so all your options are on the table.   
To learn more about how customers are using the Preempt Behavioral Firewall to apply UEBA for real-time response and prevention of insider threats, download our paper on Top Use Cases for the Preempt Behavioral Firewall.      

Topics: ueba, Behavioral Firewall, User and Entity Behavior Analytics, CISO, Use Case