Commentary Addressing Risks and Opportunities Through the Lifecycle of Data, Technology, Advertising and Innovation

Data Counsel

Home | Data Counsel

<img class="alignright wp-image-3912 size-medium" src="http://dataprivacymonitor.bakerhostetlerblogs.com/wp-content/uploads/sites/5/2015/05/Data_163916964-300x300.jpg" alt="Data_163916964" width="300" height="300" />State breach notification statutes <a href="https://www.dataprivacymonitor.com/data-breach-notification-laws/state-law-roundup-legislatures-across-the-u-s-revamp-data-breach-notification-laws/">are being amended</a> on almost a monthly basis. Several laws have, or will soon have, a mandatory notification deadline for notifying affected individuals after the discovery of the incident. Washington’s <a href="http://lawfilesext.leg.wa.gov/biennium/2015-16/Pdf/Bills/House%20Passed%20Legislature/1078-S.PL.pdf">new law</a>, which went into effect on July 24, includes a 45-day deadline for notification but goes further to allow for extra time “to determine the scope of the breach and restore reasonable integrity of the data system.” This is an excellent approach to a difficult issue. Many legislators believe that the “law enforcement delay” provisions in most breach notification statutes is sufficient to allow a company to delay notification when appropriate; however, the reality is that law enforcement is reluctant in the vast majority of incidents to state in writing that public notice of the incident would impede their investigation.

A company may want to rush to provide notification, fearing it will be criticized for moving too slowly by the press, regulators, and customers. Unfortunately, this pressure results in many incident response teams making the fatal mistake of not conducting a proper investigation, not properly containing the incident and remediating affected systems, and making public statements that may not be accurate when the investigation is actually finished (causing the company to update their message and sometimes lose the confidence of their customers, stakeholders, and regulators).

If a company believes that its credibility will be impacted if it does not notify “immediately,” it should consider that rushing to announce a breach “to be transparent” can result in making mistakes potentially more costly than poor communications and not having mitigation services in place. According to Ann Barron-DiCamillo, a director of the Department of Homeland Security U.S. Computer Emergency Readiness Team, <a href="http://www.nextgov.com/cybersecurity/2015/09/dhs-heres-why-agencies-should-not-try-boot-hackers-themselves/120647/">companies should call in outside experts</a> to help extricate the attackers and block them. 
<ul>
	<li>Preserving evidence may help identify the scope of access. Too often, companies announce a security incident because they do not have enough information to rule out that a breach happened. Sometimes the needed evidence is overwritten because so much time has passed (e.g., firewall logging, logging of search queries in a database). In other events, the internal team destroys critical evidence because it is focused on blocking the attack rather than the more broad vision of incident response – finding out what happened, how it happened, what mitigation is appropriate, and what steps need to be taken to prevent a similar incident in the future.</li>
	<li>The breach may continue after the time of the announcement if the attacker is not blocked. If the attacker is not blocked, a retaliatory attack may result, which could lead to business disruptions because the attacker takes actions to bring down the company’s IT network. In other situations, the company may need to make a second announcement because the attacker has expanded the affected population by continuing to steal personal information.</li>
	<li>Steps taken by the incident response team may tip off the attackers. During an active attack, care needs to be taken not to let the attackers know they have been discovered. During some sophisticated attacks, it has been prudent for companies to utilize email systems off of their network so that the incident response team could communicate effectively to block the attack without the attackers receiving advance notice of the steps being taken to block their efforts.</li>
</ul>
<a href="http://www.strozfriedberg.com/wp-content/uploads/2015/05/Client-Advisory_Premera_May-2015sf.pdf">According to Eric Friedberg</a>, executive chairman of Stroz Friedberg, “On the defensive side, it can then take months of round-the-clock work to determine how attackers got in, what they saw, what they stole, and whether they are hiding inside. This isn’t a bank heist, where it’s guns-drawn obvious that a theft has taken place, that money was stolen, and that the robbers went that-a-way.” It is no surprise, therefore, that the National Institute of Standards and Technology (NIST) <a href="http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf">Computer Security Incident Handling Guide</a> includes preparation; detection and analysis; containment, eradication, and recovery; and post-incident activity as the critical components of a successful incident response.

If executive leadership or other incident response team members feel pressure to notify too quickly because of an impending deadline, remind them of the importance of continuing incident response beyond detection and analysis. Failure to move onto the containment, eradication, and recovery phase before communicating the incident publicly can make things worse. If the investigation is taking an uncomfortably long time to complete, consider engaging law enforcement and maybe even regulators to help get the support the company needs when the incident is announced.

Incident Response Practice Tip: Balance Meeting Breach Notification Deadlines With Securing Your Network