Following the new "tradition" of posting tips of the week, I decided to follow along and join the initiative. So, after a long delay, Anton Logging Tip of the Day #16: Virtually There - Journey Into VMWare ESX Log Analysis CISecurity guide for VMWare (here) and DISA STIG for virtual machines (here) both mandate collection and analysis of VM platform logs; none goes into enough details on what to look for in logs. Let's try to shed some light on security-focused log analysis of VMWare ESX v. 3.x logs.

Our brilliant field engineer, Dimitri McKay (his blog) brings another fun and insightful story from the field:  "I recently went on-site for a proof of concept. I’ve always loved these exercises, as it gives me a chance to help a customer see that which was invisible in the past, whether it be virus-outbreaks, users abusing bandwidth via bit-torrent and file sharing, or VOIP phones assaulting DHCP servers for IP addresses. This particular customer had an interesting configuration.  They had been sending their critical/alert and emergency firewall logs to a 3rd party security operations center. That SOC was supposed to monitor the firewall data for any risky traffic, identify any anomalies, and report the instant there’s an issue.

[ Originally posted at OnSaaS ]

Today, the major use of cloud computing for enterprises are still in its infancy (heck the whole cloud computing space is in its infancy). Most enterprises use cloud computing for testing, development and other peripheral tasks. However, most, if any, are using the clouds for production use. This is fairly similar to the virtualization space, where early use of the virtualization technology are for testing and development. Ten years later, we are seeing more and more enterprises adopt virtualization for production use and virtualization has become main stream.

What are these challenges for enterprise cloud computing? I have tried to summarize them here (in no particular order).

I recently did this webcast on logging for accountability (slides and recording here) and people asked a lot of good questions. Here are some of the answers for them as well as our blog readers.   Q1: How do you handle variety of log sources? There are so many, almost beyond my capability.

I would like to continue the discussion I started in my previous post called "Today's Logging Problems - Then Future Problems - Part I." Specifically, upon outlining some problems with logging, I will now forecast what will happen with them in 18-24 months.

Here is another fun preso: "NIST 800-92 Log Management Guide in the Real World"

My next logging poll is out - with it I set out to figure out the old mystery of mine, why people don't protect their log data (e.g. see this lamentation "Top 11 Reasons to Secure and Protect Your Logs") Vote away! As always, results will be posted. Past polls and analysis are all here.

Remember my write-up about an ideal log management tool?  Somebody asked me: "That's great that you have such a clear  vision of a future log management technology - but tell me first what future business problems will such 'ideal tool of the future' solve?"  First, I pointed at the fact that there are plenty of log-related problems today which we are not even close to solving. We need to solve the problems of today first, before we can get to solving the future problems. So, what I consider to be the biggest log-related problems of today?

LogLogic just released a new case study on CernerWorks.

Cerner's need to meet HIPAA's requirement for logging data prompted them to investigate solutions that had adequate capacity and a centralized repository. But they wanted more than just a log management system — the solution CernerWorks found also offered troubleshooting and real time viewing, allowing it to not only meet the compliance requirement but to improve both operations and security.

To receive your complimentary copy of Kicking Log Management up a Notch at CernerWorks, please complete the form below. It will help us serve you better and provide you with valuable information.

Inspired by this and this here (and this too). It started from this example, coming from another domain: “You’re hired on at a new company placed in charge of securing their online business. You know next to nothing about the technical details of the infrastructure other than they have no existing web/software security program and a significant portion of the organizations revenues are generated through their websites. What is the very first thing do on day 1?”

Here is another of my presentations, given at many conferences in the past year or so. This one is on common log analysis and log management mistakes.

We just released a minor Project Lasso update, version 4.0.5, to SourceForge.

Loglogic Windows Event Collector 4.0.5 contains the following improvement relative to LogLogic Windows Event Collector 4.0.4:

• Resolved an issue where event message 642 is collected but some fields appear empty on the server, preventing alerting on the event. The fix also resolves empty fields appearing for other event logs. (15893)

Anton Logging Tip of the Day #15: Fear and Loathing in Event 567

This tip digs into a seemingly simple, but really VERY esoteric subject: monitoring file access and modification via a Windows event log. Now, some people - who never studied this subject - tend to have a very simplistic view of this: just enable Object Access auditing, then right-click on a file or directory, click Security->Advanced->Auditing and then pick what types of events will be logged and by what accessing entities (i.e. users or computers). OK, so this will produce some logs, that is for sure. But are they useful?