[BreachExchange] GDPR: What will happen in the first 72 hours after a data breach?

[Audrey McNeil]

https://www.computing.co.uk/ctg/news/3019682/gdpr-what-
will-happen-in-the-first-72-hours-after-a-data-breach

While the countdown began more than a year ago, it's only now that many
organisations are preparing in earnest for GDPR - with the EU regulation
coming into full force in just eight months.

Many are still unprepared for GDPR and the CIOs and CISOs at most
organisations don't believe they will be fully prepared in time, leaving
them open to fines of up to €20m or four per cent of revenue.

Yet, for organisations with limited IT security resources - and sometimes
only employing security staff part-time - the most pressing concern is
often around the reporting timeline itself, and whether it is even possible
for them to detect and report a data breach within 72 hours.

To help with this dilemma, let's break down the practical steps involved in
dealing with a breach, and propose a rough order in which to tackle them.

Preparation

By far, the most important step in meeting GDPR requirements is to lay the
groundwork, and ensure that your organisation has put all the necessary
policies and procedures in place well before May 2018, and also documented
them, so that it can demonstrate the steps it has taken to achieve
compliance.

Realistically, it is only if you have these systems already set up that you
will be able to react quickly enough to hit the 72-hour deadline.

The first step is to identify and locate your organisation's assets. In
terms of GDPR, this means understanding where your customer data is stored,
or could be accessed, including when it is used and processed by cloud
applications.

It is also important to identify how your organisation stores and uses
customer records, such as the information acquired when a customer signs-up
for a mailing list or fills out a form to download a white paper.

The next step is to set up security alerts that will warn you if there are
any potential risks to this data. Security teams often complain about being
bombarded with these sorts of alerts, but after next May, there will be no
excuses for missed alerts or mistakes.

To help cut through the noise, alerts can be grouped by assets, such as
people, and those involving customer data could be labelled as relevant to
GDPR. This will help you to spot more quickly when a breach has occurred
and save you valuable time when you need it.

Another aspect of preparation is to clarify the reporting procedures that
your organisation will use to inform shareholders, customers and regulators
about a potential breach. For this process to work effectively, it's vital
to have communications, legal and management teams looped in and briefed in
advance, so that they are ready to work together.

Such preparations should include drafting a blog and letter template, and
clarifying the process for sharing these communications to the public so
that everyone is clear on their responsibilities in the event of a breach.

Indeed, the public response to a data breach should now be part of any
disaster recovery planning if it isn't already.

The clock starts ticking

Provided that you have set up security alerts as outlined above, and
monitor them carefully, you should be notified almost immediately when a
data breach occurs. In the immediate aftermath of an attack, your primary
focus should be on containing the incident by isolating the affected
systems to prevent further damage. If you can identify some of the elements
that contributed to your breach, such as an individual laptop, then you can
take that section off the network and do some forensic analysis.

Once you've contained the incident, you need to find and eliminate the root
cause. Attackers may have used a specific vulnerability such as HeartBleed,
sent a phishing email, or cracked a weak password - but to undo its
effects, you will probably need to remove the malware, and then wipe and
reinstall affected machines.

The deadline looms

Once you have a decent understanding of the breach, you must involve the
legal, communications and management teams within your organisation.
Together, you must identify the level of risk to the customers or clients
that might have been caught up in the breach.

If it is likely to result in a high risk to the rights and freedoms of
individuals - such as the compromise of hospital records - you must notify
those people concerned directly, as well as notifying the relevant
supervisory authority.

Any breach notification should include:

- The approximate number of individuals affected by the data breach;
- Details on the type of personal data records concerned;
- The name and contact details of someone within your organisation who can
provide more information;
- A description of the likely consequences of the breach for individuals;
and,
- The measures taken (or proposed to be taken) to mitigate it.

These communications will need to be drafted (based on the earlier
templates), approved by management tiers, and then distributed to your
customers, shareholders and regulators. In the case of a significant
breach, this communication will likely trigger an avalanche of incoming
calls from worried customers, interested parties and the media.

The aftermath

While it's relatively easy to identify and contain a data breach within 72
hours, it can take significantly longer to fully eradicate and recover from
the incident.

Reinstalling and recovering from back-up could take several days, depending
on the amount of data involved and the testing required to make sure that
systems are working successfully. During this recovery process, affected
systems can gradually be put back onto the network, but it's vital to keep
a very close eye on them and monitor for any errors.

The final important step is to review and analyse what happened, work out
why it happened, and consider how such a breach could be prevented in the
future.

Unfortunately, security breaches are so common that it is really a case of
when rather than if a breach will occur, but understanding how an attack
took place and learning lessons from it can help an organisation improve
its overall security posture.

Finally, it's important to share technical information about the breach
among your peer group and threat-sharing sites, so that the wider community
can prepare their systems to detect similar attacks - and you, likewise,
can learn from their experience, too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20171024/dae8e218/attachment.html>