Determining Policy Needs

In previous chapters we have discussed, in some detail, the process for creating a business model and inventorying processes and identities. If you have performed these activities, you should have a good idea of how the business is using identity information and what priority the business places on various resources.

Identity policies will typically come from one of four places:

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.