AMC/HIPAA Workgroup 49 Section Three: Requirements for Technical Security, Services, and Mechanisms

AMC/HIPAA Workgroup

Section Three: Requirements for Technical Security, Services, and Mechanisms

Websuche.info die frische Suchmaschine alteredrealitycc derkach private Krankenversicherung Autoversicherung KFZ Versicherung Lebensversicherung KFZ Versicherungsvergleich Autoversicherungen KFZ Versicherungen Lebensversicherungen Horoskop Horoskope Eintrag bbsnet Reisen Urlaub Baufinanzierung Hausfinanzierung Immobilienfinanzierung Erotik Hallenbau Vermieterrechtsschutz Last Minute Algarve Ferienhaus Portugal Werbemittel Werbeartikel Viking Buerobedarf Bueroartikel Bueromaterial Kalender Drucker Druckerpatronen Tintenpatronen HP Drucker Werbeartikel Werbemittel Bueromoebel Kopierer Krankenversicherungsvergleich Werbeartikel Werbemittel Kreditvergleich

tableofcontents.htm start.htm securitysectiontwo.htm securitysectionthree.htm securitysectionone.htm securitycategories.htm references.htm privacysectiontwo.htm privacysectionthree.htm privacysectionone.htm privacysectionfour.htm privacysectionfive.htm privacycategories.htm jobdescriptions.htm introduction.htm index.htm hipaatrifold.htm hipaasuppliment.htm hipaaresources.htm hipaaexecsummary.htm guidelinesorganization.htm generalpolicyguidelines.htm generalcategories.htm definitions.htm contractsandpolicies.htm contact.htm amchipaasecurityandprivacyguidelines.htm acronyms.htm acknowledgements.htm

Page 2

AMC/HIPAA Workgroup

SEC.19

Access Control § .308(c)(1)(i)

HIPAA Requirement

The technical security services must include...Access control that includes:

(A) A procedure for emergency access (documented instructions for obtaining

necessary information during a crisis) and

(B) At least one of the following implementation features:

1) context-based access (an access control procedure based on the context of a

transaction as opposed to being based on attributes of the initiator or target)

2) role-based access

3) user-based access

(C) The optional use of encryption

AMC Explanation of HIPAA Regulation

Each covered entity is required to maintain a mechanism for access control that restricts access

to resources and allows access only by privileged entities, providing access only to those

workforce members with a business need for it. Possible types of access control include

mandatory access control, discretionary access control, time-of-day, classification, and subject-

object separation. In addition, a mechanism to enable emergency access is required.

Key Issues

Is there a documented procedure for emergency access?

Is there a process for screening unwarranted demands for access?

Do systems and applications have technical capability to implement user, role, or context-

based access?

Do systems prohibit or allow simultaneous access of the same user id/concurrent

connections? Why or why not?

Does the organization allow group, shared, trusted, or generic logon?

How does encryption impact access control?

Category I Guidelines-Actions must be taken to address these

Define a context-based, role-based, and/or user-based access policy as appropriate for

each of the various situations in the covered entity and adopt implementation procedures

to enforce need-to-know accordingly.

Enact a clearly stated and widely understood "break the glass" procedure for allowing

access via alternate and/or manual methods in the event of an emergency requiring access

to protected health information.

Category II Guidelines-Actions should be taken to address these

Establish a centrally administered service to define access profiles-context-based, role-

based, or user-based-and oversee consistent implementation of access control

mechanisms.

Document and test the emergency access procedure.

Page 3

AMC/HIPAA Workgroup

Evaluate information technology projects, proposals, contracts, and existing services for

access control features and implementation.

Consider adopting ASTM-defined healthcare roles.

Roadblocks

Centrally administered access control services are difficult to implement in the diverse IT

environments typical of Academic Medical Centers. Take into consideration that reduced logon

solutions, PKI, Kerberos, password brokering services, and the like are expensive, complicated,

and often require expertise not found in the healthcare industry. Testing emergency access

procedures in a realistic fashion is often cumbersome. Controlling contractor and business

partner access is challenging, particularly when remote network connections are involved and

accountability is necessary on the remote end. Modifying access profiles when staff change

roles within the covered entity will require efficient communication between personnel and IT.

Comments

Also see: SEC.05 Information Access and Control, SEC.10 Security Management Process, and

SEC.11 Termination Procedures

A user-based access model would require the organization to determine appropriate access for

each individual user. A role-based access model would require the organization to develop an

access profile for each role; for example, nurses, doctors, and desk attendants each have different

access needs dependent upon their role in the organization. A context-based access model

would, for example, allow all staff working in Endocrinology to access Endocrinology records.

Some AMCs may choose to implement combinations of access models.

Page 4

AMC/HIPAA Workgroup

