A P R I L
2 0 0 3
Take Four Steps to Address
‘Addressable’ Implementation
Specifications . . . . . . . . . . . . . . . . . . . . 1
You don’t necessarily have to adopt
“addressable” specifications, but you
do need to consider them. Here’s what
the government expects.
Required and Addressable
Implementation Specifications (p. 3)
Set Limits on E-Mail Forwarding
to Outsiders to Prevent Security
Leaks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
A potential loophole in network
security, and how to close it.
Model Clause: Add Forwarding Limits
to Your E-Mail Use Policy (p. 5)
Create Policy on Usernames and
Password Storage to Safeguard
Databases . . . . . . . . . . . . . . . . . . . . . . . 6
How to ensure that a potentially
dangerous blind spot doesn’t
undermine your access control
strategy.
Model Policy: Give IT Staff
Standards for Username/Password
Storage (p. 7)
Dos & Don’ts . . . . . . . . . . . . . . . . . . . . . 8
Apply Security Policies to Your
Telecommuters
Don’t Limit Contract Negotiations
to a Single ‘Winning’ Vendor
Don’t Overlook Portable Devices
When Creating Your Workstation
Use Policy
IN FUTURE ISSUES
■
How to Document a Decision Not to
Adopt an Addressable Specification
Because It's Unreasonable
■
Create Hardware Disposal Policy that
Complies with Media Controls Standard
■
Don’t Let Overambitious Audit Trails
Strategy Expose You to Liability
Take Four Steps to Address
‘Addressable’ Implementation
Specifications
One of the most confusing aspects of the final HIPAA security regulations is
dealing with the “addressable” implementation specifications. What’s the
problem? The security regulations set 22 standards that health care organizations must meet to safeguard the confidentiality, integrity, and availability of
electronic protected health information (EPHI). Many of these standards are
accompanied by implementation specifications—that is, instructions on how
to meet that particular standard. These implementation specifications are listed as either required or addressable. If an implementation specification is listed as required, you must implement it. If it’s listed as addressable, you don’t
have to implement it unless it’s reasonable and appropriate in light of costs
and your organization’s own situation.
That’s where things get confusing. Just because an implementation specification is addressable doesn’t mean you can ignore it or reject it out-of-hand
as too expensive. The security regulations require you to consider each
addressable implementation specification systematically as part of your overall security risk assessment and to document the assessment, notes California
health information attorney Steven M. Fleisher.
Here’s a four-step process you can follow to assess whether or not you
should implement the addressable implementation specifications.
1) Distinguish Required from Addressable Specifications
First, identify all the implementation specifications and determine if they’re
addressable or required, notes Fleisher. We’ve printed a list of the standards
and their implementation specifications, on p. 3, that shows what’s required
and what’s addressable.
Insider Says: Note that our list includes six security standards that don’t
list implementation specifications. In these cases, the preamble to the final
security regulations explains, “the standard itself includes all the necessary
instructions for implementation.” These instructions are the equivalent of
required implementation specifications. So, for example, the assigned security responsibility standard requires organizations to appoint one person to be
responsible for compliance with the security regulations. Although this
requirement is part of the standard and not listed as a separate specification,
you should also treat it as a required implementation specification.
(continued on p. 2)
2
HIPAA
SECURITY
COMPLIANCE
INSIDER
APRIL 2003
‘ADDRESSABLE’ IMPLEMENTATION SPECIFICATIONS (continued from p. 1)
BOARD OF ADVISORS
M. Peter Adler, Esq., CISSP Reece Hirsch, Esq.
Foley & Lardner
Washington, DC
Margret Amatayakul,
RHIA, FHIMss
Sonnenschein, Nath &
Rosenthal
San Francisco, CA
Gwen Hughes
Margret A. Consulting, LLC
Schaumburg, IL
Care Communications
Chicago, IL
Chris Apgar, CISSP
Sybil Ingram-Muhammad,
MBA, PhD
Providence Health Plan
Beaverton, OR
Peter Bartoli, CTO
Alphafight Heavy Industries
San Diego, CA
Joan Boyle
Trizetto Co.
Newport Beach, CA
Michael Ebert, CPA, CISA
NCO Group
Horsham, PA
Steven M. Fleisher, Esq.
Fleisher & Associates
Alamo, CA
Tom Hanks
Intellimark
Stone Mountain, GA
Robert P. Laramie
New Tech Consultancy, Inc.
N. Andover, MA
Richard D. Marks, Esq.
Davis Wright Tremaine LLP
Washington, DC
Susan A. Miller, Esq.
HIPAA Certified, LLC
Concord, MA.
Miriam J. Paramore
E-Commerce for Healthcare
Louisville, KY
PricewaterhouseCoopers LLP Harry E. Smith, CISSP
Chicago, IL
PrivaPlan Associates, Inc.
Lakewood, CO
Editors: Glenn S. Demby, Esq., Amy E. Watkins, Esq.
Executive Editors: David B. Klein, Esq.,
Nicole R. Lefton, Esq., Susan R. Lipp, Esq., Janet Ray
Senior Editors: Nancy Asquith, Heather Ogilvie
Copy Editors: Cynthia Gately, Graeme McLean
Proofreader: Lorna Drake
Production Director: Mary V. Lopez
Senior Production Associate: Sidney Short
Director of Planning: Glenn S. Demby, Esq.
New Projects Editor: Rebecca L. Margulies, Esq.
Dir. of Ref./Information Development: John D. Boyd
Marketing Director: Peter Stowe
Associate Marketing Director: Ellen Teatsorth
Director, List Services: Denise M. Fisher
Marketing Mgrs.: Christine Chan, Michael F. Sherman
Data Processing Manager: Rochelle Boorstein
Sales Manager: Joyce Lembo
Customer Service Reps.: B. Maslansky, H. Therezo
Director of Operations: Michael Koplin
Fulfillment Supervisor: Edgar A. Pinzón
Financial Manager: Janet Urbina
Administrative Assistant: Maria Safina
Publisher: George H. Schaeffer, Esq.
Owners: Andrew O. Shapiro, Esq.,
John M. Striker, Esq.
Subscriptions: HIPAA Security Compliance Insider is
published monthly. Subscription rate: $297 for 12 monthly
issues. Address all correspondence to: Brownstone
Publishers, Inc., 149 Fifth Ave., New York, NY 10010-6801.
Tel.: 1-800-643-8095 or (212) 473-8200; fax: (212) 473-8786;
e-mail: [email protected]; [email protected].
Disclaimer: This publication provides general coverage of
its subject area. It is sold with the understanding that the
publisher is not engaged in rendering legal, accounting, or
other professional advice or services. If legal advice or
other expert assistance is required, the services of a competent professional should be sought. The publisher shall
not be responsible for any damages resulting from any
error, inaccuracy, or omission contained in this publication.
© 2003 by Brownstone Publishers, Inc. No part of this publication may be reproduced or transmitted in any form or by
any means, electronic or mechanical, including photocopying, recording, or any information storage and retrieval system, without written permission from the publisher.
2) Assess Reasonableness and Appropriateness of
Addressable Specifications
For each addressable implementation specification, assess whether implementing it would be reasonable and appropriate for your particular situation, says
Fleisher. The regulations list the factors you should consider in making this
assessment, including:
■ The organization’s size and complexity;
■ The organization’s technical infrastructure, hardware, and software security capabilities;
■ The costs of implementing the specification; and
■ The probability that the potential risk to EPHI will occur and how harmful it would be if it did.
3) Implement Specification, Alternative, or Neither
Based on the results of your assessment in Step 2, do one of the following
three things with respect to each specification:
If specification is reasonable and appropriate, implement it. If you
determine that the implementation specification is reasonable and appropriate,
you must implement it.
If specification isn’t reasonable or appropriate, implement a reasonable alternative. If you determine that the implementation specification is
unreasonable and/or inappropriate, you needn’t implement it. But then you
must determine whether or not there’s an alternative that’s reasonable and
appropriate that you can use to meet the particular standard, Fleisher explains.
If so, you must implement it.
The preamble provides the following example to illustrate how this works:
An addressable implementation specification for meeting the integrity standard is using electronic mechanisms to confirm that EPHI hasn’t been altered
or destroyed in an unauthorized manner. But it might be unreasonable and
inappropriate for a small medical office to make electronic copies of EPHI.
“Rather,” the preamble explains, “it might well be more practical and afford a
sufficient safeguard to make paper copies of the data.” Making paper copies,
then, would be a reasonable and appropriate alternative that the office would
have to implement.
But experts say they have trouble with this example. “It doesn’t make
sense unless the amount of EPHI is tiny,” notes Fleisher. “It would seem more
reasonable for the office to implement a software solution that protected EPHI
from improper access rather than print out reams of paper.”
Another example that’s not mentioned in the regulations,” says Fleisher,
“would be for an organization to share a simple encryption program with
key parties to whom it e-mails EPHI rather than implement an expensive
PKI installation.” Eventually, inexpensive PKI solutions will become available. But in the meantime, this simple temporary solution could suffice,
he says.
(continued on p. 4)
© 2003 by Brownstone Publishers, Inc. Any reproduction is strictly prohibited. For more information call 1-800-643-8095 or visit www.brownstone.com
APRIL 2003
HIPAA
SECURITY
COMPLIANCE
3
INSIDER
Required and Addressable Implementation Specifications
Here’s a chart to help you understand what standards health care
organizations must meet to comply with the HIPAA security
regulations. The chart also shows which of those standards have
implementation specifications explaining how to meet the standard, what those specifications are, and whether they’re required
or addressable (marked with an R or an A, respectively). This is
critical because your organization must implement required
implementation specifications. You needn’t implement addressable implementation specifications if they’re not reasonable or
appropriate, but you may have to implement an alternative.
Note that where a standard has no separate implementation
specifications, the instructions for the standard are considered
implementation specifications, and they’re required.
SECURITY STANDARDS
ADMINISTRATIVE SAFEGUARDS
PHYSICAL SAFEGUARDS (continued)
STANDARD
IMPLEMENTATION SPECIFICATIONS
R=REQUIRED, A=ADDRESSABLE
STANDARD
IMPLEMENTATION SPECIFICATIONS
R=REQUIRED, A=ADDRESSABLE
Security Management Process
■
Risk Analysis (R)
Risk Management (R)
■ Sanction Policy (R)
■ Information System Activity
Review (R)
Facility Access Controls
■
■
(continued)
Access Control &
Validation Procedures (A)
■ Maintenance Records (A)
Workstation Use
(R)
Assigned Security Responsibility (R)
Workstation Security
(R)
Workforce Security
Device & Media Controls
■
Authorization/Supervision (A)
Workforce Clearance
Procedure (A)
■ Termination Procedures (A)
■
Information Access Mgmt.
Security Awareness & Training
Isolating Health Care
Clearinghouse Functions (R)
■ Access Authorization (A)
■ Access Establishment &
Modification (A)
■
Security Reminders (A)
Protection from Malicious
Software (A)
■ Log-in Monitoring (A)
■ Password Management (A)
TECHNICAL SAFEGUARDS
STANDARD
IMPLEMENTATION SPECIFICATIONS
R=REQUIRED, A=ADDRESSABLE
Access Control
■
Unique User ID (R)
Emergency Access
Procedure (R)
■ Automatic Logoff (A)
■ Encryption & Decryption (A)
■
■
■
Security Incident Procedures
■
Contingency Plan
■
Response & Reporting (R)
Data Backup Plan (R)
Disaster Recovery Plan (R)
■ Emergency Mode Operation
Plan (R)
■ Testing & Revision
Procedures (A)
■ Applications & Data Criticality
Analysis (A)
■
Evaluation
(R)
Business Associate Contracts
& Other Arrangements
■
Written Contract or Other
Arrangement (R)
PHYSICAL SAFEGUARDS
STANDARD
IMPLEMENTATION SPECIFICATIONS
R=REQUIRED, A=ADDRESSABLE
Facility Access Controls
■
Contingency Operations (A)
■ Facility Security Plan (A)
Disposal (R)
Media Re-use (R)
■ Accountability (A)
■ Data Backup & Storage (A)
■
■
Audit Controls
(R)
Integrity
■
Mechanisms to Authenticate
EPHI (A)
Person or Entity Authentication (R)
Transmission Security
■
■
Integrity Controls (A)
Encryption (A)
OTHER REQUIREMENTS
STANDARD
IMPLEMENTATION SPECIFICATIONS
R=REQUIRED, A=ADDRESSABLE
Business Associate Contracts
or Other Arrangements
■
Requirements for
Group Health Plans
■
Policies & Procedures
(R)
Documentation
■
Business Associate
Contracts (R)
■ Other Arrangements (R)
Amendment of Plan
Documents (R)
Time Limit (R)
Availability (R)
■ Updates (R)
■
© 2003 by Brownstone Publishers, Inc. Any reproduction is strictly prohibited. For more information call 1-800-643-8095 or visit www.brownstone.com
4
HIPAA
‘ADDRESSABLE’ IMPLEMENTATION
SPECIFICATIONS (continued from p. 2)
If specification isn’t applicable
and there’s no reasonable alternative, implement neither. You may
also decide to implement neither the
addressable implementation specification nor an alternative if you determine
that the particular implementation
specification isn’t applicable to your
situation and that it can be met in some
other fashion.
The preamble lists the following
example. Creating policies for granting individual users the right of access
to a workstation containing EPHI is
an addressable implementation specification under the information access
management standard. This may be
reasonable and appropriate in large
SECURITY
COMPLIANCE
INSIDER
organizations where users perform
distinct functions and don’t all need
access to a workstation. But the preamble notes this implementation
specification wouldn’t apply to a
small practice where all users have
the same access rights to a workstation. But workforce members would
still need to have their own strong
passwords so that access can be
tracked, Fleisher notes.
4) Document Your Decisions
The final step in assessing addressable implementation specifications is
documenting your decisions. This is
especially important if you decide not
to implement an addressable specification. In these cases, the regulations
require you to document:
APRIL 2003
■ The decision not to implement
the addressable specification;
■ The rationale behind that decision; and
■ Either the alternative safeguard
you implemented—and why it’s a reasonable and appropriate way to meet
the standard—or how the standard
can be met in some way other than
implementing the addressable specification or an alternative.
Insider Says. In a future article,
the Insider will explain how to create
this documentation. ■
Insider Source
Steven M. Fleisher, Esq.: Fleisher & Assocs.,
35 Corwin Dr., Alamo, CA 94507; [email protected].
Set Limits on E-Mail Forwarding to Outsiders
to Prevent Security Leaks
More and more physicians, nurses,
and other health care workers are
using e-mail to communicate. Although e-mail is often more convenient than phone calls and face-to-face
conversations, the security risks are
significant—especially when an
e-mail contains protected health information (PHI). So it’s not surprising
that the HIPAA security regulations
require organizations to safeguard the
confidentiality of PHI that’s e-mailed
or otherwise stored or transmitted
electronically (EPHI).
To safeguard confidentiality and
ensure compliance with HIPAA, many
organizations have begun creating an
e-mail use policy that their workforce
members must follow. Unfortunately,
many policies the Insider looked at
contain a huge loophole: They don’t
set limits on the forwarding of e-mail
to persons or entities outside the
organization. This isn’t a trivial loop-
hole—it can undermine the security of
your entire network.
Risk of Forwarding
When an e-mail recipient at your organization forwards e-mail to an e-mail
address outside your organization, the
risk of unauthorized and inadvertent
disclosures of EPHI increases. This is
true whether the e-mail is forwarded
manually (the recipient takes certain
steps to forward each e-mail) or automatically (the e-mail server automatically forwards the recipient’s e-mails to
certain e-mail addresses—for example,
to covering physicians).
Here are some reasons why e-mail
forwarding to outside addresses is
so risky:
■ The e-mails are vulnerable to
interception, cautions health information consultant Michael Ebert.
“E-mail is often sent in clear text
formats that are easily read by any-
body listening in to the network,”
Ebert explains;
■ The e-mails can be compromised by macro viruses, script monitors, account emulators, and the like;
■ Once e-mail is forwarded to an
outside address, it’s no longer protected by the security measures you use
for your own network. “You have to
rely on the recipient’s network and
e-mail server to keep the communication secure,” Ebert explains. “This
eliminates the benefits of the measures you take to secure your own
communications network”; and
■ You have no control over where
the message goes next. That is, recipients of forwarded messages may forward them on to anyone they please,
Ebert points out.
Insider Says: Problems can also
arise when somebody in your organization forwards an e-mail that she has
received from an outside sender. The
© 2003 by Brownstone Publishers, Inc. Any reproduction is strictly prohibited. For more information call 1-800-643-8095 or visit www.brownstone.com
APRIL 2003
HIPAA
original sender may be able to track
where the message is subsequently
forwarded by using one of the new
wiretapping programs available, Ebert
says. This may allow the original
sender to learn the e-mail addresses
and names of subsequent recipients.
The original sender may even read
any data, including PHI, that the recipient attaches to the e-mail. Many
popular software programs used for
e-mail are vulnerable to this so-called
e-mail wiretapping, including Microsoft Outlook, Outlook Express, and
Netscape 6 Mail.
Include Forwarding Limits in
E-Mail Use Policy
To protect against these dangers, your
organization’s policy on the acceptable
use of e-mail by workforce members
should include limits on forwarding of
e-mail messages to outsiders. Those
limits should cover both types of forwarding that may be used—manual
and automatic.
To help you add these limits to
your e-mail use policy, we’ve created
a Model Clause (see at right) that you
can adapt and add to the policy. It’s
based on a model policy published
by the SysAdmin, Audit, Network
Security Institute, and the advice of
experts. Like our Model Clause,
yours should:
Warn of dangers. Warn your
workforce members that both manual
and automatic forwarding of e-mail
can compromise the security of PHI
[Clause, par. a];
Bar automatic forwarding. Bar
automatic forwarding of any e-mail
messages to outside locations without
the prior approval of the workforce
member’s supervisor [Clause, par. b];
and
Limit manual forwarding. Limit
manual forwarding to outsiders of any
SECURITY
COMPLIANCE
INSIDER
e-mail that contains PHI. (Your organization should formally define PHI in
its information security policy.) There
are two ways to establish such limits:
1) You can bar manual forwarding
of these e-mails without the supervisor’s prior permission. This approach
gives an organization the best chance
of heading off improper disclosures of
PHI, Ebert notes.
But making workforce members
get supervisor permission each time
they want to forward an e-mail is
administratively burdensome and
highly restrictive. “There may be compelling business reasons to give certain workforce members the discretion
to forward e-mails,” Ebert explains; or
2) You can bar manual forwarding
except when forwarding of certain
information is critical for treatment
and the information is appropriately
encrypted. The advantage of this
approach is that it gives workforce
members more discretion; but that’s
also its disadvantage [Clause, par. c].
“Realistically, education and training are the keys to the effectiveness of
any policy for e-mail forwarding,”
Ebert explains. “But it’s even more
crucial for the second approach”.
Insider Says: Another way to
eliminate the risk of forwarding is to
give certain workforce members an
e-mail set-up that allows them to read
but not send e-mail. “This may be
appropriate for workforce members
like janitorial staff and outside or contract personnel, who only need to be
able to receive e-mails but not to
respond to them,” notes Ebert. ■
Insider Source
Michael Ebert, CPA, CISA: Senior Vice President–Business Systems, NCO Group, Inc.,
507 Prudential Rd., Horsham, PA 19044; (609)
932-3679; [email protected].
MODEL CLAUSE
Add Forwarding Limits to Your E-Mail Use Policy
Forwarding and automatic forwarding
of e-mail can put your e-mail security—and the rest of your network—at
risk. Here’s a Model Clause you can
use to reduce that risk. It was written
with the advice of experts and is
based on a model policy published by
a.
5
the SysAdmin, Audit, Network Security Institute (SANS).You can adapt
this clause and add it to your organization’s e-mail use policy. (If your
policy already has a clause on forwarding, you may want to compare
your clause to our Model Clause.)
FORWARDING OF E-MAIL
Purpose. Forwarding of e-mail, both manually and automatically, can result
in the unauthorized disclosure of protected health information (PHI) about
patients. The purpose of this policy is to prevent such disclosures.
b.
Automatic Forwarding Restrictions. Workforce members must exercise
extreme caution when forwarding e-mail from inside XYZ Clinic to a person
or entity outside the XYZ Clinic communications network. Accordingly,
workforce members may not automatically forward e-mail messages to
any such person or entity without the prior approval of their supervisor.
c.
Forwarding Restrictions. Workforce members may not manually forward to outside persons or entities any e-mail that includes PHI [select one
of the following options]
[Option 1] without the prior approval of their supervisor.
[Option 2] unless the forwarding of such information is critical for treatment
and appropriately encrypted in accordance with the XYZ Clinic health information security policy.
© 2003 by Brownstone Publishers, Inc. Any reproduction is strictly prohibited. For more information call 1-800-643-8095 or visit www.brownstone.com
6
HIPAA
SECURITY
COMPLIANCE
INSIDER
APRIL 2003
Create Policy on Usernames and Password Storage
to Safeguard Databases
You’ve got a tough security issue to
deal with if, like most health care
organizations, you use usernames
and passwords to authenticate the
identity of users and their authorization to access databases. Improper
electronic storage of usernames and
passwords can create potentially
huge security problems. Unauthorized parties could get at them and
use them to access your organization’s databases and the protected
health information (PHI) they contain. This can lead to violations of
the HIPAA security regulations and
make it harder for you to audit your
system for intrusions by outsiders
and misuse by insiders.
Don’t assume that the storage
your software package currently provides for usernames and passwords is
sufficiently secure, cautions security
expert Peter Bartoli. “Third-party and
custom in-house software often fail
to provide adequate protection for
passwords and usernames,” he explains. It’s up to your IT staff to audit
the software’s storage features and
make sure they provide the appropriate protection. And it’s up to you to
tell your IT staff what to look for.
“IT staff members are unlikely to be
familiar with the HIPAA regulations,” Bartoli explains.
To overcome that hurdle, Bartoli
recommends that you create a storage
policy for your IT staff to follow. This
storage policy should be incorporated
into the overall username and password policy that your organization
should have to comply with HIPAA.
Here’s how to create a storage policy.
There’s a Model Policy on p.7 that
you can use or adapt.
HIPAA and Username/
Password Storage
The HIPAA security regulations
require organizations to implement
technical safeguards, including information access controls and authentication mechanisms, to protect the
integrity, confidentiality, and availability of electronic PHI (EPHI). “The
HIPAA security regulations list the
standards organizations must meet,
but don’t dictate the specific technologies or methods they should use
to do so,” says health information
expert Michael Ebert. Usernames and
passwords can be a viable way to
meet the access controls and authentication standards—even though the
security regulations don’t specifically
mention them and even though
they’re considered less secure than
other authentication mechanisms like
biometrics and smart cards.
But if you use usernames and passwords, you need to address the electronic storage problem. Creating a
storage policy for your IT staff is one
of the keys to doing that, notes Bartoli.
What Storage Policy
Should Say
Your policy, like our Model Policy,
should start by explaining its purpose—to ensure the secure electronic
storage of usernames and passwords
in compliance with HIPAA [Policy,
par. 1]. And like our Model Policy,
your policy should provide standards
that state, at a minimum, that usernames and passwords:
Must be stored separately from
the executing files of the database
program. To run an executable—that
is, a file storing a program, such as a
database—a user must be allowed to
read its contents. Tell your IT staff
that the file containing usernames and
passwords should be stored in a separate location from the executables.
“Usernames and passwords should be
stored in a different location where
permission to read them can be
denied. Putting them in an executable
is like keeping the key right next to
the locked room,” says Bartoli.
Storing usernames and passwords
in executables also makes it harder to
detect an intrusion or to modify
passwords in response to an intrusion. “If an intrusion occurs, you’ll
have the lengthy, thankless, and
sometimes impossible job of filtering out the legitimate users and programs from the illegitimate ones to
determine who wasn’t supposed to
be on the system,” explains Bartoli
[Policy, par. 2a].
Insider Says: If a username and
password are needed to access data
within a program, tell your IT personnel to use a hash number or pointer
instead of the actual username/password combination, advises Bartoli.
That will keep the actual username/
password combination more effectively hidden from prying eyes [Policy,
par. 2c].
Must be stored in a file that’s
not world readable. Tell IT staff that
the file that stores your users’ usernames and passwords shouldn’t be set
up as world readable. “If the file is
world readable, virtually any person
who gets access to any computer on
which the file resides will be able to
retrieve the credentials list and to
attempt to decrypt passwords. This
would assist an intruder immeasurably,” says Bartoli [Policy, par. 2b].
Insider Says: Tell IT staff to limit
access to the file holding usernames
© 2003 by Brownstone Publishers, Inc. Any reproduction is strictly prohibited. For more information call 1-800-643-8095 or visit www.brownstone.com
APRIL 2003
HIPAA
and passwords as much as possible.
“Special privileged access should be
required to access this file and should
be granted only for the proper purposes,” says Bartoli.
Must be stored in a directory, if
applicable. Tell IT staff that your
usernames and passwords must be
stored in an authentication server,
also known as a directory, if such a
directory exists and is interoperable
with your application. An authentication server’s main function is to
reduce administrative overhead by
storing valid credentials—such as
usernames and passwords—in a central location. This central location
should have additional security
measures to protect its sensitive payload. Then you can rely on credentials stored in an authentication
server to allow only authorized users
stored in the server to log in to desktops, enter the database, and perform
tasks based upon their authorized
level of access. Generally, if your
usernames and passwords are stored
in the authentication server, they
needn’t be stored anyplace else on
your system [Policy, par. 2d].
Must not be stored in a Web
server’s documents tree. Tell IT staff
that files containing usernames and
passwords in any form must not be
stored in the documents tree of a Web
server or any other anonymously
available service—that is, a location
that contains data published to Web
browsers. “Usernames and passwords,
like any other kind of sensitive information, shouldn’t be stored in a location devoted to public viewing,”
cautions Bartoli [Policy, par. 2e].
Must be authenticated for
access by the database itself. Tell IT
staff that access to any computer,
database, or application must not be
granted solely on the basis of a
remote user’s authentication to any
SECURITY
COMPLIANCE
INSIDER
other computer, such as their desktop.
It may be easy for someone to forge
authorization to access another computer and then try to use that authorization to enter the database. Tell IT
staff there must be some other verification method before access is granted—for example, a verification
method through your database or
authentication server, advises Bartoli
[Policy, par. 2f]. ■
Insider Source
Peter Bartoli, CTO: Alphafight Heavy Industries, PO Box 12714, San Diego, CA 92112;
(619) 702-1071; www.alphafight.net.
Michael Ebert, CPA, CISA: Senior Vice President–Business Systems, NCO Group, Inc.,
507 Prudential Rd., Horsham, PA 19044; (609)
932-3679; [email protected].
MODEL POLICY
Give IT Staff Standards for Username/
Password Storage
Here’s a Model Policy instructing IT
staff on how usernames and passwords should be stored electronically.
The policy was adapted with the help
of Peter Bartoli, from a policy created
by the System Administrator and Network Security (SANS) Institute. After
explaining that its purpose is to
1.
ensure compliance with HIPAA, the
Model Policy lists six standards for
storing usernames and passwords.
You can use or adapt the Model
Policy for your own storage policy.
You should incorporate your storage
policy into your organization’s overall
username and password policy.
POLICY ON STORAGE OF USERNAMES AND PASSWORDS
Purpose. The security regulations of the Health Insurance Portability and
Accountability Act of 1996 (HIPAA) require the implementation of technical
measures, including access controls and authentication mechanisms to
safeguard the confidentiality, integrity, and availability of information systems that contain electronic protected health information (EPHI). The purpose of this policy is to help you determine whether the usernames and
passwords that our organization’s database users use to access databases
with EPHI are being securely stored in accordance with HIPAA.
2.
7
Standards. The following standards apply to the storage of usernames and
passwords:
a. Usernames and passwords must be stored separately from the executable files comprising a program’s code.
b. Usernames and passwords must be stored in a file that is not world
readable. Moreover, special privileged access should be required to
access files containing usernames and passwords, and such access
should be granted only for proper purposes.
c. Hash numbers, handles, pointers, or references may be used in software to identify credentials as long as they do not contain any usernames or passwords.
d. Usernames and passwords or the files containing them must be
stored on an authentication server or directory if one is available and
interoperable with an application or database.
e. Usernames and passwords or files containing them must not be
stored in the documents tree of a Web server or in any other application or server that is easily accessible by a Web browser or any
other network client.
f.
Access to any computer, database, or application must not be granted solely on the basis of a remote user’s authentication to any other
computer, such as the user’s desktop computer. A trusted database
or server must also verify or authenticate access.
© 2003 by Brownstone Publishers, Inc. Any reproduction is strictly prohibited. For more information call 1-800-643-8095 or visit www.brownstone.com
8
HIPAA
SECURITY
D O S
COMPLIANCE
&
✓
Apply Security Policies to Your
Telecommuters
Make sure your organization has security policies for all
employees who handle electronic protected health information (EPHI)—including telecommuters, says HIT consultant Dr. Sybil Ingram-Muhammad. Otherwise, you won’t
meet the workforce security standard of the HIPAA security regulations.
The HIPAA security regulations require health care
organizations to implement certain measures to ensure that
members of their workforce who handle EPHI keep it confidential. The preamble to the final regulations makes it clear
that an organization’s “responsibility to implement security
standards extends to the members of its workforce, whether
they work at home or on-site.” By implication, this responsibility would also apply to mobile employees like ambulance
drivers and EMS personnel, adds Ingram-Muhammad.
✗
Don’t Limit Contract Negotiations to a
Single ‘Winning’ Vendor
Don’t limit yourself to only one software vendor when you
select the “winner” of your bidding process. If one vendor
believes it’s the only one in the running and that all that
remains is to sign a contract, you’ll undermine your bargaining position in contract negotiations, cautions health
care attorney Steven J. Fox.
Keep in mind that everything in a vendor’s form agreement is negotiable—including price, payment terms, and
warranties, notes Fox. But leverage determines how good a
deal you can negotiate. If the vendor knows you’re no
longer considering competitors, it weakens your bargaining
position. So rather than declaring one vendor the winner,
Fox recommends selecting two vendors. “Start negotiating
with your first choice, but let it know that if things don’t
work out, the second choice is waiting in the wings,” he
INSIDER
APRIL 2003
D O N ’ T S
says. “This keeps the pressure on the preferred vendor and
generates additional concessions.”
✗
Don’t Overlook Portable Devices When
Creating Your Workstation Use Policy
Don’t overlook laptops, PCs, and other portable devices
when creating a workstation use policy for your organization. A workstation use policy that covers just “fixed location devices” isn’t good enough to satisfy the HIPAA
security regulations, notes HIT consultant Harry E. Smith.
The workstation use standard of the HIPAA security
regulations requires health care organizations to “implement policies and procedures that specify the proper functions to be performed, the manner in which those functions
are to be performed, and the physical attributes” of the
workstation. It wasn’t clear in the proposed security regulations that workstations included portable devices like laptops, Smith says. But in the preamble to the final security
regulations, HHS said it didn’t mean to limit workstations
to fixed location devices.
Accordingly, the final security regulations include a
new definition of “workstation” as “an electronic computing device, for example, a laptop or desktop computer, or
any other device that performs similar functions, and electronic media stored in its immediate environment.” So if
your workstation use policy doesn’t address portable
devices, it won’t pass muster, according to Smith. ■
Insider Sources
Steven J. Fox, Esq.: Pepper Hamilton LLP, 600 14th St. NW, Washington, DC 20005; (202) 220-1260; [email protected].
Sybil Ingram-Muhammad, MBA, PhD: Sr. Practice Director, Healthcare Privacy and Security Solutions, 5295 Hwy. 78, Ste. D, #228, Stone
Mountain, GA 30087.
Harry E. Smith, CISSP: Vice President of Product Development, PrivaPlan Assocs., Inc., 10300 W. 23rd Ave., Lakewood, CO 80215.
© 2003 by Brownstone Publishers, Inc. Any reproduction is strictly prohibited. For more information call 1-800-643-8095 or visit www.brownstone.com