Continuing our look into Windows Server 2012’s new security features, today we’ll focus on a critical component: auditing.
Why audit?
Auditing is about keeping records of events for later reference. It gives you the ability to determine who did what actions to which data, and who did not. Auditing is also an often overlooked aspect of computer network security. The first goal of network security is always to prevent security compromises from occurring. A second goal is to detect incidents if they do happen, and a third is to learn from what happened to try and prevent it occurring again. Auditing is what helps you achieve the second and third goal, but only if you set it up properly first before an incident happens.
How do I start auditing in Windows Server 2012?
You can configure audit policies within a Group Policy Object (GPO) and then assign that GPO to part or all of the network using the Group Policy Management tool. In Windows Server 2012 the location of all the policies I will discuss in this article is at the following place within a Group Policy Object:
Computer configuration Policies Windows Settings Security Settings Advanced Audit Policy Configuration
Deciding to audit events is the easy choice; the harder choice is deciding what to audit. If you audit too much then the useful data becomes more difficult to find amongst the wash of event logs. The best approach is to start small, auditing just a few items, then build up additional auditing if it is truly needed. Here are three GPO settings you can start with:
Setting One: “Audit user account management” in the Account Management policy
Setting this option will write an event to the security log whenever certain edits are made to user accounts, including the creation and deletion of accounts. It will also alert you to any changes in permissions for network administration level user accounts. Combined with setting three below this is a useful way to track changes in authorization levels for all accounts and especially the admin accounts.
Setting Two: “Audit logon” in the Logon / Logoff policy
This option will write an event to the security log whenever a user logs on. For the full picture you should check the boxes to audit both successful and unsuccessful logon attempts. Large numbers of unsuccessful logon attempts can indicate the presence of an attack on your network.
Setting Three: “Audit Security Group Management” in the Account Management policy
An event can be written to the security log every time an edit is made to any security group. You should check the boxes to audit both successful and unsuccessful group management attempts. Auditing this allows you to see if someone is trying to grant themselves additional security rights without authorization to do so.
What about more advanced auditing in Server 2012?
Windows Server 2012 also provides some extremely flexible options for defining audit policies when you configure the “Global Object Access Auditing” policy within a GPO. With the Global Object Access Auditing policy you can choose to monitor not just file access success or failure but also what actions were carried out or attempted on the file – such as read, write, delete, change file permissions and so on. You can narrow down the scope of the file auditing to specific users or groups of users. This is the same flexibility of policy definition that we saw in our earlier post on Dynamic Access Control.
For example you can create a group policy, assign it to the domain in the Group Policy Management tool, and have it alert you whenever a member of the group “staff” attempts to delete files or folders without the authorization to do so. These setting are shown in the following screenshot:
Note that for the file auditing to work you also have to enable the “audit file system” setting in the Object Access policy as shown in the picture above.
So, Windows Server 2012 allows you to be very precise in the events you choose to audit and log – no longer do you have to log everything in the hope of catching, and more importantly hoping to find, the information you actually need.
What about the logs?
Auditing is most effective when the logs are reviewed on a regular basis. In a network with many servers to be checked you can configure the logs to all be forwarded to one server where you can install software to mine them for information – this is something we’ll be covering in a later blog post.
Now that you are auditing multiple items you can expect the security log to grow faster – by default the log will overwrite old events when it runs out of space. If you don’t want this to happen then right-click on the security log and choose Properties and select the option “Archive the log when full, do not overwrite events”. As long as you have enough disk space this could give you months or even years’ worth of audit log history, which can be vital when investigating a long running issue.
Is there anything else to be aware of?
As important as auditing is, it is equally important to remember one of its limitations: auditing may tell you that a user, John Doe, attempted to access restricted files in the finance department share, however all that really tells you is that someone using the account “John Doe” attempted to access those files. Whether it was in fact the real John Doe or someone else using his network account is a much harder question to answer with certainty. This is important to remember before taking action on the results of auditing. A way to reduce this limitation would be to use two-factor authentication to logon. That will make it more likely that the real owner of the account was the person who used it – especially if you use a fingerprint as one of the authentication factors.
Where can I find out more?
New Signature has years of experience configuring security on Windows Server 2008 and Server 2012 environments. Please give us a call – we would be happy to work with you to review your auditing needs and draw up an implementation plan.
