Finding a comprehensive identity and access management architecture requires leadership to navigate the technology and implementation labyrinth.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
No need to beat around the bush—passwords stink. No one—users, administrators, security pros—likes them, and for good reason.
Despite password policies, users persist in repeating poor password choices— their dog's name, birthdays, favorite colors. Getting them to apply fixed alpha-numeric combinations at least seven characters long is a security fantasy, but shops trying to enforce strong password policies often discover that passwords aren't free. Heck, they aren't even cheap.
According to recent statistics, 25 to 30 percent of all help desk calls are password-related, the average cost per call is $25, and the average user makes roughly four of these calls per year. Then, there are the omnipresent dangers of skilled social engineers who are able to con even the savviest of users into revealing their passwords.
It's time to place authentication in its rightful place as an important component in a comprehensive identity and access management (IAM) architecture.
But, since IAM goes beyond security, it should be approached with a holistic enterprise perspective and not just focused solely on authentication.
After years of languishing on the back burner, IAM will become a major enterprise focus area in the next 24 to 36 months, driven by new business initiatives, regulatory compliance and the need for process efficiency.
Security managers must seize this opportunity and provide IAM leadership on four levels: building a planning team, mapping access requirements, designing an access control architecture and implementing the solution.
The IAM Team
When embarking on an IAM project, security managers must gather a team of application, systems, access, network and directory managers and administrators from various business units across the enterprise. Of course, each department's security should have strong representation within the IAM team.
This team's purpose is to define the IAM business requirements—not to architect a technical solution. Each participant must represent his department's needs while collaborating to address overall business requirements. The team's ultimate goal is threefold:
- Assess current problems by developing a list of IAM financial, operational and organizational issues. The team members will define the business risks, operational overhead and organizational issues associated with each problem so the IAM solution can be aligned with overall business goals.
- Define goals by prioritizing short- and long-term objectives based on business value. The team will address tactical operational and security issues, but think strategically about business and regulatory requirements. Will the company outsource any business processes in the next few years? Will the organization need to create roles and access policies for "extended enterprise" applications to service outsiders? Are there any pending or anticipated deadlines for regulatory compliance? A model solution should enable business flexibility, improve security and cut operational costs.
- Pool funds from various business units. While the IT department can certainly build and manage the technology, all business groups should invest in the process. Enterprises may allocate money to IAM projects, but it's quite common for business departments to contribute from their budgets.
During this initial phase, the security group's job is to help the organization fully appreciate the business risks associated with current IAM architectures—weak passwords, poor controls and multiple identity stores. Security managers should avoid the temptation to play "Chicken Little" with constant warnings about security breaches and identity theft that don't amount to much.
Rather, security managers should balance paranoia with hard operational facts—the process of managing and monitoring multiple RADIUS servers, VPNs and network directories requires loads of financial and human resources and is strewn with costly inefficiencies—both human and technical. Quantifying security inefficiencies, loses as a result of breaches and future savings—or as some call return on security investment (ROSI)—will be important and well-received input.
Access control isn't just about keeping bad guys out—it's about controlling who gets into the infrastructure and limiting where they can go. Mapping access needs is a crucial phase of an IAM project, since this is when secu-rity managers need to determine which users and devices will have access to specific applications and data and from which locations (intranet, mobile computers, kiosks).
During this phase, the IAM development team needs to catalog all systems and applications; each system should be rated in terms of how critical it is to the business and assigned a value.
It's important to note the process for user provisioning, management and monitoring, and, in terms of the technical information, to note whether each system has open or proprietary application interfaces and IAM infrastructure, the type of operating system, and whether the application is in a steady-state of operation or due for a near- term upgrade.
Enterprises also need to assign a level of sensitivity to data as it is being created, amended, enhanced, stored and transmitted. Data classification can be an arduous and time-consuming task, and many companies simply ignore it. At the very least, security managers should classify obvious confidential and regulated data, and assign it a level of minimum protection.
Many enterprises make the mistake of using existing access rules and accounts as baselines for new systems.
Security mangers should use the opportunity of a new IAM infrastructure to recast all access rights. Rather than focusing on the "who," best practices dictate that companies should focus on "what" (what asset?) and "why" (does this person need access to this system/data?). Building role-based access provisioning in this way will help bolster security and ease the compliance auditing both during and after the process.
With an inventory of assets, data and access roles, security managers can define rules for authentication and authorization by selecting a security model that helps meet enterprise objectives without impeding business operations. In terms of authorization, security managers can now help map existing roles and groups to the assets they truly need and secure critical systems enterprise-wide with "need to know" security.
Enterprises also need to create standard processes for account creation, change management and deletion by documenting the current workflow, approval and provisioning process, looking for inefficiencies and opportunities for automation. Once designed, the model process can be complemented with auditing, automation and provisioning tools from vendors like BMC Software, Computer Associates, Courion, Consul, IBM Tivoli, Novell and RSA Security. Given the complexities of this phase, companies often cut corners—and run into security and compliance problems down the line. CISOs must step in to make sure that this doesn't happen; successful access mapping will lead to perpetual security and operations benefits.
Striving for Scalability
Identity and access management spans the entire enterprise; in building an IAM solution, enterprises must define an appropriate architecture that allows them to start small, grow gracefully and, most important, avoid all-encompassing solutions that demand million-dollar investments and multiyear implementations.
To maximize benefits while avoiding technical lock-in, IAM services should feature a layered architecture based upon standard protocols (i.e., RADIUS, LDAP, X.509), data formats and APIs. There are three basic layers in the IAM services architecture:
- Identity Objects (i.e. user, device, file, application, etc.) sit at the bottom of the stack. They define anything with an identity that needs to be mapped to access policies and monitored for compliance. Identity objects vary based on company size, global locations and government regulations.
- Identity Services provide middleware like messaging, directory, replication and data services that link identity objects to IAM applications. Identity objects will take direct advantage of the identity services, while legacy objects with their own IAM infrastructure will rely on specific gateway and data translation (i.e., metadirectory, XML translation, etc.) functionality.
- Application Layer provides business, security and operations functionality through the identity services layer. Identity and access management applications will plug into the identity services layer through a handful of standard interfaces from leading software vendors and IAM infrastructure providers (i.e., Java, ASP/.NET, C++, etc.). As other standards evolve (such as authentication protocols like RSA Security's OTPS or VeriSign's OATH), enterprises will be able to integrate best-of-breed IAM technologies into existing architectures.
Security managers may be in unfamiliar territory during this phase as they tend to think in terms of "best-of-breed" products rather than architectural solutions. They need to focus on protecting corporate operations, long-term scalability and business needs by designing an identity management architecture, and then filling in tactical needs with standards-based tools that have an eye toward future integration.
The Final Frontier
This phase includes setting up a test bed, building a prototype, rolling out an early adoption phase and then pushing the project into production.
Though this sounds fairly straightforward, security managers must continue to oversee the deployment to ensure that design and operational goals are met.
An IAM project has no shortage of moving parts, so it's easy to get lost or have some minor problem cascade into a major showstopper. Security managers must keep meticulous records on the implementation process to troubleshoot the inevitable kinks and avoid any future problems.
To ensure progress, security managers must also make training an ongoing process. Users must be taught the mechanics of the IAM, so they will understand the protections, processes and limitations on their access rights. And, business managers must be educated on the need for maintaining IAM integrity. Shortcuts and ad hoc processes and mechanisms will undermine the IAM efficiency and, ultimately, overall security.
Unanticipated security vulnerabilities or process problems will crop up—and security managers must stay on top of them. With a project of this significance, it's better to delay deployment than to roll out systems that frustrate users and don't work.
Overall, patience is a virtue. This project will require time, money and loads of cooperation. Security managers should approach IAM as politicians—not police officers.
Identity is truly an area where security and business initiatives go hand-in-hand, so savvy security managers can use this critical project as a way to improve security, formalize controls, reduce operating overhead and support business initiatives.