The Case for Identity Management

• By Doug Gale
• 07/20/06

Developing a successful, cost-effective IdM system takes more than a reactionary response to the latest hacker scare.

WHAT IS YOUR SCHOOL’S identity management (IdM) strategy? Do you really need one? IdM is a cornerstone both for cyber security and for privacy compliance (now a particularly hot issue in health information management as institutions struggle to comply with HIPAA regulations)— so the answer to the latter question should be a big yes. But understanding the elements that comprise IdM—and finding a long-term way to balance IdM’s costs with its benefits— can be a challenge.

Months ago in this column (“Trend Report: Identity Management,” November 2005), I identified four underlying components of IdM: identification, authentication, authorization, and directory services. I then elaborated on the first two. This month, we focus on the remaining two components— authorization and directory services—as well as how to sell the need for an IdM strategy to your campus.

Authorization

Authorization is the process that determines what networkbased resources a user is allowed to access. For example, a student may be allowed to access his or her own student records, but not those of another student. The information that specifies what individuals are authorized to access may be stored in multiple databases maintained by different administrative units.

While the process is conceptually simple, it is complex to execute. Defining authorization on a case-by-case basis is extraordinarily time-consuming. Other schemas, based upon an individual’s role, organizational structure, or policy, are fraught with exceptions. The need to translate complex policies into automated combinations of more basic attributes is an area that is rapidly evolving, and campuses will benefit from following the activities and guidelines of national organizations (see “IdM Resources You Should Know”).

Authorization information or its location is typically consolidated in a “directory,” normally spanning a single campus or enterprise. Which brings us to the next component of IdM: directory services.

Directory Services

Directory services were once viewed as little more than online enterprise or network “white pages,” containing network user information such as a person’s name, title, location, network ID, e-mail address, and phone number(s). Now, directory services are becoming the central point for creating, storing, and maintaining user identities and privileges, and for management of network and application access. As the number of shared enterprise applications increases, directory services have become the answer to integrating and managing this complex online environment. This solution also reduces dependence on manual or disconnected directory maintenance processes, streamlines access, and minimizes risks to associated resources.

Fortunately, there are mature and well-defined standards, even cookbooks, for directory services. Yet not all of them fully address higher ed’s unique needs. For example, the international X.500 standard relies on a hierarchy of information access, reflecting the organizational structure of an institution. This creates substantial overhead in colleges and universities, where people frequently enter, leave, and have multiple affiliations. If you pigeonhole people and they change roles, there is a cost associated with updating the directory. To address this problem and others (such as the fact that X.500 is too complex to support on desktop PCs), the Lightweight Directory Access Protocol (LDAP) was developed at the University of Michigan. LDAP is essentially a simple version of X.500 that has been widely and successfully adopted in higher education. (More information on LDAP and other directory technologies is available here.)

Selling IdM

Often, it’s the all-too-common security scares in daily news reports that first call attention to the need for comprehensive IdM systems:

• In December 2005, an intruder hacked two Iowa State University computers containing encrypted credit card and Social Security numbers (Des Moines Business Record, April 20, 2006). This incident is a strong argument for encrypting sensitive data.
• The number of rootkit attacks being reported to McAfee Avert Labs was up by 700 percent during the first quarter of 2006, compared with the same period in 2005 (eWeek, April 24, 2006).
• On April 24 of this year, IT officials at Ohio University found that someone had hacked into an alumni database server containing personal and biographical information for more than 300,000 individuals and organizations (Computerworld, May 3, 2006).

Such scares may feel compelling in the short term, but in the long run the most successful arguments for IdM are based on a value proposition: What’s the real risk and how much will it cost to mitigate? What should be the scope of the IdM system and what is the appropriate level of financial commitment? These questions need to be answered not just by the CIO, but also from the perspective of the chief financial officer (who is concerned with containing the growth of campus expenses), as well as the chief academic officer (who is concerned about diverting scarce resources from instruction and research).

Quantitative Metrics

