pragmatic identity & access management

A Pragmatic Solution for Identity and Access Management 1

COPYRIGHT 2011 HANK GRUENBERG. ALL RIGHTS RESERVED. THIS MATERIAL MAY BE FREELY COPIED AND DISTRIBUTED SUBJECT TO THE INCLUSION OF THISCOPYRIGHT NOTICE. [email protected]

Tokio Marine Management (TMM), themanagement company for the Tokio Marine Nishido familyof insurance companies operating in the United States,committed to improve IT controls on identity and accessmanagement (IDM) due to the two factors. First, growth inthe number of applications now required an enterpriseapproach for more secure and efficient IDM. Secondly,TMM was subjected to complying with Japan’s FinancialInstrument and Exchange Law (FIEL). FIEL is similar tothe United States’ Sarbanes-Oxley law and commonlyreferred to as ‘J-SOX1’. From the IDM standpoint, theobjectives of both regulations are similar. TMM identified61 key Information Technology General Controls (ITGC)for J-SOX compliance with eight related to IDM. The natureof the controls and their effectiveness is proprietaryinformation. This IDM solution considered each of theseeight key controls and provided the functionality to ensurethe controls were effective. The external auditors found noITGC deficiencies after deploying this IDM solution. SeeTable 1 for the list of requirements. This paper shows howTMM accomplished meeting regulatory compliance and theissues encountered.

The company has 459 employees, 170 non-employees and generates $500M in revenue. There areseven offices with headquarters in New York City NY. TheIT staff, mostly located in New York City, employs 47people and manages primarily the Windows platform alongwith Red Hat and Solaris. Third parties host someapplications on the mainframe and client-server platforms.

TMM did not use an enterprise directory orfeatures like LDAP2 for authentication and authorizationmaking access management difficult. Organizationstypically have many applications built on legacytechnology, and it therefore is impractical to interface with a

central directory.3 Adding such functionality to newapplications would have increased development costs andextended their ‘go live’ target deadlines4. TMM devised asolution to improve managing entitlements to theseapplications without affecting them operationally. TMM hadto ensure that the provisioning (which includes de-provisioning) tasks were effective and adhere to corporatepolicy across 87 applications, 723 Active Directory groups,304 Lotus Notes groups, 300+ servers, 298 roles, and17,982 entitlements for 629 people. We also had to ensurethat ‘orphaned accounts’ were eliminated. Orphanedaccounts are active accounts for terminated people, whichpresent a security threat by potentially allowingunauthorized access5.

TMM built a stand-alone application that manageswork orders, which represent access entitlements andleveraged existing, manual provisioning. This avoids theissues related to automated provisioning and directorysynchronization, both of which present more risk andcomplexity than TMM was willing to undertake. The twodrivers to this solution were: 1) fixed compliance deadline;and 2) there was no reason to take on the difficulties indeveloping automated provisioning and directorysynchronization when these functions could be purchased inthe future, if required. The improvements over the priorentitlement processes relate to a new governance modelwith automated workflows, authoritative sources, a centralrepository, and easier recertification and reconciliationprocesses.

The original access processes were paper-basedwith no effective automation. Determining the status of anaccess request was difficult due to the request existingsomewhere in an email. There was no definitive way toassociate all accounts for a single person without aconsolidation of the entitlements. In terminating a person,Human Resources would address an email using adistribution list, which notified all downstream accountadministrators that, ‘Joe Bloggs resigned.’ ‘Joe Bloggs’ wasusually not the account identifier, which compromised thede-provisioning task due to lack of specificity. This requiredthe downstream account administrators to resolve: ‘What isJoe’s identifier in the each system?’ Terminated staff attimes, left orphaned accounts due to the absence ofconsolidated entitlements. There was no authoritative sourcefor non-employees, which means there was no reliablerecord of non-employees engaged with the firm.Reconciliation of a downstream directory was an impreciseprocess due to the absence of a definitive, commonidentifier and, for non-employees, the lack of anauthoritative source with which to reconcile against. Therewas a clear need for new processes and tools to achievemore effective and efficient identity management objectivesand meet regulatory compliance.

