Tim, I would not agree with your assessment about the threat from external sources. Here is a case in point article and there are numerous articles about the internet vulnerabilities of university healthcare facilities.
http://online.securityfocus.com/news/122 Regards, David Frenkel Business Development GEFEG USA Global Leader in Ecommerce Tools www.gefeg.com 425-260-5030 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 17, 2002 12:16 AM To: Bill Pankey; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Integrity Control and Applications Bill, without regard to beliefs. The documented abuse issues revolving around PHI Privacy and Security have uniformly come from internal sources, either the organization using PHI inappropriately, or its personnel doing so. Outside hackers, crackers, and script kitties represent a real threat, but a largely unrealized one to date in healthcare. Regardless, integrity comes from assuring authenticity of the whole work flow. I too agree that stamping every packet in any extraordinary way is unnecessary, that the use of standard best practice safeguards, encryption using SSL for web transmission (or intranet), with additional infrastructure safeguards, such as: active monitored intrusion detection (such as CounterPane), coupled with strong firewalls, antivirus software on a network level, thorough models and documentation, and complete security practices and policies address most issues. As long as there is a strong process in place to stay current with security, that's most of the battle. However, I recently had the displeasure to hear about an application being implemented that negates all of this. We can't forget the applications themselves. Frankly, in my opinion, applications should be looked at VERY carefully as a major potential source of both integrity breakdown, and Security AND Privacy vulnerabilities. Code reviews, where possible, should be a part of both privacy AND security risk assessments and gap analysis when dealing with custom apps and even many commercially available apps based upon platforms like MSSQL, Oracle, DB2/400, etc. By their very nature, many universal reporting tools to give full access are used. Also, application development tools that build in unknown features over and above the specific programmatic requirements are common - do you know what overhead code or libraries are compiled into your finished app? Far to many have residual access for maintenance or performance monitoring, or excessive access far beyond minimum necessary. I'm not concerned about Microsoft's OS and its auto-update intentions, but I am concerned about webapps and enterprise apps that phone home, that have maintenance backdoors, or no real thought to security beyond a password. Many apps created using standard tool sets have their own unique set of vulnerabilities over and above those of the OS. This includes webapps that allow patient access with extensive tracking mechanisms built in. All of these need to be carefully factored into your security and privacy model. Apps also need to be included in the policies and procedures of an organization - most do not. From a Privacy perspective, some of the greatest danger comes from webapps used in clinical practice. Huge numbers of "Spyware" are automatically installed on user's systems. One such called "Gator" actually sends home the contents of every HTML form filled in. Other so-called browser plug-ins are equally bad. Some Spyware cons the user into installing it for its enhanced feature set, but most is almost unavoidable being installed with the display of banner ads or on less than ethical websites. Anti-Spyware tools need to be used in addition to antivirus software, and the organization's policies need to tightly control the uses of systems used for enterprise purposes, especially if they access the web, where a simple java applet can easily defeat the best central firewall (hence the reason for human monitoring services, and spyware detectors). In short, there are a number of things that can be done to tighten up your apps, even though the security rule isn't final, they still represent Privacy vulnerabilities and liabilities and require mitigation where they exist. There can be no excuse for a poorly documented application, without a complete understanding of its use cases and data flow, a comprehensive description of its security schema, and thorough policies on minimum necessary access, with equally thorough control of the infrastructure that supports it. Also, all claims of HIPAA compliance for applications, relating to privacy and security should be treated as suspect and subject to rigorous proof. I would like to suggest to both the Privacy and Security workgroups that consideration be given to IG's that apply to applications specifically. There are existing standards documents that support ASCA's rules, but I feel that a more holistic approach to guidelines may be needed. I would be pleased to participate in their development. If anyone would like to discuss this further, please feel free to contact me. Tim McGuinness, Ph.D. Consulting Specialist in Privacy and Security [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> President, HIPAA Help Now Inc. [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> www.hipaahelpnow.com <http://www.hipaahelpnow.com/> Executive Co-Chairman for Privacy, HIPAA Conformance Certification Organization (HCCO) www.hipaacertification.org <http://www.hipaacertification.org> __________________________________________________________________ Phone: 727-787-3901 Cell: 305-753-4149 Fax: 240-525-1149 Instant Messengers: ICQ# 22396626 - MSN IM: [EMAIL PROTECTED] - Yahoo IM timmcguinness - AOL IM: mcguinnesstim __________________________________________________________________ ======================================================================== === IMPORTANT NOTICE: This communication, including any attachment, contains information that may be confidential or privileged, and is intended solely for the entity or individual to whom it is addressed. If you are not the intended recipient, please notify the sender at once, and you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message is strictly prohibited. Nothing in this email, including any attachment, is intended to be a legally binding signature. -----Original Message----- From: Bill Pankey [mailto:[EMAIL PROTECTED]] Sent: Monday, September 16, 2002 5:24 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: 'Integrity Conrol' vs 'Message Authentication' Chris I appreciate what you say. Certainly TCP is spoofable but it provides a valuable service in protecting against transmission errors, dropped packets and the like and therefore is important to 'integrity'. My question is not 'whether or not', but how integrity controls are cost effectively implemented and, from a compliance point of view, isolated. The idea that all packets should be signed seems far fetched. To do as much can hardly be cost ineffective as it essentially ignores all of the HCO effort with respect to activities like physical access control, personnel screening, workstation security and so forth. If I were transmitting over the public Inet, then I would consider signing all packets. I discount the conventional wisdom that most attacks are from inside the LAN, although I accept that insecure workstations are often the vector for attack. HCO spend a lot of effort screening personnel who after all, are 'caregivers'. In some ways it antithetical for a provider organization to protect itself from malicious activity of its staff. Afterall the HCO give knives to its people and takes responsibility for the consequences <g>. Bill ********************************************************************** To be removed from this list, go to: http://snip.wedi.org/unsubscribe.cfm?list=privacy and enter your email address. 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/. Posting of advertisements or other commercial use of this listserv is specifically prohibited. To be removed from this list, go to: http://snip.wedi.org/unsubscribe.cfm?list=Security and enter your email address. <P>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/. Posting of advertisements or other commercial use of this listserv is specifically prohibited.