POODLE and the BEAST: Ensuring you’re protected with Transport Layer Security

By May 8, 2019 May 13th, 2019 Articles

Transport Layer Security (TLS), and its predecessor Secure Sockets Layer (SSL), have come under scrutiny by security researchers and advisors in the wake of numerous vulnerabilities that plague their older versions. SSL/TLS are cryptographic protocols utilized while web browsing, emailing, and using Voice Over IP (VOIP) services.

As security features, they are vital to ensuring your data remains confidential as it travels through computer networks and over the Internet.

Unfortunately, some previously unknown vulnerabilities have been exposed in the older versions of these protocols and many organizations haven’t made the appropriate upgrades to compensate.

The potential for damage is so great that a June 30, 2018 deadline was mandated by the PCI Security Standards Council (PCI SSC) for companies to abandon support for affected SSL/TLS versions to remain compliant with PSI-DSS standards.

Importantly, organizations that aren’t required to comply with PSI-DSS standards are still accepting a massive risk by continuing to support compromised versions of SSL and TLS. Be assured, attackers don’t take time to discriminate when they stumble upon a gaping vulnerability.

Even more, it is likely that other compliance standards will follow suit and implement similar requirements with respect to unsecure versions of SSL/TLS.

How could this affect your organization? How compliant are you now?

Know Your Attacker: POODLE and BEAST

POODLE and BEAST are vulnerability exploits that are being leveraged by malicious attackers to compromise organizations’ data. These attacks take advantage of the vulnerabilities inherent to SSL and early TLS.

POODLE, an acronym for “Padding Oracle on Downgraded Legacy Encryption,” allows an attacker to decrypt information from an encrypted transaction. The attack can be used against any system that is configured to support SSL 3.0, as well as some early versions of TLS.

BEAST, or “Browser Exploit Against SSL/TLS,” similarly allows attackers to conduct man-in-the-middle (MITM) attacks to obtain authentication tokens and decrypt data being transmitted between hosts.

Technically, SSL and early TLS encryption protocols have been deemed insecure since 2015. However, many organizations’ technical infrastructures are still configured to support connections using these insecure protocol versions. Does yours?

Unsurprisingly, many are scrambling to migrate and reconfigure their systems to ensure their data is secure as any vulnerability that exposes PHI constitutes a major risk to any healthcare organization or business associate.

What’s the fix?

Unfortunately, the National Institute of Standards and Technology (NIST) has determined that patches or updates are insufficient for addressing these security issues.

The only option is to upgrade to the latest versions of TLS and disable support for SSL/early TLS.

According to the PCI SSC, TLS v1.1 or higher is recommended for ensuring that network traffic is adequately encrypted. However, PCI SSC suggests adopting TLS v1.2 for the best protection against these attacks.

Organizations should take steps to revoke support for compromised versions and introduce secure iterations of TLS into their server-configurations. Disabling support for compromised versions and out-of-date cipher suites will serve to ensure that data communications channels are safe from MITM attacks — reducing the likelihood of a costly data breach incident.

Are your networks affected?

There are multiple ways to determine if your network is affected. Some third-party webpages can determine the version and ciphers you are currently using by scanning your computer over the Internet, but security should be considered before utilizing these types of services.

Depending on which part of your network you want to diagnose, you may have to open up your protected networks to connect to these services. Of course, these services are primarily for individual computers rather than robust networks, so aren’t a viable option for most organizations.

The best way to detect this issue is to use vulnerability scanning tools and methodologies.

Industry-leading tools like Nessus and Retina can peruse large and complex networks —checking each system to see if they are configured to use unsecure versions of SSL/early TLS.

In addition to SSL/TLS vulnerabilities, scanning tools can identify a broad spectrum of vulnerabilities across the network, equipping administrators with the knowledge of where their networks’ most pressing vulnerabilities lie.

How should you proceed?

Vulnerability scanning tools can be expensive and costs scale with the size of the organization and types of licenses used. We recommend that you fully vet any outside vendors that you consider for guidance and help with implementation. These tools do require expertise to use them correctly and to accurately interpret their results.

 

About the author

Ian Terry is a Security Consultant for Intraprise Health’s BluePrint Security Services.

Intraprise Health is a recognized leader in healthcare IT security, privacy and compliance. Founded in 2018, Intraprise Health includes industry leading technologists from Intraprise Solutions as well as the security services and expertise of BluePrint Health Information Technology, created in 2003.  Intraprise Health is 100% focused on healthcare and its ISMP services provide clients with a comprehensive security, privacy and compliance solution grounded in the guidance published by the OCR, the HITRUST CSF, and emerging lessons learned from the OIG, oriented to today’s healthcare business and operational requirements. Our ISMP professional services are designed to allow clients to leverage our domain expertise and proven methodologies to help develop, execute, and manage their security, privacy, compliance and risk management programs.