Welcome to NBlog, the NoticeBored blog

The blogging will continue until morale improves

Jul 20, 2019

NBlog July 20 - what is the ISMS for?

Another interesting morning on the ISO27k Forum when a new member asked for help to address an ISMS internal audit finding relating to ISO/IEC 27001:2013 section 4.1: 

“The organization shall determine external and internal issues that are relevant to its purpose and that affect its ability to achieve the intended outcome(s) of its information security management system.”

To my beady eye, that succinct sentence (plus the rest of clause 4 and more besides) leads-in to a fairly diverse and creative set of activities relating to ‘establishing the context for the Information Security Management System’:
  1. Who are the stakeholders with an interest in the organization’s information and hence the associated risks and opportunities? What are their 'issues' - their interests, in fact? What matters to them? What are their priorities and concerns? What business is it of theirs? [Clause 4.2]
  2. Consider the organization’s purposes (business objectives/goals, strategies and other drivers and constraints) that in some way involve or drive information risk and security e.g. if “Being a trusted partner” is one of the corporate aims stated in the CEO and Board’s mission statement, that indicates a need to be a trustworthy organization, and hints at a desire to be recognized and appreciated and valued as such by business partners/outsiders. So what are the implications on how we do business, in particular how we handle information?  What should the ISMS be doing (or indeed avoiding) in support of "being a trusted partner"?
  3. Consider also how information risk and security concepts can/should support and enable the business. For instance, what is management’s position on privacy – not just the obvious legal and regulatory compliance aspects but privacy, personal space, personal choice and freedoms etc. as a more general concept? What about, say, the ‘integrity’ part of the CIA triad: in what ways is integrity relevant and potentially necessary or valuable to the business? And what about information risks: how will the ISMS help manage those? What will the ISMS bring to the game that couldn't be done as well without it?
  4. Elaborating on that concerning the ISMS itself, what is it expected to achieve for the organization? How will a [certified] ISMS earn its keep across all of those areas – how will it make that easier, better, cheaper etc., more than offsetting the costs involved in establishing, operating and maintaining the ISMS? What are the priorities? In hard-nosed business terms, where’s the financial value in going down the [certified] ISO27k ISMS route when there are many alternatives, some of which might not be possible or might be delayed if finite resources are allocated to the ISMS implementation? And what are the risks associated with the ISMS itself, plus the implementation project? What might derail this train?
  5. With all that in mind, then, what are the key elements and factors relating to the ISMS – including things such as: its main purposes or objectives, expectations etc.; its scope [clause 4.3]; the anticipated net value (ideally with enough details behind that to measure and demonstrate the value achieved); its integration with the rest of the organization including other management systems, functions, departments, initiatives etc.; its risks; and how will all that be governed, managed, directed and controlled?
That’s how I personally would read and interpret clause 4. My interpretation goes way beyond what the standard literally says and formally requires, and there are some on the ISO27k Forum who would argue (with good cause) that – as usual - I’m blabbering on, making a mountain out of a molehill and over-complicating matters (yup, guilty as charged!). The KISS approach would involve doing the least amount possible in order to convince the certification auditors that we have done what is required in the standard: I understand that perspective, and appreciate that certification and simplicity are legitimate and valuable objectives in their own right … and yet I believe we can achieve even more value from ISO27k by going beyond the minimalist formalities, designing and building an ISMS that adds even more value to the business, which in turn will help ensure its longevity and deeper integration into the organization. There's reason to my madness.

Further reinforcing the broader perspective, ISO/IEC 27003:2017 (the very useful ISMS implementation guide) has a full two pages of explanation and guidance just on section 4.1. I'm not going to lay it out here though. Go read the standard!

In practice, the outcome of those competing pressures is generally something in the middle. At the time of certification, the ISMS has to be at or above the minimum formally required in ‘27001. The question is how far above should it be? In which respects is it worth going above and beyond?

