An Identity Policy Suite

An identity policy suite is a collection of high-level policies that deal with identity. Figure 18-1 listed many of the common ones: authentication and authorization, naming and directories, encryption, software development, software licensing, networking, privacy, and federation. The number and type of policies depends on an organization's size and purpose.

The goal in creating policies at this level is to establish the boundaries within which other policies and procedures will work. The policy suite should provide a foundation on which other policies can be based. Therefore, it is important that wherever necessary, policies in the suite grant some role in the company specific authority to regulate the area further. The policy may also assign responsibilities to the role. In many cases, the policy may create the role.

For this strategy to be effective, policies in the identity policy suite will not typically be excessively detailed. At one end of the extreme, the policy will say nothing except to appoint a governing authority and leave all decisions to that authority. At the other extreme, the policy is sufficiently detailed that there's nothing left for the governing authority to do. Strike a balance and err on the side of saying less rather than more. The policies in the suite should state what is non-negotiable and leave as much room as possible for the governing authority to meet the demands of the organization and users within those guidelines.

The following sections discuss the most common policies in an identity policy suite.

A policy on naming and certificates forms the basis for other identity policies and for security policies. Naming can refer to many different things including domain names, usernames, uniform resource locators, documents, phone numbers, employee identity numbers, and physical assets such as conference rooms, printers, and computers. Your policy may not concern all of these, only the ones that are important now. Other facets of naming can be added as necessary or delegated to the appropriate parties.

The naming policy should be concerned with the form of names and who is responsible for naming. Most companies, for example, own one or more domain names. Other people in the organization will want subdomains from those domain names. Someone in the organization should be responsible for maintaining the domain name asset and assigning subdomain names. This role is typically called the "registrar."

Most organizations also own a number of digital certificates. As we saw in Chapter 6, digital certificates associate identity information with a public key in a signed data structure. I've chosen to include the policy information for certificates with naming, because I prefer using the registrar for managing an organization's certificates as well as domains. In common practices, most of the certificates will be associated with domain names and the asset tracking system being used to manage domain names, and subdomains can frequently be used to manage certificates as well. Another place to talk about certificates would be in the policy on encryption and digital signatures.

A policy on naming can also help enforce some of the standardization done as part of the identity data architecture in Chapter 16. A policy might include requirements to use information from the metadata repository or to use identities in established data stores in preference to creating new identities.

One of the most important naming roles a policy can perform is to grant authority for creating enterprise-wide identifiers. For example, how are email identifiers created? Who has authority to determine the format of employee numbers?

We discussed various password strategies and options in some detail in Chapter 7. The goal of a password policy is to:

You will be sorely tempted to over-specify the password policy. Resist that temptation by recognizing that there are plenty of other policies dealing with security that can build on the password policy, and give specific requirements for specific applications such as user access or networks.

A minimal password policy should deal with acceptable password formats, how passwords are stored, and requirements for the creation and protection of passwords. Additionally, the password policy should require that each identifier have the ability to store a separate password.

As you use the password policy as the basis for other security policies, you will run into requirements that show up over and over again. The password policy should be changed to include these general requirements rather than repeating them in multiple places. This ensures that as the password policy is reviewed, and when these general requirements are changed, that change manifests itself in all other policies.

Almost every modern organization relies on cryptographic technology. If nothing else, most businesses have a digital certificate for their web site or use certificates in a virtual private network (VPN). The goal of a policy on encryption and digital signatures is to clearly delineate acceptable cryptographic techniques. The policy usually will not include specific policies about digital certificates or VPNs, for example. These would be in another policy.

The policy on encryption and digital signatures will typically require that only approved products and algorithms be used. The policy should never include references to specific algorithms or products—include them in the policy by reference to the interoperability framework.

A policy on encryption and digital signatures will generally include prohibitions on using proprietary encryption schemes, because these are generally not as trustworthy as those designed by the community of cryptographic experts, which have been subjected to a significant social process to discover their weaknesses.

The encryption policy will also typically call attention to export controls and require that those laws be followed. There should be no mistake by your employees or other parties that you intend to follow the law in this matter.

Successfully creating and using an enterprise-wide directory is mostly about process, not technology. There are some factors that a policy on directories can help with.

First, establish who has accountability and authority. Appointing an enterprise directory director (EDD) as a collateral duty and giving that person sufficient authority is crucial. That role should be empowered by the policy to create and enforce rules and processes regarding the enterprise directory. The policy may not say it, but the EDD should avoid promulgating these rules and processes, but rather create them cooperatively with other participants in the enterprise directory.

One of the crucial success factors in an enterprise-wide directory is establishing a way to create a globally unique ID for records in the directory. We've already dealt with that in the policy on naming and certificates, but the directory policy should reference that, and the EDD should play a role in creating the format for IDs.

Another crucial success factor for an enterprise directory is the directory schema. The EDD should be empowered to manage the schema and make decisions regarding what is and is not included.

To create an enterprise directory through using metadirectory or virtual directory technology, a process has to be put in place to designate which records will be considered canonical. For example, records identifying an individual may show up in several directories. Which of these records will be considered the true source of information about that individual? The directory policy can establish a process for making that determination.

An enterprise may have several enterprise-wide directories. For example, there may be one for employees and one for customers. These different directories may need separate policies with different governance processes.

