The Top 5 Security Settings That Should Be Audited

When we talk of auditing in this article, we mean examining and reviewing the current configuration of our system's security. Auditing in the context of Windows security also means that these same security settings can "audit" actions by users or programs and generate "audit trails", which are essentially entries in the event logs. Auditing everything via event logging generates so much data in the log files that searching for the actual problem or culprit can become virtually impossible. Disk space is not usually a problem these days with the affordability of storage, but it still makes sense to rotate logs rather than generate enormous log files.

Considering these things, we need to select the important items that should be logged so that they can be used to ascertain what has happened when there is a security problem. We audit these settings now, and ensure they are configured correctly, enabling more detailed future audits and investigations. So, what are the top five security settings that should be audited?

OK, so this is not technically a setting, but it's an important item to audit--frequently. For Windows Server 2000, 2003, and 2008 that are members of a domain, check that only those accounts that really need to be are in the Enterprise Admins, Domain Admins, and Schema Admins groups. Try to only have domain groups as members of local administrative groups, not individual accounts.

What if there was a security breach yesterday, you look at the Event Viewer and discover that all of yesterday's security log events are gone? Audit all your system's Security Event Log properties and ensure that log size is adequate for the amount of events on your system, and that events are not overwritten too frequently.

Sometimes I've found that Active Directory or domain security was set to write events for failed AD logon attempts, but a local member server or local system policy had not been configured. Security event auditing for each server needs to be checked. Usually in an Active Directory environment policy would be enforced on member servers, but you should always check each server to verify that items like failed logon attempts are being recorded.

The Account Lockout policy defines what happens when users fail to provide the correct password, how long accounts are locked, how many failed attempts cause the account to be locked, and how long the failed attempts are remembered. These settings should align with the needs of your security policy as well as your user base and help desk requirements.

The password policy settings include options for how often users must change passwords, what the minimum password length is, how many passwords are remembered by the system, how complex passwords must be, and how the passwords are stored. These settings should be in line with your security needs, your security policy, and be enforced & in place on all your systems.

We want to set user accounts of any type according to the "principle of least privilege"--no more rights or privileges should be assigned or granted than the minimum needed to do a particular job or function. Users (or even administrators) may think they need rights & privileges that they don't need. Settings for password strength and account lockout are always among the top settings to verify in a security audit. A strong security policy is only as good as its implementation.