Technical and Organisational Measures

GDPR: Reporting Your “Technical and Organisational Security Measures”

You could almost be forgiven in thinking that words/phrases like; ‘pseudonymised’, ‘anonymised’, ‘access control’ or ‘encrypted’ are all that is required when reporting your technical and organisational security measures for Article 30 – Records of Processing Activities.

Almost.

Continue reading
GDPR Certification

What Will GDPR ‘Certification’ Look Like?

From my current perspective, these are the 3 most significant unknowns in the implementation of GDPR:

  1. The appropriateness of Privacy Shield (i.e. it’s not);
  2. What will ‘Representation’ look like (per Article 27); and
  3. What will ‘Certification’ look like (under Articles 42 & 43)
Continue reading
GDPR Fines

GDPR and Cybersecurity, a Very Limited Partnership


If a security vendor has ever told you that the GDPR is imposing fines of up to 4% of annual global revenue for data breaches, they are either:

  1. ignorant of the standard; and/or
  2. lying to you.

Being generous, they may not actually know they are lying, the General Data Protection Regulation (GDPR) isn’t exactly easy to decipher, but even a cursory review tells a rather obvious story. I will attempt to address the following assumptions in the course of this blog:

  1. The GDPR is >95% related to enforcing the RIGHT to privacy, not the LOSS of privacy through data breach;
    o
  2. The maximum fines for ANY organisation are 2% of ‘annual turnover’ for even the most egregious loss of data through breach, not 4%; and
    o
  3. Fines are entirely discretionary, and an appropriate security program will significantly reduce any fines levied.

Wait, there are 2 types of privacy!?

Ask a lawyer in the EU what privacy is and s/he’ll likely quote Article 12 of the Universal Declaration of Human Rights: “No one shall be subjected to arbitrary interference with his privacy, family, home or correspondence, nor to attacks upon his honour and reputation. Everyone has the right to the protection of the law against such interference or attacks.

From a GDPR perspective, this equates to two of its three fundamental aspects. Grossly simplified these are:

  1. Explicit consent; and
  2. Legitimacy of processing.

In other words, the vast majority of the GDPR is concerned with obtaining explicit consent for the personal data collected, and then ONLY using that data for legitimate purposes in-line with the consent received.

Even when GDPR refers to ‘security’, it is more concerned with these two fundamentals than it is with security of the data itself. That is what they mean by “security of processing“.

However, from a cybersecurity professional’s perspective – and the third fundamental aspect of the GDPR – privacy also involves loss. i.e. The data was stolen during a breach, or somehow manipulated towards nefarious ends. This is a very important part of the GDPR, Hell, it’s a very important part of being in business, but it should never be used to sell you something you don’t need.

Maximum fines?

Of the 778 numbered or lettered lines of text in the GDPR Articles section, there are only 26 that relate directly to data security (or 3.34%). These are contained within Articles 5, 25, 32, 33 and 34.

Per Article 83(4)(a) (a.k.a. ‘2% fines’) – “(a) the obligations of the controller and the processor pursuant to Articles 8, 11, 25 to 39 and 42 and 43;

While Article 5 is contained within Article 83(5)(a) (a.k.a. ‘4% fines’), all but one line refers to security of processing, not the security of the data.

So, if it can be assumed that if the maximum fine for ANY data breach, no matter how egregious, is 2% of the annual revenue from the previous year (in the case of an undertaking), that 2% is what the EU considers the maximum for a fine to qualify as “effective, proportionate and dissuasive” (per Article 83(1)). Therefore, a fine of €10,000,000 would be reserved for any organisation with revenue over €500,000,000 annually. Fines are never there to put you OUT of business!

It must follow that if 2% is the maximum, then fines will go down the less egregious is your offence. Everything you need to determine the level of ‘egregiousness’ is contained in the 11 lines of Article 83(2)(a) – (k). Words like ‘intentional’, ‘negligent’, ‘degree’, and ‘manner’ are bandied around, all of which can be answered by you.

In this spreadsheet, I have taken a stab at adding specific questions to each of the (a) – (k) line items. Answer them all truthfully and you’ll get an indication of what I consider to be an appropriate fine based on your annual revenue: GDPR Fine Worksheet. Caveat: I am NOT a lawyer, and this is based entirely on my own experience, not anything resembling known fact.

Finally, bear in mind that as per Article 58(2), there are many ‘corrective powers’ that a supervisory authority can resort to long before levying a fine, including simple warnings (Article 58(2)(a)). Fines should be considered as a worst case scenario in their own right, let alone the amount.

Appropriate security program?

There is no such thing as 100% security, so the more you can demonstrate that your security program is appropriate to the levels of risk, fines should be the least of your problems. As long as you have everything from senior leadership buy-in, to incident response, to disaster recovery and breach notification – you know, the basics! – it is not a foregone conclusion that fines will even be considered.

