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

[Audrey McNeil <audrey () riskbasedsecurity com>]

http://www.jdsupra.com/legalnews/incident-response-practice-tip-balance-93855/

State breach notification statutes are being amended 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 new law, 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, companies should call in
outside experts to help extricate the attackers and block them.

- 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.
- 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.
- 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.

According to Eric Friedberg, 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) Computer Security Incident
Handling Guide 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.

_______________________________________________
Dataloss Mailing List (dataloss () datalossdb org)
Archived at http://seclists.org/dataloss/
Unsubscribe at http://lists.osvdb.org/mailman/listinfo/dataloss
For inquiries regarding use or licensing of data, e-mail
        sales () riskbasedsecurity com 

Supporters:

Risk Based Security (http://www.riskbasedsecurity.com/)
YourCISO is an affordable SaaS solution that provides a comprehensive information security program that ensures focus 
on the right security.  If you need security help or want to provide real risk reduction for your clients contact us!