Are your systems vulnerable to the next Heartbleed bug?

This post is the first in our new series on digital security and two-factor authentication.

No one likes to think that their systems and networks are vulnerable to attack. In fact, it’s sometimes easier to pretend the opposite. But given the potential consequences of an attack—bad PR, lost revenue, crippled systems, angry customers—it’s worth facing the risk head on.

Broken locks
Photo used under a CC license from Flickr user Jan Kaláb.

To start, let’s look at three areas where your systems are vulnerable.

Vulnerability: Passwords

User name and password combinations have been standard at the user level for years now, but the flaws inherent to that system are well-known and growing. Truly complex passwords are difficult for users to remember, and passwords that meet most system requirements can still be weak (e.g., Password1).

Vulnerability: Stolen Credentials

Hacking and stolen credentials continue to be an issue, as shown by the steady stream of data breaches and hacked accounts. Account holders who use the same password for most or all of their account logins add to the issue.

Vulnerability: Security Holes and Exploits

No matter how well designed your systems, it’s common to later find holes in their security. Those holes invite disaster, and can be hard to close. It’s estimated that the average vulnerability window of a zero-day exploit lasts about 10 months.

The Heartbleed Bug

In April 2014, the world was made aware of an OpenSSL vulnerability now known as the “Heartbleed Bug,” a threat that had existed prior to its discovery on any website enabled with OpenSSL SSL/TLS technology. The threat exposed a vulnerability that could allow unauthenticated attackers to discover and steal private keys, passwords, session details, and data held in memory.

Though a solution to the Heartbleed bug was introduced around the same time as the public announcement and many websites moved quickly to resolve the issue, there was quite a bit of controversy surrounding the announcement.

We learned that, ironically, the threat to online account holders was actually magnified during the period just after the public announcement. Innocent online account users were often instructed to wait until their provider implemented the fix, all while the world’s would-be Internet attackers were basically shown how to exploit the vulnerability by using those same details about how to fix the issue and lists of websites with the vulnerability.

In the next post in this series, we’ll discuss a proven method for minimizing these vulnerabilities and improving security. Want a more in-depth discussion? Read the full whitepaper.