Phishing awareness module imminent

Things are falling rapidly into place as the delivery deadline for October's awareness module on phishing looms large.

Three cool awareness poster graphics are in from the art department, and three awareness seminars are about done. 

The seminar slides and speaker notes, in turn, form the basis for accompanying awareness briefings for staff, managers and professionals, respectively.  

We also have two 'scam alert' one-pagers, plus the usual set of supporting collateral all coming along nicely - a train-the-trainer guide on how to get the best out of the new batch of materials, an awareness challenge/quiz, an extensive glossary (with a few new phishing-related terms added this month), an updated policy template, Internal Controls Questionnaire (IT audit checklist), board agenda, phishing maturity metric, and newsletter.  Lots on the go and several gaps to be plugged yet.

Today we're ploughing on, full speed ahead thanks to copious fresh coffee and Guy Garvey singing "It's all gonna be magnificent" on the office sound system to encourage us rapidly towards the end of another month's furrow.  So inspirational!  

We've drawn from at least five phishing-related reports and countless Internet sources, stitching together a patchwork of data, analysis and advice in a more coherent form that makes sense to our three audience groups. I rely on a plain text file of notes, mostly quotable paragraphs and URLs for the sources since we always credit our sources. There are so many aspects to phishing that I'd be lost without my notes!  As it is, I have a headfull of stuff on the go so I press ahead with the remaining writing or I'll either lose the plot completely or burst!

For most organizations, security awareness and training is just another thing on a long to-do list with limited resources and many competing priorities, whereas we have the benefit of our well-practiced production methods and team, and the luxury of being able to concentrate on the single topic at hand. We do have other things going on, not least running the business, feeding the animals and blogging. But today is when the next module falls neatly into place, ready to deliver and then pause briefly for breath before the next one. Our lovely customers, meanwhile, are busy running their businesses and rounding-off their awareness and training activities on 'outsider threats', September's topic. As those awareness messages sink in, October's fresh topic and new module will boost energy once more and take things up another notch, a step closer to the corporate security culture that generates genuine business returns from all this sustained effort.

From weariness via wariness to awareness

Weary of the same old stuff, day after day?  Wary of over-blown threats, confusing security controls and crude "Do it or else!" compliance demands blasted out repeatedly and loudly in the vain hope some might just stick?

Us too! Those are common issues in awareness and training, betraying a lack of appreciation and respect for the audience. We can do better. 

No really, we must.

Awareness and training leading to understanding and genuine support for security is our way. We take the trouble to pick-apart complex issues such as phishing and pharming, explaining them straightforwardly with plenty of diagrams and examples to inform, engage and motivate three distinct audiences. We spend at least as much time exploring the broader context to the issues, explaining why they are of concern, as we do telling people how to respond, what to do and not to do. We are addressing intelligent adults through soundly-researched content, professionally crafted for this specific purpose.  

There's more to this than meets the eye. More Haynes manuals and exploded parts diagrams than childish cartoons or death-by-PowerPoint bullet points.

Our innovative approach to security awareness shines through topics such as phishing. Social engineers, identity thieves and other fraudsters are actively innovating, constantly on the search for new tricks to phool even wary victims. We can only get so far by talking about previous and current attacks because there's something new on the way tomorrow or the day after. Future-proofing requires a deeper appreciation of our adversaries' motivation and techniques ... which is part of the awareness challenge. 'Think like a phisher' is much easier said than done. On top of that, we must remain ethical, steering well clear of accidentally encouraging people to become phishers!  

Right there is an example of an information risk that few organizations even consider - not so much inept awareness and training as the possibility of phishing being committed by insiders against their colleagues and employer. Having covered insider threats and outsider threats in the previous two months, we have laid the foundation to take things up a level in October's awareness module.

Enough blogging: must dash. I have to 'revalidate my login' to avoid losing my email account, again ... 

What is security architecture?

A newcomer to the ISO27k Forum asked one of those disarmingly simple or naive-sounding questions today, the kind that turn out to be fascinating once we scratch beneath the surface.

"I am currently assigned task to perform security architecture review. Can anyone help me with reference links to start off with?"

It would be inappropriate to offer suggestions and press ahead without first understanding the objectives, expectations and constraints, hence the obvious starting point (from my perspective) would be to figure out what a “security architecture review” is - more specifically, what management (or whoever assigned the task) expects from it e.g.:

