478 A Practical Guide to Security Assessments
5. Who has access to the logs and if the logs were altered, could that be
identified?
Guidance: The foundation of tracking activity is the logs. Access to the
logs should be restricted to the extent possible. No one should have any ac-
cess to modify any information on the logs. Depending on the risk, it might
be appropriate to deploy tools to check the integrity of the logs.
Client Response:
ii. Emergency Access Procedure
“Establish (and implement as needed) procedures for obtaining necessary electronic
protected health information during an emergency.”
47
This requirement relates to technical measures including backups and the ability to
recover. The Backup and Recovery questionnaire in the Appendices and the emer-
gency plan questions from the HIPAA questionnaire should be used to check com-
pliance with this requirement.
b. ADDRESSABLE Implementation Specifications
i. Automatic Logoff
“Implement electronic procedures that terminate an electronic session after a predeter-
mined time of inactivity.”
48
This was originally a “required” specification, which was changed to addressable
because the automatic logoff feature is not always available. Based on the comments
and responses documented, some type of equivalent measure based on a specific
entity’s risk analysis can also be used.
1. Where available, is the “automatic logoff” mechanism used?
Guidance: This is a very specific control where you need to verify wheth-
er or not the system supports it. If it does support it but is not being used,
it might be because the client is not aware of it. If recommending the use
of this feature, warn the client that there will be some support issues in the
beginning.
Client Response:
AU1706_book.fm Page 478 Tuesday, August 17, 2004 11:02 AM
Appendix Q 479
ii. Encryption and Decryption
“Implement a mechanism to encrypt and decrypt electronic protected health information.”
49
As a form of security, encryption provides confidentiality of information. This
became an “addressable” requirement because it was questioned how valuable and
feasible it was to encrypt data. The cost of encrypting information and the ongoing
maintenance and support can be very expensive for small entities and even some
larger entities. Making this specification “addressable” gave entities the option to
encrypt data based on their specific risks.
1. Has the client’s risk analysis addressed the issue of data encryption?
Guidance: The client’s risk analysis should have considered the issue of
encryption. Based on the risk analysis, the client should be able to articu-
late why encryption is or is not being used.
Client Response:
2. STANDARD — AUDIT CONTROLS (REQUIRED)
“Implement hardware, software, and/or procedural mechanisms that record and exam-
ine activity in information systems that contain or use electronic protected health
information.”
50
This standard essentially requires entities to evaluate the systems currently in use
and determine if they can record and examine activities of individuals accessing
electronic protected health information in the systems. Note that the standard spe-
cifically mentions hardware and software. Compliance with this standard may require
new systems or custom coding of existing systems. Audit controls, by their nature,
are flexible in nature and depend on the level of risk. The comments and subsequent
responses as documented in the Federal Register clearly state that the audit controls
should be based on the entity’s own risk analysis. This specification should be
analyzed in conjunction with the related Privacy specifications, which require entities
to account for disclosures of protected health information to individuals upon
request.
1. As part of the risk analysis, has the client reviewed these hardware and
software mechanisms for recording activity?
Guidance: This requirement is based on the risk analysis. When determin-
ing what is to be reviewed, the client should consider current staffing and
AU1706_book.fm Page 479 Tuesday, August 17, 2004 11:02 AM
480 A Practical Guide to Security Assessments
how the additional work will be handled (assuming it is not being done
already).
Client Response:
2. For cases where activity is to be reviewed, does the client have documented
procedures for what has to be reviewed, when logs are generated, etc.?
Guidance: The resulting reviews that are instituted to achieve compliance
with this requirement are a process that should be documented. There
should be minimum requirements for these reviews and there should be
some expectation of what the review entails. A procedure is a good place
to capture these requirements.
Client Response:
3. STANDARD — INTEGRITY
“Implement policies and procedures to protect electronic protected health information
from improper alteration or destruction.”
51
Integrity of information is one of the pillars of information security. The point of
this standard is that electronic protected health information should not be altered in
an unauthorized manner. The integrity standard ties into the earlier requirement that
individuals’ activities should be tracked to guard against unauthorized alteration of
data. There are tools such as “integrity checkers” and intrusion detection systems
that claim to do integrity checking. In addition, some systems might have native
tools to check integrity. Software as well as existing system mechanisms should be
investigated when evaluating compliance with this requirement.
a. REQUIRED Implementation Specifications
i. None
b. ADDRESSABLE Implementation Specifications
i. Mechanism to Authenticate Electronic Protected Health Information
“Implement electronic mechanisms to corroborate that electronic protected health infor-
mation has not been altered or destroyed in an unauthorized manner.”
52
AU1706_book.fm Page 480 Tuesday, August 17, 2004 11:02 AM
Appendix Q 481
As alluded to earlier, specific software and potentially existing tools on systems can
corroborate that electronic protected health information has not been improperly
altered. Examples of built-in data authentication mechanisms include error-correct-
ing memory and magnetic disc storage. In addition, processes that utilize checksums
or digital signatures can be considered.
1. Has the integrity of data been considered in the client’s risk analysis?
Guidance: Review the risk analysis to determine whether it was considered.
Client Response:
2. Are there any mechanisms such as “integrity checkers” in place?
Guidance: Some companies have deployed tools such as Tripwire to en-
sure the integrity of critical files. If the client does not have something like
this in place, determine what tools, if any, are in use.
Client Response:
3. Based on the risk analysis, where (if anywhere) is it appropriate to deploy
integrity-checking tools?
Guidance: Determine where electronic protected health information re-
sides and where it makes sense to have which integrity checking tools. In
different cases, you may be able to deploy cheaper solutions; it all depends
on the risk analysis.
Client Response:
4. STANDARD — PERSON OR ENTITY AUTHENTICATION
“Implement procedures to verify that a person or entity seeking access to electronic
protected health information is the one claimed.”
53
Guidance: This specification builds on the first specification in the Tech-
nical Safeguards section requiring users to have unique user IDs. In the
AU1706_book.fm Page 481 Tuesday, August 17, 2004 11:02 AM
482 A Practical Guide to Security Assessments
initial draft, this specification listed actual technologies that can be used to
come into compliance with this requirement. In the final adopted rule, any
reference to technology was intentionally omitted to allow companies to
use methods that made sense based on their own risk levels. Some of the
methods that can be considered when implementing this specification in-
clude (as documented in the initial draft):
•A “biometric” identification system
•A “password” system
•A “personal identification” system
•A “telephone callback” system
• Digital signatures
• Soft tokens
1. When providing support for technologies used in this specification, how
are individuals authenticated?
Guidance: One of the most significant security risks is social engineering.
It is critical that users are properly authenticated when they are provided
with any support related to gaining access to systems. This is often a prob-
lem in smaller companies where the attitude of support personnel is “I
know everyone here.” Look for specific procedures for authenticating users.
Client Response:
5. STANDARD — TRANSMISSION SECURITY
“Implement technical security measures to guard against unauthorized access to elec-
tronic protected health information that is being transmitted over an electronic com-
munications network.”
54
Guidance: The regulations thus far have been focused on the security of
electronic protected health information that is in a system. This require-
ment focuses on the transmission of that information over an “electronics
communication network.” To clarify this further, the network is essentially
an untrusted network, such as the Internet. To properly evaluate this re-
quirement, a thorough process evaluation of how information is sent
should be performed.
1. Identify all instances where information is sent over a public network
(e.g., the Internet).
Guidance: Examples include: patient information sent electronically to
other health care entities, agencies, insurers; billing information sent to
AU1706_book.fm Page 482 Tuesday, August 17, 2004 11:02 AM
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.