2021 infosec budget

Are you responsible for your organisation's information security or cybersecurity budget? Are you busily putting the finishing touches to your 2021 budget request, still working on it, just thinking about it, or planning to do it, honestly, when you next come up for breath?

Budgeting is generally a dreaded, stressful management task. Not only do we have to figure out the figures but we typically anticipate a tough battle ahead leading (probably) to a disappointing outcome and yet more problems.

On top of that, 2020 has been an exceptional year thanks to COVID. The business and information security implications of knowledge workers suddenly working from home, en masse, are still playing out now, while the economic impacts of COVID do not bode well for any of next year's budgets except perhaps for the manufacture of vaccines, masks, gloves, sanitiser and respirators.

A substantial part of information security expenditure is (whatever we may believe as professionals) discretionary. The decision to go for ISO/IEC 27001 certification, for instance, flows largely from management's appreciation of the business value of investing in information risk and security management good practices. There may be specific drivers such as incidents, compliance pressures or demands from business owners, partners and prospective customers, but even then there are numerous options and factors to consider such as:

• The objectives for the Information Security Management System - what it is expected to achieve;
• How broadly or narrowly to scope the ISMS;
• At what pace to implement the standard, and how precisely;
• What resources to assign to the implementation, not least a suitable implementation project manager/consultant and project team;
• Priorities for this work relative to other business activities, objectives and requirements, making adjustments as necessary (both initially and as the project proceeds when stuff comes up - as COVID did, for instance);
• Alignment with other corporate projects and initiatives e.g. exploiting strategic opportunities to update various systems, policies and processes for security and other reasons, at the same time;
• Change management aspects: does the organisation have the capacity and appetite first to adopt and assimilate the ISMS, and secondly to get the most out of it; 
• Project risks e.g. the possibility that things probably will not go entirely to plan, hence the need for dynamic responses and contingency funds.

Identifying and addressing all that, and more, means a shed-load of work for management at this time of year. Not only must cunning plans be developed, they must be 'sold' to the organisation - particularly senior managers responsible for the big decisions about strategies, budgets, resourcing etc. but also the managers of other corporate departments/functions who are all, in effect, competing for slices of the same pie.

An important preliminary step, then, is to convince senior management that a 'management system' or 'governance framework' for information risk and security is more than just a matter of best practices or compliance. It gives managers the information and levers necessary to direct, guide and monitor information security, supporting and enabling the achievement of business objectives. 

With that established, it is worth exploring the additional business value of certification. An ISO27001 compliance certificate from an accredited and respected certification body is like a stamp of approval ... but there's more to it. Consider our business case for an ISMS for strong clues about how to persuade management that implementation makes sense for the business. Taking it all into account, the benefits are overwhelming. You'd be nuts not to at least explore the possibility as part of your proposals for 2021.

Status of ISO27001 Annex A

One of the recurrent (zombie) threads on the ISO27k Forum concerns the status of ISO/IEC 27001:2013 Annex A. Typically the zombie is prodded from its slumber by a relatively inexperienced member naively suggesting that certain security controls from Annex A are essential or mandatory for certification.

In the course of debating and attempting to bury the zombie, some members trot out their own curious interpretations of the standard, pointing out actual and apparent discrepancies in the wording which, to them, indicate that Annex A is at least partly mandatory. I'm too polite to say they are wrong, but I believe they are misguided or mistaken - partly, it must be admitted, because the standard is ambiguously worded in some areas, hence it has to be interpreted carefully in practice.

To be clear, based on my three decades' professional experience and membership of ISO/IEC JTC 1/SC 27, my position is that none of the controls outlined in Annex A are mandatory. 

None at all. 

 

            Zero.

 

                            Nil.

 

                                                Nada.

 

 

[Cue tumbleweed]

 

 

 

 

This is a fundamental but complex issue to explain, so please forgive yet another lengthy post. In hope of decapitating the zombie, once and for all, I feel the urge to explain in detail.

To kick off, I’ll emphasise the critical distinction between two key terms:

• Mandatory requirements are formally described in the main body of ISO/IEC 27001. In order to be certified, ALL organisations absolutely MUST do all those things and should be prepared to convince the certification auditors of that;
• Discretionary items such as the controls summarised in Annex A are options to be considered - suggestions or recommendations, good practices you could say. Clause 6.1.3 indicates that management has much more latitude in this area provided they follow the mandatory information risk management processes from the main body, and again they may need to convince the certification auditors that they diligently followed the specified processes. Most organisations find many of the Annex A controls applicable, but seldom all of them. In the extreme, a few brave organisations choose to exclude ALL of the Annex A controls precisely as worded in the standard, instead electing to use custom controls, even if many in fact end up strangely similar to the Annex A outlines: they are merely word-smithed fine-tuned variants. 

