Regulatory Compliance Using Identity Management

Regulatory Compliance
Using Identity Management
2013 Hitachi ID Systems, Inc. All rights reserved.
Regulations such as Sarbanes-Oxley, FDA 21-CFR-11 and HSPD-12 require stronger security, to protect
sensitive business processes. Regulations such as Gramm-Leach-Bliley, HIPAA, PIPEDA and the EU Privacy Protection Directive 2002/58/EC require stronger security, to protect the privacy of investors, patients,
consumers and citizens, respectively.
Security in every multi-user application depends on authentication, authorization and audit infrastructure
(AAA). In turn, this infrastructure depends on complete, current and accurate data about users. In particular,
dormant and orphan accounts must be reliably deactivated, and privilege creep must be addressed.
Identity management systems enable reliable maintenance of data about users and their security rights. In
turn, this supports reliable AAA and therefore regulatory compliance.
Contents
1 Introduction
2 Identity Management System Components
2.1
Enterprise Identity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2
Business Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3
Functional Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Authentication
3.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2
Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3
Security Benefits of Identity Management
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Authorization
4.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2
Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Audit
10
5.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2
Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.3
5.4
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Regulatory Compliance Using Identity Management
6 Summary
12
7 References
13
2013 Hitachi ID Systems, Inc. All rights reserved.
Introduction
Corporations and non-profit organizations, such as Universities or Government agencies, are increasingly
subject to regulations that have an impact on IT governance. Regulations such as Sarbanes-Oxley, FDA
21-CFR-11 and HSPD-12 require stronger security, to protect sensitive business processes. Regulations
such as Gramm-Leach-Bliley, HIPAA, PIPEDA and the EU Privacy Protection Directive 2002/58/EC require
stronger security, to protect the privacy of investors, patients, consumers and citizens, respectively.
The common theme in all of these regulations is that IT security is crucial, to protect both corporate governance and privacy. Since every multi-user computer system depends on authentication, access controls
and audit logs (AAA) for its security, it follows that the regulatory environment mandates an effective AAA
infrastructure.
AAA is not new: one form of AAA or another has been embedded into every multi-user application since
early mainframes in the 1960s. The weakness in most systems is not their ability to authenticate users,
control their access rights and audit their actions, but rather in the fact that these run-time decisions depend
on accurate and reliable user data. As the number of users in a typical enterprise IT environment has
grown, and as the number of systems and applications has multiplied, it has become increasingly difficult
to maintain accurate and reliable data about very user on every system.
Identity management systems are intended to overcome this problem, by automating user administration
processes, so that data about users, how they are authenticated, and what rights they have can be maintained more efficiently and reliably.
This document outlines a variety of problems that can arise with user profile data, the impact of those
problems on the efficacy of an enterprise AAA infrastructure, and the solutions that an identity management
system can bring to bear to eliminate those problems.
The remainder of this document is organized as follows:
Identity Management System Components
Describes the elements of an identity management system that may be deployed in an enterprise
network.
Authentication
Describes user authentication processes, how they can fail, and what identity management systems
can do to eliminate these failures.
Authorization
Describes access authorization processes, how they depend on user profile data, and what identity
management systems can do to ensure that user profile data is accurate and reliable.
Audit
Describes access audit processes, their limitations and how those limitations can be overcome using
an identity management system.
Summary
A summary of the concepts presented earlier.
2013 Hitachi ID Systems, Inc.. All rights reserved.
2
2.1
Identity Management System Components

Enterprise Identity Management
This document focuses primarily on identity management inside the enterprise, managing internal users
employees, contractors, vendors, etc. Internal users are qualitatively different than external users, in
that they are relatively few (thousands, not millions), and complex (having tens of login accounts and user
objects each, many of which may be inaccurate, uncorrelated or obsolete).
Without an identity management system, users are managed by separate administrators, using separate
software tools, and often separate business processes, on each system. This is illustrated in Figure 1.
Business Processes
Hire
IT Processes
Retire
Transfer
Resign
Fire
Finish Contract
Start Contract
New Application
Retire Application
Password Expiry
Password Reset
Users
Passwords
Operating
System
Directory
Application
Database
E-mail
System
ERP
Legacy
App
Mainframe
Groups
Attributes
Systems and Applications
Figure 1: Managing Each Application in its own Silo