Personally, I’m keen to explore the wider business objectives and possibilities (the business risks and opportunities associated with the ISMS - the stuff that clause 6.1 should have addressed if it hadn't fallen down the information risk rabbit hole) at the outset, in order to ensure that the ISMS is designed with those longer-term goals in mind, even if in the short-term it barely does what it has to do. It's about persuading management to invest in information risk and security management because that's the route to prosperity for the organization. Scoping, directing and launching the ISMS are the critical first steps on a long journey. So let's set off on the right foot, eh? Let's at least assemble the A-team to design the edifice and construct sound foundations using building materials that won't crumble if/when we decide to add a second storey. The ISMS needs integrity too.

Jul 13, 2019

NBlog July 13 - corporate infosec policy

At the peak of the typical policy pyramid sits a ‘corporate information security policy’. In clause 5.2, ISO/IEC 27001 explicitly requires a high level policy, specifying related aspects such as demonstrable management commitment.

  • The usual boilerplate for any formal policy e.g. summary, applicability, version and date up front, plus responsibilities and references at the back;
  • A short introduction, using the pyramid diagram to outline the entire information security policy structure;
  • A set of seven principles (objectives) driving information risk and security e.g. “Information is a valuable business asset that must be protected against inappropriate activities or harm, yet exploited appropriately for the benefit of the organization.  This includes our own information and that made available to us or placed in our care by third parties.”;
  • A set of 35 policy axioms (key policy statements) derived from the control objectives in ISO/IEC 27002 with some modifications and extensions to the wording to suit this purpose.
The principles fascinate me. They aren’t (yet!) stated in any of the ISO27k standards, and yet these are fundamental concepts underpinning the entire field such as 'least privilege' and 'personal accountability'. In researching and preparing our corporate infosec policy, I dug out a bunch of principles from various places and rationalized them down to the present set. I’d like to revisit that sometime, maybe even prepare a paper about the principles and then propose either a new ISO27k standard or an appendix to, say, the information security governance standard ISO/IEC 27014.

Jul 11, 2019

NBlog July 11 - not playing by the rules

According to the BBC, British Airways has been fined £183m for last year's breach of the General Data Protection Regulation, dwarfing the previous record fines of £½m under the previous Data Protection Act.  

Ouch. Privacy compliance is now A Thing - A Very Big Scary Thing with Sharp Teeth, Claws and a Bad Attitude.

The prosecution and fine broadcasts a clear message that organizations are going to be held to account under GDPR for failing to prevent privacy breaches. I guess privacy officers, information risk and security managers, CISOs, CROs, CCOs and execs generally are now scrambling to gain assurance that their organizations are not going to end up in the same mess. And management at organizations which have suffered privacy breaches since GDPR came into effect, especially if they are currently under investigation or being prosecuted, must be quaking in their hand-made Italian leather boots. 

At 366 times the previous record, the BA fine is deliberately shocking. No wonder BA is talking about appealing the decision ... but it could have been even worse. Reportedly the fine was 1.5% of BA's global turnover, while the maximum for specific penalties under GDPR is 4%: that would have been an eye-watering £488m, or about US$600m


Airline profits are unusually volatile thanks to intense competition and factors largely outside management's control, such as fuel prices and significant incidents that affect the global travel industry. BA might conceivably need to call on its parent company or the banks for assistance to settle the bill without taking a corporate nose-dive. Even cancelling executive bonuses seems unlikely to be enough.

Having said that, any well-run organization will have identified, evaluated and treated their privacy and other information risks, including making contingency and other business continuity arrangements just in case serious incidents such as this occur. Compliance is a good reason to manage information risks professionally, on top of the many good business and social reasons for taking it seriously.

Jul 9, 2019

NBlog July - playing by the rules

This month's NoticeBored information security awareness module concerns compliance - not just complying with laws and regulations, but with rules as a whole including corporate policies, contracts, agreements and ethical codes.

The materials explore the different types of obligation or expectation, and degrees of compliance. It's not a purely binary issue, despite what some may think: compliance to the very letter of the law is different to willing agreement to fulfill the spirit of the regulations.

ISO27k audit planning

A thread on the ISO27k Forum about how to go about auditing an organization's Public Key Infrastructure set me thinking this morning.

The thread started with a question from PS:
"Could you please share some tips for auditing TLS/SSL arrangements within organisation?  Nessus will help us to identify weakness around configuration of crypto but if  I want to audit how sysadmins are creating self-signed certs and applying key management principles, how would I do that?"
In response, Ahmed provided some background information about PKI, followed by a fairly detailed and specific list of 15 auditable items, describing them as 'essential points':
  1. Audit for Root Certificate: how its managed, should be stored over secure hardware module (HSM) FIPS 140-2, if not how its secured.
  2. Assess CA Signing certificate (CA Private key) : How it is managed, secured, validity and key length.
  3. Audit System documentation to audit: (mentioned above) specially key management policy and procedures.
  4. Audit roles and segregation of duties
  5. Audit certificate templates: Issuing compliant certificates, SSL-TLS and Digital identity if valid that your are using two certificate templates or only SSL-TLS
  6. Audit for certificate (key usage) for individual certificates (Mail signing, authentication, encryption, etc.)
  7. Audit access control to the CA (should be subject to dual control)
  8. Audit CA Public key and intermediate certificates distribution, to assure its trusted over all systems.
  9. Audit for clock sync over used system
  10. audit system database security
  11. audit system backup and restore (for CA server, Configurations, HSM, root certificate, database)
  12. Audit for CRL publishing or cashing over systems
  13. Audit validity of issued certificates and how renewals are managed, to avoid human error to forgot to renew a certificate may cause system malfunction
  14. Audit the process itself for certificate issuing, renewal and revocation. (should be subject to dual control as maker checker)
  15. Audit certificate formats and extensions (PKCS formats and extensions)

Those 15 items may be a useful prompt or reminder but may not be appropriate in any given situation. ‘The essential points’ for a given audit are best determined in practice by the auditor/s using risk analysis, followed by detailed planning and prioritizing the audit work given the available resources (audit timescale plus auditor man-hours and skills).

An audit must reflect the audit objectives and scope, usually determined up-front by discussion between the audit and client management when the assignment is initiated and agreed. So, for instance, if the primary objective is to audit compliance of an ISMS with ISO/IEC 27001, the PKI is probably just a small part of that. However, if the prime objective is to audit the PKI, specifically, then a list of items similar to the 15 suggested by Ahmed may flow out of the audit risk analysis – or not: it all depends on the information risks, just as the ISMS and the PKI are driven by the risks.

As a general rule, relative risks are a good basis for prioritization: in essence, the idea is to tackle the most significant risks first and deepest, leaving lower risk matters for later, shallower review. That way, if the priority stuff turns out to be more problematic or to take longer than anticipated and resources are exhausted, the assignment can end knowing that the high priority areas have been done.

With a nearly infinite amount of potential audit work for finite resources, there are things that simply can’t be done right now. So, it pays to prioritize ‘the essentials’ and de-prioritize or park the remainder for another time. Keep notes in the audit file for use in planning future audits, along with previous audit reports, fieldwork notes, an updated risk analysis and other information sources (e.g. management reviews, incident reports etc.). This is continuous improvement for auditing.

An alternative or complementary audit planning approach is to come up with a small number of 'areas of concern', then invest an appropriate amount of audit resources into each one. Determining those 'areas' again depends on circumstances: one approach to a PKI audit might distinguish technical/cybersecurity stuff from physical and procedural aspects, for instance. Another might follow the lifecycle of a digital certificate, or concentrate on the individual departments and teams associated with the PKI, or pick up on incidents and known troublespots as routes in to the analysis, or ... whatever. There's even something to be said for deliberately planning each successive audit on a different basis, in order to avoid covering the same ground from the same perspective and hence missing the same issues (blindspots).

It's always worth reserving some time to explore interesting/concerning stuff that comes up in the course of the audit. For example, if the audit fieldwork uncovers issues with, say, key-management, it might be worth delving more deeply into key management both to find out if there is anything substantial and reportable in that specific area, and also as a worked example for the more general aspects such as policies, procedures, technical controls or whatever.  The key-management focus may not have been apparent during the original audit planning, although sometimes there are nonspecific clues about potential problem areas that feed into the risk analysis and planning (the auditor’s nose sniffing out trouble spots!). 

This is an example of contingency management: the audit work that needs to be performed partly depends on the circumstances or situation that unfolds in the course of the assignment. It can't all be pre-plannned.

It cuts both ways too. If the initial audit work goes better than planned, that leaves more time for other, lower priority matters, and might even result in concluding the audit early with a glowing audit report. 

Yes, it does happen!  Been there, done that!

Jun 20, 2019

NBlog June 20 - conspicuous consumption

A short article set me thinking this morning about the interplay between rights, compliance, personal freedoms, ethics and culture. The article is about tax authorities picking up on conspicuous consumption by citizens, suggesting that they are 'living beyond their means' - a classic fraud indicator.

Although the article specifically concerns disclosures through social media, that's just one of many ways of voluntarily disclosing information. Furthermore, some disclosures are involuntary: the authorities can demand information from and about us, for example, and we inadvertently or incidentally disclose information about ourselves in the course of living our lives.

The tax authorities have to address tax fraud, of course, using relevant information legitimately obtained from anywhere ... but in this situation the information was not disclosed for that specific purpose. Tax fraudsters would happily prohibit the authorities from accessing and using the information if they could. So is it ethical for the authorities to use it? Hmmm, tricky! 

I would argue that, in choosing to consume so conspicuously and publicly, tax fraudsters have made the information available to third parties and, by implication, third parties are free to use it legitimately. Preventing tax fraud is a legitimate purpose, so that's that.

Even if tax fraudsters explicitly prohibited the authorities from using the information disclosed through social media, I believe the laws about investigating crime take precedence (although I'm not a lawyer). Small print on the fraudsters' Facebook pages or blogs along the lines of "The tax authorities are expressly prohibited from using this information" would also be a bit of a giveaway!

Jun 18, 2019

NBlog June 18 - craftsmanship

Currently I'm getting things ready for the next consultancy gig. Figuratively speaking, having cleared a space on the workbench, I'm stocking up on raw materials and selecting tools for my toolbox. Literally, that's simply a new directory for the assignment, a few potentially useful templates and public information from the client, and a bunch of methods and techniques in mind.

My favourite tools are pre-loved and well-honed. They are familiar, comfortable and trustworthy. Some of them (such as the ISO27k standards) are off-the-shelf products. Others are either homebrewed or customized for particular purposes. They all have their advantages and disadvantages and, like any craftsman, I much prefer to use the right tool for the job, hence some specialist items are rarely used but invaluable for specific tasks. I make the effort to check and maintain my tools, from time to time investing in new ones or "improving" (well OK, refurbishing and adapting) old ones. Very rarely is a tool discarded, except for those that are plain worn out and are replaced, often by something shinier. My workshop is bulging, placing a premium on small/simple/multipurpose tools.

In many areas, ‘pragmatic’ approaches are the only tools available. It’s down to me to apply them to the tasks at hand with skill and passion, although it's hard to keep in mind their limitations. There's a tendency to press on regardless, leading to uncertain results and occasional accidents. I hate bodging things and yet that's an inevitable part of practicing and improving. 

A valuable routine at the end of any assignment is to look back and draw out the learning points. Those templates I mentioned are an example: having drafted, say, a standard form for describing security metrics, I use and gradually refine it on successive metrics until it stabilises. Every field on the form has a purpose. The structure, layout and sequence makes sense and works ... so it's worth turning into a template, an MS Word template in fact. The next time I'm describing a security metric, I can simply grab the template and start filling it in, avoiding the time and effort of starting from scratch.

Alternatively, if the client already has a structured way of describing security metrics, I can probably use that instead, perhaps proposing changes based on my experience but more likely adapting my approach to suit the client. Who knows, I might even learn some new tricks along the way, leading to an updated template. That's what I mean by investing in the tools of my trade, best practices you could say - well good-enough practices anyway. The quest for perfection is never ending.

Jun 14, 2019

NBlog June 14 - the compliance burden

I've spent an enjoyable day exploring, thinking and writing about the enormous breadth of "compliance", our security awareness topic for July. You might be forgiven for thinking that compliance in this context is just about hacking and privacy laws, but no, oh no: important though those are, there's much more to it.

We have thus far compiled a list of 15 categories of law relevant in some way to information security - not just 15 actual laws but 15 typesThere's a similar range of regulations, plus contracts and agreements. No wonder corporate lawyers, compliance teams and management as a whole complain about the compliance burden on businesses!

On top of that there are myriad internal corporate rules in the form of infosec-related policies, procedures and all that jazz - again, quite a variety when you think about it. 

And we all have self-imposed rules of behavior - our habits and conventions, codes of ethics, belief systems, rules for what's right and what's wrong.

Figuring out and talking about the different kinds of 'rules' will make an interesting awareness challenge for July. We've come up with more than 60 so far, and we're not done yet!

Aside from that, I've also been exploring the conceptual angle: what are rules for anyway? Why do we have rules, in general, let alone infosec, privacy and all those other rules I've alluded to? Why is compliance necessary? What's wrong with noncompliance? That led me along a tangent into creativity, again relevant to information if marginal to information security. 

Jun 12, 2019

NBlog June 12 - lack of control is not a vulnerability

Another of those apparently simple but quite profound questions came up on ISO27k Forum this morning. Juan from Peru said:
"Well, I am pretty confused about how to correctly describe a vulnerability. I´ve seen many sheets/registers (even a topic in this group) where a vulnerability is described as a "LACK OF A CONTROL" For example if I say that a VIRUS is a threat agent, my vulnerability would be a "LACK OF A VACCINE FOR THAT SPECIFIC VIRUS", this is quite redundant, I think but in a certain way, has sense. Now, I´ve also read that a Vulnerability CAN NOT be described as "LACK OF A CONTROL" because a Vulnerability is AN INHERENT WEAKNESS OF THE ASSET, which I think has more sense than the vaccine´s example. But, there is a problem, I could not find any official literature (I mean and ISO 27k) that supports that definition. I searched in ISO 27000 and 27005, and those Standards just say that a vulnerability is a weakness that can be exploit (Nothing about INHERENT). Also in ISO 27005 I found many examples of vulnerabilities (In the annex, I think) and they are described as "LACK OF CONTROLS". This is really confusing for me."
“Inherent weakness” is my succinct working definition of vulnerability. I use the word “inherent” to refer to issues within or integral to the system of concern (not necessarily an "asset"), in contrast to threats which (again, as I use the term in practice) are outside the system and impinge upon it. Furthermore, by ‘system’ I mean a coherent collection of things acting in concert - not just, say, an IT system (the computer hardware, firmware and software plus the data) but also the associated processes involved in using and administering it, and the users and administrators, the managers overseeing it, its owners/stakeholders … and so forth. I use 'system' in as broad a sense as “information security management system".

So why does my working definition of 'vulnerability' differ from that in ISO/IEC 27000:2018? Why don't I just use the formal definition? Good point ... but my reasoning is complicated to explain. Bear with me.

I'll start with the formalities. Among other terms, ISO/IEC 27000:2018 defines:

  • Control as “measure that is modifying risk (3.61)” plus 2 notes: "controls include any process (3.54), policy (3.53), device, practice, or other actions which modify risk (3.61); it is possible that controls not always exert the intended or assumed modifying effect."
  • Vulnerability as “weakness of an asset or control (3.14) that can be exploited by one or more threats (3.74)”. That definition is a little ambiguous* but I understand it to mean that a weakness of a control would constitute a vulnerability if it might be exploited;
  • Threat as "potential cause of an unwanted incident, which can result in harm to a system or organization (3.50)"; and
  • Risk as "effect of uncertainty on objectives (3.49)" plus 6 notes: "an effect is a deviation from the expected — positive or negative; uncertainty is the state, even partial, of deficiency of information related to, understanding or knowledge of, an event, its consequence, or likelihood; risk is often characterized by reference to potential “events” (as defined in ISO Guide 73:2009, and “consequences” (as defined in ISO Guide 73:2009,, or a combination of these; risk is often expressed in terms of a combination of the consequences of an event (including changes in circumstances) and the associated “likelihood” (as defined in ISO Guide 73:2009, of occurrence; in the context of information security management systems, information security risks can be expressed as effect of uncertainty on information security objectives; information security risk is associated with the potential that threats will exploit vulnerabilities of an information asset or group of information assets and thereby cause harm to an organization."
Unfortunately, there are numerous issues and ambiguities in those four definitions: 
  • Only a few of those words are explicitly defined in the standard - the ones that are used in a particular way within the context of the ISO27k standards ('terms of art' you could say). I believe we are meant to refer to the Oxford Dictionary definitions for the rest although this is not actually stated anywhere in the published standard: it is merely a convention, possibly stemming from ISO's directives to the drafting committees;
  • As formally defined, control distinguishes two concepts: controls ‘modify’ risks and hence (I would argue) are not part of them. You could consider them to be optional extras, add-ons that you may or may not want to use – at least that’s how I think of them although the definition doesn't actually say so;
  • The definition of vulnerability is ambiguously worded in the first clause. Does it mean "weakness of an asset, or weakness of a control" or "a weakness of an asset, or a control,"? I believe it is the former but that's just my interpretation - and ideally there should be little to no room for interpretation in a formal definition;
  • Threat seems quite straightforwardly defined (aside from referring to "system or organization", implying that they are distinct ... but one could argue that an organization is one type of system, a social system, often with a legal basis; 'system' is undefined). However, as Juan noted, even ISO/IEC 27005 misinterprets the term. A lack of control may modify the risk compared to its presence, but does not actually cause an incident: it is simply an omission. Incidents are caused by circumstances or acts - the commission of something, not omissions;
  • The definition of risk is particularly awkward and unsatisfactory. It is the product of a committee of people holding differing views, hence its extraordinary length. The definition part is so vague as to be almost meaningless, while the notes compound matters by mashing up several separate concepts. What a mess! It might not be so bad if 'risk' were peripheral to ISO27k but in fact quite the opposite. Risk (or rather, as I would prefer to put it, "information risk") is absolutely central. 
I personally do not consider lack of a control to be a vulnerability for several reasons:
  1. It makes it easier to consider and evaluate the underlying risks in a situation, deliberately ignoring any current or proposed controls during the analysis. It helps us distinguish risks from controls (as per the definition), and simplifies the risk analysis.
  2. Some existing or proposed controls may be unnecessary and unhelpful (e.g. periodic password changes), but we are less likely to consider that if we always take them for granted and assume they are present and working as intended in our risk analyses. Periodic password changes, for example, are a costly control incorporated into many systems for years without good reason other than habit or convention. In any given system, there may well be other controls that serve little to no purpose, perhaps even some that are counterproductive (they actually weaken rather than strengthen the system, perhaps opening up new avenues for attack or failure: antivirus software and automated software updates are two possible examples of this).
  3. The list of potential controls is unbounded. Aside from the large variety of possible types of controls, each control has many variants, and there is a huge (possibly infinite) variety of possible combinations and sequences of controls. So how are you going to determine which controls to add to, or exclude from, the list of missing/ineffective/inadequate controls? Answering that question presupposes that you understand the risks, in other words it is a circular or self-referential issue. 
  4. It allows/encourages us to figure out which controls we require according to the risks we have identified and evaluated. It also suggests a natural priority or ranking of the controls, since those controls mitigating the most significant risks are clearly important (‘key’) controls. This has substantial implications that are not widely considered, at present e.g. resilience, effectiveness and assurance are likely to be strong requirements for key controls.
  5. Controls are not 100% reliable – in other words, there are risks associated with the controls themselves, as implied by the second note to the '27001 definition of control. This again complicates the risk analysis and (in my experience) is usually ignored … but that’s a mistake, particularly in the case of key controls. The possibility of key controls failing to operate as intended or as required means significant risks might be insufficiently mitigated in practice. Now you might say that this means 'control reliability' therefore ought to be part of the risk analysis, in addition perhaps to 'control suitability', 'control value' and maybe other considerations. Personally, I prefer to address this separately in the risk management process, particularly in the phase following the decisions about how to treat the identified and evaluated risks, plus in the ongoing management, measurement and assurance activities once the controls are in use.
Another way to look at this is that a missing, weak, inadequate, failing or inappropriate control, exposes or fails to compensate for a vulnerability ... but 'exposure and 'compensating control' are ambiguous and confusing concepts too. Maybe I'll come back to that another day.

So, that's it for today. Sorry to be so anal about the words and definitions, but Juan is certainly not the only confused soul - even ISO/IEC JTC1/SC27 has trouble with this stuff! 

Jun 11, 2019

NBlog June 11 - resistance is futile

Generally speaking, there's no point in complaining about applicable laws and regulations: like it or not, compliance is obligatory. That's not the end of the matter though: it's not as simple as that. For starters, there are questions about precisely what the obligations are, their applicability, and the potential consequences of noncompliance.

Those questions are all the more interesting in respect of other kinds of rules, especially those that are not written formally by highly trained lawyers following strict drafting practices finely honed over hundreds of years - corporate security policies for instance. 

Positioning compliance as a business or risk management issue puts a different spin on things. One particularly worthwhile approach is to elaborate on and explore the objectives behind the wording of the rules. Why is it considered necessary to protect someone's privacy, for example? What might happen if personal information was unrestricted, freely available, a commodity that could be freely shared or traded? Such questions are trickier to answer than they might appear.

Consider the actual real-world effects of "major" privacy breaches such as the Target incident in 2013. Aside from the public outcry or outrage, the enforcement penalties and various other costs relating to the clean-up, the organizations concerned are mostly still operating ... but are they the same, or have the incidents changed things? And what if any are the effects on the rest of us?

One difference stems directly from the media coverage of major incidents, specifically headline news raises awareness of the related issues among the general population and management, right up to executive level. But once the furor has died down, awareness tends to subside gradually back towards pre-incident levels - maybe a little higher due to the residual memories and reminders such as this very piece! 'A little more awareness', then, is the net, long-term effect of incidents on those not directly affected, perhaps also the individual and corporate victims who were involved.

'A little more awareness' is the least we can reasonably expect to achieve through security awareness and training activities - hopefully more than just 'a little', of course! Repeatedly topping-up on awareness levels is the approach we have taken for decades: regular refreshers work for us, in the same way that each subsequent privacy breach reminds us, yet again, that there are compliance obligations in that area. It's a ratchet or cumulative effect, each episode raising the level by some amount.