Courion Corporation

Build vs. Buy? – Sizing IAM Development Costs

In one of my first programming jobs, I worked at a major academic medical center in Boston that not only wrote their own software applications, they even developed and maintained their own proprietary programming language.

Needless to say, they don't do that anymore since that approach only makes economic sense when there are no other viable alternatives. Despite this, we occasionally run into enterprises that are considering developing their own in-house identity and access management (IAM) solution.

If you're considering developing your own custom IAM solution, what are the factors you should be considering as you evaluate the cost/benefit ratio?

Required Feature Set

First, what features would you want to implement? To simplify this, let's just consider password management and not include provisioning, role management, or other IAM applications.

Based on Courion's experience with hundreds of customers, here is a list of features that a reasonably functional password management solution should provide:

• Self-service: Users must be able to securely reset their own passwords. If you don't offer self-service, then all you're doing is automating the help desk, but without eliminating calls to the help desk in the first place, which is one of the main reasons companies choose to deploy password management.
• Challenge authentication: End-users should be able to register their own private challenge/response questions and answers in a secure directory or database that the system can use to verify their identity when they need to reset a password.
• Flexible user interface: Users should be able to reset their own passwords using a variety of interfaces. At a minimum, they should be able to use a browser and their Windows log-on screen. Other options include a telephone/voice recognition system or interactive kiosk.
• Help desk support: Some users can't, or won't, manage their own passwords, in which case your help desk needs to be able to reset passwords on their behalf without requiring privileged access to the target systems. The software should automatically create, populate and close tickets for reliable security audit and service level reports (this includes both self-service and assisted resets.)
• Password strength and history checking: The system should enforce prudent password history and strength policies, including:
• Centralized definition and enforcement of password policy;
• Minimum/Maximum password length;
• History (password reuse) and Dictionary checking;
• Required mixed case, numeric and/or special character use.
• Target integration: The solution must manage passwords on mission-critical target systems, each with its own unique native security system, including desktop computers, networks, enterprise directories, databases, packaged applications and custom-built or legacy systems. Building reliable, secure and scalable connectors to heterogeneous systems from a variety of vendors can be a daunting challenge. An IAM solution provider can enter into partner agreements that provide access to code, developers, and APIs not available to most internal developers. Troubleshooting connectors that fail when target APIs change without support can be expensive, time-consuming and frustrating.
• Logging and auditing: The solution must have a tamper-proof method for logging and tracking password-related transactions.
• Alerts and notifications: it should support email and/or pager alerts to confirm actions or warn of suspicious activity. For example, users should be notified of any changes via a message like, "Your password was reset on [date], if you didn't initiate this password reset request, please contact security immediately."
• Scalability: Only a large organization has the resources to create and maintain a custom password solution, which implies there will be times (i.e., Monday morning at 9 AM) when many users will be resetting their passwords simultaneously. The solution must scale to accommodate large numbers of simultaneous password reset requests, without buckling under the load and potentially compromising security.
• Data security: The solution must transfer and store data using encrypted and hashed formats to preserve the privacy of passwords.

Some other features that might be considered useful, but not essential for the first implementation, are:

• Synchronization: A feature that many users appreciate is the ability to synchronize a password across multiple systems, which means the user only needs to remember one password at a time.
• Delegation/Restriction: Some organizations will want to be able to block specific users from access to workflows, while others may want to be able to delegate authority to more than one administrator.
• Multi-language: A multi-national organization may need to provide support for non-English speakers.

Development Costs

Once you know what features to implement, you can estimate the costs. Based on our experience developing PasswordCourier, we estimate the above solution will require approximately eight person-years of development effort, at a total cost of between $1.2 million and $1.5 million (using fully loaded current salary rates and benefits.)

Maintenance and support of the above solution are estimated at 0.5 FTE (full time equivalent) per year or between $75K and $90K per year for routine support (bug fixes, minor enhancements, etc.) If you have a complex or dynamic environment (with new systems that require password connectors being deployed regularly), your development and maintenance requirements may be much higher.

You can do the math for your organization, but I expect you'll discover that investing more than a million dollars to develop software functionality that is currently available from commercial sources at much lower total cost of ownership won't pass muster with most CFOs.

On the other hand, if you proceed and 18 months later you've developed the password management system of your dreams, then you can start thinking about provisioning, role management, and compliance verification and reporting.

What are your thoughts?