Windows Security Logging and Other Esoterica

thoughts from the Windows auditing team

Keeping the noise down in your security log

Keeping the noise down in your security log

  • Comments 16

[2011-04-11] This post was updated to indicate the interaction between these recommendations and the granular audit policy settings which are available in Windows Vista and subsequent releases. EF

I commonly hear the complaint that "there's too much noise in the security log".  As I mentioned, that's one of the key things we're working on for Longhorn Windows Vista & Windows Server 2008 and subsequent releases- we have a new audit policy mechanism prototyped implemented, called "Granular Audit Policy"More information on granular audit policy is available here.

But here are some tips to keep your noise level down while keeping useful information in your log.

1. Turn off the security option "Audit the access of global system objects".  (This link will probably break at some point as the guys who run Microsoft.com frequently change page URLs- so if it's broken, please use MSN Search or Google to find more information on this setting.)

There are many kinds of objects that Windows uses internally.  While you're probably familiar with files and registry keys, and perhaps even processes, you might not be aware of things like mutexes and semaphores.  These objects are not persisted- they're created during or after boot, and go away when a program closes or when the system is shut down.  These objects are most commonly used by the OS and by programs to synchronize access with each other.

These objects all have permissions, implemented as DACLs (just like any other object).  They can also have SACLs.  Most of these objects do not have names.  They are only referred to by handles (32-bit numbers).  Unless you are running in the same process and know the handle, you can't touch the object.

A few of these objects are created with names.  The purpose of this is so that another thread or process can refer to the object by name, without knowing the handle.

This setting causes objects of this type which are created with names, to be assigned a SACL at creation (and therefore subject to object access auditing).  Having this setting is required for Common Criteria evaluation.  The idea is that if an object is created with a name, and if the name is discoverable, and if the ACL on the object is insufficient, then potentially an attacker could access these objects and cause other programs to malfunction.

However in practice there is a problem.  Any program can create a named object.  The programmer selects the name.  The name of the object might convey meaning, but often only is meaningful to the programmer.  And there is no central reference, even just to the Windows-created named objects, of what the objects are and what they're used for, and what "normal" accesses to these objects look like.

So the bottom line is that without the source code, typically you'll have no idea what the event means, or if the access recorded in the event is benign or malicious.

So just don't use this setting.

[2011-04-11] Note that this setting is not part of either legacy audit policy or granular audit policy; it's implemented as a registry key called "AuditBaseObjects".  As such, this recommendation does not change due to the addition of granular audit policy in Vista and subsequent releases.  However, we did some tuning work on the SACL that AuditBaseObjects causes to be applied, and this should be less noisy in releases since Vista than in earlier releases.

2. Turn off the security option "Audit the use of the backup and restore privilege".

As mentioned in an earlier post, some privileges are not audited by default, because they're too noisy.  You can turn them on with the registry key "FullPrivilegeAuditing", usually via setting this group policy setting.

Anyway, if you are really wondering how these privileges work, here's the lowdown.  If you fail an access check for "read" on an object, but you have the backup privilege enabled in your token (and for some objects like files, asserted backup when opening the object handle), then you will be granted read anyway due to the fact that you have the backup privilege.  The restore privilege works the same way, only for writes.  As a side note the restore privilege also implies WRITE_DAC and WRITE_OWNER, and can be used to set the owner of an object to an arbitrary user account- normally you can only take ownership.

The problem is, nobody backs up a single file- they back up 20,000 or 50,000 files at a time.  So auditing for backup would cause an enormous load on the security log, and on the poor soul who has to read the security log.  So we disable by default.

Now Common Criteria requires that these be auditable, because they can be used to bypass access controls.  So we added a switch to turn these on.  We still don't recommend that you actually use the setting.  However, you have to make your own value judgment.

[2011-04-11] Note that this setting is not part of either legacy audit policy or granular audit policy; it's implemented as a registry key called "FullPrivilegeAuditing". As such, this recommendation does not change due to the addition of granular audit policy in Vista and subsequent releases.

3. Remove the SACL on the Active Directory object "CN=Server,CN=System,DC=contoso,DC=com" (edit to use your actual domain name instead of contoso.com, which is our handy example domain).

This is the SAM Server object, which is responsible for object access events for the various SAM object types.  If you remove this one SACL, you'll eliminate the SAM object access events.  More information can be found here.

[2011-04-11] Note that this setting is not part of either legacy audit policy or granular audit policy; it's implemented as a SACL. As such, this recommendation does not change due to the addition of granular audit policy in Vista and subsequent releases.  However, granular audit policy also breaks down object access audit into object type subcategories (e.g. File System, Registry, etc.), and so you could effectively accomplish the same thing with Windows Server 2008 or later domain controllers, by ensuring that you use granular audit policy on your domain controllers and that you do not enable the "SAM" subcategory of the "Object Access" audit policy category.

4. Don't enable "Privilege Use" auditing.

Many of our privileges are overloaded, and many of them are used quite frequently.  For example, what do you think it means when you see that somebody used SeShutdownPrivilege?  That they shut the system down?  No, it might mean that they enabled hibernation support.  Or that they set the power management settings.  Or that they aborted a shutdown.  Who knows?  There's not enough information in the event.

I go deliver the smack-down when I find stuff like this, but I'm only one guy, and I don't have a lot of authority.  So sometimes I can get folks to change their evil ways, but sometimes not.

The bottom line is, that you don't really know what the privilege was used for.  And you don't know what the "privileged service" was that was called, in that event.  And we don't tell you, because we don't have a central reference.  And we don't have a reference of what "normal" privilege use looks like.  So the bottom line is that you're not likely to understand what a particular privilege use audit means, or whether it's normal or not, so just don't enable it.

[2011-04-11] In Windows Vista, the "Privilege Use" category was broken down into 3 subcategories as part of the granular audit policy effort:

Privilege Use

  • Sensitive Privilege Use
  • Non Sensitive Privilege Use
  • Other Privilege Use Events 

The "sensitive privilege use" subcategory was used for privileges where:

  • Posession of the privilege allows a malicious user to self-elevate to an administrator, e.g. SeDebugPrivilege allows you to OpenProcess on processes running as LocalSystem and inject threads
  • Posession of the privilege allows a malicious user to lay down code that could inadvertently cause another component or user of the system to elevate the malicious user to administrator, e.g. SeRestorePrivilege allows changes to files regardless of permissions, and
  • Posession of the privilege allows a malicious user to tamper with the system in some way which compromises the system or the integrity of the audit trail, e.g. SeSecurityPrivilege allows tampering with audit policy

My general recommendation doesn't change with granular audit policy- don't enable privilege use auditing- as the value-to-cost ratio is too low.  However, this change might allow you to enable a little bit less auditing (for example, only "sensitive privilege use"), which might result in less audit volume than if the entire category were enabled, depending on the strictness of your requirement.

Also note that recommendation #2 still applies here - "sensitive privilege use" includes the backup and restore privileges, and will be just as noisy as ever if enabled at the same time that sensitive privilege use (or the entire category) is enabled.

5. Don't enable "failure" auditing, unless you have a plan on what to do when you see one (that doesn't involve emailing me ;-) and you are actually spending time on a regular basis following up on these events.

