Can you have too much of a good thing? Maybe not, but you can certainly have too much of the wrong thing. In my first blog, I introduced the idea that Microsoft event logging from workstations can be a simple first step to building a security policy that looks beyond the perimeter. The simplicity comes from the fact that event logging is part of a workstations OS, so no need to acquire additional applications or agents.
As many of you commented, the more difficult part is filtering out the stuff you don’t need. Fortunately, this is also the fun part.
By creating focused event log filters and sets of important events, the admin is required to understand what different event IDs mean and how they relate to the overall security of the organization. Being proactive and reactive to threats requires knowledge and at times creativity. You also need to monitor and tune your workstation event log policies to ensure they are providing the appropriate level of coverage whilst not overwhelming a system from a performance standpoint.
So what are the must-haves when it comes to event logs? Here are some of the critical ones for a workstation (non-server) policy.
- NEW PROCESS STARTING: 4688 - logs when a process or executable starts
- USER LOGON SUCCESS: 4624 - tracks successful user logons to the system
- LOGIN FAILURES: 4625 - can be used to detect possible brute force attacks
- SHARE ACCESSED: 514 - helps track user access to file shares
- NEW SERVICE INSTALLED: 7045 - will capture when a new service is installed
- SERVICE STATE CHANGES: 7040 - can indicate a service has been modified by a hacker
- NETWORK CONNECTION MADE: 5156 - works with Windows Firewall to log the state of a network connection (source, destination, ports, and process used)
- FILE AUDITING: 4663 - logs an event when new file is added, modified or deleted
- REGISTRY AUDITING: 4657 - will capture when a new registry item is added, modified or deleted
- WINDOWS POWERSHELL COMMAND LINE EXECUTION: 500 - will capture when PowerShell is executed and log the command line
- WINDOWS FIREWALL CHANGES: 2004 and 2005 - will capture when new firewall rules are added or modified
- SCHEDULE TASKS ADDED: 106 - will capture when a new scheduled task is added
- USER RIGHT ASSIGNMENT: 4704 - documents a change to user right assignments on this computer and will show privilege escalations
- USER ACCOUNT CREATED: 4720 - tracks accounts created on the local machine
- USER ACCOUNT DELETED: Event Code 4726 - alerts if a local account is removed
- USER ACCOUNT LOCKOUT: Event Code 4740 - reports accounts locked due to failed password attempts
The threat landscape is always changing. Attacks have a lifecycle and in the end they are either remediated by our virus and malware products, or they morph into the next big thing.
Once you have an event policy in place, it’s important to monitor the latest security issues in order to assess the applicability of your policy.
A few points to consider are:
- Does your event set still help detect and remediate attacks?
- Has there been a change to endpoint configuration (a new agent for example) that may be creating duplicate event logs?
- As the OS changes over time, are new events available that should be introduced?
- Should I tune my parameters or deprecate event IDs that are no longer relevant to avoid taking up space?
- Are there compliance mandates that dictate a change in policy?
The moral of the story is, when it comes to security, you are never really done.
In my next post, we’ll take a look at building an overall strategy for creating event log filters and deploying your event log policies. We'll also identify some events that are worth tracking relating to specific applications and services.
One great reference for Windows Event IDs:
ultimatewindowssecurity.com 
