Welcome to the SecAware blog

I spy with my beady eye ...

22 Oct 2021

Topic-specific example 10/11: management of technical vulnerabilities

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, do 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 information risk management objectives in this regard (more on that below).

Hinson tip: what are your information risk management objectives in this regard (concerning 'technical vulnerabilities' ... or whatever aspect/s you believe need addressing)? What information risks are you facing, how significant are they (relative to other things on your plate) and how do you intend to treat them? Seriously, think about it. Talk it through with your peers and professional colleagues. Draft a cunning treatment plan for this particular subset of information risks, discuss it with management and refine it. Lather, rinse, repeat until you achieve consensus (or wear down the blockers and negotiate a fragile settlement), and finally you are primed to craft your policy.

Once more, we have your starter-for-ten, a generic patching policy template designed to help get you smartly off the starting blocks:


While we don't presently offer a policy template on vulnerability disclosures (something worth adding to our to-do list, maybe?), we do have others that are to some extent relevant to this topic, for instance on change and configuration management and information systems security. I'll pick up on that point at the end of this blog series.

Aside from the list of 11 policy examples, ISO/IEC 27002:22 offers further advice on security policies, such as:

"Topic-specific policies should be approved by appropriate managers."

Whereas it is obvious that corporate policies need to be approved (and authorized and mandated and overseen and maintained and ...) by 'management', notice the word "appropriate". Some policies (notably the information security policy) should be approved by senior management, or in ISO27k terms "top management" defined as "person or group of people who directs and controls an organization at the highest level" (with notes and further definitions - see ISO/IEC 27000). It may be appropriate for individual topic-specific policies, however, to be 'approved' by senior, middle or even junior managers. So, for instance, if your organisation currently lacks an CISO or ISM, but has maybe an IT or HR Manager, or in fact anyone reasonably senior, they could 'approve' the policies: this is an example of ISO27k's principle of applying to any kind or size of organisation. The standards avoid being too explicit.

The standard continues: 

"Topic-specific policies should be communicated to relevant personnel and external interested parties, in a form that is relevant, accessible and understandable to the intended reader. The organization can determine the formats and names of these policy documents that meet the organization’s needs. In some organizations, the information security policy and topic-specific policies may be in a single document. The organization may name these topic-specific policies standards, directives, policies or others."

Nice!  So, the people who need to know need to know, fair enough, and it doesn't matter how you tell them. It doesn't even matter whether you call them policies, procedures, catalogs, laws, regulations, lists, banana cupcakes or "Esmirelda".  "Guideline 33a" is just fine, if that suits your purposes. 

Tune-in to the blog tomorrow for a piece about the final topic-specific policy example in '27002, and some thoughts about what it means to 'implement' a policy.

No comments:

Post a Comment