Pragmatic Identity & Access Management

A Pragmatic Solution for Identity and Access Management 1

Tokio Marine Management (TMM), the central directory. 3 Adding such functionality to new
management company for the Tokio Marine Nishido family applications would have increased development costs and
of insurance companies operating in the United States, extended their ‘go live’ target deadlines4. TMM devised a
committed to improve IT controls on identity and access solution to improve managing entitlements to these
management (IDM) due to the two factors. First, growth in applications without affecting them operationally. TMM had
the number of applications now required an enterprise to ensure that the provisioning (which includes de-
approach for more secure and efficient IDM. Secondly, provisioning) tasks were effective and adhere to corporate
TMM was subjected to complying with Japan’s Financial policy across 87 applications, 723 Active Directory groups,
Instrument and Exchange Law (FIEL). FIEL is similar to 304 Lotus Notes groups, 300+ servers, 298 roles, and
the United States’ Sarbanes-Oxley law and commonly 17,982 entitlements for 629 people. We also had to ensure
referred to as ‘J-SOX1’. From the IDM standpoint, the that ‘orphaned accounts’ were eliminated. Orphaned
objectives of both regulations are similar. TMM identified accounts are active accounts for terminated people, which
61 key Information Technology General Controls (ITGC) present a security threat by potentially allowing
for J-SOX compliance with eight related to IDM. The nature unauthorized access5.
of the controls and their effectiveness is proprietary TMM built a stand-alone application that manages
information. This IDM solution considered each of these work orders, which represent access entitlements and
eight key controls and provided the functionality to ensure leveraged existing, manual provisioning. This avoids the
the controls were effective. The external auditors found no issues related to automated provisioning and directory
ITGC deficiencies after deploying this IDM solution. See synchronization, both of which present more risk and
Table 1 for the list of requirements. This paper shows how complexity than TMM was willing to undertake. The two
TMM accomplished meeting regulatory compliance and the drivers to this solution were: 1) fixed compliance deadline;
issues encountered. and 2) there was no reason to take on the difficulties in
developing automated provisioning and directory
synchronization when these functions could be purchased in
the future, if required. The improvements over the prior
entitlement processes relate to a new governance model
with automated workflows, authoritative sources, a central
repository, and easier recertification and reconciliation
processes.
The original access processes were paper-based
with no effective automation. Determining the status of an
access request was difficult due to the request existing
somewhere in an email. There was no definitive way to
associate all accounts for a single person without a
consolidation of the entitlements. In terminating a person,
Human Resources would address an email using a
distribution list, which notified all downstream account
administrators that, ‘Joe Bloggs resigned.’ ‘Joe Bloggs’ was
usually not the account identifier, which compromised the
de-provisioning task due to lack of specificity. This required
the downstream account administrators to resolve: ‘What is
Joe’s identifier in the each system?’ Terminated staff at
times, left orphaned accounts due to the absence of
consolidated entitlements. There was no authoritative source
for non-employees, which means there was no reliable
record of non-employees engaged with the firm.
Reconciliation of a downstream directory was an imprecise
The company has 459 employees, 170 non- process due to the absence of a definitive, common
employees and generates $500M in revenue. There are identifier and, for non-employees, the lack of an
seven offices with headquarters in New York City NY. The authoritative source with which to reconcile against. There
IT staff, mostly located in New York City, employs 47 was a clear need for new processes and tools to achieve
people and manages primarily the Windows platform along more effective and efficient identity management objectives
with Red Hat and Solaris. Third parties host some and meet regulatory compliance.
applications on the mainframe and client-server platforms. If there were only one directory for validating
TMM did not use an enterprise directory or authentication and authorization requests, access
features like LDAP 2 for authentication and authorization management would have been considerably easier to
making access management difficult. Organizations implement and maintain. It is precisely due to having more
typically have many applications built on legacy than one directory that raises problems for IDM:
technology, and it therefore is impractical to interface with a synchronization is required and we found more than 80
application directories. Potential security and audit issues
COPYRIGHT 2011 HANK GRUENBERG. ALL RIGHTS RESERVED. THIS MATERIAL MAY BE FREELY COPIED AND DISTRIBUTED SUBJECT TO THE INCLUSION OF THIS
COPYRIGHT NOTICE. HGRUENBERG@pragmaticIDM.COM


