It’s no secret that hackers have found a veritable “gold mine” in holding healthcare records for ransom. A recent JAMA Data Breach Report revealed that in a seven-year period, 2,149 breaches occurred, amounting to 176.4 million patient records disclosed. The first six months of 2019 have already shown a marked increase in the annual average, with a staggering 32 million records breached.
With so many effective, targeted attacks on healthcare, it should be no surprise to learn that the industry ranks 15th out of 18 major U.S. industries in terms of overall cyber health. What this means for websites handling protected health information (PHI), however, may be less understood. For instance, using the latest protocols and cipher suites – both designed to protect your sensitive data – has now become a baseline necessity. For those who have no idea what those terms mean, a quick overview of internet security will be helpful.
A Secure Internet?
Like an older car with no factory seat belts installed, the internet was originally launched without the security protocols now required to protect personal data. Since the intent was to share only free, public information – both government-related and for academic pursuit – the fledgling internet protocols (or set of rules used to communicate with web servers) simply weren’t designed to handle the flow of private, sensitive information.
Clearly, times have changed. Since the Hypertext Transfer Protocol or HTTP (the accepted command for formatting and transmitting internet messages, and which web servers and browsers use to retrieve a web page) was not designed to encrypt data, sensitive messages were now at risk. Commercial business transactions and electronic health records could easily be intercepted and read, since the messages weren’t encoded. Like a passenger without a seatbelt, now anyone handling confidential data was at increasing risk for harm.
Enter HTTPS (Hypertext Transfer Protocol Secure). With an encrypted layer wrapped around it (like a new seatbelt), this protective barrier – commonly known as Transport Layer Security (TLS) – now provided a “secure tunnel” for authentication and data encryption (or encoding) between two different endpoints. Safe transfer of sensitive data was enabled, as the client’s server request was confirmed by an SSL (secure sockets layer) certificate containing the server’s public, cryptographic key. This certificate allowed the website traffic to be authenticated as legitimate.
The Necessity of Encryption
Today, just as seat belts in cars are now the standard, current data protection for sensitive information relies on encryption as a baseline requirement. Fortunately, many websites have now adopted HTTPS for connections. This is denoted, for example, by a green padlock in the Google Chrome browser address bar, with newer versions of the browser flagging HTTP sites as “Not Secure”:
With HTTPS enabled, a web browser will check a website’s security certificate and verify that it was issued by a legitimate certificate authority.
While this is a positive sign, data security experts know that HTTPS alone doesn’t guarantee security. Verifying app security at the code level and hardening (or securing) your server-stack against vulnerabilities is still required. Additionally, updating software to address issues such as the pervasive “heartbleed” vulnerability – not a protocol flaw, but an implementation bug which exploits a flaw in OpenSSL encryption software (a widespread implementation of SSL/TLS) and tricks websites, servers, and even medical devices into releasing sensitive information – is also critical.
This leads us to our key point, which is that the latest TLS/SSL protocol versions and cipher suites (cryptographic protocols) should be enabled on websites with sensitive data, in order to ensure the strongest protections. It is equally important to disable older versions, including SSL 2.0 and 3.0, and TLS 1.0 and 1.1, since they are particularly vulnerable to attacks such as the POODLE, SLOTH, and DROWN vulnerabilities.
That said, the most widely accepted TLS protocol at the time of this writing is TLS 1.2., and unlike previous versions, 1.2 now offers modern authenticated encryption (also known as AEAD) – a form of encryption that ensures the confidentiality and authenticity of data. In other words, if you’re not supporting TLS 1.2 at a minimum, your security is lacking.
A Survey of Healthcare Sites
So, how are healthcare websites faring when it comes to actually replacing the weaker protocols and cipher suites? HIPAA Vault decided to survey 100 large U.S. city hospitals to see what SSL/TLS versions and cipher suites their web server were supporting – whether SSL 2.0, 3.0, TLS 1.0, 1.1, or
- versions (or a combination of these), and if they had a corresponding strong or weak cipher:
Here are the biggest takeaways from the survey:
- Only 3 out of 100 (3%) had enabled TLS 1.2 version only, with corresponding strong cipher suites
- 19% had enabled TLS 1.2 version only but had not enabled strong ciphers
- More than half, or 54%, were using TLS 1.2 version with weak ciphers, as well as supporting older SSL/TLS versions
- 7% had enabled TLS 1.2 version with strong ciphers but were also supporting older TLS versions
One encouraging sign is that 83% of the healthcare sites surveyed have at least adopted TLS 1.2 version or better. This is progress, and may in part be due to the PCI-DSS standard which required that all sites accepting credit card payments remove support for TLS 1.0 by June 2018.
The bad news – and this is significant – is that almost all sites surveyed have a weakness in their security.
The majority of healthcare sites surveyed (97%) have a weakness which leaves them vulnerable to attack – either because they continue to support older, weaker TLS versions at various locations in their system, and/or they have not enabled the strongest ciphers.
It should be noted that in order to support older clients (“backwards compatibility”), some healthcare companies continue to support TLS 1.0 and TLS 1.1 – for now. However, they must understand that they do so at great risk. Even TLS version 1.2 has become increasingly vulnerable to the new,
so-called “man-in-the-middle” or eavesdropping attacks, initiated through phishing emails or by connecting to unsecured servers where traffic may be monitored by an attacker.
Healthcare data breaches are continuing to grow in complexity. As the internet increasingly becomes a tool for the delivery of healthcare, with connected devices able to access sensitive information at the touch of a finger, organizations must aggressively support cyber-awareness and security training for staff. In essence, cybersecurity should now be viewed (and budgeted for) as a vital part of patient care.
A key part of this awareness is to realize how quickly malicious attacks continue to mutate and adapt, not unlike real viruses seeking to compromise their hosts. With this in mind, healthcare websites and servers need to be configured for the latest security protocols – TLS 1.2 at a minimum – with corresponding strong algorithms and cipher suites to withstand malicious attacks on sensitive data.
At the same time, organizations must identify older, legacy protocols as part of their regular risk assessments, jettisoning them as quickly as possible in order to fix the holes through which vulnerabilities may enter. Adopting the latest security protocols as a strategic part of a company-wide cybersecurity plan will not only help to minimize risk but ultimately result in a positive impact on patient care.