Last time I wrote about The Need to Protect Healthcare Data, or perhaps more importantly the potential cost of not protecting it. This time I want to talk about how to do that in a non-disruptive way that will probably save your organization money while significantly reducing the chances of a major data breach involving hundreds or thousands of patient records. Of course the same approach can be used to protect any kind of protected information from exiting en masse in any line of business.
The key is to protect the “crown jewels” – the database that contains the data that must be protected. Normally, these systems are implemented as three-tier environments. To keep the picture and words simple, in this discussion each tier has only one server but in a real implementation each tier is usually composed of multiple servers for redundancy or to provide the necessary performance.
- The data tier contains the database server that actually contains the database. This server contains the software that manages all access to the data: no one can access the data without eventually getting to the database server.
- The application tier that controls the business logic that uses the database. These are the programs that implement information retrieval and update for the medical staff, capture information from medical device controllers, and handle data retrieval for meaningful use and billing.
- The presentation tier is what interfaces with the user or another application system. It is often implemented as web services so that any device with a web browser can access the same information.
For example, when a doctor needs to see a patients chart from her tablet, she can use a browser or a special tablet application to ask for the current chart for “John Smith DOB 04/23/1945.” The tablet browser or application sends that request to the presentation tier, where the doctor is authenticated if necessary, then sends that request to the application tier. There a program formats a query against the database and sends it to the data tier. The data tier retrieves the information and sends it back to the application tier, who formats the specific information for the chart and sends that to the presentation tier. The presentation tier then sends it to the tablet browser or application for display to the doctor.
While this may seem like a complicated process, it nicely separates the operation so that, for example, a different kind of user device with completely different display characteristics can be easily added by changing only the presentation tier, and usually just making a single change that will work independent of the specific kind of transaction. Similarly, it allows the application layer to perform additional validation on a specific transaction, such as verifying that the doctor is permitted by HIPAA to see John Smith’s information.
The purpose of this requirement is to limit access to the application and data tiers to only those specific devices that have a valid need to access those tiers. In particular, only the servers in the application tier should be allowed to access the servers in the data tier, and only the servers in the presentation and data tiers should be allowed to access the servers in the application tier. There are, of course, users called administrators that require access directly to the application and data tier servers. These are the people who are responsible for the management and operation of the applications and database. In most organizations, there are just a few database administrators and application administrators who must have direct access into those servers.
This solution described there uses the Unisys Stealth Solution. Stealth uses state-of-the-art encryption, but the key principle behind Stealth is that it only allows a device to communicate with another device if they share a Community of Interest, a COI. A COI is nothing more than a group of people and servers. Data can be shared freely within a COI, but must not be shared with any person or server not in the COI. In the usual Stealth installation, a user’s COI or set of COIs is specified in the site’s identity management system, the system that is used to authenticate a user when the user signs on. If some device tries to access a Stealth-protected server or workstation without belonging to the same COI, then the Stealth-protected device is completely invisible; the Stealth-protected device simply will not respond to anything from that device.
The picture represents each tier by a single server and shows one database and application administrator. As stated before, there are usually multiple of each. The red lines show the communications paths protected by Stealth. The black line represents clear-text traffic coming from the organizations internal network or over the Internet. The Internet traffic should already be protected by some form of encryption such as IPsec or SSL. There are three Communities of Interest (COIs) in the diagram. The green dots represent devices in the DB COI, the blue dots represent devices in the Application COI, and the yellow dots represent devices in the DB Administrator COI. Only the database Administrator and the application tier server can access the data tier server. Only the data tier server, application administrator, and presentation tier server can access the application tier server. Any other device attempting to access the data or application tier servers would be completely ignored.
Since the individual administrator’s COI is determined at log on time, it does not matter which workstation an administrator uses. When an individual signs on with a database administrator’s credentials, he now has the DB ADMIN COI and can access the data tier server.
One Stealth implementation can protect multiple databases that are in the same network segment, i.e., are visible from each other in the network. Otherwise you can replicate the Stealth implementation as needed.
This solution has no impact on existing applications and is invisible to end-users and even to the database and application administrators. Capital savings come from not requiring as much network infrastructure such as firewalls. Operational savings come from not needing to reconfigure firewalls or other network security devices and applications. If an administrator is added or moves on, simply change your identity management system. Stealth then automatically permits or prevents the individual from accessing the database or application servers.
If you do not have a tiered implementation or have collapsed the tiers onto a single server, and therefore allow end users to directly access the server containing the database then this mechanism does not help. Then again, not much would be able to help in this situation. You first need to separate your environment into multiple tiers so that any security solution can control access to the database and application servers.
The last word:
This mechanism does not protect against the accidental or deliberate loss caused by inappropriate actions of individuals who are authorized to access the data. This includes the file clerk who walks away from a logged-on workstation in a semi-public area, or the doctor who foolishly loads a couple of patient files on her son’s laptop at home. There are ways to reduce the chances of these kinds of incidents, and in super-sensitive environments it makes sense to make those investments. But they are very expensive and usually not worth the cost. While these errors are regrettable they rarely lead to fines or the risk of losing accreditation, or the CIO needing to find a new job.
As always, the key is to have a good security policy document and provide annual security training emphasizing to employees and contractors that you are serious about data security.
Keep your sense of humor.