As a new CIO, I had an imperfect understanding of the role that policies, procedures, and rules played in managing a large IT organization and, more important, governing its interaction with the business. I underestimated their power and I neglected them for some time. As I became more comfortable in the role of CIO however, I realized that policies, procedures, and rules, properly enacted through a participatory and well-understood governance process, were the primary means by which I could shape the future direction of IT in a large, loosely coupled organization.
If you've completed the activities discussed in the preceding chapters, you'll understand the governance procedure that is used to create policies, have a good idea of the business context of your organization, have a good inventory of the processes and identities that exist in that context, and have an interoperability framework.
We distinguish between policies and standards. As we saw in the previous chapter, standards stipulate specific levels of performance, specify certain goods or services, set quality requirements, or describe best practices. Policies, on the other hand, are internally developed rules of conduct and behavior that are specific to the organization. Policies often refer to standards.
In this chapter, we'll discuss what policies are, how they can be written so as to be effective, how they can be implemented, and how they should be maintained.
Many technologists loathe to create policies, feeling that policies stifle creativity, impede productivity, and are nothing more than an autocratic attempt to control people. In fact, if designed correctly, policies enable action and productivity. You cannot create an IMA and reap the attendant benefits without policies. They are the heart of the architecture as well as the foundation on which effective identity management strategies are formed. Policies define appropriate behavior, specify the tools and processes that will be used, communicate a consensus, and provide a foundation for enforcement.
Many organizations have a smattering of security policies in place, and some of these touch on identity issues. In creating an identity management architecture, we're advocating separating out the identity aspects of those policies and creating a holistic approach to identity on which to build not only security policies, but also other important aspects of the business.
Figure 18-1 shows an IMA policy stack. The interoperability framework of standards undergirds identity policies. These policies include naming, passwords, encryption, authentication, privacy, access control, provisioning, directories, and federation, among others. In turn, the IMA supports activities important to the business such as software practices, security policies, software licensing, contracting, procurement, customer strategies, information protection, risk assessment, and partner interactions.