Simplicity itself

"Simplicity is the default unless there's a good business reason to do something else. What is typically lacking are the business reasons ..."

That comment on CISSPforum set me pondering during this morning's caffeine fix. We've been chatting about some training webinar sessions recently promoted by (ISC)2. Some say they over-simplify information security to the point of trivialising and perhaps misleading people.

If you follow this blog, you'll know that this month I have been slaving away on an awareness module covering malware, a topic we've covered many times before - particularly the avoidance or prevention of infections but this year a customer asked us for something on publicly disclosing incidents in progress, a disarmingly simple request that turned into a fascinating foray into the post-malware-infection incident management and resolution phase for a change. I've been exploring and writing about what does, could or should happen after malware 'hits' - from that dramatic moment the ransomware demands appear on everyone's screens, for example. 

What follows is quite an intricate and frantic dance, in fact, involving management, IT and other staff, customers, suppliers and partners, regulators/authorities, journalists and the news + social media etc. plus the Incident Management Team, infosec and business continuity pros trying to keep everything on track, the legal team figuring out who to sue, the compliance pros wondering how not to get sued, and various hired-hands helping with forensics, disinfection and finding then retrospectively plugging whatever holes were initially exploited by the malware. All the while, the menacing hackers and cybercrims are wielding big coshes in the shape of threats to make the disruption permanent and terminal, and/or to disclose whatever juicy tidbits of corporate and personal info they've previously stolen (the CEO’s emails, or browser history perhaps?). And all the while the systems, data, business processes/activities, websites and apps are being maintained, recovered or restored. Brands and relationships are under pressure, along with all the dancers. It's an intensely stressful time for them, I'm sure. 

The approach we've taken is to explore the timeline of an actual incident, in real time as it happens (as it happens), building a case study around the ongoing Travelex ransomware incident: the sequence forms a convenient thread to lead people through the story, thinking about what's going on at each stage and imagining how it would be if a similar incident happened 'here'. I’ve drawn up a simplified Travelex incident timeline in the same style as the one I drew for the Sony Pictures Entertainment fiasco 5 years back, pointing out some of the key events plus the phases of the overall process. The new Travelex version (‘in press’!) is simpler but remarkably similar since the sequence is much the same at this fairly high level. 

My point is that pictures help. They really do ‘speak a thousand words’. We use mind maps, diagrams, screenshots, flowcharts, Ishikawa-style risk-control spectra, animated PIGs and other eye-catching visuals extensively, making frequent use of Red-Amber-Green traffic-light colours and other visual cues. Most people still need to have stuff explained to them in written or spoken words, too, but the TL;DR; version is usually graphic. The graphics act as foils or prompts as well as summaries for the written or spoken words - in fact I seem to be naturally a ‘visual thinker’: it’s easier for me to write simply about complex stuff with a picture in mind, on the screen or scribbled on a scrap. 

In other words, we reduce ‘understanding a complex topic’ down to ‘explaining and expanding upon a few simple images’.

One of the nice things about that is our approach in practice, at 'run-time' when our content is actually being used in, say, an awareness session, workshop, course or online discussion, the way the materials are used depends on the presenter, the audience, the topic and its relevance to the organization, and the context (e.g. is it a half day session in a meeting room or half minute chat in the lobby?). Diagrams are much more flexible than text - although techniques such as headings, contents pages, side-bars, pullquotes and text boxes make it easier for people to skim through the text to pick out whatever catches their eye in, say, a briefing paper or report. Generally speaking, bright, colourful, 'interesting' pictures make the best eye-catchers.

If you’ve done much teaching and coaching, or you are some other sort of social engineer (!), you probably get it, although you probably have your own style and preferences too. There are ways and means of simplifying and explaining even complex stuff, step-by-step, top-down, bottom-up, middle-out, end-to-end or whatever. The visual approach works well for me. The real trick, though, is to explore and understand the topic well enough firstly to prepare said simple versions, and secondly to be able to explain them reasonably eloquently, preferably with enough enthusiasm and presence to engage with and motivate the audience. It’s all very well me writing a tidy stack of awareness and training content, but I can’t personally present and discuss this with our customers’ employees: that’s down to their awareness and training people … who first of all have to explore and understand the awareness content themselves! That’s why our PowerPoint slide decks have extensive speaker notes, supplementing and explaining the relatively simple and largely graphical slides. 

As if that’s not enough already, we also have to bear in mind the awareness audiences. Whereas most security awareness programs only address “staff” (sometimes known as “users” or “general employees”), we’re also keen to engage “management” and “specialists” too since they are key pieces in the infosec puzzle, with their own information needs and preferences. Management, for instance, has an obvious interest in the governance, strategy, policy, compliance, continuity and assurance aspects, plus of course risks, specifically information risk management, oh and let’s not forget “the business” – all of which are relevant in the post-malware-infection module. Likewise the IT, risk, continuity and compliance professionals have their own interests and concerns. The differences extend all the way down to the individuals: Freda in Accounts might be fascinated by the numbers – the headline figures and the graphs, whereas Alice in Engineering is far too busy and distracted right now and can barely even spare a sideways glance at the screen. John from IT might be colour blind, or plain blind, so all our hard work on those diagrams is wasted unless someone can conjour up the pictures for John.

Individuals vary in our preferred modes of learning too. Some of us like to read stuff (words and/or pictures) while others prefer to listen, be shown or experience things first-hand. Some simply accept new information at face value (especially if provided by an 'expert' or 'senior') whereas some challenge or are inspired to contemplate and explore the topic as their way of internalising it. A few reject stuff by default, only ever accepting things on their own terms. And yes, some simply can't be bothered, don't understand and/or don't care. We all have our off-days and Other Stuff Going On Right Now.

I guess either those (ISC)2 webinars are not aimed at the CISSPforum-type greybeard audience, or whoever prepared them comes from a different place - a high level outline thinker rather than a details-oriented geek, maybe, or a professional educator working to a budget from a prepared brief rather than an infosec pro working from knowledge, experience and a passion for the subject.

Simplification is good but even awareness, training and teaching are more complex than they appear, once you scratch the surface.

PS  Although I'd love to supplement or even replace this blog piece with a neat little diagram, I don't have the time to simplify things right now. That's the downside of graphics: visual creativity takes time to express. Must dash, module to finish ...