Posted by: adelvecchio
cybersecurity, data encryption, data in motion, data privacy and security, healthcare data
Guest post by Dr. Michael G. Mathews, president, COO, & co-founder, CynergisTek, Inc.
In previous articles, I covered the fundamentals of encryption using symmetric (shared secret), asymmetric (public-key), and mixing the two to create a hybrid approach to keeping data confidential. I also covered the concepts of data integrity (knowing a message has not been changed) and non-repudiation (verifying the sender is authentic). This installment focuses on the security of healthcare data in motion. The final segment in this series will focus on the security of healthcare data at rest.
At the risk of sounding like a broken record (as it seems all things security start with this), it is critical to understand the application data flow for the data being protected. Knowing the type of data being moved and where it originates and is destined, as well as if there are intermediate stops/routings along the way, helps inform what type of protection makes the best sense for the data. For example, an application that is moving data from point A to point B within the internal network might simply be an exercise in proper network architecture design to segment the traffic as best as possible from those who don’t need access to it. Since network segmentation as a mitigating control falls outside the realm of encryption, I’ll reserve that topic for a future article.
Any data leaving the internal network and going beyond the perimeter firewall certainly deserves a critical eye from a data confidentiality perspective to include non-traditional health IT applications such as Voice over Internet Protocol (VoIP). In the case of VoIP, depending on how calls are routed, the data portion of the call might live on the internal network or it might leave the internal network to a hosted private branch exchange. In the latter case, any conversations that include protected health information would be exposed to the Internet –potentially creating an unauthorized disclosure — without mitigating controls in place. In general, where it’s possible to enable data confidentiality, there’s rarely a reason not to do so.
One of the prominent options available for protecting the confidentiality of healthcare data is transport layer security or TLS — which, together with its predecessor secure sockets layer (SSL), are often collectively referred to as SSL. TLS takes a hybrid cryptography approach in that it uses asymmetric (public-key) cryptography to establish a secure initial communication channel in which it then negotiates a session key (symmetric) for further communications.
The benefit of using SSL/TLS is that, for discussion’s sake, it works at the application layer. This means that by the time the traffic hits the network, it’s encrypted. One detriment is that unless the application in question is written to support SSL/TLS, it’s not something that can be added after the fact, though there are workarounds that use SSL tunneling to make non-SSL/TLS-aware applications work with SSL/TLS. In recent years SSL/TLS have started to become more ubiquitous in applications, making accessibility to this route of protecting data much more favorable. Though it hasn’t been without its setbacks, with Heartbleed being the most widespread and serious.
The other widespread route is IP security or IPsec. In contrast to SSL/TLS, IPsec works at the network layer and, as such, it can be used to secure the confidentiality of any application, including those that don’t have security or privacy as integral features. Readers will most likely associate IPsec with site-to-site virtual private network (VPN) connections and even some implementations of end user VPN connectivity. IPsec depends on what are called security associations to establish the rules of the connection and the rules must match on each side of the connection to be successfully negotiated. Like SSL/TLS, IPsec also uses a hybrid approach to cryptography with initial key exchange either using a shared secret or a protocol-based key exchange to generate session keys for the communication to be protected.