Condividi tramite

Keeping the noise down in your security log

  • Articolo

[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

  • Anonymous
    January 11, 2005
    The comment has been removed

  • Anonymous
    January 11, 2005
    ACS currently does not have filtering on the agent, however that is being considered prior to RTM.

    The reason that we haven't implemented that is that it is a management feature, not a security feature. From a security perspective we want all events so that we can detect gaps in the event stream- there's no way for us to tell the difference at the collector whether the forwarder filtered an event, or whether the admin tampered with the log and deleted an event.

    Two other mitigating factors:
    1) If you don't want an event, don't generate it- use audit policy. Yes, I know that there are limits to this.
    2) ACS uses a streaming compression algorithm (SLDC), which compresses extremely well. We've seen event streams which take only 11 bytes per event on the wire, including protocol overhead (YMMV).

    For those of you unfamiliar with ACS, we'll publish news on it shortly. It's in a private beta state right now, I'll blog an entry when we open up the beta.

    Thanks,
    Eric

  • Anonymous
    January 15, 2005
    I think something else that would be useful would be an event viewer that was more flexible in terms of what you want to view. Ability to filter out specific events and ability to have it highlight certain events you are concerned about or even pull them into a "watch these" separate display panel.

    Personally I like a lot of information because you never know what little thing may make you realize something isn't right. However, the current state of event viewer is sort of like dir compared to explorer when looking at file listings only event viewer isn't even as flexible as dir.

    joe

  • Anonymous
    January 16, 2005
    Thanks for the feedback, Joe. I've pretty much said the same thing to the event viewer team; I'll pass along your comments!

    Eric

  • Anonymous
    January 24, 2005
    I turn on "failure" logging, when trying to understand what a app is doing when its not working. Just did it today trying to get SQL Report Serivces to run. Its a pain to install it on a nonstandard system, especially when you run IIS in a very secure mode.

  • Anonymous
    February 04, 2005
    Failure logging will probably always be yucky. We're working on some changes for longhorn that should make success auditing much more useful and less voluminous for object access, but all I can do for failures is log them. It's pretty common for apps to request more privilege than they need, trap the failure case so they can re-attempt open with less privilege, and trash my log.

    I actually am having a discussion now with several teams on whether there is anything we think we can do. However no brainstorms yet.

    Eric

  • Anonymous
    March 11, 2005
    Eric posted an interesting article on how to cut down the noise of the security log in Windows Server. He points out a lot of interesting tidbits. I don't agree with them all, but that's just me. I'd rather wrestle with a little more noise on a hardened server and have to MUCH logs rather than not enough when doing a forensic audit. Of course, most people aren't even LOOKING at their logs, so its a moot point. Overall though, a very useful article on how to cut down the noise in your security logs on some areas of the system which are not that beneficial for you. Worth checking out. Happy reading....

  • Anonymous
    September 01, 2005
    Here is the pattern you should expect to see when creating a local account.  For domain accounts,...

  • Anonymous
    April 17, 2007
    Deşi subiectul este destul de sensibil, risc. Mă frămîntă de vreo cîteva zile unele lucruri descoperite

  • Anonymous
    September 04, 2008
    I've written before on noise reduction in the Windows security event log. I've also written to describe

  • Anonymous
    September 22, 2010
    Hi Eric, Regarding point 4 "Dont enable Privilege Use Auditing"; I understand that this setting can fill up the Security event viewer log and lead to degraded performance. However my QSA insists on turning this on (to find out elevated privilege information). Is this the only way to find elevated privileges in eventviewer? Or shall I ask: what's the best way to find instances of elevated privileges in EventViewer? Regards, Max (name changed to protect identity)

  • Anonymous
    October 12, 2010
    Hi Max, In Vista+, you can use the auditpol.exe tool to be a little bit more granular, there are audit policy subcategories for "sensitive" and "non-sensitive" privilege use.  "Sensitive" privileges are those that could lead to tampering or elevation of privilege. Eric

  • Anonymous
    April 08, 2011
    Can you point us to an updated version of these ideas taking into account the categorical granularity enhancements in Server 2008 R2? Our noise is rising and we want to ensure we are tuning to allow the greatest degree of actionable information in the Security Logs. Thank you much for this information.

  • Anonymous
    April 11, 2011
    Done!