If there were only one directory for validatingauthentication and authorization requests, accessmanagement would have been considerably easier toimplement and maintain. It is precisely due to having morethan one directory that raises problems for IDM:synchronization is required and we found more than 80application directories. Potential security and audit issues



(e.g., separation of duties conflicts and orphaned accounts)lingered in the absence of a consistent, enterprise-wideapproach for trans-directory integrity, workflows, accountprovisioning, and recertification. Options were to eitherimplement a commercial IDM product or build a bespokeapplication. Commercial products can require significantcustomization, which translates into expense andcomplexity. A Request for Information initiative disclosedthat commercial products were beyond the available budget.See Rencana’s The Impact of Total Cost of Ownership inIAM Investment Decisions6, which compares the costs offive commercial products. The TMM solution presents asignificantly lower Total Cost of Ownership due to theabsence of licensing, service, and customizations fees.Using the Rencana model for medium sized firms (7,500end users), it is estimated that TMM’s Total Cost ofOwnership, using five year present value, is about 80% lessthan the commercial products in the Rencana report7.

Given the time and budget constraints, TMMdecided to develop a custom application and TMM launchedproject ‘Paladin’ in April 2010. This decision seemscounterintuitive, but we limited the scope and complexity ofthe application, which minimized the development effortand focused our resources to meet specifically statedobjectives and nothing more.

Minimizing complexity was a key factor and takingon too much functionality would have jeopardized the timeconstraint. The complexity included how to addressdirectory synchronization, associating accounts to a person,and removing accounts for terminated staff. Automatedprovisioning requires customizations for each directory tosynchronize with the authoritative source. TMM’s diversityof applications, each with its unique directory structure,across multiple computing platforms (i.e., Windows, Linux,Solaris, OS/2, MVS/370), presented a significant challengefor automating account provisioning. In response, Paladindid not automate account provisioning and kept the manualtasks in place using a common repository to organize IDMobjects through managed work orders. This also added abenefit for its security: as a system gets more complex, theyget less secure8. Paladin became the basis of this pragmaticapproach to IDM and allowed TMM to defer automatedprovisioning to commercial products, if, and when, time andbudget became available and after achieving the 2010objectives.

A significant issue concerned relating accounts topeople. One person has many accounts, usually withdifferent identifiers. Accounts were difficult to tie back toan individual in the absence of a common key. Joe Bloggs’identifiers could be ‘JBloggs,’ BloggsJo,’ ‘XE34R,’ etc.,and names make poor identifiers. Imprecise accountassociations raise various security risks by producingorphaned accounts, not knowing who has what rights towhich applications, or making it difficult to determine ifthere is separation of duties issue9. ‘Recertification,’ theperiodic validation of rights, helps ensure that when a rolechanges, a person will only have the rights they need toperform their job. Prior to Paladin, recertification wasdifficult due to relying on a person’s name. Role-baseaccess control is one of the more difficult aspects of IDM,

due to the dynamics of people, titles, roles and the numberof resources, and in TMM’s case, managing almost 18,000entitlements. The Ponemon Institute notes that‘organizations are not able to keep pace with changes inusers’ roles as a result of transfers, terminations, andrevisions to job responsibilities. As a result, they faceserious noncompliance and business risks.’10 Paladinaddressed role-base access control via the ‘role prototype’and entitlement recertification, both of which will follow.

The Paladin Application

The project, code name ‘Paladin,’ built a customapplication to manage the representation of access rights (orentitlements) for more than 1,100 IDM-related resources.Note that Paladin does not manage the actual, operationalaccess rights. Paladin manages representations of these IDMobjects in a stand-alone data store. The development teamcomprised of two people. One and one-half full timeequivalent (FTEs) developed Paladin within six months.One web developer, a contractor, worked full time for sixmonths and the other one-half FTE was the project manager,who was also the business analyst, database designer andconversion analyst. Paladin’s implementation uses two non-dedicated servers, one to host the web-based application andthe other for the database.