SEC.20

Audit Controls § .308(c)(1)(ii)

HIPAA Requirement

The technical security services must include...(mechanisms employed to record

and examine system activity).

AMC Explanation of HIPAA Regulation

System activity logging is required in order to recreate pertinent system events and actions taken

by system users and administrators. An audit process of examining logged information is

required in order to identify questionable data access activities, investigate breaches, respond to

potential weaknesses, and assess the security program.

Key Issues

What activities need to be monitored?

What level of logging detail is necessary?

How long should covered entities retain audit log data?

How should covered entities protect audit log data?

Who may access audit log data?

How can a covered entity identify inappropriate access?

How can a covered entity best use audit tools to assess its security program?

When should prospective audits be used?

Category I Guidelines-Actions must be taken to address these

Employ event logging on systems that process or store protected health information

where warranted by risk analysis.

Category II Guidelines-Actions should be taken to address these

Log system administration events:

Creation and removal of accounts;

Assigning and changing of privileges;

Installation, maintenance, and changing of software;

Changes in hardware configurations.

Log user activities:

Logon and logoff, both successful and unsuccessful;

Read, write, create, and delete actions at the file level;

Individual user access to individual patient records;

Attempts to access unauthorized data and/or services.

Perform prospective audits of user activity where risk levels warrant.

Maintain log data for a specified period of time.

Protect system logs, especially those containing personally identifiable healthcare

information, from unauthorized access or alteration.

Employ audit reduction tools and/or "intelligent" methods of correlating log data to

detect unauthorized activity and reduce volumes to manageable size.

Page 5

AMC/HIPAA Workgroup

Roadblocks

Be aware that system audit logs can quickly become voluminous and require additional

maintenance time. Prospective auditing and determining appropriateness of access and actions

taken is an expensive, time consuming, and difficult process.

Comments

The purpose of system event logging is to be able to recreate pertinent events should a security

violation or compromise occur. Log data is typically examined reactively, when indications of

unauthorized activity are reported. How entities interpret and respond to findings is a measure of

compliance. Because prospective audits are onerous and usually require the input of clinicians to

resolve need-to-know issues, they should be performed sparingly and with good cause in

accordance with risk and threat levels as determined through the risk analysis process.

Enterprise systems are normally subject to audit controls. Departmental systems and those with

limited numbers of users and lower functionality, such as laboratory systems or those that feed

data up to enterprise systems, are normally not subject to audit controls unless the risk analysis

process determines otherwise. The risk analysis process should consider track records of

violations. Logging and audit strategies should reflect levels of abuse. Logging to a high level

of detail, such as individual keystroke capture, is generally not necessary.

The required retention period for audit log data may vary. In general, at least several months of

data are necessary to adequately investigate instances of inappropriate access. The National

Industrial Security Program, which oversees the protection of U.S. government classified

information, requires at least six months of log data. This may be a reasonable and defensible

goal for Academic Medical Centers as well.

Also see: SEC.06 Internal Audit, SEC.09 Security Incident Procedures, PRIV.53 Complaints,

and PRIV.54 Sanctions.

Page 6

AMC/HIPAA Workgroup

SEC.21

Authorization Control § .308 (c)(3)

HIPAA Requirement

...(the mechanism for obtaining consent for the use and disclosure of health

information) that includes at least one of the following implementation features:

(A) Role-based access

(B) User-based access

AMC Explanation of HIPAA Regulation

Covered entities must implement a mechanism to authorize the privileged use of protected health

information available via systems and applications. The mechanism must limit these privileges

to the maximum practical extent commensurate with professional needs.

Key Issues

How can a covered entity determine which type of authorization mechanism-role-based

or user-based-is appropriate?

Category I Guidelines-Actions must be taken to address these

Employ a system or application-based mechanism to authorize activities within system

resources in accordance with the Least Privilege Principle. (See Comments.)

Implement:

A role-based mechanism where users with common information needs are provided

access and privileges through common security authorization classes; or

A user-based mechanism where users' information access and privilege needs are

determined and provided on an individual basis.

Maintain individual accountability for actions taken by forbidding group (shared, generic,

trusted, etc.) logons.

Category II Guidelines-Actions should be taken to address these

None.

Roadblocks

Implementing a data stewardship model is prudent but will likely be difficult in large covered

entities. Individuals or groups sometimes perform stewardship functions but may not understand

the concept of accountability for usage and disclosure.

Comments

The Least Privilege Principle pertains to one's ability to perform specified system functions.

Users should not have system capabilities not required of their positions. For example, a user

who requires only read access to medical information should not have the ability to change or

delete it. AMCs will almost certainly use the role-based authorization approach given the large

numbers of users typical of these organizations. Covered entities are cautioned to avoid