Go here for more on what a security program should look like: What is a Security Program?

In conclusion…

In the UK, if you are an organisation that processes personal data and you were already a) complying with the Data Protection Act (DPA), and b) doing security properly, GDPR compliance would require only relatively minor adjustments. For those that weren’t, you have a lot of work to do now once the supervisory authority has the powers that GDPR bring to bear, and not much time to do it in (May 25, 2018).

That said, don’t do anything for compliance alone. Do it for the business, do it properly, and compliance will fall out the back end. So while it is reprehensible that security vendors are trying to exploit the GDPR for profit, if you fall for it it’s entirely your fault.

By the way, if you’re a business that is predominantly centered around the processing of personal data, the Article 58(2)(f) – “to impose a temporary or definitive limitation including a ban on processing;” can take you offline indefinitely. And yes, you can be fined on top of that.

I hate to say it, but don’t do anything until you’ve spoken to a lawyer.

[If you liked this article, please share! Want more like it, subscribe!]

ISO 27001 Certification

How to Begin Your ISO 27001 Certification Project


There are many consultants with significantly more ISO 27001 experience than I have. And type “how to begin ISO 27001” into Google and you’ll get ~8.2 million hits. So what makes me think I can do any better?

Actually, I not saying I can, but I am saying that my style of consulting seems to be conducive to getting such difficult projects off the ground quickly. Or at all for that matter. No security project is more difficult that implementing an ISMS.

In last week’s blog; ISO 27001 Certification, Is It Really Worth It? I stated that the top 5 reasons that ISO certification projects fail are:

  1. Grossly underestimating the level of effort;
  2. Doing it just to land a big contract (or for marketing purposes);
  3. Tying the certification to an overly aggressive deadline;
  4. Ignoring the expert help; and
  5. Having no business goals in mind.

It follows therefore that to make certification a success, you must overcome these challenges at a minimum. Sadly, nothing I say from this point point forward will be in any way new. Some of what I have to say has been said dozens of times by me, and thousands of times by my peers and betters.

The Challenges

  1. Grossly underestimating the level of effort – Symptomatic of one thing; asking the wrong questions. If you had asked the right people the right questions you would KNOW just how difficult an ISO certification project is. No certification should be undertaken lightly, but there are more than enough ISO experts out there to make the level of effort abundantly clear.
    o
  2. Doing it just to land a big contract (or for marketing purposes) – While I can empathise with this one, allowing what amounts to greed to provide the entire impetus for something that requires a fundamental shift in culture is naive at best. The promise of a big contract can, and often does, provide the initial business case for ISO certification. But to then focus entirely on doing just enough to land that project is a total waste of time and effort. Many good consultants will rightly walk away from such projects. It’s our reputation too.
    o
  3. Tying the certification to an overly aggressive deadline – Usually an extension of 2 above, and will invariable derail the project before it begins. If all you’re focused on is a looming deadline, nothing will be done properly, nor will it be sustainable. Remember, ISO certification requires 6 month health checks, an unsustained ISMS will result in the removal of your certification. Quite right too.
    o
  4. Ignoring the expert help – You don’t go to the doctor and tell them you have a brain tumour. You tell them you have a headache and let them do the rest. So why would you hire an ISO expert them argue with every step of the way just because you don’t like what you hear? A good consultant will not ask you for anything they already have, or they do not need, so either do the work or stop the project if it’s too much.
    o
  5. Having no business goals in mind – Contracts, even very large ones, are not business goals, they are a means to achieving a business goal. Done correctly, an ISMS can enable almost every goal you’d care to mention. Done correctly. Before you begin your project, find out what your CEO’s goals are and map the ISMS efforts to them. Miss this step and you will fail every time.

I use the word ‘recommend’ very carefully, but I HIGHLY recommend that you put all the relevant stakeholders through a 1 day ISMS training session to set the scene. Without this context, you will have no support.

If the CEO can’t even make an appearance at this session, that will tell you all you need to know about how your project is going to go.

[If you liked this article, please share! Want more like it, subscribe!]

Security Core Concept 1: Risk Assessment / Business Impact Analysis


This begins a series of posts related to my theory of The 6 Security Core Concepts. I am assuming that The 4 Foundations of Security are either already in place, or at least being addressed in parallel.

So, in terms of cybersecurity, what is a risk assessment? According to Wikipedia it’s; “…the determination of quantitative or qualitative value of risk related to a concrete situation and a recognized threat.”

NIST SP800-30 Revision 1 states; “Risk assessments are used to identify, estimate, and prioritize risk to organizational operations (i.e., mission, functions, image, and reputation), organizational assets, individuals, other organizations, and the Nation, resulting from the operation and use of information systems.”

Great David, now what? I know what a risk assessment is, I just don’t know how to do one!