There are touch-points between the management system (as formally specified in the main body of '27001) and the information security controls (as succinctly outlined in annex A). However, both conceptually and practically, they are distinct parts to the standard with specific implications for certification.

Here's an example. Any management system, such as an ISMS, revolves around and depends upon management information. That management information has various associated information risks and security requirements. For example, there are information risks associated with the security metrics (which are a mandatory part of the ISMS, as specified by the main body clause 9.1 “Monitoring, measurement, analysis and evaluation”) requiring risk treatments, typically through information security controls to protect that management information – controls that may be selected from Annex A, or from any other source, perhaps even created from scratch by creative thinking and innovation. 

The standard does not demand specific Annex A controls to protect the security metrics or other management information: the organisation evaluates the risks and chooses whichever controls best suit its purposes – in other words, the controls are discretionary but, for certification, the risk management process for selecting and implementing various controls must comply with the main body requirements. 

The touch point comes in clause 9.1 part (b): “The organisation shall determine … the methods for monitoring, measurement, analysis and evaluation, as applicable, to ensure valid results; NOTE The methods selected should produce comparable and reproducible results to be considered valid.” So here is a main body mandatory requirement to ensure the validity of the ISMS metrics, but notice there is no explicit requirement to use certain controls from Annex A. The organisation determines for itself how to ensure its security metrics are valid, and in practice the controls in this area vary between certified organisations. That’s fine, so long as they each followed the information risk management process defined by their ISMS, and those ISMSs in turn fulfill all the mandatory requirements of the standard.

To confuse matters a little, there are in fact some discretionary aspects to the main body of ‘27001, dotted in amongst the mandatory requirements. Clause 6.1.3 is a classic example: the organization “shall define and apply an information security risk treatment process” … but the process it describes has management selecting controls, taking account of things, determining which controls are ‘necessary’ etc. That’s a blend of mandatory and discretionary requirements. 

Another confusion is caused, unfortunately, by the use of the reserved term “shall” throughout the standard including Annex A. “Shall” normally denotes mandatory requirements in ISO-land. Personally, I think SC 27 made a mistake in changing “should” in the drafts of ‘27001 Annex A to “shall” in the published version, a change that happened quite late in the drafting process as I recall, with the publication deadline looming. On the other hand, the change was a compromise that placated those on the committee who were adamant and had been passionately arguing that some of the Annex A controls are universally required and ought to be mandatory. It also (I think) satisfied an ISO directive about the wording to be used in the management systems standards - a double whammy. 

Anyway, the upshot is that we’ve ended up with ‘a racing horse designed by committee’ (as shown above). This, along with the ambiguous wording of clause 6.1.3 about Annex A, will hopefully be resolved when ‘27001 is revised and reissued. The intended and formally specified status of Annex A remains the most contentious aspect of ‘27001 for SC 27. This is one persistent resilient awkward bugger of a zombie!

Standardising ISMS data/application program interfaces

We've been chatting on the ISO27k Forum lately about using various IT systems to support ISO27k ISMSs. This morning, in response to someone saying that a particular tool which had been recommended did not work for them, Simon Day made the point that "Each organisation trying to implement an ISMS will find it’s own way based on their requirements."

Having surveyed the market for ISMS products recently, I followed-up with my usual blurb about organisations having different information risks and business situations, hence their requirements in this area are bound to differ, and in fact vary dynamically (in part because organisations mature as they gain experience with their ISMS: their needs change). The need for flexibility is why the ISO27k standards are so vague (essentially: figure out your own requirements by identifying and evaluating your information risks using the defined governance structure - the ISMS itself), rather than explicitly demanding particular security controls (as happens with PCI-DSS). ISO27k is designed to apply to any organisation. 

That thought sparked a creative idea that I've been contemplating ever since: wouldn’t it be wonderful if there was a standard for the data formats allowing us to migrate easily between IT systems supporting ISO27k ISMSs?

I’m idly thinking about a standard file format with which to specify information risks (threats, vulnerabilities, impacts and probabilities), controls, policies, procedures, metrics, objectives etc. - maybe an XML schema with specified field names and (where applicable) enumerated lists of values.

Aside from migrating between ISMS IT support systems and services, standard data formats would facilitate data sharing between application systems, services or sub-functions (e.g. for vulnerability management, incident management and information risk management), and between departments or even organisations (e.g. insurance companies, auditors and advisors and their clients and partners).

Perhaps we should develop an outline specification and propose such a standard to ISO/IEC JTC 1/SC 27. A New Work Item Proposal would need sufficient details to be clear about what is being proposed and why, expanding on the requirement. Researching the topic and generating a basic draft as a starting point would ease the process of developing an ISO27k standard, so that's something else to add to my to-do list. I wonder if there are already XML schemas in this general area?