Denys Rudyi - Fotolia

Why should I limit the number of desktop audit logs?

A Windows audit log can get big and cumbersome, which presents a problem if you need to look at it after a security breach. Only audit what is necessary.

There are many different philosophies regarding how to best audit Windows workstations, but I tend to follow a less-is-more approach.

Most organizations do not examine desktop audit logs until after a security incident. In that situation, desktops must contain meaningful forensic information, but relevant desktop audit log entries must also be easy to find. The Windows operating system contains a very rich auditing system, and it would be easy for an administrator to turn on logging for every conceivable event. But doing so causes Windows to create a mind-boggling number of log entries. The Windows audit log grows so large and verbose that it's nearly impossible to locate the events that are of the greatest interest after a security incident.

In my opinion, it is best to turn on audit logging only for the events you will be interested in referencing if a security incident occurs. For example, I recommend auditing successful events for actions such as policy changes and account management. Policy changes can refer to anything from a Kerberos policy change to an audit policy change. I also recommend auditing successful and failed events related to the logon process and system events. System events refers to events such as booting or shutting down the system, clearing the Windows audit log, changing the system time, or attempting to use an invalid Remote Procedure Call. Some people also like to audit privilege use, but I find privilege auditing to be more useful for servers than workstations.

Next Steps

How to set audit policies in the registry

Steps for your best desktop audit

Don't rely on audit checklists

Dig Deeper on Endpoint security management tools