Having problems with message search?
Administrative Safeguards - § 164.308
A covered entity must, in accordance with § 164.306:
-
-
Standard: Security management process. Implement policies and procedures to prevent, detect, contain, and correct security violations.
-
Implementation specifications:
-
Risk analysis (Required). Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity.
-
Risk management (Required). Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with § 164.306(a).
-
Sanction policy (Required). Apply appropriate sanctions against workforce members who fail to comply with the security policies and procedures of the covered entity.
-
Information system activity review (Required). Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports.
-
-
Comment: We proposed a requirement for internal audit, the in-house review of the records of system activity (for example, logins, file accesses, and security incidents) maintained by an entity. Several commenters wanted this requirement deleted. One suggested the audit trail requirement should not be mandatory, while another stated that internal audits would be unnecessary if physical security requirements are implemented.
A number of commenters asked that we clarify the nature and scope of what an internal audit covers and what the audit time frame should be. Several commenters offered further detail concerning what should and should not be required in an internal audit for security purposes. One commenter stated that ongoing intrusion detection should be included in this requirement. Another wanted us to specify the retention times for archived audit logs.
Several commenters had difficulty with the term "audit" and suggested we change the title of the requirement to "logging and violation monitoring."
A number of commenters stated this requirement could result in an undue burden and would be economically unfeasible.
Response: Our intent for this requirement was to promote the periodic review of an entity's internal security controls, for example, logs, access reports, and incident tracking. The extent, frequency, and nature of the reviews would be determined by the covered entity's security environment. The term "internal audit" apparently, based on the comments received, has certain rigid formal connotations we did not intend. We agree that the implementation of formal internal audits could prove burdensome or even unfeasible, to some covered entities due to the cost and effort involved. However, we do not want to overlook the value of internal reviews. Based on our review of the comments and the text to which they refer, it is clear that this requirement should be renamed for clarity and that it should actually be an implementation specification of the security management process rather than an independent standard. We accordingly remove "internal audit" as a separate requirement and add "information system activity review" under the security management process standard as a mandatory implementation specification.
Au-1.b User Association
AU-2.b Content of Audit Records
AU-3.b Auditable Events
Au-4.b Audit Processing
AU-5.b Audit Reduction and Report Generation
AU-6.b Non-Repudiation
From AU-3.b The Auditable Events include:
1. start-up and shutdown of the audit functions
2. successful and unsuccessful logons and logoffs
3. successful and unsuccessful attempts to access security relevant files and utilities including user authentication information
4. operations performed to read, modify or destroy the audit information
5. modifications to the audit configuration that occur while the audit functions are operating
6. actions taken due to exceeding of a threshold or audit storage failure
7. unsuccessful use of the user identification or authentication mechanisms including the identify provided
8. unsuccessful revocations of security attributes
9. modifications to the group of users that are part of a role
10. key recovery requests and associate responses including who made the request and when
11. changes to the time
12. denial of access resulting from an excessive number of logon attempts
13. blocking or blacklisting a user ID, terminal, or access port and the reason for the action
14. detected replay attacks
15. rejections of new sessions based upon any limitation on the number of concurrent sessions
16. other activities that modify, bypass, negate security controls with the information system
17. use of compilers
18. use of privileged accounts.
| NIST SP 800-14 | Generally Accepted Principles and Practices for Securing Information Technology Systems |
| NIST SP 800-18 | Guide for Developing Security Plans for Information Technology Systems |
| NIST SP 800-26 | Security Self-Assessment Guide for Information Technology Systems |
| NIST SP 800-27 Rev A | Engineering Principles for Information Technology Security (Baseline for Achieving Security) |
| NIST SP 800-30 Rev A | Risk Management Guide for Information Technology Systems |
| NIST SP 800-37 | Guide for the Security Certification and Accreditation of Federal Information Systems |
| NIST SP 800-53 | Recommended Security Controls for Federal Information Systems |
| NIST SP 800-60 | Guide for Mapping Types of Information and Information Systems to Security Categories |
| DRAFT NIST SP 800-65* | Integrating IT Security into Capital Planning and Investment Control Process* |
| FIPS 199 | Standards for Security Categorization of Federal Information and Information Systems |
| NIST SP 800-12 chapter 5 | An Introduction to Computer Security: The NIST Handbook |
The access audit logs on their own are useless, unless a human reviews their results and takes action when inappropriate access is identified. The logic for this requirement is understood and the requirement to review these logs in a timely fashion is also understood. However, logging all accesses to ePHI, whether authorized or not, places an inordinate burden on an organization by essentially replicating through a log review the very functions which the identification, authentication and authorization control system is specifically designed to provide.
1. Who or how will this logging be reviewed/audited?
2. How will the reviewer know if it was an unauthorized access?
A technical security control in the Logical Access Control (AC) Family of recommended NIST security controls (DRAFT NIST SP 800-53) might be used for system users to "self-audit". It is AC-2.b Logon Notification Message.
"Control Objective: In accordance with organizational policy, automated mechanisms are in place and detailed supporting procedures are developed, documented, and effectively implemented to provide users with information about previous logons both successful and unsuccessful.
Upon successful logon, the user is notified of the date and time of the user's last logon, the location of the user's last logon, and the number of unsuccessful logon attempts using this user ID since the last successful Logon. A warning/notification message is displayed upon successful logon and before gaining system access. The message:
(i) is approved and standardized; (ii) remains on the screen until
explicit user action to remove it; (iii) warns all users that they
have accessed a U.S. Government information system [this may not
apply to your organization, so you will need to modify]; (iv)
provides appropriate privacy and security notices; (v) notifies the
user that system usage may be monitored, recorded, and subject to
audit, and (vi) notifies the user that use of the information system
indicates (a) the consent of the user to such monitoring and
recording and (b) the unauthorized use is prohibited and subject to
criminal and civil penalties."
This may be a way for individual system users to audit their own access log and notify the appropriate contact should unsuccessful attempts, or the prior successful logon was/are in error (i.e., someone did/or attempted to access the system pretending to be the authorized system user).
Thought I would mention this technical security control, as I can't figure out how auditing sign-ons to a system by anyone other than the authorized system user could flag an unauthorized access if an authorized user's ID and password were used. Also, most systems have this technical capability available. The resources involved in
implementing this may be very marginal. The hardest part will most likely be getting authorized system users to read the screen before taking the explicit action to remove it and getting the authorized system users to inform the appropriate entity that the prior log-on information or attempted log-on information is suspicious.
I have made an audio/video presentation titled "DeMystify Security - NISTify IT!" It is web accessible and made freely available to all 24/7 by Blass Consulting, LLC. It spends about 30 minutes showing how to use Draft NIST SP 800-53. It also steps you through each phase of the NIST Security Risk Management Program from "defining the scope" to monitoring and audit. I have provided information below my signature block providing access information to this presentation and additional information about HIPAA ComplyAssistant, a HIPAA compliance management.
Regards,
Barbara McGowin, CPC
Executive Recruiting
HIT Recruiting
(843) 824-8537
mcgowins@...
Connecting Healthcare Organizations with People,
Products and Services to Achieve HIPAA Compliance.
HIPAA ComplyAssistant (HCA) www.complyassistant.com is the leading tool in providing NIST functions and features for HIPAA privacy and security compliance management, and HCA provides the only tool to help manage a TCS compliance plan.
How does HCA automate your compliance? By providing functions to document and manage surveys, issues, incidents, complaints, gap assessment, and mitigation work plan and budget development. The software provides work plans and budget reports, trending snapshot graphs and reports, links to valuable websites, and policy management. In addition, HCA includes a function to document and manage PHI (protected health information) data exchange.
The end result is a central database of project management and due diligence documentation
One of HCA’s user-friendly functions is the flexible and easy to customize question master. Because of this function, HCA may now be delivered with its standard HIPAA content or with the NCHICA HIPAA EarlyView™ Privacy and Security content. Or, use your own HIPAA privacy or security survey!
The following audio/video recordings are available and freely accessible. Just click “Presentations” at www.complyassistant.com
DeMystify Security – NISTify IT!
HIPAA TCS – Become Compliant and Avoid Fines
Providers’ Current Realities of HIPAA Privacy, Security, and TCS
Payers’ Current Realities of HIPAA Privacy, Security, and TCS
Seeing is believing!!!! Request a live demo anytime at: www.complyassistant.com/online_meeting_req.htm
Offline 
Send Email