3 Deadly File Permissions Mistakes

Scarily, in most organizations people have access to much more information than they need in order to do their jobs.  With file permissions, it’s easy to mess things up and hard to find and fix problems, especially in large environments.  One tiny mistake can cause a ripple effect across terabytes of data, opening up a massive security hole.

But why do so many file servers’ permissions look like the Gordian Knot?

Increasingly Complexity

File systems are alarmingly complex.  Given 1 TB of data, on average you will have:

• 50,000 folders
• 2,500 folders with unique permissions
• 4 security groups on every unique folder
• 15 members per security group

2500 x 4 x 15 = 150,000 functional relationships in a single terabyte of data.

With this level of complexity countless things can go awry, but there are some common mistakes you should avoid at all costs.  Here’s a round-up.

1. Global Access Groups

We’ve all been there: the CEO is screaming that she’s getting a “Permission Denied!” message trying to access her slide deck 5 minutes before a board meeting.  It’s not clear what’s wrong, so you commit the cardinal sin of access control: you grant full access to the Everyone group or Authenticated Users.  You make a note to fix it later…and that never happens.

Routinely run (or better yet, automate) a full audit of your servers, looking for any data containers (folders, mailboxes, SharePoint sites, etc.) with global access groups applied to their ACLs and replace them with tightly managed security groups.  You can knock out this project with a free trial of Varonis DatAdvantage, which has the added bonus of being able to sort by data sensitivity and to test changes in a sandbox.

2. Individual Users Applied to ACLs

Though it might be quick and easy to add Bob directly to an ACL rather than figure out the right security group to put him in, this practice is extremely error prone and can be a maintenance nightmare.  What if Bob changes roles?  Now you’re hunting and pecking for ACLs to remove him from rather than making a simple group change.

Many organizations have a strict policy to never, under any circumstances, name an individual user to an ACL and you might want to do the same.

3. Broken ACLs

In Windows, when an ACL is mechanically “broken”, it means that NTFS inheritance will not function properly.  Either the child folder has not properly inherited permissions that it should have or it is inheriting permissions that are not applied to the parent (it has an extra ACE on its ACL).  Either way, mayhem occurs, so you need a way to find and fix broken ACLS.

Native tools in Windows won’t help much, but thankfully there are solutions that can easily identify folders with broken ACLs or other inconsistent set of permissions.

(Also, Brian Vecci wrote an awesomely detailed post on broken ACLs.)

Bonus Tip!

Even if you avoid the 3 mistakes above, your security groups should be periodically reviewed by someone with context to decide who the appropriate members are — or your permissions can quickly get out of hand.  Security groups need to be fluid and represent how authorization should look today, not 6 months ago.

Even if you have perfectly groomed security groups, without a map of which files and folders they’re applied to, you’re still at risk. Verifying security group membership without making sure you know what data those groups provide access to is like checking to see if someone has the right keys with no idea what doors they might unlock.  You can map out where your groups grant access with a free trial of Varonis DatAdvantage.

Image credit (cc): https://www.flickr.com/photos/viatorius/