Banking

SolutionBase: Creating a Windows Server 2003 audit policy

How secure is your network? Are users or hackers trying to access data that they shouldn't? Do you even know? You stand a better chance of finding out by using an audit policy on your server. Here's how it works.

Security is often one of the top concerns for network administrators. After all, it's not uncommon for networks to contain confidential data such as employee records or information on new products. Fortunately, there are countless security mechanisms that you can put in place to help secure such data. But how can you be sure that your data is really secure? One way is by implementing an audit policy on your servers. In this Daily Drill Down, I'll discuss the issues involved in establishing an audit policy in a Windows Server 2003 environment.

What is auditing?

In its simplest form, auditing is nothing more than creating a record of events. These events can be performed by users or by the servers themselves. An example of such an event might be a user logging in to the network. If you wanted to audit logins, you could actually create a record of every time that each user logged in to the network. All of the events you monitor are documented in Windows Server 2003's security log.

Okay, so auditing provides a method for documenting system and user events, but how can you make the security log useful? After all, if you audit every user and every system event, it's possible that the server will log hundreds of events every minute. I've lost count of the number of times that I've seen administrators log every single event in the name of good security. In such situations, the security log can quickly fill up, meaning that no more events will be logged until the log has been cleared out.

Excessive logging can also cause performance problems for the server since logging consumes disk and processor time. Another downside to logging every event is that the logs cease to be meaningful. If you suspect that a security breach may have occurred, locating a record of it can be like looking for the proverbial needle in a haystack.

As you can imagine, a better process is to audit only meaningful events rather than every single event in the entire system. After all, who cares if Fred in Accounting created a new spreadsheet this morning? Instead, you should look for and create logs of things that could potentially damage your network or its data, such as someone being granted administrative privileges or files being deleted from an important directory. In the sections that follow, I'll show you some guidelines you can follow to create an effective audit policy.

Success or failure

Before you audit anything, you should understand a little bit about how the auditing process works. When you audit an event, you can audit it by success, failure, or both. For example, suppose that you wanted to audit logins to the network. Depending on the size of your network, success audits may be overkill because they would create a security log entry every time that someone logged in. As alluded to above, this would create log files that grow quickly and become cumbersome to work with.

A more effective technique might be to use a failure audit for network logins. A failure audit would create a security log entry only if a user tried to log in and was unsuccessful. You could then review the audit log to see who had trouble logging in to the network. If a user's name appears only once in the security log, then you could probably assume that the user simply typed their password incorrectly. If you discover that a particular user has tried to log in unsuccessfully a number of times--especially after business hours--then you may want to investigate the invalid login as a possible hack attempt.

If you make such a discovery, you can take steps to counteract the hack attempt. These steps might include things like creating a policy that disables user accounts after three bad login attempts within a few minutes. If the hack attempts continue, you might look at what time the attempts are made each night and try to catch the hacker red-handed.

Enabling auditing

Now that you have a basic idea of what auditing is and how it works, it's time to begin building an audit policy. I'll start by showing you how to audit an event. Once I've done so, I'll explain which events that I recommend auditing.

As I mentioned earlier, auditing is configured through the use of an audit policy. You can set an audit policy to be applied to domain controllers, member servers, stand-alone servers, or workstations. If you apply a non-local audit policy to a domain controller, all other domain controllers within the domain will share that audit policy. I strongly recommend auditing all domain controllers because they are so crucial to your organization's security. It's also not a bad idea to audit member servers or stand-alone servers too if they contain any sensitive or confidential data. I don't recommend auditing Windows XP Professional workstations, unless you have a very specific reason for doing so. It's simply too time-consuming and inconvenient to constantly review the audit logs on every single workstation.

Before you begin to build an audit policy, I should point out that to do so you must have the Manage Auditing And Security Log user right. The Administrator account has this right by default, but if you want a nonadministrator to manage the auditing, you'll have to grant them the appropriate permissions. In actuality, having a nonadministrator to do the auditing isn't a bad idea. You can remove the Manage Auditing And Security Log user right from the administrator's group to ensure that only one person has rights to the audit log. This is one way to keep administrators honest, since they won't be able to clear the security log after a misdeed.