Paladin provided a foundation for optionallyimplementing a third-party product since defining resources,roles, and associating account identifiers to people is alsorequired for any IDM solution. This effort focused onidentifying and resolving the data relationships amongpeople, resources, entitlements, and roles. Sinceauthentication and authorization for applications does notrequire Paladin in real-time, employing other products withfeatures such as LDAP does not present a conflict in theapproach. TMM can still leverage the IDM objects if, andwhen, the firm acquires a commercial product.

Managers request entitlements for their staff. Thevarious departments designated ‘resource owners,’ whoapprove entitlement requests to their applications,represented as resources in Paladin. The help desk staffedthe downstream account administrator positions. Humanresources, the authoritative source for employees, add andterminate employees. All other people with access rights areconsidered non-employees, which includes contractors,vendors, temporary staff, external auditors, etc. Theauthoritative source for non-employees is the hiringmanager, who adds and terminates these people using thePaladin web interface. Recertification calls for 1) managersrecertifying the non-employees on their staff; 2) humanresources recertifying employees; and 3) resource ownersrecertifying entitlements.

Impact on the Staff

Paladin users are those people designated asmanagers, resource owners, account administrators, humanresource specialist, or Paladin administrators. The totalnumber of users was 163 people out of a population of 629.Access to the application requires membership in any of fiveActive Directory groups where each group represents adifferent Paladin role (e.g., manager, resource owner, etc.,).



Membership in these groups determines which menu itemsare exposed and limits the user’s actions in the application.Paladin treats membership in these groups as any otherresource managed by Paladin and subject to the sameworkflows and recertification processes. Managers now usea web interface to request an entitlement. For training, themanagers received a video file consisting of screen shotswith narrated animations of the manager functions. Therewere 132 managers out of 459 employees. The projectmanager trained the 48 resource owners and 38 useradministrators using a web-based meeting tool wheretrainees can see the trainer’s web session. We conductedtwo sessions for each of these two user groups.

A Two Phased Approach

1. Phase One: Meta-directory, workflows, conversion,and recertify people and entitlements

2. Phase Two: Directory reconciliation, Separation ofDuties and reporting

Phase One – The Meta-Directory, Workflows,Converting the Data, and Recertification

We inventoried the various identity managementobjects, and due to the number of them and theirrelationships, we employed database technology to organizethe results. The database, or meta-directory, is a repositoryfor all IDM objects such as applications, people, groups,staff organization, and entitlements11.

Managers request access rights for their staff andresource owners approve or reject these requests (SeeFigure 1). The account administrators receive work orders(i.e., approved requests) from the meta-directory and mustupdate their downstream directories accordingly. They thenadd the new account identifier to the work order, whichrepresents the entitlement in the meta-directory. This updateis key in Paladin’s ability to provide significant value whileavoiding the synchronization complexities. Having theaccount identifier in the meta-directory now enables easierreconciliation by comparing it to the one in the downstreamdirectory. An application’s account naming standard isirrelevant to Paladin and there is no requirement that JoeBloggs has to have the same account identifier in every

directory. Storing the account identifier in the meta-directory also avoids converting identifiers in thedownstream directories. The alternative is standardizing allaccount identifiers for a person, which represents significanteffort and risk. The risk stems from an adverse impact onthe business, as imperfect changes to the account identifierswill disrupt a person’s access.

The account administrator is the ‘synchronizer’between the meta-directory and the downstream directories(See Figure 2). Paladin had little impact on the accountadministrators. They still maintained accounts as they didprior to Paladin, so little training was required. Theworkflow provided them with a queue of pending workorders through a web interface. The account administrator’srole actually diminished in the reconciliation task: forautomatable directory extracts, account administrators wereno longer involved, save applying corrections. More onreconciliation will follow.

The meta-directory does not perform real-timeauthentication or authorization nor does it containpasswords. The only interfaces with other systems are theemployee roster file and a real-time Active Directory updatefor terminations. This design avoids integration issues andrun-time complexities. Programming began with processingthe employee roster file, which contains all activeemployees and relevant details. A comparison between theroster file and the meta-directory generates additions (i.e.,new hires), changes, and deletions (i.e., terminated staff)and updates the meta-directory. For terminated staff, Paladininvokes the de-provisioning process, which triggers theremoval of all entitlements. The hiring manager, using aweb browser, provides the additions, changes, and



