Do WES7 Thin Clients need Antivirus Software to be HIPAA Compliant?

While developing a custom image for a new HP T620 thin client with Windows Embedded Standard 7, I came across the obvious security question: Do WES7 Thin Clients need Antivirus Software to be HIPAA Compliant?  Not being sure whether it is an industry standard to include antivirus software for thin clients, I posted the question in a number of IT forums.  There was conflicting response from our online community of experts, both with good reasoning behind their assertions.

Why would you not include antivirus software on a thin client?  For a number of reasons actually.  Adding antivirus clients to all thin clients is more costly.  It can also be viewed as overkill since the client is just a sort of viewer or dumb terminal that connects the user to his/her published desktop or applications.  Assuming that the connections are encrypted and there is no data stored locally, why go to greater, more costly lengths in protecting the thin client?  As a matter of fact, a selling point for several thin client vendors is that thin clients help eliminate cost because they do not require antivirus software installed locally.

Being that the server hosting the services is already protected by antivirus software, having it on both machines might appear to be overly cautious.  Furthermore, the thin client's embedded OS is a stripped down version that has lesser functionality and services running, so the risk of infection is less.  Locking down the client even more by modifying local policies, accounts and applications also minimizes risk.

So where do I stand on whether Thin Clients need Antivirus Software?  I have to agree that antivirus software on thin clients is best practice in my opinion.  As other IT professionals stated, the fact that the machine is running services and is connected to the LAN puts it at risk of infection even though the risk is small.  If malware is already present in the LAN or is brought in through the use of USBs, then the risk of infection for thin clients is greater than if they had antivirus software installed.

Do WES7 Thin Clients need Antivirus Software to be HIPAA Compliant?  The short answer is no. I don't consider that thin clients need antivirus software to be HIPAA compliant because it is not specifically required that all machines connected to the LAN have antivirus software installed.

The following was quoted from an online source and states:

Standard 164.308(a)(5)(ii)(B): PROTECTION FROM MALICIOUS SOFTWARE: (The Covered Entity must implement) "Procedures for guarding against, detecting, and reporting malicious software." - See more at: http://www.physicianspractice.com/blog/hipaa-compliant-antivirus-protected-computers-can-still-get-i...

The rule doesn't make it very clear and is at the organization's discretion just how to address this.  For example, one could "address" this by implementing firewalls and/or security appliances that have antivirus built in such as Cisco Meraki MX80 (which we are using) that protects the LAN. Additionally, the thin client itself, does not store ePHI locally.  Thus, one might argue that the servers hosting the published desktops have antivirus software to address this section of HIPAA.

On the other hand, I can tell you that on one occasion I had to run on-demand virus removal tools on a thin client because it was infected with malware.  I was alerted to it by the Meraki appliance.  My guess is that a PC user downloaded the malware and it spread to the thin client that was sitting unprotected on the same LAN.

Thus, while having antivirus software on thin clients is not necessary to be HIPAA compliant, I consider it a best practice because depending on the type of infection, it could spread to other machines in the LAN, perhaps even shared files and folders hosted on servers.

Fix Unidentified Network Local Only in Vista when Tethering Phone Connection

This is an update to my previous post Fix Unidentified Network Local Only.  As mentioned previously, an HP Pavilion Entertainment PC/Notebook could connect to a wireless network but could not access the internet.  The connection details stated Unidentified Network Access: Local Only.

Microsoft Fix It automatically fixed the problem the first time around.  However, after installing updates to the laptop, the thing was broken again.  The second time I attempted to uninstall the wireless network card and drivers.  After re-installing, connectivity was restored.

In my particular case, however, the user will be connecting to their mobile hotspot; that is, they will be sharing their phone's internet with the laptop.  When I tried connecting the the phone's wireless connection the same issue happened all over again.  Apparently, the first two attempts fixed the problem on a home wireless network but not when sharing your phone's internet connection. Searching online and an hour later, I came across the answer on this forum:

Atheros AR5007EG & AR5007 We have recently been seeing a lot of problems with the above adapters over the last few months, mainly concerning WPA and WPA2 encryption and windows Vista. 
The adapter gets an IP configuration, and shows as connected, but communication is non-existent or sporadic.

Atheros AR5007 is the wireless network adapter on the HP Pavilion laptop I was working on.