An identity management system is used to externalize the administration of user objects, replacing processes that are implemented within each system and application with new processes that apply uniformly
to all users, on all systems. This simpler process is illustrated in Figure 2.
Business Processes
Hire
IT Processes
Retire
Transfer
Resign
Fire
Finish Contract
Start Contract
New Application
Retire Application
Password Expiry
Password Reset
Identity Management System
Users
Passwords
Operating
System
Directory
Application
Database
E-mail
System
ERP
Legacy
App
Mainframe
Groups
Attributes
Systems and Applications
Figure 2: Externalizing the Management of Users and Entitlements
2.2
Business Processes
As illustrated in Figure 2, an identity management system connects to multiple, existing systems where user
objects are stored, and manages them cohesively. It does this as the end-product of one or more business
processes, which drive changes to user definitions.
Identity management systems may implement any of the following business processes:
Auto-provisioning:
Detect new user records on a system of record (such as HR) and automatically provision those users
with appropriate access on other systems and applications.
Auto-deactivation:
Detect deleted or deactivated users on an authoritative system and automatically deactivate those
users on all other systems and applications.
Identity synchronization:
Detect changes to personal data, such as phone numbers or department codes, on one system and
automatically make matching changes on other systems for the same user.
Self-service requests:
Enable users to update their own profiles (e.g., new home phone number) and to request new entitlements (e.g., access to an application or share).
Delegated administration:
Enable managers, application owners and other stake-holders to modify users and entitlements within
their scope of authority.
Access certification:
Periodically invite managers and application owners to review lists of users and security entitlements
within their scope of authority, flagging inappropriate entries for further review and removal.
Authorization workflow:
Validate all proposed changes, regardless of their origin and invite business stake-holders to approve
them before they are applied to integrated systems and applications.
Consolidated reporting:
Provide data about what users have what entitlements, what accounts are dormant or orphaned,
change history, etc. across multiple systems and applications.
2.3
Functional Components
Breaking processes down further, enterprise identity management systems may expose some subset of
the following functions:
Identity administration and governance:
Connectors, to read current state from and write updates to user objects on integrated systems
and applications.
Automatically propagate changes from one system (such as HR) to other systems (such as
directories, mail systems, databases, servers, etc.).
A request portal, where users can ask to change their own or others profiles and can request
additional access rights.
An authorization workflow engine, to route change requests to appropriate business stakeholders for approval.
Various policy engines, to enforce rules such as segregation of duties or role based access
control.
Access certification / attestation.
Reports, dashboards and analytics, to examine current state, historical access rights, trends and
more.
Credential management:
Self-service management of passwords, security questions and other authentication factors by
users.
Managed enrollment of data such as security questions or voice biometrics.
Assisted service, enabling help desk and other privileged users to reset user passwords or clear
lockouts without needing full administrative rights.
Privileged access management:
Automatic discovery and classification of systems and accounts.
Scheduled and event-triggered randomization of passwords on privileged accounts.
Encrypted and replicated storage of privileged credentials.
Temporary privilege escalation for existing users.
Single sign-on and other access disclosure mechanisms, allowing administrators to connect to
shared, privileged accounts conveniently, securely and with clear audit records.
Integration with unattended infrastructure, such as Windows service accounts and applicationto-application accounts, to reduce the prevalence of embedded, plaintext passwords.
Identity management systems are closely related to access management systems, which may consolidate
or strengthen user authentication processes (i.e., single, strong sign-on) and may enforce authorization
policies at run-time. These include:
Strong authentication, using smart cards, tokens and biometrics.
Web single sign-on (Web-SSO), typically using cookies to maintain session state, but increasingly
using federation protocols such as SAML and WS-Security.
Web access management (Web-AM), typically integrated with Web-SSO, which enforce runtime decisions about whether users should be allowed to access specific servers, URLs or application features.
Authentication
3.1
Overview
Users typically sign into systems and directories by typing a personal login ID and password. In most
organizations, if a user forgets his password, or inadvertently mistypes it often enough to trigger an intruder
lockout, the user may call the help desk, identify himself, and request a new password.
3.2
Vulnerabilities
This process can create multiple security vulnerabilities, exposing sensitive systems and data to access by
unauthorized users:
Weak passwords: Short, simple or static passwords can be cracked by password guessing programs,
or by patient intruders.
Too many passwords: Users with too many passwords will write them down, and so reduce systems
security to be equivalent to physical security. In many organizations, a large physical perimeter means
that physical security is very weak.
Caller authentication: Help desks often fail to reliably authenticate callers, and so can be convinced
by an intruder to mistakenly reset an intended victims password. Many help desks authenticate callers
by asking for some part of their social security numbers or birth-dates neither of which are hard for
an intruder to acquire.
Credential proliferation: In many help desks, a large number of support staff have administrative
rights to target systems, required to provide the password reset service. This is contrary to security
best practice, which is to minimize the number of people with administrative rights (reducing the attack
surface). Turnover among support staff also creates security security concerns.
Audit logs: Few systems log administrative password resets, or attribute them to specific support
staff. Consequently, there is no accountability for who reset whose password, when and why, as
would be required in response to a security incident.
3.3
All of the above problems can be addressed by an effective identity management system:
Weak passwords: Password synchronization systems can enforce a strong password policy, including minimum length, frequent expiry, history and complexity whenever a user changes passwords.
This ensures that passwords are difficult to crack, and expire long before the time required to crack
them.
Strong authentication products also works to eliminate weak passwords, typically requiring that users
submit multiple authentication factors.
Too many passwords: Both password synchronization and single signon systems eliminate the need
for users to remember multiple passwords. A single, strong, regularly changed password is much
more secure than multiple passwords written down.
Caller authentication: Self-service and assisted password reset systems can be configured to implement a robust process for authenticating users who forgot or locked out their password. This may
include a prompting users to answer a combination of user-defined and standard questions, or resort
to another authentication factor, such as a hardware token or biometric sample, prior to a password
reset.
Credential proliferation: By delegating the right to reset passwords, separately from other privileges,
password reset systems eliminate the need to give support staff administrative rights.
Audit logs: Password reset systems can audit all password resets, both self-service and assisted.
3.4
Summary
Vulnerabilities in a typical password-based authentication infrastructure can be eliminated using a combination of:
Password synchronization.
Self-service and assisted password reset.
Single sign-on.
Multi-factor authentication.
Authorization
4.1
Overview
Most systems control user access to data by first authenticating users (see previous section), and then
checking each attempted user action against a privilege model.
Users gain access to sensitive systems and data first by having a login account on the system in question,
and secondarily by having specific privileges on that system. Users may be granted privileges directly, or
in relation to specific resources (e.g., folders, shares, printers, screens, menus, etc.). Users may acquire
privileges by virtue of membership in a security group, which itself has been assigned privileges.
Most large systems rely heavily on user groups to manage privileges, since assigning fine-grained rights
individually to many users is too onerous. As a result, the rights a user has across multiple systems in
an organization can usually be expressed as a function of which accounts the user has, and what security
groups the user belongs to on each system.
4.2
Vulnerabilities
The authorization infrastructure in most systems and applications is technically effective, but relies on data
about user rights, which may be inaccurate:
Login accounts: Accounts may be orphaned meaning that their users have left the organization,
or dormant meaning that the user no longer needs them.
Accounts may be active, but have no known owner, which eliminates the possibility of making users
accountable for their actions.
Security group memberships: Users may be assigned inappropriate privileges, either due to failure
to standardize access rights in conformance with policy, or in compliance with out-of-date policies.
Users may belong to groups which grant them no-longer-needed privileges. This is a result of privilege
accumulation, whereby users gain new rights as their responsibilities change, but where their old (and
no longer needed) rights are not reliably deactivated. This compromises the security principle of least
privilege.
Conflicting privileges: Users may have multiple privileges, which are reasonable individually but
violate the need for separation of duties in combination. A traditional example for this is a user who
can both submit purchase orders and issue payments, thereby circumventing traditional accounting
controls.
4.3
The above problems can be addressed by an effective identity management system:

