Security Advisor

Separation, No Anxiety

Separation of duties is a good idea in the business world. It’s also a good one in the IT world.

• By Roberta Bragg
• 01/01/2004

Some say the reason there are few women in IT is because very early in their lives they were introduced to the concept of separation of duties: The formerly popular belief that women should be in the kitchen, barefoot and pregnant, and that men should be out killing dinner and fending off tigers. Then, the theory goes, women are subjected to societal actions and rules that reinforce this female = soft, pampered airhead; male = strong, forceful intelligent leader concept. According to some, it’s all more than we poor flesh-and-blood Barbie dolls can manage, so we self-select roles that don’t require us to think, or at least those that don’t require us to exist as equals in this male-dominated industry.

Personally, I don’t subscribe to that theory, but I do believe in separation of duties. At least I do when it comes to defining what users can do within an application, when accessing a computer or network resource, or even as administrators of information systems of any kind. However, my rules aren’t based on sex, sexual orientation, ethnicity, skin color, nation of origin or allegiance. Roberta’s Rules are based on something much more clear-cut and less provocative. In IT, separation of duties is the security principal that requires a clear division of privileges. It’s based on an understanding of how the actions that these privileges allow could be used to compromise a system, steal money (or other assets) or otherwise subvert a process and cause harm. For example, if the IT administrator is also the auditor of his own actions, this is a clear violation of thisa principal.

In the business world, separation of duties has been around for a long time. Long before computers made their appearance, business realized the problem of giving too much power to a single individual. For example, accounts payable clerks can approve invoices, and some of them can even write checks, but they can’t issue purchase orders. That’s the job of the purchasing clerks. If one person could do both, they could very easily defraud the company by issuing purchase orders and writing checks for things that never got delivered. When two people have to collaborate to make fraud work, it can still happen, but it’s more difficult and more likely to be discovered. Clearly, in the business world, separation of duties results in, or complements, role separation. Role separation divides duties between different titles or functions in order to make it impossible for one person alone to steal or otherwise damage an organization’s assets.

In IT, role separation doesn’t happen that way. If you think about Windows administration, there are users and administrators, but administrators can do what users do and some advocate making users administrators on their own desktop computers (don’t). There are some default groups that can do some subset of administrative duties, and you can define your own. You could implement role separation of duties, but where is the guidance for doing so?

Administrative Separation of Duties Guidance
Rule No. 1: Administrators should have two accounts—one, with which they do their administrative job, and the other for ordinary work, like reading e-mail. You can make this a policy in your organization, but compliance still relies mostly on your administrators. One helpful tip: Use Software Restriction policies in Windows Server 2003 and Windows XP Professional to keep the administrators group from running ordinary applications such as Word and Outlook.

Rule No. 2: Never make a user an administrator. There are clearly defined duties for each role, and while administrators can do stupid user things, users can’t do stupid administrator things.

Enforcement of Role Separation
How do you implement the process? It’s all very fine and good to speak of giving one group of users one privilege, and another group of users another privilege, but can you enforce these roles? If you give the Accounts Payable Clerks group access to the check printer and the other resources they need to do their job, and give the Purchasing Clerks group access to the purchase order application, will that be enough to do the job? What happens if an Accounts Payable clerk moves from Accounts Payable to Purchasing? Will he be able to both issue purchase orders and write checks to vendors? If someone tells you he’s moved, you can remove him from the Accounts Payables Clerks group and add him to the Purchasing Clerks group and all will be fine. But will anyone let you know that this happened? You’re more likely to get a call from Purchasing to add him to the Purchasing Clerks group. Unless your company is small, and unless you recognize this as a problem, he’s probably still going to have membership in the Accounts Payables Clerks group and now have access to both functions.

Put Them in Denial
It’s possible to accidentally provide such employees with membership in two groups originally designed to provide role separation. Situations like this occur when IT isn’t regularly informed about employee movement. What often happens is that IT gets a panicked call that someone needs to be given a privilege or permissions, with no corresponding notice that others should be revoked.

But if you design permissions properly, you can enforce some role separation. If, for example, the Accounts Payable Clerks group has the Allow Print permission on the check printer, give the Purchasing Clerks the Deny Print permission on the check printer. That way, if Jamie leaves Purchasing for Accounts Payable, and her user ID isn’t removed from the Purchasing Group, when she attempts to print a check, access will be denied. When the Account Payable manager calls to find out why, the problem will be revealed. Unless someone changes the permissions, the only way to enable Jamie to print checks is to remove her ID from the Purchasing group.

The ability to provide and enforce role separation relies on three things:

Knowledge of where role separation and separation of duties is required.

Support within Windows.

Knowledge of how Windows works.

Required Role Separation
You can prevent, for example, Account Operators from making changes to Administrator accounts—that’s built in. But can you prevent administrators from messing with the rest of the account structure? Not right now, and you may not want to. If Account Operators are supposed to manage most accounts, let them. There likely isn’t an administrator out there who wants to add that duty to her roster. You’ve got to know when separation of duties is a good thing—and better yet, when enforcement of role separation is required.

You’re going to have to chat with the business managers and the auditors of your organization to find out where separation of duties might be required in your organization, but I can tell you where I think it would be useful on the IT side. There are two cases that immediately come to mind.

