One of the most interesting facts in the field of computer security is that most corporate victims fail to detect their own compromises. Most often the malicious activity is first noticed by outsiders, but even then the discovery may occur many months, if not years, after the original compromise.
This is despite the fact that most victims have the evidence of the compromise sitting in their own event logs. They simply don't look. This should never be an acceptable fact, but it's downright negligence in today's world of constant spam, ever-present malware, and ever-successful APTs (advanced persistent threats).
[ Learn how to harness the security secrets contained in your event logs with "Log Analysis Deep Dive Report." | Keep up with key security issues with InfoWorld's Security Adviser blog and Security Central newsletter. ]
In truth, no one likes to ignore event logs. The central problem is that most alerting systems are 99.999 percent full of events that indicate nothing malicious whatsoever -- it's a self-induced denial-of-service attack. We get information overload from everywhere: firewalls, IDSes, antimalware consoles, antispam, system logs, forensics analysis, network flow analysis, and honeypots. Almost none of it is truly useful.
So how do you change the status quo to get more relevant, actionable information?
Step one is ending the madness of generating events and alerts that never result in an immediate, meaningful response. Turn the traditional event-logging model on its head by deciding to create alerts only on events that are absolutely malicious and/or should always result in an immediate, meaningful investigative response. To do this, you need to define which events indicate malicious mischief in no uncertain terms.
Raising the alarm on bad logons
Suppose domain admins and enterprise admins should never log on to regular workstations. If someone belonging to those superelevated groups does so, it should create an event to be investigated.
Microsoft Windows has defined such an event-monitoring tool, known as Special Logons. With Special Logons, admins define which groups are considered "special" and write those groups to each computer to be monitored in the Special Logons table. When enabled, if someone logs on to a monitored computer and belongs to a defined group, it generates a new event that should be immediately forwarded to an event log collector, which then generates an alert.
The one company in the world that hasn't been pwned uses this trick. Bad guys usually try to get elevated accounts, then use them to laterally traverse the network, hopping computer to computer. They usually have "god account" credentials with which they can log in all over the place. They have no idea what Special Logons are or where they should or shouldn't be logging on using the god accounts.
A lot of good event logging is looking at normal, reoccurring events, only alerting if they are excessively high. For example, a "bad logon" is a pretty normal event on most networks. They occur on almost every computer at least once a week, if not multiple times a day, usually due to the legitimate user putting in a bad password. This happens more and more, especially as we knowingly increase password sizes. You can't just generate an alert for a bad logon or even 100 bad logons on your network.
That's why bad logons, like many other events, require baselines and thresholds. The idea is you need to measure the range of the normal number of bad logons in your environment, then alert only when that normal number has been excessively exceeded -- and not by a little amount.