Basic Baselining For Quick Situational Awareness

Last week, I had the pleasure of speaking on a panel called "Using Log Files and SIEM Data to Identify New Threats to the Enterprise." It’s a long, fluffy title, but the discussions were good and a common theme kept coming up despite the distinct difference in backgrounds among the other panelists (Joe Gottlieb, CEO, SenSage; Mary Landesman, senior security researcher, Cisco) and me. The theme was that to have an understanding of what’s going on within your network, you need to first have a basic understanding of what’s going on -- starting with a baseline of what’s normal.

Baselining activity in your network does not have to be complicated. Sure, it can get complicated, and that’s part of the reason why there are entire companies built around SIEM products with pretty dashboards to show what’s going on and when things deviate from the average level of normalcy. But -- not everyone can afford those products or have a network large enough to justify having one. Or, it might be that there is an immediate need to get a feel for the state of things. Whatever the reason, baselines can start out basic and grow to adapt to changing needs and knowledge of the systems involved.

Let’s start off with a basic example of where a system administrator could start doing simple baselining to understand what’s normal operation for one to many systems during a regular business day. The admin could start by taking a look at some of the critical systems to see how many events show up in the logs each day. The events could be broken down into the services generating the events or the types of events. For example, what's the average number of access and error messages in an Apache Web server's logs, or how many successful and failed logins do the Microsoft Active Directory domain controllers see?

Simply knowing the average number and type of events that occur on a daily basis gives an immediate awareness of what's normal and an opportunity to catch abnormalities as they arise. If there is a sudden jump in failed logins, for example, then there could be a brute-force password guessing attack. Start analyzing the logs to see what accounts were attacked and whether any successful logins occurred immediately after the failures, indicating an account might have been compromised. With Web server logs, it could indicate someone is scanning for vulnerabilities or exploiting a SQL injection flaw to pull out the contents of the back-end database.

This same basic baselining method can be applied to desktops, servers, Web applications, firewalls, intrusion-detection systems, and pretty much anything else that logs data. After getting a feel for what's normal day-to-day, the baselines can be adapted to see what's normal for certain days of the week, weekday vs. weekend, or even hour-to-hour each day.

As you become more familiar with the logs, what's normal, and how systems interoperate, additional ways to view the data in meaningful ways will come about. The biggest hurdle to logging is starting -- baselining is the same way. Just do it. You won't regret it. John Sawyer is a Senior Security Analyst with InGuardians. The views and opinions expressed in this blog are his own and do not represent the views and opinions of his employer. He can be reached at [email protected] and found on Twitter @johnhsawyer.