The process of enabling auditing is similar for domain controllers and non-domain controllers. The biggest difference is that you use a different tool to get the job done. To set up an audit policy for your domain controllers, open the Active Directory Users And Computers console and navigate through the tree to Domain Controllers. Right-click Domain Controllers and select the Properties command from the resulting context menu.

When you do, you'll see the Domain Controllers properties sheet. Now, go to the Group Policy tab, select the group policy that you want to audit, click Edit, and Windows will load the Group Policy console. Navigate through the group policy console to Computer Configuration | Windows Settings | Security Settings | Local Policies | Audit Policy, as shown in Figure A. You're now at a point where the basic auditing technique is the same for both domain controllers and non-domain controllers.

Figure A

Navigate to Computer Configuration | Windows Settings | Security Settings | Local Policies | Audit Policy.

To set up auditing for a non-domain controller, open the Local Security Policy console and navigate through the tree structure to Security Settings | Local Policies | Audit Policy. You can see an example of this screen in Figure B.

To set up auditing for a nondomain controller, open the Local Security Policy console and navigate to Security Settings | Local Policies | Audit Policy.

From this point, the technique is the same whether you're on a domain controller or not. Let's audit an event. For demonstration purposes, we'll audit failed login attempts. As you can see in Figures A and B, Windows lists several different types of events that can be audited. One of these events is Audit Account Logon Events.

To audit a logon failure, right-click Audit Logon Events and select the Properties from the resulting context menu. When you do, you'll see a dialog box that will allow you to audit the events. The dialog box will vary slightly depending on whether or not you're auditing a domain controller.

If you're auditing a domain controller, you must select the Define These Policy Settings check box before you'll be able to audit an event. This check box doesn't exist when auditing nondomain controllers. At any rate, you'll now be able to audit an event success, failure, or both. For the purpose of auditing login failures, select the Failure check box, as shown in Figure C, and click OK.

Figure C

You can audit the success or failure of an event by simply selecting a check box.

Once you've set up the audit policy, you must apply it. To do so, you must either type a command at the command prompt, reboot your server, or wait until the next propagation cycle, which is usually every eight hours. If you decide that typing the command is the easiest method, open a command prompt window, type GPUPDATE /target:computer and press [Enter].

What needs to be audited?

Now that you know how auditing works, the first question that you should ask yourself is what really needs to be audited? As I mentioned, I always recommend auditing domain controllers, and if the situation applies, member servers and stand-alone servers. But what should you audit on those servers? I recommend that you audit the following items:

  • Logon failures
  • Policy changes
  • Privilege use
  • Account management
  • Any directories that are confidential or sensitive (a file-level audit)

Before I get into file-level auditing, there are a couple of helpful hints that I should point out. First, it's a good idea to audit just about everything that members of the Administrator's group do. The reason for this is that a hacker will typically try to gain administrative access before attacking your system. Therefore, such an attack would likely show up as an administrative action.

Another tip is that when auditing users, you should audit the Everyone group instead of the Users group. The reason for this is that the Users group includes only authenticated users. It doesn't cover anonymous users who may have slipped through your Internet firewall. The Everyone group, on the other hand, covers all users whether or not they are authenticated.

File-level auditing

Before you can audit a file, directory, or other object, you must enable Object Access auditing by using the method that I demonstrated earlier. Once you've enabled object auditing, go into Windows Explorer and navigate to the object that you want to audit. Right-click the object and select the Properties command from the resulting context menu.

When you see the object's properties sheet, navigate to the Security tab and click the Advanced button. You'll now see the Access Control Settings For dialog box. Next, select the Auditing tab, click the Add button, and select the users or groups that you want to audit. Click OK to continue. You'll now see a long list of auditable actions related to the object. You can perform a success and/or failure audit on any of these objects by selecting the appropriate check boxes. Click OK to enable the auditing.

Review the security logs

One of the most important things that you need to know about auditing is that the simple act of auditing won't alert you to a security breach or an attempted break-in. It's up to you to read and understand what the security log entries mean. I recommend reading the security log the first thing in the morning, right after you change the backup tape. By doing so, you'll get into a routine, and you'll always be aware of your network's security.

0 comments

Editor's Picks