Topic-specific policy 8/11: cryptography and key management

Maybe this particular policy was mentioned in previous editions of ISO/IEC 27002 and picked as a topic-specific policy example for the forthcoming 3rd edition in order to include something directly relevant to governmental organisations, although to be fair crypto is a consideration for all of us these days. Many (most?) websites are now using HTTPS with TLS for encryption, for example, while cryptographic methods are commonly used for file and message integrity checks, such as application/patch installers that integrity-check themselves before proceeding, and password hashing.

Here's a glimpse of one I prepared earlier:

Like all our templates, this one is generic. Organisations with specific legal or contractual obligations in this area (such as governmental and defense companies bound to employ particular algorithms, key lengths and technologies such as physically secure hardware crypto modules, or companies bound by PCI-DSS) would need to adapt it accordingly. 

You'll see that it mentions the Information Classification Policy: I'll have more to blog about classification tomorrow.

If you've been tagging along on my tiki-tour of the topic-specific policy examples in ISO/IEC 27002:2022, and if you read that LinkeDin piece by Chris Hall that I recommended, you will probably by now recognise the standard document structure we've adopted for all our policy templates. The main elements are:

• Page header with a logo (our logo in the template, yours to download and customise) and a short, pithy, catchy policy title.
• Information security policy up-front to be crystal clear about the nature and ownership of the policy, since some topics could equally belong to other corporate functions (e.g. our "Fraud" policy template is, in fact, an information security policy addressing the information risks associated with fraud, misrepresentation and so on, not an HR or legal policy about disciplinary procedures and compliance).      
• Policy title, big and bold to stand out. The precise wording is important here (I'll return to that point in another blog piece).
• Policy summary, outlining the main thrust of the policy in a single paragraph for readers who have been sufficiently intrigued by the title to open the document, are unsure whether they ought to read the full policy (e.g. is it applicable to them?), and hopefully as a quick reminder of the content some while after they last read it. 
• Applicability is stated to indicate that most information security policies apply to 'all workers' (meaning the organization's paid employees and third parties' employees such as contractors and consultants), although some are of more direct concern to particular departments or groups within the organisation.
• The actual policy, split into three subsections:
• Background lays out the rationale/purpose and scope of the policy. While this half page or so could be cut out, I find it helps (for most readers, the rational thinkers at least) to set the scene, outline the information risks and so justify the need for the policy, briefly. It easily earns its keep as far as I'm concerned. 
• Policy axioms (guiding principles) are high level policy statements, usually just one or two brief, pithy and formally worded sentences. These form an important link to the "information security policy", being the highest level policy in the structure. 
• Detailed policy statements amplify and explain the axioms and requirements in more pragmatic terms - less formal or stilted, closer to plain English. These range from half to a few pages, depending on the breadth and depth or complexity of the topic.
• Responsibilities are assigned, preferably to corporate functions or roles rather than named individuals, reducing the amount of policy maintenance to reflect staffing changes. The aim is to clarify what management is expecting the applicable people to do under this policy, although these are merely brief summaries: job/role descriptions, procedures, employment/service contracts, guidelines, work instructions and in some cases other policies (e.g. on auditing) and laws (e.g. the Privacy Officer role) expand on the stated responsibilities in various ways.  

The page layout, colours, fonts and formatting are also as consistent as we can make them across all the policy templates, hence workers who read/study any one should find others familiar and easier to navigate. We use just a handful of MS Word Styles for this, so customers can readily change to 11-point Arial with one inch borders on legal size paper, or whatever their own policy style guides dictate, simply by updating the Word Styles.

The language or writing style is another consistent aspect to all the SecAware policy templates. It helps immensely that I have personally written them all, hence they all reflect my natural style - or rather the particular style I have inevitably acquired through decades of practice, writing thousands of policies, procedures, standards, guidelines, awareness materials, management reports, audit reports, papers, articles and so on, oh and these bloggings of course. 

As organisations mature, they gradually accumulate numerous policies covering various topics, many written by different authors with different goals and different audiences in mind.  Hence it's no surprise to find substantial differences between then - even with the benefit of corporate guidance such as a style guide or policy management policy(!). You may have experienced (suffered!) the curiously officious pseudo-legal phrasing that some naive policy authors think appropriate - 'including but not limited to the following four (4) clauses ...' and so forth. A degree of formality is inevitable. Stilted, archaic language, heretofore and hereunder, is not. It's unhelpful and should be eschewed.

Having said that, my writing style is continually evolving so I can't resist refining the wording every couple of years or so when I review and maintain the policy templates, despite their maturity. That involves systematically updating the entire policy suite by the way, a laborious task given ~80 templates (!). It's an important quality and consistency/integrity check though, as well as an opportunity to ensure that the policies reflect current priorities and the state of the art/good practices in the field (e.g. replacing deprecated crytpographic algorithms with recommended ones), another aspect that is evolving in parallel.