Security, et al

Randy's Blog on Infosec and Other Stuff Follow @randyfsmith

Using Dynamic Audit Policy to Detect Unauthorized File Access

Tue, 15 Oct 2013 13:43:49 GMT

This article was first published in EventTracker’s EventSource Newsletter: http://www.eventtracker.com/newsletters/using-dynamic-audit-policy-to-detect-unauthorized-file-access/

One thing I always wished you could do in Windows auditing was mandate that access to an object be audited if the user was NOT a member of a specified group. Why? Well sometimes you have data that you know a given group of people will be accessing and for that activity you have no need of an audit trail.

Let’s just say you know that members of the Engineering group will be accessing your Transmogrifier project folder and you do NOT need an audit trail for when they do. But this is very sensitive data and you DO need to know if anyone else looks at Transmogrifier.

In the old days there was no way to configure Windows audit policy with that kind of negative Boolean or exclusive criteria. With Windows 2008/7 and before you could only enable auditing based on if someone was in a group not the opposite.

Windows Server 2012 gives you a new way to control audit policy on files. You can create a dynamic policies based on attributes of the file and user. (By the way, you get the same new dynamic capabilities for permissions, too).

Here’s a screen shot of audit policy for a file in Windows 7.

Now compare that to Windows Server 2012.

The same audit policy is defined but look at the “Add a condition” section. This allows you to add further criteria that must be met before the audit policy takes effect. Each time you click “Add a condition” Windows adds another criteria row where you can add Boolean expressions related to the User, the Resource (file) being accessed or the Device (computer) where the file is accessed. In the screen shot below I’ve added a policy which accomplishes what we described at the beginning of the article.

So we start out by saying that Everyone is audited when they successfully read data in this file. But then we limit that to users who do not belong to the Engineering group. Pretty cool, but we are only scratching the surface. You can add more conditions and you can join them by Boolean operators OR and AND. You can even group expressions the way you would with parenthesis in programming code. The example below shows all of these features so that the audit policy is effective if the user is either a member of certain group or department is Accounting and the file has been classified as relevant to GLBA or HIPAA compliance.

You’ll also notice that you can base auditing and access decision on much more that the user’s identity and group membership. In the example above we are also referencing the department specified on the Organization tab of the user’s account in Active Directory. But with dynamic access control we can choose any other attribute on AD user accounts by going to Dynamic Access Control in the Active Directory Administrative Center and selecting Claim Types as shown here.

You can create claim types for about any attribute of computer and user objects. After creating a new claim type for a given attribute, it’s available in access control lists and audit policies of files and folders throughout the domain.

But dynamic access control and audit policy doesn’t stop with sophisticated Boolean logic and leveraging user and computer attributes from AD. You can now classify resources (folders and files) according to any number of properties you’d like. Below is a list of the default Resource Properties that come out of the box.

Before you can begin using a given Resource Property in a dynamic access control list or audit policy you need to enable it and then add it to a Resource Property List which is shown here.

After that you are almost ready to define dynamic permissions and audit policies. The last setup step is to identity file servers where you want to use classify files and folders with Resource Properties. On those file servers you need to add the File Server Resource Manager subrole. After that when you open the properties of a file or folder you’ll find a new tab called Classification.

Above you’ll notice that I’ve classified this folder as being related to the Transmogrifier project. Be aware that you can define dynamic access control and audit policies without referencing Resource Properties or adding the File Server Resource Manager subrole; you’ll just be limited to Claim Types and the enhanced Boolean logic already discussed.

The only change to the file system access events Windows sends to the Security Log is the addition of a new Resource Attributes to event ID 4663 which I’ve highlighted below.

This field is potentially useful in SIEM solutions because it embeds in the audit trail a record of how the file was classified when it was accessed. This would allow us to classify important folders all over our network as “ACME-CONFIDENTIAL” and then include that string in alerts and correlation rules in a SIEM like EventTracker to alert or escalate on events where the information being accessed has been classified as such.

The other big change to auditing and access control in Windows Server 2012 is Central Access Policies which allows you to define a single access control list or audit policy in AD and apply it to any set of computers. That policy is now evaluated in addition to the local security descriptor on each object.

While Microsoft and press are concentrating on the access control aspect of these new dynamic and central security features, I think the greatest immediate value may come from the audit policy side that we’ve just explored. If you’d like to learn more about dynamic and central access control and audit policy check out the deep dive session I did with A.N. Ananth of EventTracker: File Access Auditing in Windows Server 2012.

email this • digg • reddit • dzone
comments (0) • references (0)

New Technical Brief by Randy Franklin Smith

Mon, 14 Oct 2013 15:43:28 GMT

I have a new technical brief titled "Who, What, When, Where and Why: Tracking the 5 W's of Change in Active Directory, SharePoint, SQL Server, Exchange and VMware".

Your organization relies on you to prevent and detect tampering, unauthorized access or human error to your key enterprise technologies, including: Active Directory, SharePoint, SQL Server, Exchange and VMware.