(e.g., separation of duties conflicts and orphaned accounts) due to the dynamics of people, titles, roles and the number
lingered in the absence of a consistent, enterprise-wide of resources, and in TMM’s case, managing almost 18,000
approach for trans-directory integrity, workflows, account entitlements. The Ponemon Institute notes that
provisioning, and recertification. Options were to either ‘organizations are not able to keep pace with changes in
implement a commercial IDM product or build a bespoke users’ roles as a result of transfers, terminations, and
application. Commercial products can require significant revisions to job responsibilities. As a result, they face
customization, which translates into expense and serious noncompliance and business risks.’10 Paladin
complexity. A Request for Information initiative disclosed addressed role-base access control via the ‘role prototype’
that commercial products were beyond the available budget. and entitlement recertification, both of which will follow.
See Rencana’s The Impact of Total Cost of Ownership in
The Paladin Application
IAM Investment Decisions6, which compares the costs of
five commercial products. The TMM solution presents a The project, code name ‘Paladin,’ built a custom
significantly lower Total Cost of Ownership due to the application to manage the representation of access rights (or
absence of licensing, service, and customizations fees. entitlements) for more than 1,100 IDM-related resources.
Using the Rencana model for medium sized firms (7,500 Note that Paladin does not manage the actual, operational
end users), it is estimated that TMM’s Total Cost of access rights. Paladin manages representations of these IDM
Ownership, using five year present value, is about 80% less objects in a stand-alone data store. The development team
than the commercial products in the Rencana report 7. comprised of two people. One and one-half full time
Given the time and budget constraints, TMM equivalent (FTEs) developed Paladin within six months.
decided to develop a custom application and TMM launched One web developer, a contractor, worked full time for six
project ‘Paladin’ in April 2010. This decision seems months and the other one-half FTE was the project manager,
counterintuitive, but we limited the scope and complexity of who was also the business analyst, database designer and
the application, which minimized the development effort conversion analyst. Paladin’s implementation uses two non-
and focused our resources to meet specifically stated dedicated servers, one to host the web-based application and
objectives and nothing more. the other for the database.
Minimizing complexity was a key factor and taking Paladin provided a foundation for optionally
on too much functionality would have jeopardized the time implementing a third-party product since defining resources,
constraint. The complexity included how to address roles, and associating account identifiers to people is also
directory synchronization, associating accounts to a person, required for any IDM solution. This effort focused on
and removing accounts for terminated staff. Automated identifying and resolving the data relationships among
provisioning requires customizations for each directory to people, resources, entitlements, and roles. Since
synchronize with the authoritative source. TMM’s diversity authentication and authorization for applications does not
of applications, each with its unique directory structure, require Paladin in real-time, employing other products with
across multiple computing platforms (i.e., Windows, Linux, features such as LDAP does not present a conflict in the
Solaris, OS/2, MVS/370), presented a significant challenge approach. TMM can still leverage the IDM objects if, and
for automating account provisioning. In response, Paladin when, the firm acquires a commercial product.
did not automate account provisioning and kept the manual Managers request entitlements for their staff. The
tasks in place using a common repository to organize IDM various departments designated ‘resource owners,’ who
objects through managed work orders. This also added a approve entitlement requests to their applications,
benefit for its security: as a system gets more complex, they represented as resources in Paladin. The help desk staffed
get less secure8. Paladin became the basis of this pragmatic the downstream account administrator positions. Human
approach to IDM and allowed TMM to defer automated resources, the authoritative source for employees, add and
provisioning to commercial products, if, and when, time and terminate employees. All other people with access rights are
budget became available and after achieving the 2010 considered non-employees, which includes contractors,
objectives. vendors, temporary staff, external auditors, etc. The
A significant issue concerned relating accounts to authoritative source for non-employees is the hiring
people. One person has many accounts, usually with manager, who adds and terminates these people using the
different identifiers. Accounts were difficult to tie back to Paladin web interface. Recertification calls for 1) managers
an individual in the absence of a common key. Joe Bloggs’ recertifying the non-employees on their staff; 2) human
identifiers could be ‘JBloggs,’ BloggsJo,’ ‘XE34R,’ etc., resources recertifying employees; and 3) resource owners
and names make poor identifiers. Imprecise account recertifying entitlements.
associations raise various security risks by producing
orphaned accounts, not knowing who has what rights to Impact on the Staff
which applications, or making it difficult to determine if Paladin users are those people designated as
there is separation of duties issue9. ‘Recertification,’ the managers, resource owners, account administrators, human
periodic validation of rights, helps ensure that when a role resource specialist, or Paladin administrators. The total
changes, a person will only have the rights they need to number of users was 163 people out of a population of 629.
perform their job. Prior to Paladin, recertification was Access to the application requires membership in any of five
difficult due to relying on a person’s name. Role-base Active Directory groups where each group represents a
access control is one of the more difficult aspects of IDM, different Paladin role (e.g., manager, resource owner, etc.,).


