File Server Migration to Server 2012 Part 5: File Auditing

File Auditing is another one of those things that isn't very fun but it's still very important. With File Auditing, you can track who created/opened/moved/modified/deleted which file, when and from what computer they did it from. Not only is it great for knowing what's going on with your data, but it's also a key part of making sure your infrastructure is HIPAA, SOX or PCI compliant if your company calls for it.

It's important when you're thinking about auditing to cast a wide net. You're not setting this up to "catch" someone doing something wrong. You're doing this to increase visibility into the goings-on of your data; The data you've been tasked with managing. You want to audit things, not people or groups. When you audit people, you might find that they are still doing something wrong but they're not doing the wrong thing you thought they were doing. Also, if you're auditing specific people or specific groups of people, that could be looked at as discrimination from a legal standpoint. Instead, you should focus on auditing things.

Enabling File Auditing isn't difficult at all. It's a quick, 2-step process. Firstly, you'll need to enable the Audit Object Access policy. Normally, in an infrastructure where you have a domain controller, that's where you'd enable it. If you're just at home testing it in a home lab then you can enable it in the Default Domain Policy. If this is in a home lab and you don't have a domain controller then you can enable it in the Local Security Policy on the file server itself as pictured below (I'm using a machine in our test environment). Normally, in a production setting, you would make sure the file server (or servers) are in their own OU, make a separate GPO for enabling the Audit Object Access policy and link that GPO to the OU that contains the file server(s).


Secondly, you'll need to specify what folders you wish to have Auditing enabled on. For my test drive I've been working with, I've got my E:\ drive called Test Vol. On the test drive, right-click > Properties > Security tab > Advanced button on the bottom > Auditing tab. (Pictured below)


Here is where you'll specify the specifics of "who" and "what". Click the Add button.


You'll see here that I've already made some changes. The Principal is who you want to audit. You could list some specific groups or you can just audit everyone, like I've setup to do. For Type, this is where you choose if you specifically wish to audit failures or successes. I chose both since I'm casting a wide net of sorts. For Applies To, There are some options to play around with. You can look at just files, just subfolders and files, This folder/subfolders and files like I have set, etc. For Permissions, this is where you specify more specifically what you want to audit. Figure out what things you want to watch for and click OK.

You might be wondering to yourself why you need to enable Auditing in both Group Policy AND Whatever drive/share you wish to audit. I mean, why can't you just enable it and it tracks everything that happens to every item every time by every person? Because then you'd have too much information. I don't mean "TMI" in the sense of a co-worker discussing a rash he's been dealing with. If you setup Auditing to watch everything, it would generate so many log entries that it would be difficult to get back meaningful information. That's why you get a bit more specific about what you're watching for in the second step. It's really about finding a balance; Cast too big of a net and you've got a mountain of information to sift through to find anything meaninful. Cast too small of a net and you could be missing important security events.

Speaking of logs, it's important that someone actually goes through the audit logs from time to time. Setting up Auditing is great and all but without actually checking the logged events, you could be missing things until it too late. It's like installing an expensive security camera system in your home only to review footage after someone's already broken in and stolen all your stuff. If you had been periodically reviewing footage, you might have seen someone casing the place, trespassing, etc.

Your Security logs will be in Event Viewer under Windows Logs > Security. However, there are a lot of products out there that will help in security auditing. These programs still require Auditing enabled like we discussed above but they'll take that information and generate their own custom reports (and often store the logs in their own special way as well). When I first got this project, I didn't know we already had auditing, and review of the audit logs were being done by our security Network Security team. We use File System Auditor by Scriptlogic (an old version that's only compatible with Server 2k3 or XP). After a discussion with our security team, we've agreed to not reinvent the wheel and let security keep doing the security audits (a decision I was highly in favor of) and figure out upgrading that program to a more recent version later.

I'd like to dig a bit deeper into Auditing but since it's no longer a major part of this project, I've got to put it on a back burner for a while. My idea was instead of keeping tabs on all the things, we should sit down and come up with a definition of confidential or classified information and then simply audit everything about those objects. I also wanted to look more into reporting. If I can generate reports myself then that would be nice. It would also save us from being at the mercy of old, unsupported software and save some money while doing it. However, those are ideas for another time.

Comments

Popular posts from this blog

Installing CentOS 7 on a Raspberry Pi 3

Modifying the Zebra F-701 & F-402 pens

How to fix DPM Auto-Protection failures of SQL servers