The NSA released a PDF entitled “Spotting the Adversary with Windows Event Log Monitoring” earlier this year. While there’s a bit of irony in this, given the whole Snowden story that followed the release of this document, the PDF is still chock full of great information on what to watch for in an effort to “spot the adversary.” Now, I must warn you – there’s good news and bad news that comes with this document.
The good news is it’s probably one of the most detailed documents I’ve seen in a long time. Everything from setting up Event Subscriptions, to a hardened use of Windows Remote Management, including the use of authentication and firewalls, this document tells you how to securely setup an environment where you can natively consolidate and monitor event log based entries.
In addition, the NSA goes onto cover a number of areas that should be monitored – complete with event IDs – which I’ve broken into two sections.
Machine-specific issues – which can be indications of malicious activity
- Application Crashes
- System or Service Failures
- Kernel and Device Signing
- The Windows Firewall
Administrator Activity – specific actions performed that may be suspect
- Clearing of Event Logs
- Software and Service Installation
- Remote Desktop Logon
- Account Usage
OK – so what’s the bad news? The bad news is you’re still left to sort out a TON of event log detail and interpret whether the entries are a problem or not.
The real value of event logs is being able to see what specifically has changed. In some cases, like a service failure, it’s easy to see – the once working service now no longer is. Same goes for something simple like the clearing of an event log – you’ll know Joe Smith cleared it at a specific date and time. So what’s the big deal then? Well, when you start looking at more advanced activity, like Account Usage, event logs will only take you so far. Let’s take the one example the NSA document hasn’t taken into consideration – changing the audit policies themselves. Think about it. The entire setup spanning 67 pages only works IF auditing of each type of activity is enabled. So what happens when the “adversary” simply turns off the auditing of, say, Account Usage, and then performs some dastardly deed?
You’ll never catch it. The reason? Changes to Group Policy only show up in the events as a change to the policy, but lack detail on exactly what was changed within the Group Policy.
To truly have a grasp on whether you have an “adversary” within or not and, if so, what that adversary is doing, you’re going to require a solution that not only collects events, but can correlate them into something intelligent. Your solution should:
- Consolidate events
- Focus on the events you are concerned about
- Provide comprehensive detail about the changes to your systems, security and data
The NSA doc will take you to about 2 and a quarter of the three bullets, but it’s the rest of that last bullet that is going to make the difference. Knowing a change to a server was made last night at 11:53pm is well and fine, but knowing exactly what was changed is going to make all the difference in the world when trying to spot and address your enemies within.
