The 5 most important things to consider during a data breach

Notifiable Data Breach


Learning that you have experienced a data breach is an uncomfortable moment in any person’s life. Especially if you are a cyber security professional charged with keeping information safe and secure. More so if a third party tells you that you have seemingly lost information. Unfortunately, any day involving a data breach will be a bad day. How bad a day, will depend on a number of factors, and your level of readiness. The five important things to consider during a data breach presented here aim to help make a bad day, just a little bit easier.

Please keep in mind that managing a data breach is complex. There is no substitute for experience and knowledge, as no two data breaches are identical. The caveat I need to provide with this advice, is that the five most important things to consider during a data breach is not exhaustive advice and there are nuances that you need to consider. Please treat the following as general good practice advice.

Before we dive into a Top 5

There is a propensity to look for blame and jump to conclusions. Keep in mind, if you take your security obligations seriously, respect the role you have as a custodian of sensitive information, invest appropriately in security and manage your risk appropriately, you need to accept the fact that you are not alone. You are not incompetent or even special, breaches happen, and are a part of the world we live in. You are not the first person or organisation to experience a breach and unfortunately, you won’t be the last. Having said that, if you are guilty of consistently ignoring your security obligations, underinvesting in people, process and technology, overlooking your obligations to protect sensitive information, and trusting to providence that everything will be fine, those feelings of regret, remorse and discomfort are entirely appropriate.

At this stage you haven’t even confirmed whether it really is a security incident, you’ve just received (or uncovered) some information that indicates there might be a breach. So, before we panic, we really just need to work through the steps and work the facts.

Incident response is a process typically consisting of six main steps:

1.  Preparation

2.  Identification

3.  Containment

4.  Eradication

5.  Recovery

6.  Lessons Learned

Now if you haven’t actually done step number 1. Preparation, then a little bit of panic is probably appropriate at this stage, but all is not lost.

 

#1 – Confirm the breach, work the data.

Before we get carried away let’s establish whether there, in fact, has been a breach. This is part of the identification stage in the incident response process. You need to look at what has been reported and how. Was it third-party notification? i.e. someone outside the organisation told you a customer perhaps or business partner. Was it an internal staff member that reported something weird, or clicked a link? Was it your bank letting you know that there have been fraudulent transactions on credit cards and the common factor is your organisation. Was there data on Pastebin or similar services that looked like it may have come from your databases? Was there an alert from an IDS/IPS, SIEM event or other systems that indicated there may be a breach? Are files on the network suddenly encrypted?

These notifications all need to be validated and confirmed. It wouldn’t be the first time an incident turned out to be a new feature on a website, a new system or a misconfiguration (which can be a breach as well BTW).

How do you confirm the breach? Simple, assume the information received is correct and form a hypothesis of how it could have occurred. We’re doing a privacy blog here so let us use the loss of Personally Identifiable Information (PII) as an example. Let’s say data has been identified on Pastebin and it looks like your client records. Some key questions you will need to ask are:

  • Where does this information exist in our organisation?
  • How can it be accessed, is it internal only or internet facing? Perhaps it is stored by a third party?

Asking these two questions will help you establish whether it is indeed your data and perhaps give a clue as to which controls may have failed. These questions will provide guidance as to where you need to look next. Are we looking through web and application logs, or are we digging through internal access logs in Active directory, proxy logs, email logs, etc? By just following up on these two questions, the Shearwater team have in the past confirmed incidents where hackers had gained access to systems and were actively retrieving data, but we’ve also identified incidents where a staff member inadvertently mailed out the bulk of a confidential database. In one case, the breach was actually at a third party where the data was stored for other purposes.

Now that you have validated it is indeed a breach or a suspected breach we can move on to containment. If you haven’t already done so to help identify the issues this is a good time to get the incident response team together. It might be a good time to let management know there is a potential breach that needs to be dealt with and give the privacy officer a heads up to let them know that there may be a notifiable data breach requirement. But this is all in your incident response plan…. right ?

