The art to policy

After the weekend's WannaCry excitement, we're pressing on with the IoT security materials.

I've been thinking about developing a model IoT security policy for the module. What policy axioms/principles and policy statements would be appropriate in this area? 

Identifying, analyzing and treating the associated information risks is a sensible, generic approach aligned with ISO27k, but the technological/cybersecurity controls typically employed in other contexts are somewhat challenging or impossible on many current-day IoT devices. Situations where the tech controls simply aren't sufficient to mitigate the risks perhaps ought to be covered as a policy matter. Giving up on IoT security and accepting the residual risks just because other options are too hard is not smart. 

Another angle is assurance. If an IoT supplier claims their thing uses strong authentication and encryption, it may or may not be appropriate to take it on trust and accept the assertions at face value, depending on the consequences of being wrong ... which again depends on the information risks and hence the context in which the thing is being used - and that triggers another thought: what happens when things change, such as new devices, new models, firmware or software patches, new applications, new business or technical situations etc.? The risks ought to be reviewed, requiring a link to the change management policy and process.

Oh and another thing: compliance. How will compliance with the policy be achieved, in practice? What stops workers from, say, casually introducing things into the corporate environment, or changing things, without bothering about the risk management formalities (perhaps because it doesn't even occur to them due to lack of awareness)? An approach that might help here is classification and business continuity thinking: where things are used within or supporting highly classified or critical business activities or information, the risks are likely to be higher so the security and process controls probably ought to be stronger, than with run-of-the-mill or more trivial IoT stuff. It makes sense to develop and maintain some sort of corporate database or register of the critical things, hopefully ensuring that the accompanying risk and security activities aren't neglected.

So, that's a reasonable starting point to develop a generic IoT security policy. Now all I need to do is open up our policy template in MS Word with the normal structure, headings and boilerplate, and flesh it out along those lines. Easier said than done! 

We should avoid the 10 reasons policies fail, for example the policy must be clear, easy to read and understand, so the language is important. 

Part of the policy-drafting challenge is to be succinct. We try to limit our example policies to about three pages in total, of which the axioms and policy statements are about 1 page.

It also needs to be persuasive and motivational: there's litle point in formally laying down the rules if readers disagree and/or fail to comply, which is why the template has an introductory section to explain (briefly) the background, justifying why the policy exists and why it is important. 

With the lyrics in mind, all that remains is to compose a catchy tune and write a smash-hit.