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.


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

Voicemail and VOIP

Commonly overlooked security risks


Every company has a phone system of some type, and just like with smartphones, these systems often offer so much more than just basic PABX functionality — technology such as VoIP, video conferencing, Unified Communications platforms, cloud based PABXs are all becoming par for the course. Most, if not all of these systems, also include integrated voicemail functionality.

This article considers some of the avenues through which attackers may look to compromise the security of a company’s phone systems.


There are many reasons attackers may be interested in a company’s phone system, including:

  • Using it to make fraudulent calls;
  • Aiding in social engineering attacks;
  • Eavesdropping on sensitive calls;
  • Harvesting sensitive information from voicemails;
  • Compiling internal directories of company staff; and
  • Attempting to obtain call detail records for market intelligence and industrial espionage.

Complicating matters is that, unlike dedicated VoIP systems and Video Conferencing systems which are often audited and maintained by the IT Security teams, traditional PaBX, IVR and Voicemail systems are often overlooked or fall outside the management purview of the IT and Security teams.

Voicemail is still relied upon for everyday use by many organisations, and sensitive information is commonly left in voicemail messages. A motivated attacker targeting a company is highly likely to be able to gain valuable information by listening to the voicemail of system administrators or executives over a period of time.

With cheap VoIP services being readily available it is also simple for attackers to automate and scale up their attacks to make multiple simultaneous calls and complete them faster. There are many ways to automate phone attacks, and it is easy for an attacker to write a script or use existing software to automate a range of attacks, including those outlined below.

Types of Voicemail and VOIP Attacks

Brute force attacks

Having a four-digit PIN as the de facto standard for voicemail authentication means an attacker will have a reasonable chance at successfully guessing the PIN through manual avenues such as by just using the phone keypad. Even with longer PINs, common patterns and repeating numbers are so commonly used by staff that an attacker is likely to work out the PIN using a PIN list instead of having to manually enter in every possible combination of digits.

In combination with most voice mail and phone systems not supporting account lockouts, nor having other security controls such as logging and alerting, which are commonly applied to other IT systems, undertaking a successful PIN brute force attack to gain access to a staff member’s voicemail box is unlikely to prove difficult to the determined attacker. Additionally, there are also methods to bypass lockout timers in those instances where they are in place. One technique that is almost always successful on large voicemail systems is attempting two or three common PINs against every extension or user account. This would prevent triggering any account lockouts, if implemented.

Once an attack run is complete the attacker may well have access to several voicemail accounts.

Directory reconnaissance

The same automation that can be applied to PIN brute force attacks can also be used for other attacks against phone systems. One example is the creation of internal directories. An attacker can use the “find extension” feature of modern PABXs and voicemail systems to make a list of names, extensions and sometimes job titles within a company. They can also do this by calling and making a note of every greeting for every extension if the PABX doesn’t have a names directory feature.

Call-forwarding attacks

Another use attackers have for voicemail is the call forwarding feature which can be used for free phone calls or to aid in social engineering attacks.

Getting free phone calls is the simplest example. An attacker who has compromised a voicemail box sets up call forward to a mobile phone, overseas or other toll number they want to call, then calls back the local DDI number or the company’s main toll-free number and enters the extension number and waits for the call-forward to connect them to their pre-programmed toll number.

This attack can be reversed as well — an attacker can also use a compromised voicemail box to receive incoming calls using the call forwarding feature to forward calls to a VOIP or pre-paid phone controlled by the attacker.

They then will have control of an extension on that company’s phone system which they can give to external parties to call back on to appear like they are inside the company’s office, which can be an invaluable means to facilitate the commission of a further social engineering attack.

Leveraging Caller ID

Most phone systems, when call-forwarding is used, display the caller-ID of the voicemail extension rather than the number of the originating party.

An attacker may be able to leverage the call-forward feature to masquerade as a known external party, such as appearing to be a known vendor or to be calling from inside the target company’s building. This can gain greater traction for social engineering purposes.

On a penetration testing engagement some years ago, my colleagues and I took over a manager’s extension at corporate headquarters and set up a call forward to the security desk at one of their rural sites. We called ahead to the security desk to add our names to the visitor register. The security desk asked very few questions because their phone displayed the call as originating from the manager’s phone at the organisation’s headquarters.

When we arrived, the security desk was expecting us and allowed us to enter without any restrictions.


The attacks scenarios above relate to simple voicemail systems, which most people overlook, considering them to a straightforward way to store and retrieve messages. However, when you include customer facing IVRs, VoIP systems, PABX systems, Teleconferencing and Video Conferencing systems, Unified Communications systems, call-queue management systems and the endless other applications of modern phone systems, then the possible vulnerabilities that can be exploited by attackers are almost endless.

Large companies often own a block of numbers, generally in lots of ten thousand. It is a good idea to periodically audit these number blocks to classify all lines, then performing an audit of possible attack vectors of all the phone systems connected to them.

Practicing the same security hygiene for voicemail that you do for other systems is critical, for example:

  • Disabling default accounts;
  • Auditing voicemail boxes for common PIN’ or disallowing common or simple PINs;
  • Setting a minimum PIN length of six digits;
  • Setting unique temporary PINs when provisioning new voicemail boxes;
  • Setting up lockout timers that don’t lose their state over multiple calls;
  • Disabling call forwarding features;
  • Restricting allowed forwarding numbers to local mobiles and landlines only;
  • Deactivating unused voicemail boxes; and
  • Applying logging and alerting if possible.

With some phone systems this is often easier said than done. We hope this article gets you thinking about how your company uses and manages phone systems and how they might be abused by attackers if appropriate vigilance is not exercised.

Article by John McColl, Principal, Hivint