Membership in these groups determines which menu items directory. Storing the account identifier in the meta-
are exposed and limits the user’s actions in the application. directory also avoids converting identifiers in the
Paladin treats membership in these groups as any other downstream directories. The alternative is standardizing all
resource managed by Paladin and subject to the same account identifiers for a person, which represents significant
workflows and recertification processes. Managers now use effort and risk. The risk stems from an adverse impact on
a web interface to request an entitlement. For training, the the business, as imperfect changes to the account identifiers
managers received a video file consisting of screen shots will disrupt a person’s access.
with narrated animations of the manager functions. There The account administrator is the ‘synchronizer’
were 132 managers out of 459 employees. The project between the meta-directory and the downstream directories
manager trained the 48 resource owners and 38 user (See Figure 2). Paladin had little impact on the account
administrators using a web-based meeting tool where administrators. They still maintained accounts as they did
trainees can see the trainer’s web session. We conducted prior to Paladin, so little training was required. The
two sessions for each of these two user groups. workflow provided them with a queue of pending work
orders through a web interface. The account administrator’s
A Two Phased Approach
role actually diminished in the reconciliation task: for
1. Phase One: Meta-directory, workflows, conversion, automatable directory extracts, account administrators were
and recertify people and entitlements no longer involved, save applying corrections. More on
reconciliation will follow.
2. Phase Two: Directory reconciliation, Separation of
Duties and reporting

Phase One – The Meta-Directory, Workflows,
Converting the Data, and Recertification
We inventoried the various identity management
objects, and due to the number of them and their
relationships, we employed database technology to organize
the results. The database, or meta-directory, is a repository
for all IDM objects such as applications, people, groups,
staff organization, and entitlements11.

Managers request access rights for their staff and
The meta-directory does not perform real-time
resource owners approve or reject these requests (See
authentication or authorization nor does it contain
Figure 1). The account administrators receive work orders
passwords. The only interfaces with other systems are the
(i.e., approved requests) from the meta-directory and must
employee roster file and a real-time Active Directory update
update their downstream directories accordingly. They then
for terminations. This design avoids integration issues and
add the new account identifier to the work order, which
run-time complexities. Programming began with processing
represents the entitlement in the meta-directory. This update
the employee roster file, which contains all active
is key in Paladin’s ability to provide significant value while
employees and relevant details. A comparison between the
avoiding the synchronization complexities. Having the
roster file and the meta-directory generates additions (i.e.,
account identifier in the meta-directory now enables easier
new hires), changes, and deletions (i.e., terminated staff)
reconciliation by comparing it to the one in the downstream
and updates the meta-directory. For terminated staff, Paladin
directory. An application’s account naming standard is
invokes the de-provisioning process, which triggers the
irrelevant to Paladin and there is no requirement that Joe
removal of all entitlements. The hiring manager, using a
Bloggs has to have the same account identifier in every
web browser, provides the additions, changes, and


