Rapid7 Blog

Log Search  

User Behavior Analytics and Privacy: It's All About Respect

When I speak with prospects and customers about incident detection and response (IDR), I'm almost always discussing the technical pros and cons. Companies look to Rapid7 to combine user behavior analytics (UBA) with endpoint detection and log search to spot malicious behavior in their environment.…

When I speak with prospects and customers about incident detection and response (IDR), I'm almost always discussing the technical pros and cons. Companies look to Rapid7 to combine user behavior analytics (UBA) with endpoint detection and log search to spot malicious behavior in their environment. It's an effective approach: an analytics engine that triggers based on known attack methods as well as users straying from their normal behavior results in high fidelity detection. Our conversations center on technical features and objections – how can we detect lateral movement, or what does the endpoint agent do, and how can we manage it? That's the nature of technical sales, I suppose. I'm the sales engineer, and the analysts and engineers that I'm speaking with want to know how our stuff works. The content can be complex at times, but the nature of the conversation is simple. An important conversation that is not so simple, and that I don't have often enough, is a discussion on privacy and IDR. Privacy is a sensitive subject in general, and over the last 15 years (or more), the security community has drawn battle lines between privacy and security.  I'd like to talk about the very real privacy concerns that organizations have when it comes to the data collection and behavioral analysis that is the backbone of any IDR program. Let's start by listing off some of the things that make employers and employees leery about incident detection and response. It requires collecting virtually everything about an environment. That means which systems users access and how often, which links they visit, interconnections between different users and systems, where in the world users log in from – and so forth. For certain solutions, this can extend to recording screen actions and messages between employees. Behavioral analysis means that something is always “watching,” regardless of the activity. A person needs to be able to access this data, and sift through it relatively unrestricted. I've framed these bullets in an intentionally negative light to emphasize the concerns. In each case, the entity that either creates or owns the data does not have total control or doesn't know what's happening to the data. These are many of the same concerns privacy advocates have when large-scale government data collection and analysis comes up. Disputes regarding the utility of collection and analysis are rare. The focus is on what else could happen with the data, and the host of potential abuses and misuses available. I do not dispute these concerns – but I contend that they are much more easily managed in a private organization. Let's recast the bullets above into questions an organization needs to answer. Which parts of the organization will have access to this system? Consider first the collection of data from across an enterprise. For an effective IDR program, we want to pull authentication logs (centrally and from endpoints – don't forget those local users!), DNS logs, DHCP logs, firewall logs, VPN, proxy, and on and on. We use this information to profile “normal” for different users and assets, and then call out the aberrations. If I log into my workstation at 8:05 AM each morning and immediately jump over to ESPN to check on my fantasy baseball team (all strictly hypothetical, of course), we'll be able to see that in the data we're collecting. It's easy to see how this makes employees uneasy. Security can see everything we're doing, and that's none of their business! I agree with this sentiment. However, taking a magnifying glass to typical user behavior, such as websites visited or messages sent isn't the most useful data for the security team. It might be interesting to a human resources department, but this is where checks and balances need to start. An information security team looking to bring in real IDR capabilities needs to take a long and hard look at its internal policies and decide what to do with information on user behavior. If I were running a program, I would make a big point of keeping this data restricted to security and out of the hands of HR. It's not personal, HR – there's just no benefit to allowing witch hunts to happen. It'll distract from the real job of security and alienate employees. One of the best alerting mechanisms in every organization isn't technology, it's the employees. If they think that every time they report something it's going to put a magnifying glass on every inane action they take on their computer, they're likely to stop speaking up when weird stuff happens. Security gets worse when we start using data collected for IDR purposes for non-IDR use cases. Who specifically will have access, to what information, and how will that be controlled? What about people needing unfettered access to all of this data? For starters, it's absolutely true. When Bad Things™ are detected, at some point a human is going to have to get into the data, confirm it, and then start to look at more data to begin the response. Consider the privacy implications, though; what is to stop a person from arbitrarily looking at whatever they want, whenever they want, from this system? The truth is organizations deal with this sort of thing every day anyway. Controlling access to data is a core function of many security teams already, and it's not technology that makes these decisions. Security teams, in concert with the many and varied business units they serve, need to decide who has access to all of this data and, more importantly, regularly re-evaluate that level of access. This is a great place for a risk or privacy officer to step in and act as a check as well. I would not treat access into this system any differently than other systems. Build policy, follow it, and amend regularly. Back to if I was running this program. I would borrow pretty heavily from successful vulnerability management exception handling processes. Let's say there's a vulnerability in your environment that you can't remediate, because a business critical system relies on it. In this case, we would put an exception in for the vulnerability. We justify the exception with a reason, place a compensating control around it, get management sign off, and tag an expiration date so it isn't ignored forever. Treat access into this system as an “exception,” documenting who is getting access, why, and define a period in which access will be either re-evaluated or expire, forcing the conversation again. An authority outside of security, such as a risk or privacy officer, should sign off on the process and individual access. Under what circumstances will this system be accessed, and what are the consequences for abusing that access? There need to be well-defined consequences for those that violate the rules and policies set forth around a good incident detection and response system. In the same way that security shouldn't allow HR to perform witch hunts unrelated to security, the security team shouldn't go on fishing trips (only phishing and hunts). Trawls through data need to be justified. This is for the same reasons as the HR case. Alienating our users hurts everyone in the long run. Reasonable people are going to disagree over what is acceptable and what is not, and may even disagree with themselves. One Rapid7 customer I spoke with talked about using an analytics tool to track down a relatively basic financial scam going on in their email system. They were clearly justified in both extracting the data and further investigating that user's activity inside the company. “In an enterprise,” they said, “I think there should be no reasonable expectation of privacy – so any privacy granted is a gift. Govern yourself accordingly.” Of course, not every organization will have this attitude. The important thing here is to draw a distinct line for day to day use, and note what constitutes justification for crossing that line. That information should be documented and be made readily available, not just in a policy that employees have to accept but never read. Take the time to have the conversation and engage with users. This is a great way to generate goodwill and hear out common objections before a crisis comes up, rather than in the middle of one or after. Despite the above practitioner's attitude towards privacy in an enterprise, they were torn. “I don't like someone else having the ability to look at what I'm doing, simply because they want to.” If we, the security practitioners, have a problem with this, so do our users. Let's govern ourselves accordingly. Technology based upon data collection and analysis, like user behavior analytics, is powerful and enables security teams to quickly investigate and act on attackers. The security versus privacy battle lines often get drawn here, but that's not a new battle and there are plenty of ways to address concerns without going to war. Restrict the use of tools to security, track and control who has access, and make sure the user population understands the purpose and rules that will govern the technology. A security organization that is transparent in its actions and receptive to feedback will find its work to be much easier.

Log Search Simplified

Hi, I'm Laura, UX Designer at Logentries and today I'm going to discuss how just about anyone can use Logentries to search and analyze their log data no matter what their job title or technical skill level. What is Logentries? At Logentries, the team works…

Hi, I'm Laura, UX Designer at Logentries and today I'm going to discuss how just about anyone can use Logentries to search and analyze their log data no matter what their job title or technical skill level. What is Logentries? At Logentries, the team works tirelessly to provide an easy to use log management service that allows users to stream their logs from just about anything. Logentries can accept data from almost any device that generates log data, including servers, applications, firewalls and routers. Really, any data, from any device and in any kind of format. These log events are automatically collected and sent to one secure location where users can quickly search and visualize their data to find out all they need to know. Typically, Logentries is used by DevOps and Developers while they are busy debugging, monitoring and troubleshooting. More recently, as Logentries has become part of Rapid7 information security and analytics solutions, the power of log search has grown to include a new variety of users within information security teams and IT. These professionals use Logentries search to help solve security problems, investigate incidents and help maintain compliance. So IT guys get to have all the fun? Not quite. We have a growing number of users from non-technical backgrounds who are hot on their heels. Businesses and marketing teams have recognized the potential of using Logentries to monitor behaviors, identify patterns and gather all types of interesting information to help focus their business goals or marketing campaigns. The basics of performing a search So you're not a DevOps master or some kind of IT guru? No problem. I'm going to take you through the basics of performing a search in Logentries using our very own search language LEQL (Logentries Query Language). Using this simple SQL-like language you can extract data hiding deep in your logs. Now that you know the basic query format, we will take a look at putting it into practice. For example, let's take myself, a UX Designer who wants to design solutions for an improved user experience within Logentries. But where do I start? Where do I focus my energies? First I want to discover the most popular or core features in Logentries. Easy. I can do this by using an application library such as node.js, .Net or Java libraries which allow you to log straight from the front end of your application. You can find this in the "Add a log" page and it is a quick and easy set up process. You can find a more detailed set up process and tips in the blog post "A different way to log your website usage". Your developer will help you embed the necessary code into your site and create listeners on elements you would like to track like buttons, links, pages and features. Once set up it can track metrics such as usage trends, activity, behaviors and engagement times across your application. Tracking most clicked features Now that I have the information that is important to me logging to my Logentries account, I can write some LEQL to query this data. First, navigate to the Logentries Log view. This is where logs feed into, where we can select logs and where we can search. The query search bar has two modes. "Advanced" is the mode an experienced user would use to write full LEQL queries. "Simple" mode is for users who are newbies or just need a helping hand in building their query. We are going to use simple mode to get you started. We are interested in learning how often a user visits a feature. We can find this out by tracking how often the button or link to this feature is clicked. First comes the "where" field followed by the "groupby" and "calculate" fields. Next is an icon to allow you to save your query and a time picker to allow you to select a particular time range to search. The mode can be toggled between simple and advanced via the switch mode link. Step 1 We want to search for click events so we search the keyword "clicked." Keyword search will work on all log entries regardless of their format and are case sensitive by default. This will give you a result of all the log entries containing click events. You can see the keyword highlighted in yellow. Step 2 That's great, but we want to do a more granular search. We need to break this up into exactly what features were clicked. Let's group by "features." Once this key is added to your query the calculate function automatically selects calculate(count). This returns a count of the matched search. Your results are returned as a table with all of your search criteria listed and a visualization of your data. Now you can see all the features that have been clicked and how often they were clicked giving an indication into what features users spend most of their time using. This can help me prioritize where I should focus my efforts to work towards making these features better for our users. Endless possibilities This is just one example of how you can use Logentries search to gain insight into your application usage. You could potentially find out lots of other interesting data like what screen resolution your users use most or what the most popular browsers are. You could find out how often or at what point a user drops off or cancels from a workflow such as a sign up process or a create wizard. Or even how long a user hovers on a button or how long they spend on a particular page. The possibilities are endless. To learn more about search check out our docs or start a 30 day free trial. Thanks for reading! Laura EllisUX Designer, Rapid7

Featured Research

National Exposure Index 2017

The National Exposure Index is an exploration of data derived from Project Sonar, Rapid7's security research project that gains insights into global exposure to common vulnerabilities through internet-wide surveys.

Learn More

Toolkit

Make Your SIEM Project a Success with Rapid7

In this toolkit, get access to Gartner's report “Overcoming Common Causes for SIEM Solution Deployment Failures,” which details why organizations are struggling to unify their data and find answers from it. Also get the Rapid7 companion guide with helpful recommendations on approaching your SIEM needs.

Download Now

Podcast

Security Nation

Security Nation is a podcast dedicated to covering all things infosec – from what's making headlines to practical tips for organizations looking to improve their own security programs. Host Kyle Flaherty has been knee–deep in the security sector for nearly two decades. At Rapid7 he leads a solutions-focused team with the mission of helping security professionals do their jobs.

Listen Now