Orphan accounts:
One function of any enterprise identity management system is to construct enterprise-wide user profiles, which connect user objects on multiple systems to single owners. Orphan accounts can be
identified once this process is complete, as they are the accounts with no known owners.
Typically a user provisioning system will be used to first deactivate orphan accounts, and wait to see
their (legitimate) owners complain. After some time, orphan accounts can be removed, reducing the
security attack surface and possibly also software licensing costs, where they are tied to the number
of user objects.
Dormant accounts:
A user provisioning system can be used to identify dormant accounts, by inspecting the last-login-time
attribute of each user. Dormant accounts can be eliminated in the same way as orphan accounts.
On systems where there is no record of last login time, accounts can be connected to user profiles,
and if the primary login account in the profile is inactive, it may be assumed that all other accounts
are likewise dormant.
Standardized privileges:
By creating accounts through the user provisioning system, rather than directly using a variety of
native user administration tools, organizations can enforce standards regarding login account configuration, to ensure that new users get appropriate privileges when their login IDs are created.
Privilege accumulation:
A privilege auditing system can be used to periodically review the rights of all users. Managers,
application owners and group owners can identify and remove inappropriate privileges, that were
either improperly assigned or retained beyond their relevance.
The same system can also be used to identify orphan and dormant accounts.
Separation of duties:
A user provisioning system can be used to prevent users from acquiring inappropriate privilege combinations. It can also be used to report on such combinations where they exist prior to deployment of
the system, so that some or all of the offending privileges can be removed.
4.4
Summary
The combination of a user provisioning system and a privilege auditing system can be used to find and
remove:
Orphan and dormant accounts.
Inappropriate privileges, whether accumulated over time or improperly granted at account creation
time.
Inappropriate combinations of rights, that would violate rules requiring separation of duties.
Audit
5.1
Overview
Audit logs are intended to make users accountable for their actions. Various regulations that impact IT
security require logging of changes to financial data, attempts to access private information, various authorizations and digital signatures.
The degree to which common systems and applications log events of interest is variable. For example, most
systems record failed login attempts and user lockouts, but not all systems record successful user logins.
Financial and clinical systems log authorizations and signatures, but other systems dont. Many systems
do not log user administration actions, such as the creation of new users, changes to user privileges or
deactivation of user access.
In almost all cases, audit logs are internal to systems and applications. Events on different systems may be
difficult or impossible to correlate, as would be required in a forensic audit to establish a pattern of activity.
Beyond local storage, a challenge for event correlation is that users often have different login IDs on different
systems, and so audit logs on one system cannot be readily connected to those on another.
5.2
Vulnerabilities
Limited, system-specific audit logs present some security challenges to enterprises who must protect multiple, sensitive systems:
Event correlation: It is difficult to match security events on one system to those on another if user
identifiers are different and not otherwise correlated.
Privilege audit: It is difficult to quickly answer the question who has the following privileges? when
the privileges span multiple systems.
Privilege history: It is impossible to quickly answer the question who had the following privileges at
a given date? when systems do not log privilege changes.
Record of authorization: Most systems do not audit security change requests or authorization, since
these happen out of band with respect to the administrative user interface. Moreover, use of generic
administrator accounts and limited audit capabilities mean that most systems cannot even report on
when a given privilege was assigned to a user, or by whom.
Appropriate privileges: Systems and applications cannot determine whether privileges granted to
their own users are appropriate. Instead, administrators are presumed to assign privileges in a manner appropriate to business requirements.
5.3
An identity management system can resolve all of these audit challenges:
10
Event correlation: Login ID reconciliation is pre-requisite to the deployment of any enterprise identity
management system. Consequently, data from any enterprise identity management system can be
used to correlate event logs between multiple systems and applications.
Privilege audit and history: A user provisioning system, configured to monitor and manage privileges on multiple systems, can be used to report on current and historical privileges.
Record of authorization: Where the user provisioning system is used to request and authorize
security changes (e.g., using a workflow engine), it can report on this change history. Where changes
are made through an automated process, it can at least report on which system of record triggered
changes. Where a consolidated or delegated user administration model is used, the user provisioning
system can report on which administrator initiated the change.
Appropriate privileges: A privilege audit system engages business stakeholders, such as managers,
application owners and group owners, to review privileges and make an informed decision about
whether they are appropriate.
5.4
Summary
A user provisioning system, combined with a privilege auditing system, can significantly improve the ability
of an organization to create accountability, and to find and remove inappropriate security privileges.
11
Summary
Regulations increasingly demand that corporations and non-profit organizations implement sound IT security to protect privacy and ensure sound governance.
Most systems and applications already incorporate authentication, authorization, and audit (AAA) infrastructure with which to do this. Unfortunately, AAA infrastructure is vulnerable to weaknesses in security-related
business processes and to improper user privilege definitions.
An identity management system, including user provisioning, password synchronization and reset and privilege audit can be used to address shortcomings in security business processes and inappropriate user
privileges, which would otherwise undermine a AAA infrastructure.
These identity management features can be supplemented by strong authentication technology, single signon and web access management systems.
12
References
Hitachi ID is an enterprise identity management software vendor:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . http://Hitachi-ID.com/
Hitachi ID Identity Manager is a user provisioning solution from Hitachi ID:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . http://Hitachi-ID.com/Identity-Manager/
Hitachi ID Password Manager is a password synchronization and password reset solution from Hitachi ID:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . http://Hitachi-ID.com/Password-Manager/
Hitachi ID Access Certifier is a privilege audit solution from Hitachi ID:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . http://Hitachi-ID.com/Access-Certifier/
500, 1401 - 1 Street SE, Calgary AB Canada T2G 2J3 Tel: 1.403.233.0740 Fax: 1.403.233.0725 E-Mail: sales@Hitachi-ID.com
www.Hitachi-ID.com
File: /pub/wp/documents/idm-compliance/idm-compliance-1.tex
Date: June 20, 2005

Regulatory Compliance Using Identity Management

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Regulatory Compliance Using Identity Management

Uploaded by

Copyright:

Available Formats

Regulatory Compliance

Using Identity Management

2013 Hitachi ID Systems, Inc. All rights reserved.

2 Identity Management System Components

Enterprise Identity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Security Benefits of Identity Management

Security Benefits of Identity Management

Security Benefits of Identity Management