This section also explains how auditors can access and aggregate event data from multiple servers and desktop computers. It also covers how to address storage requirements. This section provides guidelines for effective deployment of a Windows security audit policy. Deploying Windows audit policy settings in a test lab environment can help you confirm that the settings you've selected will produce the audit data that you need.
But only a carefully staged pilot and incremental deployment based on your domain and organizational unit OU structure will confirm that the audit data you generate can be monitored and meets your needs. A security audit policy must support and be an integrated aspect of an organization's overall security framework. Every organization has a unique set of data and network assets such as customer and financial data and trade secrets , physical resources such as desktop computers, portable computers, and servers , and users which can include various internal groups such as finance and marketing, and external groups such as partners, customers, and anonymous users on the website.
Not all of these assets, resources, and users justify the cost of an audit. Your task is to identify which provide the strongest justification for the focus of a security audit. An organization's domain and organizational unit OU structure provide a fundamental starting point for thinking about how to apply a security audit policy.
They likely provide a foundation of Group Policy Objects GPOs and logical grouping of resources and activities that you can use to apply the audit settings that you choose. Your domain and OU structure probably already provide logical groups of users, resources, and activities that justify the resources needed to audit them.
For information about how to integrate a security audit policy with your domain and OU structure, see Mapping security audit policy to groups of users, computers, and resources later in this document.
In addition to your domain model, determine whether your organization maintains a systematic threat model. A good threat model can help identify threats to key components in your infrastructure. Then you can apply audit settings that enhance your ability to identify and counter those threats. Including auditing in your organization's security plan also helps you budget resources to the areas where auditing can achieve the best results.
For data and resource auditing, you need to identify the most important types of data and resources such as patient records, accounting data, or marketing plans that can benefit from the closer monitoring that Windows auditing can provide. Some of your data resources might already be monitored through auditing features in products such as Microsoft SQL Server and Exchange Server.
If so, you may want to consider how Windows auditing features can enhance your existing audit strategy. As with the domain and OU structure discussed previously, security auditing should focus on your most critical resources. You also must consider how much audit data you can manage. You can record if these resources have high, medium, or low business impact; the cost to the organization if these data resources are accessed by unauthorized users; and the risks that such access can pose to the organization.
The type of access by users such as read , modify , or copy can also pose different levels of risk. Increasingly, data access and use is governed by regulations, and a breach can result in severe penalties and a loss of credibility for the organization. If regulatory compliance plays a role in how you manage your data, be sure to also document this information. Many organizations find it useful to classify the types of users they have and then base permissions on this classification.
This classification can help you identify which user activities should be the subject of security auditing and the amount of audit data that they'll generate. Organizations can create distinctions based on the type of rights and permissions that users need to do their jobs. Under the classification administrators , for example, large organizations might assign local administrator responsibilities for a single computer, for specific applications such as Exchange Server or SQL Server, or for an entire domain.
Under users , permissions and Group Policy settings can apply to all users in an organization or as few as a subset of employees in a given department. Also, if your organization is subject to regulatory requirements, user activities such as accessing medical records or financial data may need to be audited to verify that you're complying with these requirements.
To effectively audit user activity, begin by listing the different types of users in your organization, the types of data they need access to, and the data they shouldn't have access to.
Also, if external users can access your organization's data, be sure to identify them. Determine whether they're a business partner, customer, or general user; the data they have access to; and the permissions they have to access that data. The following table illustrates an analysis of users on a network. Our example contains only a single column titled "Possible auditing considerations," but you may want to create additional columns to differentiate between different types of network activity, such as logon hours and permission use.
Security and auditing requirements and audit event volume can vary considerably for different types of computers in an organization. These requirements can be based on:. The operating system version determines which auditing options are available and the volume of audit event data. For example, a web server that's accessed by external users requires different audit settings than a root certification authority CA that's never exposed to the public internet or even to regular users on the organization's network.
Many industries and locales have specific requirements for network operations and how resources are protected. In the health care and financial industries, for example, strict guidelines control who can access records and how the records are used. Many countries have strict privacy rules. To identify regulatory requirements, work with your organization's legal department and other departments responsible for these requirements.
Then consider the security configuration and auditing options that you can use to comply with these regulations and verify compliance. By using Group Policy, you can apply your security audit policy to defined groups of users, computers, and resources.
To map a security auditing policy to these defined groups in your organization, you should understand the following considerations for using Group Policy to apply security audit policy settings:. The policy settings you identify can be applied by using one or more GPOs.
Decide whether every policy setting that you select should be enforced across the organization or apply only to selected users or computers. You can then combine these audit policy settings into GPOs and link them to the appropriate Active Directory containers. However, a GPO that's linked at a lower level can overwrite inherited policies. For example, you might use a domain GPO to assign an organization-wide group of audit settings but want a certain OU to get a defined group of additional settings.
Then, a logon audit setting that's applied at the OU level will override a conflicting logon audit setting that's applied at the domain level, unless you've taken special steps to apply Group Policy loopback processing.
Audit policies are computer policies. 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.
You're now at a point where the basic auditing technique is the same for both domain controllers and non-domain controllers. 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. 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.
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.
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:. 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. You can now audit these operation details under Windows Server You can use operation-based auditing to audit files or folders enabling you to configure logging of both the file access details and the operations on those files e. Operation-based audits are categorized as object audits in the security log.
They are easily distinguishable by their unique event ID. The event ID is These events are generated the first time the operation is invoked by the system. They only apply to files and folders, not other types of Active Directory objects.
You must first enable Audit Object Access to enable operation-based auditing. Refer to the Defining and Auditing Policies section earlier in the chapter. In this section, you'll learn how to apply and modify the audit policy settings.
In this article, we will show you how to configure security audit policies in Windows using the example of configuring file and folder access auditing.
You can use the Group Policy console to configure audit policies on Windows. You can use the Local Group Policy Editor console gpedit. The following event categories are available in it:.
0コメント