Security awareness lessons from Pokemon

August's security awareness topic is "pocket ICT security", referring to the information risks associated with portable Information and Communications Technology devices: the smartphones, laptops, tablets, USB sticks, wearables and other high-tech stuff we carry about our person.

Risks such as walking into the road and being hit by a car.

Yes, seriously. 

It is both on-topic and highly topical in the case of Pokemon Go players, young and old, being so focused on the virtual world on the smartphone screen that they neglect the real world hazards around them. The lucky ones are spotted and avoided by alert drivers. The unlucky ones are injured, perhaps even mown down by a vehicle driven by a similarly distracted driver.

Distraction is the more general information risk, a modern-day affliction. The more portable ICT we use, the more distracted we become. Wearables are the latest trend, long predicted but curiously slow to take off, perhaps because of the distraction factor? Or is it just that the Killer App has yet to appear?

August's awareness module delivers another 200 Mb of fresh awareness content, almost all of it researched and prepared within the past few weeks:

• A train-the-trainer guide with creative advice on making good use of the materials;
  
  
• A newsletter, using recent news clippings to illustrate the risks;
  
  
• Three awareness seminar slide decks (one each for staff, managers and professionals), mostly graphical with few words on the slides and detailed speaker notes;
  
  
• Six high-resolution awareness posters and six diagrams (mind maps and example metrics) suitable for professional printing, or to incorporate into other materials;
  
  
• Three security policies and a procedure;
  
  
• Several awareness briefings explaining things that are relevant to and hopefully resonate with the intended audiences;
  
  
• A security metrics paper proposing and discussing several relating to portable ICT - useful whether you want to prove that everything is under control or to identify and justify systematic security improvements;
  
  
• An FAQ, word-search challenge, awareness survey, quiz and case study supporting the learning process and awareness program;
  
  
• A comprehensive hyperlinked glossary of information risk and security terms, highlighting those that are especially pertinent to pocket ICT;
  
  
• An ICQ (Internal Controls Questionnaire) with which to review or audit the organization’s risks and controls in this area.

The materials are mostly MS Office files, supplied camera ready but unlocked (without Digital Rights Management), making it simple for subscribers to tweak or customize themselves ... in fact we actively encourage them to adapt the materials to their specific requirements. That might be as straightforward as selecting a few bits-n-pieces, replacing the placeholder logo with their own security awareness branding and updating the 'contact us for more info' details in each of the materials, or it could involve more substantial changes (e.g. if BYOD is totally forbidden, rather than being authorized by management as appropriate). 

Either way, it's much easier and cheaper just to adapt the supplied content than to research, prepare, proof-read and finalize everything from scratch, assuming a suitable technical author is immediately to hand - someone who has the qualifications, experience, competence, creativity and track-record in security awareness. Good luck finding someone suitable and willing to step into that role for anything remotely approaching the cost of our materials. Industry surveys tell us the information security jobs market is heating up rapidly as demand outstrips supply. One year's salary for an infosec awareness professional would buy the average organization enough awareness materials for decades, literally.

ISO27k standards status update

I spent my weekend catching up with a backlog of ISO/IEC JTC 1/SC 27 emails, updating ISO27001security.com to reflect my personal understanding of the current status on all the ISO27k standards. 

A few items of note: 

