Openvms Compliance with HIPAA Security Requirements

OpenVMS Compliance

with

HIPAA Security Requirements

December 2000

Version 1.0

Hal Bettle

Security Analyst

Purpose

Summary

Details

TECHNICAL SECURITY SERVICES TO GUARD DATA INTEGRITY, CONFIDENTIALITY AND AVAILABILITY

REQUIREMENT: Access control

REQUIREMENT: Audit controls

REQUIREMENT: Authorization Control

REQUIREMENT: Data Authentication

REQUIREMENT: Entity Authentication

TECHNICAL SECURITY MECHANISMS TO GUARD AGAINST UNAUTHORIZED ACCESS TO DATA THAT IS TRANSMITTED OVER A COMMUNICATIONS NETWORK

REQUIREMENT: Communications/network controls

ELECTRONIC SIGNATURE

REQUIREMENT: Digital signature

ADMINISTRATIVE PROCEDURES TO GUARD DATA INTEGRITY, CONFIDENTIALITY AND AVAILABILITY

REQUIREMENT: Certification

REQUIREMENT: Chain of trust partner agreement

REQUIREMENT: Contingency plan

REQUIREMENT: Formal mechanism for processing records

REQUIREMENT: Information access control

REQUIREMENT: Internal audit

REQUIREMENT: Personnel security

REQUIREMENT: Security configuration mgmt.

REQUIREMENT: Security incident procedures

REQUIREMENT: Security management process

REQUIREMENT: Termination procedures

REQUIREMENT: Training

PHYSICAL SAFEGUARDS TO GUARD DATA INTEGRITY, CONFIDENTIALITY AND AVAILABILITY

REQUIREMENT: Assigned security responsibility

REQUIREMENT: Media controls

REQUIREMENT: Physical access controls (limited access)

REQUIREMENT: Policy/guideline on work station use

REQUIREMENT: Secure work station location

REQUIREMENT: Security awareness training

Resources Used

Purpose

This paper was created to show the compliance of OpenVMS Version 7.2 based systems in a HIPAA operational environment.

The following overview was summarized from several public web sites that relate to HIPAA and the health care industry in general.

The Health Insurance Portability and Accountability Act of 1996 (HIPAA) is federal legislation aimed at health plan issuers, group health plans, and, in some instances, employers.

HIPPA is concerned with many areas of the health industry including the simplification of administrative procedures. These procedures require and set standards for the management of and access to patient health data stored or transmitted in electronic form. These include a standard set of transaction codes, Unique Health Identifiers, Privacy Legislation, Electronic Signature and Security Standards.

This paper addresses the security standards established for HIPAA compliant systems.

It is important to note the HIPAA implementation plan is behind schedule from the original proposal. The security standards used for this paper have not been formally approved and are still subject to change. It is worth mentioning that the standards used in this paper have been published since December 1999 and have not changed.

The system configurations for this paper include standalone and cluster versions of OpenVMS 7.2. The actual assumption is that there is a common security domain for all systems.

There was no consideration of internationalization but nothing prevents the use OpenVMS in a HIPAA compliant system in an international environment.

Summary

The requirements listed in the next section are from the HIPAA Security Matrix found at

Many of the terms used in the Security Matrix are defined in a glossary found at The web site providing this information is operated by the Workgroup for Electronic Data Interchange (WEDI) organization. They have a specific interest in “electronic commerce in the health care industry.” These requirements have been posted elsewhere without significant changes.

OpenVMS, along with selected layered products meet all technical security requirements. Compaq already tests and/or uses these products as part of the OpenVMS release qualification process. This demonstrates that OpenVMS already meets or exceeds the existing HIPAA Security Standards.

The following components are used to build an OpenVMS HIPAA compliant system.

Required Products

OpenVMS V7.2

This can be a VMScluster or standalone configuration, supported on either Alpha or VAX hardware.

Encryption for OpenVMS, Version 1.3

Supported on all OpenVMS V7.2 configurations and platforms

Database Layered Product

One of the following type products is expected to support “record level” auditing requirements

Oracle
“M” (MUMPS)
InterSystems Cache’

Optional Products

There are several layered products or features that may be used to enhance the level of HIPAA compliance of OpenVMS.

Pretty Good Privacy (PGP) for OpenVMS
RSA SecureID
Kerberos API’s as expected to be supported in OpenVMS V7.2

Optional Support Services

There are several support services provided by Compaq that may be used to enhance the level of HIPAA compliance of OpenVMS.

Compaq Software Security Response Team
Disaster Planning and Recovery Services

Details

This section of the paper provides details of the HIPAA security requirements and how Compaq meets each of these requirements.

The Security Matrix identifies which requirements are mandatory and which are optional. This paper reprints that information. Most often the Security Matrix lists a set of features that must or may be implemented to meet each requirement.

As the HIPAA Security Matrix documentation indicates, there is overlap in the requirements and features. Therefore the same OpenVMS feature or Compaq product can be used to fulfill multiple requirements.

