I mentioned recently here on the blog that there can be strategic elements to policies, just as there are operational aspects to the supporting procedures and guidelines. With the new year fast approaching, I'd like to explore that further today. Warning : your blinkers are coming off. Prepare for the glare. Take for instance the corporate responses to COVID-19. Out of necessity, organisations in lockdown shifted rapidly from on-site office work and in-person meetings to home-working, using video conferencing, email and collaborative approaches. Although that may have been a purely reactive, un-pre-planned response to the global crisis that erupted (despite prior pandemics and warnings arising from increasing international travel) , it was facilitated by longer-term planned, strategic changes and investments in a resilient workforce with flexible working practices and positive attitudes, strong relationships within and without the organisation, plus appropriate tools and technolog...

Congratulations on completing this cook's tour of the topic-specific information security policies in ISO/IEC 27002:2022 (forthcoming). Today we reach the end of the track, reflecting back on our journey and gazing forward to the next objective. Through the blog, we have stepped through the eleven topic-specific policy examples called out in clause 5.1, discussing various policy-related matters along the way:  0.   Introduction : an initial overview of the classical 'policy pyramid'.  1.   Access control : 'policy axioms' are key principles underpinning policies.  2.   Physical and environmental security : ignore these aspects at your peril! 3.   Asset management : using templates/models to develop your policies. 4.    Information transfer : consider the business context for policies.  5.   Networking security : risks associated with data and social networks. 6.   Information security incident management : unique or gener...

The final topic-specific policy example from ISO/IEC 27002:2022 is another potential nightmare for the naïve and inexperienced policy author.    Policy scoping Despite the context and presumed intent, the title of the standard's policy example ("secure development") doesn't explicitly refer to software or IT. Lots of things get developed - new products for instance, business relationships, people, corporate structures and so on. Yes, even security policies get developed! Most if not all developments involve information (requirements/objectives, specifications, plans, status/progress reports  etc .) and hence information risks ... so the policy  could  cover those aspects, ballooning in scope from what was presumably intended when the standard was drafted. Even if the scope of the policy is constrained to the IT context, the information security controls potentially required in, say, software development are many and varied, just as the development and associat...

With respect to whoever crafted the wording of the 10th topic-specific example policy for ISO/IEC 27002:2022 , "management of technical vulnerabilities" is the kind of phrase that speaks volumes to [some, switched-on, security-aware] IT pro's ... and leaves ord'nry folk perplexed, befuddled and nonplussed. In this case, that may be appropriate if it aligns with the intended audience for the policy, perhaps not if the policy needs to be read, understood and complied with by, say, workers in general, for whom "Patching" is arguably a more apt and widely-known term. So, d o you need to tell workers to keep their IT systems, smartphones and IoT things up to date with security patches? If so, before launching into the policy development process, think very carefully about the title, content and style of your policy - plus the associated procedures, guidelines, awareness and training materials, help-desk scripts or whatever you decide is necessary to achieve your ...

I'll admit up-front that I have very mixed feelings about the utility and value of classification as a form of control, at least in the civilian/commercial world outside of the government and defence realm anyway. On the one hand, it is (or rather it  should be, thanks to the policies, procedures, guidelines, training and awareness materials and activities) reasonably obvious how to handle correctly classified and labelled hardcopy documents. Computer data - not so much, unless you are using mil-spec classified systems and networks with all manner of mandatory hard-coded built-in bullet-proof controls.  Do your corporate information security controls include automatic rifles and attitude? Are you at the very top of your game? On the other hand, even in mil/govt circles, classification and labelling can be tricky and consistency is always an issue. E ach level or category of classification covers a range, a spectrum of information risks. Individual items of information falling ...

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 s...

This is an interesting policy example to have been selected for inclusion in ISO/IEC 27002:2022 , spanning the divide between 'cybersecurity' and 'the business'. Why do data need to be backed up? What's the purpose? How should it be done? Questions like these immediately spring to mind (mine anyway!) when I read the recommendation for a topic-specific policy on backup ... but as usual, there's more to it than that. Play along with me on this worked example. If you already have a backup policy (or something with a vaguely similar title), I urge you to dig it out at this point and study it (again!) before returning to read the remainder of this blog.  Think about it. Does it address those three questions? What else does it cover? What is its scope? Is it readable, understandable, motivational - not just for you but for its intended audience/s? Does it state who those audiences are? Any spelling mistakes, grammatical errors or layout problems? Is it lengthy, offici...

I'm intrigued by the title of this topic-specific policy from the [draft] 3rd edition of ISO/IEC 27002 , being the only one of eleven example titles in the standard that explicitly states "information security".   I ask myself why? Is there something special about the management of events classed as 'information security incidents', as opposed to other kinds?  Hmmmm, yes there are some specifics but I'm not entirely convinced of a need for a distinct, unique policy. I feel  there is more in common with the management of all kinds of incident than there are differences in respect of infosec incidents, hence "Incident management policy" makes more sense to me. Here's one I prepared earlier . Organisations deal with events and incidents all the time. Aside from the humdrum routines of business, things don't always go to plan and unexpected situations crop up. Mature organisations typically have incident management policies already, plus the acco...

The information risk and security implications of data networking, along with the ubiquity of data networks, makes this an obvious policy topic and naturally we offer a policy template . I alluded to this at the end of the last blog piece as one of several security policies relating to information transfer: Less obviously, there are also potentially significant information risks and security controls applicable to social networking and social media ... and yes, we have a policy template for that too : Although 'social media' generally refers to Facebook, Twitter, LinkeDin and the like, many of the information risks pre-date them, back to the days of in-person personal and business interactions through professional membership organisations, special interest groups, town hall meetings, breakfast clubs and chambers of commerce. Other comms technologies such as the telephone, email and videoconferencing, plus 'groups' and collaborative working, have dramatically expanded ou...

"Information transfer" is another ambiguous, potentially misleading title for a policy, even if it includes "information security". Depending on the context and the reader's understanding, it might mean or imply a security policy concerning: Any passage of information between any two or more end points - network datacommunications, for instance, sending someone a letter, speaking to them or drawing them a picture, body language, discussing business or personal matters, voyeurism, surveillance and spying  etc. One way flows or a mutual, bilateral or multilateral exchange of information. Formal business reporting between the organisation and some third party, such as the external auditors, stockholders, banks or authorities. Discrete batch-mode data transfers ( e.g . sending backup or archival tapes to a safe store, or updating secret keys in distributed hardware security modules), routine/regular/frequent transfers ( e.g . strings of network packets), sporadic/ex...