Search This Blog

Thursday, July 10, 2014

(T) Filtering or trimming Windows logs the right way, NOT by Event ID

Have you ever worked with Windows logs and enabled all or a lot of auditing items and feel there are way too many events or noise?

Ever enabled 'Filter Platform Policy Change' to monitor the Windows Firewall connection? This auditing option will add Event ID’s 5156 and 5158 to your logs and quickly be in your Top 10 of all events generated. If you enable success for 'Process Creation' you will get Event ID’s 4688 and 4689. These four Event ID’s will probably be your Top 4 events generated.

Enabling these two auditing items will add a ton of events to your logs. While stored on a systems local disk you won't notice a thing, forwarding them to a Log Management solution you will find they add up and impact disk space and licensing. But they are some of the greatest events Windows has to offer, so use them!

Jedi Tip: Ever wanted to know what IP's and ports a Windows application is using? Maybe to make a change on your enterprise firewall? Use 'Filter Platform Policy Change - success' to see all inbound and outbound connections to and from your Windows Server or Workstation. You can even use this data to refine your Windows a Firewall rules for allowed IP's to an application like a security camera for example or remote access, see my last Blog entry for tips on this one HERE.

So how do you enable a policy item, start collecting log data yet filter the unwanted noise out? Most people do it by disabling auditing of the two items above or excluding by Event ID, which is a terrible way to filter or trim logs. Unless of course the Event ID is truly worthless and none of the events in that ID are useful to you or your admins or dev folks.

If you filter out or disable Windows firewall auditing (Event ID’s 5156 and 5158) for example; then you can't see all the inbound connections to your systems, remote connections by remote IP to the system, track users surfing to IP's, or outbound malware C&C requests. You would be forced to do this at the network layer where you cannot easily hone in on a host and what process is using an IP you are investigating.

If you filter out or disable Process Creation auditing (Event ID’s 4688 and 4689) for example; then you can't see the processes that have been launched on a system, or see what process called another process like CMD.exe calling malware.exe.

Do you need to see or keep ALL of the events of the ID's just discussed? No, you can look at Process Names and Application Names that you deem normal noise and exclude them versus eliminating by Event ID. Google Chrome Update is incredibly noisy log wise, yet probably not needed for InfoSec or forensic investigations. You could toss out GoogleUpdate.exe or Splunk*.exe and reduce your events of the four Event ID's mentioned by 50% give or take saving disk and log management licensing. The image at the top is exactly this filter before and after.

If you are wanting to try the Free version of Splunk at home or in your lab, then reducing events by tossing them out will save on the 500mb per day Splunk eval license restricts you to. Each log solution will have different ways to filter items out or blacklist them from being collected, but never ever do it by Event ID as you can or will lose valuable log data. Unless you are certain the Event ID and all its' events are worthless.

Read the definitive "Windows Logging Cheet Sheet" I put together for Windows logging here for tips on what to enable, configure, gather and harvest.

#InfoSec #HackerHurricane #LoggingDoesntSuck