Mandatory data breach notification: Are you ready?

With one month to go before data breaches must be reported in accordance with the mandatory data breach notification (MDBN) scheme, it’s a good time to check if you’re fully prepared for the scheme’s requirements. The consequences of failing to notify or not complying will attract a maximum penalty of up to $360,000 for an individual and $1,800,000 for corporations.

Basic fundamentals of a data breach within the MDBN scheme

In this section we will explore the basic fundamentals within the MDBN scheme. Please bear in mind that it does not cover the entire scheme, but serves a starting point only.

What is a data breach?

According to the Office of the Australian Information Commissioner (OAIC), there are currently three events constituting a data breach:

1. Unauthorised access to data

2. Unauthorised disclosure of data

3. Data loss

What type of data is included in a breach?

There are currently four types of data that if lost, is deemed a breach:

1. Sensitive data: medical and health records, political opinions, ethnic information etc.

2. Identifying information: driver’s licence, tax file number, Medicare number, passport number or similar

3. Financial information: bank details, credit card details, investment information, stock options, Bitcoin (yes, Bitcoin!)

4. A combination of two or more pieces of personal information: for example name and date of birth.

When should you notify?

A notifiable breach event happens when the following three criteria are met:

1. A data breach occurred

2. The breach will likely result in serious harm

3. The entity holding this information was not able to prevent the risk of serious harm

Preparing for data breach notification

The MDBN can be an overwhelming scheme to tackle, and this is why we have simplified it to three key areas you need to cover to ensure that you are in compliance.

Ultimately you need to answer three simple questions:

1. Do you know where your customer data is stored and who has access to it?

2. Do you have the proper detection and monitoring processes in place?

3. Is your incident response process ready and tested?

Where is your customer data and who has access to it?

The following list contains potential data storage locations to consider, but is in no way exhaustive:

Data centres: Think about the infrastructure under your control such as data centres, as these will typically hold some of your customer data. Consider also your disaster recovery (DR) sites or any other back up sites containing the four types of data mentioned above. Don't forget databases that contain copies of this data too.

Cloud providers: Consider not only what is hosted in Amazon Web Services (AWS) and Azure, but also what is located in public clouds such as Google Drive, OneDrive or other cloud-based applications. Creating an inventory of what is (and has previously been) stored across public cloud applications is a very difficult and challenging exercise and must be carefully and correctly executed.

Endpoint: This includes data stored on the laptops and desktops of employees and contractors. If you enable Bring Your Own Device (BYOD), you may need to consider these BYOD devices as well.

Partners: These are often forgotten, but if you have a software development partner then they most likely received a copy of your data to develop your application. Without proper mechanisms in place to anonymise data, this could lead to the exposure of sensitive customer data via this partner.

Media storage devices: Consider USB devices, DVDs, backup tapes and any other form of media that may contain this data. All too often devices such as these are lost, only for sensitive customer data to be found by others who then use it fraudulently or compromise the data owner.

Creating an inventory of your data across many locations is not a simple exercise, and you may wish to leverage some technical data discovery tools to assist. During data inventory, take particular consideration to the four types of data previously discussed, as well as the protection mechanisms in place.

Who has access to the data?

Whilst on the surface this may seem like a simple question, modern-day usage of various outsourcing opportunities creates a complex environment. This makes defining an organisation’s boundary and identifying individuals with access a much more challenging exercise.

The following is a non-exhaustive list of parties who may have access to your data:

1. Within your organisation:

  • Your IT department
  • Other non-IT team. Think about other departments in your business that have access such as the marketing team, Data Warehousing, R&D team and others. Don’t forget application managers with administrative access to the application

2. Outside of your organisation:

  • Your third party suppliers and vendors (don’t forget to include any outsourcing providers your suppliers may be using)
  • Offsite backup providers, DR site providers amongst others

Detection and monitoring of breaches

It goes without saying that to report data breaches, you firstly need to be able to detect and monitor these breaches.

Start by asking the following list of qualifying questions:

1. Do you have tools and processes to detect the three types of breaches (unauthorised access, unauthorised disclosure and data loss)?

2. What type of detection controls do you have in place? Do you have a data loss prevention (DLP) tool installed and configured correctly?

3. Do you have appropriate logging enabled for access to the data?

4. Do you have continuous monitoring in place? Do you have an in-house or an outsourced Security Operations Centre (SOC)?

Incident response and breach notification

This is the final piece of the puzzle; if you know where your data is, who has access to it and that you’re able to monitor access to that data, you now need to know what to do when there is a breach.

If you detect a data breach, you must have a suitable incident response procedure in place. It cannot be stressed enough how important it is to have the following:

1. A defined incident response process that includes technical and business representation and covers multiple breach scenarios

2. Regular testing of incident response processes

3. A classification and escalation process for the handling of security incidents (from low to extreme) based on its impact to the business

4. An appropriate PR communication statement for various types of breaches

When a data breach is detected you need to notify the affected individuals and possibly the OAIC. However, you only need to do so when the breach may cause harm to individuals and you don’t have controls in place to mitigate that harm. Such mitigating controls could be data encryption or the ability to remote wipe the device, along with other similar types of controls.

A note about prevention and detection

An effective prevention strategy, whilst not required under MDBN scheme, should be the cornerstone of your security program. The strategy should include controls such as vulnerability management, security testing and red teaming. Prevention and detection has been known to reduce the likelihood of breaches in the first instance, therefore also reducing the risks of notification fines. Additionally, a strong prevention strategy commonly identifies breaches that are hard to detect with traditional off-the-shelf detection monitoring.

Recommendations on how to create an effective prevention program are out of the scope of this article but will be covered in further blogs.

Endnote

Preparing for the mandatory data breach notification scheme is not an easy step for organisations to take. This article attempted to simplify MDBN and its requirements for organisations, however it does not cover the details of a complete security program that should include areas such as governance, prevention, staff awareness, security testing, and many more.

For further assistance from highly skilled and experienced consultants on how to achieve a robust security program ready to meet the demands of the MDBN, please email NCC Group at response@nccgroup.trust.

Published date:  19 January 2018

Written by:  Louay Ghashash

comments powered by Disqus

Filter By Service

Filter By Date