You might or might not realize, that auditing in general is a potential denial-of-service attack on the system.  Auditing consumes system resources (CPU & disk i/o and disk space) to record system and user activity.  Success auditing records activity of authenticated users performing actions which they've been authorized to perform.  This somewhat limits the attack, since you know who they are, and you've allowed them to do whatever it is that you're auditing.  If they try to abuse the system by opening the audited file a million times, you can go fire them.

Failure auditing allows unauthenticated or unauthorized users to consume resources.  In the worst case, a logon failure event, a remote user with no credentials can cause consumption of system resources.

Now many failures are normal.  For instance, it's absolutely normal to see a small percentage of logon failures, especially if you're using strong passwords, since people make typing errors.  Likewise, it's normal to see Explorer attempt to open a file with full control access, when the user only has read- Explorer likes to know how much access you have, and it finds it out by trying to open with maximum permissions.  Nothing is broken and no error message is generally seen; if the access check fails then Explorer will note that you don't have write access and will attempt to open the file with only read access.  Explorer then will make adjustments to the UI based on the failure- for instance, if you go to the permissions dialog it will tell you that it's disabling the "apply" and "advanced" buttons since you don't have permission to change permissions.

The bottom line is, that for failure auditing to be effective, you need a baseline against which to compare failure events.  And you have to build that yourself.

So just don't enable this unless you have to.

[2011-04-11] Note that this recommendation doesn't pertain to audit policy, but rather to SACL policy, so is not affected by the audit policy changes in Vista and subsequent releases.

6. Tune your SACLs.

If you have, or intend to set, SACLs on files, registry keys, or AD objects, then you need to (1) think about what activities you're trying to record and set the minimum SACLs necessary to catch only those activities, and (2) review your logs after you set the SACLs, to see if you need to tune them.

Recently I set up auditing templates for the Security Configuration Wizard in Windows Server 2003 Service Pack 1.  I wanted a template that would be useful, would improve security, and would not result in noisy logs.  So first I performed a simple threat model exercise- what threats could audit help mitigate?

One answer was "tampering with system files".

So I thought about what tampering would look like in the security event log- it would look like writes to system executables or configuration.

Next, I calaloged all the directories in \Windows.  I identified the contents of each directory by executable, configuration, data, or some combination of these.

For executables and configuration, I created a security template which set a SACL for Everyone for these directories & files, for any "write" accesses but not for read accesses.

I applied the template to my own machine, ran for a week, and then looked at my log.  I found that I had hit pretty close to the mark, but that there were still a few file objects which appeared over and over in the log, so I adjusted the template to exclude those objects, re-applied, and ran again.

After a couple of iterations I was down to a handful of events per day.  Not bad for setting hundreds of SACLs.

So we identified some production machines in our IT department, hosted the templates, and reviewed the logs.  After a couple more iterations we had reduced the noise again to a few events per day, and then we added the template to SCW.

This process works really well- it forces you to think about what you're trying to accomplish, and what the side effects are, and to make the necessary trade-offs.  I highly recommend it.

 

Well, that's all for now.  I hope this is helpful to you guys.  I'll probably have a real writer turn this into some kind of formal communication, but I wanted to get it out there for Google Bing to find.

Eric

[2011-04-11] Note that this recommendation doesn't pertain to audit policy, but rather to SACL policy, so is not affected by the audit policy changes in Vista and subsequent releases.  However, granular audit policy also breaks down object access audit into object type subcategories (e.g. File System, Registry, etc.), and so you don't have to tune registry SACLs to enable effective file system access auditing, for instance.

Comments
Page 2 of 2 (16 items) 12
Leave a Comment
  • Please add 6 and 5 and type the answer here:
  • Post