Appendix Q 453
ii. Protection from Malicious Software
“Implement procedures for guarding against, detecting, and reporting malicious soft-
ware.”
16
This requirement, before the final draft of the regulations, was related only to com-
puter viruses. The terminology was changed to “malicious software” to include
malicious acts such as worms.
1. Have there been any recent incidents relating to viruses, worms, or other
malicious software?
Guidance: Recent incidents relating to malicious software and how the
entity reacted to it will provide significant information regarding how ma-
licious software is handled. Many of the questions below can be answered
as a result of this question.
Client Response:
2. Is anti-virus software in use in the IT environment?
Guidance: Anti-virus software should be running where appropriate
based on the individual company’s business requirements. To the extent
possible, anti-virus software should be centrally managed and locked
down on PCs, so that employees cannot prevent it from running.
Client Response:
3. Are virus signatures updated on a regular basis?
Guidance: Ideally, this should be done automatically with minimal human
intervention. Depending on the risk, the company may consider multiple
anti-virus vendors to decrease the associated risk.
Client Response:
AU1706_book.fm Page 453 Tuesday, August 17, 2004 11:02 AM
454 A Practical Guide to Security Assessments
4. Do users know what to do in the event that they encounter malicious
software?
Guidance: This question speaks to incident handling, which is a related
HIPAA requirement. There should be a documented process for incident
handling complete with escalation guidelines, contact names, etc. (see In-
cident Handling questionnaire for further details)
Client Response:
5. Do the security risks of the entity justify any type of network- or host-
based intrusion management system? If not, what mitigating controls are
in place to protect systems with electronic protected health information
against malicious software or intrusions? How would the company know
if someone was trying to gain unauthorized access to electronic protected
health information?
Guidance: Depending on the complexity of the environment, how it is
managed, and the associated risk, intrusion management might be a viable
option for the entity. Within a security assessment, key factors must be
considered when recommending intrusion management including moni-
toring capabilities, risks, and cost. Besides formal intrusion management
systems, there are specific logs already on a system, which, if reviewed,
can also help mitigate some of the associated risk.
Client Response:
6. On the systems where electronic protected health information resides, are
the following measures taken to reduce the risk of malicious software?
• Application of appropriate security and other patches
• Systems hardened to the extent possible
Guidance: Earlier in this book, one of the points emphasized was the idea
of layered security. System hardening and the application of security
patches are two of these layers. During a security assessment, as critical
systems are identified, the application of patches and system security
should be tested using tools as well as manual procedures. Depending on
the system, there are best practice guidelines, which can be used as a
benchmark to evaluate how secure it is.
AU1706_book.fm Page 454 Tuesday, August 17, 2004 11:02 AM
Appendix Q 455
Client Response:
iii. Log-In Monitoring
“Implement procedures for monitoring log-in attempts and reporting discrepancies.”
17
This requirement gets into specific measures related to the log-in process. In systems
such as Windows 2000, built-in logs readily provide this information. They key
impact of this specification is that entities will potentially need to be proactive with
regard to log-in monitoring.
1. Where the relevant systems support the following features, are they used?
• Are system controls used to record log-in attempts?
• Does the system lock users out after a certain number of failed log-in
attempts?
• Are users’ logins restricted by other means such as time of day?
Guidance: Where system features are available for enforcing company se-
curity policy, they should be used. If these features are not being used,
there is a question as to how logins are being monitored. When recom-
mending the use of system features for user administration security, con-
sider the education and support impacts (from a help desk perspective).
These changes require awareness, and there will likely be an increase in
help desk calls, which must be addressed.
Client Response:
2. Is there any real-time notification when failed log-in attempts occur on
critical machines where electronic protected health information resides?
Guidance: Real-time notification is a proactive approach to dealing with
intrusions, and this information may be available in the system logs. If no
mechanism for notification exists, there might be a need for monitoring on
a regular basis.
Client Response:
AU1706_book.fm Page 455 Tuesday, August 17, 2004 11:02 AM
456 A Practical Guide to Security Assessments
3. Are the appropriate logs that detail log-in attempts reviewed on a regular
basis? Based on logs, are investigations made as needed?
Guidance: Many systems have logs that record information about log-in
attempts, which should be reviewed on a regular basis. The review can
either be done manually or by using third-party tools. If anything suspi-
cious is found, an investigation should be initiated.
Client Response:
iv. Password Management
“Implement procedures for creating, changing, and safeguarding passwords.”
18
This specification goes into the details of good password management. The HIPAA
security regulations recognize the importance of passwords and that they are a first
line of defense.
1. When a new account is created for the network or specific applications
that access electronic protected health information, how is the initial
password communicated?
Guidance: Falsely obtaining passwords is a common social engineering
technique used by malicious individuals to gain unauthorized access. As a
result, communication of initial passwords should be done in a secure
manner. Steps should be taken to properly authenticate individuals receiv-
ing passwords. In some smaller environments where everyone is familiar
with each other, this may not be taken as seriously. This becomes more of
an issue as entities grow, where it becomes more difficult to know everyone.
Client Response:
2. Are users encouraged or forced to change their initial passwords?
Guidance: If possible, the system should be used to force users to change
initial passwords. If not forced, may users will not change initial pass-
words. Depending on the support capabilities, it might be useful (and fea-
sible) to walk users through this process so they understand it. If the
system does not support it, the importance of changing the initial password
should be taught to users in an education or awareness session.
AU1706_book.fm Page 456 Tuesday, August 17, 2004 11:02 AM
Appendix Q 457
Client Response:
3. Does the system enforce strong password standards?
Guidance: Passwords are the most basic level of protection, and a signif-
icant amount of risk related to unauthorized access can be eliminated with
strong passwords. If available, the system should force users to have strong
passwords. Keep in mind that clients might push back by saying that there
will be too many support calls or that users will start placing their pass-
words on post-it notes stuck to their monitors. In this case, you should pro-
vide techniques for users to develop strong passwords such as using the
first letters of words in a phrase or substituting certain characters for letters.
Client Response:
4. If the system does not enforce strong passwords, is the strength of pass-
words audited?
Guidance: If the system cannot enforce strong passwords, the strength of
passwords should be audited as part of the standard IT audit process. There
are third-party tools available for auditing password strength.
Client Response:
5. Are users encouraged or forced to change passwords on a regular basis?
Is there a policy on recycling old passwords?
Guidance: Passwords should be changed on a regular basis (at least every
45 to 90 days) and there should be a policy on not being able to recycle
recent passwords. In addition, users should be discouraged from using
passwords such as names of months and other obvious names (the system
might be able to enforce this). This should be addressed within a security
awareness program.
Client Response:
AU1706_book.fm Page 457 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.