What to monitor to stop hacker and malware attacks

The 2012 Verizon Data Breach Investigations Report released last week continues to reverberate. The stats that jumped out at me: 96 percent of data breaches were relatively easy for attackers to pull off, and 97 percent of those attacks were easily avoidable.

Want to protect yourself against malicious hackers and malware? Do the basics better and more consistently. Patch better, isolate better — and for god’s sake, enable your monitoring.

According to the report, 85 percent of victims were unaware of their compromised state for weeks- to months-long stretches. When they did become aware, 92 percent of the time it was because an outside third party told them. That’s embarrassing.

In which group would you rather be? The 85 percent hanging their heads in shame or the 15 percent who had a clue?

I know InfoWorld readers care more than the average IT working stiff. It’s why you read our publication and this blog in particular. I also realize that our readers are tasked with dozens of different projects every year, each one a high priority that overrides previous priorities.

But the bottom line is this: If you don’t have a good security event logging program, become the champion in your organization and create one.

What to monitor

You should enable event log monitoring on all managed workstations and servers. Don’t make the mistake of only monitoring servers — 99 percent of the malicious action begins on a regular end-user’s workstation before it spreads to the servers holding the data. Often, by the time attackers reach the servers, they are operating with an elevated end-user’s credentials, and event log monitoring becomes much tougher.

In the interest of giving specific advice, I’ve assembled the Windows security event log IDs [Excel format] that you should be monitoring on Microsoft operating system, although the events and behaviors they cover should be monitored on any OS used by your organization. Microsoft probably has the best security event log ID descriptions, so it’s a good place to start. (Note: I am a full-time employee of Microsoft.)

High-criticality events. Here are the events I consider most relevant and require immediate investigation, unless the event that occurred through approved change/configuration control requirements.

Medium-criticality events. Medium-criticality events should be monitored, but shouldn’t generate alerts unless they were incurred in an anomalous manner.

There are numerous other events, many with low criticality, that deserve monitoring and alerting if they occur in an anomalous way (these are listed in my downloadable Excel file). Failed log-ons provide a great example. Every large environment experiences dozens to hundreds of failed, nonmalicious log-ons every day. People simply can’t type their passwords or PINs correctly every time. But an alert should be generated if the number of failed log-ons suddenly exceeds the normal amount expected in a given time period or occurs across more than the normal cross-section of computers. The event could just be the outcome of an errant script that is attempting to use an old password, but it could also be an attacker guessing the password.

No event log monitoring plan should be complete without a few well-placed honeypots. In those cases, any attempted log-ons to the fake systems should generate alerts.

There are far more to security event log monitoring systems than can be covered in a short article, but if you’ve ever wanted someone to give you specific list of events that you should be monitoring and alerting on, you have it now.