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.

http://Hitachi-ID.com/

http://Hitachi.com/

This Hitachi ID Systems, Inc. whitepaper explores the Health Insurance Portability and Accountability Actand how it impacts organizations within the healthcare sector. Read about what the Act entails and how itinfluences identity management in these organizations. Learn physical and technical safeguards in additionto Hitachi ID Systems’s straight forward and easy solutions to meet HIPAA regulations. The informationoutlined here is garnered from over nine years of providing our over 650 customer with practical everydaysolutions 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 Actand how it impacts organizations within the healthcare sector. Read about what the Act entails and how itinfluences identity management in these organizations. Learn physical and technical safeguards in additionto Hitachi ID Systems’s straight forward and easy solutions to meet HIPAA regulations. The informationoutlined here is garnered from over nine years of providing our over 650 customer with practical everydaysolutions to their identity management needs, including compliance issues.

This document gives a brief introduction to the Health Insurance Portability and Accountability Act, anddescribes 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 therequirements 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 HealthInsurance Portability and Accountability Act. This document represents the best understanding of Hitachi IDSystems 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 addedan 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 forelectronic documents pertaining to healthcare patients. These standards are now required to be in placefor the following entities:

• Health Care Providers – any provider of health care services who transmits health information inelectronic 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. Smallhealth 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 HIPAAfaces 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 five years imprisonment if the wrongful conduct involves false pretenses, and to $250,000 and up to tenyears imprisonment if the wrongful conduct involves the intent to sell, transfer, or use individually identifiablehealth information for commercial advantage, personal gain, or malicious harm. Criminal sanctions will beenforced by the Department of Justice.



3 Relevant Sections

The Health Insurance Portability and Accountability Act includes a Security Rule, which requires HealthCare providers, Health plans and Health Care Clearinghouses to assure their customers that the confiden-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 systemsand 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 tomanage 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 buildingsand 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 securityviolations 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 thecore 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 andprocedures required.


A security official needs to be assigned who is able to assess, implement and monitor the organization’ssecurity, 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 haveappropriate access to electronic protected health information, and to prevent those workforce members whodo 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 transmitprotected 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 thatare 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 andtransmit 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 theprocess 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 awareof 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 ondifferent systems must be correlated to one another, which depends on matching event time and originatingdevice, 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 otheroccurrence (for example, fire, vandalism, system failure, and natural disaster) that damages systems thatcontain electronic protected health information.


The implication here is that every system, including those systems used to manage user access to patientdata, 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 implementedunder this rule and subsequently, in response to environmental or operational changes affecting the securityof electronic protected health information, that establishes the extent to which an entity’s security policiesand 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 technicallysimple, 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 callersprior to offering them a password reset.

• User access to systems or data persisting long after the user requires that access, and indeed inmany 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 usingeffective 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. Pleaserefer 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 electronicprotected health information to allow access only to those persons or software programs that have beengranted access rights as specified 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 transmitprotected 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 avacuum, 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 healthinformation 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 forproviding stronger security in health care. The NIST special publication “An Introductory Resource Guidefor Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule” providesfurther 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 relateto 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 leastprivilege is often not well enforced. Consolidating the administration of users and their privilegesmakes 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 becompromised. Connecting login IDs to one another, and to human owners, makes it possible toextend 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 nearlyimpossible 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 jobfunctions to specific privileges across multiple systems, is called role engineering, and in practice hasrarely 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 userprivileges – 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 thatshould 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 asHR functions, matching processes to ensure that logical access matches hires, transfers and firesmay be fragmented or unreliable. An identity management system is an ideal platform for ensuringthat 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 usersthemselves, 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 securityadministrators. 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, canbe 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 whichthey have access, they must be able to request assistance. When they do so, users must be reliablyauthenticated, to prevent an intruder from accessing the help desk service in the guise of a legitimateuser.

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 andassisted-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 everysystem, 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 isgranted, 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 administrativechanges required to make actual privileges match those predicted by the system. This process canautomatically 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 dormantaccounts.

• 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 basedon 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 exampleby having the manager of new staff specify an initial password, and expiring that password after firstuse.

• 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 securechannel, 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 insystem-specific audit logs can be connected to physical users.

• 15.2.2 Do data owners periodically review access authorizations to determine whether they remainappropriate?



An identity management system can collect data about users and their privileges, and automate aperiodic review process by managers or application owners.

• 16.1.2 Is there access control software that prevents an individual from having all necessary authorityor 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 dormantaccounts.



5 Impact of HIPAA on Identity Management

Compliance with the HIPAA Security Rule requires many specific processes and technical controls, asdescribed in the previous sections. The specific identity management requirements are repeated here, withduplications eliminated:

1. General Requirements

(a) Authentication, authorization and audit (AAA) infrastructure are required in each system andapplication, and must be effectively managed. The task of an identity management system is tomore 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 toelectronic 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 theprocess 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 – withsystem 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 userlegitimately 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 singleindividual, and preventing new occurrences.

(c) Map authoritative data about hires, transfers and terminations to systems access privileges, toautomatically 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 tosuitable 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 terminationdate, 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 matchinglogin 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 singleindividual, 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 credentialsacross systems and applications. Organizations deploy the Management Suite to strengthen controls, meetregulatory 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. Thisis 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 changesand reviewing the current state of users and privileges.

• Consolidated management enables security staff to manage access with a user-centric, rather thanapplication-centric view.

• Password synchronization and enterprise single sign-on reduce the number of passwords that usersmust remember and type.

• Reports enable auditors, security officers and system administrators to analyze current state andreview historical changes.

