How to disclose a security breach

[Audrey McNeil <audrey () riskbasedsecurity com>]

http://betanews.com/2015/12/07/how-to-disclose-a-security-breach/

The days and weeks after a major security breach can be trying, even for
veterans of the security field. Chaos inevitably erupts as the organization
attempts to assess and contain the damage. Often far down the list of
priorities is the disclosure of the breach, but this can be one of the most
critical steps for an organization to get right.

It is vital for financial reasons, to the recovery of the brand and for the
viability of the company. It is not an easy task when customer’s personal
information has been stolen. The reaction from customers is almost always
the same: swift and highly critical of the organization and how it manages
the aftermath.

The October 2015 TalkTalk breach has been one of the most fascinating
incidents of the last year. It provides us with many cybersecurity lessons,
and serves as a prime example of how not to handle a breach disclosure. It
is also possible it is one of the largest breaches in the history of the
UK, with initial reports stating that the personal information of a million
customers was compromised during a "sophisticated and sustained
cyber-attack".

A Bizarre Sequence of Events

TalkTalk was inexplicably open about not adhering to established security
best practices. As part of its initial communications with the media, CEO
Dido Harding stated that the company was not under any obligation to
encrypt any sensitive customer data.

A strange declaration strongly indicating that sensitive data may be
sitting unprotected amongst the firm’s assets. TalkTalk was also breached
this past February and its former parent company, Carphone Warehouse,
suffered a breach in August affecting 480,000 TalkTalk customers.

There were of signs of massive chaos at TalkTalk after the attack, as they
disclosed that data was stolen as a result of a distributed denial of
service (DDoS) attack. Again, an eyebrow-raising statement that does not
even make sense: a DDoS attack is not capable of "stealing data".

It is likely that attackers used the DDoS attack as a smokescreen. This is
an increasingly common tactic amongst advanced attacks and alleged to be
the same method used to target Carphone Warehouse. The purpose of using a
smokescreen is to keep the security operations staff distracted while the
real attack is executed amidst the noise. In many ways the cyber
battlefield echoes the real world battlefield. Diversionary tactics or
"feints" have long been a part of military campaigns.

Much like the many other cyberattacks this year, TalkTalk customers quickly
took to social media to criticize the breach, and the bizarre
communications from the company to notify them that their personal data was
at risk.

Responsible Breach Disclosure

Even before this incident, responsible disclosure of breaches was a hotly
debated subject in the security industry. There are many elements involved
in the decision to disclose and the delays that may result.

The breach must be scoped to understand what data has been compromised and
what users may have been affected. This process is often slow and
laborious, especially for organizations with nascent incident response
capability.

Disclosing breaches without all of this information can be dangerous and
costly to the organization, as every affected customer represents a
potential dollar amount to the company in terms of response and follow-on
support. It is also possible that a disclosure could place an active
investigation at risk.

However, waiting too long to disclose is not fair to customers and end
users whose personal information is now in jeopardy. Care must also be
taken in the method of disclosure. Again, experts disagree on the best
method to use to disclose the breach.

Disclosing via phone, text or email may be introducing another vector for
phishing, making matters worse. Disclosing via traditional mail may be too
slow.

The many variables involved make it difficult to put hard restrictions
around what a "normal" disclosure time should be.

Many jurisdictions have developed legislation targeted at this issue. In
the United Kingdom, the Information Commissioner’s Office (ICO) requires
that they be notified within 24 hours of an organization becoming aware of
the "essential facts" of the breach.

ICO provides little guidance on customer notification timeframes, other
than customers should be notified "without undue delay". The wording around
guidance is generally loose, indicative of the difficulty surrounding this
issue.

In the United States, HIPAA (Health Insurance Portability and
Accountability Act) requires customer notification within 60 days of the
detection of the breach. 60 days seems a long time to learn one’s personal
data has been compromised. A timeframe of two to four weeks seems
reasonable for an initial disclosure.

Breaches continue to grow more commonplace. Attackers are now targeting
personal and health care related data, as its value grows on the dark web.
As we observed with these recent breaches, customers are showing they are
becoming acutely aware of the security practices of the organizations they
choose to do business with.

It’s clear that there’s a need for an even greater dialogue between
security professionals and organizations about what constitutes responsible
breach disclosure.

_______________________________________________
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!