Security, et al

Windows audit policy has evolved for 20 years and many people at Microsoft have come on gone.  The result is what one Microsoftie describes as “good”. See: http://blogs.technet.com/b/askds/archive/2011/03/11/getting-the-effective-audit-policy-in-windows-7-and-2008-r2.aspx

If you aren’t careful you can easily end up thinking your systems are auditing the right security events when in fact they are not.  In this article I show you how to avoid these problems.

The original audit policy in Windows NT was 7 audit policies corresponding to 7 categories in the Windows security log.  Along came Windows 2000 with Active Directory and that increased to 9.  You configured those settings in group policy under Computer Configuration\Windows Settings\Security Settings\Local Policy\Audit Policy.

Easy.

Then with Windows 2008, Microsoft and apparently more specifically, Eric Fitzgerald, then security log czar at Microsoft, made a LOT of changes to the security log in a project called Crimson. 

All security log event IDs changed from 3 digits to 4.  Some events were split into multiple new ones, other legacy events were merged into a single new event ID. New categories were added for new security events for the Windows firewall and other features. To handle the new events and to respond to customer pressure to improve the granularity of audit policy, each of the 9 audit categories gained multiple new subcategories.  Microsoft should have just done away with the original 9 but probably didn’t for backward compatibility?  It would have saved untold confusion that exists till this day and the arrangement of the subcategories in to the legacy 9 categories does not make sense.  (e.g. what are IPsec events doing in the Logon/Logoff category?). 

Anyway you could supposedly configure Windows using either the top 9 audit categories or the new subcategories.  But no one would want to do that because the new subcategories for the Windows firewall are scattered through the original 9 categories and are extremely noisy making almost everyone want to disable them.  You can only pick and choose between subcategories if you tell Windows to ignore the legacy 9.  In Windows 2008 there was no way to configure subcategories from group policy; you had to use the auditpol command on each system. 

With Windows 2008 R2 Microsoft added Advanced Audit Policy Configuration to a completely different place in Group Policy and put the “Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings” under Security Options.

Now, as long as you know to ignore the legacy 9 categories, enabled the “Audit: Force subcategory…” option and configure your Advanced Audit Policy Configuration you can safely use to group policy to centrally configure audit policy across your Win2008+ systems.  By the way you can use the same GPO to manage audit policy on Win2003 and XP systems.  They will ignore the new subcategories and that security option and just look at what you configure on the legacy 9 categories. 

But Microsoft never finished adjusting other areas of Windows policy management to fully support the new subcategories.  This means that policy reporting tools you depend on like Group Policy Results Wizard may very well lie.

Also, unlike most other security settings, local administrators can use auditpol to temporarily override the audit policy you push down from group policy.  You heard me right.  Just open a command prompt and change audit policy with auditpol and you can disable any subcategories you like until the next time group policy refreshes.  (By the way, on laptops disconnected from the domain, this does NOT take affect by running gpupdate or rebooting.  I just tested it from my hotel.  The policy reverts to what it should be only once you re-connect to the domain.)

This is really sad because in order to enforce accountability over admins, we need audit log integrity.  What can you do?  Continue to monitor for 4719 (audit policy change) and 1102 (audit log cleared).  I always like to say, “While admins can cover up their tracks, they can’t cover up the fact they covered up their tracks.”

Where does all of this leave us?  Here are my:

Best Practices/Commandments for Win2008R2/Win7 Audit Policy Configuration:

1. Do not use Local Security Policy 
2. Do not use auditpol /set
3. Use group policy objects in AD to configure audit policy
4. Always enable “Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings” and, for Win2008R2+ systems, ignore the 9 legacy audit categories.
5. Configure all of the advanced audit policy subcategories even if it is just to explicitly disable them
6. Do not use Local Security Policy, Group Policy Results Wizard, RSOP or gpresults to verify what your true audit policy is
7. Use only “auditpol /get /category:*” to verify what your true audit policy is on a given system
8. Monitor for 4719 where user is not the system itself.  This indicates someone is temporarily overriding your official audit policy defined in AD GPOs.  Terminate them!  Seriously though, it is indicative of something bad.

Hope this helps and I want to thank SolarWinds Log & Event Manager for sponsoring this article.