terminations for their non-employees. One part-time (0.1FTE) Paladin administrator keeps the meta-directory up todate with new resources.

The next step was to define the relevant roleswithin the resources. Roles represent authorization rights foran application and were well understood, since they arealready in use. Resource owners can add specific roles toresources as required.

Automating workflows entailed defining thevarious work order status fields and based on values in thesefields, presenting the work orders to a user for some actionvia the web user interface. When requesting an entitlement,the manager selects a staff member, resource, role andenvironment (i.e., production, test, etc.,). For example,‘supervisor’ or ‘service manager’ are roles for the customerinformation system, the resource. Relationships betweenresources and roles support the presentation of the list ofrelevant roles for a resource when requesting entitlements.In this manner, a manager is limited to selecting a role fromonly those roles defined to a resource12. Upon approval ofan entitlement request, the downstream accountadministrator creates the account in the downstreamapplication and closes the work order by including the newaccount identifier. This keeps the downstream directory insynchronization with the meta-directory and supportssubsequent reconciliations between them. (See Figure 3)

A decision was required regarding if existing rightsshould be loaded into the meta-directory. The case for notconverting was to avoid adding suspect data to the newmeta-directory. Not converting them would require thatmanagers enter new entitlements for their staff. It wasunacceptable to ask managers to enter over 17,000entitlements and therefore the employees’ rights wereconverted. However, we did not convert entitlements fornon-employees due to not having had an authoritativesource for them. In this case, the managers did create newnon-employee records and entitlements. This was areasonable foundation for populating the new meta-directory. The conversion used the available accountinformation in each user directory and transformed it into anentitlement record in the meta-directory with the associationto (hopefully) the proper person. The quality of thisassociation was dependent on data available in thedownstream directory, which was not always adequate.Reconciliation in Phase Two addresses discovering andcorrecting discrepancies in the data conversion as well asday-to-day entitlement processing13.

The ‘role prototype’



To assist managers requesting entitlements, Paladinprovides a special type of person object, the ‘roleprototype.’ The role prototype is a set of fictitious persons,such as ‘Claims Manager’ and associates a set ofentitlements with this ‘person.’ Hiring or promoting a realperson as a ‘Claims Manager’ automatically assigns all ofthe entitlements defined for that role prototype. Identifyingthe various role prototypes required working with humanresources to standardize job titles and determine whichentitlements are appropriate for each job. The role prototypeserves as a starting point for assigning access rights and thenthe manager adds or removes specific rights. There is stilladditional work required to complete the implementation ofthis feature mostly due to the efforts in normalizing jobtitles, descriptions, and identifying appropriate resources.TMM uses job titles to help comply with various states’labor regulations and therefore titles provide little help inapplying role-based access control. Additional functionaljob titles are required and entail considerable effort.Applying role-based access control is an ongoing challengeand continues to require efforts from IT, business units, andhuman resources due to refinements, legacy resources, androle changes14. A benefit of using role prototypes is thatthey abstract much of the technology internals (i.e., ActiveDirectory group memberships, virtual private network, etc.,)which confuses managers15. A manager can choose fromover 1,100 resources and understanding which ones arerelevant has been overwhelming. We could not implementall role-prototypes within the available time; however, wecould address the remaining ones after the initial applicationdeployment.

Recertification: Periodically Confirming Access Rights

Phase One implements recertification, whichseparately validates people and entitlements. Paladin sendsemail notifications every day within 15 days of anexpiration date to managers, who recertify non-employees,or resource owners, who recertify rights (See figure 4).Both people and rights have expiration dates. The employeeroster file recertifies each employee every time HR submitsthe file. The hiring manager recertifies their non-employeesevery 90 days. Ignoring a recertification request willautomatically invoke the termination tasks after theentitlement or person’s expiration date passes. ThisDraconian tactic provides a fail-safe mechanism againstexpired rights or people no longer engaged with the firm.

Phase One delivered the functionality to meetcompliance and security objectives. However, it provides noway to validate the downstream directories. Phase Two’sreconciliation feature provides that mechanism.

Phase Two: Reconciliation, Separation of Duties andReporting

