The trouble with dropping controls

I literally don’t understand a question that came up on the ISO27k Forum this week. A member asked:

‘Should a control be discontinued because a reassessment showed a lower acceptable risk score?’ 

I find it interesting to pick apart the question to explore the reasons why I don't understand it, and the implications. See what you think ... 

• Any control may legitimately be ‘discontinued’ (removed, unimplemented, retired, replaced, modified etc.) provided that change has been duly thought-through, assessed, justified, and deemed appropriate for whatever reasons. It may be important, though, to be reasonably certain that discontinuation is, in fact, in the best interests of the organization, and that’s often hard to determine as controls can be quite complex in themselves, and are part of a highly complex ‘control environment’. A seemingly trivial, unimportant, even redundant control (such as an alert) might turn out to be critical under specific circumstances (where other alerts fail, or were accidentally disabled, or were actively and deliberately bypassed by an attacker or fraudster). So, it may be preferable to ‘suspend’ the control for a while, pending a review to determine what the effects truly are … since it is probably easier and quicker to reinstate a ‘suspended’ control if needs be, than it would have been if the control was completely removed and trashed. A dubious firewall  rule, for example, might be set to 'warn and log only', rather than simply being dropped from the ruleset, the reverse of how new firewall rules can be introduced.  On the other hand, a control that is patently failing, clearly not justifying its existence, is a strong candidate to be removed … and potentially replaced by something better (which opens a whole new topic).
  
  
• A ‘reassessment’ might be a reassessment of the risks, the control, the control effectiveness, the business situation, the compliance obligations/expectations, the alternatives and supporting/compensating controls, or something else:  ‘reassessment’ is a very vague term.  It might mean anything on the range from ‘someone changed their mind’ to ‘a full independent investigation was launched, producing a lengthy report that formally discussed all the options including a recommendation to remove the control, which the management body duly considered and authorized, with various caveats or controls around the way it was to be done …’!
  
  
• ‘Lower acceptable risk’ might mean ‘We reduced our risk acceptance level’ but that’s ambiguous – it could mean that you are accepting a lower level of risk than before (management is more risk-averse) or the polar opposite i.e. the level of risk that can be accepted has been reduced (management is more risk-tolerant)!  More likely, the member who posed the question simply missed a comma, intending to say ‘a lower, acceptable risk score’ suggesting that he have decided the risk does not warrant retaining the control, hence ‘discontinuation’ is an option to be considered, as already discussed. 
  
  
• ‘Risk score’ hints at yet another potential minefield - one I've discussed repeatedly here on the blog. How are risks being ‘scored’, exactly? How certain are you that a reduction in the score genuinely reflects a reduction in the risk? If you are totally happy with your risk evaluation and scoring process, why has this question even arisen? If you have some doubts or concerns about the process, discontinuation of a control may not be a sensible approach without additional assurance and assessment, and perhaps the ability to reinstate the control efficiently if it turns out to be needed after all.
  
  
• More generally, removal of, or deliberate decisions not to implement, controls can be a challenging, problematic concept for risk-averse information security professionals. We are naturally biased towards risk reduction through controls. It’s an inherent part of our mind-set, a default approach.  The rest of the world does not necessarily think the same way! To ‘a level-headed business person’, controls may be perceived as costly constraints on business … which means they need to be justified, appropriate and necessary, and worth having i.e. they have a positive net value to the business (benefits less costs, ideally taking full account of ALL the benefits and ALL the costs). Ineffective controls, then, have a negative net value (no benefits, only costs) and are clearly candidates for removal … but removing controls is itself an activity that has risks, costs and benefits too.

That's a confusion of complexity and doubts arising from such a short question! Am I seriously over-thinking it? Well, yes, maybe I am. Still, it amuses me to exercise my grey matter, and I hope I've stimulated you to dig a little deeper when you see a question that furrows your brow. I've said before that some of the most insightful discussion threads on ISO27k Forum arise from seemingly naïve or trivial questions that might easily have been overlooked.