Manage Data Breach
Having a structured approach to a security incident will help make a bad day, just a little bit easier.

 

#2 – Contain the pain

Containment of the incident is the next step in the process. It is possible that the damage has been done, true, but you still need to deal with the fact that an attacker may still be in your network and may still have access to the data. There is an argument to allow the breach to continue as it may provide you with valuable information that may allow you to better prosecute the perpetrator. To be honest, to me this is like saying “let the bank robbers get away with the money because I want to see how they make their getaway”. If you are losing PII the best response is generally to shut them out. Remember the attacker doesn’t necessarily know why they lost access. They will often assume they did something wrong.

In the identification stage you would have looked at the various logs and established how the deed occurred, or at least you’ll have a good idea. If the web logs indicate an SQL injection, perhaps remove the application, or configure a WAF to drop those requests. Maybe shut the service down whilst you identify the root cause and eradicate the issue (the next step). If it was a mail-out by a staff member, have a chat to the culprit and explain the result of their actions. So to contain the issue you may be:

  • Resetting passwords and disabling compromised credentials
  • Addressing known vulnerabilities and bugs via patching
  • Blocking network access
  • Quarantining compromised hosts or applications or shutting down systems.
  • Having some stern discussions on following processes.

Various business decisions should inform all of the above approaches, and should weigh up the harm occurring due to the compromise/breach versus the harm that could occur from shutting down systems. The decision to shut down systems that effectively shut off business operations should not be taken lightly, but may be necessary to help prevent a greater harm. Don’t forget if your systems are being used to attack others, you may be in deeper water than you first realised. Also don’t forget to communicate to management what has been happening and where things are at.

 

#3 – Fumigate, eradicate, exterminate

Once the containment has been accomplished, there is huge pressure to remove the badness immediately. However, you need to identify the root cause of the issue. During identification you had the first clues, during containment you shut them out and hopefully gained more insight. Now it is time to do some navel gazing and identify exactly the how, what and why of the issue. There really is no substitute for a thorough investigation. This is no time to take shortcuts. If you do not have the skills, consider getting some in. Getting this wrong will result in a system that is compromised over and over and over. We see this quite often when organisations miss this step or get the next step (recovery) wrong.

Identifying the root cause of the issue is paramount. Analysis should be undertaken and the path to compromise understood in intimate detail. If you can’t explain the breach in excruciating detail and don’t have a complete timeline of events (within the realms of what is possible), then the investigation is not complete. You will be under pressure to undertake the investigation quickly but resist the urge to finalise the investigation until you understand the breach and can have sufficient input for recovery. Make sure you have your facts and are as certain as you can be. Remember number 1, the issue has been contained, you are no longer hemorrhaging data.

When looking for the root cause make sure you manage your evidence, establish your timelines and identify the how and why. Was it missing patches, misconfiguration of a system, a missing firewall rule, a bad piece of code in an application, a WAF that was switched off. Creating a timeline is by far the best approach to get clarity on the events that have resulted in the breach.

Go through all the elements. On servers perhaps take a forensically sound image or snapshot. Safeguard log files. All of these can be used as evidence and help identify the how. Use the tools you have to identify the vulnerability that was exploited. It could be technical, it could be procedural. Consider deploying an incident response tool to help identify the compromised systems or malware if present.

Once you have established the how you can now devise strategies to eradicate the issue.

In the case where you have lost PII your privacy officer or committee should now have the relevant information that they need to complete their analysis on whether the breach needs to be reported or not. You will have information on:

1.  the timeframe (when did the breach start?)

2.  what systems and information has been disclosed, accessed modified or lost

3.  who has been impacted. Is the impact likely to cause serious harm

4.  are third parties involved or impacted

You may have some of the information already from the previous stages, but until the investigation has concluded you may not have certainty.

Manage Data Breach
Post-breach clean-up is vital to prevent recurrence.

 

#4 – FIX IT, once, correctly.