1. Terminology continues to be a problem for the committee. ISO/IEC 27000 isn’t working out very well. Although there are obvious advantages in everyone agreeing on the terms and definitions, it causes dependencies between standards projects. There are lingering disagreements over the meanings of terms such as ‘information asset’ and ‘cyber’ (currently undefined), and bureaucratic delays in publishing the free version of the standard. The standard might become an online glossary but whether that will help or hinder is uncertain. [The current online glossaries are not exactly paragons of web design and functionality – take a look at the ISO Online Browsing Platform (OBP) and/or the IEC’s equivalent International Electrotechnical Vocabulary (IEV, a.k.a. Electropedia) and see what you think.]
   
   
2. The updated versions of ISO/IEC 27003 (ISMS implementation guide) and ISO/IEC 27004 (metrics) are nearing release, possibly before 2017. Both are (in my opinion) huge improvements over the current versions, recommended reading for everyone on this Forum when they are released.
   
   
3. The project to update ISO/IEC 27005 ('information security risk management'*) has been canned. It was a victim of its own success in that lots of creative changes were proposed, derailing the project from its core objective to update the standard to reflect the 2013 versions of ISO/IEC 27001 and ISO/IEC 27002. It ran out of time on the ISO-imposed project timescale. The update project should be restarted with a more tightly-defined scope, meaning that those ‘creative changes’ may be held over to a subsequent version, or might possibly surface in other ISO27k standards.
   
   
4. Within ISO27k, several cloud security and eForensics standards are nearing completion, plus others on application security and incident management. The committee is as busy as ever, especially given that ISO27k is only about half of its remit (there is a parallel programme of identity management, privacy and other IT security standards). There are lots of liaisons, too, coordinating things with other ISO committees, industry bodies and specialist groups. 

This is all ‘unofficial’ info: if that matters to you, please check with ISO/IEC or your national standards body for the ‘official’ version, without my errors, cynicism and bias. And please put me right if I am wrong or off-base. I’d welcome other perspectives. Please join the free ISO27k Forum to discuss this further with more than 3,000 other fans of the ISO27k standards.

* It's really about the management of 'information risk' but that term is not yet used within ISO27k, unfortunately. I'm working on it.

Micro vs. macro metrics

Whereas "micro metrics" focus-in on detailed parts, components or elements of something, "macro metrics" pan out to give a broad perspective on the entirety. 

Both types of metric have their uses.

Micro metrics support low-level operational management decisions. Time-sheets, for example, are micro metrics recording the time spent on various activities, generating reports that break down the hours or days spent on different tasks during the period. This information can be used to account for or reallocate resources within a team or department or identify. Normally, though, its true purpose is to remind employees that they are being paid for the hours they work, or as a basis on which to charge clients. 

Macro metrics, in contrast, support strategic big-picture management decisions. They enable management to "see how things are going", make course-corrections and change speed where appropriate. The metric "security maturity", for example, has implications for senior managers that are lost on lower levels of the organization. I have a soft spot for maturity metrics: they score strongly on the PRAGMATIC criteria, enabling us to measure complex, subjective issues in a reasonably objective and straightforward fashion.

The sausage-machine metrics churned out automatically by firewalls, enterprise antivirus systems, vulnerability scanners and so forth are almost entirely micro metrics, intensely focused on very specific and usually technical details. There are vast oceans of security-related data. Lack of data is not a problem with micro metrics - quite the opposite.

Some security professionals are 'boiling the ocean' using big data analytics tools in an attempt to glean useful information from micro metrics but a key problem remains. When they poke around in the condensate, they don't really know what they're looking for. The tendency is to get completely lost in the sea of data, constantly distracted by shiny things and obsessing about the data or the analysis ... rather than the information, knowledge, insight and wisdom that they probably should have gone looking for in the first place.

It's like someone stumbling around aimlessly in the dark, hoping to bump into a torch!

Just as bad, when a respected/trusted metrics "expert" discovers a nugget and announces to the world "Hey look, something shiny!", many onlookers trust the finder and assume therefore that the metric must be Good, without necessarily considering whether it even makes sense to their organization, its business situation, its state of maturity, its risks and challenges and so forth ... hence they are distracted once more. As if that's not enough, when others chime in with "Hey look, I've polished it! It's even shinier!", the distractions multiply. 