Is Facebook an asset?

Yet another good question came up on the ISO27k Forum today*. Someone asked whether to add the company's Facebook page to their information asset register (implying that it would need to be risk-assessed and secured using the Information Security Management System processes), or whether the asset should be the Facebook account (ID and password, I guess)**.

From the marketing/corporate perspective, good customer relations are perhaps the most valuable information assets of all, along with other external relations (e.g. your suppliers, partners, prospective and former customers, regulators/authorities and owners) and internal relations (the workforce, including staff, management, contractors, consultants and temps, plus former and prospective workers). It’s tempting to think of these as just categories or faceless corporations, but in reality the interactions are between individual human beings, so social relations in general are extremely important in business. 

There are numerous mechanisms that generate, support and maintain good customer relations, Facebook for example. Likewise for other relations (e.g. ISO27k Forum!). You might think of them as simply apps or information services, often cloud based, often commercial services provided by third parties hence limiting what is on offer and your options or influence over the infosec, privacy and other requirements. 

There are also related processes and activities, some of which have infosec, privacy and other implications e.g. I have a bank pestering me right now for identification info which they need from me as part of the anti money laundering regs: it’s a pain for me and for them, but they have to comply with the laws and regs. Workforce relationship management and ‘industrial relations’ is a huge part of ‘management’, with governance, compliance and other implications and risks. Overall, relationship management is, clearly, an important part of business success, or indeed failure when things go horribly wrong (e.g. look up the Ratners jewelers fiasco in the UK, and just look around at the difficulties arising from COVID-19: our people and myriad relationships are under extreme stress this year, not just our organisations).

Summing up, I encourage everyone to think big in terms of the scope of information assets, with a strong emphasis on the information that matters most to the business, the organization, and its strategic objectives. The IT systems and services are merely business tools: what matters most is the business information generated/processed by them.

* As I've said before, it's funny how often a simple, seemingly basic or naive question on ISO27k Forum leads to something more revealing when the answers and debate start flowing: such is the power of social media! 

** My answer to the original question is "Both ... and more besides"! It was a false dichotomy.

2021 infosec budget

Are you responsible for your organisation's information security or cybersecurity budget? Are you busily putting the finishing touches to your 2021 budget request, still working on it, just thinking about it, or planning to do it, honestly, when you next come up for breath?

Budgeting is generally a dreaded, stressful management task. Not only do we have to figure out the figures but we typically anticipate a tough battle ahead leading (probably) to a disappointing outcome and yet more problems.

On top of that, 2020 has been an exceptional year thanks to COVID. The business and information security implications of knowledge workers suddenly working from home, en masse, are still playing out now, while the economic impacts of COVID do not bode well for any of next year's budgets except perhaps for the manufacture of vaccines, masks, gloves, sanitiser and respirators.

A substantial part of information security expenditure is (whatever we may believe as professionals) discretionary. The decision to go for ISO/IEC 27001 certification, for instance, flows largely from management's appreciation of the business value of investing in information risk and security management good practices. There may be specific drivers such as incidents, compliance pressures or demands from business owners, partners and prospective customers, but even then there are numerous options and factors to consider such as:

• The objectives for the Information Security Management System - what it is expected to achieve;
• How broadly or narrowly to scope the ISMS;
• At what pace to implement the standard, and how precisely;
• What resources to assign to the implementation, not least a suitable implementation project manager/consultant and project team;
• Priorities for this work relative to other business activities, objectives and requirements, making adjustments as necessary (both initially and as the project proceeds when stuff comes up - as COVID did, for instance);
• Alignment with other corporate projects and initiatives e.g. exploiting strategic opportunities to update various systems, policies and processes for security and other reasons, at the same time;
• Change management aspects: does the organisation have the capacity and appetite first to adopt and assimilate the ISMS, and secondly to get the most out of it; 
• Project risks e.g. the possibility that things probably will not go entirely to plan, hence the need for dynamic responses and contingency funds.

