Heartbleed: What to do now

by Latham & Watkins LLP
Contact

heartbleed.png[co-author: Alex Stout]

Hardly a day passes now without some new report of a security vulnerability with inevitable breaches that follow, but Monday’s news about the two-year old vulnerability in OpenSSL is (or should be) catching everyone’s attention.  The problem is a coding error in a widely used cryptographic software library for implementing secure connections between a website (or web interface on a hardware device) and its user (typically indicated by a reassuring padlock in the status line of a browser). The bug allows undetectable access to random blocks of memory on the server.  This means essentially all information being processed by the server may be exposed to an attack that exploits the vulnerability, including user names, passwords and, critically, the keys used to protect information on what are intended to be secure connections. (The official reference for the vulnerability is CVE-2014-0160, but the bug has been dubbed “Heartbleed” because it involves an update used to implement a “heartbeat” protocol used to evaluate the status of a secure connection.) 

So, what does this mean for those charged with managing data security obligations?

  • Who is really affected?  The threshold question is whether your organization uses the relevant versions of the OpenSSL code in any public facing webservers.  OpenSSL is included in a number of widely used Linux-based web server packages (including as as part of a Linux based  front end to some Windows servers).  .  The vulnerable versions of the software are Open SSL 1.0.1 through 1.0.1f.  The OpenSSL project and others have posted detailed information you can use to identify whether your servers are affected.  Make sure you check for use of the vulnerable code in any public facing hardware that incorporates an SSL protected configuration or management console in firmware.

Note: Although there has been a lot of press suggesting that “virtually every” server on the internet is affected by Heartbleed, it is only those running the vulnerable versions of OpenSSL that are at risk.  According to Netcraft, this is about 17% of the servers running on platforms that could use OpenSSL. That’s a lot of servers, but far from “all.”  So, again, the threshold question is whether you are running the vulnerable versions of OpenSSL.

  • Patch/update code.  If your organization operates vulnerable systems, you should make sure your IT team is using information available from OpenSSL or your server package vendor to patch or update the code. Because your certificate(s) for the server may have been compromised, you should consider revoking and replacing the certificates after patching the vulnerabilities. (While one at least one certificate authority—bracing for an onslaught of certificate revocation requests—has questioned the risk of certificate compromise, even they are advising to assume those credentials are subject to compromise for now.)
  • Communicate with users.   Whether you ran a vulnerable version of OpenSSL or not, assuming you operate any user or customer facing SSL connections you’ll probably want to provide information to your users and customers about this issue.  This should include information about whether or not your systems were vulnerable, and if vulnerable, the time you patched or updated OpenSSL and the actions you’ve taken with respect to your digital certificates.  Here are links to examples of “OK” and “resolved” or “being resolved” messages.  Be sure to carefully tailor yours so it is accurate. .  A number of companies have already posted useful notices, but they remain in the minority of affected websites and device manufacturers. 
  • Are there other disclosure obligations?  Finally, with respect to your servers (assuming you were using vulnerable code), , you need to consider whether you have any disclosure obligations arising under contracts or applicable law.  Although the news media is frequently  referring  to this incident as a “breach,” it is uncertain whether evidence of a vulnerability is ever sufficient to trigger reporting or notification obligations.  Constructions vary widely, but typically breach disclosure obligations arise in the event of an actual breach (always) or evidence that a breach may have occurred (sometimes).  In some cases, especially under commercial contracts, the mere fact that vulnerable code was running may be enough to trigger a disclosure obligation (which would need to meet contract requirements, but is likely to be similar to the customer disclosure suggested above).  But, in most cases, absent some indication that the vulnerability was actually exploited (which might be indicated by evidence of use of protected information from the servers), there is not likely to be a state requirement for notifying individual users or customers.

Most U.S. state breach notification statutes require notification only when the data custodian has knowledge (for example, Massachusetts, Mass. Gen. Laws 93H § 1 et seq.) or a reasonable belief  (for example, Florida, Fla. Stat. § 817.5681) of data having been compromised, both of which appear to require more than mere discovery of a coding flaw.  Even states without a clear “knowledge” requirement (for example, Washington, D.C., D.C. Code § 28-3851 et seq.) still seem to require more by defining “breach” with a requirement that data be acquired.  Some states, such as Delaware (Del. Code Ann. tit. 6 § 12B-101 et seq.) and Idaho (Idaho Code § 28-51-104 et seq.), may require you to undertake a good-faith investigation to determine if there is a reasonable likelihood of harm to consumers. 

Whether or not notification statutes or regulations are triggered will depend on the precise facts of your situation, so make sure consideration of the issue is on your checklist.  Remember that contract standards may have a lower threshold for what constitutes a breach than that in typical breach disclosure statutes.  As to the statutes, while a review of all breach disclosure law is well beyond the scope of a blog post, in the absence of any other indicators that a breach has occurred, the mere fact that one was running vulnerable code is not likely to constitute a breach under such laws.

