In Chapter 9, I discussed the metadirectory project that the State of Utah completed. This project was driven by a clear business need—specifically, the governor and others wanted a better URL for state web sites and shorter email addresses. This project inspired policies about naming conventions and directory interaction. This is just an example of how business projects and processes inform identity policies.

To some, driving policies from business projects and processes may seem somewhat less than pure. But in fact, that’s the point. By tying your policies to the places where they are needed, you’ll get better policies and avoid creating unused policies. As an example, you may determine that you can justify the creation of part of your identity infrastructure on the basis of the savings from password reset. That’s a perfect opportunity to create naming, password, and directory policies. Even then, you might opt to create just the parts of those policies that you need to complete the password reset project and leave other parts of those policies for another time.

The danger in this approach is that sometimes business requirements will demand that decisions be made faster than you can accommodate with the policy creation process you’ve put in place. You can mitigate this problem in one of two ways:

In either event, you want to avoid two extremes. On one extreme, you delay important business decisions and their implementation with the policy process. This is certain to breed discontent and force people to work around the system, rather than within it. On the other extreme, people make decisions without any guidance from the policy process and the identity infrastructure suffers from ad hoc decisions and no structural context.

One of the most important roles for identity policies is to secure organizational resources. Much has been written about information security , and most large organizations have people in place who are dedicated to this important task. You may already have security policies that touch on some of the identity issues that we’re discussing.

One thesis of this book is that identity enables information security but is not subsumed by it. Indeed, there are significant security considerations that have little to do with identity such as firewall and intrusion detection policies. This implies that security policies should be separate from and built on identity policies, as shown in Figure 18-1.

Traditional security policies such as network security, acceptable use, and firewall requirements typically use concepts such as naming, authentication, encryption, and access control; but policies on those issues are frequently not aggregated together. You may find on reviewing security policies from your organization that they even contradict each other on these issues.

Separating identity policies from security policies requires that you rewrite each security policy to remove more general identity issues and reference them instead. As you do this, the requirements of your security policies will drive the contents of your identity policies.

The governance process should always include subject matter experts on security so that they can speak to information security needs as policies are developed and implemented. In fact, you may find that the governance process we’ve outlined in this book is useful for creating and maintaining security policies as well. Just be sure to keep those policies separate. While the needs of information security should play an important role in creating identity policies, they should not overshadow other important needs in the organization.

External sources such as government regulators and large partners frequently place requirements on the enterprise. These are another important place for identity policies to germinate. External requirements might be legal or regulatory requirements such as HIPPA, Sarbanes-Oxley, or the Gramm-Leach-Bliley Act. At other times, these external requirements are developed by some industry group and have the force of law for all intents and purposes (such as “generally accepted accounting principles”). Others are voluntary, but the business has concluded that they will abide by them for some reason.

In any event, your organization probably already meets, or attempts to meet, these requirements. Doing so places a burden on the identity infrastructure. Identity policies can codify and normalize these requirements as well as provide a process for meeting the many external identity requirements that are placed on your organization.

Determining what policies are needed in your organization is an iterative task, not an event. Like any good business process, the governance model discussed in Chapter 14 has a built-in feedback mechanism. If properly implemented, this feedback mechanism will give you information about what policies are working and which are not. It will also point to policies that need to be developed to answer questions that arise in the application or enforcement of existing policies.

What should a policy look like? Typically, identity policies have a set of sections that follow an identifiable outline . I recommend the following sections:

The specific policies you develop may have all or only some of these sections depending on the circumstance. I recommend that you develop a policy template for your organization and use it for every policy so the policies have a consistent style and format.

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:

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.