FINANCIAL SERVICES INDUSTRY UPDATE

Coping with Compliance: Identity Management Offers Relief

By Alan Joch

It's becoming more expensive to comply with government regulations. AMR Research estimates that organizations spent about $15.5 billion for this area last year, and the figure could grow to $80 billion by 2010.

Spending for compliance is hitting IT budgets especially hard. According to a recent
press release from Gartner on its 2005 Financial Compliance Management Survey, "IT financial compliance management spending will increase to between 10 percent and 15 percent of IT budgets in 2006, up from less than 5 percent in 2004."

The challenge is clear: Finding the right technology and procedures for adhering to regulatory requirements has become a top goal of companies throughout the world. Fortunately, identity management (IdM) systems can go a long way to meeting regulatory needs.

The most common deficiencies include so-called "orphan" accounts, where active access rights exist beyond what should be available after changes in an individual's employment status. Other audit problems arise as workers' responsibilities change over time. Similarly, conflicts in access rights create a regulatory stumbling block. For example, under some governance rules, people authorized to use an accounts payable system shouldn't also be free to tap into a purchasing application—dual authorization could potentially lead to payment fraud. Finally, enterprises get hammered by regulators when password policies aren't enforced uniformly across all enterprise systems.

An IdM system provides a first line of defense against these audit problems by including the right set of administrative features.

IdM should centralize security policies to assure that the policies apply uniformly throughout the organization. Centralization also provides for greater visibility into security administration.

The framework should standardize access rights as a way to enforce the segregation of duties. IT and security managers can use this segregation to create policies governing which groups of people have authorization to use specific systems. IdM tools should be available for maintaining tight managerial control over authorizations and profile data as the prime means for restricting access to sensitive data and applications.

The burden of managing access to resources is lessoned when IdM systems accommodate group authorizations. Using this strategy, a company can assign access rights to groups of workers, for example, those in the purchasing department who are all entitled to use an order-management application. Similarly, people responsible for managing vendor relationships would receive rights to access a database of approved contractors. However, to reduce the chance for fraud and to meet regulatory requirements, security administrators could stipulate that people in one group are locked out of the other's resources. And when someone moves out of either group, the IdM system automatically changes his or her access privileges.

The IdM solution should also be able to automate access-management activities. Administrators should be able to create, approve, and issue privileges within a traceable, electronic process that includes safeguards for ensuring that all relevant approvals are obtained. Automated access management eliminates many of the security problems associated with manual authorization systems that rely on paper approval forms and e-mail. These legacy systems make it difficult for administrators to document when and why they granted authorizations.

Similarly, the IdM system should create all the necessary reports and documentation required by managers for regulatory compliance. The system should draw on internal audit data of user privileges to compile the reports. This information in turn becomes the cornerstone for showing ongoing compliance to the various regulations relevant to the organization.

Alan Joch is an independent writer focusing on business and technology.

This document is provided for information purposes only, and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor is it subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document, and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission.

Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.