This is the recovery stage of the incident response process. Rebuilding systems, recovering data, patching systems, fixing the configuration to make sure the same issue does not reoccur. This step is informed and guided by the output of the previous eradication steps. Post-breach clean-up is vital to prevent recurrence. We have instances where a breach occurred in 2011, every two or three days the attackers return to test and see if the system is vulnerable again. That is a long-term game. We have seen instances where the system was brought back online prematurely and the attackers took control before all security measures could be implemented. We’ve seen organisations recover corrupted data from backups, only to be breached again because the application was not fixed.

Build it from scratch, patch it, test it, scan it, patch it again, test it again, make sure that you apply all the additional controls you identified that would have helped prevent the issues. Test it again. After all that is complete, that is the stage where the system can be put back online.

Keep in mind that during recovery, your support and administration staff are likely to remain overworked and under pressure. Implement and enforce fatigue management processes to manage workloads to ensure silly mistakes don’t creep in at this stage.

Then watch it as they will be back, remember they do not know why the system went away or they lost access to the system.

 

#5 – Notify and Prevent

The lessons learned at preparation stage is key. Once the incident is over sit down and debrief. See what should have gone better. Review the information from the root cause analysis and determine what is to become BAU and what is part of incident response. Update documentation, perhaps write a rough post-incident report and go to sleep. As soon as you are able to, complete the Post Incident Report (PIR). It provides great lessons learned, enables objective review of current processes, and provides opportunities for improvement.

From a NDB notification perspective there is still some work left to do. The NDB scheme provides clear guidelines on how to notify individuals and the OIAC (please see my earlier posts). You should follow their recommendations to the letter and meet all scheme compliance requirements.

If I put myself in the position of an individual affected by a breach. I will evaluate the breach to see if the breached organisation has made every effort to secure my personal information and sensitive data prior to the breach. I am probably going to be understanding to a point. What will matter most to me from the point of being notified, is how the organisation manages the breach, and recovery. If the recovery and management are exemplary, I am more likely to provide the disclosing firm with a degree of understanding and give them the benefit of the doubt. If the breach management is poor or slipshod, I’m taking my data and my business elsewhere.

Hopefully, you have found this post helpful and the series of blog posts on the data breach topic illuminating. If you have any follow up questions, or would like some further information on related topics, please don’t hesitate to get in contact.

 

5 things to help you prepare for the Notifiable Data Breach scheme


Following on from my last post that covered the 5 things you need to know about the Notifiable Data Breach (NDB) scheme, this post is focused on the 5 things you really must do, in order to be prepared for the Notifiable Data Breach scheme. As you will remember the NDB impacts a significant number of organisations and requires specific actions to be followed in the event of a breach. So here is a top 5:

  1. Find out whether you need to comply with the provisions of the NDB.
  2. Determine what sensitive personal information you hold, and make a determination of what the following terms mean to you and your organisation:
    a. likely to ‘occur’
    b. ‘serious harm’.
  3. Prepare a step by step process of what you need to do in the event of a breach.
  4. Educate your stakeholders.
  5. Run a practice drill.

1.  Find out whether you need to comply with the provision of the NDB Scheme

This task should be the simplest of the 5 things you need to do. A good starting point is provided in my previous blog post, but if you are in any doubt, please refer to the Office of the Australian Information Commissioners website.

If you are covered by the scheme and need to comply, and haven’t already started on your NDB compliance journey, I’d suggest you need to initiate some internal conversations. If necessary engage some external expertise.

Even if you don’t need to comply, the investment you make in preparing a breach process will not be wasted.

2.  Determine what sensitive personal information you hold

This task may actually sound a little easier than it is for a large number of organisations. Unfortunately, many organisations have a very poor understanding of their information assets, what is important to them, and what information they need in order to run their business. If sensitive information is not understood, you may be capturing, storing or processing more sensitive information than you need to.