terminations for their non-employees. One part-time (0.1
FTE) Paladin administrator keeps the meta-directory up to
date with new resources.
The next step was to define the relevant roles
within the resources. Roles represent authorization rights for
an application and were well understood, since they are
already in use. Resource owners can add specific roles to
resources as required.
Automating workflows entailed defining the
various work order status fields and based on values in these
fields, presenting the work orders to a user for some action
via the web user interface. When requesting an entitlement,
the manager selects a staff member, resource, role and
environment (i.e., production, test, etc.,). For example,
‘supervisor’ or ‘service manager’ are roles for the customer
information system, the resource. Relationships between
resources and roles support the presentation of the list of
relevant roles for a resource when requesting entitlements.
In this manner, a manager is limited to selecting a role from
only those roles defined to a resource12. Upon approval of
an entitlement request, the downstream account
administrator creates the account in the downstream
application and closes the work order by including the new
account identifier. This keeps the downstream directory in
synchronization with the meta-directory and supports
subsequent reconciliations between them. (See Figure 3)

A decision was required regarding if existing rights
should be loaded into the meta-directory. The case for not
converting was to avoid adding suspect data to the new
meta-directory. Not converting them would require that
managers enter new entitlements for their staff. It was
unacceptable to ask managers to enter over 17,000
entitlements and therefore the employees’ rights were
converted. However, we did not convert entitlements for
non-employees due to not having had an authoritative
source for them. In this case, the managers did create new
non-employee records and entitlements. This was a
reasonable foundation for populating the new meta-
directory. The conversion used the available account
information in each user directory and transformed it into an
entitlement record in the meta-directory with the association
to (hopefully) the proper person. The quality of this
association was dependent on data available in the
downstream directory, which was not always adequate.
Reconciliation in Phase Two addresses discovering and
correcting discrepancies in the data conversion as well as
day-to-day entitlement processing13.
The ‘role prototype’



To assist managers requesting entitlements, Paladin
provides a special type of person object, the ‘role
prototype.’ The role prototype is a set of fictitious persons,
such as ‘Claims Manager’ and associates a set of
entitlements with this ‘person.’ Hiring or promoting a real
person as a ‘Claims Manager’ automatically assigns all of
the entitlements defined for that role prototype. Identifying
the various role prototypes required working with human
resources to standardize job titles and determine which
entitlements are appropriate for each job. The role prototype
serves as a starting point for assigning access rights and then
the manager adds or removes specific rights. There is still
additional work required to complete the implementation of
this feature mostly due to the efforts in normalizing job
titles, descriptions, and identifying appropriate resources.
TMM uses job titles to help comply with various states’
labor regulations and therefore titles provide little help in
applying role-based access control. Additional functional
job titles are required and entail considerable effort.
Applying role-based access control is an ongoing challenge
and continues to require efforts from IT, business units, and
human resources due to refinements, legacy resources, and
role changes14. A benefit of using role prototypes is that
they abstract much of the technology internals (i.e., Active Phase One delivered the functionality to meet
Directory group memberships, virtual private network, etc.,) compliance and security objectives. However, it provides no
which confuses managers15. A manager can choose from way to validate the downstream directories. Phase Two’s
over 1,100 resources and understanding which ones are reconciliation feature provides that mechanism.
relevant has been overwhelming. We could not implement
all role-prototypes within the available time; however, we Phase Two: Reconciliation, Separation of Duties and
could address the remaining ones after the initial application Reporting
deployment.
Reconciliation compares a downstream directory’s
Recertification: Periodically Confirming Access Rights entries with the corresponding entitlements in the meta-
directory. This task recognizes errors caused by the
Phase One implements recertification, which provisioning functions or other out-of-synchronization
separately validates people and entitlements. Paladin sends conditions. For example, there may have been terminations
email notifications every day within 15 days of an but the downstream directory still has active accounts for
expiration date to managers, who recertify non-employees, these former people (i.e., orphaned accounts).
or resource owners, who recertify rights (See figure 4). Reconciliation automatically recognizes if there are more
Both people and rights have expiration dates. The employee entries in the user directory than in the meta-directory
roster file recertifies each employee every time HR submits (evidence of an unauthorized change) or if there are missing
the file. The hiring manager recertifies their non-employees entries in the user directory (evidence of either a timing
every 90 days. Ignoring a recertification request will issue or an ignored work order)16.
automatically invoke the termination tasks after the In pre-Paladin, reconciliation was a an arduous
entitlement or person’s expiration date passes. This process, manually extracting data from the downstream
Draconian tactic provides a fail-safe mechanism against directories into spreadsheets and, using whatever data was
expired rights or people no longer engaged with the firm. available, matching entries against the employee roster file
(another spreadsheet). This match was susceptible to
incorrect pairings or non-matches due to using names
instead of unique keys (i.e., the account identifier).
Within Paladin, the reconciliation process extracts
a downstream directory’s contents and adds them to the
meta-directory’s reconciliation table. A computer program
then matches on the account identifiers and detects
discrepancies. Each discrepancy generates a corrective work
order for the account administrator. Automating the
extraction task is dependent on the availability and
complexity of the downstream directory. If the directory is
accessible, a computer program performs the extract and
loads the entries into Paladin. If the directory is not directly



