Breaking Bad Behavior: Why Non-SIEM Behavioral Analysis May Not Be All It’s Cracked Up to Be
Behavioral Analysis is becoming a huge buzzword in the IT and Information Security industries. With the idea that you can automatically determine whether or not what’s going on within your network is legitimate or not is a huge benefit to any organization. But, challenges exist. The sheer volume of data available makes finding attention-worthy events difficult at best, and when they are found, the risk of a system promoting false positives can cripple the efficiency of an organization’s efforts to leverage this automation for a tangible benefit. Purpose-built Security Information and Event Management (SIEM) tools have the potential to deliver real value, but what about all the other tools which claim they have deep Behavioral Analysis functionality? This white paper will discuss some of the challenges present with making Behavioral Analysis an effective part of your organization, along with better strategies for efficiently responding to events generated by other tools in order to minimize false positives, increase the effectiveness of your security program, and enable your staff to focus in on the issues that matter most.
The State of Behavioral Analysis
In the Cyber Security world, information is king. Whether it’s the databases we try to protect from exposure, or the internally-created log and event information every single system on our networks generates, it all comes back to data. And as technology grows in scope, the amount of data these systems generate grows at exponential rates. Where once a system administrator could simply review the local log files of a handful of servers on a daily basis to ensure that nothing troublesome is happening, now there are thousands upon thousands of systems generating gigabytes of data, which no single human could review without the assistance of some sort of tool. This, of course, is where the true power of Security Information and Event Management (SIEM) tools has come into its own to help aggregate the sheer volume of data sources while helping to filter and prioritize the events that need to be reviewed.
But SIEM vendors aren’t the only ones who are trying to get their arms around all of this data. Many other companies are attempting to use whatever event data their specific, specialized software gathers to deliver additional value to their customers. This value add-on usually comes in the form of Behavioral Analysis, which is often touted as a way to automatically make decisions based on the data provided in order to detect anomalous behavior within the system. The idea here is to establish some sort of baseline that is deemed to be “normal” behavior by a user or a system, and then use that to flag anything that does not conform to the baseline pattern. A common example given is the idea of a rogue IT Admin who normally works from 9am to 5pm who then suddenly starts logging in at 3am. An admin, who likely has elevated access to critical systems, is now logging in at a time that is unusual and suspicious, and thus this activity gets flagged for review and/or action. But is this truly a proper analysis of behavior?
The promise of Behavioral Analysis is to provide operational efficiency for the personnel trying to sort through these mountains of data, while delivering critical and priority events that should be reviewed to the responsible parties quickly and accurately. Trying to sift through millions of events to determine what needs attention and what does not is simply not scalable for humans to do, especially given the constraint of resources available to IT teams everywhere. If the Behavioral Analysis tool does its job well, then you can utilize those precious few human resources available in an optimal way to review those critical events which require the subjective analysis that only a human can provide. However, if it can’t do that well, you actually create more work for your teams, as they must deal with false positives, unmanageable volumes of events and improper prioritization of these system events. This, of course, defeats the entire purpose of what proper Behavior Analysis tools are meant to do by increasing operational cost and inefficiency, and burdening IT teams with a tool that ultimately, they’ll just stop using. Unfortunately, this is an all too common scenario for many organizations.
Putting Context Around the Problem
If information is the king of the security profession, then context is the ruler of any proper Behavioral Analysis effort. Without context, a single data set could be interpreted in many different ways, most ending up to be incorrect. Take our IT Admin example above. One set of login data suggests that the IT Admin is either logging in at 3am because they’re up to something nefarious, or a hacker has gotten a hold of the Admin’s account and is logging in with those credentials. And while most of us could add a few more possibilities, to do so would require that we incorporate other data sets that most of us know offhand. For example, maybe the Admin is working on an emergency help desk ticket and is working at 3 am due to this crisis problem. A very reasonable conclusion, but it requires the knowledge that a help desk system exists, that a process for problem resolution exists, and that this IT Admin may be one of the people assigned to handle incidents of this nature. Bringing all that to the table means we have several other sources of data in which to create context around the original event that the single set of login data cannot provide on its own.
One of the troubles, then, with Behavior Analysis is that even if you provide a huge amount of context, it’s still difficult to systematically create an accurate picture of what’s actually going on for a given event. Often, it requires a human to get involved to review the data sets and then make a determination about whether the event is a real event or a false positive and whether or not the behavior detected is or is not malicious. Without large amounts of contextual data, automated analysis tools are going to generate huge amounts of false positives that will require more time and attention from staff, thus reducing the effectiveness of the tool and burdening staff with more time being spent on dealing with these errors. And even if you feed tons of data sets into an aggregation tool, there could still be missing pieces of non-system generated information that the behavioral analysis tool can’t take into account. Is our IT Admin on vacation, or are they working from the other side of the planet in a completely different time zone? It may not occur to feed in the data from the employee time tracking system in order to add that context, even if it may be common knowledge to the people in the office where the Admin is on a given day. And even if that data was made available, it still may not accurately tell you if the 3am login is supposed to be happening, or if it’s truly a malicious event being staged by a rogue IT Admin. Effective and efficient Behavioral Analysis is hard even when you have a lot of different data sources to create broader context for an event. It’s nearly impossible for a software tool that isn’t purpose-built for this type analysis that is only looking at a single data source to make its determination.
Being Effective with Event Management and Response
So why is this so important? At Thycotic, being the most widely-used Privileged Account Management (PAM) tool out there, we often get questions from colleagues and customers about our take on Behavioral Analysis as it pertains to the administrative and elevated credentials our products protect and manage. And it’s a valid question, to be sure! But it’s important to make sure we’re asking the right question in this context. Are we trying to analyze data from a wide variety of sources to try and make difficult, subjective determinations as to what might be going on, or are we looking to take proactive action to stop activity which we already know to be improper or malicious? Most would answer with the latter and it is here where real value can be gained with your PAM tool or any other specialized security tool.
Within Thycotic Secret Server, you can take control of the behaviors you do or don’t want to take place around the use of your privileged accounts with a variety of tools built into the product. These tools are designed to analyze and respond to behavior in the manner which you choose for your environment, effectively eliminating the need to manually review events (which may not have enough context available to determine accurate behavior patterns) as well as automating the process of taking action to protect your administrative credentials and prevent abuse of these keys to the kingdom.
- Event Notification – Within Secret Server, you can define specific rules for a wide variety of improper credential use or other flagged behavior and be notified immediately when these events take place. By defining the specific activities, you are most concerned about taking place within your environment, you reduce the amount of noise generated by potential events and can focus your response teams to handling legitimate issues.
- Automated Discovery Rules – You can automate the process of what Secret Server will do whenever it finds new accounts anywhere in your environment. Regardless of why the account may exist or who created it on your network, you have the ability to take control of these accounts and immediately secure them based on parameters you control and configure. These rules can be as simple as leveraging the Event Notification function to inform the appropriate parties that these accounts have been created, all the way to taking complete control of the account, rotating the password to something lengthy and complex, and applying existing policies to provide immediate access to the correct responsible teams within your IT or Operations teams.
- Role-Based Access Control and Policy Sets – By applying security policies to the credentials stored in your Secret Server instance and leveraging strong Role-Based Access Control (RBAC), you can enforce the type of access you want your employees to have right from the start, without having to build baselines for behavior and compare against what may or may not be anomalous. These kinds of controls lock down the means and methods of access to ensure that the credentials are only used in a way you deem to be approved with no need for constant review or monitoring.
- SIEM Integration – If, after all your controls are in place, you want to add true and proper Behavioral Analysis to your security programs, then you can leverage Secret Server’s SIEM Integration to deliver the context that Secret Server maintains in its internal audit logs to your SIEM tool. This allows you to correlate the data around privileged account access and use to all of the other data streams in your environment, providing the proper context that any reasonable attempt to baseline behavior requires. Standard CEF and syslog support is available, and powerful APIs can be leverage to leverage the data feed to custom analysis tools.
At the end of the day, a mature security program will leverage a wide array of security tools, including Behavioral Analysis tools and processes. But be wary of any system or service that offers Behavioral Analysis without providing the wide breadth and necessary depth of context that needs to be present in order to create a reliable and useful offering. Log analysis from a single data source is simply not sufficient to create true baseline patterns of behavior in which to further make determinations of what is valid or not in your environment. But, by leveraging a more proactive approach and taking control of your privileged credentials up front and in accordance with the mission of your organization, you can more effectively improve your overall security posture with less effort and overhead while reducing the number of false positives that your staff has to deal with, and bringing real value to your organization. And, should you leverage this approach to augment a true SIEM-based Behavioral analysis effort, you will strengthen the efficiency of that implementation by preventing anomalous behavior up front, without having to filter and sort through this data after the fact.