458 A Practical Guide to Security Assessments
6. How are password resets handled?
• When passwords are reset, how are users authenticated?
• Are reset passwords communicated to users in a confidential manner?
• Are users encouraged or forced to change reset passwords?
Guidance: The password-reset process is something commonly used by
social engineers to gain unauthorized access to systems. It is imperative
that users are properly authenticated and that passwords are communicated
in a secure manner. One issue often found is with smaller companies where
IT support personnel “know everyone” and do not necessarily authenticate
individuals. This practice is a problem because it sets the wrong expecta-
tions with users and becomes a problem if turnover occurs or if the entity
grows. If the entity grows, it might be difficult to institute this practice. It
is better to have a standard process that is always followed.
Client Response:
7. What measures are taken to ensure that users safeguard their passwords?
Guidance: One of the things seen in many companies is users having pass-
words on written on yellow sticky notes stuck to their monitors or under-
neath their keyboards. This should be addressed in a security awareness
program and should be part of the IT audit process.
Client Response:
6. STANDARD — SECURITY INCIDENT PROCEDURES
“Implement policies and procedures to address security incidents.”
19
The HIPAA regulations define a security incident as “the attempted or successful
unauthorized access, use, disclosure, modification, or destruction of information or
interference with system operations in an information system.”
20
a. REQUIRED Implementation Specifications
i. Response and Reporting
“Identify and respond to suspected or known security incidents; mitigate, to the extent
practicable, harmful effects of security incidents that are known to the covered entity;
and document security incidents and their outcomes.”
21
AU1706_book.fm Page 458 Tuesday, August 17, 2004 11:02 AM
Appendix Q 459
The requirements make up a standard incident handling policy that any entity should
have in place as part of its security policies. This is another example of the similarity
between HIPAA security regulations and information security best practices. The
questions below are based on some of the comments and clarifications to the security
incident requirement as documented in the Federal Register. In addition to the
questions below, the Incident Handling checklist should be used when evaluating
this HIPAA requirement.
1. Is an incident handling policy in place? (See Incident Handling checklist
for further best practices related to incident handling.)
Guidance: For this requirement, there should be, at the minimum, an In-
cident Handling policy in place. Like the other security policies, it should
be readily accessible by employees and be maintained. With incident man-
agement, some entities, particularly the smaller ones, will say that every-
one knows what to do in the event of an incident. As with other security
policies, this becomes a problem when the number of employees grows or
if turnover occurs. In addition, the policy is a requirement for HIPAA pur-
poses so it must be documented and used for handling security incidents.
Client Response:
2. As part of the incident handling process, are there any requirements for
documenting the details of a security incident?
Guidance: Per the HIPAA regulations, there are no specific documenta-
tion requirements relative to security incidents. Documentation should be
based on the individual entity’s business requirements. Specific recom-
mendations for what to document are contained in the Incident Handling
questionnaire in the appendices of this book.
Client Response:
3. Are there any business or legal requirements related to reporting inci-
dents? If so, are they addressed in the Incident Handling policy?
Guidance: Based on the HIPAA security regulations comments and re-
sponses as documented in the Federal Register, no requirements exist for
internal or external reporting. Companies are free to tailor their reporting
based on their own business requirements. Keep in mind that an entity
AU1706_book.fm Page 459 Tuesday, August 17, 2004 11:02 AM
460 A Practical Guide to Security Assessments
might have other reporting requirements that might drive the reporting as-
pect of its incident handling policy.
Client Response:
b. ADDRESSABLE Implementation Specifications
i. None
7. STANDARD — CONTINGENCY PLAN
“Establish (and implement as needed) policies and procedures for responding to an
emergency or other occurrence (for example, fire, vandalism, system failure, and natural
disaster) that damages systems that contain electronic protected health information.”
22
Note that this requirement is specific to having a plan only in those cases where
electronic protected health information can be lost or compromised. Although com-
ments during the comment period of the HIPAA security legislation process sug-
gested this requirement be removed, it was kept in because in the event of an
emergency, the usual security measures might either be ignored or not working. The
contingency plan serves as a last resort to ensure the security of electronic protected
health information in the event of an emergency. However, in all likelihood, contin-
gency plans related to electronic protected health information (if they exist) are a
component of a larger company-wide contingency plan.
a. REQUIRED Implementation Specifications
i. Data Backup Plan
“Establish and implement procedures to create and maintain retrievable exact copies
of electronic protected health information.”
23
Guidance: Refer to the Backup and Recovery checklist in this book to
evaluate the data backup process. Note that for HIPAA security purposes,
the backup requirements are only for the electronic protected health infor-
mation. However, when performing a security assessment, other data sup-
porting critical operations should be considered.
Client Response:
AU1706_book.fm Page 460 Tuesday, August 17, 2004 11:02 AM
Appendix Q 461
ii. Disaster Recovery Plan
“Establish (and implement as needed) procedures to restore any loss of data.”
24
The questions below address some basic things you should see when looking at a
disaster recovery plan.
1. Does the client have a disaster recovery plan in place?
Guidance: Based on this requirement, a formal documented plan should
be in place.
Client Response:
2. Has the plan been developed using a recognized methodology?
Guidance: The value of developing a plan with a recognized methodology
is that risks and business impacts are identified before the plan is devel-
oped. Identification of the risks is critical to the success of the disaster re-
covery plan. In the case of companies subject to HIPAA, you would
formally identify electronic protected health information as critical data
that must be adequately protected. In addition, using a recognized method-
ology, such as the one promoted by the Disaster Recovery Institute, pro-
vides a good degree of assurance that the plan is thorough.
Client Response:
3. What specific measures are taken for electronic protected health informa-
tion to ensure its confidentiality and security?
Guidance: Because this questionnaire focuses on HIPAA, it is important
to identify the specific measures that would be taken for electronic protect-
ed health information in the event of a disaster. You should review this and
determine whether it is adequate based on the risks facing the company.
Client Response:
AU1706_book.fm Page 461 Tuesday, August 17, 2004 11:02 AM
462 A Practical Guide to Security Assessments
4. Is someone responsible for updating the plan as the environment changes?
Guidance: Companies are constantly changing and some of the changes
might impact the disaster recovery plan. For example, there might be a sig-
nificant change to the IT environment resulting in critical data being
housed on different machines; this can potentially affect the disaster recov-
ery plan. The bottom line is that if the plan is not updated, it can quickly
become obsolete. Someone must own this process to ensure that it is prop-
erly done.
Client Response:
5. Is the plan tested on a regular basis?
Guidance: Disaster recovery can be very complicated, and its certainly
possible that personnel might not get it right the first time. To minimize the
risk of not taking the right steps in the event of a disaster and to ensure that
the disaster recovery plan works, the plan should be tested on a periodic ba-
sis. The testing can range from a simple tabletop exercise to a full-blown test.
Client Response:
iii. Emergency Mode Operation Plan
“Establish (and implement as needed) procedures to enable continuation of critical
business processes for protection of the security of electronic protected health infor-
mation while operating in emergency mode.”
25
This requirement is essentially having an emergency plan in place. Each of the
questions below addresses a specific element of an emergency plan. Below are some
questions to help understand and review emergency plans.
1. What are the critical business processes that, in the event of a disaster,
must continue to protect electronic protected health information? (This is
how “emergency mode” is defined in the HIPAA security regulations.)
Guidance: The HIPAA security regulations require that certain processes
be in place to protect electronic protected health information in the event
of a disaster. Although these processes should likely be a part of a disaster
recovery plan, this question should be asked to ensure that the processes
relevant to HIPAA are identified as critical and that measures are in place
to ensure that electronic protected health information is protected.
AU1706_book.fm Page 462 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.