• What are its aims/purposes or drivers? 
• Where did it spring from? What triggered it? Why now? Why you?
• Is it business-led or IT or infosec or risk or what? Who is behind it? Who stands to benefit or be affected by it? Who are the stakeholders? Are they supportive and engaged, neutral/unaware, or reluctant and disengaged?
• What is it expected to lead into – if anything? Is the outcome entirely open at this point, depending on what the review finds, or are there pencil marks or proposals on the table already, perhaps secret agendas looking for fuses to light?
• What is the scope? Is it meant to be reviewing all of 'security' (whatever that means), or information security, or cybersecurity, or compliance, or strategy, or assurance, or software development security, or information flows, or something else? And why is that - what determines the scope? Why are some things in and others out of scope?
• And, not least, what is ‘security architecture’, or indeed 'architecture', in the specific context of the organization? In some organizations, architecture is central to strategy, making it the domain of senior, experienced managers, who are unlikely to task a clueless underling to review it. To others, it's about blueprints (literally) showing plan and elevation views, and Crime Prevention Through Environmental Design.

These are not facetious or trivial questions: to my mind, there are lots of possibilities which affect the review substantially - such as its priorities, depth, scope, timescale, assurance and so on. It's basic navigation really:

Before plotting the route, where are we
on the map ... oh and where are we heading? 

For example, a "gap analysis" comparison of the organization’s information risk and security management practices against the recommendations in ISO/IEC27001 and 27002, is one possible approach. But that may not be what the organization is expecting from its "security architecture review" ... and that's not the only interpretation of "gap analysis"!

Another possible approach would be a strategic/high-level review of the organization’s information risk management practices and/or its suite of information security controls, with a strong emphasis on how things are or should develop over the next few years. Are there suitable foundations on which to build a solid ISMS with all the appropriate controls and other risk treatments in place? If not, what are the gaps and how might they be filled-in? Are there, for example, any other business, change, IT or other strategic initiatives on the horizon that might be opportunities to deliver substantial parts of the ISMS, with strong business backing and hopefully the funding to suit?

Yet another possibility is an audit/review of the organization’s current ‘security architecture’, a chance to determine how effective it is and has been, historically, forming the basis for revision, renewed emphasis or simply endorsement going forward. Is the organization poised to align its security arrangements with business objectives, technology trajectories and so forth? 

Those are substantially different approaches, just for starters, based on the forum question. We're some way from answering it at this point!

What is the best development method for security?

