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

This piece is different to the others in this blog series. I'm seizing the opportunity to explain the thinking behind, and the steps involved in researching and drafting, an information security policy through a worked example. This is about the policy development   process , more than the asset management policy per se .  One reason is that, despite having written numerous policies on other topics in the same general area, we hadn't appreciated the value of an asset management policy, as such, even allowing for the ambiguous title of the example given in the current draft of  ISO/IEC 27002:2022 .  The standard  formally but (in my opinion) misleadingly defines asset as 'anything that has value to the organization', with an unhelpful note distinguishing primary from supporting assets. By literal substitution, 'anything that has value to the organization management' is the third example information security policy topic in section 5.1 ... but what does that actua...

Yesterday I blogged about the "access control" topic-specific policy example in ISO/IEC 27002:2022. Today's subject is the "physical and environmental security" policy example. Physical security controls are clearly important for tangible information assets, including IT systems and media, documentation and people - yes, people. The first "computers" were humans who computed numbers, preparing look-up tables to set up field guns at the right elevation and azimuth angles to hit designated targets at specific ranges given the wind speed and direction, terrain and ordinance - quite a lot of factors to take into account in the field, so the pre-calculated tables helped speed and accuracy provided the gunners used them correctly anyway, and I'm sure they were highly trained and closely overseen! Aside from a little mental arithmetic, most of us don't "compute" many numbers today but we still process staggering quantities of information flo...