The bottom-up approach is predicated on and perpetuates the myth of Universal Security Metrics - a set of metrics that are somehow inherently good, generally applicable and would be considered good practice. "So, what should we be measuring in security?" is a very common naive question. Occasionally we see various well-meaning people (yes, including me) extolling the virtues of specific metrics, our pet metrics (maturity metrics in my case). We wax lyrical about the beauty of our pet metrics, holding them up to the light to point out how much thy gleam and glint. 

What we almost never do is explain, in any real detail, how our pet metrics help organizations achieve their objectives. We may describe how the metrics are useful for security management, or how they address risk or compliance or whatever, but we almost invariably run out of steam well before discussing how they drive the organization towards achieving its business objectives, except for a bit of vague hand-waving, cloud-like. 

By their very nature, it is even harder to see how micro metrics relate to the organization's business objectives. They are deep down in the weeds. Macro metrics may be up at the forest canopy level but even they are generally concerned with a specific area of concern - information security in my case - rather than with the business.

I guess that's why I like the Goal-Question-Metric approach so much. Being explicit about the organization's goals, its business and other high-level objectives (e.g. ethical or social responsibility and environmental protection), leads naturally into designing macro metrics with a clear business focus or purpose. 

In the full glare

Here's a neat illustration of the challenges facing those protecting critical national infrastructures.

Take a look at this map of the UK's fuel pipelines - a massive mesh of pipes criss-crossing the country, linking refineries and fuel stores with power stations and airports. Many of the pipes are buried, carrying large volumes of volatile and energetic fuel under substantial pressure for hundreds of miles across open country, along roads, over canals and under cities, hence the need for the map, the website and the organization behind it: trust me, you don't want people accidentally digging them up, or driving piles through them. For health and safety reasons, let alone the risk of serious economic and physical fallout, people driving big yellow mechanical diggers and pile-drivers need to know if they are within striking range of the pipes. Planners, architects and builders need to know where they lie, plus the operators who use and maintain them, oh and the emergency services just in case.

Now imagine you've been tasked with protecting those same pipes against deliberate attacks by, well, anyone with a big yellow digger and a grudge for starters. The list of potential adversaries and their possible reasons is long and changeable. Some of them have serious resources and capabilities behind them, and no particular rush.

The reality of protecting critical infrastructures is rather different than the Popular Mechanics perspective.

ISO/IEC 27000:2016 available for FREE download

Like its predecessors, the 2016 fourth edition of ISO/IEC 27000 has been released for FREE.  It can be downloaded in both English and French.

Whereas I regret to say that ISO/IEC charges heavily for almost all of the ISO27k standards, ISO/IEC 27000 is FREE in order both to spread a common understanding of information security terms, and to outline the whole family of ISO27k standards. This is not some ripped off pirated version but a legitimate publication by ISO/IEC.

The definitions in ISO/IEC 27000 apply throughout the ISO27k standards except where terms are explicitly redefined in the individual standards: generally those explicit redefinitions are refinements in the specific context of a single standard, or variations required to align with ISO standards outside the ISO27k family. 

A few of the official definitions are rather curious and narrow - for instance I believe the definition of 'integrity' as 'property of accuracy and completeness' is referring to data and system or process integrity, but not personal integrity - which is, for sure, a core concern in relation to information risk and security, for instance in fraud and insider threats. Integrity is also about trustworthiness, grit, honesty and ethics.

A few definitions are grammatically weak, and perhaps technically wrong - for instance 'authenticity' is defined as 'property that an entity is what it claims to be' whereas a fake (unauthentic) Gucci handbag doesn't "claim" anything: it is just a fake handbag. The people who made and/or sell it claim (falsely assert) that it is Gucci, but the handbag itself is merely a branded inert object, incapable of making claims as such. This is a classic example of where a conventional dictionary does a better job than ISO/IEC 27000, for such commonplace terms anyway. The editors of ISO/IEC 27000 really ought to go through the glossary, pulling out such everyday terms (and citing a suitable dictionary), leaving behind only the specialist 'terms of art', most of which I suspect will be multi-word terms or phrases.

