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
Cartoon
Current Issue
Dark Reading Must Reads - September 25, 2014
Dark Reading's new Must Reads is a compendium of our best recent coverage of identity and access management. Learn about access control in the age of HTML5, how to improve authentication, why Active Directory is dead, and more.
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-5485
Published: 2014-09-30
registerConfiglet.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via unspecified vectors, related to the admin interface.

CVE-2012-5486
Published: 2014-09-30
ZPublisher.HTTPRequest._scrubHeader in Zope 2 before 2.13.19, as used in Plone before 4.3 beta 1, allows remote attackers to inject arbitrary HTTP headers via a linefeed (LF) character.

CVE-2012-5487
Published: 2014-09-30
The sandbox whitelisting function (allowmodule.py) in Plone before 4.2.3 and 4.3 before beta 1 allows remote authenticated users with certain privileges to bypass the Python sandbox restriction and execute arbitrary Python code via vectors related to importing.

CVE-2012-5488
Published: 2014-09-30
python_scripts.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via a crafted URL, related to createObject.

CVE-2012-5489
Published: 2014-09-30
The App.Undo.UndoSupport.get_request_var_or_attr function in Zope before 2.12.21 and 3.13.x before 2.13.11, as used in Plone before 4.2.3 and 4.3 before beta 1, allows remote authenticated users to gain access to restricted attributes via unspecified vectors.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
In our next Dark Reading Radio broadcast, we’ll take a close look at some of the latest research and practices in application security.