2229 Dutch Gold Dr, Lancaster, PA 17601
717.993.4693
hello@chstechsolutions.com

Remote desktop is, by default, not HIPAA compliant

We Make I.T. Work

Created with Sketch.

Remote desktop is, by default, not HIPAA compliant

With today’s workload, long hours, and pressure to get more done in less time, remote access to your work computer can be a life saver. The remote access we will be discussing in this article is accessing your work desktop, files, printers, and applications. There are a number of options, some are better than others.

HIPAA says the following about remote access:

Any access from the Internet or a remote location must be encrypted. This means healthcare information going across the Internet cannot be read until it reaches the authenticated user on the other end where is it decrypted.
Passwords should be stored in a central, manageable location like a managed firewall or windows server.
Remote access is tracked and attempts to connect are also logged.
Login and Password are sent as encrypted data.
Unlimited attempts to guess or crack a password are stopped by the VPN device.

There are a number of solutions that are HIPAA compliant out of the box. If you use logmein for your remote access you can stop reading, logmein achieves all of the above. VNC and TeamViewer can be configured to be HIPAA compliant with some changes to there default installation. 

But what about multiple office access, and the convenience of the Microsoft solution Remote Desktop Protocol (RDP)? Citrix is an “upgraded” fuller featured version of remote desktop and does not need VPN or the overhead of RDP.

RDP between offices or from home to the office by itself is NOT HIPAA compliant, it fails on 1, 4, and 5 above. However, it can be HIPAA compliant, PCI compliant, and accepted as Standard Business Security if you use RDP across a virtual private network (VPN).

So how can a healthcare facility allow remote access without violating HIPAA, PCI, and other security standards?

We recommend installing a firewall, in particular a Sonicwall Firewall. The Sonicwall line of firewalls come with an SSL VPN, which is a secure way to create an encrypted connection to your office network before initiating a remote desktop connection. Sonicwalls are affordable for almost any business starting at about $800.00. We also offer Basic Sonicwall monitoring that stores logs offsite, sends reports, and sends alerts for threats.

Sonicwall’s SSL VPN feature provides easy access to work on data from any Internet enabled Windows PC by downloading a small SSL VPN client. For Physicians who need to access sensitive data from multiple locations in a hurry this product fits the bill perfectly.

If your practice is at risk, please contact us. We offer a free initial consultation and can offer a total HIPAA compliance package.