developing too many authorization profiles in a role-based model, as management of a large

number of profiles is unwieldy.

Page 7

AMC/HIPAA Workgroup

SEC.22

Data Authentication § .308 (c)(4)

HIPAA Requirement

...(The corroboration that data has not been altered or destroyed in an

unauthorized manner. Examples of how data corroboration may be assured

include the use of a check sum, double keying, a message authentication code, or

digital signature.)

AMC Explanation of HIPAA Regulation

Each covered entity must be able to provide corroboration that protected health information in its

possession has not been altered or destroyed in an unauthorized manner. Data corroboration

methods include, but are not limited to, the use of checksums, double keying, message

authentication codes, and digital signatures.

Key Issues

Is the use of digital signatures a cost effective approach?

Are technical integrity controls a reasonable expectation for more than certain critical

functions?

Can trusted procedures supplant technical controls in some respects?

Category I Guidelines-Actions must be taken to address these

Employ technical controls such as checksums, digital signatures, double keying, and

message authentication codes where feasible and appropriate to the level of risk.

Category II Guidelines-Actions should be taken to address these

Employ technical integrity controls for critical automated functions such as physicians'

orders and prescriptions.

Procedural aspects closely related to technical authentication and integrity:

Maintain separation of duties. Avoid overlapping responsibilities of application and

system programmers, data center operators, data base administrators, network

operations, and user functions.

Establish and demonstrate change management discipline.

Roadblocks

No roadblocks specific to this point.

Comments

None.

Page 8

AMC/HIPAA Workgroup

SEC.23

Entity Authentication § .308 (c)(5)

HIPAA Requirement

...(the corroboration that an entity is the one claimed) that includes:

(A) Automatic logoff (a security procedure that causes an electronic session to

terminate after a predetermined time of inactivity, such as 15 minutes), and

(B) Unique user identifier (a combination name/number assigned and maintained

in security procedures for identifying and tracking individual user identity).

(C) At least one of the following implementation features:

(1) Biometric identification (an identification system that identifies a human from

a measurement of a physical feature or repeatable action of the individual (for

example, hand geometry, retinal scan, iris scan, fingerprint patterns, facial

characteristics, DNA sequence characteristics, voice prints, and handwritten

signature)).

(2) Password.

(3) Personal identification number (PIN) (a number or code assigned to an

individual and used to provide verification of identity).

(4) A telephone callback procedure (method of authenticating the identity of the

receiver and sender of information through a series of ``questions'' and

``answers'' sent back and forth establishing the identity of each). For example,

when the communicating systems exchange a series of identification codes as part

of the initiation of a session to exchange information, or when a host computer

disconnects the initial session before the authentication is complete, and the host

calls the user back to establish a session at a predetermined telephone number.

(5) Token.

AMC Explanation of HIPAA Regulation

Entities (an entity may be a person, system, or process) must be authenticated prior to accessing

protected health information. Authentication is the process of corroborating that an entity is who

or what it claims to be; it may occur through a trusted process such as the provision of a secret

password, a personal identification number, or a token. Dial-up remote access users are subject

to stronger, or two-tiered, authentication that may include telephone call-back or other strong

authentication methods. Automatic log offs, or inactivity time-outs, can help enforce

authentication by precluding others from accessing unattended sessions.

Key Issues

Is a unique user ID with password authentication secure enough?

Should alternative authentication methods such as biometrics be considered?

What standards are necessary to make a public key infrastructure (PKI) interoperable and

truly useful?

Category I Guidelines-Actions must be taken to address these

Uniquely identify each user and authenticate identity.

Implement at least one of the following methods to authenticate a user:

Page 9

AMC/HIPAA Workgroup

Password;

Biometrics;

Personal Identification Number (PIN);

Physical token;

Call-back or strong authentication for dial-up remote access users.

Implement automatic log-offs to terminate sessions after set periods of inactivity.

Determine appropriate periods based on the levels of risk and exposure.

Category II Guidelines-Actions should be taken to address these

Include procedures for initiating user access, resetting passwords/tokens, and providing

administrative access in the authentication system, and ensure it is fully documented.

Employ a formal risk management methodology to identify risks and threats to the

authentication process.

Employ secure architectures, where risk appropriate, to authenticate entities. These may

include Kerberos, RADIUS, TACACS, PKI, or similar methods.

Encrypt hard-coded passwords that reside on client machines or in applications.

Securely authenticate contractors. Device-to-device or firewall-to-firewall authentication

is acceptable provided the contractor demonstrates individual accountability for access.

Change passwords periodically.

Specify time-out intervals based on business need and levels of risk and exposure.

Allow users to select and change their own passwords.

Roadblocks

No roadblocks specific to this point.

Comments