First, there ought to be some separation of duties between data administrators and service administrators. Data administrators do things like add users, change their membership in groups and so on. Service administrators, on the other hand, do things like manage the Active Directory infrastructure. The separation of these two roles is a good thing, and while there is some support for it in Windows 2000 and above, correctly improving the technical controls for this type of role separation requires more effort. (More on that at a later date.)

Second, for server applications, separation of duties can be a huge boon. You might, for example, wish to separate the privileges of the OS administrator from those of the database administrator on a SQL Server. Similarly, separating the roles of OS administrator from Exchange server administrator might be a good thing. It’s difficult in both cases to find someone as qualified in one area as they are in the other, and giving one individual full responsibility for both server side application and the OS isn’t a good idea. Within these products, role separation is available, but once again, you’ll have to really work to make it fit the model.

Support Within Windows
This separation of duties stuff is starting to sound like a lot of hard work. Why doesn’t Windows offer more support? Well, actually, it does; here’s an example of separation of duties performed through role separation, and what’s more, how it can be enforced. By enforced, I mean that not only do separate roles exist, but you can prevent those who have one role from being able to perform the duties of another role.

This example is in the administration of Windows Server 2003 Certification Authorities.

Here’s how it works.

Two roles within certificate services are defined by permissions assigned on the CA object. These roles are Certificate Manager and CA Administrator.

A Certificate Manger issues and manages certificates. Give a Windows group (created for this purpose) the Issue and Manage Certificates permission, and members can:

Approve and deny certificate enrollment requests.

Approve and deny revocation requests.

Reactivate certificates placed on hold.

Recover archived keys

A CA Administrator administers the CA. If a Windows group (created for this purpose) is given the Manage CA permission, its members can:

Configure policy and exit module

Stop and start certificate services

Configure extensions and roles

Configure Certificate Manager’s restrictions

Delete a single row in the CA database when necessary

Enable, publish or configure CRL schedule when necessary

Assign other CA roles when necessary

Renew the CA certificate

Define key recovery agents

Here’s the best news. This role separation between CA Administrators and Certificate Managers can be technically enforced. Enforcement isn’t a matter of making fancy moves with permissions or scripting administrative roles. Instead, it’s built in. So, should an attempt be made to gain both sets of privileges on the CA by adding an account to both groups, the account will be prevented from doing either.

There’s more. By default, members of the local Administrators, Domain Admins and Enterprise Admins groups have the right to manage the CA. Enforce role separation, however, and administrators don’t have the ability to manage the CA. For an example of why this can be important, see the sidebar, “Key Archival Protection.”

Key Archival Protection A new feature of Windows Server 2003 CAs is custom certificate templates. These templates make it possible to design and create certificate templates that vary from the standard templates. One change is the ability to do key archival, which allows the archiving of private keys associated with a certificate. This is a huge gain for the Encrypting File System (EFS), where the loss of a private key can mean the loss of access to critically important documents. But what happens if it’s easy to get the archived key? Right—unauthorized people could read an encrypted document. To prevent this, the duties of key retrieval and key recovery are separated. When the private key is archived, it’s encrypted and this “key blob” is stored in the CA database. Only the Certificate Manger can actually retrieve the key blob, but only a key recovery agent can actually decrypt the key blob and get the key. Any guesses as to who can define the key recovery agents for the CA? Yup, the CA Administrator. Any way you look at it, it would take two people to fraudulently obtain a private encryption key.

Common Criteria Approved
Enforcement of role separation—new in Windows 2003—is more than some new Microsoft idea of what’s good for security. The need for role separation in the management of a CA is a requirement of the Certificate Issuing and Management Components (CIMC) Family of Protection Profiles that’s part of Common Criteria. Common Criteria is an international standard for the definition of secure information processing hardware and software, and is supported by 18 countries.

The philosophy behind Common Criteria is that if a common specification for evaluation exists, and products are tested against this specification, it won’t be necessary for organizations to do their own exhaustive testing. All they need to do is find a “protection profile” and evaluation level defined by Common Criteria that meets their security needs, and then pick a Common Criteria-evaluated product in that category. The participating countries develop the evaluation levels and protection profiles (specifications that define security for a product).

To obtain an evaluation, the product has to undergo extensive evaluation against the specification. Win2K, for example, has the EAL4+ evaluation when configured as specified in the same manner as systems tested. Understand that Win2K evaluation doesn’t qualify Windows 2003, and the ability to configure CA administration to meet the Common Criteria recommendations doesn’t give a Windows 2003 CA any Common Criteria evaluation level rating. (For more information on Common Criteria, read my March 2003 article, “Windows and Common Criteria.”)

Knowing How Windows Works
There are more gems that support separation of duties hidden within the Windows operating system and the applications that run on it. But to implement them is not as straightforward as it is for CAs. You must use the assignment of privileges and permissions to architect separation of duties and understand how things work in order to enforce them.

Finally, you must remember that the ultimate barrier to separation of duties is within the administrator’s role itself. Whatever you can do can be undone. An administrator can turn off the enforcement of role separation in a Windows 2003 CA. But that’s not all bad; you may need to do so to recover access to the CA if, for example, roles are incorrectly set up in the first place.

Still, turning off enforcement for fraudulent reasons can be done, too. It’s also possible for a rogue administrator to create two accounts and give each one of them a different CA administrative role, then use each separately to gain power over the CA. To counter any such abuse, you’re going to have to audit administrative activity and assume some responsibility for developing a trustworthy administrative culture. Trustworthy administration is something you should have even if you don’t implement role separation or Windows CAs.