HIPAA Compliance - Using the Hitachi ID Identity Management Suite

HIPAA Compliance
Using the
Hitachi ID Systems Management Suite
© 2014 Hitachi ID Systems, Inc. All rights reserved.

This Hitachi ID Systems, Inc. whitepaper explores the Health Insurance Portability and Accountability Act
and how it impacts organizations within the healthcare sector. Read about what the Act entails and how it
inﬂuences identity management in these organizations. Learn physical and technical safeguards in addition
to Hitachi ID Systems’s straight forward and easy solutions to meet HIPAA regulations. The information
outlined here is garnered from over nine years of providing our over 650 customer with practical everyday
solutions to their identity management needs, including compliance issues.
Contents
1 Introduction 1
2 The Health Insurance Portability and Accountability Act 1
2.1 Compliance dates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.2 Penalties for privacy violations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
3 Relevant Sections 3
3.1 Administrative Safeguards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1.1 Security Management Process (164.308)(a)(1) . . . . . . . . . . . . . . . . . . . . 3
3.1.2 Assigned Security Responsibility (164.308)(a)(2) . . . . . . . . . . . . . . . . . . . 4
3.1.3 Workforce Security 164.308(a)(3) . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.4 Information Access Management 164.308(a)(4) . . . . . . . . . . . . . . . . . . . 4
3.1.5 Security Awareness and Training 164.308(a)(5) . . . . . . . . . . . . . . . . . . . . 4
3.1.6 Security Incident Procedures 164.308(a)(6) . . . . . . . . . . . . . . . . . . . . . . 5
3.1.7 Contingency Plan 164.308(a)(7) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.8 Evaluation 164.308(a)(8) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Physical Safeguards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3 Technical Safeguards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.1 Access Controls 164.312(a)(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.2 Audit Controls 164.312(b) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.3 Integrity 164.312(c)(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.4 Person or Entity Authentication 164.312(d) . . . . . . . . . . . . . . . . . . . . . . 7
3.3.5 Transmission Security 164.312(e)(1) . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4 National Institute of Standards and Technology 8
5 Impact of HIPAA on Identity Management 13
i

HIPAA Compliance Using The Hitachi ID Systems Identity Management Suite
6 Hitachi ID Systems Solutions Meeting HIPAA Requirements 15
6.1 The Hitachi ID Systems Identity Management Suite . . . . . . . . . . . . . . . . . . . . . . . 15
6.2 Meeting HIPAA Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7 Summary 24
8 References 25
© 2014 Hitachi ID Systems, Inc. All rights reserved.

1 Introduction
This Hitachi ID Systems, Inc. whitepaper explores the Health Insurance Portability and Accountability Act
and how it impacts organizations within the healthcare sector. Read about what the Act entails and how it
influences identity management in these organizations. Learn physical and technical safeguards in addition
to Hitachi ID Systems’s straight forward and easy solutions to meet HIPAA regulations. The information
outlined here is garnered from over nine years of providing our over 650 customer with practical everyday
solutions to their identity management needs, including compliance issues.
This document gives a brief introduction to the Health Insurance Portability and Accountability Act, and
describes how it impacts information security in healthcare organizations in the US.
The Hitachi ID Systems Identity Management Suite is then introduced, and its use to comply with the
requirements set forth in the Health Insurance Portability and Accountability Act is described.
Please note that this document does not constitute legal advice, or a legal interpretation of the Health
Insurance Portability and Accountability Act. This document represents the best understanding of Hitachi ID
Systems of the relevance of this legislation to information security, and to identity management in particular.
2 The Health Insurance Portability and Accountability Act
HIPAA legislation was originally enacted to provide Health insurance to someone leaving a job. It then added
an additional goal to provide administrative simplification by setting out standards for electronic transactions.
Because of the sensitivity of medical information, it became necessary to stipulate security standards for
electronic documents pertaining to healthcare patients. These standards are now required to be in place
for the following entities:
• Health Care Providers – any provider of health care services who transmits health information in
electronic form.
• Health Plans – any plan that pays for health care products and services.
• Health Care Clearinghouses – any person or company that processes health care transactions.
2.1 Compliance dates
The Health Insurance Portability and Accountability Act came into effect on April 21, 2003. Covered entities,
with the exception of small health plans, are to comply with the requirements as of April 21, 2005. Small
health plans (defined as having annual receipts of $5 Million or less) must comply by April 21, 2006.
2.2 Penalties for privacy violations
A person who knowingly obtains or discloses individually identifiable health information in violation of HIPAA
faces a fine of $50,000 and up to one-year imprisonment. The criminal penalties increase to $100,000 and
© 2014 Hitachi ID Systems, Inc.. All rights reserved. 1

up to ﬁve years imprisonment if the wrongful conduct involves false pretenses, and to $250,000 and up to ten
years imprisonment if the wrongful conduct involves the intent to sell, transfer, or use individually identiﬁable
health information for commercial advantage, personal gain, or malicious harm. Criminal sanctions will be
enforced by the Department of Justice.

3 Relevant Sections
The Health Insurance Portability and Accountability Act includes a Security Rule, which requires Health
Care providers, Health plans and Health Care Clearinghouses to assure their customers that the conﬁden-
tiality, availability and integrity of their electronic health is protected, both in storage and during transmission.
The HIPAA Security Rule has been categorized into three main areas. Each area is a collection of safe-
guards designed to help those complying with the act to address legal obligations and to implement systems
and processes supporting compliance. These categories are:
• Administrative safeguards:
Administrative actions, policies, and procedures, to manage the selection, development, implementa-
tion, and maintenance of security measures to protect electronic protected health information and to
manage the conduct of the covered entity’s workforce in relation to the protection of that information.
• Physical safeguards:
Security measures to protect a covered entity’s electronic information systems and related buildings
and equipment from natural and environmental hazards and unauthorized intrusion.
• Technical safeguards:
Technology and the policy and procedures for its use that protect electronic protected health informa-
tion and control access to it.
Of these three areas, administrative and technical safeguards are supported by identity management tech-
nology, as described below:
3.1 Administrative Safeguards
3.1.1 Security Management Process (164.308)(a)(1)
Implement policies and procedures to prevent, detect, contain and correct security violations.
Identity Management Impact:
Preventing security violations requires effective user authentication and authorization. Detecting security
violations requires effective audit trails and alarms, plus human monitoring of those logs and alarms.
Containing and correcting violations requires human response.
Authentication, authorization and audit together are referred to as AAA. AAA infrastructure is at the
core of any identity management system.

3.1.2 Assigned Security Responsibility (164.308)(a)(2)
Identify the security official who is responsible for the development and implementation of the policies and
procedures required.
A security official needs to be assigned who is able to assess, implement and monitor the organization’s
security, including identity management processes and technical infrastructure.
3.1.3 Workforce Security 164.308(a)(3)
Implement policies and procedures to ensure that all members of a healthcare organization’s workforce have
appropriate access to electronic protected health information, and to prevent those workforce members who
do not have access from obtaining access to electronically protected health information.
As with Subsubsection 3.1.1 on Page 3, this requires effective AAA in systems that house and transmit
protected health information.
Firm policies must be in place concerning staff access rights, as well as timely adjustments to elec-
tronic systems to reflect the hiring, promotion, demotion, and termination of staff.
3.1.4 Information Access Management 164.308(a)(4)
Implement policies and procedures for authorizing access to electronic protected health information that
are consistent with the applicable requirements of privacy of Individually Identifiable Health Information.
As with Subsubsection 3.1.1 on Page 3, this requires not only effective AAA in systems that house and
transmit protected health information, but also effective processes to manage the data used by AAA infras-
tructure. Standards and policies must be in place concerning the authorization of access as well as the
process for restricting access once that access becomes inappropriate.
3.1.5 Security Awareness and Training 164.308(a)(5)
Implement security awareness and training program for all members of its workforce (including manage-
ment).

This typically includes both an acceptable use policy, and ongoing user education. All users must be aware
of the present security policies, and procedures need to be in place to encourage enforcement.
3.1.6 Security Incident Procedures 164.308(a)(6)
Implement policies and procedures to address security incidents.
Response to security incidents depends heavily on effective audit records. In many cases, audit records on
different systems must be correlated to one another, which depends on matching event time and originating
device, and also on matching login IDs across systems back to a human user.
The latter – login ID reconciliation – is a core element of any identity management system.
3.1.7 Contingency Plan 164.308(a)(7)
Establish (and implement as needed) policies and procedures for responding to an emergency or other
occurrence (for example, ﬁre, vandalism, system failure, and natural disaster) that damages systems that
contain electronic protected health information.
The implication here is that every system, including those systems used to manage user access to patient
data, must be supported by a disaster recovery capability.
3.1.8 Evaluation 164.308(a)(8)
Perform a periodic technical and non technical evaluation, based initially upon the standards implemented
under this rule and subsequently, in response to environmental or operational changes affecting the security
of electronic protected health information, that establishes the extent to which an entity’s security policies
and procedures meet the requirements of this subpart.

Creating and documenting processes is not enough. Security must be tested, and weaknesses corrected.
Some of the most common security vulnerabilities in a typical network environment are technically
simple, but their impact is serious:
• Users with trivial and unchanging passwords.
• Passwords written down or shared.
• Weak processes, vulnerable to social engineering, at the corporate help desk to authenticate callers
prior to offering them a password reset.
• User access to systems or data persisting long after the user requires that access, and indeed in
many cases long after the user is employed by the organization.
All of the above problems are likely to be raised by a routine security audit, and are readily addressed using
effective password management and user provisioning systems.
3.2 Physical Safeguards
Note that while physical safeguards are very important, they are beyond the scope of this document. Please
refer to the following sections of HIPAA to learn more.
• Facility Access Controls 164.310(a)(1)
• Workstation use 164.310(b)
• Workstation Security 164.310(c)
• Device and Media Controls 164.310(d)(1)
3.3 Technical Safeguards
3.3.1 Access Controls 164.312(a)(1)
Implement technical policies and procedures for electronic information systems that maintain electronic
protected health information to allow access only to those persons or software programs that have been
granted access rights as speciﬁed in Sec. 164.308(a)(4). (Note: Supports the Information Access Manage-
ment Administrative Standard and Facility Access Controls Physical Standard)
As with Subsubsection 3.1.1 on Page 3, this requires effective AAA in systems that house and transmit
protected health information.

3.3.2 Audit Controls 164.312(b)
Implement hardware, software, and/or procedural mechanisms that record and examine activity in informa-
tion systems that contain or use electronic protected health information.
This requires audit logs of access to systems and data (the third A in AAA). Logging cannot exist in a
vacuum, it must be checked and reviewed for any security violations.
3.3.3 Integrity 164.312(c)(1)
Implement policies and procedures to protect electronic protected health information from improper alter-
ation or destruction.
This requires authorization over changes to data and usage in health information systems (2nd A in AAA),
and audit of those changes (3rd A in AAA).
3.3.4 Person or Entity Authentication 164.312(d)
Implement procedures to verify that a person or entity seeking access to electronic protected health infor-
mation is the one claimed.
This is a clear requirement for reliable user authentication (1st A in AAA).
3.3.5 Transmission Security 164.312(e)(1)
Implement technical security measures to guard against unauthorized access to electronic protected health
information that is being transmitted over an electronic communications network.
This calls for both access authorization (2nd A in AAA) and for technical measures to protect data transmis-
sion (e.g., encryption in transit).

4 National Institute of Standards and Technology
The National Institute of Standards and Technology (NIST) has provided a number of recommendations for
providing stronger security in health care. The NIST special publication “An Introductory Resource Guide
for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule” provides
further recommendations for security.
This document is available at:
http://csrc.nist.gov/publications/drafts/DRAFT-sp800-66.pdf
The above, HIPAA-specific document also refers to NIST’s security checklist – “NIST Security Self Assess-
ment Guide for Information Technology Systems” as a template for federal agencies and private corpora-
tions to use in evaluating their information security.
This document is available at:
http://csrc.nist.gov/publications/nistpubs/800-26/sp800-26.pdf
“The NIST Security Self Assessment Guide” includes, among others, the following instructions, which relate
to identity management:
• 6.1. Are duties separated to ensure least privilege and individual accountability?
Since managing user access to multiple applications is complex and time consuming, a policy of least
privilege is often not well enforced. Consolidating the administration of users and their privileges
makes it more feasible to enforce a policy of least privilege.
While most systems implement some audit trails, login IDs on different systems are often un-
connected to one another, or indeed to specific human users. As a result, accountability can be
compromised. Connecting login IDs to one another, and to human owners, makes it possible to
extend technical audit trails to real world accountability.
• 6.1.1 Are all positions reviewed for sensitivity level?
(See also: FISCAM SD-1.2, NIST SP 800-18)
A periodic review of user access to systems and data is hard enough on a single system, and nearly
impossible across a large organization and many users. Periodic audit of user rights requires signifi-
cant automation and consolidated access to user rights in order to be realistically implemented.
• 6.1.2 Are there documented job descriptions that accurately reflect assigned duties and responsibili-
ties and that segregate duties?
(See also: FISCAM SD-1.2)

Managing user access to systems through user assignment to job functions, and connection of job
functions to specific privileges across multiple systems, is called role engineering, and in practice has
rarely if ever been successfully completed in a large organization.
Short of full-fledged role engineering, an identity management system can at least identify cur-
rent user privileges, and require authorized stake-holders, such as managers or application owners,
to periodically review and either accept or revoke them.
Segregation of duties is also feasible with an identity management system, as specific privi-
lege pairs can be identified as mutually exclusive. Doing so does not require full modeling of user
privileges – just identification of privileges that should never be held by a single individual.
• 6.1.3 Are sensitive functions divided among different individuals?
(See also: OMB Circular A-130, III, FISCAM SD-1, NIST SP 800-18)
As above, an identity management system makes it possible to define functions or privileges that
should be segregated, without resorting to full user access rights modeling / role engineering.
• 6.1.7 Are hiring, transfer, and termination procedures established?
(See also: FISCAM SP-4.1, NIST SP 800-18)
In many organizations, while processes to manage staff in the physical world are well established as
HR functions, matching processes to ensure that logical access matches hires, transfers and fires
may be fragmented or unreliable. An identity management system is an ideal platform for ensuring
that logical access matches personnel status.
• 6.1.8 Is there a process for requesting, establishing, issuing, and closing user accounts?
In addition to coarse-grained access setup and termination, as described above, an identity man-
agement system can enable stake-holders, such as managers, application owners or indeed users
themselves, to request access privilege changes. Such requests are validated, routed to suitable au-
thorizers, approved or rejected, and either automatically applied to systems or forwarded to security
administrators. This functionality is the workflow engine in a user provisioning system.
• 11.2.3 Are procedures in place to determine compliance with password policies?
(See also: NIST SP 800-18)
An identity management system in general, and in particular a password management system, can
be used to enforce arbitrarily secure password policies.

• 14.1. Is there a capability to provide help to users when a security incident occurs in the system?
When users are locked out, or unable to log in, or detect suspicious activity on a system to which
they have access, they must be able to request assistance. When they do so, users must be reliably
authenticated, to prevent an intruder from accessing the help desk service in the guise of a legitimate
user.
An identity management system can support authentication of users who require assistance,
and can provide services such as password reset and intruder unlock in both a self-service and
assisted-service mode.
• 15.1. Are users individually authenticated via passwords, tokens, or other devices?
Sound authentication, using any of these means, can be managed by an identity management system.
• 15.1.1 Is a current list maintained and approved of authorized users and their access?
(See also: FISCAM AC-2, NIST SP 800-18)
An identity management system can automatically maintain a list of users and their privileges on every
system, and leverage this data for access management and periodic review.
• 15.1.4 Is emergency and temporary access authorized?
(See also: FISCAM AC-2.2)
An identity management system can provide a sufficiently rapid access requisitioning system (work-
flow) so that emergency or temporary access can be reliably requested and authorized before it is
granted, and can be automatically terminated after a given time span.
• 15.1.5 Are personnel files matched with user accounts to ensure that terminated or transferred indi-
viduals do not retain system access?
The automated administration component of a user provisioning system can scan personnel files,
project data in these files to desired access on managed systems, and make any administrative
changes required to make actual privileges match those predicted by the system. This process can
automatically deactivate accounts for terminated staff, for example.
• 15.1.6 Are passwords changed at least every ninety days or earlier if needed?
(See also: FISCAM AC-3.2, NIST SP 800-18)

A password management system can make periodic password changes both easier for users to im-
plement and easier for administrators to enforce globally.
• 15.1.7 Are passwords unique and difficult to guess (e.g., do passwords require alpha numeric, up-
per/lower case, and special characters)?
A password management system can enforce strong, global password quality rules.
• 15.1.8 Are inactive user identifications disabled after a specified period of time?
An identity management system can automatically detect and, if appropriate, deactivate dormant
accounts.
• 15.1.10 Are there procedures in place for handling lost and compromised passwords?
A password management system can provide both self-service and assisted-service password resets,
after suitably reliable non-password authentication (e.g., using a challenge-response method based
on personal user information).
• 15.1.11 Are passwords distributed securely and users informed not to reveal their passwords to any-
one (social engineering)?
(See also: NIST SP 800-18)
A user provisioning system can be used to enable secure distribution of initial passwords – for example
by having the manager of new staff specify an initial password, and expiring that password after first
use.
• 15.1.12 Are passwords transmitted and stored using secure protocols/algorithms?
A password management system can ensure that password updates, at least, are made over a secure
channel, such as SSL / HTTPS.
• 15.2.1 Does the system correlate actions to users?

(See also: OMB A-130, III, FISCAM SD-2.1)
An identity management system can be used to correlate login IDs across systems, so that events in
system-specific audit logs can be connected to physical users.
• 15.2.2 Do data owners periodically review access authorizations to determine whether they remain
appropriate?
An identity management system can collect data about users and their privileges, and automate a
periodic review process by managers or application owners.
• 16.1.2 Is there access control software that prevents an individual from having all necessary authority
or information access to allow fraudulent activity without collusion?
Collecting user privileges across systems makes it possible to find and remove users who have con-
flicting privileges, and to ensure that users cannot acquire mutually-exclusive privileges in the future.
• 16.1.5 Are inactive users’ accounts monitored and removed when not needed?
An identity management system can automatically detect and, if appropriate, deactivate dormant
accounts.

5 Impact of HIPAA on Identity Management
Compliance with the HIPAA Security Rule requires many specific processes and technical controls, as
described in the previous sections. The specific identity management requirements are repeated here, with
duplications eliminated:
1. General Requirements
(a) Authentication, authorization and audit (AAA) infrastructure are required in each system and
application, and must be effectively managed. The task of an identity management system is to
more reliably manage existing AAA infrastructure.
(b) A security official needs to be assigned who is able to assess, implement and monitor the orga-
nization’s security, including identity management processes and technical infrastructure.
(c) Firm policies must be in place concerning staff access rights, as well as timely adjustments to
electronic systems to reflect the hiring, promotion, demotion, and termination of staff.
(d) Standards and policies must be in place concerning the authorization of access as well as the
process for restricting access once that access becomes inappropriate.
2. Password Management Requirements
(a) Users must be prevented from choosing easily guessed passwords.
(b) Users must be required to periodically change their passwords.
(c) Users must be reliably authenticated when they require assistance from IT support staff – with
system access, password resets, intruder lockouts, and other security services.
3. User Provisioning Requirements
(a) User access to systems or data must not be allowed to persist beyond the time when the user
legitimately requires that access, and never after the user leaves the organization.
(b) Enforce segregation of duties by identifying privileges that should never be held by a single
individual, and preventing new occurrences.
(c) Map authoritative data about hires, transfers and terminations to systems access privileges, to
automatically create, modify and deactivate systems access following staff status changes.
(d) Provide a reliable workflow process to enable stake-holders, such as managers, application own-
ers or users to request access privilege changes. Such requests must be validated, routed to
suitable authorizers, approved or rejected, and either automatically applied to systems or for-
warded to security administrators.
(e) Ensure that access requisitioning and authorization processes are sufficiently efficient (fast,
easy) to support emergency and temporary access rights.
(f) Ensure that access requisitioning and authorization processes include a pre-defined termination
date, so that they can be safely used to grant emergency or temporary access.
(g) Detect and, if appropriate, automatically deactivate dormant accounts.
(h) Ensure that initial passwords are distributed securely to users.

4. Data Cleansing and Correlation Requirements
(a) Audit records on different systems must be correlated to one another, which requires matching
login IDs across systems back to human users.
5. Access Audit Requirements
(a) Identify current user privileges, and require authorized stake-holders, such as managers or ap-
plication owners, to periodically review and either accept or revoke them.
(b) Enforce segregation of duties by identifying privileges that should never be held by a single
individual, and locating and removing violations.

6 Hitachi ID Systems Solutions Meeting HIPAA Requirements
6.1 The Hitachi ID Systems Identity Management Suite
The Hitachi ID Management Suite is an integrated solution for identity administration and access gover-
nance. It streamlines and secures the management of identities, security entitlements and credentials
across systems and applications. Organizations deploy the Management Suite to strengthen controls, meet
regulatory and audit requirements, improve IT service and reduce IT operating cost.
The Management Suite is designed to efficiently create, manage and deactivate user objects, identity at-
tributes and security entitlements across systems and applications in medium to large organizations. This
is done using a combination of automation and self-service:
• Automation propagates changes from one system to another.
• Workflow invites business users to participate by completing their own profiles, authorizing changes
and reviewing the current state of users and privileges.
• Consolidated management enables security staff to manage access with a user-centric, rather than
application-centric view.
• Password synchronization and enterprise single sign-on reduce the number of passwords that users
must remember and type.
• Reports enable auditors, security officers and system administrators to analyze current state and
review historical changes.
A rich set of connectors are included, to easily integrate with most common systems and applications and
to manage credentials including passwords, challenge/response profiles, biometric samples, OTP devices,
PKI certificates and smart cards.
The Management Suite is designed as identity management and access governance middleware, in the
sense that it presents a uniform user interface and a consolidated set of business processes to manage
user objects, identity attributes, security rights and credentials across multiple systems and platforms. This
is illustrated in Figure 1.
Figure 1: Management Suite Overview: Identity Middleware
Employees, contractors,
customers, and partners
Users Hitachi ID
Management Suite
Target Systems
Business processes
Synch./Propagation
Request/Authorization
Delegated Administration
Consolidated Reporting
User Objects
Attributes
Passwords
Privileges
Related Objects
Home Directories
Mail Boxes
PKI Certs.
The Management Suite includes several functional identity management and access governance modules:
• Hitachi ID Identity Manager – User provisioning, RBAC, SoD and access certification.

– Automated propagation of changes to user profiles, from systems of record to target systems.
– Workflow, to validate, authorize and log all security change requests.
– Automated, self-service and policy-driven user and entitlement management.
– Federated user administration, through a SOAP API (application programming interface) to a
user provisioning fulfillment engine.
– Consolidated access reporting.
Identity Manager includes the following additional features, at no extra charge:
– Hitachi ID Access Certifier – Periodic review and cleanup of security entitlements.
* Delegated audits of user entitlements, with certification by individual managers and applica-
tion owners, roll-up of results to top management and cleanup of rejected security rights.
– Hitachi ID Group Manager – Self service management of security group membership.
* Self-service and delegated management of user membership in Active Directory groups.
– Hitachi ID Org Manager – Delegated constuction and maintenance of Orgchart data.
* Self-service construction and maintenance of data about lines of reporting in an organization.
• Hitachi ID Password Manager – Self service management of passwords, PINs and encryption keys.
– Password synchronization.
– Self-service and assisted password reset.
– Enrollment and management of other authentication factors, including security questions, hard-
ware tokens, biometric samples and PKI certificates.
Password Manager includes the following additional features, at no extra charge:
– Hitachi ID Login Manager – Automated application logins.
* Automatically sign users into systems and applications.
* Eliminate the need to build and maintain a credential repository, using a combination of
password synchronization and artificial intelligence.
– Hitachi ID Telephone Password Manager – Telephone self service for passwords and tokens.
* Turn-key telephony-enabled password reset, including account unlock and RSA SecurID
token management.
* Numeric challenge/response or voice print authentication.
* Support for multiple languages.
• Hitachi ID Privileged Access Manager – Control and audit access to privileged accounts.
– Periodically randomize privileged passwords.
– Ensure that IT staff access to privileged accounts is authenticated, authorized and logged.
• Group Manager is available both as a stand-alone product and as a component of Identity Manager.
The relationships between the Management Suite components is illustrated in Figure 2 on Page 17.

Figure 2: Components of the Management Suite
6.2 Meeting HIPAA Requirements
As described in Section 5 on Page 13, the Health Insurance Portability and Accountability Act security rule
calls for a variety of technical and process controls, which map to a range of identity management functions.
The Hitachi ID Management Suite meets every requirement defined in Section 5, as follows:
Req. Management Suite Feature
2a Hitachi ID Password Manager normally enforces a global password policy to supplement
the various policies enforced on each system and application. This policy ensures that
passwords accepted by Password Manager will work on every system.
The built-in policy engine includes over 50 built-in rules regarding length, mixed-case,
digits, dictionary words and more. Regular expressions and plug-ins enable organizations
to define new rules. Password history is infinite by default.
2b Password Manager can invite users to change their passwords with a web portal before
they expire. These invitations can be sent via e-mail or launched in a web browser when
users sign into their PCs. Users can even be forced to change passwords by launching a
kiosk-mode web browser at login time.
Password change notices are normally only sent at the start of users’ work day and work
week, to discourage users from changing passwords right before leaving work and
subsequently forgetting the new password.

2c Users may authenticate into Management Suite as follows:
• On the web portal:
– By typing their current password to a trusted system (e.g., Windows/AD, LDAP,
RAC/F, etc).
– By answering security questions.
– Using a security token (e.g., SecurID pass-code).
– Using a smart card with PKI certiﬁcate.
– Using Windows-integrated authentication.
– Using a SAML or OAuth assertion issued by another server.
– By typing a PIN that was sent to their mobile phone via SMS.
– Using a combination of these mechanisms.
• Using a telephone, calling an automated IVR system:
– By keying in numeric answers to a series of security questions (e.g., employee
number, date of hire, driver’s license number).
– By speaking one or more phrases, where the Management Suite server
compares the new speech sample to one on record (biometric voice print
veriﬁcation)
• Using a telephone, calling an IT support technician:
– By answering a series of security questions, where the technician must type the
answers into a web portal to authenticate the caller.

3a Several processes are available for timely and reliable user access termination. Choice of
the appropriate process depends on an organization’s business requirements and
preferences:
• Scheduled access termination
Some workers, such as contractors, summer students and temporary staff, have
pre-defined termination dates. These dates can be entered or loaded into Hitachi ID
Identity Manager.
A scheduled batch process runs periodically on the Identity Manager server and
checks for scheduled terminations. It can send e-mails to managers in advance,
allowing them to update termination dates (e.g., defer them). It can disable users
whose termination date has passed and it can delete, move or reassign accounts,
mail boxes, home directories etc. for users who have been disabled for a sufficiently
long amount of time.
• HR-initiated access termination
HR staff can mark employees and contractors1
either with a termination date, which
is processed as described above or as already terminated. The Identity Manager
automation engine can periodically poll the HR system for such changes and
automatically disable login access for every newly-terminated user.
• Manager-initiated access termination
Managers can use the same change request process to request updates to a user’s
termination date and status. This can be used to schedule or defer termination or to
request immediate deactivation. Requests are routed to authorizers by e-mail, who
respond on a secure, authenticated web form. Once deactivation requests are
approved and/or a user’s termination date has elapsed, all login IDs for the indicated
user are disabled.
• Urgent access termination
A web-based user management interface allows security administrators to terminate
access to any user, on any combination of systems, immediately. This is used for
urgent termination scenarios.
3b Accounts and group memberships can be flagged as mutually exclusive. Business logic in
the Identity Manager workflow engine can prevent conflicting resources from being
requested for a single user.
1If contractors are tracked in an HR or similar application

3c Automated user management works by monitoring one or more systems of record and
waiting for changes to user profile data. Detected changes are then:
1. Filtered, so that only changes within the scope of the system remain.
2. Transformed, from the data format of the system of record, to the data format of the
identity management and access governance system and of the target systems.
3. Forwarded, from the identity management and access governance system to target
systems.
Some examples of auto-provisioning/auto-deactivation are:
1. Payroll staff create a record for a new hire in the HR application. The user
provisioning system detects this event, notes that it is in scope and reformats the
event into workflow requests to create a Windows/AD account, an Exchange
mailbox and a mainframe login ID.
2. HR staff set a termination date for an employee in the HR application. The user
provisioning system detects this and sets the same date in the user’s IAM profile. A
batch process runs nightly and automatically submits “deactivate all accounts”
workflow requests for every user whose termination date has passed.
3. A rogue administrator adds his accomplice’s login account to the Domain Admins
AD group. The user provisioning system detects this new group membership,
removes the user from the group and sends an SMS message describing what it
detected to a security officer.

3d Users can sign into the Identity Manager web portal and make updates to their own
profiles. This includes changes to their contact information and requests for new access to
applications, shares, folders, etc.
Profile updates are subject to:
• Access control policies. For example, users may be able to see but not modify their
job code or pay grade.
• Field- and form-level validation rules. For example, the area code in a user’s phone
number may have to match the city in which the user resides.
• Authorization rules. For example, changes to a user’s department code may have to
be approved by both the old and new department managers.
Changes to a user’s roles, accounts or security groups are subject to policy as well:
• What entitlements a user can see or request is limited by policy.
• Requests must not create an end-state which violates SoD policy.
• Changes to a user’s entitlements are normally routed to application owners and/or
managers for approval.
3e The Identity Manager workflow is simple to use, and so is preferred by users, who can
expect results faster than they would be able to get with manual processes.
3f All Identity Manager workflow requests can include a termination date, and a built-in
process includes advance warning, on-time deactivation, and later deletion.

3g Identity Manager can be used to find orphan and dormant accounts:
• The last login time and date can be extracted from each managed system, for each
user. Users who have not logged in recently can be flagged as dormant accounts.
• Login ID reconciliation data can connect dormant accounts on one system, to
unmarked accounts on another system, which may not track last login date.
• Login ID reconciliation data can be used to identify accounts that have no apparent
owner – i.e., they exist in the login ID inventory on a system, but no current user has
attached the account to his or her own profile.
The lists of dormant and orphan accounts generated in this way are tentative and should
not in general be automatically disabled. For example, apparently-dormant accounts may
simply be infrequently used, while apparently-orphan accounts may simply not yet have
been attached to their owner’s profile.
Orphan and dormant account lists can and should be manually reviewed, to remove
obvious errors. The resulting, sanitized lists should be resubmitted to Identity Manager
first to batch-disable, and later to batch-delete.
The time interval between disabling and deleting orphan accounts gives the owners of
those accounts time to notice the problem and complain, thereby causing their accounts
to be reactivated.
3h Initial passwords may be assigned to newly provisioned accounts in one of two number of
ways:
1. Using a plug-in program, which typically generates a random password value.
2. By having a human requester specify the initial password as a part of the request, so
as to minimize the number of people who know this password.
In any case, initial passwords are normally set to expire after first use, meaning that the
user must change them immediately.
Using Password Manager, the initial password process can be based on security
questions. This means that new users can be assigned a random password plus have
their security questions at least partially populated as a part of the onboarding process.
This way, new users at first login must answer their initial security questions, then populate
additional ones and finally choose their own initial password.

4a Management Suite supports multiple options for login ID reconciliation, as follows:
• Automatically, typically by matching consistent login IDs.
• By matching other attributes such as an SSN or employee ID, where they are
available.
• By drawing on an external source of data – for example, some organizations
maintain a mapping table or spreadsheet.
• Using a self-service reconciliation process.
5a Hitachi ID Access Certifier is a solution for distributed review and cleanup of users and
entitlements. It works by asking managers, application owners and data owners to review
lists of users and entitlements. These stake-holders must choose to either certify or
revoke every user and entitlement.
Access Certifier is included with Identity Manager at no extra cost.
5b Identity Manager can report on current user privileges – essentially a “who has what”
report. User access data extracted by Identity Manager can be applied to business logic,
identifying mutually-exclusive privileges, to find and remove inappropriate access
combinations.

7 Summary
As described in this document, HIPAA introduces formal requirements for healthcare providers and clear-
inghouses to implement strong internal controls, in order to protect the privacy of patient data.
Internal controls imply information security, which in turn requires sound identity management practices,
to ensure that security infrastructure enforces controls based on valid, current information about legitimate
users.
The Hitachi ID Systems identity management suite includes robust, secure, scalable and deployable tech-
nology to implement identity management processes, supporting strong authentication, effective authoriza-
tion and audit ability to ensure accountability.

8 References
The full text of the HIPAA act: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .http://aspe.hhs.gov/admnsimp/pl104191.htm
The HIPAA Security Rule as of February 20, 2003: http://cms.hhs.gov/hipaa/hipaa2/regulations/security/03-
3877.pdf
The NIST document An Introductory Resource Guide for Implementing the Health Insurance Portability and
Accountability Act (HIPAA) Security Rule:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .http://csrc.nist.gov/publications/drafts/DRAFT-sp800-66.pdf
The NIST document Security Self Assessment Guide for Information Technology Systems:
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . http://csrc.nist.gov/publications/nistpubs/800-26/sp800-26.pdf
Hitachi ID Password Manager, the Self service management of passwords, PINs and encryption keys:
http://Hitachi-ID.com/Password-Manager/
Hitachi ID Identity Manager, the User provisioning, RBAC, SoD and access certiﬁcation: . . . http://Hitachi-
ID.com/Identity-Manager/
The Hitachi ID Systems corporate web site: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . http://Hitachi-ID.com/
www.Hitachi-ID.com
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
File: /pub/wp/documents/hipaa/mtech-hipaa-3.tex
Date: Nov 7,2006

HIPAA Compliance - Using the Hitachi ID Identity Management Suite

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (12)

Mehr von Hitachi ID Systems, Inc.

Mehr von Hitachi ID Systems, Inc. (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

HIPAA Compliance - Using the Hitachi ID Identity Management Suite