accessible or the data structures containing the account ID conflict. Upon detecting this situation, the requestor would
and role information is too complex to extract using be prevented from completing the request.
automation, the account administrator extracts or obtains the Since the SoD conflict prevention was
data into a standardized file, as in pre-Paladin. A directory implemented after the conversion of the pre-Paladin existing
may not be available if a vendor manages it in a hosted entitlements, a program was written to look for existing
environment, and TMM had several. The project assessed entitlements, for individuals, that would now be considered
each downstream directory in terms of priority and degree an SoD conflict. This report runs whenever there are
of difficulty to automate the extraction. Regardless of using changes made to the SoD ‘role pair’ table.
automation or a manual task for extraction, the subsequent
Reporting
steps (i.e., matching, discrepancy detection, work order
generation) are identical and use the same program code Reporting is facilitated entirely from the data
(See figure 5). Standardizing the data extraction and the contained in the Paladin meta directory. Each record
consistent format of the meta-directory objects eases the contains attributes that define status, data of status change,
reconciliation process. The frequency of discrepancies date of insertion, last modification, deletion, etc., so that
pointed out the error rates for each downstream account comprehensive reports can be created. No records are ever
administrator and guided any needed remediation. physically deleted from the meta directory. A scheme is
used to ‘logically’ delete records, which easily identifies
which records are ‘active’ and which records would have
been deleted if physical deletions were performed. In
addition, a separate table is used as a repository for
recording defined transactions or other activities (i.e.,
tracing). Records are inserted into this table when an event
occurs. Suitable encoding enables reporting events for a
variety of perspectives, include chronological, specific
approver, account administrator, reconciliation, separation
of duties conflicts, etc.,
Lessons Learned
The most difficult task was organizing the sheer
number of Active Directory groups that were in use without
a definitive understanding how each related to a particular
job function. Group names provide few clues regarding how
they are used. Managers were uncertain when to include an
entitlement that required one of these groups. While the role
prototypes help reduce this confusion, managing and
documenting these groups still requires effort mapping all
groups to role prototypes or retiring them.

Conclusion

