• Communications to the Organization’s Servers.  The communications to and from the systems of organizations that utilize certain versions of OpenSSL may be at risk of interception.

• Communications by an Organization’s Employees to Third Party Organizations Affected by Heartbleed.  The authentication credentials of personnel and information sent by an organization’s employees to business-related websites subject to Heartbleed (e.g. Dropbox) may be at risk.  If an employee logged into such a site his or her password could have been compromised, and hackers could also have obtained access to information sent by the employees over encrypted SSL channels and information on the business site itself.

• Communications by Employees to Organizations Affected by Heartbleed During their Personal Use of the Internet.  An employee visiting a website affected by Heartbleed (e.g. Google and thousands of other common consumer sites) during their personal Internet use (at the home, office or offsite) could have had his or her username and password compromised.  If that employee uses the same username and password to log into his employer’s systems, those systems could also be at risk.

In addition to the serious security concerns implicated by Heartbleed, there may be legal consequences associated with this vulnerability, especially with respect to the potential unauthorized access or acquisition of personal information.  At this juncture it is imperative that affected organizations remediate the Heartbleed vulnerability, communicate with their customers, employees and other system users, and consider potential legal risks and obligations associated with Heartbleed.

In this blogpost we present some key FAQs concerning the security and resulting legal implications of Heartbleed.  Specifically, we address remediation efforts necessary to reduce security and legal risk associated with Heartbleed, password reset and communications to affected individuals, the applicability of breach notification laws, and potential investigation obligations under HIPAA’s Security Rule.

What type of information may have been exposed?  Does this breach expose “personal information” under breach notification laws?

The Heartbleed vulnerability does not target a specific file or type of information. Instead, the information exposed is whatever was in the computer’s active memory (not hard drive storage space) at the time of the attack. For every request made by the attacker, the Heartbleed-vulnerable computer will respond with the contents of up to 64KB of memory. Because of this limitation the primary targets of an attacker exploiting Heartbleed are not files or documents. Instead, the real targets of this attack are usernames, passwords, and encryption keys because they are regularly stored in active memory, small enough to fit within 64KB of data, and can be leveraged to access even more information.

Under California’s breach notice law, “personal information” is defined to include the following:

 A user name or email address, in combination with a password or security question and answer that would permit access to an online account.

As such, the exploitation of Heartbleed that captures this information could trigger breach notification in California. Moreover, if authentication credentials compromised as a result of Heartbleed are further leveraged, highly sensitive information on an organization’s systems or affected third party systems may be at risk, including trade secrets, intellectual property and personal information (essentially anything accessible using the authentication credentials at issue).  Therefore, if Heartbleed is exploited, organizations that regularly transmit or receive personal information may be at risk, and may have to notify affected individuals.

Is an attack using the Heartbleed vulnerability detectable?

Now that security professionals know what to look for, it is possible to detect and prevent an attack that uses the Heartbleed vulnerability. However, it is substantially more difficult to determine if an attack occurred in the past (and the vulnerability has been around for 2 years).

A Heartbleed attack leaves no trace on the target computer and signs of an attack are normally not logged. It is possible to detect if you previously captured all incoming SSL traffic or maintained very detailed server logs on TLS/SSL “handshakes.” However, most sites do not record their SSL traffic because the volume of information can be prohibitively expensive to maintain. Even those sites that record their SSL traffic or maintain detailed server logs, only do so for a short period of time due to the amount of data generated.  As a result, most organizations will be able to confirm the presence of the Heartbleed vulnerability, but unable to determine if it was actually used.

What should be done in response to the Heartbleed vulnerability?

At this point, Heartbleed is a commonly known vulnerability (whether that was true or not prior to its recent discovery is unclear).  Hackers, fraudsters and other nefarious forces, if they were not already doing it, are likely to launch attacks.  The longer an organization goes without remediating the vulnerability the greater the likelihood of a security breach and resulting legal liability and risk.  Organizations should move swiftly to address Heartbleed and reduce their risk, and should consider the following actions:  

• Identify Vulnerable Systems (if any). The first step is to assess whether you have any vulnerable systems. Typical desktop or laptop computers are not affected by this exploit. The Heartbleed vulnerability is present on computers running OpenSSL version numbers 1.0.1 through 1.0.1f and 1.0.2-beta1. It also affects certain network hardware such as routers, switches, and firewalls. Be sure to check with the manufacturer to see if you have any vulnerable networking equipment or check the list maintained by Mashable by clicking here.  Notably, many organizations (about one-third of Internet sites) do not use Open SSL.  While they may not need to take action to directly address the vulnerability, they may still be at risk (as described further below).