You should also consider, where that sensitive information is stored. Long gone are the days when you could safely say that all my data is on my big file server in my data centre under lock and key. When you really look into where sensitive personal data is stored, you are likely to find that it is located on multiple servers and applications, SAN devices, laptops, iphones, USB sticks, on your backups media, on SharePoint, OneNote, DropBox, and in a myriad of other cloud and/or shadow IT environments.

The next consideration needs to be who has access to the sensitive personal information you possess. Questions to consider include: Do you outsource functions, systems or operational tasks. Are you storing data entirely within Australia, or are you working offshore and around the Globe. Do your partners know that you have an NDB obligation. What is the state of your information supply chain, and where are you exposed. In fact, the legislation does recognise that organisations can jointly hold personal information, and has made provisions to avoid duplicate obligations.

Only once you have a full appreciation of what information you hold custodial responsibility over, where it is, and who else has access to it, can you make a determination and a judgement on what is ‘likely to result in serious harm’.

As with most approaches to information security and privacy matters, a solid understanding of risk management in terms of likelihood and consequence should be leveraged to inform the conversation around the serious harm question. The implementation of the NDB scheme effectively raises the bar on expectations from a risk management perspective.

 

Security News and Alerts

Get updates and exclusive content from our security experts
  • This field is for validation purposes and should be left unchanged.

 

3. Prepare step by step process of what you need to do in the event of a breach

After you have undertaken an information asset inventory and understood what sensitive personal information you have, where it is and who has access to it, you need to prepare for a breach by developing a breach response framework. The framework should include:

  • A process that provides:
    • Identification, investigation, validation and containment rules
    • Clear authority to initiate an investigation and declare a breach
    • High-level resolution guidelines and plans
    • Permitted timeframes for each phase of the breach
    • Communications protocols internally including a clear RACI model
    • Key contacts both within your organisation and with specialist external parties to assist with investigation and resolution where required
    • Plugs in to your work health and safety policy to help manage fatigue
  • Notification protocol for individuals affected. There are proforma’s available and these can be leveraged rather than invented. The information provided that relates to the breach should include:

    • the date, or date range, of the unauthorised access or disclosure
    • the date the data breach was detected
    • the circumstances and or known causes of the data breach
    • who has obtained or is likely to have obtained access to the information
    • the steps undertaken to contain or remediate the breach
  • Options for notifying individuals include:

    • Notify all individuals impacted
    • Notify only individuals who are at likely risk of serious harm
    • Publish your notification, and publicise it to bring it to the attention of individuals at likely risk of serious harm
  • Notification protocol for the OAIC. Again, proforma’s exist that can be used. Items required to be provided in the notification to the OAIC include:
    • Contact details for your organisation
    • A description of the data breach
    • The kind of information involved in data breach
    • The steps you recommend for impacted individuals in response to the breach

4. Educate your stakeholders

Without appropriate education and guidance, responsibility for everything during a breach may fall on you – the reader of this blog! Each stakeholder must know their roles and responsibilities and must be able to operate autonomously and as part of a team when it comes to managing a breach. An internal education activity is definitely something that you should undertake as a priority after your preparation activities. But don’t forget step 5. Knowledge helps, but nothing makes that knowledge stick like having stepped through the protocol at least once.

5. Running a practice drill

As the old saying goes, practice makes perfect. Running a breach practice drill doesn’t have to be onerous or take massive amounts of time to prepare. Although the more you plan and the more often you can practice, the better off you will be. As a first step, prepare some meaningful scenarios, book a meeting with relevant stakeholders, establish some ground rules and run through your established breach process for each of the practice scenarios. Appoint a note taker who will observe and record variations to the process flow. Initially, stick to the process that you have designed, but annotate any issues. Then roll those lessons learned into a second iteration of your NDB process.

Then keep practicing. Perhaps utilise your regular business continuity and disaster recovery drills as a vehicle to test your NDB processes.

The 5 things you need to know about the Notifiable Data Breach scheme


Mandatory Data Breach Disclosure and the Notifiable Data Breach (NDB) scheme are both really hot topics at the moment. There is a number of experts from the legal, cyber security and business community all providing their advice, many providing guidance in forensic detail on what should be done to prepare an organisation for this change.

