The
Tunitas Group is enthusiastic over this long overdue policy change.
Our critical remarks are not meant to discourage Internet use, only to
inform of some issues in adopting the solution sets proposed by HCFA. Background
on HCFA Policy
DATE OF ISSUANCE: MM/DD/YYYY
HCFA - INFORMATION SYSTEMS SECURITY PROGRAM (ISSP) HANDBOOK
BULLETIN NUMBER 98-01
TO: ALL HCFA COMPONENTS, CONTRACTORS, STATE AGENCIES ACTING AS HCFA AGENTS, PARTICIPANTS IN COOPERATIVE AGREEMENTS, AND ENTITIES (USERS) PARTY TO A DATA USE AGREEMENT WITH HCFA
FROM: Gary G. Christoph, Ph.D.
Chief Information Officer
Director, Office of Information Services
SUBJECT: Internet Communications Security and Appropriate Use Policy and Guidelines for HCFA Privacy Act-protected and other Sensitive HCFA Information.
1. Purpose.
(DRAFT) This bulletin formalizes the policy and guidelines for the security and appropriate use of the Internet to transmit HCFA Privacy Act-protected and other sensitive HCFA information.
2. Effective Date. (DRAFT) This bulletin is effective as of the date of issuance.
3. Expiration Date. (DRAFT) This bulletin remains in effect until superseded or canceled.
4. Introduction.
(DRAFT) The Internet is the fastest growing telecommunications medium in our history. This growth and the easy access it affords has significantly enhanced the opportunity to use advanced information technology for both the public and private sectors. It provides unprecedented opportunities for interaction and data sharing among health care providers, HCFA contractors, HCFA components, State agencies acting as HCFA agents, Medicare and Medicaid beneficiaries, and researchers. However, the advantages provided by the Internet come with a significantly greater element of risk to the confidentiality and integrity of information. The very nature of the Internet communication mechanisms means that security risks cannot be totally eliminated. Up to now, because of these security risks and the need to research security requirements vis-a-vis the Internet, HCFA has prohibited the use of the Internet for the transmission of all HCFA Privacy Act-protected and other sensitive HCFA information by its components and Medicare/Medicaid partners, as well as other entities authorized to use this data. HCFA may have prevented the effective use of the Internet for communication of Privacy Act protected data, but this position could not be justified by any lack of appropriate security technology. All of the technologies referred to in this draft document were available by the summer of 1996. The use of SSL tunnels through the public Internet to support secure communication within broadly distributed communities has been known for some time. HDIC proposed use of the these technologies in a widely distributed, September 9, 1996, "Virtual Intranet" paper. Bill Pankey, a Tunitas Group partner, was the principal author of this document.
The Privacy Act of 1974 mandates that federal information systems must protect the confidentiality of individually-identifiable data. Section 5 U.S.C. ?552a (e) (10) of the Act is very clear; federal systems must:...establish appropriate administrative, technical, and physical safeguards to insure the security and confidentiality of records and to protect against any anticipated threats or hazards to their security or integrity which could result in substantial harm, embarrassment, inconvenience, or unfairness to any individual on whom information is maintained. One of HCFA's primary responsibilities is to assure the security of the Privacy Act-protected and other sensitive information it collects, produces, and disseminates in the course of conducting its operations. HCFA views this responsibility as a covenant with its beneficiaries, personnel, and health care providers. This responsibility is also assumed by HCFA's contractors, State agencies acting as HCFA agents, other government organizations, as well as any entity that has been authorized access to HCFA information resources as a party to a Data Release Agreement with HCFA.
However, HCFA is also aware that there is a growing demand for use of the Internet for inexpensive transmission of Privacy Act-protected and other sensitive information. We also note that Internet communication is effectively more reliable and efficient than VAN based systems that require scheduling of file transfers. HCFA has a responsibility to accommodate this desire as long as it can be assured that proper steps are being taken to maintain an acceptable level of security for the information involved. This issuance is intended to establish the basic security requirements that must be addressed for use of the Internet to transmit HCFA Privacy Act-protected and/or other sensitive HCFA information. It also addresses the means of documenting that those requirements are met through a self-certifying process.
The term 'HCFA Privacy Act-protected Data and other sensitive HCFA information' is used throughout this document. This phrase refers to data which, if disclosed, could result in harm to the agency or individual persons. Examples include:
(DRAFT) This Guide establishes the fundamental rules and systems security requirements for the use of the Internet to transmit HCFA Privacy Act-protected and other sensitive HCFA information collected, maintained, and disseminated by HCFA, its contractors, and agents.
It will now be permissible to use the Internet for transmission of HCFA Privacy Act-protected and/or other sensitive HCFA information, as long as an acceptable method of encryption is utilized to provide for confidentiality and integrity of this data, and that authentication or identification procedures are employed to assure that both the sender and recipient of the data are known to each other and are authorized to receive such information. Detailed guidance is provided below in item 7.
6. Scope.
(DRAFT) This policy covers all systems or processes which use the Internet, or interface with the Internet, to transmit HCFA Privacy Act-protected and/or other sensitive HCFA information. Non-Internet Medicare/Medicaid data communications processes (e.g., use of private or value added networks) are not changed or affected by the Internet Policy. This policy guidance does not extend to the full range of security protections necessary to protect data while it resides in or is being processed at a local users site, i.e., when not being transmitted. This policy covers Internet data transmission only. It does not cover local data-at-rest or local host or network protections. Sensitive data-at-rest must still be protected by all necessary measures, in conformity with the guidelines/rules which govern the entity's possession of the data. Entities must use due diligence in exercising this responsibility.
Local site networks must also be protected against attack and penetration from the Internet with the use of firewalls and other protections. Such protective measures are outside the scope of this document, but are essential to providing adequate local security for data and the local networks and ADP systems which support it.We note that the Health Insurance Portability and Accountability Act of 1996 (HIPAA) calls for stringent security protection for electronic health information both while maintained and while in transmission. The proposed Security Standard called for by HIPAA was published in the Federal Register on August 12, 1998. The public has until October 13, 1998, to comment on the proposed regulation. Based on public comments, a final regulation is planned for early 1999. Policy guidance contained in this bulletin is consistent with the proposed HIPAA security requirements.
7. Acceptable Methods
(DRAFT) HCFA Privacy Act-protected and/or other sensitive HCFA information sent over the Internet must be accessed only by authorized parties.Technologies that allow users to prove they are who they say they are (authentication and/or identification) and the organized scrambling of data to avoid inappropriate disclosure or modification (encryption) must be used to insure that data travels safely over the Internet and is only disclosed to authorized parties. Encryption must be at a sufficient level of security to protect against the cipher being readily broken and the data compromised. The length of the key and the quality of the encryption framework and algorithm must be increased over time as new weaknesses are discovered and processing power increases. As of September 1998, a level of encryption protection equivalent to that provided by an algorithm such as Triple 56 bit DES for symmetric encryption, 1024 bit algorithms for asymmetric systems, and 160 bits for the emerging Elliptical Curve systems is recognized by HCFA as minimally acceptable. HCFA reserves the right to increase these minimum levels when deemed necessary by advances in techniques and capabilities associated with the processes used by attackers to break encryption (for example, a brute-force exhaustive search). We note that this level of encryption strength is currently provided by domestic versions of commerical web-browser and server products. Export grade encryption, by Federal government design, does not satisfy this requirement. Support for the stronger encryption often requires installation of a patch over the default or bundled freeware \ trialware distributed by Netscape or Microsoft.
User authentication and/or identification must be coupled with the encryption and data transmission process to be certain that confidential data is delivered only to authorized parties. There are a number of effective means for authentication and/or identification which are sufficiently trustworthy to be used, including both in-band authentication and out-of-band identification methods. Passwords should be sent over the Internet only when encrypted.
ENCRYPTION MODELS AND APPROACHES
(DRAFT) Figure 1 depicts three generalized configurations of connectivity to the Internet. The generic model is not intended to be a literal mirror of the actual Internet interface configuration, but is intended to show that the encryption/decryption processes take place prior to information being presented to the Internet for transmission. A large organization would be very likely to have the Internet Server/Gateway on their premises while a small organization would likely have only the Internet Client, e.g., a browser, on premises with the Internet Server at an Internet Service Provider (ISP). The Small User and Large User examples offer a more detailed depiction of the functional relationships involved.
The Encryption/Decryption process depicted graphically represents a number of different approaches. This process could involve encryption of files prior to transmittal, or it could be implemented through hardware or software functionality. The diagram does not intend to dictate how the process is to be accomplished, only that it must take place prior to introduction to the Internet. The 'Boundary' on the diagrams represents the point at which security control passes from the local user. It lies on the user side of the Internet Server and may be at a local site or at an Internet Service Provider depending upon the configuration.
FIGURE 1: INTERNET COMMUNICATIONS EXAMPLES Unfortunately, the copy of the draft we received did not include these figures.
Acceptable Approaches to Internet Usage
(DRAFT) The method(s) employed by all users of HCFA Privacy Act-protected and/or other sensitive HCFA information must come under into one of the approaches to encryption and one (or more) of the authentication or identification approaches. These approaches are as generic as possible and as open to specific implementations as possible, to provide maximum user flexibility within the allowable limits of security and manageability.
Note the distinction that is made between the processes of 'authentication' and 'identification'. In this Internet Policy, the terms "Authentication" and "Identification" are used in the following sense. They should not be interpreted as terms of art from any other source. Authentication refers to generally automated and formalized methods of establishing the authorized nature of a communications partner over the Internet communications data channel itself, generally called an "in-band process." Identification refers to less formal methods of establishing the authorized nature of a communications partner, which are usually manual, involve human interaction, and do not use the Internet data channel itself, but another"out-of-band" path such as the telephone or US mail.
The listed approaches provide encryption and authentication/identification techniques which are acceptable for use in safeguarding HCFA Privacy Act-protected and/or other sensitive HCFA information when it is transmitted over the Internet. In summary, a complete Internet communications implementation would include adequate encryption, employment of authentication or identification of communications partners, and a management scheme to incorporate effective password/key management systems.
(DRAFT) ACCEPTABLE ENCRYPTION APPROACHES
HARDWARE-BASED ENCRYPTION:
1. Hardware encryptors - While likely to be reserved for the largest traffic volumes to a very limited number of Internet sites, such symmetric password 'private' key devices are acceptable.
SOFTWARE-BASED ENCRYPTION:
2. Secure Sockets Layer (SSL) (Sometimes referred to as Transport Layer Security - TLS) implementations - At a minimum SSL level of Version 3.0, standard commercial implementations of PKI, or some variation thereof, implemented in the Secure Sockets Layer are acceptable. In this context, the statement suffers from a problem of type in that it confuses the requiremnet with an implementation mechanism. SSL is a protocol to authenticate server to client and (potentially) client to server, to establish a "session" and to negoitiate parameters for the encryption of messages exchanged during that session. These parameters include a shared "symmetric" encryption key and chosen encryption algorithim. SSL does not require any particular choice of these parameters. Indeed, using "default" SSL configurations in browsers and servers will likely result in no client authentication and 40 bit DES encryption. Furthermore, it is possible to have SSL sessions with no encryption whatsoever. SSL is a powerful tool used to support an authentication / encryption policy; it is, itself, not that policy.
3. S-MIME - Standard commercial implementations of encryption in the e-mail layer are acceptable. S/MIME is a protocol for the "cryptographic enveloping" of MIME messages. Because eMail is asychronous, the sender determines algorithm / key length prior to sending the s/MIME message. s/MIME itself does not determine key length, merely how to securely exchange keys and algorithm information. s/MIME implementations usually support a number of algorithms but the standard only requires support for relatively weak algorithms (due to the federal export restriction and patent concerns). The sender choosing relatively strong encryption may find some receipents unable to decipher the message, while relative insecure messages will routinely be received and decrypted. For example, Netscape's domestic s/MIME implementation's default configuration calls for 168bit DES EDE3, while the "out of the box" Microsoft default is the weak 40 bit DES. This is an area where trading partner and industry cooperation is necessary and appropriate.
We note that, as an application and as a protocol, PGP can also provide technology appropiate to the HCFA requirements.
We believe that HCFA support of SSL and s/MIME is proper as these technolgies are broadly available and are subject to continued scrutiny by the Internet security community. We emphasize, though, that mere use of these technologies does not guarantee statisfaction of the HCFA requirment. Implementation must be appropiately configured and managed.
4. In-stream - Encryption implementations in the transport layer, such as pre-agreed passwords, are acceptable.
5. Offline - Encryption/decryption of files at the user sites before
entering the data communications process is acceptable. These encrypted
files would then be attached to or enveloped within an
unencrypted header and/or transmission.
(DRAFT) ACCEPTABLE AUTHENTICATION AND IDENTIFICATION APPROACHES
AUTHENTICATION (This function is accomplished over the Internet, and
is referred to as an 'in-band' process.)
1. Formal Certificate Authority-based
use of digital certificates is acceptable. The
acceptance of certificates created by a third party CA should come only
after close scrutiny of the CA's issuance policies. As of yet, there
are no formal guidlelines for a healthcare CA and every organization is
left to its own diligence. An introduction to some of the issues
involved can be found in the American
Bar's digital signature guidelines.
2. Locally-managed digital
certificates are acceptable, providing all parties to the communication
are covered by the certificates.
3. Self-authentication,
as in internal control of symmetric 'private' keys, is acceptable.
4. Tokens or 'smart cards'
are acceptable for authentication. In-band tokens involve overall network
control of the token database for all parties.
IDENTIFICATION ( The process of identification takes place outside of
the Internet connection and is referred to as an 'out-of-band' process.)
1. Telephonic identification
of users and/or password exchange is acceptable.
2. Exchange of passwords
and identities by U.S. Certified Mail is acceptable.
3. Exchange of passwords
and identities by bonded messenger is acceptable.
4. Direct personal contact
exchange of passwords and identities between users is acceptable.
5. Tokens or ?smart cards?
are acceptable for identification. Out-of-band tokens involve local control
of the token databases with the local authenticated server vouching for
specific local users.
8. REQUIREMENTS AND AUDITS
(DRAFT) Each organization that uses the Internet to transmit HCFA Privacy Act-protected and/or other sensitive HCFA information will be expected to meet the stated requirements set forth in this document.
All organizations subject to OMB Circular A-130 are required to have a Security Plan. All such organizations should modify their Security Plan if they decide to use the Internet for transmittal of HCFA Privacy Act-protected and/or other sensitive HCFA information. HCFA reserves the right to audit any organization's implementation of, and/or adherence to these requirements. This includes the right to require that any organization utilizing the Internet for transmission of HCFA Privacy Act-protected and/or other sensitive information submit documentation attesting that they meet these requirements.
9. ACKNOWLEDGMENT OF INTENT
(DRAFT) Organizations desiring to use the Internet for transmittal of HCFA Privacy Act-protected and/or other sensitive HCFA information must notify HCFA of this intent. An e-mail address is provided below to be used for this acknowledgment. An acknowledgment must include the following information:
Name of Organization
Address of Organization
Type/Nature of Information being transmitted
For submission of acknowledgment of intent, send an e-mail to:
internetsecurity@hcfa.gov
10. POINT OF CONTACT
(DRAFT) For questions or comment, write to:
Security and Standards Group
Division of HCFA Enterprise Standards -Internet
7500 Security Boulevard
Baltimore, MD 21244