Preparing for DAC

Microsoft

Sep 20, 2018

First published on TechNet on May 09, 2016

Hello everyone. This is Randy Turner to share some insights learned with implementing Dynamic Access Control (DAC.) There are numerous posts which I will share at the end to discuss the steps to implement all the features covered by DAC, but very little on how to adopt these changes. DAC is just an outcome from what is really a fundamental change behind data governance. The key features of DAC provide solutions to the new open landscape of BYOD and Cloud Services. Data is no longer safe behind a firewalled LAN. Data needs to be available anywhere from any device in order to support a more productive workforce. I have outlined some of the solutions that this new view can achieve.

Goals for this change in data governance

· Protection against the dissemination of sensitive data . We need to identify sensitive data and imbed this classification into the file as well as imbed means to control, audit and revoke access into the file. By managing security at the file level, we can enforce access control regardless of its location.

· Setting permissions with meaningful origin. We need to align access control with user administration so that permissions are updated alongside an individual’s role. Permissions need to be expressed in natural language policy for awareness and compliancy. The identification of security requirements need to move away from the technology staff and into the hands of the information owners.

· Controlling permissions at a policy level. We need to set conditions at the enterprise level and propagate these changes to all file servers. Automate and continually verify the adherence of these settings across all controlled file servers.

· Consider conditional factors when protecting access. We need to make authorization decisions based on things like:

o whether a user is working remotely

o on an unmanaged device

o Age of the file

The truth is, this is a change that reinvents the foundation of how data is currently protected. Most organizations still rely on data shares of file servers to control permissions. This architecture runs into problems when you consider how data moves around and gets copied, or expressing the original intent of the data share security as time goes by, or the attestation of the users granted access as they change roles. A new philosophy must be adopted to support the world we now live in. They can both coexist while we migrate to this new philosophy. Here are the topics of the preliminary work:

Understanding how it works

We need to understand the differences between our current Identity Based Access Control (IBAC) which rely on security group membership and manual updates to individual access control lists; and the Access Based Access Control (ABAC) model and Dynamic Access Control (DAC) features in Windows.

· Research: At the end of this document are a list of resources.

· Triage on topics: Invite presenters to discuss topics.

· Test: Deploy in a lab environment.

Identify Opportunity

This investigative phase involves communicating these ideas to department leads. We need to reiterate the goals outlined above and understand how this might work within our organization. There are three topics to consider when identifying opportunity.

· Object Attributes: Also known as File Classification. When speaking with data owners, listen for distinct characteristics that could group together similar files. This grouping could be based on a job responsibility, geographical ownership, or content such as Personally Identifiable Information (PII) or Company Intellectual Property (IP).

· Subject Attributes: These would be attributes of an employee that could govern access to certain information. When considering subject attributes, be sure to use ones with clear distinctions. Associate a confidence level with each attribute to differentiate between those with background checks and oversight for accuracy, and others that may be more arbitrary.

· Natural Language Policy (NLP): Listen for statements governing management and access of enterprise objects. These statements will be the building blocks for writing access policy rules. Do not worry about how you might implement a policy rule, we are only documenting needs within the organization.

In addition to this investigation, we need to identify sensitive information that needs to be accounted for within the organization. Questions to ask would be:

· Are specific naming conventions used to identify these files?

· Are there any other identifiable attributes or content to locate these files?

· How are these protections currently handled? If a certain security group is associated with sensitive data, then we can look at current file and folder permissions to locate these files.

In addition to department leads, you will also want to involve your legal department to identify what constitutes as sensitive information.

Incorporate Industry standards and compliance requirements

Beyond company needs are conditions required by your industry or federal law. Much of this can be found through Internet searches, Microsoft’s Data Classification Toolkit , and 3 ^rd party data governance software. You can include this information in your investigative phase under each of the three topics. Be sure to note any deviations from these standards in your implementation. These industry guidelines are known as IT Governance, Risk Management, and Compliance (GRC) Authority Documents. Here is a list used by Microsoft’s Data Classification Toolkit.

· Payment Card Industry Data Security Standard (PCI-DSS) . This is a credit card industry standard focusing on managing protected cardholder information.

· National Institute of Standards and Technology (NIST) Publications . This is a set of United States standards used to meet regulations that are applicable to federal agency IT services. This set of documents includes:

· NIST SP 800-53A . This is a United States standard, functioning as the Guide for Assessing the Security Controls in Federal Information Systems .

· NIST SP 800 - 60 Vol1&2 . This is a United States standard, including Vol1: Guide for Mapping Types of Information and Information Systems to Security Categories , and Vol2: Appendices .

· NIST SP 800-122 . This is a United States standard, functioning as the Guide to Protecting the Confidentiality of Personally Identifiable Information (PII) .

· Federal Information Processing Standards (FIPS) Publication 199 . This is a United States standard, functioning as a standard for "Security Categorization of Federal Information and Information Systems."

Identify Data Storage Locations

We need to verify compatibility of each technology with our file server infrastructure. If Windows, we need to know the operating system version. If not Windows, we need to know vendor information on what is supported and if there are similar solutions that might be implemented in tandem. Supportability might require upgrades or policy restricting where certain data must be stored.

In addition to file servers, what other services could also host data needing governance. How can we protect and incorporate SharePoint? Are other Web Services, Databases or Applications offering data with similar security needs.

Document your own GCRs

After considering the needs of your enterprise, it is important to document the Governance, Risk Management, and Compliance measures you hope to achieve. Here you can map out elements of the DAC and ABAC models to understand where and how policy is configured, where it is enforced, and what it protects. These documents will be the foundation for implementing and adhering to the security needs of your enterprise’s data.