Archive for: October, 2011

The Authorization Problem

In one of my recent posts, I talked a little bit about how the levels of data protection—authentication, authorization and auditing (or accountability)—applied to unstructured and semi-structured data. By the title of the post I bet you can guess what I’m going to talk about today: authorization.

If you recall, authorization refers to what someone can actually access once they’re authenticated. To illustrate, let’s assume someone is trying to access a system; let’s call her Mary. The authentication step is where we verify that this person is actually Mary. Authorization is when the system decides what Mary can and cannot do once she’s authenticated. What data can she access? What can she do with that data? Can she just read it, or can she change or delete it as well?

Ensuring proper authorization has traditionally been very difficult. Let’s look at a Windows environment as an example. How do we control Mary’s authorization? Typically, we put her into security groups, and then put those groups on the access control list (ACL) of shared folders, SharePoint sites, and Exchange public folders. So if Mary is part of the Marketing group, she would be placed in Group_Marketing. Data that the Marketing group needs access to would be placed in folders that have Group_Marketing on the ACL. Now, once we’ve authenticated Mary, she’ll be able to access data in those folders. Easy!

So what’s wrong with this, then? Well, first of all, Group_Marketing may exist not just on folders belonging to the Marketing department, but it’s possible that group is also on some other, unrelated folders. If you ask your Windows admin to show you all of the folders a specific user of group has access to, he or she probably can’t do it. It’s too hard to answer that basic question using the built-in tools Windows offers. On top of that, we’ve got all these folders everywhere that are open to global access groups. In Windows alone we’ve got Everyone, Domain Users and Authenticated Users. If a folder has one of those groups on the ACL it means everyone can access it. Maybe it’s by design, like if the folder has a bunch of blank forms or templates everyone should be able to access. Often, though, it’s by accident—somehow the folder was set to be open for Everyone, and now we have no idea what’s in there, who’s using it and who should have access to it. Basically, we’re not performing any authorization at all. If you’re authenticated, you’re authorized!

Another problem is that users tend to be put into new groups without ever having old access revoked. Let’s say Mary’s a real go getter and decides she wants to move from marketing into R&D. Now she needs access to all of R&D’s data, so IT puts her into Group_Research. What’s often not done, though, is pulling her out of Group_Marketing. Maybe she needs access to a few things during her transition, so it’s put off for a while and then never actually done. Or maybe IT generally doesn’t revoke access when it’s no longer needed, which is also common. IT is really good about granting access since users call up the help desk when they can’t get to something they need. But no one ever calls up the help desk screaming that they have too much access, do they? The end result is that the longer Mary’s with the company, the more data she’s going to likely have access to, and our authorization controls become less and less effective.

These are just some of the challenges organizations today are facing when it comes to proper authorization. When groups to the right data sets, folders are open global access and unwarranted access not being revoked are all symptoms of broken authorization. What’s needed to fix these problems, and ensure they stay fixed, is automation. The reason we can’t easily fix a folder open to a global access group is because we have no good way of figuring out who actually should have access. We need an automated way to gather data about all this data (metadata) and then analyze it so we can start answering basic questions: Who’s got access? What are they doing with that access? Who’s got access that should be revoked? In future posts we’ll talk about how we can use intelligent automation to clean up authorization and implement a sustainable, secure access control model.

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)

Global and Regional Requirements for Data Governance

Last week I had the opportunity to present “Ensuring Your Organizations Digital Collaboration is Secure” at an IDC conference in Dubai.  The conference was attended by approximately 100 people from a variety of Middle Eastern countries and companies.  Although the event proved to be beneficial for the obvious reasons (market development and sales), it also proved to be worthwhile as it provided additional proof that data governance is a global challenge which needs to be addressed at both global and regional levels.

Not surprisingly, the IDC conference was attended by every type of vertical, including financial services, manufacturing, technology, media, medical and telecom companies.  Many of the people I had the opportunity to speak with expressed interest in controlling access to data, understanding where their critical data resides, and, most importantly, who was accessing their critical data.  They were interested partly because of regulatory factors such as PCI, but mostly because they recognize that critical data simply must be protected.

One participant expressed concern that IT and data governance decisions are centralized as broad corporate initiatives, but local business requirements dictate the institution of immediate controls:

  • Prove that access permissions to email, shared folders and SharePoint repositories conform to a least privilege model
  • Remediate inappropriate access permissions
  • Identify the individuals responsible for sensitive data (data owners)
  • Ensure that intellectual property access is monitored by these data owners

Based on these requirements, this participant has been authorized to initiate a local data governance initiative to ensure that intellectual property (IP) is protected in his division. Given that IP exists throughout his company, implementing a successful governance strategy at a local level will likely have broader ramifications for his organization’s data governance initiatives.

The Dangers of Data Portability

I read some research recently by Dell KACE, showing that almost two-thirds of IT professionals are worried about security issues associated with the use of personal devices in the workplace. The research, which took in the responses of 750 key IT security professionals, shows that they are worried about the personal devices that seem to be multiplying in the workplace like tribbles1. The conclusions of this report come as no surprise; IT security professionals already shudder and rub their weary eyes when thinking about what is happening to their organization’s data in the modern world. It shows that almost 90 percent of employees use their own laptops, tablet computers and mobile phones for work-related tasks. It is clear that companies now need to keep track of their data as never before.

At Varonis, we have been monitoring this issue and it is undoubtedly getting worse from a security perspective. Mobile devices and the cloud services that sync with them offer very tempting productivity gains: it’s natural for employees to want take files out of central data stores, work on them, and then move them back into the organization. This boost in productivity, however, also extends and exacerbates the common vulnerabilities that are still big problems on the core collaboration infrastructure, like file shares and email.

Employees usually have too much access to file shares, SharePoint, Exchange mailboxes and public folders, and can freely download data to their workstations without any record. With all the memory now standard on tablets and smartphones, and free GB’s of storage on cloud services, it’s easy to take more data further outside the core where there are even fewer controls. As an example, how often have you seen, over the shoulder of someone on a plane, train or subway, confidential information displayed on the screen of an iPad, iPhone or laptop? (I try to avert my eyes).

There is no easy answer, but instead of getting annoyed by powerful new smartphones, tablets, and cloud synchronization services, we can take some steps to reduce the risks associated with data portability if we ensure that access to sensitive data is limited upstream, before it makes it onto any of today’s portable devices. Organizations have been challenged with this in the past because many fundamental controls, like access auditing and metadata analysis, have been missing, and the processes to limit access to data have relied on IT personnel to make access control decisions (instead of data owners). Unaudited, overly permissive access naturally allows personnel to move accessible data onto all the devices they use to complete their work and collaborate digitally.

This is where an automated data governance system really comes into its own, as these types of systems can not only audit and log the distribution – plus usage – of an enormous volume of unstructured data, but they can also alert key members of staff when something unusual happens. The future will almost certainly continue to bring us physically smaller, logically bigger, faster, more connected gadgets faster than we secure them, but we can achieve a reasonable level of control, at our core—where most data ends up and lives for long periods of time.

1Tribbles are fictional asexual animals in the Star Trek universe,the expression “multiplying like tribbles” has also become commonplace in the context of science fiction or technology