Is the DROWN vulnerability really that bad?

Even if you're not in the information security industry, chances are you will have heard about the new TLS-related vulnerability in the SSLv2 protocol that was revealed last week, dubbed DROWN.

DROWN is estimated to be affecting one third of the world’s webservers, allowing an attacker to steal the server’s private key and subsequently decrypt encrypted browsing sessions, steal passwords, personally identifiable information, credit card details, etc.

However, the extent of the issue doesn’t stop there. DROWN will also affect any network service that uses (or has the potential to use) TLS-dependent protocols to secure communications, such as email systems, instant messaging systems and VOIP systems.  

Even if you think you have done a great job of removing all of the SSLv2 ciphers from your webserver configuration, as per your security architecture guidelines (like any company with a good approach to security architecture would have done, right?), because of another vulnerability (CVE-2015-3197), OpenSSL could still be accepting SSLv2 connections.  

On the surface of it, DROWN seems serious enough to drop everything and spend a few days reconfiguring each of your affected systems to make sure you're not at risk. However, is that really the right thing to do?

Assess the risk

Businesses, as you might expect, are now coming quickly down on their security operations teams to find and eradicate the exposure before the bad guys develop exploit code and target them.

And on the face of it, this sounds like the right approach, or at least it’s the one we’ve come to expect from our boardroom.

However, for security managers with more resolve, you might want to consider pushing back to the executive with a balanced approach that focuses on the systems that really are at risk rather than dropping tools and focusing entirely on DROWN.

Like with Heartbleed, Logjam and Poodle, the business’ knee-jerk reaction to new and highly visible vulnerabilities is often to force the reprioritising of work and insist operations teams drop everything until this issue has been fully rectified.

Such a knee jerk reaction can lead to mistakes being made and other more pressing issues being overlooked as technical teams spend all of their time focusing on mitigation of a vulnerability that’s not been assessed in the context of the business.

Threat intelligence company iSIGHT Partners labelled the DROWN attack "medium-risk" and of only "moderate" threat.

"Although a large number of systems are reportedly vulnerable, exploitation requires notable manual effort and can only be used to obtain the private key for individual users," the firm said.

"Further, since the attacker needs to be in a position to intercept traffic, we believe most victims will be targets of opportunity, not targeted. Therefore, we anticipate limited actor interest and do not expect widespread exploitation.”

So you need to look at DROWN in context of your business and assess it through the risk management framework used for everything you work on.

If you map the threat against the vulnerability - as assessed by iSIGHT Partners as medium risk - and the impact to your business, you’ll get the true risk rating in context of your business in a language and format executive management will understand.

You might just find that it comes out as a medium to low risk for the majority of internal systems, while that one external webserver is rated as medium; you can then prioritise it being fixed accordingly.

Now you can tell your executive what you are doing about DROWN without compromising the work you are doing on patching your systems properly, closing down all those open USB ports and bolstering your web gateway with new signatures and anti-ransomware strategies.

The majority of businesses won’t be victims of a DROWN-based attack, however, will your executive excuse you when you overlook an outbreak of CryptoLocker because you were DROWNing in webserver configuration files? Probably not.