Welcome Guest. | Log In | Register | Membership Benefits
Dark Reading's evil-bytes Weblog

Topics:   Evil Bytes

Top Excuses For Foregoing Security Monitoring, Logging

Monitoring for security incidents can be tough. It's tougher when you don't know what to look for. Now imagine trying to investigate an incident when you don't have any logs to analyze.

Sep 28, 2010 | 08:30 AM | 

By John H. Sawyer
Dark Reading

Monitoring for security incidents can be tough. It's tougher when you don't know what to look for. Now imagine trying to investigate an incident when you don't have any logs to analyze.In this day and age, it's simply irresponsible for organizations to shrug the value and basic need of having a centralized logging infrastructure. Instead, they make excuses for why it can't be done and let the logs autorotate themselves into the ether.

There are two excuses I hear repeatedly regarding why organizations (of all sizes) don't enable logging, centralize the logs, and monitor them in some way.

1. The first is they simply don't have the manpower to devote to log monitoring. Really? I guess if you're talking about devoting a full-time person to watching logs as they scroll by on the screen, then sure, I wouldn't want to allocate any manpower to that task either. It'd be a boring, monotonous job that would likely end up with a lot of turnover.

Have you ever had to deal with a security breach? How about one that led to notification -- or should have led to notification -- but management swept it under the rug? Those investigations can be lengthy, and the more systems involved, the longer it takes. Having the logs from all of your systems in one place can drastically cut that time.

Setting up a logging infrastructure, configuring automated reports that get e-mailed on a regular schedule, and a few real-time alerts using Splunk or OSSEC HIDS takes a lot less time than the typical multisystem breach investigation. And when done right, it can even prevent a breach or at least prevent serious collateral damage.

2. The second excuse that gets thrown at me (complete with a sad face) is that centralizing logs is too expensive. If you're looking to put an expensive SAN behind your logging solution, then it can definitely be pricey. Since the logs are generated for free, you should take advantage of them -- at the very least throw some cheap storage at the problem.

You can get a 2 TB hard drive for around $100, so buy one, shove it into that server sitting in the corner, install Linux running syslog or Windows running Kiwi Syslog Daemon, and start sending logs to it. Then at least you'll have them for when the stuff hits that fan, which is much better than staring at your CIO with a dumb look on your face when he asks why you can't figure out what happened or how long it has been going on for.

Storage needs aside, the software needed to centralize logs is available freely. Sure, plenty of vendors will sell you some expensive log management appliance that will suck down the logs and make them available via a pretty Web interface, but you can do that for free with Linux (same OS the appliances are running) and Splunk (using the free edition of Splunk that is limited in some features).

Even the software to get the logs from the systems doing the logging is free if it's not already included. For example, to get the logs from Windows systems, Snare and LASSO are great, free options that push Windows Event Logs and some text-based logs (e.g., IIS and DHCP) to a syslog server.

As we approach the looming PCI deadline, logging is something companies will be scrambling to implement as they try to fill in all the boxes on their compliance checklists. Once they realize it really isn't that hard, they'll be asking why they weren't doing it sooner.

John H. Sawyer is a senior security engineer on the IT Security Team at the University of Florida. The views and opinions expressed in this blog are his own and do not represent the views and opinions of the UF IT Security Team or the University of Florida. When John's not fighting flaming, malware-infested machines or performing autopsies on blitzed boxes, he can usually be found hanging with his family, bouncing a baby on one knee and balancing a laptop on the other. Special to Dark Reading.



Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dark Reading encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dark Reading moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. Dark Reading further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
Subscribe to RSS









  1. Cookies, Social Media And FireSheep
  2. SMB Guide To Credit Card Regulations, Part 2: The Low-Hanging Fruit
  3. HP And The Scary Corporate Fifth Column Concept
  4. Taking USB Attacks To The Next Level
  5. NoSQL: Not Much, Anyway
  1. Taking Cybersecurity Lessons To The Bank
  2. Researchers See Real-Time Phishing Jump
  3. 'BlackSheep' Sniffs Out Firesheep WiFi-Hacking
  4. Slideshow: Ten Free Security Monitoring Tools
  5. A Different Spin On Sleuthing Stuxnet
  6. M&A Activity Muddles Database Security
  1. Secure Managed Web Hosting Saves 960.gs from Malicious Hackers
  2. Access Governance as a Business Service: An Integrated Strategy for Automation with ITSM
  3. Business Driven Access Management and Governance: Simplifying the Delivery and Governance of Access Throughout
 
 


 
  Ars Technica
Boing Boing
Channel 9 Forums
CRN Blogs
Dr.Dobb's Portal: Blogs
Engadget
Gizmodo
GrokLaw
  Lifehacker
Schneier on Security
Slashdot
TechCrunch
Techdirt
Techmeme
Valleywag
 
  May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
  June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
 
Featured Webcasts
Featured Whitepapers
Featured Reports