Some important terms (such as 'information asset') are undefined, largely I suspect because the committee cannot agree on the definitions, but possibly because someone has decided that the dictionary will suffice. 'Information security risk' is another undefined and strange term, common throughout the ISO27k standards. I hope it will eventually be replaced by the much more intuitive and sensible term 'information risk' with a suitable, straightforward definition, something along the lines of 'risk involving or relating to information'.

Whereas neither 'information security risk' nor 'information risk' are defined as phrases, 'information security' and 'risk' are defined separately, along with 'information security event', 'information security incident', 'information security incident management' - oh and 'information security continuity' which apparently means the processes and procedures (both, you understand: don't go thinking one or the other is enough) ensuring the continuance of information security operations (which - yes you guessed it - remains undefined).  

Overall, though, while we (well OK, I) may bicker about specific issues, gaps and inconsistencies, it is A Good Thing that terms are consistently and formally defined. And, hey, at least it's FREE!

What is an ISO 27001 gap analysis?

In the context of ISO/IEC 27001, I've often heard people planning to commission or conduct a ‘gap analysis’ or 'readiness assessment' or 'pre-certification audit' or 'ISMS project review', but what do they mean? What exactly is going to take place?

Good question! There is no formal definition. It is essentially just a consultancy assignment specified by the client and agreed with the consultant/s doing the work. Given the context, its main purpose is generally to review the organization's state of readiness, addressing the question "Is the organization ready to be certified compliant with the ISO standard?" Another way of putting that is to ask "If the certification auditors turned up next week, would they: 

1. Turn around and walk away during the very first morning, shaking their heads in sheer disbelief at the near total clue deficiency and leaving site with another war-story;
   
   
2. Get stuck in to the audit fieldwork, quickly digging up plenty of issues including some major ones to discuss with management, perhaps serious enough that they would refuse to issue a certificate unless they were resolved;
    
3. Get stuck in to the fieldwork, finding only a few trivial issues and a lot of good practices, hence having every reason to issue the certificate; or
   
   
4. Struggle to find anything of real concern, perhaps leaving site with enough material for a case study in how to do it?

Determining the organization's certification readiness status is (usually) the obvious focal point of the job, its core objective ... but there's more to it in practice. In addition to the obvious gap-gazing element, an 'ISO27k gap analysis' or whatever the assignment is called will typically also:

• Review the scope of the ISMS and hence the likely scale and nature of the implementation project, including the timescales and resources needed;
  
  
• Review the information risks and security controls against those required or recommended by ISO/IEC 27001 [this is a surprisingly small element, since the standard and the certification auditors pay far more attention to the Management System than to Information Security];
  
  
• Review the ISMS implementation project or programme - the plans and resources (particularly key players such as the project manager, steering committee and senior management advocate), and various project risks;
  
  
• Introduce various people in the organization to the idea that managing information risk and security really is a bigger, broader, deeper concern than they probably appreciated (e.g. it concerns physical security for smartphones and servers, corporate papers, tablets, laptops and people while they are traveling on business or working from home or whatever - areas that traditional IT security, even in the modern guise of ‘cybersecurity’, may have barely even considered: there's more to ISO27k than IT/technical security!);
  
  
• Inform and hopefully engage management and other stakeholders more fully with the ISMS and the ISMS implementation project, giving them the chance to think about, raise and discuss information risks that are of concern to them and the business, not just of theoretical concern to those paranoid infosec pro's;
  
  
• Pump-prime a productive business dialog between stakeholders and specialists that will continue indefinitely, concerning information risks, opportunities, controls, governance, compliance, privacy And All That, emphasizing their value to the organization (the business context);
  
  
• Provide information and guidance for planning and completing the ISMS implementation, such as prioritizing areas which need some serious effort to bring them up to the required standards. The advice may extend to working out roughly how long it will take and how much more it is likely to cost; identifying the ‘friends' of information security vice those who are more likely to be blockers or enemies, needing some guidance and persuasion to bring them into line;
  
  
• Give management an independent perspective on the ISMS and the project team, from a competent, experienced professional who knows the standards inside-out and has been hands-on using them for a considerable period (hopefully, that is: anyone can claim to be a consultant, so caveat emptor - check their qualifications, background and expertise. An ISO/IEC 27001 Lead Auditor or Lead Implementer certificate may seem impressive but does not, in itself, indicate much beyond confirming somebody's attendance on a short course, especially if it is a fake or was issued under dubious circumstances. Remember that the consultant is likely to gain sensitive inside knowledge about the client's information security arrangements, hence they must be trustworthy);
  
  
• Give the Chief Information Security Officer, Information Security Manager, Information Security team, Cybersecurity guy/gal or ISMS Implementation Project Manager a chance to see how the consultant works, and vice versa. If the assignment goes well for both parties and the working relationship flourishes, there may be opportunities for ongoing contact and support, perhaps further consulting assignments during the journey ahead. If not, well fair enough, maybe it's better to part ways at this point;
  
  
• Support and encourage all concerned in a general sense. As well as gently pointing towards the end goal, boosting team morale, (re)motivating people and reassuring nervous managers are classic side-benefits of a productive project audit or review.

As with the ISO27k standards themselves, factors such as the size or type of organization, its structure, ownership etc. are of limited relevance to the assignment. A gap analysis is likely to be quite quick (perhaps a couple of days on the ground) for a relatively small, simple organization at a single location that doesn’t have a lot of valuable or vulnerable information to protect, doesn’t have many people or business relationships, is already strong on information security, and isn’t subject to stringent compliance obligations (laws, regulations, contracts including PCI-DSS, and more). Conversely a bank, even a small/specialist one, is bound to take longer to assess. Likewise a multinational or a government body.

The timing of the gap analysis is also pertinent. If the job is done very early on in the ISMS implementation project (perhaps even in advance of project approval), there probably won't be much in the way of hard evidence to review, making the assignment very fluid and somewhat perplexing for client employees not already engaged with the project. Conversely if it is done just a few weeks before the formal certification audit, most of the hard work should have been done: a competent consultant should still find a few things to comment on, providing a measure of assurance to management that the audit is likely to go smoothly once the final few pieces slip into place.  

Things can get interesting if the gap analysis falls in the middle period. The basics of an ISMS should all be in place with some parts of it operational already. This is normally such a fraught period for the implementation project team, however, that they may not have the high-level oversight, hence management may well be concerned to find out whether the project is on track and going to plan, teetering on the brink or running off the rails. A gap analysis in this period can be more involved and take longer, if only for the simple reason that everyone is extremely busy. On the up-side, there is still time left to make substantial changes if that is necessary. This is a good point to pencil-in the certification audit, and start lining up the certification body (the details to be confirmed nearer the time, perhaps after a final readiness assessment).

Strong governance of information risk and security, including management engagement with the ISMS is, I venture, crucial to its long term success, one of the if not the biggest Critical Success Factors. To put that another way, limited management understanding and support is, in my experience, the number one reason for problems on ISMS projects and the most likely reason for lack of funds, lack of priority, disinterest, unplanned changes, limited scope, lack of opportunity for improvements, aggravation, stress and, ultimately, marginal value to the organization. A well-timed, well-specified, well-resourced gap analysis can be the turning point.

PS  I am planning to add that updated version of the process diagram to the free ISO27k Toolkit at ISO27001security.com in due course.

PPS Get in touch if you think you might want a gap analysis. I know several gap analysts around the world, even some down here in the South Pacific. 

IP Intellectual Poverty

A thought-provoking piece in Forbes about the commercial value of intellectual property contains a stack (a set? A pile? A jumble? An assortment?) of remarkable statistics ... and I feel inspired to comment on one graph in particular:

Neither the Forbes piece nor the Ocean Tomo source explain how the numbers on that graph were calculated. Intangible assets are not normally reported/disclosed, and in fact are notoriously difficult to value. Various approaches could have been used to estimate the asset values but we don't know how it was done.

The valuation appears to have been based, in part, on the 'market value' or capitalization - essentially the product of the number of issued shares and the share price - of some or all of the Standard & Poor's Top 500 companies. The difference between capitalization and reported tangible asset values would estimate the value of intangibles ... but both values are somewhat uncertain. Share prices, for instance, tend to be far more volatile than tangible asset values. Having been determined by an acceptable method (i.e. conventional book-keeping, accounting and auditing practices), tangible asset values are essentially fixed, but that raises another concern since the 'book value' of a capital asset may be the value when purchased, not necessarily today's value. The accounting and tax rules for depreciating and re-valuing assets further complicate things.

Anyway, setting all those doubts and concerns aside, what does the graph tell us? If we trust the numbers, it says that over the past 40 years, the proportion of the asset value of some US-listed companies relating to intangibles has substantially grown, relative to their tangibles. The rate of growth has fallen over the last 10 to 20 years, and the trend suggests the intangible to tangible value ratio will reach its peak of about 86% in the next 10 years.

That in turn raises all sorts of interesting questions such as why has the ratio changed so remarkably, and why is it now stabilizing? The Forbes article strongly implies that the change is largely due to a marked increase in the value of intangibles over the period (mirroring the widely reported emergence of the 'knowledge economy'), but it could equally be that tangibles have fallen in value (mirroring the widely reported decline of manufacturing industry): some capital assets such as vehicles, computers and other electronics have indeed become cheaper in real terms, but we are buying more of them now so the net expenditure could be lower, the same or higher. I'm equally unsure about buildings and land. Land values increase fairly steadily, on the whole, but over the period we have seen social changes such as urbanization. City center real estate values have skyrocketed, prompting some businesses in turn to downsize HQ or head out to rural business parks and less crowded towns. New, more efficient building techniques and materials may have reduced building costs, but conversely improved building standards, environmental controls etc. may have negated or reverse those savings.

It's all very complicated!

The Forbes article uses the Ocean Tomo graph and findings from other surveys and studies to encourage young workers to take more of an interest in generating and exploiting intellectual property, particularly patents. Fair enough although being an information risk and security professional, I have a different interest in or perspective on the same information. Seems to me the main take-home message is that we should have been substantially improving our protection for intangible assets, particularly information, in recent decades. We should be investing or spending proportionally much more on information security today than on physical security, of the order of four-to-one. So if our annual bill for physical/site security (doors, locks, barriers, guards, alarms, patrols, CCTV systems and so on) is $1m, we should expect to spend about $4m on information security (antivirus, firewalls, passwords, infosec pros, backups, patents, compliance etc.), other things being equal.

That's an intriguing thought. Even at a high level, it's hard for management to determine how much an organization ought to be spending on its information security, hence resource allocation and investment appraisal in this area are distinctly challenging. Several different approaches are used (e.g. benchmarking against other similar organizations, finger-in-the-air budgeting such as '5% more than last year', and various value assessments based around the projected costs of incidents if expenditure was cut) but none is definitive. The sizes of information security departments varies widely in practice between organizations, but perhaps now we have a more objective basis, comparing information security and physical security expenditure. While it may be no easier to determine how much ought to be spent on physical security, we do at least have the advantage of thousands of years of real-world experience in that domain! 

Then again, maybe not: it all depends on whether all those numbers, assumptions, presumed causal links and assorted leaps of faith are valid.

I have a nasty, nagging feeling that the average dollar spent on information security somehow achieves less return than the average dollar spent on physical security. Is there truly a business case for investing as much as we do in, say, antivirus or information security awareness? 

I believe so but I'm hard pressed to prove it. Mind you, I've given it my best shot!