On the other side of the table, what does this mean if you or your business are the user of a site or service which may be vulnerable?

  • As an initial step, check the status of your vendor’s site.  You could simply ask or look for information on the vendor’s site.  While there are tools available to test sites, bear in mind that they speak to current status, so they won’t tell you if the vulnerable code was running at some prior point.
  • Consider taking steps to make sure your browsers (and other client devices) are not tricked by revoked certificates.  This may include setting your browsers to reject revoked certificates or taking other steps to exclude access to sites or services that are using revoked certificates.
  • Check the terms of your contract.  Many commercial agreements require software and hardware vendors to notify their customers about breaches or vulnerabilities as soon as they are discovered.  For vendors important information (especially information that is PII of others where you have potential breach disclosure obligations), determine what information you might be entitled to receive, ask for it, and use the information you learn to develop your own risk assessment.    As discussed above notification laws vary widely and require unique determinations based on the facts of your situation, but in the absence of other indications that a breach has occurred, the fact that your vendor used vulnerable code on a server used to process PII for which you are responsible is not likely to give rise to a notice obligation.  Talk to your vendor to determine whether any of your data may have actually been exposed by this vulnerability and make your notification decisions accordingly. 
  • Finally, this is another great opportunity to remind users to use strong, unique passwords for each application, and to change them frequently.  You (and your employees) should carefully consider changing the passwords for any site processing sensitive data that used the flawed version OpenSSL (or even for non-sensitive data if the same password is used at any site processing sensitive data).  And, as is always the case when a security incident occurs (or is evaluated), consider whether any lessons learned in responding suggest updates to your information security policies and procedures. 

DISCLAIMER: Because of the generality of this update, the information provided herein may not be applicable in all situations and should not be acted upon without specific legal advice based on particular situations.

© Latham & Watkins LLP | Attorney Advertising

Written by:

Latham & Watkins LLP
Contact
more
less

Latham & Watkins LLP on:

Readers' Choice 2017
Reporters on Deadline

"My best business intelligence, in one easy email…"

Your first step to building a free, personalized, morning email brief covering pertinent authors and topics on JD Supra:
Sign up using*

Already signed up? Log in here

*By using the service, you signify your acceptance of JD Supra's Privacy Policy.
Custom Email Digest
Privacy Policy (Updated: October 8, 2015):
hide

JD Supra provides users with access to its legal industry publishing services (the "Service") through its website (the "Website") as well as through other sources. Our policies with regard to data collection and use of personal information of users of the Service, regardless of the manner in which users access the Service, and visitors to the Website are set forth in this statement ("Policy"). By using the Service, you signify your acceptance of this Policy.

Information Collection and Use by JD Supra

JD Supra collects users' names, companies, titles, e-mail address and industry. JD Supra also tracks the pages that users visit, logs IP addresses and aggregates non-personally identifiable user data and browser type. This data is gathered using cookies and other technologies.

The information and data collected is used to authenticate users and to send notifications relating to the Service, including email alerts to which users have subscribed; to manage the Service and Website, to improve the Service and to customize the user's experience. This information is also provided to the authors of the content to give them insight into their readership and help them to improve their content, so that it is most useful for our users.

JD Supra does not sell, rent or otherwise provide your details to third parties, other than to the authors of the content on JD Supra.

If you prefer not to enable cookies, you may change your browser settings to disable cookies; however, please note that rejecting cookies while visiting the Website may result in certain parts of the Website not operating correctly or as efficiently as if cookies were allowed.

Email Choice/Opt-out

Users who opt in to receive emails may choose to no longer receive e-mail updates and newsletters by selecting the "opt-out of future email" option in the email they receive from JD Supra or in their JD Supra account management screen.

Security

JD Supra takes reasonable precautions to insure that user information is kept private. We restrict access to user information to those individuals who reasonably need access to perform their job functions, such as our third party email service, customer service personnel and technical staff. However, please note that no method of transmitting or storing data is completely secure and we cannot guarantee the security of user information. Unauthorized entry or use, hardware or software failure, and other factors may compromise the security of user information at any time.

If you have reason to believe that your interaction with us is no longer secure, you must immediately notify us of the problem by contacting us at info@jdsupra.com. In the unlikely event that we believe that the security of your user information in our possession or control may have been compromised, we may seek to notify you of that development and, if so, will endeavor to do so as promptly as practicable under the circumstances.

Sharing and Disclosure of Information JD Supra Collects

Except as otherwise described in this privacy statement, JD Supra will not disclose personal information to any third party unless we believe that disclosure is necessary to: (1) comply with applicable laws; (2) respond to governmental inquiries or requests; (3) comply with valid legal process; (4) protect the rights, privacy, safety or property of JD Supra, users of the Service, Website visitors or the public; (5) permit us to pursue available remedies or limit the damages that we may sustain; and (6) enforce our Terms & Conditions of Use.

In the event there is a change in the corporate structure of JD Supra such as, but not limited to, merger, consolidation, sale, liquidation or transfer of substantial assets, JD Supra may, in its sole discretion, transfer, sell or assign information collected on and through the Service to one or more affiliated or unaffiliated third parties.

Links to Other Websites

This Website and the Service may contain links to other websites. The operator of such other websites may collect information about you, including through cookies or other technologies. If you are using the Service through the Website and link to another site, you will leave the Website and this Policy will not apply to your use of and activity on those other sites. We encourage you to read the legal notices posted on those sites, including their privacy policies. We shall have no responsibility or liability for your visitation to, and the data collection and use practices of, such other sites. This Policy applies solely to the information collected in connection with your use of this Website and does not apply to any practices conducted offline or in connection with any other websites.

Changes in Our Privacy Policy

We reserve the right to change this Policy at any time. Please refer to the date at the top of this page to determine when this Policy was last revised. Any changes to our privacy policy will become effective upon posting of the revised policy on the Website. By continuing to use the Service or Website following such changes, you will be deemed to have agreed to such changes. If you do not agree with the terms of this Policy, as it may be amended from time to time, in whole or part, please do not continue using the Service or the Website.

Contacting JD Supra

If you have any questions about this privacy statement, the practices of this site, your dealings with this Web site, or if you would like to change any of the information you have provided to us, please contact us at: info@jdsupra.com.

- hide
*With LinkedIn, you don't need to create a separate login to manage your free JD Supra account, and we can make suggestions based on your needs and interests. We will not post anything on LinkedIn in your name. Or, sign up using your email address.