|
Karen,
Thank you for suggesting in so many words that audit trail capabilities “per se” are not required. As opposed to the Security NPRM (draft security rule) there is no specific requirement for an “audit trail” capability in the final security rule. The “Audit Controls” standard of the final rule which, along with the associated implementation feature, Information System Activity Review (though existing in different sections of the rule), comes closest to the former audit trail description (for which there were many, various implementation interpretations and a fair amount of resulting confusion).
“Audit controls” are defined as representing the requirement to “record and examine system activity” with entities having flexibility to implement the standard in a manner appropriate to their needs as determined by a risk analysis. The definition of “System activity” then is left up to the covered entity to determine what makes sense in their particular environment from a risk management standpoint. Implementation of this standard, along with the implementation feature Information System Activity Review, could certainly include recording every record access and/or update but this level of scrutiny is not required by the regulation. Also note that the rule emphasizes “periodic” and not “continuous” review of an entity’s system logs. Please see the relevant comment/response excerpt from the (full) final security rule below.
There are implications for data authentication, as associated with the “integrity” standard, which can be addressed by audit controls but I believe the integrity standard also can be satisfactorily addressed without implementation of a formal audit trail capability.
Steve Giesecke Couloir Consulting (360) 561-3803
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.
-----Original Message-----
At this point, we can't keep track of every inquiry -
the number is too large, and the disk storage it would need is
cost-prohibitive. Besides, even if we could afford to keep info on every
inquiry, we have *no* idea of how we'd analyze it. So we looked for a reasonable,
scalable solution. Delivered-To: [EMAIL PROTECTED] -----Original Message----- From: Karen Weber [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 05, 2003 1:08 PM To: WEDI SNIP Security Workgroup List Subject: Fwd: Re: Audit
Configuration
Here's what we're doing and/or what we've decided to do. We think that this represents a reasonable first step. We're a multi-specialty medical group with some Health Plan functions (we have our own Managed Care plan, and we are also at risk for several of the Managed Care plans in our area.) 1. Every record in every file that has PHI, has a Last Changed Date/Time/Operator. This doesn't contain history on all changes made - just the last change. We *may* change this in the future, and keep a record of all changes made in the last xx months. 2. We have more job descriptions (role-based access classifications) in our application security now, so we can stop certain people from seeing things that they don't need to see. We're having HR review UserIDs after they're set up, to be sure that supervisors don't build in "responsibility creep" when they're requesting UserIDs. (For example, a department manager may decide that all of her people need "supervisor" capability. IS doesn't question this, and establishes the record as requested, but if they give "supervisor" capability to a non-supervisory person, HR's going to question it.) 3. We've cut back *dramatically* on the amount of information that a non-clinical person can see. This involves (primarily) removing diagnoses, diagnosis descriptions, and procedure descriptions from some of our screens. 4. We have certain records marked as Employees, and other records marked as VIPs. Only people with certain security clearance can look at these records. (They get a message saying "not cleared for this access" when they try to display it.) Also, we're going to record every Read and every Write operation *on these records only.* We're doing this because we felt that recording all Read operations was overkill to the point of silliness and would have cost a huge fortune in additional disk storage. (Also we couldn't figure out what we'd do with these massive amounts of data if we kept it, anyway.) We determined that the records that are most likely to be accessed inappropriately would be those of employees (because you want to know what's going on with a co-worker) and of VIPs (since everybody wants to know what Elton John had done while he was in town). We've talked about expanding this philosophy to records with a sensitive diagnosis (AIDS, mental illness, etc.), or certain sensitive specialties (mental health) but we can't figure out how to manage this, so we've tabled it for now. (When we talked about other classifications of info that might be accessed inappropriately, we also talked about "friends, neighbors and relatives of employees." But we had absolutely *no* idea of how we'd identify these records.) 5. We will be defining what alerts we want to have on Employee and VIP data. So for the records defined in point #4, what should trip a "panic button?" Our discussions are going along the lines of: If you aren't one of the patient's physicians, or a member of that physician's staff, you shouldn't be looking at the record. (Haven't figured out how to define "this physician is OK, that one's not" without cutting off consulting physicians. Suggestions are welcome.) 6. For the records defined in #4, we're going to periodically spot-check the activity on a limited number of records - a random audit of all activity. We haven't defined how often or how many records. In these audits, the auditor would look at the activity, and will look for justification of "why did this person look at this record." If he can't easily tell why (for example, because this was the appointment scheduler for one of the patient's physicians), he's going to make the person who accessed the record justify why they were looking at it. We'd welcome any comments, suggestions or questions on what we're doing, either on- or off-list.
At 11:49 AM 11/5/2003 -0600, you wrote: Has anyone created any guidance for their organization as to how various audit mechanisms should be configured to track access to PHI? I am looking for a balanced approach to configuring system/application audit mechanisms to record creates, reads, writes and the success or failure of events (or an appropriate combination thereof)?
What Im really looking for is .....if a system/application administrator were to ask you (as the security/privacy guru) what you would like the system to track&..what would be the got to haveand nice to haveevents you would have them record?
If youre thinking of sending me to CMS, AHS, or NIST for guidance&&&.dont bother. I would like to know what people are reallydoing.
Dale "Chip" Dahlstrom, CISSP Chief Security/Privacy Officer Office: (812) 228-2013 Cell: (812) 204-2310 Availability--Integrity--Confidentiality -- Healthcare that works -- Healthcare that is safe -- Healthcare that leaves no one behind
NOTE: This e-mail message may contain information that may be privileged, confidential, and exempt from disclosure. It is intended for use only by the person to whom it is addressed. If you have received this message in error, please do not forward or use this information in any way, delete it immediately, and contact the sender as soon as possible by the reply option or by telephone at the telephone number listed (if available). Thank you. --- The WEDI SNIP listserv to which you are subscribed is not moderated. The discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. These listservs should not be used for commercial marketing purposes or discussion of specific vendor products and services. They also are not intended to be used as a forum for personal disagreements or unprofessional communication at any time. You are currently subscribed to wedi-security as: [EMAIL PROTECTED] To unsubscribe from this list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED] If you need to unsubscribe but your current email address is not the same as the address subscribed to the list, please use the Subscribe/Unsubscribe form at http://subscribe.wedi.org
Karen Weber [EMAIL PROTECTED] 602-430-5612 FAX 877-496-7816
Karen Weber [EMAIL PROTECTED] 602-430-5612 FAX 877-496-7816 --- The WEDI SNIP listserv to which you are subscribed is not moderated. The discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. These listservs should not be used for commercial marketing purposes or discussion of specific vendor products and services. They also are not intended to be used as a forum for personal disagreements or unprofessional communication at any time. You are currently subscribed to wedi-security as: [EMAIL PROTECTED] To unsubscribe from this list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED] If you need to unsubscribe but your current email address is not the same as the address subscribed to the list, please use the Subscribe/Unsubscribe form at http://subscribe.wedi.org
The WEDI SNIP listserv to which you are subscribed is not moderated. The discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. These listservs should not be used for commercial marketing purposes or discussion of specific vendor products and services. They also are not intended to be used as a forum for personal disagreements or unprofessional communication at any time. You are currently subscribed to wedi-security as: [EMAIL PROTECTED] To unsubscribe from this list, go to the Subscribe/Unsubscribe form at http://subscribe.wedi.org or send a blank email to [EMAIL PROTECTED] If you need to unsubscribe but your current email address is not the same as the address subscribed to the list, please use the Subscribe/Unsubscribe form at http://subscribe.wedi.org |
- RE: Re: Audit Configuration Upleger, Grace
- RE: Re: Audit Configuration Vishnevsky, Jacob
- Fwd: RE: Re: Audit Configuration Karen Weber
- RE: RE: Re: Audit Configuration Vishnevsky, Jacob
- Re: Audit Configuration Stephan Giesecke
- Re: Audit Configuration Ben Walters
- Re: Audit Configuration Kenneth Dildy
- RE: Audit Configuration Price, Carolyn