Following the format of the published Security Matrix, this section is separated into five parts. Each part has one or more requirements listed. The first three parts are the technical requirements and this paper maps how Compaq meets each of the requirements with OpenVMS features and layered products. Where practical, the OpenVMS release that introduced the feature is also listed. The last two areas are administrative and can be met via customer in-house procedures and policies. All areas are listed for completeness.

TECHNICAL SECURITY SERVICES TO GUARD DATA INTEGRITY, CONFIDENTIALITY AND AVAILABILITY

The requirement in this section is met by OpenVMS or met by use of OpenVMS layered products.

REQUIREMENT: Access control

This requirement is mandatoryand met by OpenVMS.

This feature must be implemented.

Procedure for emergency access.

OpenVMS provides emergency access to system data via the system console. The console is considered part of the trusted system hardware and must be physically protected. When it is part of a workstation system the console is password protected.

This feature has been available since at least OpenVMS V6.0.

At least one of the following features must be implemented.

Context-based access

OpenVMS does provide direct context based access. Some capabilities like “time of day” can be simulated via the AUTHORIZE utility which can be used to limit the type and hours of access a user has to the system.

Role-based access

OpenVMS provides role-based access to system utilities, resources and data based on several techniques. These include use of system privileges, identifiers and subsystems. The AUTHORIZE Utility is used by privileged system administrators to establish the access rights of a specific user.

All of these features have been available since OpenVMS V6.0. Some have been available since much earlier versions.

User-based access

OpenVMS provides user based access to system utilities, resources and data based on C2 Discretionary Access Controls. Users are uniquely identified to the system via a UIC. In addition Access Control Lists may be implemented to refine access (allowed or denied) to a specific user. The UIC (User Identification Code) and Access Control Lists are used to determine what objects the user is allowed to access.

These features have been available since OpenVMS V4.3.

This feature is optional.

Encryption

OpenVMS does not provide a built in general use encryption utility. Compaq has an application product supported on OpenVMS V7.2 that implements this feature. It is currently called Encryption for OpenVMS, Version 1.3.

Versions of this application have been available since before OpenVMS V6.0.

The Kerberos API’s are expected to be supported in OpenVMS V7.2.

REQUIREMENT: Audit controls

This requirement is mandatory and met by OpenVMS when used with supported products.

HIPAA defines auditing at the “record” level. That is, each action on a record in a database must be audited. OpenVMS supports several Database products that provide these capabilities. They include

Oracle
“M” (MUMPS)
InterSystems Cache’

In addition, OpenVMS provides auditing of many events far too numerous to list here. Auditing can be set to track the actions of a single user or access to a single object. Both success and failure accesses can be recorded. Audit reduction tools are provided with OpenVMS to easily filter large volumes of audit data. Use and changes to the audit trail can also be audited and system defensive measures can be set in the event auditing becomes disabled.

The full OpenVMS auditing has been available since OpenVMS V6.0. Most has been available from far earlier versions.

REQUIREMENT: Authorization Control

This requirement is mandatoryand met by OpenVMS.

At least one of the following features must be implemented.

Role-based access

These features have been available since at least OpenVMS V6.0.

User-based access

OpenVMS provides user based access to system utilities, resources and data based on U.S. Trusted Computer System Evaluation CriteriaC2 Discretionary Access Controls. Users are uniquely identified to the system via a UIC. In addition Access Control Lists may be implemented to refine access (allowed or denied) to a specific user. The UIC and Access Control Lists are used to determine what objects the user is allowed to access. The AUTHORIZE Utility is used by privileged system administrators to establish the access rights of a specific user.

These evaluated features have been available since OpenVMS V4.3.

REQUIREMENT: Data Authentication

This requirement appears optional but is met by OpenVMS.

Data authentication is an ambiguous term but the HIPAA definition refers to altered or destroyed data by unauthorized users. Data Integrity is defined as preventing the unauthorized modification of data. For this paper data authentication shall be synonymous with data integrity.

Check Sum

OpenVMS provides a file based check sum mechanism for data authentication with the Checksum command. Check sums are used as part of OpenVMS kit authentication and can be used on a per file basis.

Message Authentication Code

OpenVMS does not provide a built in message authentication code (MAC) mechanism for user data. Compaq has an application product supported on OpenVMS V7.2 that implements this feature. It is currently called Encryption for OpenVMS, Version 1.3.

Double Keying

This is an undefined term but this paper provides a working definition of “using two different keys” to encrypt data. An alternative definition is using the same key twice to encrypt data.

Digital Signature

OpenVMS does not provide a built in data signature mechanism. There does exist Pretty Good Privacy (PGP) for OpenVMS that does provide digital signatures.

REQUIREMENT: Entity Authentication

This requirement is mandatory and met by OpenVMS.

All listed features must be implemented.

Automatic logoff

OpenVMS does not provide an automatic logoff feature, but one can be easily added to the system. There are several freeware products available that provide such a feature including a Motif version on the OpenVMS CD. A customer may choose to create their own program or command procedure to provide this feature. OpenVMS choose not to provide a built in feature because of the lack of an industry wide definition of “user inactivity.”

Unique user identification.

OpenVMS provides unique user identification via individual usernames. At successful login these unique usernames are mapped to an assigned UIC in the system authorization database. Before the UIC is mapped to the username the user must be authenticated to the system.