Reconciliation compares a downstream directory’sentries with the corresponding entitlements in the meta-directory. This task recognizes errors caused by theprovisioning functions or other out-of-synchronizationconditions. For example, there may have been terminationsbut the downstream directory still has active accounts forthese former people (i.e., orphaned accounts).Reconciliation automatically recognizes if there are moreentries in the user directory than in the meta-directory(evidence of an unauthorized change) or if there are missingentries in the user directory (evidence of either a timingissue or an ignored work order)16.

In pre-Paladin, reconciliation was a an arduousprocess, manually extracting data from the downstreamdirectories into spreadsheets and, using whatever data wasavailable, matching entries against the employee roster file(another spreadsheet). This match was susceptible toincorrect pairings or non-matches due to using namesinstead of unique keys (i.e., the account identifier).

Within Paladin, the reconciliation process extractsa downstream directory’s contents and adds them to themeta-directory’s reconciliation table. A computer programthen matches on the account identifiers and detectsdiscrepancies. Each discrepancy generates a corrective workorder for the account administrator. Automating theextraction task is dependent on the availability andcomplexity of the downstream directory. If the directory isaccessible, a computer program performs the extract andloads the entries into Paladin. If the directory is not directly



accessible or the data structures containing the account IDand role information is too complex to extract usingautomation, the account administrator extracts or obtains thedata into a standardized file, as in pre-Paladin. A directorymay not be available if a vendor manages it in a hostedenvironment, and TMM had several. The project assessedeach downstream directory in terms of priority and degreeof difficulty to automate the extraction. Regardless of usingautomation or a manual task for extraction, the subsequentsteps (i.e., matching, discrepancy detection, work ordergeneration) are identical and use the same program code(See figure 5). Standardizing the data extraction and theconsistent format of the meta-directory objects eases thereconciliation process. The frequency of discrepanciespointed out the error rates for each downstream accountadministrator and guided any needed remediation.

Separation of Duties (SoD)

The effort to implement role prototypes provided asecond dividend after enabling role-base access controls.This ability detects and prevents requesting access rightsthat would create a Separation of Duties conflict.Segregation of Duties is the separation of incompatibleduties that could allow one person to commit and concealfraud that may result in financial loss or misstatement to thecompany. Segregation of duties may be within anapplication or within the infrastructure.17

Business and IT subject matter experts, workingtogether, identified role pairs that represented SoD conflicts.These ‘role pairs’ were incorporated into the meta-directory.When an entitlement was requested, the ‘role pairs’ wouldbe checked if there was already an existing entitlement that,with this additional, new entitlement, would create an SoD

conflict. Upon detecting this situation, the requestor wouldbe prevented from completing the request.

Since the SoD conflict prevention wasimplemented after the conversion of the pre-Paladin existingentitlements, a program was written to look for existingentitlements, for individuals, that would now be consideredan SoD conflict. This report runs whenever there arechanges made to the SoD ‘role pair’ table.

Reporting

Reporting is facilitated entirely from the datacontained in the Paladin meta directory. Each recordcontains attributes that define status, data of status change,date of insertion, last modification, deletion, etc., so thatcomprehensive reports can be created. No records are everphysically deleted from the meta directory. A scheme isused to ‘logically’ delete records, which easily identifieswhich records are ‘active’ and which records would havebeen deleted if physical deletions were performed. Inaddition, a separate table is used as a repository forrecording defined transactions or other activities (i.e.,tracing). Records are inserted into this table when an eventoccurs. Suitable encoding enables reporting events for avariety of perspectives, include chronological, specificapprover, account administrator, reconciliation, separationof duties conflicts, etc.,

Lessons Learned

The most difficult task was organizing the sheernumber of Active Directory groups that were in use withouta definitive understanding how each related to a particularjob function. Group names provide few clues regarding howthey are used. Managers were uncertain when to include anentitlement that required one of these groups. While the roleprototypes help reduce this confusion, managing anddocumenting these groups still requires effort mapping allgroups to role prototypes or retiring them.

Conclusion

