Archive for: October, 2011

Share Permissions

In one of our recent posts, What About Individual Users on ACL’s? I mentioned that some organizations have opted for using Windows share permissions instead of NTFS permissions for file shares. This approach goes against Microsoft’s recommendations, but it has one advantage: sharing permissions are applied more or less instantaneously, where NTFS permissions can take a long time to apply to all the files and folders in a big hierarchy. So what’s the downside? Three problems associated with using only share permissions are:

  1. Share permissions levels are full, write (change), and read—NTFS permissions offer many more options.
  2. Unlike NTFS permissions, share permissions only apply when you are accessing files and folders via that share—local access and access via another share, for example, are not subject to the permissions set on the (first) share.
  3. Related to number 2, you can have multiple shares in the same hierarchy, or “nested shares.” Each share may have different permissions, so determining someone’s effective permissions can be confusing.

As an example to illustrate the third issue, let’s say you have a simple folder tree, like the one shown below:


It has three folders, A, B, and C, where B contains C and A contains B and C. The arrows indicate that both A and C are set up as shares. Let’s call our server, “foo,” and the share names for A and C, “shareA” and “shareC.”



Let’s say that the share permissions on shareA are set to everyone read, and the share permissions on shareC are set to everyone read + write. For the sake of simplicity, let’s also assume that NTFS permissions on all files are open to everyone (by the way, these are examples of “open shares,” and they are definitely not something that you, your security team, or your auditors want on your network—we’ll discuss open shares in a future post).

When you access a share over the network, you typically either “map a drive,” or type an address into windows explorer. Either way, you’re accessing a share via what’s known as a UNC path, which looks like this:


So, if you want to create or look at some files in folder C, you can access them in two ways:

  1. \\foo\shareC\
  2. \\foo\shareA\B\C\

Since the share permissions set on shareC are read + write, you’ll be able to read and write files in C if you access the files using the first path, but you’ll only be able to read files if you access them via the second path. These kinds of situations can result in lots of helpdesk calls, since users will get different access rights depending on how they got to a file or folder.

It gets more confusing when you start restricting the share permissions to groups, and even more confusing when you start using (as you should) NTFS permissions. One common security issue arises when an organization is unaware of these nested shares—it thinks its files are secure because the known shares are locked down, but someone has created a more permissive share somewhere deep in the hierarchy that has gone unnoticed.

Using an automated data governance solution like Varonis DatAdvantage can help organizations identify nested shares, open shares, and view effective permissions (share + NTFS permissions).


Steve Jobs – the Ultimate Data Owner

Those of us who have admired Steve Jobs throughout his career have spent the last week reading countless articles about his personal and professional life. Through Steve, Apple has rewarded both consumers and shareholders with incredible products and consistent profitability. So, what is the relationship between Steve Jobs and Varonis? Apple’s maniacal control of its Intellectual Property is widely known, and Apple goes to excruciating lengths to protect its information. The following are perfect examples of how least privilege, need to know, and authorization controls are used within Apple that can be traced to the culture Steve created:

  • According to [an article in the NYTimes in 2009], “Employees working on top-secret projects must pass through a maze of security doors, swiping their badges again and again and finally entering a numeric code to reach their offices.”
  • There were only about a dozen people that had actually seen an iPhone before [it was shown at Macworld 2007]1
  • An iPad developer reported on some of the [steps necessary to get one] prior to the release date.2 These included:
    • Working in a room with no windows
    • Only four people were allowed to go in the room, and Apple recorded the names and social security numbers of each
    • Devices were chained to a hole in individual desks using bicycle cables
    • Each iPad was encased in custom frames to hide their external appearance
    • Apple took pictures of the wood grain of the desks so that if any pictures leaked out, they could trace it back to the specific desk each iPad came from

These are but a few examples of a defined and tightly-controlled authorization process based on data owner involvement, with Mr. Jobs being the consummate Data Owner at Apple.  Consider the number of people, internal teams and departments, vendors and suppliers involved in development of a product as popular as the iPhone or iPad.  Apple maintained a security culture that kept control of all access to what is undeniably one of the most popular products ever.   Intellectual property data protection is critical for most companies, not just Apple, and those who don’t have defined authorization processes involving data owners will certainly pay the price. Apple rarely paid such a price—a testament to the fact that Steve Jobs was the ultimate Data Owner.



Fix Windows Permissions

If you’re a Windows system administrator or involved in Windows security or permissions management in any way at your organization, I can pretty much guarantee you’ve had broken Windows permissions at one point or another. “Broken” can mean a lot of different things, of course, since there are a variety of ways NTFS permissions can break.

In a previous post, I talked a bit about how even though permissions may be mechanically correct—they’re working as they should from an authentication point of view—they may be broken since they’re not providing proper authorization. If you’ve got a folder open to the Everyone group, for instance, you’ve got a folder whose permissions are probably considered broken. But authorization failures aren’t what I’m interested in for this post. Rather, let’s talk about when Windows folder permissions are mechanically broken, meaning that NTFS “inheritance” is not functioning correctly.

In general, a Windows folder can be in one of 3 inheritance states—the first is that it simply inherits all permissions from its parent, so its ACL is exactly the same as its parent folder. The second is that the folder inherits all entries from its parent, but it has additional permissions applied to it. Varonis calls these folders “unique.” In both of these cases permissions changes made on the parent[1] will be applied to the child. The third state is when inheritance is broken, or turned off—Microsoft (and Varonis) call these folders “protected.” Folders that are protected do not inherit permissions from their parents, and changes made to the parent folder permissions will not affect its ACL. Typical Windows administration tools don’t provide a lot of visibility into which folders have inheritance turned off or unique permissions applied, and this is one of the main reasons organizations don’t often know that data is accessible by too many people.

What’s makes things more difficult is that sometimes inheritance can be broken. Either the child folder has not properly inherited permissions that it should have (so an Access Control Entry (ACE) is missing from the ACL) or it is inheriting permissions that are not applied to the parent (it has an extra ACE on its ACL).  Either way, mayhem occurs—IT thinks folders are restricted when they’re not, or thinks they’re accessible when they’re not. When mayhem does occur, to find and fix the culprit means analyzing every ACL in the affected branch of the hierarchy.

Broken ACL’s can occur for several reasons. Some automated copy programs have been known to produce unexpected results. Home-grown scripts can also produce these issues. Another inconsistency can be caused when someone simply moves a file or folder from one folder on a volume to another folder  on the same volume with different permissions. When a file or folder is moved intra-volume, it is really just being renamed in the file allocation table and its permissions do not change. When a file or folder is moved inter-volume (from one volume to another) it inherits the permissions of its new parent.

Thankfully, we now have the technology to find and fix these kinds of problems. Varonis DatAdvantage collects a complete map of Windows permissions along with the users and groups from Active Directory and can easily produce a report detailing everywhere a folder exists with a broken ACL or other inconsistent set of permissions. Now, this helps fix the mechanically broken permissions, but we still need to talk about permissions that are working like they’re supposed to but are still letting way too many people in. Stay tuned.

[1] (unless set to not propagate to all descendant folders)