TMM remediated all issues related to identity
management and passed JSOX compliance. The security
posture improved via the continual confirmation of accounts
Separation of Duties (SoD) and roles. Terminating accounts after their expiration date
The effort to implement role prototypes provided a has passed now automatically generates termination work
second dividend after enabling role-base access controls. orders. Paladin uses a single process for all entitlements,
This ability detects and prevents requesting access rights which eliminates user’s confusion regarding how to obtain
that would create a Separation of Duties conflict. access to a resource. Business owners have control as to
Segregation of Duties is the separation of incompatible who can perform which functions within their applications.
duties that could allow one person to commit and conceal This IDM approach also provides an attractive Total Cost of
fraud that may result in financial loss or misstatement to the Ownership when compared to the implementation of a
company. Segregation of duties may be within an commercial product.
application or within the infrastructure. 17 On the technology side, Paladin’s single repository
Business and IT subject matter experts, working for all IDM objects facilitates data management and audit
together, identified role pairs that represented SoD conflicts. trails. Paladin achieved directory synchronization without
These ‘role pairs’ were incorporated into the meta-directory. the complexity required by automated synchronization.
When an entitlement was requested, the ‘role pairs’ would Isolating the meta-directory from the downstream user
be checked if there was already an existing entitlement that, directories resulted in no operational impact on applications,
with this additional, new entitlement, would create an SoD which reduces operational risk. Reconciliation essentially



audits each directory against an authoritative source to methodology and used it to remediate I.T. controls to achieve
recognize and correct errors. Supplementing manual tasks regulatory compliance.
with automated workflows and database technology Publications: “Establishing the Year 2000 Testing
circumvents the complexities of end-to-end automated Environment,” Year/2000 Journal, (1999)
Hank has also worked with Marsh & McLennan,
directory synchronization and provisioning. These benefits American Express, Merrill Lynch, Wolters Kluwer, MacMillan
taken together, Paladin offers a pragmatic approach for an Publishing, Dun & Bradstreet, McNeil Pharmaceutical,
effective IDM system. International Flavors & Fragrances, Core States Bank, Travelers
Insurance in both employee and consulting roles.
He holds an M.S.C.S. from Villanova University, a
References B.B.A. from Temple University, and awarded certifications:
Certified Information Security Manager, Certified in Risk and
Office of Government Commerce, ITIL Service Design, U.K., Information Systems Controls, Project Management Professional,
2007, www.tso.co.uk and ITIL Foundation v2 and v3.
Contact Hank at hank@hankgruenberg.com
ISO, ISO/IEC 27002:2005 Information technology -- Security
techniques -- Code of practice for information security
management

Biography

Hank Gruenberg, CISM, CRISC, PMP, is responsible for
IT compliance and information security at Tokio Marine
Management, Inc., a property-casualty insurance company. His
background includes having founded, developed and brought to
market JetAlerts, Inc., conceived and designed the Paladin IDM
Endnotes

1
J-SOX is the nickname of Japan's Financial Instruments and Exchange
Law, which was promulgated in June 2006. Inspired by corporate scandals
such as the Kanebo, Livedoor, and Murakami Fund episodes, the law is
referred to as the Japanese version of the Sarbanes-Oxley Act, hence J-
SOX
2
Internet Engineering Task Force (IETF), Lightweight Directory Access
Protocol, Standard Track Requests for comments (RFCs) as detailed in RFC
4510
3
Williamson, Graham, et. al., Identity Management: A Primer, (Ketchum
ID: Mc Press, 2009), location 27
4
Mather, Tim, et. al., Cloud Security and Privacy (Theory in
Practice),(Sebastopol CA: O’Reilly Media, 2009), location 248
5
Op cit. Williamson, location 118
6
Rencana LLC, www.rencanallc.com
7
Paladin five year Present Value (PV) is $571,738 compared to $2,865,712
for 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 5838
9
Todorov, Dobromir, Mechanics of User Identification and Authorization:
Fundamentals of Identity Management, (Boca Raton: Auerbach
Publications, 2007), location 278
10
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 85
12
Op cit. Williamson, location 118
13
ibid., location 145
14
ibid., location 90
15
Ferraiolo, David F., et. al., Role-Base Access Control (Norwood: Artech
House, 2003), p. 29
16
Scheidel, Jeff, Designing an IAM Framework with Oracle Identity and
Access Management Suite, (New York: McGraw-Hill, 2010), location 1558
17
Deloitte Development LLC. Segregation of Duties Solutions


Pragmatic Identity & Access Management

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (16)

En vedette

En vedette (11)

Similaire à Pragmatic Identity & Access Management

Similaire à Pragmatic Identity & Access Management (20)