The idea is to define what you absolutely know is anomalous, then create an event log management system that looks only for those events. You don't have to be all-inclusive or perfect. Start off by defining the items you know are bad and would never happen in your environment. Don't pick up every event log entry that could be generated. Instead, generate only what's actionable, and restrict your collection and reaction to those less numerous events. We go for the low-hanging fruit in almost every other IT project. Why not with event log management?
You might think the events you know are likely to be bad would generate too many false positives. If that's true, then you're defining the wrong events. My advice is to define only the stuff that you know is 100 percent malicious.
Don't get me wrong. You might not always catch an uber-hacker. You might ensnare the SQL admin exploring SQL servers they weren't authorized to visit or an end-user who thinks they're an admin trying to use RDP to one of the servers. Those aren't false-positive events.
But if you catch a few people doing things they shouldn't, pretty soon word starts going around about your killer antihacker monitoring system. You'll end up impressing employees, yourself, and management. You can't and won't do that with a traditional log management approach.
This story, "Event log management made easy," was originally published at InfoWorld.com. Keep up on the latest developments in network security and read more of Roger Grimes' Security Adviser blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.