(ISC)2 Blog

Protect or exploit?

The perennial discussion about the value of risk analysis has broken out yet again over on CISSPforum.  It's close to being classed as one of our zombie topics - the ones that we think we've successfully killed off after getting nowhere but some time later they arise from the grave to haunt us again, over and over.  I wouldn't mind so much but we seem to dance around the same old handbags every time:

• Quantitative versus qualitative risk analysis - the pros and cons of each, and innumerable associated methods, tools and techniques 
• Risk-based versus experience and good practice-based security investment decisions
• Risk- or experience-based versus compliance-based decisions
• All of the above versus risk-based standards such as ISO27k
• The futility of any form of information security risk analysis if management can undermine any argument versus the need for us to be "risk-focused", for various reasons expressed with varying degrees of hand-waving

This afternoon, I'm contemplating a different argument, the contrast between what general business and financial managers think of "risk" versus what it means to CISSPs.  For management, risk is something to be embraced and exploited, where appropriate, because risk brings opportunity.  For CISSPs, risk is something to be avoided, controlled/mitigated or transferred because it is BAD.  We're worlds apart.

So, how about we turn our argument on its head: instead of asking "How can we best minimize information security risk X?", ask "How much information security risk X can the organization stand before it becomes intolerable?" or, for kicks, "How lucky do you feel?".  I find this kind of approach quite liberating, in a funny sort of way, a bit like extreme sports.  Extreme CISSPs deliberately take chances and enjoy the thrill that entails.  I'm not talking about being totally reckless - we're still CISSPs at heart, so we understand the value of contingency measures - but knowingly pushing the boundaries where appropriate, in the full knowledge that some of our risk-taking will fail (just as it will even if we are ultra-conservative!).  The key to success, as in extreme sports, is to know when to stop the game, but the difference with this approach compared to the usual risk-averse-verging-on-paranoid traditional play is that we are not automatically saying "No!" to everything, so if and when we do actually say "No!", it inevitably has more impact. 

Taking this a step further, it is fascinating to discuss such an approach with management, particularly as they have more at stake being the information asset owners, accountable for their protection and exploitation.  It may be counterintuitive, but I suspect a CISO who asks "How much information security can we do without?" stands just as good a chance of getting the funding she needs for critical projects as her more traditional peers - but with a very definite additional advantage, namely the genuine management support that we stick-in-the-muds so often lack.

Resilience - the missing link?

While reading IT Grundschutz, the German information security baseline standards, and in particular the BSI standard 100-4 on Business Continuity Management, I've been thinking about a curious gap that I believe has opened up between the fields of information security and business continuity. 

The way I think of it, 'resilience' (and related concepts such as 'over engineering', redundancy, automated failover and so forth) is very definitely an integral and essential part of 'business continuity' (in other words, keeping vital business operations running as near normally as possible, despite whatever threats and vulnerabilities might materialize).  Keeping unauthorized users out of the applications, systems and networks, preventing data and systems corruption (including that deliberately introduced by corrupt fraudsters, as well as incompetent or indolent users, designers, administrators, developers and managers), avoiding unplanned and unwelcome changes, avoiding/neutralizing malware and maintaining adequate IT performance and capacity are, for me, all important business process resilience controls, and are therefore all valid aspects of 'business continuity'. 

Avoiding or at least reducing the extent/impact of incidents, crises and disasters has got to be better than recovering from them, surely?

However, most 'business continuity' standards are purely concerned with 'Assume a disaster has happened: we need to prepare ourselves to cope with what happens next'.  They talk about timely resumption and recovery, all post-event of course, while most information security standards major on maintaining confidentiality, with a few token nods towards data, network, application or sysem integrity but very little in the way of process or personal integrity and even less about availability, other than referring to 'business continuity' (often meaning IT Disaster Recovery in fact) as if that settles the matter.

Most organizations I've worked with seem to separate information security from business continuity management, in the same way that most separate physical from information security, and have other stovepipes for fraud, risk management and compliance. 

So what on Earth happened to resilience?  Where did it go?  Have you seen it, hiding in a corner somewhere?  While I totally support the need for contingency planning to prepare the organization to cope more effectively with disasters that result from the failure of preventive controls, I strongly suspect that many organizations would be better off diverting some of their not inconsiderable business continuity budgets towards resilience and prevention, or at the very least creating a more coherent strategy linking information security with business continuity through their common interest in resilience.

I'd be especially interested to hear from anyone who is familiar with standards, guidelines etc. that cover resilience (as outlined above) in some detail, whether they claim to cover information security, business continuity or something else entirely.  Go on, give us a clue about where to find the missing field.