As a physicist by training, I’ve always been attracted to the use of quantitative models and metrics to evaluate and compare IT initiatives. It turns out that I’m not the only one so enamored. The most recent Computer Crime and Security Survey conducted by the Computer Security Institute (CSI) and the Federal Bureau of Investigation found that a significant number of organizations conduct some form of economic evaluation of their security expenditures. (The full text of the survey can be found here.)

The most popular metric is a percent of revenue. For example, the CSI/FBI survey found that 48 percent of responding organizations devoted between 1 and 5 percent of the total IT budget to security. Other common metrics are expenditure per employee or per user. The advantage of these metrics is that they are relatively simple to explain to management; the problem is that averages can be misleading and can mask wild variations in the samples. As someone who has used IT expenditures as a percent of institutional budget as a rationale for increasing the IT budget, I have reluctantly concluded that these simple metrics have limited effectiveness and should be used with caution, if at all.

More complex metrics have been proposed. A recent national security publication proposed a “value protection” metric based upon an algebraic formula. Upon closer inspection, however, the methodology is circular. The user is asked to specify a desired “value protection level” based upon a poorly defined and fuzzy explanation of the metric. The formula is then used to generate the cost of meeting the metric. Unfortunately, the resulting investment cost is derived directly from the formula—independently of what it may actually cost to provide the service in the real world. This particular metric can work (sometimes) because senior executives do not always fully understand statistics, what they mean, how they are derived, and what assumptions were made in their preparation. The metric is still balderdash, and if exposed, will undermine the credibility of the IT organization using it.

A Workable Strategy

What I suggest to clients is an honest assessment of the probability and costs associated with various security risks, solid research on the costs to mitigate those risks, and a common-sense decision-making process. The goal should be adequate security—much like Ralph’s Pretty Good Grocery in Garrison Keillor’s Lake Wobegon, where you can get what you need but not necessarily everything you want. Most people routinely make decisions in their everyday lives based upon this common sense process. Years ago, as a rock climber and new father, I took out a large life insurance policy because the risk was high and the cost of mitigating the risk relatively low (at the time, insurance companies didn’t yet include rock climbing on their list of dangerous activities). I didn’t base that decision on a formula or a spreadsheet, but rather on a clear, common-sense measurement of the risks, and the costs associated with mitigating those risks. The same process is key to assessing security risks and their potential costs to your institution.

Common-Sense Security-Event Costs

What is the cost of a “security event?” Since they can negatively impact an institution in a variety of ways, the costs go beyond the dollar amount required to fix a server or eradicate a computer virus. Components of the institutional cost may include:

• Response costs. The costs to bring the institution’s operational processes back to normal; for example, the person-hours to eradicate a computer virus.
• Recovery costs. The costs to bring the institution’s IT resources back to normal; for example, the cost of removing a rootkit from a server.
• Lost revenue. Revenue that is lost to the institution, such as tuition from reduced student enrollment, lost grant funding, or a reduction in donations resulting from damage to reputation.
• Lost productivity. The cost of staff and faculty idle time while IT recovers from an event.
• Penalties. The cost of penalties, such as those incurred by non-compliance with privacy legislation.
• Perception costs. The long-term costs to counter a negative perception or repair a damaged reputation, including public relations and marketing costs.

Evaluating and prioritizing these costs will go a long way toward developing the right IdM strategy for your own institution.

Community Benefits

Beyond averting an individual institution’s security-event costs, IdM offers other potential benefits to higher education at a community level. In particular, federated IdM allows a user who has been authenticated at the campus level to access resources on other campuses through a trust fabric. Shibboleth is a national higher ed initiative, funded by the National Science Foundation and facilitated by Internet2, to implement a single sign-on federated IdM infrastructure. Shibboleth uses the Security Assertion Markup Language (SAML) open standard for exchanging authentication and authorization information across multiple security domains.

Whether you’re focused on your own institution’s security initiatives, or on weaving them into the community fabric of a federated infrastructure, developing a successful IdM strategy is a key concern now and for the future. Don’t wait for a security event to bring your IdM needs to light—it’ll cost you!