Larry, I think the scenario Chris described is just one of all the possible scenarios we face. Especially because your clearing house and list of payers tends to be fairly static (in the scheme of things). So I guess I'd approach it a little bit differently. I'd ask, what problem are you trying to solve? Communications with business associates? with payers? with providers? remote support from IT vendors? remote access for employees? patient access to their own information?
Let's look at the situation where we are granting remote access through the web to community physicians (for treatment & payment purposes)in an Extranet/VPN scenario. Community providers also tend to be fairly static (except when you throw in the mix of medical students and residents on clinical rotations). So, how many accounts will you have and is it feasible to manage things like issuing tokens? Also, do you want to provide access from their offices only, or do you want to make it available from their homes, or even when travelling? In such a scenario you face the challenge of whether to require digital certificates and whether those are going to live in someone's hard-drive or in a token that the user can carry along so that access is an option from whatever the location. If it's feasible, I'd recommend the latter. The same would apply to patients which for the most part are not a static population at all. But the numbers are far greater than the numbers of providers, employers, contractors and other BA's combined. The challenge then is to decide whether you have the resources to deploy and manage dual factor authentication (say a token + pin) that the patient can utilize w/o having to retrofit clients with readers etc (when you do that, you're basically restricting access to a pre-set range of remote locations anyway, and making it hard for those folks that travel, etc). Here the costs would be huge and I think this is a scenario where strong PW would suffice. Since you would restrict access to their own information, if the patient is not careful with his/her PW, then I would think it's his/her problem. For remote vendor access you may want to set up a call-back procedure so you don't have to deploy tokens (plus you know for sure when a vendor is coming into your network because you don't activate their domain accounts until you verify the request via phone or a digitally signed email). This obviously assumes the number of IT vendors is relatively small and requires the ability to respond quickly to such requests and assumes a 24/7 operation. Now, I'd keep in mind the spirit of the regs when evaluating each problem to be solved. HIPAA makes it a point to recommend balancing risks versus costs. And if your risks are relatively low and you don't have many resources, then a strong PW policy may be the answer for your organization. Anyway, I've rambled on for a while, but I guess the bottom line is that there is not a single answer and the best method will depend on a case by case basis. I' would assume that most of us are exploring different approaches to solve different problems. a. Albert Oriol, CHE, CISSP Privacy & Data Security Officer The Children's Hospital [EMAIL PROTECTED] (303) 861 6094 "All things should be as simple as possible, but no simpler" -- Albert Einstein -----Original Message----- From: Chris Riley [mailto:[EMAIL PROTECTED]] Sent: Friday, February 08, 2002 7:39 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Web authentication for HIPAA Larry, When HIPAA protected data is accessed via a web server the custodian of the data must protect against un-authorized access. This problem has a different twist than the way you would normally think about it. Typically, HIPAA data would not be pulled from a website (in that case you would have to guarantee the identity of the receiving party) but rather pushed to the site in the case of a provider sending a claim request to a clearing house. In this example, it is the provider who is responsible to guarantee the identity of the clearing house. When a clearing house website uses SSL and a Certification Authority (CA), a number of things happen. The providers web browser gets an encrypted packet from the clearing house containing a guarantee from the CA that the clearing house is who they claim to be. It is our opinion that the CA guarantee combined with a proper business partner agreement is sufficient to transfer the data. The other side of this coin are the issues surrounding the receiver of the data. The clearing house needs to be reasonably sure that the data they receive is from a known source otherwise the quality of their service could be impacted. Unfortunately, SSL does nothing to address this issue and that is where the discussion of passwords versus digital certificates comes into play. The problem with passwords (even strong passwords), is that users tend to do thinks like write them on sticky notes and paste them on their screens. Because the issuer of the password (clearing house) can not control how the password is used, it does not really provide a strong guarantee that the user is who they claim they are. They are however better than no authentication at all. Digital Certificates, on the other hand will provide a guarantee to the receiver that the sender is who they claim to be. This is really an issue receiver of the data has to resolve. Although Digital Certificates are not required by HIPAA, the receiver has to decide how this may impact their quality of service. Hope this helps, Chris Riley, CISSP Information Tool Designers Inc. http://aegis.info-tools.com/ "Hooser, Larry" wrote: > HIPAA does not require digital certificates for web authentication. There > is a reason for that related to cost, overhead, customer impact, lack of > standardization, and others. Some also are not convinced that they add a > great deal of value to security. Ultimately, if the user shares the pin > number, you have the same security breach as sharing the username and > password. There are some physical access improvements, but the question is > are they substantial. > > I believe that strong, rules-based usernames and passwords, along with > effective identification and issuance processes, does provide "reasonable > care" and effective web authentication. I also agree that digital > certificates may have their place in some cases. > > Is there anyone out there planning to use strong, rules-based > usernames/passwords for HIPAA web authentication - or are all of you leaning > toward PKI as the ONLY authentication method? Where portability, cost, > customer impact, performance, and other consideration are of concern in > using digital certificates, can usernames/passwords be a viable, trusted > alternative? > > Feedback appreciated. > > Larry D. Hooser > DSHS/MAA WMS Security Manager/HIPAA Consultant > 617 8th Ave SE, Bldg 1 - 4th Floor > Olympia, WA 98504-5511 > email: [EMAIL PROTECTED] > Phone: 360.725.1236 > > ********************************************************************** > To be removed from this list, go to: http://snip.wedi.org/unsubscribe.cfm?list=privacy > and enter your email address. -- ********************************************************************** To be removed from this list, go to: http://snip.wedi.org/unsubscribe.cfm?list=privacy and enter your email address. CONFIDENTIALITY NOTICE: The information contained in this message is legally privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any release, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the author immediately by replying to this message and delete the original message. Thank you. ********************************************************************** To be removed from this list, send a message to: [EMAIL PROTECTED] Please note that it may take up to 72 hours to process your request.
