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- we have a new audit policy mechanism prototyped.
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.
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.
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.
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.
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.
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 to find.
Eric