In answer to someone on CISSPforum asking for advice about the impact of various software development lifecycles, methods or (as if we need another ology) methodologies, I asserted that the SDLC method affects the way or the manner in which infosec is achieved (spec'd, built, confirmed, delivered, used, managed, monitored, maintained ...) more than how effective it ends up being.

There are pros and cons to all the methods - different strengths and weaknesses, different purposes, opportunities, risks and constraints. Software or systems development involves a load of trade-off and compromises. For example, if information risks absolutely must be minimized, formal methods are a good way to achieve that ... at huge cost in terms of both the investment of money and time for the development, and the functionality and rigidity of the developed system. However, an even better way to minimize the risk is to avoid using software, sidestepping the whole issue!

In most circumstances, I would argue that other factors are more significant in relation to the information security achieved in the developed system than the choice of development method e.g.:

• Governance, management and compliance arrangements, especially around the extended dev team and the key stakeholders;
• Strategies (e.g. business drivers for information security), priorities, resources available (including maturity, skills and competence on infosec matters - not just $$$);
• Policies and standards, especially good security practices embedding sound principles such as:
• Don't bolt it on - build security in;
• Be information risk-driven;
• Address CIA and other security, privacy, compliance and related matters;
• Secure the whole system, not just the software;
• Focus on important security requirements and controls, taking additional care, increasing both strength and assurance over those;
• Later security, in anticipation of layers being breached: make it harder and more costly for adversaries and incidents to occur;
• Trust but verify;
• Accept that perfect or absolute security is literally unachievable, and security maturity is more quest than goal, hence provide for resilience, recovery and contingency as well as incident management and continuous improvement.
• Well-defined critical decision points, sometimes known as hurdles, stage gates etc., plus the associated criteria and assurance requirements, plus the associated management processes to measure progress, handle issues, re-prioritize ...;
• Corporate culture, attitudes towards information risk, infosec, cybersec, IT, compliance etc., among management, the intended system users, IT and the dev team, plus awareness and training;
• Documentation: more than simply red tape, good quality documentation on information risk and security indicates a mature, considered, rational approach, facilitates wider involvement plus review and authorization, captures good practices and helps those not closely involved with the project appreciate what is being developed, how and why;
• Systems thinking: alongside people, hardware, networks and other system, and dynamics, the software is just part of the bigger thing being developed;
• Team working: high performance teamwork can achieve more, better security and higher quality products with the same resources, especially if the extended team includes a wide range of experts, users, administrators, managers and more;
• Suitable metrics, such that 'more, better security and higher quality products' is more than just a hand-waving notion, becoming criteria, measures and drivers;
• Risk and change management practices and attitudes, maturity, support, drive etc.;
• Most of all, the deep understanding that underpins sound requirements specs, planning and execution, and leadership: infosec is an integral part not a bolt-on, ideally to the point that it is taken for granted by all concerned that It Will Be Done Properly.

I would love an opportunity to try out dev-races, where two or more development teams set out in parallel to build and deliver whatever it is, in friendly competition with each other. They will all have the same fixed specs for some aspects of the delivery, but latitude to innovate in other respects e.g. methods/approaches.  At the appropriate points during the project, the 'losers' admit defeat and either depart or join the 'winners', pushing through the final, toughest activities together on the home straight.  At first glance, it sounds like it will double the costs ... but that's only for the early stages, and has the advantages of improving both motivation and the end product.  Personally, from both the security and business perspectives, I see more investment in the early stages as an opportunity more than a cost!

Phishing awareness

Today marks the end of a long but successful week. We've been slogging away at the phishing awareness topic for October's module, picking out the key issues, coming up with the awareness messages and figuring out the stories to tell.

Despite technology being such a small part of phishing, it plays an important part that we can't just ignore. Multi-Factor Authentication, for example, is increasingly being used by organizations that care about identification and authentication, so workers are quite likely to have at least heard of it, even if they are not actually using it as yet. Explaining what MFA is would set them up to appreciate what it means when they are offered or required to accept it.

At the same time, MFA is not a universal or ultimate solution. Managers and professionals should appreciate that there are pros and cons to implementing MFA, and lots of choices in exactly what form of MFA the organization might adopt ... but explaining all that in detail would divert or distract attention from  phishing, the main subject. 

Fortunately, we don't need to delve too deep. The rolling monthly sequence of topics means we can pick up on MFA and other aspects another time, without feeling guilty about just skimming over in October.

By the same token, although we haven't delivered an awareness and training module purely on phishing for some time (too long really), we have mentioned/skimmed it repeatedly, several times a year in fact, in the course of covering other topics such as email security, Internet security, malware, social engineering and fraud. 

That's enough for now. Time for a break, re-girding our loins prior to finalizing and polishing October's materials next week.

Which reminds me, why are loins girded anyway? What's that all about, Google?

Attendance stats

Someone's attendance at, or absence from, a security awareness and training session or event is, at best, a rough indication of their involvement and engagement with the awareness and training program and yet it is often used as a measure, a metric. Why is that?

Clearly, if someone fails to show up at all, they are hardly going to benefit from the sessions ... but a well-rounded awareness and training program will not rely solely on in-person classes, seminars and similar events: it will typically have an intranet site, maybe newsletters, emails, discussion forums, posters and more. Hence is it certainly possible for someone to be engaged with the program and highly security-aware even if they do not attend the events for some reason (e.g. they may be forgetful, too busy doing other stuff, disabled, working night shifts, low on energy, sick or on vacation, antisocial, not keen on that style of learning, perceived lack of value or purpose ...). Nevertheless, nonattendance generally signals a lack of engagement.

In contrast, someone who shows up at every session without fail appears to be highly supportive of the program - but are they really? Or are they just keen to escape the office drudgery, dozing quietly at the back of the class maybe? 

Most workers (including the session leaders or trainers!) lie somewhere between those extremes: they attend a proportion of events depending on various factors. It is not unreasonable to assume that most attendees are demonstrating some level of interest in or engagement with the awareness program, their attendance rate across multiple sessions presumably correlating with their interest and engagement levels.

From another perspective, attendance rates at various awareness and training events are indicative of the popularity and perceived value of the sessions ... but again there are several factors at play (e.g. the particular topics being covered, the quality of the venue and catering, the quality of the trainer/leader, the supportiveness of the social environment both in and out of class) in addition to all the reasons why a given worker may or may not attend. Provided the attendance data are sufficiently accurate and representative, trends may indicate the awareness program's success or failure, strengths and weaknesses among the training team, popular or unpopular topics, venues, timing and formats etc.

Another reason for recording and reporting attendance is to demonstrate activity and concern. For various reasons, although busy senior managers may be unable to attend many events themselves, they may be relieved to know the events are being held regularly and are being well attended. They are using attendance as an assurance measure, confirming that the organization's investment in information security awareness and training is achieving something beneficial. Hopefully.

One more reason for using attendance as a metric is that it is cost-effective to collect, relative to other possible metrics in this area: attendees at awareness and training events are simply recorded in some fashion, perhaps signing an attendance register or being counted by someone (perhaps even estimated). The raw data are readily accumulated, analyzed (e.g. to identify trends or proportions) and reported ... which brings up another issue: to whom would the information be reported or presented? Who would want to know attendance levels? When and with what purpose? 

Potential audiences include:

• Management: need assurance that the organization's investment in security awareness and training is worthwhile, and is achieving its objectives;
• Information risk and security awareness and training professionals: need data to help invest the organization's resources wisely, develop and deliver the activities most effectively, evaluate and compare various options such as different modes of delivery, trainers, topics and venues, and demonstrate their professionalism;
• Other stakeholders with an interest in the organization's information risk and security status, such as: owners; suppliers, customers and business partners; authorities (such as industry regulators); and compliance certification bodies;
• Human Resources: most are responsible for administering training records, some take a more proactive interest in personal development plans, awareness and training strategies etc.;
• Individual workers: some of us like to track our awareness and training activities along with other personal development, updating our resumes and plans accordingly.

Reporting intervals vary from weekly or monthly up to once every few years, or one-off, depending on audience needs. Reporting formats are equally diverse.

Bottom line: while they have their limitations, awareness and training attendance statistics potentially deserve being part of the organization's metrics mesh. 

Fragility

In preparation for a forthcoming security awareness module, I'm researching business continuity.  Today, by sheer coincidence, I've stumbled into a business discontinuity: specifically, the website for a commercial company advertising/sponsoring a popular multi-week New Zealand radio show promotion is currently unavailable. It seems to have been so fragile that it broke.

This is how the web page looks right now:

Mostly white space. 502 is the standard error message number indicating a 'bad gateway', meaning that the company's website cannot be contacted by some intermediate network system. It appears to be dead. Resting maybe.

The HTML code for the sparse error page is almost as sparse - just these 14 lines, half of which are comments:

DownForEveryoneOrJustMe.com tells me its not just my Internet connection playing up.  The website really is unreachable.

That's the NZ website. The company's Australian website is also unavailable, whereas its US site is up and running. 

nginx is the name of a webserver front-end load-balancer utility/application/system.  Given the radio promotion, it is possible the company is using nginx as a cache to reduce an anticipated heavy load on the webserver, or to balance the load across several webservers, but either way evidently it isn't working out right now.  

Summing up the situation:

• The company has planned and paid for a radio promotion including links to its website: management must have known this was coming;
• Management appears (at some point) to have made technical arrangements to cope with a heavy load on the webserver: presumably, it anticipated the risk of the website being overloaded;
• The technical arrangements appear to have failed: the website is currently unavailable;
• Either management doesn't know the corporate website is down (due to the lack of effective monitoring) or it knows but hasn't reacted effectively (maybe nginx was the response: it hasn't worked for me, today);
• The company has fallen off the web, making it hard for potential customers to make contact and do business;
• That, in turn, has implications for its public image: its brand is becoming somewhat tarnished by this incident. It's not a good look.

This is a classic information security (availability and integrity) incident with business implications. The website evidently wasn't sufficiently resilient, and the incident does not appear to have been handled effectively. 

Of course, we can only guess at some of this in the absence of further information. Perhaps my assumptions are wrong. Maybe the fault lies elsewhere and/or the situation is more complex than it appears. Conceivably, the site might even have been taken down deliberately as a response to some other incident. We just don't know.

But we do have a little case study for the awareness module. I'll continue checking the site to see what happens next - how the situation resolves and perhaps gleaning further information about the incident.

[I haven't named the company because it isn't necessary to do so, and I don't want to make the incident any worse for them than it already is by prompting YOU to go check out their website as well!]

UPDATE: by 9am the following day, both the NZ and Australian websites were back on the air.

The business value of infosec

Thanks to a heads-up from Walt Williams, I'm mulling over a report by CompariTech indicating that the announcement of serious "breaches" by commercial organizations leads to a depression in their stock prices relative to the stock market.

I'm using "breach" in quotes because the study focuses on public disclosures by large US commercial corporations of significant incidents involving the unauthorized release of large quantities of personal data, credit card numbers etc. That's just one type of information security incident, or breach of security, and just one type of organization. There are many others.

The situation is clearly complex with a number of factors, some of which act in opposition (e.g. the publicity around a "breach" is still publicity!). There are several constraints and assumptions in the study (e.g. small samples) so personally I'm quite dubious about the conclusions ... but it adds some weight to the not unreasonable claim that "breaches" are generally bad for business. At the very least, it disproves the null hypothesis that "breaches" have no effect on business.

Personally, I'm intrigued to find that "breaches" do not have a more marked effect on stock price. The correlation seems surprisingly weak to me, suggesting that I am biased, over-estimating the importance of infosec - another not unreasonable assumption given that I am an infosec pro! It's the centre of my little world after all!

Aside from the fairly weak "breach" effect, I'd be fascinated to learn more about the approaches towards information risk, security, privacy, governance, incident management, risk & security strategy, compliance etc. that differentiate relatively strong from relatively weak performers on the stock market, using that as an indicator of business performance ... and indeed various other indicators such as turnover, profitability, market share, brand value etc. I'm particularly interested in leading indicators - the things that tend to precede relatively strong or weak performance.

On the flip side, I'd be interested to know whether 'good news' security disclosures/announcements (such as gaining ISO27k or other security certifications, or winning court cases over intellectual property) can be demonstrated to be good for business. Given my inherent personal bias and focus on infosec, I rather suspect the effect (if any) will be weaker than I expect ... but I'm working on it!

Black market credit card values

An otherwise unremarkable marketing email from Armor caught my beady with this:

"Armor has been tracking hackers, on both English-speaking and Russian-speaking markets, and found that current prices for stolen U.K. credit cards (Visa, Mastercard and American Express), with corresponding CVV data and expiration dates runs $35 each, $30 for a European Visa, Mastercard or American Express card, and $15 for a U.S. Visa or Mastercard and $18 for an American Express card." 

That's quite a range of values. I wonder why some stolen credit card details are twice as valuable as others on the black market. What makes them so attractive, relatively speaking?

Possible reasons for the discrepancy:

• Market imperfections such as time lags between changes in supply or demand and price adjustments;
• Some are rarer, in relatively short supply, with consistent demand driving prices up;
• Vendors are simply taking advantage of 'market pricing': they charge whatever the market will bear, by reference to prices and sales for similar commodities;
• Buyers are price-insensitive: the purchase price is insignificant compared to the anticipated income;
• Demand is higher for some of them hence they are 'worth' more because: 
• Identity fraud is somehow easier with them (e.g. the card providers' anti-fraud controls are weaker, perhaps detection and prosecution of fraudsters is less likely?);
• Identity fraud is more lucrative with them (e.g. the accounts to which they link have larger balances and credit limits);
• They are more likely to be and remain active, less likely to have been or be deactivated by the companies or card holders concerned (perhaps they are less aware of and/or responsive to identity fraud?);
• The financial companies concerned and/or the authorities are actively buying up these cards in order to take them out of circulation, hoping perhaps to trace the sellers, in the process inadvertently driving up their market value (doh!);
• Buyers value them for some other reason: they are deemed to be of higher quality, maybe 'needed' to complete collectors' sets?;

• Statistical anomalies, truly random fluctuation, data errors and plain ol' mistakes e.g. we're not told how many of each type of card were on sale, nor is there any indication of the variance in prices;
• Ulterior motives and bias behind the reported numbers: they were, after all, included in a mass marketing email, an unsolicited one at that i.e. spam.

As usual, I'm quoting and citing the source to illustrate an analytical approach, not to discredit or challenge the source so much as encourage you, dear blog reader, to think critically about such information rather than taking it at face value. I've seen similar numbers from other sources ... which may mean they are 'in the right ballpark' but could equally be an example of anchoring bias (if people have no idea of the correct value, they tend to estimate within or near whatever range is suggested to them, focusing on and implicitly assuming that the suggested range is valid).

Just sayin'

Scary stats

In the course of researching phishing for our next awareness module, I Googled into a 2017 cybercrime report. It makes numerous dire predictions (such as "cybercrime will cost the world in excess of $6 trillion annually by 2021") and is stuffed to the gunnels with outrageously scary statistics (using "1,300 percent", for example, rather than a mere thirteen times). 

While reading and evaluating the credibility of the report, I found myself strangely distracted by page 9 on "security awareness training":

"Cybersecurity Ventures expects 2018 to be the Year of Security Awareness Training — the breakthrough year when organizations globally take the (financial) plunge and either train their employees on security for the first time or doubledown on more robust and ongoing security awareness programs. Global spending on security awareness training for employees is predicted to reach $10 billion by 2027, up from around $1 billion in 2014. Training employees how to recognize and defend against cyber attacks is the most under spent sector of the cybersecurity industry. While the annals of hacking are studded with tales of clever coders finding flaws in systems to achieve malevolent ends, the fact is most cyber attacks begin with a simple email. More than 90 percent of successful hacks and data breaches stem from phishing, emails crafted to lure their recipients to click a link, open a document or forward information to someone they shouldn’t. Training employees on how to recognize and react to phishing emails and cyber threats may be the best security ROI. ... Employee training may prove to be the best ROI on cybersecurity investments for organizations globally over the next 5 years."

That's almost the entire written content of the security awareness section. Those strident assertions (e.g. about the 'breakthrough year', and training being 'the most under spent sector') might as well have been plucked out of thin air. 

The report's author, Cybersecurity Ventures, immodestly describes itself as "the world’s leading researcher and publisher covering the global cyber economy". Gosh. The commercial sponsor, Herjavec Group, tells us "Information Security Is What We Do. Full Stop." ... then continues. 

Ever the cynic, I wonder if the report was written in such extreme terms simply in order to be quoted incessantly - and, yes, blogged about. Much as I would love to believe their claims about the meteoric rise of security awareness this year, somehow I doubt it will be much different to every other year. Despite the best efforts of awareness and training providers, I see no evidence of a massive change of heart. Yet. Unfortunately.

What we need is a more effective awareness campaign ... about the value of security awareness. Ironic really.

Chew before swallowing/spitting

The Global State of Online Digital Trust is a typical vendor-sponsored piece, a white paper (= marketing promotion in the guise of a 'survey') prepared by Frost & Sullivan for CA Technologies.

I say 'typical' in that they have disclosed hardly any information about the survey method and sample. A press release instructs us to see the report for "Full survey methodology details" but unless I'm blind, it looks to me as if someone either 'forgot' to write the materials-and-methods section or casually neglected to incorporate it in the published report.  Oh dear.

A CA marketing VP called it "a survey of 1,000 consumers, 350 cybersecurity professionals and 325 business executives from all over the world" whereas the press release referred to it as "The global online survey of 990 consumers, 336 security professionals and 324 business executives across 10 countries". 

We can only guess at how they might have assigned respondents between the three categories e.g. who would not qualify as a 'consumer'? Wouldn't a CISO fall into all three groups? In the report, numbers next to the graphs appear to indicate the sample sizes up to about 990

Last time I checked, there were rather more than 10 countries in the world aside from USA BRA UK FRA GER ITA AUS IND JPN and CHN as listed the report. If I'm interpreting those abbreviations correctly, that's well short of "all over the world".

If indeed the survey was online, that rather suggests the sample only consisted of people from the ten countries who were happy to answer an online survey - which itself implies a degree of trust in online security as well as a willingness to respond to a vendor-sponsored survey. 

It is unclear whether or how the report's conclusions relate to the survey findings ... and they are somewhat predictable given the report sponsor's commercial interests:

"CULTIVATE A CULTURE OF SECURITY Implement data protection policies that are in accordance with the world’s strictest data privacy regulations. Ensure company-wide familiarity with security policies, including among non-technical staff to reduce the risk of data breaches. 

START AT THE TOP Too many business executives see security initiatives as a negative return on investment. Alert the C-Suite to the tangible business impacts of a breach and a loss of consumer trust. 

COVER YOUR BASES Consumers consider both social and technical factors when determining whether to trust an organization; be sure that your organization has the technical foundation in place to mitigate attacks and have a response team ready to minimize damage to consumer trust in the event of a breach. 

KEEP IT SIMPLE Clear communication from organizations around policies and data handling practices is critical for building trust. Far too many organizations overestimate the degree to which consumers can easily manage their personal data online. Present your policies in simple language, and provide important details without overwhelming the consumer."

So they evidently equate "a culture of security" with data protection, data privacy and data breaches. Spot the common factor. A similar bias towards privacy law compliance and the protection of "customer data" is evident in all four paragraphs. That is an important issue, I agree, along with "cybersecurity" (an undefined term ... but I guess they mean IT security) but what about all the rest of information security: trade secrets, intellectual property, business continuity, physical and procedural security, information integrity, blah blah blah?

I freely admit to being heavily prejudiced in favour of both cultural development and management-level security awareness but their emphasis on breach impacts and consumer trust once again betrays a myopic focus on privacy breach incidents, while the conclusion about return on investment seems very suspect to me. I wonder if the survey question/s in that area were unambiguous enough to be interpreted in the same way by all the respondents? Or are the reported differences between the groups of respondents merely indicative of their distinct perspectives and assumptions? Did they even face the same questions? We can't tell since they choose not to disclose the survey questions.

The report introduces the term "Digital trust index". Sounds great, right? A metric concerning trust in, errr, digits? A percentage value relative to, um, what exactly? Oh let me guess, relative to the score conjured out of the air for this, the first report. And unfortunately for the sponsors, the term "Digital Trust Index" is already in use elsewhere.

Overall, a disappointing and essentially pointless read, like most other commercially-sponsored and heavily-promoted "surveys" I have read in my professional career, with disappointingly few exceptions. 

Clearly, I'm a slow learner, stubborn as an old boot. Venting my spleen through this blog is immensely helpful though, along with the vain hope that you might perhaps be persuaded to take a more critical look at the next "survey" that plops onto your screen. Chew it over rather than swallowing whole. If it is distasteful, spit. 

What have policies ever done for us?

Why do we have policies, procedures and all that jazz? What are they and what are they for?  What do they actually achieve?  What would happen if we didn't bother at all?  What else could we do instead - are there better ways?  

Those rhetorical questions were prompted by a disarmingly simple and naive-sounding question on the ISO27k Forum this morning, viz "I am looking at implementing iso27001. How do I know if I need a policy or procedure in place?" 

Good question!

In relation to ISO27k and to information risk and security in general, policies and/or procedures are needed in order to:

• Address information risks that are of concern to the organization, or more specifically to management and other stakeholders;
• State or express management's intentions formally in various areas;
• Communicate and clarify things to the intended readers, giving them clear guidance (e.g. work instructions, awareness and training materials);
• Satisfy requirements stated explicitly in ISO/IEC 27001(assuming the organization intends to be certified compliant);
• Satisfy other relevant and applicable requirements (e.g. under privacy laws and regulations, or for contractual reasons);
• Promote good practices through a stable, mature, considered, structured and systematic approach, allowing continuous review, updates and improvement where needed;
• Integrate various approaches in a coherent manner (e.g.information risk and security, plus privacy, plus business continuity, plus compliance, plus physical security, plus .... plus ...);
• Demonstrate to all concerned (insiders and outsiders) that various issues have been considered and desired approaches have been determined, while generally implying that other possible approaches have been discounted and are not required, perhaps even not approved or authorized;
• Enable assurance checks and formal compliance enforcement purposes, in which case they need to be unambiguous: clearly written, clearly applicable, clearly mandated ...;
• Ensure consistency of operations and response; *
• Allow for reporting and metrication of results; *
• Stop people guessing or making stuff up on a whim, or at least reduce this in certain areas while giving them more latitude in other areas;
• Emphasize and focus attention on Stuff That Matters.

* Additional objectives contributed by Anton Aylward - thanks Anton!

As to 'policy' and 'procedure', individuals and organizations quite often interpret those and related terms differently. Dictionary definitions are generally   definitive.

ISO/IEC 27000 defines some terms explicitly in the context of the ISO27k standards including:

• “Documented information” means information required to be controlled and maintained by an organization and the medium on which it is contained [i.e. ‘documentation’ in common parlance];
• “Policy” means intentions and direction of an organization, as formally expressed by its top management [where organization and top management are also explicitly-defined terms];
• “Process” means set of interrelated or interacting activities which transforms inputs into outputs [where none of those terms are explicitly defined!].

By the way, "insurance policy" neatly demonstrates a key difficulty in defining words individually, in isolation from the context. An insurance policy is not the "intentions and direction of an organization, as formally expressed by its top management" - it is a legally binding agreement, a contract between the parties concerning the insurance arrangement. "Foreign policy" is different again, and so on. Dictionaries tackle this situation by providing multiple, distinct or related definitions and examples, illustrating the defined terms being used in typical statements. ISO/IEC 27000 backs into a corner by giving just one definition and no context.

To make it worse, several key words and terms (including "key", for one!), are undefined. “Procedure” is not explicitly defined … but is used throughout ISO27k including 27000 itself where “processes and procedures” suggests they are distinct, and “policies, procedures and practices” implies further [also undefined] distinctions.

“Procedure” to me means the description of a “process” which is generally a sequence of “activities” which may be “tasks” or “decisions” or something else (e.g. “Wait patiently for authorization”). The manner of their description may be step-by-step instructions, flow diagrams, demonstrations, notes or some other format, usually captured in some form so that it can be more easily and consistently specified, stored, standardized, reviewed and authorized, communicated/used, and improved.

I have my own personal documentation preferences and styles. Given the choice, I prefer clear at-a-glance diagrams over tedious paragraphs of text for procedures, although both and more may be needed. For corporate policies, I much prefer readable plain English over the curious pseudo-legal mumbo-jumbo that is depressingly common in practice. But then IANAL: I'm a technical author writing information risk and security policies, procedures, training guides and awareness materials for ordinary people.

If a client uses different terms or interpretations, has particular requirements such as specific documentation formats and styles, needs their mumbo to be jumbo or whatever, that’s fine by me. He who pays the piper calls the tune!  

So, apart from all that, what have security policies ever done for us?

Outsider threat awareness module published

If “insiders” are defined as the organization’s employees, “outsiders” must be everyone else, right, all those who are not on the payroll?  In reality from any single organization’s perspective, a huge variety and number of people qualify as outsiders. 

‘We’ are completely outnumbered by ‘them’.

Leading on from August’s awareness coverage of insider threats, it’s time now to explore the information-related threats from outside the organization – both threatening outsiders and external threats that don’t involve malicious people, or indeed people, at all.

The scope of September's security awareness and training module includes external events, incidents, accidents and challenges that aren’t deliberate, targeted attacks by specific people or groups – supply chain interruptions, cloud service failures and Internet drop-outs for example are external threats to the business, as are more general, widespread or social issues such as climate change, infectious disease outbreaks and natural disasters.  We call these “outside threats”.

For completeness, the threats and risks arising from “inbetweenies” – neither insiders nor outsiders - were mentioned last month and are brought up again this month.  We’re talking about contractors, consultants, professional advisors, interns, temps and others.  Perhaps at some future point we should explore the inbetweeny threats in more depth.

By the way, the A-to-Z guide to outsider threats turned out to be 12 pages as I predicted. It was a bit of a rush to prepare such a detailed awareness paper at the end of the month but I'm glad we did; I'm still thinking about offering it as a threat catalog to guide anyone trying to identify and understand their outsider threats.  Google finds a number of threat catalogs already but none I have found so far cover "outsider threats" as well as ours does. But then I wrote it, so I'm biased. I should probably let it cool off for a while, and maybe I should add "insider threats" as well to complete the set.