In this brief, Windows security expert Randy Franklin Smith explores the 5 W's of auditing critical changes to your core technologies by discussing:

The types of activities that you can audit
How to enable auditing and where to find audit data
The hidden gaps, caveats and weaknesses of built-in auditing tools
How ChangeAuditor from Dell Software fills the gaps in auditing

You’ll come away with a better understanding of the limitations and capabilities of native auditing tools and why a third-party solution might be the best approach to protect your systems, data and your company’s productivity and bottom line.

Click here to read more.

email this • digg • reddit • dzone
comments (0) • references (0)

Audit Myth Busters: SharePoint, SQL Server, Exchange

Wed, 02 Oct 2013 08:44:19 GMT

Had many, many valuable conversations with colleagues in DC a couple weeks ago at HP Protect 2013 about auditing and monitoring SharePoint, SQL Server and Exchange. This is a tough subject because there are so many details. You can’t just answer "Are you currently monitoring SharePoint/SQL/Exchange: Yes/No?"

This is because each of those applications have multiple logs with widely ranging security value and content. Also, there are some existing connectors from HP for these apps but their capabilities, caveats vary greatly - as well as exactly which logs and versions of SharePoint/SQL/Exchange they apply to. Many folks are making decisions and/or belaboring under one or more misconceptions.

In this post I'm going to try to quickly bust a few of those and myths and provide links to where you can get more details. It’s kind of specific to ArcSight users but has value to anyone with a SIEM and Microsoft apps.

1. We are already monitoring SharePoint.

OK, but what are you actually monitoring in SharePoint? SharePoint has about 4 different logs. Only one of them is the actual SharePoint Audit Log with security activity. And that log is not available through normal log collection means. Just recently HP released a SmartConnector for SharePoint. But this SmartConnector simply uses JDBC to pull the raw audit log from the SharePoint DB. Take a look at the raw audit log in SharePoint (http://www.ultimatewindowssecurity.com/sharepoint/logbindersp/crypticdata.aspx) Getting the raw SharePoint audit log into ArcSight allows you to say you are collecting the SharePoint Audit log but try understanding and responding to the events. Things like user 17 and role 42 are not translated, so you don’t know who or what you are dealing with. Check here for more non-commercial information on the SharePoint audit log. Learn how we solve the problem with LOGbinder SP here.

2. We are already monitoring Exchange.

Again, what are you actually getting from Exchange? Exchange has 3 different logs that are valuable to security. The message tracking log tracks message flow and is available through a connector for Exchange Message tracking. While it’s incredibly voluminous, it does allow you to track all inbound and outbound emails, but it doesn’t track:

- Non-owner access to other mailboxes

- Mailbox copies and exports

- Privileged user operations

- Administrative changes

- Security policy and configuration changes

For non-owner mailbox access auditing, you need the mailbox audit log. As of Exchange 2010 that log is not a log file nor is it sent to the Windows event log. Each mailbox has a hidden folder where it stores audit records for that mailbox. There is a SmartConnector for the Exchange mailbox audit log and it is practical if you need to audit a handful of mailboxes and do not require full audit log integrity. See my comparison here between that SmartConnector and LOGbinder EX. Check here for more non-commercial information on the mailbox audit log.

The 3^rd log in Exchange, admin audit log, is extremely important because it gives a full fidelity audit trail of all privileged user activity in Exchange including:

- Exports and copies of mailboxes

- Changes to security policies

- and about 600 other operations

This log is also completely inaccessible to SIEMs because it’s stored in a hidden mailbox of all places in Exchange. There is no connector at all, but we do handle it beautifully with LOGbinder EX. Check here for more non-commercial information on the admin audit log.

What about SQL Server auditing?

SQL Server 2008 added a new and beautiful, true, honest-to-goodness audit capability. It blows the old SQL Trace out of the water. No comparison. SQL Audit can send events directly to the Windows event log which you could then pick up with the WUC or Snare, etc. But if your DB admin has anything to do with it you may run into trouble because of the performance load of both logging and retrieving those events through the heavy Windows event API. Microsoft recommends using the other output option which is to a binary log file on some other server on the network. This is the most efficient high speed low overhead method of getting audit events off of a busy production SQL Server. If you need that option, LOGbinder SQL is there to help. The other issue with collecting SQL audit events from the Windows event log is that SQL Server logs every possible operation (we’re talking 100s of them) as just one generic event ID with the same static text and fields. Can you say cryptic? We can help with that too. More, non-commercial, information on SQL Server Audit here.

Some other educational resources right here on 724 are: https://protect724.arcsight.com/docs/DOC-3181 for Exchange and https://protect724.arcsight.com/docs/DOC-3170 for SharePoint.

I hope this helps and feel free to reach out to me anytime…

Randy Franklin Smith

Security Log Nerd

Designer of LOGbinder

email this • digg • reddit • dzone
comments (0) • references (1)

previous | next