Cyberdemocracy

This week I went to an event aptly dedicated to “Cyberdefense and cybersecurity”. These topics are fashionable and for good reasons.

The cyber suffix is more and more a reality and needs to enter our lexicon fast. Otherwise, we will soon be swept over by a world under a not so bright new order.

Beyond the obvious fears and calls to action, I captured these, starting from the one I think we all can do something about it:

• Education – Surprise! Everyone, and especially the youth, as to step up on their awareness for the cultural and democracy shift brought by the post-Internet world. I place my bet here for informed people are wiser. Here’s one free online introductory course. Cybersecurity education resources can be found too.
• Regulation – A need for a net of cooperation institutions from all sectors to bring order to the new wild west. Or face being ruled by big corporations as nations sovereignty keep declining. There’s hope from the UK. Also,  an informative report from ENISA.
• Artificial Intelligence – Like other disrupting technologies, it did not bother knocking first before entering our lives. Really fast. It is already being used for cyberattacks.

 

GDPR – Data breach reporting

For this third post on GDPR, we will cover the who and what of data breach reporting obligations. It is a good candidate for building up on existing event and incident activities.

The definition of a data breach within GDPR is:

“Data breach” means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed. – Art.4(12)

In case of a personal data breach, the controller shall without undue delay, and where feasible, no later than 72 hours after becoming aware of it,  notify the personal data breach to the competent supervisory authority.

The GDPR details mandatory information to be included in the personal data breach notification (check what items comprise that mandatory information at the end of this post).

Regarding timing and completeness of the notification, Recital 85 states: “Where such notification cannot be achieved within 72 hours, the reasons for the delay should accompany the notification and information may be provided in phases without undue further delay.”

This obligation applies only when the data breach may result in a risk to the rights and freedoms of natural persons I suggest you double check those rights and freedoms with legal. Even better, ask the supervisory authority.

Retaining wall breach – by Hefin Richards

Furthermore, the processor shall notify the controller without undue delay after becoming aware of a personal data (the Regulation does not enforce a hard deadline for the processor to controller notification).

Beware that, for the first time, the processors will also now be subject to penalties and civil claims by data subjects.

Operationally, for all this to work, a prior assessment of the impact of processing operations on personal data will provide reliable criteria for which and when to notify data breaches (also, that assessment – known as a Data Protection Impact Assessment  in GDPR  – pinpoints what needs to be monitored for breaches).

What about the affected data subjects?

The controller should, as soon as reasonably possible and in close cooperation with the supervisory authority (for instance, prompt communication for if there’s an immediate risk of damage), communicate to the impacted data subjects:

• the nature of the personal breach
• recommendations for the natural person concerned to mitigate potential adverse effects.

Data breaches must be documented

The controller must document any personal data breaches (what happened, effects and remedial action taken). This documentation shall enable the supervisory authority to verify compliance with the data breach notification GDPR article 33. Clearly, there’s a need for people and a management system to support it (both may currently exist in the organization, due to other information security requirements).

Piggybacking on existing practices

If the organization already has procedures for handling information security incidents, then they should be reviewed for specific treatment of the personal data ones, including how to properly documenting them should supervisory authority (or legal authorities) demand it, how to notify the supervisory authority, and getting processor data breach notifications.

From CNIL, the French supervisory authority, Notifications d’incidents de sécurité aux autorités de régulation : comment s’organiser et à qui s’adresser ? provides guidance on notification of security incidents.

Where to start?

Being compliant with what GDPR regulates for data breach notification has a significant impact on organizations, including raising awareness on handling data breaches; procedures for detecting, documenting and notifying data breaches; reviewing and checking on third party entities processing personal data for your organization; communication with both supervisory authority and the data subjects.

Introducing these changes costs money, you will need to build a business case towards a data breach reporting initiative in order to secure funds. Consider this:

Personal data breaches seem to be more damaging to companies than other security breaches.

Campbell et al. (2003) found that security breaches in which personal data was accessed had a significant impact on a company’s stock market valuation (please check References below for source). People relate more with personal data security breaches (“Hey, that could have happened to me!”).

Next post will tackle the reason why GDPR exists: individuals’ rights.

References

Art. 33 GDPR Notification of a personal data breach to the supervisory authority (Recitals 85, 86 and 87 are relevant for further clarification)

Karyda, Maria & Mitrou, Lilian. (2016). DATA BREACH NOTIFICATION: ISSUES AND CHALLENGES FOR SECURITY MANAGEMENT.

Annex – What’s goes into the data breach notification?

The notification shall at least include:

• the nature of the personal data breach including where possible: the categories of data subjects and approximate number of data subjects concerned, and the categories and approximate number of personal data records concerned;
• the name and contact details of the data protection officer or other contact point where more information can be obtained;
• the likely consequences of the personal data breach;
• the measures taken or proposed to be taken by the controller to address the personal data breach, including, where appropriate, measures to mitigate its possible adverse effects.