... 97, 98, 99, 100, coming, ready or not!

Kind regards,
Gary Hinson
ISO27001security.com
NoticeBored.com

PS  A well-written piece on Investing in software resiliency by Dr. C. Warren Axelrod, U.S. Cyber Consequences Unit, lays out several aspects of resilience, including a number of availability threats, software development process issues and of course a range of IT resilience controls such as fault tolerance and failure recovery, system fail-over and recovery and restoration.  Even cloud computing merits a mention.  However, once again, business continuity and the wider aspects of identifying and maintaining critical business functions are largely implied. 

Security awareness video

If your organization relies on "proximity cards" or "swipe cards", or even good ol' fashioned staff passes, to restrict access to secure areas, I heartily recommend a BBC security awareness video featuring, um, pigs.

Whoever said security awareness sessions have to be boring?  :-)

Gary

Add "human factors"? No.

OK, Gary has asked if the CISSP CBK should be expanded to cover "human factors" in security?

And I answer "No."

With that kind of beginning, you could be forgiven for thinking that I disagree with Gary about the importance of human factors in security.  Nothing could be further from the truth.  I agree with everything he has said about the fundamental significance of human factors in information security, as well as the difficulty of dealing with them, and will defend to the death his right to say it.

What I disagree with is the question.

The CBK already addresses human factors.

When I teach CBK review seminars, I start with the security management domain.  Yes, Gary is right that this field started out with a bunch of technical people who had difficulty understanding that people don't always do what you tell them.  So candidates coming in, who are not prepared for dealing with human factors, get a good scare right off the top.  They have to deal with management, which means dealing with people (and probably politics).  And organizational roles (which have to do with people).  And security awareness training. (Oh, and ethics.)

Moving on to access control, we talk about social engineering there.  (As well as the password choice problem Gary mentioned.)  Good scope for human factors.

Crypto's a technical field, so no human factors, right?  Wrong.  We talk about implementation problems, and the inability of people to be truly random.

Physical security talks about human factors.

BCP talks about human factors.  As long as you are truly recovering the business, as you should be, and not just systems.  (Common mistake.)

Security architecture is pretty technical.  But it deals with the security frameworks, with all those guideline documents.

Applications security has a lot to do with human factors.  (If you actually do it properly.)

Telecom?  Sure, that's technical.  But it also has to do with spam, social networking, phone phreaking, and all kinds of social engineering/human factors implications.

Operations?  You're dealing with people.  In fact, most of the stuff in operations could equally be dealt with in other domains, except for the extra provisions you have to make for your employees who need escalated privileges.  Your classic insider situation.

Law and investigation?  If you don't think that is mostly dealing with human factors, you are in the wrong field.

So, no, the CBK doesn't need to have human factors added.

If you want to talk about whether we need to pull all the human factors stuff out, and put it in a separate domain, that's a different question.

(And, to that one too, I'd say no.  We'd have a human factors domain that takes up three days of a five day seminar, and have to squish the existing domains into the remaining two days.)

Should the CISSP CBK be expanded to cover "human factors" in security?

Of all the areas in information security, human factors are the hardest to understand and even harder to influence or control, yet are often the deciding factors that make or break security in practice.  "Human factors" here includes answering questions such as what motivates hackers to hack, employees to follow or ignore policies and procedures, designers and developers to build-security-in, and managers to invest in security and compliance?  Does it matter that some people respond to threats and others to incentives, and that none of us is consistent in this?  And how can we best influence them all?  As information security pros, we have a *lot* to learn from other fields, including human psychology, marketing and education.