The updated drivers are located here.

So, after downloading and updating the drivers for Atheros AR5007 wireless NIC internet connectivity has been restored for good :)

Fix Unidentified Network Access: Local Only Internet Issue in Windows Vista

Fixing the local only internet access issue in Windows Vista | The Bit Guru:

'via Blog this'


Sharing from a very helpful article that allowed me to fix an issue in Windows Vista in which when connecting to a WiFi network, the wireless connection is labeled as Unidentified and Access: is Local Only, causing users to not be able to connect to the internet.  Issue is due to a bug in Windows Vista and thought to share it.  I browsed the web in search of a fix and this did the trick.

The cause (From Microsoft):

By default, the BROADCAST flag in DHCP discovery packets is enabled in Windows Vista (DhcpConnEnableBcastFlagToggle = 1). Therefore, Windows Vista gets an IP address by using the BROADCAST flag in DHCP discovery packets. If a router or DHCP server can’t process the DHCP discovery packets, Windows Vista will fail to get an IP address. The fix disables the BROADCAST flag by setting DhcpConnEnableBcastFlagToggle to 0.
By default, this problem does not exist in Windows XP Service Pack 2, Windows XP Service Pack 3 or Windows 7 because the BROADCAST flag is disabled (DhcpConnEnableBcastFlagToggle = 0.

As suggested by Farhan Ahmad, I first tried the automatic fix by Microsoft; this fixed the issue initially.  However, a couple of days later Windows Update installed new updates on the computer and the issue happened again.  System Restore did not fix it. Neither did running the Fix IT application from Microsoft again.  Again I did as the original post suggested and tried uninstalling the wireless card drivers, restarting the computer and then reinstalling the wireless card drivers.  This worked for me.  Much thanks.

The IT Department is Useless: 10 Reasons Why that is Not True

What has your IT Department done for you lately? The IT Department is useless, or perhaps it's just misunderstood. In many industries, Healthcare especially, the IT Department is useless.

At least that is the way it is perceived. The IT department is often times viewed as an obscure group of high paid nerds that sit around surfing the web for most part of the day. IT department staff are sometimes thought of as know-it-all that look down on the less computer savvy, hard-working staff. 

The IT Department is useless because they are never around when you really need them and bug staff with an endless list of protocols to follow. They are also the snitches, the all-seeing eye, making sure you cannot get around to post on your Facebook or respond to personal email. Heck, they are probably watching you right now!  This, of course, is a misconception and while there are some bad apples, the assumption that the IT department is useless is wrong. The IT Department, if anything, is misunderstood.

• The IT Department is not useless because it is responsible for keeping your computers running. While your own computer may be down for some time, usually, you will have access to some other workstation temporarily.
• The IT Department is not useless because it is responsible of keeping you connected to applications and services and to the web. While there may be some issues, for the most part, an organization cannot function without these vital business tools.
• The IT Department is not useless but often times understaffed. If your workstation has been down for days, chances are that it is not the only one; but, there may be only one computer technician per 100 computers...probably more.
• The IT Department is not useless because IT staff usually serve dual or triple roles in the organization. That is, the computer technician may also be doing some networking and helping out with administrative tasks such as developing IP lists, Software and Hardware Inventory Lists aside from their core responsibilities.
• The IT Department is not useless. IT staff is very unlikely to be monitoring your internet usage specifically and certainly are not out to get you.  Unless of course, your web activity is causing problems on the network or poses a security risk.
• The IT Department is not useless because keeping the network safe and stable is of the highest priority. As such, they will look at whatever is causing problems in the network or the workstations that have been recently infected with viruses, malware, etc. If that happens to be because a certain staff member is listening to Pandora or downloading wallpapers then company policy dictates the incident to be reported, thus, making IT staff look like the company snitch. The truth is, our job depends on how well we can do our functions and we are often put in situations in which we either do the right thing and report a vulnerability or turn a blind eye to keep others from getting in trouble.
• The IT Department is not useless. IT Department staff are often seen sitting around but that is just the nature of the job they perform. It involves a lot of thinking; that is always better done sitting down, sipping a cup of coffee and staring blankly at a computer screen. Rest assured, the guy is not under hypnosis, but is working on resolving your co-worker's computer problem.
• The IT Department is not useless. The To-Do list for IT Department staff is endless. There are always assessments to be made, holes to be patched, computers to be replaced, software and hardware to be installed, lists to be made, documentation, reporting, maintenance, etc. They won't be able to get them all at once so setting up priorities will enable the business to carry on as usual. Ask yourself this question: What is most important to the boss and to the organization as a whole? Sadly, fixing the printer closest to you is probably going to land somewhere down the bottom of the list depending on what else is at stake.
• The IT Department is not useless and is not all-knowing. Technologies are constantly evolving. Old ones are scrapped and new ones are under development. As such, IT department staff has to perform a great deal of research to stay on top of things.
• The IT Department is not useless and Information Technology, in some way, is like the healthcare industry. A nurse will not operate on a patient because she is not trained or qualified to do so. A general surgeon will know little about brain trauma and the podiatrist will not know how to do bypass surgery. Likewise, there are many different branches of Information Technology yet the computer technician working on a printer is sometimes expected to do something about EHR's poor performance or the fact that printers are not working in a Citrix Published Desktop.

Those of us who work in IT usually love what we do. A lot of us like helping people out or at the very least, we like the challenge of solving a problem. We are on your side. What's the IT Department like in your organization?

Why I Don't Do Hosted Fax Service - Healthcare IT

Hosted fax service is a shady line when it comes to security and HIPAA. Undoubtedly there are great benefits to a hosted fax service such as:

• The ability to share the same account amongst many users makes the service low cost.

• The benefit of sending faxes via the email client means fewer hassles for users.

• A hosted fax service will usually offer Print-to-Fax functionality allowing you to fax out anything you can print.

• You get no busy signals when receiving faxes.

• The use of a fax queue that holds fax jobs until the resources are available to be sent is seamless to the user and allows for faxes to be sent out one after the other without having to wait.

• Automatic fax transmission notifications are sent out by default.

• A hosted fax service is more cost effective than traditional faxing because it saves on equipment, equipment maintenance, ink, paper and traditional analog lines.

• Faxes can usually be resent from the web portal.

• Hosted fax service usually provides limited fax storage.

• The signup process and account management is simple.

• With hosted fax service, you have access from anywhere using an internet connection via the web portal.

As beneficial as hosted fax service is, when it comes to Healthcare Information Technology, we must look at it from a regulatory perspective as Community Health Centers and other healthcare institutions are subject to HIPAA laws and other regulations. Thus, I do not do hosted fax service for the following reasons:

1. In order to be HIPAA compliant, users cannot share the same account for the service as the sharing of passwords is explicitly prohibited for systems containing ePHI. Thus, the number of hosted fax service providers is limited since many do not have safeguards in place to provide logins and a separate workspace for individual users.
2. Sending faxes through the use of email clients, in my opinion, is a vulnerability because email accounts are often setup for use on portable devices that are at greater risk of being lost or stolen. Thus, ePHI stored in the Sent Items is visible to whoever has the device.
3. ePHI can be accessed on a desktop by going to the Sent Items on the email client, and with some hosted fax service providers, it can also be accessed via the Print-to-Fax cache on the workstation.
4. Email clients don't usually ask for a password by default. This circumvents the technical safeguards put in place with the implementation of an EHR.
5. Also, depending on whether you have an in-house email server or hosted, the setup for secured transmissions is more involved and should include SSL.
6. If an email account is ever black listed for spam, that may disrupt the faxing service as well.
7. If the email server goes down, you are unable to fax out unless the hosted fax service provides an alternate method for fax transmissions.
8. The faxes are stored off-site with the hosted fax service provider; the liability of a breach still rests with the covered entity. At the very least, a Business Associate Agreement (BAA) is needed.
9. The ability to access the hosted fax service from anywhere constitutes another risk as users will have access to ePHI even after business hours and from off site with no oversight.
10. The ability to access the web portal from outside the network increases the risk for man-in-the-middle attacks and network sniffers.
11. Most hosted fax service providers do not support a Citrix environment with the exception of a few such as RightFax and GoldFax.  Perhaps the good people at +RightFax Pros can offer a solution.

While hosted fax service may be perfect for most organizations, Community Health Centers and other healthcare institutions should look for an in-house electronic fax solution to be in compliance with HIPAA regulations. I wonder if +HIPAA For MSPs  would like to comment on this post.

How To Install HP t610 Thin Client in 30 Minutes

Do you want to know how to set up a thin client in 30 minutes flat? Learning how to set up a thin client is almost a pre-requisite in many of today's current network environments as more and more organizations move towards virtualization. There are various ways on how to set up a thin client. The following allows me to set up a thin client in 30 minutes.

 First and foremost, there must be a documented process to follow. If you have set up 100+ thin clients before, then the process on how to set up a thin client is probably engraved in your tired brain by now. If you are like me though, you may need a little extra help in remembering the steps on how to setup a thin client. In knowing how to set up a thin client, I cannot stress enough the importance of developing a sound process and documenting it. It is for your benefit and will allow you to achieve your goals quicker, more effectively and with fewer mistakes. What's more, being able to develop a process and document it will set you above others in any field.

Our organization currently uses Wyse, HP t5740e and HP t610 thin clients; we are soon to include the HP t620 model. This post focuses on how to set up a thin client an HP t5740e and HP t610 thin client.  Both have Windows XP Embedded OS. As such, they act very much like mini copies of Windows XP but with much less functionality and features. How to set up a thin client in 30 minutes can be broken down as follows:

1. Un-boxing, connecting and powering up equipment. 8 minutes.
2. Flashing the thin client with a custom thin client image. 12 minutes.
3. Configuring thin client embedded OS and applications. 10 minutes.

The process outlined above on how to set up a thin client has been simplified and is achievable by taking special care of the following:

1. Workspace - the physical location where the thin client will sit must be prepped and ready beforehand. When someone calls in a request for a new thin client in our organization the first thing that I think of is to notify the leader of that department to make sure the area is clean and that there is furniture in place for the thin client to rest on. I later make a quick stop to verify that available electrical outlets and data ports are close by and live. Grommet holes, if necessary must have been made prior, usually by maintenance staff.
2. Checklist - all materials, hardware and tools must be allocated and on-hand for the installation to go smoothly. I have a checklist of the items I need which include the following:
   1. thin client
   2. monitor
   3. power surge protector
   4. tools (I use a Leatherman Wave pocket knife)
   5. cat5 cables (for thin client, VOIP phone, and rack)
   6. cable ties or velcro and/or looming
   7. USB thumb drive with the thin client image to be deployed
   8. thin client configuration procedures

3. Access - schedule yourself to be on site and make sure that you will have unrestricted access to the work area and the communications closet. It would also help to have a knowledgeable contact in the department where the thin client will be located that can answer questions you may have regarding the setup.

While everything on the previous list is important on how to set up a thin client, there are two items that are essential and without them, setting up a thin client in 30 minutes will not be possible.

• the thin client image - the thin client image is composed of the Windows Embedded OS, installed software applications and pre-configured settings. Developing a custom thin client image for your organization is very important because that will save you a great deal of time during setup. A thin client custom image will also prevent mistakes. Every organization should have a list of applications and configurations that are standard to all thin clients. Developing a thin client image is time consuming. It requires planning, and some knowledge of the embedded OS. It requires pre-configuring various OS and application components and must be tested several times before it can be used for companywide deployments. It is well worth the effort as it allows you to deploy thin clients left and right at a whim. There are various ways on how to deploy a thin client image. I currently use two methods.
  • Vendor deployed image - all of our thin clients purchased come with the thin client image already deployed from the vendor. It is a custom thin client image that I have created, tweaked and tested a million times before providing it to the vendor. The vendor charges us a fee for having the image deployed on all thin clients we order. This allows me to be able to set up a thin client in 20 minutes rather than 30 minutes as I no longer have to flash the thin client during setup.
  • USB thumb drive - the software to create a thin client image using a USB thumb drive is available on HP t5740e and HP t610 thin clients in the control panel. Once you have installed all standard software and made necessary changes to the OS you can capture the thin state of the thin client and have it saved to USB.
• thin client configuration procedures - tailored specifically for your virtual and network environment, thin client configuration procedures will save you a great deal of time in setting up a new thin client. Thin client configuration procedures are a corner stone on how to set up a thin client. These procedures are intended to guide staff, making sure that no mistakes are made in the configuration process and nothing is open to interpretation or assumptions. All is documented and must be adhered to. The result is a working thin client that is up to company specs each and every time. Thin client configuration procedures should be based on the thin client image being deployed. Every organization deploying thin clients should create thin client configuration procedures for technical staff to follow. Procedures should include step-by-step instructions on how to configure all pertinent settings.

  *Special Note on how to set up a thin client: The process of configuring a thin client is two tier. As much as is possible and reasonable should be pre-configured with the Windows Embedded OS image. This will reduce the number of changes needed to be made individually on each thin client.

The following is the Table of Contents from the thin client configuration procedures I have created for our organization to give you an idea of what should be included. It is best to outline it in chronological order and to be as thorough as possible. Include screenshots with your instructions to make it more understandable.

How to Set Up a Thin Client - Thin Client Configuration Procedures *Applies to thin clients using custom flash version: 5.1.989

Contents

Section I: LOG IN TO LOCAL ADMINISTRATOR ACCOUNT
Section II: CHANGE TIME/DATE
Section III: CONFIGURE DNS SETTINGS
Section IV: CHANGE SCREEN RESOLUTION
Section V: CHANGE COMPUTER NAME
Section VI: ADD THIN CLIENT TO DOMAIN
Section VII: LOG ON TO DOMAIN as ADMINISTRATOR
Section VIII: CONFIGURE TEAMVIEWER
Section IX: DISABLE INTERNET EXPLORER FOR DOMAIN USERS
Section X: DELETE ClientName REGISTRY KEY
Section XI: CHANGE XENAPP APPLICATION IN PROGRAM NEIGHBORHOOD
Section XII: INSTALLING A PANASONIC KV-S1025C SCANNER
Section XIII: CONFIGURE DOMAIN USER ACCOUNT AUTO-LOGIN
Section XIV: ENABLE WRITE FILTER

In closing, on how to set up a thin client, plan ahead, develop a thin client image specific to your organization to use with all new installations and develop step-by-step procedures to guide you through the configurations. How do you set up a thin client in your organization?

HIPAA Security Rule Section 164.312 Encryption and Decryption

This post is about HIPAA Security Rule Section 164.312 Encryption and Decryption. Encryption is a process used to make data incomprehensible to unauthorized users and readable to authorized users by encoding. In healthcare information technology, encryption is a very important tool in protecting patient data and is addressed in HIPAA Security Rule Section 164.312 Encryption and Decryption under Technical Safeguards.

Understanding HIPAA regulations dealing with the protection of electronic Protected Health Information (ePHI) can be daunting, yet extremely important. If you work in Healthcare IT you may already be familiar with 45 CFR § 164.312 Technical Safeguards (a)(2)(iv) Encryption and Decryption. This is the section dealing with the encryption of ePHI data and or devices that store, transmit, or work with ePHI (i.e. disk drives, USBs, directories, etc.) The rule reads as follows:

"(iv) Encryption and decryption (Addressable). Implement a mechanism to encrypt and decrypt electronic protected health information."

Well, that seems very to the point. But just what does Addressable mean as pertains to HIPAA Security Rule Section 164.312 ? Are covered entities required to encrypt or not? It took a bit of research and half a cup of coffee but here is the answer coming from a reliable source.

"Is the use of encryption mandatory in the Security Rule? Answer:No. The final Security Rule made the use of encryption an addressable implementation specification. See 45 CFR § 164.312(a)(2)(iv) and (e)(2)(ii). The encryption implementation specification is addressable, and must therefore be implemented if, after a risk assessment, the entity has determined that the specification is a reasonable and appropriate safeguard in its risk management of the confidentiality, integrity and availability of e-PHI. If the entity decides that the addressable implementation specification is not reasonable and appropriate, it must document that determination and implement an equivalent alternative measure, presuming that the alternative is reasonable and appropriate. If the standard can otherwise be met, the covered entity may choose to not implement the implementation specification or any equivalent alternative measure and document the rationale for this decision."

via Is the use of encryption mandatory in the Security Rule?. Thus, in order to comply with HIPAA Security Rule Section 164.312 encryption requirements, a covered entity must conduct a Security Risk Assessment first to determine if encryption is warranted for their organization and to what extent. If they find it inappropriate or unreasonable, the reasoning behind that determination should be documented.