GDPR – Privacy by design (PbD)

Privacy by design (PbD) is meant to tackle privacy throughout the whole cycle of activities that together allow an organization to handle personal data for their purposes.

The intention is to invest sooner in privacy thus reducing untimely measures to fix personal data misuse.

A brief lookup on the topic will bring up the goal of having privacy by design done to such extent that you actually won’t need to protect personal data at all (because there won’t be any left). Also, there’s some criticism about PbD vagueness. This stems from its origin as a set of principles as we will see next, which to me is a good sign in favor of its usefulness.

The principles

It started in Canada, with Anne Cavoukian, the former Information & Privacy Commissioner of Ontario, and her Pbd principles, known as the Ontario model:

1. Proactive not Reactive; Preventative not Remedial
   Focus on anticipating privacy risks.
2. Privacy as the Default
   Individuals should get maximum possible privacy by default.
3. Privacy Embedded into Design
   Privacy by Design is an explicit part of design and architecture of IT systems and business practices.
4. Full Functionality – Positive-Sum, not Zero-Sum
   The goal is to have full functionality, not using security as an excuse for less.
5. End-to-End Security – Lifecycle Protection
   Secure lifecycle management of information, right from the instant information enters all the way up until is no longer needed.
6. Visibility and Transparency
   Both users and providers can check on how PbD is achieved.
7. Respect for User Privacy
   Users first. Meaning strong privacy defaults, appropriate notice, and empowering user-friendly options.

Whenever we go for principles, actually doing it is not immediate – that’s the point (because, hey, they’re generic and meant to keep in mind – not operational, rather supporting operational decisions).

To focus our initiative we can piggyback on data mapping and privacy impact assessments. These are opportunities to identify the parts where there’s a need to intentionally introduce privacy by design.

Privacy by Design moments of truth

The ICO gives concrete examples where privacy by design should be considered and applied. Specifically,  contexts where things change. Both from inside and outside:

• Building new IT systems for storing or accessing personal data
  • This can be done through a change management process though you may find a better source whenever a funding request comes for new IT systems (or cloud services around your customers).
• Developing legislation, policy or strategies that have privacy implications
  • Make PbD part of the checklist of topics to check.
• Embarking on a data sharing initiative
  • Remember sharing data has never been so easy.
• Using data for new purposes
  • Look out for requests coming from marketing and sales; they know the business, you better know its impact (and express it in such a clear way your family would be proud).

Simplify

Like with security in general, by embedding checks in the right moments we can go a long way without too much extra work. Take these ways to simplify as a starting point in your PbD journey:

• Data minimization – Collect only what you need.
• Purpose limitation – Only use personal data in the way you have permission to, and only if necessary.
• Retention limitation – Don’t store it longer than necessary.
• Early consideration – Incorporate privacy at the thinking stage of a development life cycle, before doing anything.
• Start where you are – Use what you have right now.

As with other efforts, it’s sensible to embed these in existing processes and procedures, which include project management, development, and support codified practices (it’s easy to change existing organizational habits than introducing new ones, wouldn’t you agree?).

Next post I will go for breach notification (and yes, GDPR has fines for this too).

 

On security for IT services

Security by Loopzilla at flickr - some rights reserved

[from: http://www.flickr.com/photos/loopzilla/2073400408/]

How should one go about regarding security for IT services?

One can look at it taking in account the service lifecycle approach from ITIL and concentrate on the Design phase, when we can invest early in order to achieve that honorable goal of having the minimum (avoidable) surprises and rework when service finally goes live. In other words, reduce operational costs by designing services right.

Some ideas (in no particular order):

1. Ensure external partners and suppliers that contribute to the services know and formally agree to their responsibilities (Underpinning Contracts)
2. Also get internal groups/teams formally agree on their responsibilities (Operational Level Agreements)
3. Changes to the services must include security impact assessment
4. A procedure for receiving and acting on security vulnerabilities reported from vendors of components that support the service
5. Include an explicit security section regarding security requisites in the initial analysis phase for new or changed services
6. Link the security requisites to service level targets so the SLA covers them
7. Check those requisites with customer when feasible (or at least with yourself if you’re a good candidate for using the service)
8. Make sure security tests are covered in the test plan
9. Then, while transitioning the service, perform the security tests
10. Have experts trying to break your service from outside and inside
11. Use the tools. There are technical tools and best practices you can apply thus avoiding reinventing the wheel or forgetting important checks
12. If a security incident happens is it clear for everybody who must be involved and what to do?

Yes, some of these will happen in the Transition and Operation phases even though their planning occurs before.

Love to hear about more ideas!

Mush and Room #9: Security and C.I.A.

Security and C.I.A. (secrets between Mush and Room)