There are 5 golden rules of conducting a risk assessment;

  1. Get Management Buy-In – I know, surprising huh?;
    o
  2. Agree on the Scope – region, department, business line, compliance regulation etc. Keep it simple or you’ll never finish;
    o
  3. Agree the Methodology & Deliverables – whether you use something based on methodologies such as NIST or OCTAVE, or a combination of many, agree the method up front and stick to it for ALL of your risk assessments;
    o
  4. Agree the Timeframe – from the beginning to the delivery of the results stick to the agreed timeframe, even if you’re not finished.
    o
  5. Get Started! – don’t get caught in ‘analysis paralysis

Once these are agreed, start your interview process, and again, don’t over-complicate this. Each department is going to have a different take on what’s important, and it’s not your job – yet – to argue priorities. You simply ask them what they consider to be the major threats to the business (from their perspective), and what is the likelihood of that threat being realised.

Bear in mind, this will not just be IT threats – IT does not corner the market – but it IS a big chunk of them; malware, data theft or other loss, network outage, Internet outage, server crash and so. That said, even such concepts as operational resilience have a majority foundation in IT systems, so that’s why the IT department have traditionally – and incorrectly – owned this process (if it exists at all).

Done correctly, the risk assessment will be driven by the Governance Committee (Core Concept 4), and have equal input from both the IT and the business sides. If not, it won’t have the management buy-in I go on so much about.

Once the data is collected, it must be put into some kind of perspective. This is where the words quantitative and qualitative come into play. Only very mature risk management processes should attempt quantitative, it’s simply too difficult for most organisations. Qualitative allows for better adoption by non-technical personnel, and will most likely speak better to the immediate needs of the business; i.e. reducing risk.

Assuming you’ve chosen qualitative, you must still put some value on the identified risks; 1 -5, 1 – 100, high-medium-low etc., as well as some indication of its likelihood of occurrence. For example; a planetary implosion would be catastrophic, but VERY unlikely. The payroll server going down has much less impact, but will occur more often, so should be the priority in this ridiculous example.

Now that you have your risks ranked in terms of impact and likelihood, you need to put some kind of monetary value on each in order to put the final prioritisation against it. It is VERY difficult to put $/£/¢ values against these risk rankings, but unless you do, you can’t prioritise, nor can you set the baselines required in your operational resilience (OR) / incident response (IR) / disaster recovery (DR) plans.

For example, if your e-commerce sites makes 100% of your revenue downtime is not an option. Therefore you not only need full redundancy in your systems and apps etc, and real-time monitoring of system health, you also need extremely robust SLAs against your 3 party vendors (hosting facilities etc.). Only this will ensure that both IR and DR processes are in line with your Business Continuity Management (Core Concept 6) plans.

You have those, right?

If it is determined that the risk is just too great for the organisation to stomach, you will move on to the next step in the process; Security Control Selection & Implementation (Core Concept 2). You will start by performing a gap analysis of your infrastructure to see where the gaps are between your current capability, and the agreed standards accepted by management in the risk assessment phase.

The purchase of technology is always the LAST resort! Business process review is the first, enhancing the capability of existing infrastructure is the second. Rushing to throw technology at gaps can lead to bigger problems as I have suggested in Insecurity Through Technology.

One of the themes I have running through my posts – other than the terrible grammar – is the concept of how not knowing where to start often leads to organisations doing nothing at all. As in every other instance, the way to avoid this issue is to ask the people who DO know. A good consultant will not only be able to help you design a risk assessment methodology for your organisation, they will be able to teach you to run it yourself. Remember, the role of your consultant is to teach, not just do.

Finally, like every other business process, the risk assessment methodology should be standardised across the enterprise so that the results are compatible with the business culture and comparable against each other. However, they should also be reviewed at least annually, or after significant organisational, change for continued suitability. As your organisation changes and adapts to the future business environment, so must your risk assessment keep up in order to stay relevant, and useable.

This post is not meant to tell you how it’s done (there is an infinite variety of risk assessment methodologies), but to ease the confusion that is still prevalent. Hopefully I have done that enough that you at least begin to ask the right questions.

Like all security, the risk assessment is simple, not easy, but simple.

To summarise;

  1. Don’t do ANYTHING until you’ve conducted a risk assessment, and this includes starting your PCI compliance project (if applicable). This is beginning of all security, and the initiation of all future business plans;
  2. Don’t over-complicate it, just choose your target, set a time goal and stick to it. Whether you are finished or not isn’t important, you can always get back to it later and reducing your risk as soon as possible is more important;
  3. Get an expert in the first time, learn from them;
  4. Don’t BUY anything until you know where it fits in, and how you’re going to manage it; and
  5. Unless the solutions you choose costs well under the estimated value of the data, don’t buy them, it’s career limiting.

[If you liked this article, please share! Want more like it, subscribe!]