The problem is that corporations aren't managing security in quite that fashion. Many companies are adopting more comprehensive written security policies, and many of those policies define sensitivity levels for various kinds of data -- something the U.S. government, by the way, has done for decades. Companies might define sensitivity levels like "confidential," "top secret" and "executive eyes only." These sensitivity levels might be accompanied by a need-to-know list, which specifies which users actually require access to the data. Finally, each sensitivity level might also include some kind of authentication requirement. "Confidential" data, for example, might be accessible to anyone with a user name and password, but "top secret" data might require stronger, two-factor authentication.

These policies are easy for executives and information security professionals to dream up, and they make sense on paper. As I mentioned, it's pretty much the classification system the government has used for ages. Windows administrators trying to implement such policies, however, have to bridge a gap between the written policy and the way Windows' security subsystems work. As Microsoft continues to explore new security and data storage technologies for future versions of Windows, maybe it's time the security infrastructure got a little overhaul. Mind you, I'm not saying there's anything inherently wrong with Windows' security; I'm suggesting that perhaps the level of granularity, the point of control, and the user interface itself could be revised to provide a more policy-oriented form of control.

Central Policy Definition
Like Group Policy, administrators should have the ability to centrally define security classifications. These classifications could live in Active Directory, where they'd be accessible by member computers and users. My new so-called data classification policies (DCP) would define various classes of data: Confidential, Public, Secret or whatever a company required.

Each DCP would be accompanied by a policy definition. This would be comprised of three distinct components:

• A DACL. Just like the DACLs of today, this component would specify who has access to the data, and what they can do with it: Read, write, delete, modify permissions, and so forth. In addition to the regular users and groups, the DACL could of course assign permissions to special groups, like the Everyone group. A new special group would also be available: Need To Know Users.
• A SACL. Similar to the SACLs on files and directory objects today, this specifies auditing requirements. In addition to specifying auditing-such as, "Audit all denied access attempts to this file"-the SACL could also specify whether or not auditing was a hard requirement. In other words, if the SACL were applied to a file on a server that didn't have auditing enabled, the SACL could specify that access to the file was to be denied until auditing was turned on. This feature would ensure that the centrally-defined DCP would always be obeyed.
• Minimum authentication. Many companies feel that more sensitive data requires stronger authentication. This component of the DCP would specify the minimum level of authentication required to access the data. Unless a user logged on with this minimum level, they'd be prompted for additional credentials, or denied access to the resource. Options might include, "NTLM vX," "Kerberos one-factor," "Two-factor," "Biometric," and so forth.

Remember, each DCP would be centrally created and applied in Active Directory. DCPs could also be updated from time to time, to reflect the organizations' changing needs. But the DCPs themselves don't apply security, they simply offer easy-to-understand classifications.

Applying Security
Files, folders, printers, directory objects, and other permission-protected resources could use a simplified user interface to actually apply DCPs. For example, if you wanted to edit the permissions on a particular folder, you'd only do two things: Select the appropriate DCP ("Confidential," "Secret," or whatever your company set up), and edit the Need To Know list.

Of course, there's some more detail to cover:

• The Need To Know list can be left empty. That's fine; this list simply defines who will be governed by the permissions assigned, within the DCP, to the special Need To Know Users group. The DCP could also assign permissions directly to specific users and groups, so Need To Know wouldn't be required.
• Each DCP would be protected by its own permissions, which among other things would tell Windows who could edit the DCP and who could apply it. When you edit the permissions on a resource, you only see the DCPs that you have permission to apply. That'll keep users from recklessly applying special-purpose DCPs to their own files and folders.

The interaction of that Need To Know list could be complex, so here's a brief example: Suppose I create a DCP named "Sales Confidential." I set the authentication level to "Kerberos one-factor," meaning a simple username and password combination will suffice. I also grant read, write, and delete permissions to a domain global security group named "SalesGroup." Finally, I also add read permissions to the special Need To Know Users group.

Then I waltz over to one of the company's file servers, and find the folders that contain the Sales department's confidential information. I open the folders' properties and apply the Sales Confidential DCP. On the Need To Know list for some of the folders, I add a domain global security group named, "Executives."

The outcome: The members of SalesGroup have the necessary permissions to their files. The Executives group also has read permission-because they "need to know"-on certain files. Nobody else has any permissions to the files. The Need To Know functionality allows a granular override to the DCP's built-in permissions. Of course, such an override can be centrally prevented by simply excluding the special Need To Know Users group from the DCP's DACL.

Why The Change?
So what's the big problem with the way security already works? It doesn't map as readily to the types of corporate security policies that companies are beginning to adopt. Most importantly, Windows' current security doesn't provide any means to define data classification levels at some central level, and then allow administrators and other users to apply those policies as appropriate.

A user can be expected to know that the document they just created falls under the company's "Secret" classification. But users should not be expected to know how to edit a Windows DACL to ensure that the document is sufficiently protected. However, if a user could simply select "This data is Secret" from a drop-down list, then the centrally controlled DCP could apply the proper permissions to comply with the written security policies.

Under the hood, Windows' existing security is more than sufficient to implement my suggested new infrastructure. Permissions inheritance would play a big role, allowing a DCP to be applied to a folder and affect all the files and subfolders within. The permissions themselves -- read, write, delete, and so forth -- wouldn't need to change. Active Directory would need to pick up the new central management, and a bunch of UI changes would have to be made. But security could take on a much more policy-based implementation, making it more accessible both to administrators implementing written policies as well as users and other non-technical individuals.

What Do You Think?
How do you think Microsoft should evolve Windows' security to mean changing corporate needs? Would you be comfortable managing DCPs on your servers? Let me know by posting below or drop me a line at .