Windows Workstation Logs – Increasing Visibility

Anyone who has looked at the number of event IDs assigned to Windows events has probably felt overwhelmed. In the last blog, we looked at some best practices events that are a great start to providing contextual data in the event of a security breach. For example, repeated login failures, attempted privilege escalations, and attempts to manipulate registry entries are all going to provide useful forensic data during incident response. Let’s broaden our horizons. The fact that event IDs exist in several sources beyond Microsoft-Windows-Security-Audit allows us to be more proactive and have a better understanding of how our users and systems interact. It’s all about building a baseline of what is normal and recognizing potential threats and IoCs as sequences of event IDs.

Here are some additional event sources and useful IDs that will help increase visibility through a better understanding of network assets and how they are used:

Between these events and the list of account, process, and firewall events from the previous blog, you know have a well-rounded security policy.

Note that this is by no means an exhaustive list. The idea is to get started with a set of events to build a threat detection policy. There are several other types of events such as those that report on wireless usage, mobile device activities, and print services. These events can be tracked for audit, billing, and resource utilization purposes and periodically archived.

The next step is to define how to apply our security policy and to be prepared to tune it over time. To facilitate this process, create a checklist for your environment:

• Identify which events should be monitored for critical assets versus all endpoints
• Identify those events that should be tracked at various times of the day
• Identify events that should trigger an immediate action, such as send an email to an admin; these may be tied to a task directly from the Windows Event Viewer or a series of events can be configured as triggers for alerts via the Task Scheduler

• If I don’t use features such as AppLocker or Defender, should I investigate their applicability?
• Understand which events should be prioritized in terms of reaction and remediation

• What events or combinations of events are considered alerts, and which are providing contextual information?
• What events need to be tied to thresholds that make a clear distinction between normal versus threat?
• Do I need to have a policy for threat detection and a process for collecting audit information?

Having a clear plan for your security policy will help overcome the biggest issue with all logging and alerting; large numbers of false positives that waste time and resources and possibly detract from a real threat.