TMM remediated all issues related to identitymanagement and passed JSOX compliance. The securityposture improved via the continual confirmation of accountsand roles. Terminating accounts after their expiration datehas passed now automatically generates termination workorders. Paladin uses a single process for all entitlements,which eliminates user’s confusion regarding how to obtainaccess to a resource. Business owners have control as towho can perform which functions within their applications.This IDM approach also provides an attractive Total Cost ofOwnership when compared to the implementation of acommercial product.

On the technology side, Paladin’s single repositoryfor all IDM objects facilitates data management and audittrails. Paladin achieved directory synchronization withoutthe complexity required by automated synchronization.Isolating the meta-directory from the downstream userdirectories resulted in no operational impact on applications,which reduces operational risk. Reconciliation essentially



audits each directory against an authoritative source torecognize and correct errors. Supplementing manual taskswith automated workflows and database technologycircumvents the complexities of end-to-end automateddirectory synchronization and provisioning. These benefitstaken together, Paladin offers a pragmatic approach for aneffective IDM system.

References

Office of Government Commerce, ITIL Service Design, U.K.,2007, www.tso.co.uk

ISO, ISO/IEC 27002:2005 Information technology -- Securitytechniques -- Code of practice for information securitymanagement

Biography

Hank Gruenberg, CISM, CRISC, PMP, is responsible forIT compliance and information security at Tokio MarineManagement, Inc., a property-casualty insurance company. Hisbackground includes having founded, developed and brought tomarket JetAlerts, Inc., conceived and designed the Paladin IDM

methodology and used it to remediate I.T. controls to achieveregulatory compliance.

Publications: “Establishing the Year 2000 TestingEnvironment,” Year/2000 Journal, (1999)

Hank has also worked with Marsh & McLennan,American Express, Merrill Lynch, Wolters Kluwer, MacMillanPublishing, Dun & Bradstreet, McNeil Pharmaceutical,International Flavors & Fragrances, Core States Bank, TravelersInsurance in both employee and consulting roles.

He holds an M.S.C.S. from Villanova University, aB.B.A. from Temple University, and awarded certifications:Certified Information Security Manager, Certified in Risk andInformation Systems Controls, Project Management Professional,and ITIL Foundation v2 and v3.

Contact Hank at [email protected]

Endnotes

1 J-SOX is the nickname of Japan's Financial Instruments and ExchangeLaw, which was promulgated in June 2006. Inspired by corporate scandalssuch as the Kanebo, Livedoor, and Murakami Fund episodes, the law isreferred to as the Japanese version of the Sarbanes-Oxley Act, hence J-SOX2 Internet Engineering Task Force (IETF), Lightweight Directory AccessProtocol, Standard Track Requests for comments (RFCs) as detailed in RFC45103 Williamson, Graham, et. al., Identity Management: A Primer, (KetchumID: Mc Press, 2009), location 274 Mather, Tim, et. al., Cloud Security and Privacy (Theory inPractice),(Sebastopol CA: O’Reilly Media, 2009), location 2485 Op cit. Williamson, location 1186 Rencana LLC, www.rencanallc.com7 Paladin five year Present Value (PV) is $571,738 compared to $2,865,712for the lowest PV in the Rencana report.8 Schneier , Bruce, Secrets and Lies: Digital Security in a Networked World,(Indianapolis: Wiley Publishing, Inc., 2004), location 58389 Todorov, Dobromir, Mechanics of User Identification and Authorization:Fundamentals of Identity Management, (Boca Raton: AuerbachPublications, 2007), location 27810 Ponemon Institute, 2008 National Survey on Access Governance – U.S.Study of IT Practitioners, 2008, reprinted with permission.11 Windley, Phillip J., Digital Identity, (Sebastopol CA: O’Reilly Media,2008), location 8512 Op cit. Williamson, location 11813 ibid., location 14514 ibid., location 9015 Ferraiolo, David F., et. al., Role-Base Access Control (Norwood: ArtechHouse, 2003), p. 2916 Scheidel, Jeff, Designing an IAM Framework with Oracle Identity andAccess Management Suite, (New York: McGraw-Hill, 2010), location 155817 Deloitte Development LLC. Segregation of Duties Solutions

pragmatic identity & access management

Documents