Container-Based Controls versus Dynamic Authorization: The Difference in Windows Environments (Part 1 of 2)

By Sandeep Chopra.

If you are debating whether to upgrade to Windows Server 2012, plenty of articles describe its new security benefits (for example, see here and here). Fewer articles discuss the basic shift in Access Management this release can enable. To understand the potential benefits of one key feature, Dynamic Access Control, it’s useful to compare this approach with more well-known models of Access Management, such as ACLs and Security Groups. This blog is first in a series that compares how Access Management was handled in Windows environments prior to the 2012 release with what’s possible now.

Container-Based Controls: ACLs and Group Management

ACLs and Security Groups are currently the most ubiquitous model of Access Management. ACLs come standard in operating environments and many enterprise applications, and are familiar to both IT professionals and the common Windows user. ACLs are simply lists of users (Security Groups) with permissions applied to containers. While ACLs can also be applied to files, this is not a common solution for addressing broad authorization requirements. It’s not practical to manually apply permissions to (what might be) thousands of files. More typically, ACLs are applied to containers (folders) on file servers and network shares.

The ACL and Security Group model is both manual (with permissions defined per container, by an Administrator), and static (pre-determined and applied ahead of time). For reasons discussed below, this model can expect a lot of IT Administrators and end users. From the perspective of regulatory and compliance staff, this model does not always ensure accurate controls.

From the Perspective of IT Administrators

From an IT Administrator perspective, managing permissions and containers can become difficult. One reason is data tends to expand and organizations tend to have lots containers. Administering which Security Group(s) should have access to which containers quickly becomes complex and error-prone. The number of Security Groups that IT must manage also tends to grow, especially when authorization requirements are more complex. For example, the following graphic describes how many separate Security Groups must be maintained to apply controls to a growing list of containers, for a fairly simple authorization case. One problem is that, prior to Windows Server 2012, there was no support for conditional expressions or logical ANDs between Security Groups. This means it was necessary to create another set of Groups to express an intersection between groups (in first example below, a control that applies to both Project A Group and Secure Group).

Containers vs Groups

For End Users

From an end user perspective, properly securing data on a file server requires you to know exactly which container to put it in. In this discretionary model, users have to be familiar with all the pertinent information storage and sharing policies, know which policies apply to the data under question, and know which designated container is the one to use.

For Compliance and Regulatory Staff

From the perspective of compliance and regulatory staff, another limitation with Security Groups and ACLs is the lack of precision. It’s not “containers” compliance people care about when they think about authorization requirements—it’s the characteristics of data that warrant a control in the first place. You cannot apply ACLs directly around these characteristics. The best you can do is express these characteristics in the name of the container (in the sample above, Project A, Secure).

There are several problems with this approach. While the value of the data might be captured by directory name, the actual value may be more specific, or there might be multiple values (or classifications) that apply to data. Plus, even when a container name accurately represents the value of data that is driving access control, that attribute is not applied at the file-level. If a file is moved to a different location, where the correct ACLs are not applied, protection on the file will be lost.

Container Based Controls in Your Authorization Toolkit

Access Management models are like tools in your toolkit—you should try to use the right tool for the job. In the past, IT organizations have been limited by what tools are available. Now that there are more choices, administrators should evaluate their requirements and decide which approach is the best option. The following guidelines apply to using ACLs and Security Groups. 

The Right Tool When…         Container-based controls that rely on Groups and ACLs can be the right tool for the job when the number of containers and groups required is small, when users can be expected to know which policies apply for data and can be trusted to comply with those policies, and when data-level controls are not necessary. ACLs can also be a good tool for deploying a baseline access control model, on top of which finer-grained controls may be layered.

The Wrong Tool When…      Container-based controls alone are the wrong tool in environments where the numbers of containers and groups grow very large, when discretionary controls are not adequate, when controls must be applied outside a container, and when data-level controls are necessary.

Sandeep Chopra is the Director of Product Management at NextLabs. Sandeep’s extensive experience in Enterprise Information Risk Management includes work at Microsoft and Deloitte.   In the past, he has created products, such as SharePoint, and delivered consulting services for Fortune 500 companies, enabling them to implement sustainable, risk-based data protection programs.


4 thoughts on “Container-Based Controls versus Dynamic Authorization: The Difference in Windows Environments (Part 1 of 2)

  1. Great question JP.

    The best way to address the classification gorilla is to identify the specific business problem you are trying to address, then focus classification and access controls around that. For instance, are you trying to address a specific compliance requirement? A specific IP use case? Designing classification around a specific security objective is a far better approach than trying to address the general file security problem.


  2. Sandeep I like your description the inherited problem most administrators deal with in a day to day production enviioment. In most cases the ACL and groups have been there for long period of time which makes the problem more complex to deal. Underanding the DAC concept what would be a good methodology to adopt when trying to wrestle the 800 pound gorilla? We all know data classification and records retension strategies are a large part of the effort in order to be successful, normally are big initiatives that are not well defined to get off the ground effectively. What has been you experience with current deployments or designs that leverage DAC?

    Pardon for the typos working on a mobile device 😉

    Best regards
    JP Calderon

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s