Auditing is a way to gather and keep track of
activity on the network, devices, and entire systems. By default,
Windows Server 2008 R2 enables some auditing, whereas many other
auditing functions must be manually turned on. This allows for easy
customization of the features the system should have monitored.
Auditing is typically used for
identifying security breaches or suspicious activity. However, auditing
is also important to gain insight into how the network, network
devices, and systems are accessed. Windows Server 2008 greatly expanded
auditing as compared with previous versions of Windows. As it pertains
to Windows Server 2008 R2, auditing can be used to monitor successful
and unsuccessful events on the system. Windows Server 2008 R2 auditing
policies must first be enabled before activity can be monitored.
Audit Policies
Audit policies are the basis
for auditing events on a Windows Server 2008 R2 system. Depending on the
policies set, auditing might require a substantial amount of server
resources in addition to those resources supporting the server’s
functionality. Otherwise, it could potentially slow server performance.
Also, collecting lots of information is only as good as the evaluation
of the audit logs. In other words, if a lot of information is captured
and a significant amount of effort is required to evaluate those audit
logs, the whole purpose of auditing is not as effective. As a result,
it’s important to take the time to properly plan how the system will be
audited. This allows the administrator to determine what needs to be
audited, and why, without creating an abundance of overhead.
Audit policies can track
successful or unsuccessful event activity in a Windows Server 2008 R2
environment. These policies can audit the success and failure of events.
The policies that can be monitored consist of the following:
Audit account logon events—
Each time a user attempts to log on, the successful or unsuccessful
event can be recorded. Failed logon attempts can include logon failures
for unknown user accounts, time restriction violations, expired user
accounts, insufficient rights for the user to log on locally, expired
account passwords, and locked-out accounts.
Audit account management— When an account is changed, an event can be logged and later examined.
Audit directory service access—
Any time a user attempts to access an Active Directory object that has
its own system access control list (SACL), the event is logged.
Audit logon events— Logons over the network or by services are logged.
Audit object access— The object access policy logs an event when a user attempts to access a resource (for example, a printer or shared folder).
Audit policy change— Each time an attempt to change a policy (user rights, account audit policies, trust policies) is made, the event is recorded.
Audit privilege use—
Privileged use is a security setting and can include a user employing a
user right, changing the system time, and more. Successful or
unsuccessful attempts can be logged.
Audit process tracking—
An event can be logged for each program or process that a user launches
while accessing a system. This information can be very detailed and
take a significant amount of resources.
Audit system events— The system events policy logs specific system events such as a computer restart or shutdown.
The audit policies can be
enabled or disabled through the local system policy, domain controller
security policy, or Group Policy Objects. Audit policies are located
within the Computer Configuration\Policies\Windows Settings\Security
Settings\Local Policies\Audit Policy folder of the Group Policy
Management Editor, as shown in Figure 1.
For the audit policies, the recommended settings are given in Table 1. These should be set on the Default Domain and Default Domain Controller GPOs. By default, all the policies are Not Defined. Figure 1 shows the recommended settings.
Table 1. Matching Audit Policies Recommended Settings
| Audit Policy | Recommended Setting |
|---|
| Audit account logon events | Success and Failure |
| Audit account management | Success and Failure |
| Audit directory service access | Success |
| Audit logon events | Success and Failure |
| Audit object access | Not Defined |
| Audit policy change | Success |
| Audit privilege use | Not Defined |
| Audit process tracking | Success |
| Audit system events | Success |
The recommended settings
are designed to address specific threats. These threats are primarily
password attacks and misuse of privilege. Table 2 matches the threats to the specific audit policies.
Table 2. Matching Specific Threats to Audit Policy Recommended Settings
| Threat Addressed | Audit Policy |
|---|
| Random password attacks | Audit account logon events (failures) |
| | Audit logon events (failures) |
| Stolen password attacks | Audit account logon events (successes) |
| | Audit logon events (successes) |
| Misuse of privileges | Audit account management |
| | Audit directory service access |
| | Audit policy change |
| | Audit process tracking |
| | Audit system events |
These recommended
settings are sufficient for the majority of organizations. However, they
can generate a heavy volume of events in a large organization. Or,
there might be a subset of security events that an organization needs to
track. In those cases, the next section discusses how to fine-tune the
audit policy using audit policy subcategories.
