Breach Disclosure

Introduction of mandatory breach disclosure laws

After several long years gestating through the lower and upper house, the Australian Government has finally passed the Privacy Amendment (Notifiable Data Breaches) Bill 2016, which establishes a mandatory breach notification scheme in Australia.

This morning, almost in anticipation of the law’s passage, the Australian Information Security Association (AISA) sent an email notifying its members of an incident affecting its members’ data:

We have made a commitment to you that we will always keep you up to date on information as and when we have it.

Today the new Board took the decision to voluntarily report to the Office of the Australia Information Commissioner an incident that occurred last year that could have potentially impacted the privacy of member data kept within the website. At the time, a member reported the issue to AISA and it was rectified by the then administrative team. What wasn’t done, and as we all know is best practice, was notification to you as members that this potential issue had occurred, and notification to the Australia Privacy & Information Commissioner.

Your member information is not at risk and the issue identified has been rectified.

The AISA Board takes this matter very seriously.

As the industry body representing these and many other information security issues, we expect and demand best practice of AISA and of our members. The Board holds the privacy of member data as sacrosanct and will ensure that all members are aware of any and all privacy information.

If you have any concerns or wish to discuss this matter please feel free to contact either myself or the Board members.

Many thanks for your ongoing support.

And while AISA quite validly trumpets that notifying its members is best practice, how they notified their members falls well short of best practice.

More specifically, the notification doesn’t answer any questions that would be expected to be asked, and in the context of broader AISA issues occurring, raises questions of why the notification occurred now.

Questions left unanswered include:

• What happened?
• What has been done to remediate and limit such exposures in the future?
• What information was potentially compromised?
• Was it a potential compromise or an actual compromise?
• What should I (as a member whose data was potentially compromised) do about it?
• Do I need to look out for targeted phishing attacks? Transactions?
• Has my password been compromised? Has my credit card been compromised?
• Who has investigated it and how have you drawn the conclusions you’ve drawn?

Data breach notification effectively forms part of a company’s suite of tools for managing customer and public relations. Doing data breach notification well can make a difference in the effort required to manage those relationships during a crisis, and the value of long term customer goodwill.

This blog post explores what a “good” data breach notification looks like, and highlights where AISA falls short of that standard.

How to effectively manage a breach

As data breaches continue to increase in frequency, the art of data breach notification has become more important to master. A key challenge in responding to a data breach is notifying your customers in a way that enhances, rather than degrades, your brand’s trustworthiness.

This guide outlines the key factors to consider should you find yourself in the unfortunate position of having to communicate a data breach to your customers.

There are 7 factors we recommend you focus on:

Clearly, the AISA announcement falls short on a number of the above factors.

In particular:

• Clarity — the AISA announcement does not clearly identify who was affected, or even if there was in fact a breach of data.
• Timeliness — If the incident occurred on June 15th last year last year, why wait to notify members over eight months after the incident occurred? Given so much time has passed since the incident, and AISA having sufficient time to investigate and rectify the issue, why was there not more information provided about the nature of the breach? Given the time elapsed, the breach notification seems conveniently timed to coincide with the legislation, which leads to the final point;
• Genuineness — No apology was given as part of the breach notification, nor was any detail given about what members need to do, what information (if any) was breached, or any assurances that it won’t occur again.

An email with the 7 factors included will answer (as best as you can) the questions the affected party may have. Further follow up information can be provided using an FAQ, a good example of which is the Pont3 Data Breach FAQ.

So, with an understanding of what to do, it’s also key to consider what not to do.

Breach Disclosure — What not to do

When formulating a breach notification strategy it is also important to know what not to do. Described below is our ‘Hierarchy of Badness’, starting with the worst things first!

1. Intentionally lying: Making any false statements in a bid to make the situation appear less complicated or serious than it is known to be, for example, stating that the data lost was encrypted when it was not. There is a very high chance that the truth will become available at some point, and at that point apparent intentional lies will wipe you out. This routinely gets people fired, and can cause significant reputational damage for the organisation.

2. Unintentionally lying: Drawing conclusions and providing statements without thoroughly analysing the impact and depth of the breach can lead to unintentional lies or the omission of information. This can be a result of publishing a notification too early before the details are fully understood. Whilst unintentional lies are ‘better’ than intentional lies, it may be difficult to prove to your customers that there was no ill intent. Depending on the lie, this may also result in someone getting fired.

3. Malicious omission: As the name suggests, organisations sometimes leave out key information from their disclosure statements particularly by directing focus to information that is not as crucial. For example, rather than stating that data was not encrypted in storage focusing the statement on data being encrypted at transit. While the latter is true, a crucial piece of information has purposely been omitted for the purpose of diversion. Not a great strategy. While omission may be a a legal requirement throughout the course of an incident, an omission which changes the implied intent or meaning of a communication can backfire.

4. Weasel words and blame-shifting: A very common but poorly conceived inclusion in breach notifications is overused clichés such as ‘we take security seriously’, or ‘this was a sophisticated attack’. If there is no good reason to use that particular phrase/word it is better not to include it in the statement. Describing an attack as sophisticated or suggesting steps are being taken without providing further details is not going to make your customers feel better about the situation.

Our Hierarchy of Badness heat map below depicts the sweet spot for disclosure.

Conclusion

Historically, some organisations have preferred to use the ‘Silence & roll the dice’ strategy. This is a risky strategy, where the organisation doesn’t notify its customers about the breach at all, and simply hopes the whole situation will blow over.

However, with the passing of the Privacy Amendment Bill, while this may pan out well in some cases, it can have adverse outcome in others particularly if the breach is identified and reported by bloggers/researchers/users (a case of malicious omission in the ‘Hierarchy of Badness’). However, there will be a lot of organisations falling under the threshold for disclosure, so the ‘Silence and roll the dice’ strategy will continue to be used.

An ideal way to help your customer through a data breach is by referring them on to services like ID Care, the various CERTs, or other service providers for your customer get the advice they need to respond to the issue in their particular circumstances. Trying to “advise” your clients about what they should do post-breach — when you’re doing this from a position of having just had a breach yourself — is rarely a good strategy.

Finally, the best preparation for data breach disclosure is to have both:

• A micro-level response for your customers regarding what data was lost, if it’s recoverable and what they as data owners can do to mitigate the impact; and
• A macro-level response for the press with details of the volume of data lost, response plan and how your customers must go about handling the situation.

It is also necessary to realise that data breach notification is not a one-time act. To ensure the best outcome from a public relations and crisis management perspective, it’s best to provide customers with updates as and when you get new information and ensure your customers realise it’s an ongoing engagement and that you genuinely care about their data.

Article by Nick Ellsmore, Chief Apiarist, Hivint

Check out more resources in Security Colony, such as incident response runsheets, an incident response communications plan guide, and a sample breach notification letter