Perimeter
10/28/2011
01:00 PM
John H. Sawyer
John H. Sawyer
Commentary
Connect Directly
RSS
E-Mail
50%
50%

Basic Baselining For Quick Situational Awareness

Baselines can be extremely valuable in knowing what's going on within your network, but they can't help if they're not created -- start with the basics

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 johnhsawyer@gmail.com and found on Twitter @johnhsawyer.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-6335
Published: 2014-08-26
The Backup-Archive client in IBM Tivoli Storage Manager (TSM) for Space Management 5.x and 6.x before 6.2.5.3, 6.3.x before 6.3.2, 6.4.x before 6.4.2, and 7.1.x before 7.1.0.3 on Linux and AIX, and 5.x and 6.x before 6.1.5.6 on Solaris and HP-UX, does not preserve file permissions across backup and ...

CVE-2014-0480
Published: 2014-08-26
The core.urlresolvers.reverse function in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3 does not properly validate URLs, which allows remote attackers to conduct phishing attacks via a // (slash slash) in a URL, which triggers a scheme-relative URL ...

CVE-2014-0481
Published: 2014-08-26
The default configuration for the file upload handling system in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3 uses a sequential file name generation process when a file with a conflicting name is uploaded, which allows remote attackers to cause a d...

CVE-2014-0482
Published: 2014-08-26
The contrib.auth.middleware.RemoteUserMiddleware middleware in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3, when using the contrib.auth.backends.RemoteUserBackend backend, allows remote authenticated users to hijack web sessions via vectors relate...

CVE-2014-0483
Published: 2014-08-26
The administrative interface (contrib.admin) in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3 does not check if a field represents a relationship between models, which allows remote authenticated users to obtain sensitive information via a to_field ...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
This episode of Dark Reading Radio looks at infosec security from the big enterprise POV with interviews featuring Ron Plesco, Cyber Investigations, Intelligence & Analytics at KPMG; and Chris Inglis & Chris Bell of Securonix.