This feature has been available since the first versions of OpenVMS.

At least oneof the following features must be implemented.

Biometric

OpenVMS does not provide a built in biometric method of authentication.

Password

OpenVMS provides password authentication on a per user bases. Many options are provided to allow system administrators to set password usage policies.

All of these features have been available since OpenVMS V6.0. Most have been available from far earlier versions.

OpenVMS does not provide a built in Personal Identification Number (PIN) method of authentication but the RSA SecureID product does.

Telephone callback

OpenVMS does not provide a built in automatic telephone callback method of authentication

Token

OpenVMS does not provide a built in token method of authentication but the RSA SecureID product does.

TECHNICAL SECURITY MECHANISMS TO GUARD AGAINST UNAUTHORIZED ACCESS TO DATA THAT IS TRANSMITTED OVER A COMMUNICATIONS NETWORK

The requirement in this section is met by OpenVMS when used with OpenVMS supported layered products.

REQUIREMENT: Communications/network controls

OpenVMS supports the use of an IP stack since version 5.0 as well as the use of DECnet from many versions prior to version 5.0.

If communications or networking is employed, one of the following features must be implemented.

Access controls

Access controls refers to the protection of transmissions over a network so that it can not be intercepted or interpreted by unauthorized recipients. OpenVMS relies on Encryption for this feature.

Encryption

Versions of this application have been available since before OpenVMS V6.0.

The Kerberos API’s are expected to be supported in OpenVMS V7.2.

These features must be implemented.

Integrity controls

The definition of this term refers to the validity of information being transmitted or stored. OpenVMS relies on Encryption (see previous or next feature) to ensure the integrity of stored data. The Kerberos API’s are expected to be supported in OpenVMS V7.2. for user authentication as well as the use of PGP for digital signatures.

Message authentication

In addition, if using a network, the following four features must be implemented

Alarm

The OpenVMS auditing utility provides real time reporting of any audit condition. A system administrator can be notified in many ways and the system can take defensive action based upon the event being reported.

The full OpenVMS auditing and alarm reporting has been available since OpenVMS V6.0. Most has been available from far earlier versions.

Audit trail

OpenVMS auditing provides for auditing the use and changes to the audit trail. System defensive measures can be automatically invoked in the event auditing becomes disabled.

The full OpenVMS auditing has been available since OpenVMS V6.0. Most has been available from far earlier versions.

Entity authentication

OpenVMS provides coverage for this feature. Please see the “Entity Authentication” requirement in the previous section.

Event reporting

This term refers to reporting 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. Depending upon a refined definition, OpenVMS provides several utilities for this feature. They include auditing/alarm reporting, network management tools such as NCP and/or transaction services (TP_SERVER).

These features have been available since OpenVMS V6.0.

ELECTRONIC SIGNATURE

REQUIREMENT: Digital signature

This requirement is optional and expected to be met by OpenVMS when PGP is used.

OpenVMS does not provide a built in data signature mechanism. There does exist PGP for OpenVMS that does provide digital signatures.

If digital signatures are used then the following features must be implemented.

Message integrity

Non-repudiation

User authentication - Covered in “Entity Authentication”

If digital signatures are used then the following features are optional.

Ability to add attributes

Continuity of signature capability

Counter signatures

Independent verifiability

Interoperability

Multiple signatures

Transportability

ADMINISTRATIVE PROCEDURES TO GUARD DATA INTEGRITY, CONFIDENTIALITY AND AVAILABILITY

The requirements listed in this section are administrative. The requirements can not be met with the technical features of OpenVMS. They are met by implementing organizational practices and procedures. They are listed here to allow Compaq to map the requirement to a practice or service that may assist a customer to meet these requirements.

REQUIREMENT: Certification

This requirement is mandatory and met by current OpenVMS engineering practices.

OpenVMS received a U.S. Trusted Computer System Evaluation Criteria (TCSEC) C2 Security Ratings on several versions. Please see

The engineering process used to build these evaluated versions is continuously used to build current versions of OpenVMS. OpenVMS is currently participating in a United Kingdom Information Technology Security Evaluation Criteria (ITSEC) E3 evaluation.

There is discussion that HIPAA compliant systems will be certified via the Common Criteria with a HIPAA Protection Profile. Please see Common Criteria is a blend of several evaluation processes including TCSEC and ITSEC.

OpenVMS 6.0 and 6.1 are TCSEC evaluated.

REQUIREMENT: Chain of trust partner agreement

This requirement is mandatoryand has no impact to Compaq. It is implemented via a contract between two HIPAA compliant partners.

REQUIREMENT: Contingency plan

This requirement is mandatory and may be met by Compaq’s Disaster Planning Services. The use of these services needs to be verified and detailed

All listed features must be implemented.

Applications and data criticality analysis

Data backup plan

Disaster recovery plan

Emergency mode operation plan

Testing and revision

REQUIREMENT: Formal mechanism for processing records

This requirement is mandatoryand has no impact to Compaq. It is implemented via the formally written procedures and policies of a customer. Compaq may have services to assist a customer in meeting this requirement.