Privacy policies in the identity policy suite should concentrate on the global requirements that must be followed by everyone and every project in the organization. Note that this privacy policy is different from, but governs, the privacy statement you might place on your web site. The most fundamental point in the global privacy policy is to establish the ground rules for protecting personally identifying information. This policy then forms the authoritative basis for many other security policies.

In Chapter 4, we gave 10 important principles regarding privacy. Use the governance process to establish a set of guiding principles for your organization based on these privacy principles and then make sure your privacy policy reflects them. Incorporate the principles into the policy by reference and give specific guidance where necessary.

For example, the privacy policy should establish a role such as a chief privacy officer (CPO) and empower that role to establish rules in keeping with the policy and the guiding principles.

Other items to include in a privacy policy are requirements to post privacy statements on web sites, conduct regular reviews of the identifying information being collected by each project and product, and use best practices to protect identity information from accidental disclosure and theft.

Privacy policies should require the appointment of data custodians for each repository of personally identifying information and charge that person with the requirement to meet the other requirements in the policy, such as conducting periodic reviews.

Data confidentiality should be maintained by specifically telling persons with access to repositories what they can and can't do with respect to the data. For example, copying data for testing and development could be prohibited or allowed within certain parameters. The policy would not usually include the specifics of such an agreement but assign responsibility to some role in the organization for creating and maintaining it.

Authentication policy is built on the naming, password, and directory policies.

One of the most important factors in authentication is the creation of authentication levels. For example, a company might designate the following authentication levels with associated authentication mechanisms:

Note that these requirements say nothing about access control; rather, they specify authentication levels. This gives significant guidance to system architects and designers, because they can then count on the authentication system giving them back an authenticated user with a certain authentication level. This removes the ambiguity of trying to sort out for each system what authentication mechanism to use and what it means.

Authentication policies should provide guidance on using the enterprise directory infrastructure (if one exists) and require that systems be purchased to support the authentication infrastructure. Major system upgrades should also be evaluated for compliance issues.

Unlike other policies that we have dealt with, access-control policies do not specify a single role to be held accountable for the performance of the policy. Access control is about thousands—even millions—of individual resources that have different owners and custodians. In many modern organizations, nearly every employee is the owner of many information resources.

Consequently, an access-control policy should define owners and custodians and spell out specific responsibilities for each. The policy should also specify responsibilities for users, so that users who violate policies knowingly can be held accountable.

As we saw in Chapter 8, owners determine what the access-control policy for a given resource will be while custodians determine how to carry out the policy set by the owner.

Information resources generally fall into one of three access-control categories:

  • Uncontrolled resources have no oversight whatsoever. Anyone can create, modify, or delete them. You may not think that much will fall into this category, but in fact this is unfortunately the default classification for most corporate data even when the owner would like to apply some other policy.

  • Audited resources are tracked so that the organization can determine which user took what action and when. These records may be audited at varying times to ensure that users are behaving in compliance with the owner's policies.

  • Controlled resources have access-control policies associated with them. Those access-control policies should be enforced by the information systems.

The access-control policy will not generally specify access-control methods for meeting policies because that depends a great deal on specific systems. A policy may, however, make recommendations or guide new development toward certain access-control methods.

As we saw in Chapter 5, there are many opportunities in the identity management lifecycle for provisioning identities. Unless your organization takes steps to ensure that provisioning is done according to standards and with an eye to automation, help desk costs can become excessive.

As a result, the goal of the provisioning policy should be to require conformance with standards listed in the interoperability framework and to require automation. Depending on the maturity of your digital identity infrastructure, the policy may be more directional than regulatory. That is, the best you can do in some cases is to require automation, where possible, because your infrastructure may not yet be up to the task. This is a good example of how policy must change depending on the status of the infrastructure it's supporting.

One of the things that a provisioning policy should always do is require that new systems be in compliance, especially in automation functions like password reset. Another important consideration is support for and requirements to use the enterprise directory.

Policies for federation are particularly important, because there can be considerable risk in connecting with external partners. At the same time, the very idea of federation implies that two or more partners are coming together and compromise will be necessary. A federation policy therefore has to distinguish between requirements that you're placing on your employees, things on which you're unwilling to compromise, and what approvals are needed for agreements that may stray from internal policies.

There are several big gotchas in federation projects that should be covered by the policy. Among the most important is the amount of trust you can place in external partners. You may choose to require that they meet external, independent security criteria, such as SAS70, or simply submit to due diligence by your own staff. Of course, they'll likely require that you meet the same requirements.

Another important aspect of a policy on federation is to ensure that agreements that initiate and govern the relationship are properly reviewed and limit your liability in case of fraud or error.

Most of the foregoing assumes a private federation agreement, that is, a custom agreement between two or more parties. In the future, you may be able to join a federation network that has standard policies and agreements. The downside of such agreements is that they will likely not be customizable to any great degree. You take what's offered. On the other hand, as we've seen, such networks will standardize the process of federation and make it easier and less costly to enter into federation relationships.

A policy review framework should be included in the policies that are developed as part of an IMA. The framework is really nothing more than a schedule. Consequently, it is generally short and relatively non-controversial. The review framework consists of the following parts:

The schedule itself should be reviewed the last month of the calendar or fiscal year and a new review calendar created for the coming year.