Identifying and addressing all that, and more, means a shed-load of work for management at this time of year. Not only must cunning plans be developed, they must be 'sold' to the organisation - particularly senior managers responsible for the big decisions about strategies, budgets, resourcing etc. but also the managers of other corporate departments/functions who are all, in effect, competing for slices of the same pie.

An important preliminary step, then, is to convince senior management that a 'management system' or 'governance framework' for information risk and security is more than just a matter of best practices or compliance. It gives managers the information and levers necessary to direct, guide and monitor information security, supporting and enabling the achievement of business objectives. 

With that established, it is worth exploring the additional business value of certification. An ISO27001 compliance certificate from an accredited and respected certification body is like a stamp of approval ... but there's more to it. Consider our business case for an ISMS for strong clues about how to persuade management that implementation makes sense for the business. Taking it all into account, the benefits are overwhelming. You'd be nuts not to at least explore the possibility as part of your proposals for 2021.

Status of ISO27001 Annex A

One of the recurrent (zombie) threads on the ISO27k Forum concerns the status of ISO/IEC 27001:2013 Annex A. Typically the zombie is prodded from its slumber by a relatively inexperienced member naively suggesting that certain security controls from Annex A are essential or mandatory for certification.

In the course of debating and attempting to bury the zombie, some members trot out their own curious interpretations of the standard, pointing out actual and apparent discrepancies in the wording which, to them, indicate that Annex A is at least partly mandatory. I'm too polite to say they are wrong, but I believe they are misguided or mistaken - partly, it must be admitted, because the standard is ambiguously worded in some areas, hence it has to be interpreted carefully in practice.

To be clear, based on my three decades' professional experience and membership of ISO/IEC JTC 1/SC 27, my position is that none of the controls outlined in Annex A are mandatory. 

None at all. 

 

            Zero.

 

                            Nil.

 

                                                Nada.

 

 

[Cue tumbleweed]

 

 

 

 

This is a fundamental but complex issue to explain, so please forgive yet another lengthy post. In hope of decapitating the zombie, once and for all, I feel the urge to explain in detail.

To kick off, I’ll emphasise the critical distinction between two key terms:

• Mandatory requirements are formally described in the main body of ISO/IEC 27001. In order to be certified, ALL organisations absolutely MUST do all those things and should be prepared to convince the certification auditors of that;
• Discretionary items such as the controls summarised in Annex A are options to be considered - suggestions or recommendations, good practices you could say. Clause 6.1.3 indicates that management has much more latitude in this area provided they follow the mandatory information risk management processes from the main body, and again they may need to convince the certification auditors that they diligently followed the specified processes. Most organisations find many of the Annex A controls applicable, but seldom all of them. In the extreme, a few brave organisations choose to exclude ALL of the Annex A controls precisely as worded in the standard, instead electing to use custom controls, even if many in fact end up strangely similar to the Annex A outlines: they are merely word-smithed fine-tuned variants. 