• Test Servers for the Heartbleed Vulnerability (time and resource permitting).  Next, the most common response is to immediately patch your servers.  However, if you have the time and resources available, you should test your servers for the vulnerability in the pre-patched state. Not every implementation of OpenSSL is susceptible and the ability to confirm if your systems were vulnerable in the first place will be extremely valuable.

• Patch Affected Servers.  Upgrade to the latest version of OpenSSL and install the latest patch or firmware on all affected computers and hardware.   OpenSSL has made the patch available here (the upgrade with the patch is OpenSSL 1.0.1g.).   After you have patched or upgraded the affected equipment, be sure to restart and re-test the equipment to ensure the vulnerability is closed.

• Revoke and Regenerate Existing SSL Certificates and Encryption Keys. Do not regenerate these certificates until after you have upgraded to the latest version of OpenSSL or you will jeopardize the security of the new certificate all over again.

• Password Reset.  Finally, you will need to decide whether to notify individuals to reset their passwords (e.g. employees and customers) or reset their passwords yourself. Here, the results of your pre-patch testing will come into play and should help you make an informed decision. The key is to take a close look at the computers that were affected and the potential information that was exposed. A corporate mail server will store substantially different information that an online marketplace. The type of information accessible by the affected computer should help guide your decision. Even if your systems were not affected, your customers and employees may expect a response given the wide-spread publicity surrounding this exploit.

Our systems were not affected by the Heartbleed vulnerability.  Do I need to do anything?

Unfortunately, because of the widespread nature of this vulnerability, even organizations unaffected by this exploit should consider taking steps to address potential security risk arising out of Heartbleed.

If any organization’s employees has dealings with a third party organization with the Heartbleed vulnerability, the employee’s credentials used to log into the third party’s systems may have been compromised.  If that third party service stores sensitive information or personal information related to the organization it could be at risk.  Moreover, if the organization’s employee uses the same password on the third party site to log into the organization’s system, the organization’s system and information could be at risk.

Even personal Internet use (at home, at work or otherwise) could expose an organization’s systems and information.  Again, if an employee uses the same log in credentials for his or her personal Internet use,  then the capture of those credentials could allow access to the organization’s systems and information.

Even if the organization was not directly vulnerable to Heartbleed, it should consider requiring its employees to reset their authorization credentials.  In addition, organizations should direct their employees to not use the same password at work that they do for their personal sites and use (regardless of Heartbleed, this is a good idea anyway).

When should I tell my employees, customers and others to change their passwords?

Individuals should not change their passwords until after the relevant Heartbleed-affected site has been patched.  If an individual changes his or her password before the Open SSL patch is operational then the new password will be at risk of compromise.  Since so many websites and servers have been impacted by Heartbleed, this timing issue poses challenges.  For affected third party sites, one must attempt to ascertain whether the site has implemented the patch.  Some organizations are attempting to track the date when some higher profile websites have implemented the OpenSSL patch.

What should I tell my employees, customers and others about resetting their passwords?

To cover all the scenarios outlined above, you should consider communicating the following to your employees, customers and other affected individuals:

• Reset Password to Organization’s Systems.  After the organization has implemented the OpenSSL patch it should tell its affected employees and customers to change their passwords (or force a password reset of such systems).

• Reset Passwords to Third Party Affected Systems used by the Organization.  To the extent employees accessed Heartbleed-affected third party sites used by the organization, you should ask your employees to change their passwords to those systems.  You may also have to inform your employees concerning the timing issues discussed above – they should be told to change passwords only after the affected third party site has implemented the OpenSSL patch.

• Employees that Use the Same Password for Work and Personal Use Should Change their Passwords.  Even if the organization’s own system was not affected by Heartbleed, and even if the organization does not utilize third party sites affected by Heartbleed, companies should consider asking employees and customers to change their organizational password if they use the same password for personal reasons.

Does the Heartbleed vulnerability trigger U.S. breach notification laws?

Breach notification laws define "security breach" in different ways.  For example, under California’s breach notice law, a “breach of the security of the system" is defined as:

unauthorized acquisition of computerized data that compromises the security, confidentiality, or integrity of personal information maintained by the person or business.

Other states also define a security breach in terms of “unauthorized access” (as opposed to acquisition), including Connecticut’s law which defines “breach of security” as:

unauthorized access to or unauthorized acquisition of electronic files, media, databases or computerized data containing personal information when access to the personal information has not been secured by encryption or by any other method or technology that renders the personal information unreadable or unusable.

Finally, under HIPAA HITECH, “breach” is defined as:

the acquisition, access, use, or disclosure of protected health information in a manner not permitted under subpart E of this part [the HIPAA Privacy Rule] which compromises the security or privacy of the protected health information.