Dial-back has been largely replaced by more robust architectures such as Remote Dial-In User

Authentication (RADIUS). Most covered entities will continue to employ user ID and password

authentication. Managed properly this is adequate, but processing speeds and wide availability

of hacker tools and techniques have made this method obsolete for all but internal authentication.

Inactivity time-outs are secondary controls and users should not rely on them to end their

sessions. Password standards must be risk appropriate. Covered entities will need to address

password length, complexity, change frequency, user selection, etc. This will continue to be a

moving target.

Page 10

AMC/HIPAA Workgroup

SEC.24

Communications/network controls § .308(d)

HIPAA Requirement

(1) If an entity uses communications or network controls, its security standards

for technical security mechanisms must include the following:

(i) The following implementation features:

(A) Integrity controls (a security mechanism employed to ensure the validity of the

information being electronically transmitted or stored).

(B) Message authentication (ensuring, typically with a message authentication

code, that a message received (usually via a network) matches the message sent).

(ii) One of the following implementation features:

(A) Access controls (protection of sensitive communications transmissions over

open or private networks so that they cannot be easily intercepted and interpreted

by parties other than the intended recipient).

(B) Encryption.

(2) If an entity uses network controls (to protect sensitive communication that is

transmitted electronically over open networks so that it cannot be easily

intercepted and interpreted by parties other than the intended recipient), its

technical security mechanisms must include all of the following implementation

features:

(i) Alarm. (In communication systems, any device that can sense an abnormal

condition within the system and provide, either locally or remotely, a signal

indicating the presence of the abnormality. The signal may be in any desired form

ranging from a simple contact closure (or opening) to a time-phased automatic

shutdown and restart cycle.)

(ii) Audit trail (the data collected and potentially used to facilitate a security

audit).

(iii) Entity authentication (a communications or network mechanism to irrefutably

identify authorized users, programs, and processes and to deny access to

unauthorized users, programs, and processes).

(iv) Event reporting (a network message indicating operational irregularities in

physical elements of a network or a response to the occurrence of a significant

task, typically the completion of a request for information).

AMC Explanation of HIPAA Regulation

Covered entities that use external communication systems, such as the public switched telephone

system, or open networks, such as the Internet, are required to safeguard protected health

information that traverses them. The specified technical security services address network risks

of message interception and interpretation by parties other than the intended recipient.

Additionally, these services protect information systems from intruders attempting to exploit

external communication points such as Internet host systems and telephone switches. In addition

to the other listed precautions, some form of encryption is required when using open networks.

Key Issues

How is relative risk determined?

Page 11

AMC/HIPAA Workgroup

How much encryption is enough?

When should encryption be used?

Category I Guidelines-Actions must be taken to address these

If the covered entity employs an internal, private, or value-added network, the covered

entity must:

Employ alarms to sense abnormal conditions;

Enact an audit trail to recreate events in the instance of violations or compromises;

Identify and authenticate authorized users, programs, and processes;

Deny access to unauthorized users, programs, and processes;

Employ event reporting to identify operational irregularities and occurrences of

significant tasks.

If the covered entity employs the public switched telephone system, the covered entity

must:

Enact integrity controls to ensure the validity of protected health information

transmitted;

Enact message authentication to ensure that content is not altered in transmission;

Enact access controls or risk appropriate encryption to preclude unauthorized access,

interception, or interpretation.

If the covered entity employs the public Internet, the covered entity must enact the

controls listed for the public switched telephone system as well as using risk appropriate

encryption. (See Comments.)

Category II Guidelines-Actions should be taken to address these

Do not store or transmit system passwords in the clear.

Control network access through individual identification and authentication.

Employ encryption keys of the length specified by the HCFA Internet Security

Policy.

Roadblocks

Encryption is often difficult to implement. Hardware-based encryption is generally costly but

fast because it does not require CPU cycles, while software-based encryption is generally less

costly but tends to be system or application dependent and impedes performance.

Comments

Threats to data transmissions are difficult to quantify and widely misunderstood. Threat levels

vary and are sometimes based on factors such as geography. For example, the threat of

eavesdropping on the public switched telephone system within the United States is very low, but

the threat rises dramatically when international communications are considered. State-sponsored

eavesdropping is the norm in some parts of the world-particularly when U.S. interests are

involved.

In November of 1998, the Healthcare Finance Administration (HCFA) released an Internet

Security Policy describing appropriate encryption key lengths for public, private, and elliptical

Page 12

AMC/HIPAA Workgroup

curve algorithms. Required key lengths are, of course, subject to change as technology

improves. Academic Medical Centers should use strong encryption with key lengths at least as

long as those specified by HCFA for Internet transmissions.

AMCs may need further advice from communications experts and national

agencies/organizations.