There are touch-points between the management system (as formally specified in the main body of '27001) and the information security controls (as succinctly outlined in annex A). However, both conceptually and practically, they are distinct parts to the standard with specific implications for certification.

Here's an example. Any management system, such as an ISMS, revolves around and depends upon management information. That management information has various associated information risks and security requirements. For example, there are information risks associated with the security metrics (which are a mandatory part of the ISMS, as specified by the main body clause 9.1 “Monitoring, measurement, analysis and evaluation”) requiring risk treatments, typically through information security controls to protect that management information – controls that may be selected from Annex A, or from any other source, perhaps even created from scratch by creative thinking and innovation. 

The standard does not demand specific Annex A controls to protect the security metrics or other management information: the organisation evaluates the risks and chooses whichever controls best suit its purposes – in other words, the controls are discretionary but, for certification, the risk management process for selecting and implementing various controls must comply with the main body requirements. 

The touch point comes in clause 9.1 part (b): “The organisation shall determine … the methods for monitoring, measurement, analysis and evaluation, as applicable, to ensure valid results; NOTE The methods selected should produce comparable and reproducible results to be considered valid.” So here is a main body mandatory requirement to ensure the validity of the ISMS metrics, but notice there is no explicit requirement to use certain controls from Annex A. The organisation determines for itself how to ensure its security metrics are valid, and in practice the controls in this area vary between certified organisations. That’s fine, so long as they each followed the information risk management process defined by their ISMS, and those ISMSs in turn fulfill all the mandatory requirements of the standard.

To confuse matters a little, there are in fact some discretionary aspects to the main body of ‘27001, dotted in amongst the mandatory requirements. Clause 6.1.3 is a classic example: the organization “shall define and apply an information security risk treatment process” … but the process it describes has management selecting controls, taking account of things, determining which controls are ‘necessary’ etc. That’s a blend of mandatory and discretionary requirements. 

Another confusion is caused, unfortunately, by the use of the reserved term “shall” throughout the standard including Annex A. “Shall” normally denotes mandatory requirements in ISO-land. Personally, I think SC 27 made a mistake in changing “should” in the drafts of ‘27001 Annex A to “shall” in the published version, a change that happened quite late in the drafting process as I recall, with the publication deadline looming. On the other hand, the change was a compromise that placated those on the committee who were adamant and had been passionately arguing that some of the Annex A controls are universally required and ought to be mandatory. It also (I think) satisfied an ISO directive about the wording to be used in the management systems standards - a double whammy. 

Anyway, the upshot is that we’ve ended up with ‘a racing horse designed by committee’ (as shown above). This, along with the ambiguous wording of clause 6.1.3 about Annex A, will hopefully be resolved when ‘27001 is revised and reissued. The intended and formally specified status of Annex A remains the most contentious aspect of ‘27001 for SC 27. This is one persistent resilient awkward bugger of a zombie!

Standardising ISMS data/application program interfaces

We've been chatting on the ISO27k Forum lately about using various IT systems to support ISO27k ISMSs. This morning, in response to someone saying that a particular tool which had been recommended did not work for them, Simon Day made the point that "Each organisation trying to implement an ISMS will find it’s own way based on their requirements."

Having surveyed the market for ISMS products recently, I followed-up with my usual blurb about organisations having different information risks and business situations, hence their requirements in this area are bound to differ, and in fact vary dynamically (in part because organisations mature as they gain experience with their ISMS: their needs change). The need for flexibility is why the ISO27k standards are so vague (essentially: figure out your own requirements by identifying and evaluating your information risks using the defined governance structure - the ISMS itself), rather than explicitly demanding particular security controls (as happens with PCI-DSS). ISO27k is designed to apply to any organisation. 

That thought sparked a creative idea that I've been contemplating ever since: wouldn’t it be wonderful if there was a standard for the data formats allowing us to migrate easily between IT systems supporting ISO27k ISMSs?

I’m idly thinking about a standard file format with which to specify information risks (threats, vulnerabilities, impacts and probabilities), controls, policies, procedures, metrics, objectives etc. - maybe an XML schema with specified field names and (where applicable) enumerated lists of values.

Aside from migrating between ISMS IT support systems and services, standard data formats would facilitate data sharing between application systems, services or sub-functions (e.g. for vulnerability management, incident management and information risk management), and between departments or even organisations (e.g. insurance companies, auditors and advisors and their clients and partners).

Perhaps we should develop an outline specification and propose such a standard to ISO/IEC JTC 1/SC 27. A New Work Item Proposal would need sufficient details to be clear about what is being proposed and why, expanding on the requirement. Researching the topic and generating a basic draft as a starting point would ease the process of developing an ISO27k standard, so that's something else to add to my to-do list. I wonder if there are already XML schemas in this general area?

NZ Stock Exchange DDoS continues

The New Zealand Stock Exchange is having a rough week.  Under assault from a sustained DDoS attack, its web servers have crumpled and fallen in an untidy heap again today, the fourth day of embarrassing and costly disruption.

DDoS attacks are generally not sophisticated hacks but crude overloads caused by sending vast volumes of data to overwhelm the servers.  

The Host Error message above shows "RedShield" which appears to be a security service remarkably similar to a Web Application Firewall (although the company claims to be producing something far better) ...

If so, RedShield appears to be passing DDoS traffic to the stock exchange web servers which can't cope. Presumably, this particular DDoS attack does not fit the profile of the attacks that RedShield is designed to block, in other words RedShield is patently not preventing the DDoS.

I don't know whether RedShield is supposed to block DDoS traffic and is failing to do so, or if DDoS protection is simply not part of the RedShield service. Either way, it appears a DDoS attack is causing business impacts.

Whether RedShield is still working as designed to block application-level attacks is a moot point if the web servers are down ... but it is possible that the DDOS attack may be an attempt to over-stress the security systems, allowing more sophisticated hacks to leak past the weakened defences.  Hopefully, RedShield is still faithfully blocking all of them.

More likely, I suspect, this is a classic DDoS extortion: the attackers are demonstrating their power to disrupt the Stock Exchange's business, repeatedly, despite the defensive measures in place, as a way to force the Exchange to pay a ransom (probably - they are understandably reluctant to reveal the details with the spooks at GCSB actively investigating the incident).

Defences against DDoS attacks start with the basics such as network and server security, plus the policies and procedures to make sure the controls are effective in practice. Routine security monitoring and incident responses should include characterising the attack in progress, leading to active responses ranging from 'simply' disconnecting the network feeds (perhaps literally pulling the cables out) to filtering, diverting or slowing down the network traffic, ideally blocking the malicious traffic while allowing legitimate traffic to flow as normal. I'm talking about fairly conventional network security controls (mostly firewalls), albeit with sufficient throughput to cope with the onslaught. 

Almost certainly the responses would need to be coordinated with Internet service providers, internal IT service providers, and the authorities. Given the clearly disruptive impacts on the business, a crisis team would be liaising with all involved while keeping senior management and other stakeholders informed. From personal experience, this is an extremely stressful time for all involved, all the more so if there was inadequate preparation i.e. business continuity management, crisis planning, incident management exercises etc. with lashings of security awareness and training.  [If it turns out the Exchange was not, in fact, adequately prepared for this, there are governance and accountability implications for senior management. DDoS is just one of several 'real and present dangers' for any Internet connected business.] 

From there, the sky's the limit in terms of potential investment in increased server and network capacity, resilience, flexibility and redundancy, even cloud-based DDoS mitigation services such as Cloudflare and Akemai and other business continuity arrangements designed to guarantee at least a minimal level of service for essential business activities. Quite possibly these are in effect and working just fine right now, despite the apparent disruption to the Exchange's website: I have no inside track here but I'll be watching the news with interest as the incident unfolds. 

Creative teamwork post-lockdown

A couple of days ago I blogged about MURAL, just one of many creative tools supporting collaborative working. If you missed it, please catch up and contemplate about how you might use tools such as that right now for teamworking during the COVID lockdowns.

Today I've been thinking about 'the new normal' as the world emerges from the pandemic, inspired by the intersection of two threads.

Firstly, thanks to a Zoom session with participants and presenters from Queensland, I've been reading-up on "industry 4.0". I'm not totally au fait with it yet but as I see it the key distinguishing features are:

• Ever-increasing automation of manufacturing, with smart devices and robotics supplementing the capabilities of both manual and knowledge workers;
• Industrial IoT, coupling sensors and actuators on the production line with each other, allowing workers to interact with the machinery through screens and keyboards etc. and a growing  layer of automation smarts and networking;
• Ever-increasing reliance on IT, data, analytics, systems and artificial intelligence (with implications for risk, resilience, reliability and security);
• New capabilities, particularly in the specification and design areas - such as virtual reality simulations and rapid prototyping of jigs, machines and products by "additive manufacturing" (industrial 3D printers);
• An increasing focus on adding value through knowledge work in research and development plus product service/support, de-emphasising the manufacturing production core activities (which, I guess, started with the off-shoring of manufacturing to low-wage economies, and is now leading to both on- and off-shore automated manufacturing);  
• Rapid innovation and change, leading to difficulties in strategic corporate planning (with credible planning horizons falling to just a couple of years!) and personal career planning (e.g. how can workers learn to use tools and techniques that either aren't refined enough to be taught, perhaps not even invented yet?);
• Shortages of people with the requisite skills, knowledge and adaptability, able to thrive despite the challenges and seize opportunities as they arise.

Secondly, various governance experts have been grappling with changes brought about directly and suddenly by COVID19, and what remains to be done as we collectively recognise that, thanks to dependencies, incidents can spread ripples far and wide through the extended supply networks we've built. For example, through a YouTube session, David Koenig emphasised the governance need for resiliency, implying not just a greater appreciation of supply network risks, but better quality information and stronger control of those risks. David promotes a positive view of risk, in other words boards and senior exec management deliberately taking risks where that best serves the needs of the business and its stakeholders (implying a convergence of their clear rooftop view of the rapidly changing external environment with solid management information about the situation way down in the engine room, driving the corporation towards effective and efficient achievement of its business objectives). 'Taking risks smartly' is cool. 

[Aside: where do you stand on this if you are an infosec pro? Do you accept the duality of risk and opportunity, or that the "exploitation" of information can be both illegitimate and legitimate? Do you see information risk as a business and human issue, rather than purely a technology issue? If so, you may be CISO material!]

So, this evening I'm wondering about the governance and enterprise risk management aspects of Industry 4.0. Yes there are all manner of risks associated with automation, industrial IoT, rapid innovation and change ... but at the same time there is significant potential for strong organisations that understand what they are getting into, and are both willing and able to exploit opportunities opened up, in part, by COVID.

I'm intrigued by the possibility of small, nimbler, innovative organisations collaborating to take down the industry goliaths - the lumbering supertankers. Those creative collaborative teamworking tools I mentioned earlier could be game-changers. Being frank about it, although some SMEs will fail valiantly, they are more expendable than those misguided supertankers heading inexorably for the rocks. 

Now is the time to be bold, SME friends! Watch your ankles, goliaths! 

ISMS templates

Systematically checking through ISO/IEC 27001 for all the documentation requirements is an interesting exercise. Some documents are identified explicitly in the standard and are clearly mandatory, while many others are only noted in passing, often in ambiguous terms or merely alluded-to ... which can make it tricky to both comply with the standard and persuade the certification auditors of that.

Here's an example, one of the document templates from SecAware ISMS Launchpad:

That succinct one-pager addresses two requirements from the standard:

• Clause 9.2 (c) says (in part) "The organisation shall plan, establish, implement and maintain an audit programme(s)" - an explicit documentation requirement that the certification auditors will definitely check for compliance;
  
  
• Clause 9.3 says (in part) "Top management shall review the organization's information security management system at planned intervals to ensure its continuity suitability, adequacy and effectiveness." - an implicit documentation requirement that the certification auditors will probably check for compliance, and although the standard doesn't literally demand it, they may well insist on seeing written evidence that management reviews have been planned.

Those clauses lay out fairly succinctly what it means to internally audit or management review the ISMS: I have interpreted the requirements in terms of activities that might be performed quarterly over two years as shown on the schedule, with brief descriptions about the approaches to be taken ... but, as with all the SecAware materials, they are merely generic suggestions that customers are encouraged to adapt. 

Large, mature organisations with Internal Audit functions, for instance, may well engage them to plan and perform the ISMS internal audits using their conventional audit approach and whatever associated documentation they normally produce. They may prefer to audit the ISMS just once during the three year certification cycle, or conversely they may want to focus on a series of specific areas of risk and concern over successive audits, perhaps integrating the ISMS audit work with other IT, risk, cybersecurity or compliance audits.

Small organisations may feel that the absolute minimum of audits and reviews will suffice for them since they are short of resources and are already tackling all the significant issues anyway - but determining 'the absolute minimum' involves interpreting the wording of the standard very carefully, and then hoping the certification auditors accept whatever they do. 

Yesterday I completed a supplementary document template with the scopes and objectives of those audits and reviews. Today I'm developing a fill-in-the-blanks reporting template to be used for both audits and reviews: again, these are simple, generic documents, designed to be customised. Based on my experience in this area, we provide 'typical' generic templates in the hope of inspiring customers to develop whatever they need. 

Imagine yourself implementing clauses 9.2 and 9.3 of the standard in your organisation. Faced with those requirements, would you know what to do - how to go about the audits and reviews? Or would you be scratching your head, staring blankly at the screen wondering where on Earth to start? We can help with that! 

Find out more about the first two packs of SecAware ISMS templates, and keep an eye on this blog for news of the third one, currently in preparation.    

ISMS comms plan

Yesterday I started preparing an ISMS communications plan to satisfy ISO/IEC 27001:2013 clause 7.4, with a little help from the Web.

Naturally I started out with the standard itself. Clause 7.4 doesn't literally demand that organisations must have a "communications plan" as such, otherwise it would have been one of the mandatory documents included in SecAware ISMS Launchpad. Oh no, it's more circumspect: the standard says "the organization shall determine the need for internal and external communications relevant to the information security management system" ... and proceeds to outline - yes, you guessed it - a "communications plan".

ISO/IEC 27003:2017 confirms our assessment by stating explicitly:

"Documented information on this activity and its outcome is mandatory only in the form and to the extent the organization determines as necessary for the effectiveness of its management system".

In other words, a documented comms plan is discretionary - advised as good practice but not strictly demanded of every organisation for '27001 compliance certification.

Well anyway, let's do it! To comply with the standard, what should typically be communicated in respect of the ISMS, when, to and by whom, and by what means?

ISO/IEC 27003 offers examples of the things that should be communicated:

• Information security policies and procedures, plus changes thereto;
• [The organisation's] Information [risk and] security objectives;
• Knowledge on information security risks; 
• Requirements [of information] suppliers; 
• Feedback on the information security performance (not least the certificate of compliance with '27001 and asserted conformance with privacy laws);
• [Information about relevant] incidents and crises. 

Hmmm, as you can guess from the [insertions] in the list, while reading the advice I'm already putting my own slant on this, thinking about how the organisations I've previously worked/consulted with interpreted the standard's concise/minimalist advice, and what I would do now.

Next I set to work drafting the template in the form of a summary followed by a table with three columns (when, internal comms and external comms), rows for each quarter of a year and bullet points outlining the nature of the comms in each case. A simple 3½-page two-year comms plan covering the period up to and beyond certification came together in no time. 

Here's a taster, a glimpse of the first ½-page as originally drafted:

The sequence of communications mirrors the ISMS implementation project from initial approval through building the ISMS to certification and then business as usual as the ISMS settles down and gradually matures - hence the comms plan is pretty close to being an ISMS implementation project plan, including management comms about the progress of the project.

Have I neglected anything important though? I turned to Google and found useful guidance in the first few search results:

• Jean-Luc Allard, a respected member of ISO/IEC JTC 1/SC 27, takes the opportunity while writing for Advisera to elaborate on the standard's requirement. I appreciate his advice to consider comms as a two-way street: I will incorporate that into the template comms plan.
  
  
• ISMS.online has quite a bit of advice albeit much of it concerns how their ISMS cloud service generates information in a form that could usefully be communicated. They point out the link to a discretionary control on security awareness which is already in the plan anyway: maybe we should mention it in the preamble though.
  
  
• Ben Woelk, program manager for the Information Security Office at Rochester Institute of Technology, has published a detailed ISO comms plan - 16 pages laying out all the things they planned to communicate as part of their ISMS. I anticipate our customers using the templates to develop something along these lines, customised of course to suit their specific requirements ... but the SecAware ISMS templates are much shorter and generic. We are deliberately offering a bare-bones starting point hoping to inspire customers to develop the templates as they need, rather than a comprehensive out-of-the-box 'solution' which is unlikely to suit every customer. Nevertheless, Ben's inclusion of the goals and strategies for his comms plan is a cool idea, something again we can mention in the preamble.

I could continue laboriously trawling the remaining 1.7 million Google results (!) for inspiration but life's too short. Already I have the impression that the template comms plan is fine with just a little adjustment to the preamble - that summary section up-front that explains what the plan is about and intends to achieve. For example, it should mention who will be involved in preparing, authorising and delivering the comms (several people from various functions). So that's one of today's tasks on the to-do list.

First, though, I need to feed our ravenous ewes, lambs, goats and kids, two tame deer, a small flock of chooks and a house cow called Ginger. The sky is blue, the sun shining brightly, another glorious Spring day in rural New Zealand. Feeding out is an opportunity to think in peace (ignoring the bleating, mooing and clucking).

PS  This blog piece has taken me as least as much time and effort to write as the comms plan itself, but I hope you find it useful to hear about the work that goes into the SecAware ISMS templates and other materials. 

Creative teamwork in lockdown

Inspired by a heads-up from a colleague on LinkeDin, I bumped into MURAL today.

MURAL is a 'digital workspace for visual collaboration' by virtual teams.   

The animated demonstration on their home page caught my beady eye. Here's a static snapshot as a small group of people are busy placing/moving blobs on a graphic, presumably while discussing what they are doing on a parallel channel (e.g. Zoom):

Replacing the static monochrome graph with one of our colourful red-amber-green Probability Impact Graphics, a Risk-Control Spectrum, Universal Awareness Device, mind map, word cloud, process flowchart, any form of metric, clustered Post-It Notes, architecture diagrams, conceptual designs, strategy maps ... or ... whatever ... the approach would work nicely.

MURAL looks like a creative, fun and productive way for groups or teams working from home to collaborate virtually as if they were physically present in one of those soulless corporate meeting rooms lined with whiteboards and dire warnings about not writing on the projector screen.

If it makes you feel better, start the session with an inspirational poster of your glorious leader quoting the corporate values, followed by a numbered list of the rules for running a good meeting.

Or simply wing it. Go on, take a chance. Live a little.

In-person collaborative sessions are excellent for discussing and reaching consensus among teams, provided the person or people leading/guiding the session have the relevant skills and aptitudes, and the participants play along. It's a balancing act to inject enough energy and enthusiasm into the proceedings without over-cooking it, and to keep things on-track, moving inexorably towards the intended objectives ... which implies being reasonably clear about those objectives when inviting people and introducing the session ... and inviting the right people ... which requires some preparatory work rather than diving straight in at the deep end, unless the session leaders and participants are sufficiently experienced to know the score. 

How about virtual team weekly progress meetings? Progress reports? Personal morale timelines? Project planning and reporting? Interactive audit reports?Budgeting? Security awareness and training sessions? Knowledge transfer and creative inspiration? To-do and shopping lists? Virtual draughts/checkers, or chess, or other board games given the appropriate board images, icons, players and spare time (a little something for the night shift, perhaps)? 

Rather than everyone lamely watching some inept presenter reading out their bullet points with a tedious monologue, how about an interactive webinar where the presenter and audience, collectively, mind-map the proceedings, doodle around the topic at hand, all the while generating a memorable and inspirational visual record?  

The possibilities are endless. Pull up a mouse and engage brain.

If you're not already using it, check out MURAL.