8 Responses

  1. The generalized statement that RDP is not HIPAA compliant is false. RDP has included SSL encryption (the same technology that is lauded in the document as a great benefit of a SonicWall SSL VPN) since 2000, and provides strong encryption, including certificate based encryption in newer releases. the following link from Microsoft’s MSDN outlines this in detail.
    http://blogs.msdn.com/b/rds/archive/2009/03/12/top-10-rdp-protocol-misconceptions-part-2.aspx

    • frackingawesome@me.com says:

      Yes it is true that that RDP and RDS both have the ability to use ssl encryption these encryptions are not fully implemented with out of the box installations. The ssl is based on self generated certs that give errors on connection making it trivial to perform a man in the middle attach and recover the username and password.

      2 more points, first if you state in your HIPPA plan that you are aware of the issue and deem it an acceptable business risk then that will make it complaint as well… until you get in trouble… then it may not.

      That said i love your comments and i do agree that HIPPA is very complicated and there is no single solution.

      Thanks

      Also as you will see in the link below there is a fair amount more configuration to secure authentication, and connections to ensure compete end to end security

      http://blogs.msdn.com/b/rds/archive/2008/07/21/configuring-terminal-servers-for-server-authentication-to-prevent-man-in-the-middle-attacks.aspx

  2. The generalized statement that RDP is not HIPAA compliant is false. RDP has included SSL encryption (the same technology that is lauded in the document as a great benefit of a SonicWall SSL VPN) since 2000, and provides strong encryption, including certificate based encryption in newer releases. the following link from Microsoft’s MSDN outlines this in detail.
    http://blogs.msdn.com/b/rds/archive/2009/03/12/top-10-rdp-protocol-misconceptions-part-2.aspx

    • frackingawesome@me.com says:

      Yes it is true that that RDP and RDS both have the ability to use ssl encryption these encryptions are not fully implemented with out of the box installations. The ssl is based on self generated certs that give errors on connection making it trivial to perform a man in the middle attach and recover the username and password.

      2 more points, first if you state in your HIPPA plan that you are aware of the issue and deem it an acceptable business risk then that will make it complaint as well… until you get in trouble… then it may not.

      That said i love your comments and i do agree that HIPPA is very complicated and there is no single solution.

      Thanks

      Also as you will see in the link below there is a fair amount more configuration to secure authentication, and connections to ensure compete end to end security

      http://blogs.msdn.com/b/rds/archive/2008/07/21/configuring-terminal-servers-for-server-authentication-to-prevent-man-in-the-middle-attacks.aspx

  3. Windowsnerd says:

    A few notes to add-

    Teamviewer is not capable of being HIPAA compliant. The HITECH omnibus requires a business associate agreement with 3rd parties including remote desktop software providers. They do NOT fall under the conduit exemption, this was addressed in the notes of the omnibus. Encryption is NOT a required checkbox, it is under ‘recommended.’ Like OP says, you can make a business case, document it and move along. Ridiculous I agree but nonetheless the law is the law.

    Microsoft remote desktop meets HIPAA/HITECH Omnibus out of the box and just fine if your framework says it does. This applies to systems you run, not systems provided by a 3rd party to you like logmein, teamviewer. They still have to provide you with a BAA to get started(which they will not as of today.) Me, Chris and everyone else are required by law to have a signed BAA with anyone we does business with in the healthcare field. Even if we don’t have a BAA, we are required to comply with HITECH if we know there is PHI. The BAA gives us a chance to insert indemnity and arbitration clauses, so much better to do the BAA and get a little protection from lawsuits.

    RDP is encrypted and authenticated by default, if you are in a domain you aren’t going to have a man in the middle attack on the kerb default. If you have done mitigation work for things like poodle, you probably already took care of this stuff. Chris is right about a standalone environment with self-signed ssl if you had that on, I don’t come across it often – http://blogs.msdn.com/b/rds/archive/2009/03/12/top-10-rdp-protocol-misconceptions-part-2.aspx If you are in a HIPAA environment, your framework should probably have some standards for encryption that already solved this for you. What framework? Choose one, NIST, HITRUST, Dell Secureworks, whatever.

    There are oodles of easy mitigation options for those of us who realize encryption should be ‘required,’ and want additional layers of security. Run direct access, another vpn layer, add ipsec encryption with kerb authentication on your rdp port etc, do machine, user and domain certs as part of your auth process per port per machine. Every entity must choose their own framework to cover their own environment. The big problem with these regulations is that they just aren’t specific enough. They don’t say "you must follow all of NIST sp 800-53 and its referenced documents." That would make things a little more clear. Instead we have weak language in the omnibus that can be broken down to ‘yeah you probably should encrypt things but we won’t make you.’

    Or just use a 3rd party who knows what is up – Bomgar and Citrix. Liability shift is a wonderful thing.

    As for using VNC, I don’t recommend it. VNC is fine if it is kept up to date but there are way too many security products who hate vnc. It causes more trouble than it is worth in terms of lost hours troubleshooting.

    I try to get more information out as I can. Too many people armchair quarterbacking like on spiceworks and soaking up the google results with misinformation. Keep up the good work here!

    If any of yall have a list of software you have gotten a BAA from or been denied I’ve been meaning to keep track here:
    http://windowsnerd.com/hitech-baa-scramble-of-2013-google-the-first-to-say-no/

    Let us know in the comments and I’ll add to the list.

    One edit for ya, HIPAA not HIPPA. Although I’ve found adding a HIPPA tag goes a long way in helping search results.

    • frackingawesome@me.com says:

      I want to thank you for for taking the time and energy to post this response. i have found it very informative with a few points. i think i made an assumption about teamviewer a while back where it was compliant. At this point i am not 100% it is not but i am also not 100% sure that it is so that puts it in the 100% do not use category.

      As for RDS I am referring to remote access where even with a domain i still disagree that we are compliant and not open to liability with the out of the box configuration for remote access. mainly because of the encryption. here are my reasons.

      1) it is easy and fully supported.
      2) it is very inexpensive to implement
      3) disallowing older clients to access it is an option you have at install.

      I do agree that you can make a business justification that you do not need it, however with the simplicity and relative inexpensive to enable encryption and SSL and a number of other security technologies i think you would have a hard time in court justifying it.

      Everything else i totally agree with. Liability shift truly is a wonderful thing.

  4. frackingawesome@me.com says:

    I want to thank you for for taking the time and energy to post this response. i have found it very informative with a few points. i think i made an assumption about teamviewer a while back where it was compliant. At this point i am not 100% it is not but i am also not 100% sure that it is so that puts it in the 100% do not use category.

    As for RDS I am referring to remote access where even with a domain i still disagree that we are compliant and not open to liability with the out of the box configuration for remote access. mainly because of the encryption. here are my reasons.

    1) it is easy and fully supported.
    2) it is very inexpensive to implement
    3) disallowing older clients to access it is an option you have at install.

    I do agree that you can make a business justification that you do not need it, however with the simplicity and relative inexpensive to enable encryption and SSL and a number of other security technologies i think you would have a hard time in court justifying it.

    Everything else i totally agree with. Liability shift truly is a wonderful thing.

  5. Steve Dosan says:

    On research I have found that R-HUB remote support servers are HIPAA Compliant. Have a look at http://www.rhubcom.com/v5/remote-Support.html

Leave a Reply

Your email address will not be published. Required fields are marked *