The problem, I feel, stems from the origins of this field in IT, hence a lot of what we read and obsess about still concerns IT security not information security.  Most of the time, computers do exactly what they are programmed to do: they are mechanistic and to some extent predictable.  They are complicated but barely "complex" (in the engineering or scientific sense).  Even a lot of the supposed "solutions" to security awareness out there in the market are technology "solutions", strongly focused on the technology, developed by technologists selling hard to their peers.  For me, the technology one can use to deliver awareness messages and imperatives to people is incidental and pales into insignificance compared to the actual messages and imperatives themselves.  We get hung up on arguing about whether the awareness PowerPoint slides should use bullet points or mind maps, or whether to use a wiki or document management system or learning management system - the "how to deliver" question rather than on *what* we should be saying to our audiences (and yes, thay's very definitely a plural!) that will have the most beneficial effects.  As I recall saying in that discussion, politicians (professional orators and cultural influencers) don't use PowerPoint.  Why do we?  We should focus far more on the content, not [just] the mechanism.

Here's a more concrete illustrative example: passwords.  Look at the average corporate policy and awareness messages on passwords to see a whole load of rules and complications, most inadequately explained, some rather obscure and a few actually harmful to our central security objectives around reliably authenticating the identities of individuals.  Go on, I challenge you to look at your own organization's verbiage on this single point.  Reducing all that lot to the 8-word security awareness message "Choose long, strong passwords and keep them secret", repeated often, would be a significant improvement in most cases.  I don’t want to kick off yet another boring argument about those 8 words, or all the things I have deliberately or accidentally left out, or particular situations in which those words are insufficient, or arcane discussions about the particular phrasing - that's realy not the point.  The issue is to simplify the message to its basics and figure out how best to get our simplified message across to everyone who needs to know it.  Are "policies" worth the paper or screens they're written on?  Do "awareness presentations" achieve anything other than annoyance and free lunches?  Do we need to add "rôles and responsibilities" and threaten "enforcement" to get "compliance", and what do we really mean by those terms in practice?   There are a million practical questions here that are far more interesting and much harder to answer than the issue of what our password policy should be, and yet where do we usually put almost all our effort?  Yes, we argue about the policy, and generally leave the "minor implementation details" to the technologists, who know lots about computers and not nearly so much about people.  It's just the same with corporate mission statements.  We obsess about the specific words, worry a little about the hidden meaning and largely ignore the implementation.

Here's another example of human factors: cognitive biases.  Bruce Schneier and others have noted that some of the ways we humans rationalise and deal with things are not necessarily the most appropriate.  Some human decision mechanisms are the result of millions of years of evolution as hunter-gatherers (which kind of puts that horror-of-horrors, the 'annual security awareness training seminar' into perspective!!).  So most of us will most of the time totally discount threats which we perceive as low or very low probability, even if the impacts would be catastrophic.  Most of us will most of the time click the "Go away and stop bothering me" option on security warning pop-ups, almost subconsciously.  Most of us most of the time are too caught up in our own little worlds to spot social engineers and fraudsters at play, or notice visitors wandering around the offices at will, or trap typos or .... whatever.  Again, the point is not the detail but the fact that we have cognitive biases, should be more aware of them, and need to take them into account in how we try to influence behaviour and get information security into the corporate or national culture ....

... And there's another thing.  What is "culture"?  What is "behaviour"?  What are awareness, training and education?  Do we need more carrot or stick, or is this just a false dichotomy while we are missing other equally or perhaps more important factors?  Is awareness/education an end in itself, or merely a step on the path to enlightenment and behavioural change?  There are library shelves filled with books and papers on issues of this kind, and a great wealth of creative approaches out there, some of which are far more effective than others.  I live and breathe this stuff but claim to know only a small fraction of it as it applies to information security awareness.  And yes, I too have cognitive biases, and I still hunt and gather!

That's why I'd like to see this area expanded substantially in the CISSP CBK and, by the way, in the ISO/IEC 27000-series standards too.  Security awareness gets a few light, low level mentions in '27002 but not nearly enough to emphasize its importance as a fundamental control underpinning pretty much everything else that we do to understand, manage and hopefully improve information security.

What do you think?  Comments are welcome.

-----------

PS  This monologue was first posted on the CISSPforum discussion forum for CISSPs and SSCPs.  Find out more about CISSPforum here.  Join the fun!

Treating risks

Convention has it that there are just four ways of "treating" risks:

1. Mitigate the risk, typically by reducing the associated threat, vulnerability and/or impact.
2. Avoid the risk by not doing something risky.
3. Transfer the risk, for example by forcing business partners to enter into a binding contract that places huge costs and liabilities on them for security breaches while leaving you appearing squeaky clean (don't laugh: PCI DSS does this).
4. Accept the risk.  Shrug your shoulders and accept that the costs of mitigating, avoiding or transferring the risk outweigh the advantages (as you perceive them).

Well I'm not so sure that's a complete list.  Here are some more possibilities:

• Explore the risk - which means doing things like analyzing or assessing the risk, researching the risk parameters and algorithms
• Ignore or deny the risk.  This looks a little like risk acceptance at first glance but it revolves around either genuine or feigned ignorance.  "It'll never happen to me" is one justification.  "It hasn't happened so far" is another variant, "so it probably won't".  "You don't know it will happen, since your risk analysis is full of holes and ridiculous assumptions" is only marginally better than "Trust me, it's not a problem."
• Exploit the risk, which is of course what hackers, fraudsters, scammers, industrial spies and other Bad Guys do (in the information security context), and how arbitrageurs, forex traders, bankers, corporate treasurers, insurers and other Good Guys do (in other contexts).  Summed up by "Run with it, live dangerously and enjoy the rush' (a.k.a. the bunjee jumper's guide to risk management).
• Hype the risk, with its corrollary, downplay the risk, which is what politicians do all the time.  "Folic acid in your bread will reduce the risk of neural tube defects" says one.  "Folic acid in your bread will increase the risk of cancer" says another.  "What's folic acid?" say most of the population, "Pass me the butter."

I'm sure there are still others ... comments welcome ...

Are policies mandatory and guidelines optional?

Although this is often expressed, I fundamentally disagree that policies are mandatory whereas guidelines are optional.  This to me is a rather naïve assessment, and is distinctly unhelpful, misleading even.  Let me explain.

For a start, do you truly understand the distinction between "mandatory" and "optional"?  Are they really (as some claim) as different as binary and analogue?  I beg to differ.  In my world, they are both analogue concepts.  They are both a matter of degree.

Occasionally by "mandatory" the information security manager or CISO probably does mean an absolute hard-and-fast rule with no exemptions (authorized non-compliance) or exceptions (unauthorized non-compliance) whatsoever being permitted.  However this kind of binary situation tends to be rather unusual in information security.  More often, "mandatory" statements are in fact very strong requirements or obligations but if there are justifiable reasons for not complying, that's probably OK provided the resulting risks are understood and are acceptable to management - an important proviso.*  You may take the hard line that policies can only contain absolutely mandatory statements, in which case you will end up with an admirably succinct set of policies ... but a long list of exemptions and exceptions.  This mess is not easy to read, and worse still implies that exemptions and exceptions are the norm, not the exception (if you get my drift).

Likewise, "optional" could mean 'go ahead if you feel like it, otherwise ignore this and do whatever you want' but more often means 'advisory' or 'recommended' or 'strongly recommended' or 'ignore this at your peril' with many other context-dependent interpretations.  In other words, "optional" is not a specific strength of requirement but a broad range, meaning something slightly to a lot less than absolutely mandatory. 

There's nothing wrong in my book with policies offering implementation guidance as well as requirements, provided the wording is such that the intention is clear either way.  Words such as 'must' and 'shall' and 'will' normally mean firm requirements, whereas 'may' and 'should' and 'ought' and 'could'  and 'can' normally imply some discretion.  It is entirely appropriate for policies to allow management and possibly staff discretion in some circumstances, without the need always to create and seek management approval for a formal policy exemption or ending up by default with a policy exception. Furthermore, little bits of helpful advice and explanation such as examples make the requirements clearer.  Flexibility in the wording and interpretation can make a policy much more readable which creates a very important benefit per se: policies that are too formalised and/or attempt to lay out explicit requirements for all possible circumstances are stilted, difficult to read and hence are mostly not read in practice.  Read a typical contract or law, in detail, to see what I mean!  If you really intend your information security policies to sit on a shelf collecting dust until used in anger by the lawyers, go ahead with this approach but that is not generally accepted good information security practice.

Again, if you feel that guidelines are purely advisory, then you need to be extremely careful not to even mention any mandatory rules, requirements, laws or other obligations unless you have very deep pockets, since you will create a serious earning opportunity for the lawyers.  Guidelines often refer to more or less mandatory requirements from the policies and standards, offering tips or advice on how to implement them.  If you view the organization's policy/standards/procedures/guidelines etc. as a classic layered triangle, the mandatory requirements are formally identified in broad terms in the upper level/s of the triangle and trickle down through the entire hierarchy, with more and more helpful explanatory advice and details being added to items at the lower levels. 

Therefore many things identified in a typical guideline will in fact be considered mandatory, whereas others are merely helpful suggestions.  Careful wording can or rather should make the distinction clear.  Mandatory requirements or obligations are often identified by referencing applicable policy statements.  In some cases, the exact wording may be formally quoted from a policy, and then "interpreted" in the guideline for one or more specific contexts. 

Finally, I'll just mention that essentially the same considerations apply to standards, procedures, advisories, recommendations, briefings, acceptable use policies, terms and conditions of employment and a million other things we use at work.   It's a brave or foolhardy information security manager/CISO who states categorically that particular documents are either totally mandatory or optional.

Bottom line: if you really intend to take such a clear-cut line on the differences between policies and guidelines in terms of the mandate or obligation to comply, be aware that in so doing you will be creating a whole new set of problems.

Kind regards,
Gary Hinson CISSP
ISO27001security
NoticeBored
IsecT

* Even laws work this way.  The police and judicial systems have some discretion in applying them.  Some commonplace practices break the laws and are strictly-speaking illegal, but offenders are not necessarily prosecuted or if they are may be given nominal penalties.

Passwords are dead - long live passwords

Over on CISSPforum, a zombie topic about passwords has risen from the dead yet again.

This time, someone suggested making it a "condition of employment" that "If you cannot remember a username and password, find employment elsewhere."

Well yeah but no but.  A username and A password, even a reasonably strong one, would be just fine for most people.  Unfortunately, we need loads. 

As information security pros, isn't it part of our rôles and responsibilities to make information security as low-impact as possible on the organization (including its 'most valuable assets', the people) without unduly compromising the level of security? 

Forcing people to choose lots of complex/strong passwords, change them often and remember them is, like it or not, quite a challenge for the average human, me included.  I long since gave up trying to think up and remember strong passwords for all the websites I visit.  For a while I wrote down the passwords and secured the piece of paper as best I could.  Pass phrases worked better but then I just confused myself by inventing obscure rules for punctuation and 133tne55 and, with senilility approaching, I have trouble remembering the userID bit too. 

Now I use a password vault which allows me to create, securely store and instantly recall totally ridiculous passwords, up to the maximum length permitted by the authentication system (1000+ character password? No problem sir, here you go.  Fancy another?  Poof!  Your click is my command) and as complex as a highly complex thing on Complexity Day.  All I need do is remember one strong password/passphrase to unlock the vault and through constant practice I'm getting pretty good at doing that, thanks to setting the password lifetime setting to "blue moon".  I can store passwords and notes for other non-web-based systems too.

Yes, I'm putting my eggs in one basket and yes I absolutely do appreciate the risk of so doing.  I agonised over this.  On balance, my risk assessment convinced me that, compared to the bits of paper and occasional lock-outs (plus those dumb password reset questions or 'Thank you.  We have just emailed your password in clear to an email account you placed on record with us five years ago.  Have a nice day'), the vault's implementation of AES, coupled with my ability not to disclose the vault key, wins easily.  And yes I take care over that non-disclosure bit, for example never typing it into public-access PCs, and using a strong password/phrase.  And being a paranoid security geek, I'm seriously thinking about buying a USB stick with a fingerprint reader to armour-plate the egg basket.

In this case, at least, technology CAN make the world a more secure place.

Regards,
Gary Hinson CISSP
NoticeBored information security awareness

Please don't reply to this blog entry here - join in the discussion on CISSPforum. 

The folly of annual "awareness training"

Hord Tipton is quoted in a rather curt piece on GovInfoSecurity referring to the "Need to provide federal employees awareness training more often than once a year because of the ever-changing challenges IT security presents".  Right-on Hord!  I realise I'm quoting a small extract from a short piece about a press interview, but still there's much more to it than Hord's statement implies.  I hope you'll forgive me a short but passionate rant ...

1.  It's not just federal employees who need more than once-a-year training.  The same applies to everyone, including employees (staff, managers, IT professionals, temps, contractors, consultants, auditors ...), students, retired people and other ordinary members of the general public.  And yes, even CISSPs.  A once-a-year training session falls way short of what any rational professional would call Continuous Professional Education.

2.  What is "awareness training" anyway?  In my experience, it's management doublespeak for a lecture at the troops - a broadcast, a sermon maybe, but almost invariably tedious, dull and worse than that, annoying to all concerned.  Management get to spout off at the workforce about what they should and should not do.  They lay down the corporate law, usually with implied or explicit threats to thrash the message home.  Such sessions take time out of busy worklives, and are attended under sufferance (not because the audience actually want to go along and learn new stuff, but because they are told in no uncertain terms that they "just have to go").  Conceited or naive managers tick the compliance box that says "Security awareness - done" and move onto 'more important things'.  In reality, what I'm talking about is neither awareness nor training.  It's an amateur attempt at brainwashing.  It shows an amazing lack of creativity and understanding of human psychology.  The only motivation it achieves is to encourage staff (and, I bet, some managers) to find ways to evade future sessions.

3.  IT does indeed present ever-changing challenges, but so too does the organization, its business, the commercial & regulatory environment, the people, the compliance obligations, the consequences of failure, the hackers, the malware, the criminals, the competitors, the peers, the partners ... Oh and, by the way, it's not just a matter of IT security.  Information security takes in the obvious things such as indiscreet conversations and leaving sensitive papers on public transport, but more subtly it concerns protecting information assets, meaning the information content, the meaning,the knowledge, the expertise and experience - which goes way beyond the data or IT.

Surely by now we all know annual awareness sessions simply don't work.  It's really not hard to poke giant holes in the concept but why does this ridiculous "annual awareness" thing refuse to lay down and die?  I doubt any CISSP would seriously contend that subjecting employees to an "awareness training session" (whatever that might be) is going to achieve anything beneficial past the first few weeks, days, hours or minutes, let alone persist until the next year's session.  Would you allow someone to drive a car on the basis of a "driving awareness training session" once a year?  Would you be happy to don the face mask and place your most valuable personal assets in the hands of a surgeon who did a "surgery awareness training session" nearly a year ago?  It's totally nuts, yet it keeps coming up like a dreaded zombie back from the grave to haunt us.

What concerns me most is that merely repeating the phrase (which I appreciate, ironically, is exactly what I am now doing) "annual security awareness training sessions" furthers the myth that that's what is meant by security awareness and/or security training, which are in fact quite distinct ideas.  Worse still, since we all know that these annual sessions are a worthless and insufferable waste of time, it implies that both security awareness and security training are also worthless and insufferable.  Doh!  That's a classic example of throwing the baby out with the bath water.

Consider for a second the modern aircraft and its pilot.  The cockpit is stuffed full of the most amazing technical wizzardry, designed to make flying as safe, cost-efficient and generally pleasant as possible for all involved, a large part of them designed to make the pilot's job simpler and easier than ever ... yet we don't let just anyone sit in the hot seat and fly us to Barbados.  Pilots undertake intense training courses on the ground before even taking to the skies, and then are required to clock so many hours flying experience before being granted the privilege of becoming a qualified pilot - and yes it is a privilege that carries a heavy responsibility.  They have further on-the-job training and flight simulator exercises to complete, and regular assessments to keep them up to date with the latest technologies, flight rules and so forth, throughout their careers.  They meet and converse with other pilots, taking an interest in new risks and opportunities in flying.  They develop a very personal passion or love for what they do.  They get it.

OK, now switch scenes to the average corporate "end user" (surely a perjorative term, but quite apt in this context) - largely untrained, almost always unqualified and yet sat there in the hot seat playing with corporate and personal information assets with hardly a thought as to their protection or security.  The PC is merely a tool to him, one that belongs to the evil corporation that makes him work for a living.  Are we surprised they don't get it at all, even right after one of those dreadful "annual awareness training sessions"?

Right, switch scenes again to the classic geek hacker, all tattoos and piercings and black hoody - self trained, knowledgeable, committed and yes intensely passionate about what he does, with a deep fascination and respect for the technology.  His PC is an art form, a thing of joy, an altar even.  He inhabits a parallel universe to the end user.  When end-user-man knocks off work at 5pm and traipses dejectedly home, the last thing he wants to do is "sit in front of the bloody PC all night", whereas that's exactly what geek-hacker enjoys most.  Once the bytes start flying, the endorphins are released and before he knows it, it's dawn and time to get ready for work. 

In computer security terms, it's a seriously unfair fight.  In the blue corner, end-user man just wants to do his job and have an easy life.  In the red corner, geek hacker wants to pwn his b0x, and has the tools, expertise and motivation to get it (and these days, someone wants to pay him serious money to do it for him).  Meanwhile, the poor old security manager does his best to gee up end-user-man from the sidelines but knows there's not going to be a pretty ending.

Well maybe I've seriously over-stretched that analogy and taken the parody too far but what I'm really getting at is that end-user-man desperately needs effective information security awareness and training to:

• Inform him about the information security risks all around him, in terms he can relate to;
• Show him how to recognise and tackle those risks, in pragmatic terms he can actually use;
• Give him the skills and tools to do stuff securely, and the sense to report stuff that is patently not right;
• Motivate him to take an interest in protecting both the corporation's information assets and his own;
• Remind him of his obligations, meaning accountability and responsibility towards behaving securely;
• Light that spark of passion, that interest and feeling of control over his own destiny, that will enable him to take the fight to the other corner.  Until and unless we get to this stage, constently and repeatably, "awareness training" is doomed.  We'll never create a security culture by shouting it down employees' earholes once a year.

That's it, relax, rant over.  Now it's your turn.  What do you think?

P.S.  Even mighty SANS refers to "awareness training" and "at least an annual basis".  At the bottom of the latest SANS list of 20 Consensus audit guidelines is one recommending Security skills assessment and training to fill the gaps.  The SANS advice includes: "Organizations should develop security awareness training for various personnel job descriptions. The training should include specific, incident-based scenarios showing the threats an organization faces. The training should reflect proven defenses for the latest attack techniques.   Organizations should devise periodic security awareness assessment quizzes, to be given to employees and contractors on at least an annual basis, determining whether they understand the information security policies and procedures for the organization, as well as their role in those procedures."

NIST SP800-16 - revised draft security training standard

I've been reading and thinking today about a revised NIST Special Publication SP800-16, currently released for public comment. If you are genuinely interested in making security awareness more effective, I recommend setting aside an hour or three to read and consider the draft document.

To whet your appetite, here are just a few short paragraphs from one section of the draft, with my own thoughts and comments cited below.

Under section 2.2.1 of SP800-16, NIST says:

"Awareness is not training (1). Security awareness is a blended solution of activities (2) that promote security, establish accountability, and inform the workforce of security news (3). Awareness seeks to focus an individual’s attention on an issue or a set of issues (4). The purpose of awareness presentations is simply to focus attention on security (4). Awareness presentations are intended to allow individuals to recognize information security concerns and respond accordingly. (2)

In awareness activities the learner is a recipient of information, whereas the learner in a training environment has a more active role. (2) Awareness relies on reaching broad audiences with attractive packaging techniques. Training is more formal, having a goal of building knowledge and skills to facilitate job performance. (5)

A few examples of information security awareness materials/activities include:
• Events, such as an information security day,
• Briefings (program- or system-specific or issue-specific)
• Promotional/specialty trinkets with motivational slogans,
• A security reminder banner on computer screens, which comes up when a user logs on,
• Security awareness video tapes, and
• Posters or flyers. (6)

Effective information security awareness efforts must be designed with the recognition that people tend to practice a tuning-out process called acclimation. If a stimulus, originally an attention-getter, is used repeatedly, the learner will selectively ignore the stimulus. (6) Thus, awareness delivery must be on-going, creative, and motivational, with the objective of focusing the learner's attention so that the learning will be incorporated into conscious decision-making. This is called assimilation, a process whereby an individual incorporates new experiences into an existing behavior pattern. (3 & 5)

Learning achieved through a single awareness activity tends to be short-term, immediate, and specific. For example, if a learning objective is “to facilitate the increased use of effective password protection among employees,” an awareness activity might be the use of reminder stickers for computer keyboards. (7)

The fundamental value of information security awareness programs is that they set the stage for awareness training and role-based training by bringing about a change in attitudes which should begin to change the organizational culture. The cultural change sought (8) is the realization that information security is critical because a security failure has potentially adverse consequences for everyone. Therefore, information security is everyone’s job. (9)"

My comments:

(1) The terms "awareness", "training" and "education" are often used interchangeably and sometimes combined, as in "awareness training". However, they are different activities with different mechanisms and purposes. SP800-50 “Building an Information Technology Security Awareness and Training Program” covers this point rather eloquently, better in fact than SP800-16 and FISMA which tie themselves in knots over the terminology.

(2) If you can read past the much abused second word of "blended solution of activities", the real point is that awareness requires a range of separate but complementary activities - and by "activities" I mean things that involve physical actions by both the information givers and the information receivers. I am talking about proactive learning, not passive entertainment or "edutainment". The most important part of a training course is not the presentation slides or other materials, the presenter, the facility or the audience: it's the engagement, interest and interaction that happens when members of the audience become inspired to think about and then change what they do thereafter.  Actions speak louder than words.

(3) Informing people, in other words providing relevant facts about information security risks and controls, is an important element of awareness, training and education but is not in itself sufficient, in most cases. Erudite but boring and dry factsheets have limited impact and can be counterproductive. News stories are just one way to bring information security to life, reminding people that we are not talking purely hypothetically about security incidents. They are really happening around us, and not just Out There in the news headlines but much closer to home, affecting us, our colleagues, friends and families, and of course our organization and society. Getting personal on information security matters is a good way to engage with people.

(4) Focus is important. Generic, bland "be more secure" messages are a total waste of brain cycles. People need to know what, specifically, they should be worried about and what they should do ... but first they need to open up in order to even receive the message. Making people "wake up and smell the coffee" is one option but is not the only way (I'll speak about other techniques another time). Focus, to me, includes getting straight to the point - being direct and avoiding unnecessary fluff or irrelevancies. It also includes picking on specific information security topics, providing more depth than is typical of those rushed security induction training classes.

(5) Building knowledge and skills to enhance job performance is all very well but has little value unless people actually use the knowledge and skills when they get back to work. Achieving this is the crux of effective awareness, training and educational activities. Unless people are taken beyond the point of being mere receptacles for facts and are motivated to behave more securely, the program is not going to earn its keep.

(6) Notice that "forcing employees to sit down en masse in a stuffy meeting room or lecture theatre while some boring IT geek or clueless manager spouts off about information security" does not feature in NIST's list of worthwhile activities, but is not far from the truth in some organizations! Awareness, training and education take creativity and passion. It's not that hard really.

(7) Taking focus to the extent of a single awareness activity covering just a single information security control might perhaps be necessary if that one control is conspicuously failing but seems unlikely to cover the full breadth of security controls that employees should understand and respect, in any reasonable timeframe. Coupling this point with comments about keeping the content interesting implies to me the need to run quite rapidly through a sequence of topics, moving ahead at or just before the point that eyelids start to droop. This idea of a rolling awareness program, in my experience, makes all the difference but there's one more little point to bear in mind. "Sequences" can be random or directed. A random assortment of information security topics may achieve the coverage desired but misses the opportunity to link together successive topics into a more coherent security story. Being smart about the sequence and scope of the topics leads to a more subtle form of the old teacher's saw "Tell them what you are going to tell them, tell them, then tell them what you told them". We can introduce future topics and refer back to previous topics, all while delivering the present topic. The interrelatedness of information security topics makes this quite easy to achieve with just a bit of thought and planning. The advantage is a level of coherence and reinforcement that random assortments don't achieve.

(8) Now there's a thought: we are seeking "cultural change" are we? Great idea, one I thoroughly endorse ... but unfortunately for many managers, security awareness is less about achieving cultural change than about "being seen to be Doing Something" or, even worse, "doing it for compliance reasons". Health and safety training finds itself in the same pickle. Effective H&S training has a lasting impact on what employees do as they go about their normal business activities, long after the ink has dried on the training evaluation forms. It's about putting on the ear muffs and safety goggles even when there's nobody else looking. It means taking a moment to deal with a trip hazard in a public thoroughfare even when you yourself have clearly spotted and avoided the hazard. Achieving cultural change to create a "culture of security" is a fabulous objective, one that's much easier to say than to do. For me, it goes somewhat beyond the rather simplistic if important ideas noted in section 2.2.1, picking up concepts such as:

• Providing continuity - planning awareness activities over the long term (and I don't mean 'scheduling next year's security awareness session'!);
• Addressing the entire organization (staff and managers), in fact the scope can usefully cover the extended organization including friends and relatives of employees, contractors/consultants, outsource suppliers, customers, suppliers, business partners, other stakeholders and, to some extent, society at large
• Using creativity to create interest and engage people with the program, and retaining that interest indefinitely;
• Being sensitive to cultural norms, communications preferences and so forth for the audiences - notice the plural: it makes little sense to focus all the security awareness activities on one homogeneous audience when we know full well that business units, departments, teams and individuals vary markedly in many key respects. "Selling" copyright compliance to, say, an Indian or Chinese business unit is a rather different prospect to getting the same point across to a Scandinavian organization. For some people, the 3 minute high level overview is more than enough: for others, 3 minutes would not be nearly enough for the briefest of introductions;
• Taking audience engagement to the extent of active audience participation, for example encouraging managers, IT professionals and employees to converse on the same information security topic, putting their respective points of view in the context of a shared understanding of the terms and concepts involved.

(9) If "information security is everyone's job", it ought to be in everyone's job descriptions - not a bad idea in itself but I feel there's a bit more to it. "Information security is everyone's responsibility" takes it a step further since it is not purely a job-related thing, and hints at a vital security concept, that of ownership, accountability and responsibility. "Information security is what we do" might be a bit excessive, but I prefer the word "we" in there since it is clearly a shared responsibility. [Arguing about the specific meaning and nuance of every word smacks of the crazy process of developing corporate mission statements. However, the discussion is at least if not more valuable than the product, rather like planning and plans. Discussing such security principles leads to a common understanding and is a good way to engage senior managers with the awareness program.]

Right, that's section 2.2.1 duly considered. I'll stop there for now, leaving consideration of the remaining 156 pages as an exercise for you dear reader - homework if you will. NIST welcomes comments on the draft SP800-16 until June 26th 2009 by email to 800-16comments@nist.gov.

Kind regards,
Gary Hinson
NoticeBored