Monday, 26 September 2011


Security Auditing
Performance is not the only thing that it’s important to monitor in Windows Server 2003. In today’s business environment, perhaps even more vital than ensuring top performance is the ability to ensure that sensitive data is kept secure. Security auditing allows you to track access to and modifications of objects, files or folders and to determine who has logged on (or attempted to do so) and when.
Security events are logged in the Security log, accessible by administrators via the Event Viewer. An audit entry can be either a Success or a Failure event in the Security log. A list of audit entries that describes the life span of an object, file or a folder is referred to as an Audit Trail. The primary types of events that you can choose to audit include the following:
·    Computer logons and logoffs.
·    System events (when a computer shuts down or reboots, or something happens that affects system security, such as the audit log being cleared, system time is changed, or an invalid procedure call port is used to try to impersonate a client)
·    User and computer account management tasks (such as the creation of accounts or changes to account status or permissions).
·    Access to files, folders and objects.
Configuring security auditing will help you to track potential security issues and provide evidence in relation to security breaches. It is best practice to create an Audit Plan before you enable auditing on your system. The audit plan will detail the purpose and objectives of the audit. The audit plan should contain the following:
·    The type of information you want to audit
·    How much time you have to review audit logs
·    The resources you have for collecting and storing audit logs (disk space, memory and processor usage)
·    The intended scope of the audit
You’ll need to ask yourself some questions as you prepare the audit plan. Is the purpose of the audit plan is to prevent security breaches from unauthorized sources? If so, you need to enable the Audit Failure events on logons and collect information on it. Is the objective of the auditing is to get a snapshot of the organization’s activities for forensic purposes? In that case, you need to enable both success and failure events to collect data on all applications.
It is important to remember that the audit trail information can result in a very large amount of data if the both success and failure audits are enabled. Too wide a scope for the audit can also make it difficult for you to find the information you’re looking for within a huge file that records thousands of events.
Defining and Modifying Auditing Policies for Event Categories
The audit policy has to be configured before you can log any audit information on access to files, folders and objects. You can define audit policies for any of the following:
·    Local computer
·    Domain controller
·    Domain
·    Organization unit.
The Audit Account Logon Events and Audit Logon Events items are enabled for auditing by default in Windows Server 2003. By default, object access is not enabled. You can view the security audit entries under the Security section of the Event Viewer.

Policies for the Local Computer
Let’s learn how to define an audit policy on a local computer. The local audit policy dictates the audit procedures on the local machine. It does not dictate the audit policy for the rest of the network computers. Exercise 9.02 walks you through the steps required to enable the auditing policy on the local computer. You need to have administrator access to perform any of the auditing policy changes.

No comments:

Post a Comment