A rich set of connectors are included, to easily integrate with most common systems and applications andto 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 thesense that it presents a uniform user interface and a consolidated set of business processes to manageuser objects, identity attributes, security rights and credentials across multiple systems and platforms. Thisis 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./PropagationRequest/AuthorizationDelegated AdministrationConsolidated Reporting

User Objects

AttributesPasswordsPrivileges

Related Objects

Home DirectoriesMail BoxesPKI 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 SecurIDtoken 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 rulecalls 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 supplementthe various policies enforced on each system and application. This policy ensures thatpasswords 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 organizationsto define new rules. Password history is infinite by default.

2b Password Manager can invite users to change their passwords with a web portal beforethey expire. These invitations can be sent via e-mail or launched in a web browser whenusers sign into their PCs. Users can even be forced to change passwords by launching akiosk-mode web browser at login time.

Password change notices are normally only sent at the start of users’ work day and workweek, to discourage users from changing passwords right before leaving work andsubsequently 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 certificate.

– 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., employeenumber, date of hire, driver’s license number).

– By speaking one or more phrases, where the Management Suite servercompares the new speech sample to one on record (biometric voice printverification)

• Using a telephone, calling an IT support technician:

– By answering a series of security questions, where the technician must type theanswers into a web portal to authenticate the caller.




3a Several processes are available for timely and reliable user access termination. Choice ofthe appropriate process depends on an organization’s business requirements andpreferences:

• Scheduled access termination

Some workers, such as contractors, summer students and temporary staff, havepre-defined termination dates. These dates can be entered or loaded into Hitachi IDIdentity Manager.

A scheduled batch process runs periodically on the Identity Manager server andchecks 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 userswhose 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 sufficientlylong amount of time.

• HR-initiated access termination

HR staff can mark employees and contractors1 either with a termination date, whichis processed as described above or as already terminated. The Identity Managerautomation engine can periodically poll the HR system for such changes andautomatically 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’stermination date and status. This can be used to schedule or defer termination or torequest immediate deactivation. Requests are routed to authorizers by e-mail, whorespond on a secure, authenticated web form. Once deactivation requests areapproved and/or a user’s termination date has elapsed, all login IDs for the indicateduser are disabled.

• Urgent access termination

A web-based user management interface allows security administrators to terminateaccess to any user, on any combination of systems, immediately. This is used forurgent termination scenarios.

3b Accounts and group memberships can be flagged as mutually exclusive. Business logic inthe Identity Manager workflow engine can prevent conflicting resources from beingrequested 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 andwaiting 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 userprovisioning system detects this event, notes that it is in scope and reformats theevent into workflow requests to create a Windows/AD account, an Exchangemailbox and a mainframe login ID.

2. HR staff set a termination date for an employee in the HR application. The userprovisioning system detects this and sets the same date in the user’s IAM profile. Abatch 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 AdminsAD group. The user provisioning system detects this new group membership,removes the user from the group and sends an SMS message describing what itdetected to a security officer.




3d Users can sign into the Identity Manager web portal and make updates to their ownprofiles. This includes changes to their contact information and requests for new access toapplications, shares, folders, etc.

Profile updates are subject to:

• Access control policies. For example, users may be able to see but not modify theirjob code or pay grade.

• Field- and form-level validation rules. For example, the area code in a user’s phonenumber may have to match the city in which the user resides.

• Authorization rules. For example, changes to a user’s department code may have tobe 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/ormanagers for approval.

3e The Identity Manager workflow is simple to use, and so is preferred by users, who canexpect 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-inprocess 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 eachuser. Users who have not logged in recently can be flagged as dormant accounts.

• Login ID reconciliation data can connect dormant accounts on one system, tounmarked accounts on another system, which may not track last login date.

• Login ID reconciliation data can be used to identify accounts that have no apparentowner – i.e., they exist in the login ID inventory on a system, but no current user hasattached the account to his or her own profile.

The lists of dormant and orphan accounts generated in this way are tentative and shouldnot in general be automatically disabled. For example, apparently-dormant accounts maysimply be infrequently used, while apparently-orphan accounts may simply not yet havebeen attached to their owner’s profile.

Orphan and dormant account lists can and should be manually reviewed, to removeobvious errors. The resulting, sanitized lists should be resubmitted to Identity Managerfirst to batch-disable, and later to batch-delete.

The time interval between disabling and deleting orphan accounts gives the owners ofthose accounts time to notice the problem and complain, thereby causing their accountsto be reactivated.

3h Initial passwords may be assigned to newly provisioned accounts in one of two number ofways:

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, soas 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 theuser must change them immediately.

Using Password Manager, the initial password process can be based on securityquestions. This means that new users can be assigned a random password plus havetheir 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 populateadditional 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 areavailable.

• By drawing on an external source of data – for example, some organizationsmaintain 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 andentitlements. It works by asking managers, application owners and data owners to reviewlists of users and entitlements. These stake-holders must choose to either certify orrevoke 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 accesscombinations.



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 legitimateusers.

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 andAccountability 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 certification: . . . 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: [email protected]

File: /pub/wp/documents/hipaa/mtech-hipaa-3.texDate: Nov 7,2006

http://aspe.hhs.gov/admnsimp/pl104191.htm

http://cms.hhs.gov/hipaa/hipaa2/regulations/security/03-3877.pdf

http://cms.hhs.gov/hipaa/hipaa2/regulations/security/03-3877.pdf



http://Hitachi-ID.com/Password-Manager/

http://Hitachi-ID.com/Identity-Manager/

http://Hitachi-ID.com/Identity-Manager/



HIPAA Compliance - Using the Hitachi ID Identity Management Suite

Technology

Transcript of HIPAA Compliance - Using the Hitachi ID Identity Management Suite