I’m not planning to cover NDB in detail, the aim of this blog post is to quickly and succinctly outline the 5 most important things you need to know about NDB scheme within Australia.

Essentially, the why, what, when, who, and which of NDB. I’ll follow with a number of additional posts designed to provide practical guidance for organiations on this topic.

Why NDB?

With the prevalence and increased impact of data breaches on the news and in our lives, there is a greater need than ever for a consistent treatment mechanism. The absence of any industry consensus on data breach notification meant that it was only a matter of time before the Government put in place a scheme to protect the interests of consumers, and individuals.

After extensive industry and professional consultation, the Notifiable Data Breaches (NDB) scheme was passed under Part IIIC of the Privacy Act 1988 (Privacy Act).

What is the NDB?

The Notifiable Data Breaches (NDB) scheme establishes a framework governing how data breaches are assessed and responded to, and the obligations of organisations in reporting breaches.

Specifically, the NDB introduces obligations for organisations who experience a data breach that exposes personal information and meets the criteria specified as likely to cause ‘serious harm’. More on what constitutes ‘serious harm’ in a moment.

Any breach notification must include recommendations for impacted individuals on the steps that they should take as a result of the breach.

The NDB also specifies that the Australian Information Commissioner must be notified of eligible data breaches.

When does NDB come into effect?

The NDB comes into effect on the 22nd of February 2018.

Who does the NDB impact?

Unless you live entirely off the grid and share no personal information, ultimately, the NDB affects us all.

Whilst not an exhaustive list, with some exceptions, a good summary of the organisations that are impacted by the NDB include:

  • Australian Government agencies
  • Businesses and not-for-profit organisations with an annual turnover of $3 million or more
  • Credit reporting bodies
  • Credit providers:
    • banks, building societies, credit unions, finance companies
    • retailers who issue credit card
    • organisations where payment is deferred for at least 7 days – telco’s, energy and water utilities
    • organisations that provide credit for hiring, leasing or renting goods
  • Health service providers
  • TFN recipients, which likely impacts State Government entities if they use TFN’s

An important thing to note is NDB applies to overseas organisations that have been incorporated or formed in Australia.

Which breaches are covered by the NDB?

In broad terms a data breach is defined as either: unauthorised access; unauthorised disclosure; or loss of personal information. The type of personal information covered includes:

  • An individual’s health information or other ‘sensitive’ information
  • information used as a precursor to identity fraud (Medicare card, driver licence, and passport details)
  • financial information
  • a combination of types of personal information.

As with all legislation, the devil is in the detail. This information does not seek to be exhaustive, and the usual legal disclaimers around seeking professional legal advice do apply.

The Office of the Australian Information Commissioner (OIAC) states:

The NDB scheme only applies to data breaches involving personal information that are likely to result in serious harm to any individual affected. These are referred to as ‘eligible data breaches’. There are a few exceptions which may mean notification is not required for certain eligible data breaches.

What does all this mean? The terms ‘likely’ and ‘serious harm’ are key.

  • ‘Likely to occur’ means more probable than not/possible
  • ‘Serious harm’ may include serious physical, psychological, emotional, financial, or reputational harm to an individual

These terms are subjective and require some assessment against the so called ‘reasonable person’ test. Harm can include: loss of business or employment opportunity, damage to a person’s reputation, relationships; humiliation; identity theft; significant financial loss; threats to physical safety; and workplace or social bullying or marginalisation. The circumstances of the breach is also an important factor.

The stated exceptions are interesting, because if an organisation acts quickly to remediate a data breach, and as a result of their quick response the impact of the data breach reduces the breach to something less than what is termed serious harm, then there is no requirement to notify any individuals or the Commissioner.

Hopefully you have found this blog useful to set the scene for NDB. I’ll be following up with an additional series of posts on how to prepare for NDB, what is important during a breach and how your organisation can be prepared.