Naïve risk analysis methods typically involve estimating the threats, vulnerabilities and impacts, categorizing them as low, medium and high and then converting these categories into numbers such as 1, 2 and 3 before performing simple arithmetic on them e.g. risk = threat x vulnerability x impact . This approach, while commonplace, is technically invalid, muddling up quite different types of numbers : Most of the time, numeric values such as 1, 2 and 3 are cardinal numbers indicating counts of the instances of something. The second value (2) indicates twice the amount indicated by the first (1), while the third value (3) indicates three times the first amount. Standard arithmetic is applicable here. Alternatively, 1, 2 and 3 can indicate positions within a defined set of values - such as 1 st , 2 nd and 3 rd place in a running race. These ordinal values tell us nothing about how fast the winner was going, nor how much faster she was than the runners-up: the winner might have led by a...

Many information security controls that are intended to mitigate significant business- and/or safety-critical information risks are themselves critical. If critical controls are missing, ineffective, fail in service, or are disabled (whether accidentally or deliberately), the associated risks are more likely to materialize, leading to unacceptable impacts. Therefore, relative to less- or non-critical ones, critical controls deserve additional investment and attention throughout their lifecycle.  For examples, critical controls should ideally be: Identified as such, implying that controls should be systematically measured as to their criticality, and ranked or categorized accordingly in order to identify the most critical ones that deserve additional effort; Carefully considered, specified and documented in detail; Designed, developed and tested thoroughly by experienced professionals, applying sound security principles such as defense-in-depth; Resilient and fai...

Section 9.1 of ISO/IEC 27001:2013 requires organizations to 'evaluate the information security performance and the effectiveness of the information security management system'.  The standard doesn't specify precisely what is meant by 'information security performance' and '[information security?] effectiveness' but it gives some strong hints: "The organization shall determine: a) what needs to be monitored and measured, including information security processes and controls; b) the methods for monitoring, measurement, analysis and evaluation, as applicable, to ensure valid results; c) when the monitoring and measuring shall be performed; d) who shall monitor and measure; e) when the results from monitoring and measurement shall be analysed and evaluated; and f) who shall analyse and evaluate these results." The standard specifies (much of) the measurement process without stating what to measure i.e. which metrics.  No doubt the committee would argue...

We've just republished the next in the series of management-level security awareness papers on metrics.  The latest one lays out a range of metrics for information security and risk management . Leaving aside the conventional metrics that are typically used to manage any corporate function, the paper describes those that are peculiar to the management of information risk and information security, with an emphasis on business-focused metrics. I spent last week teaching a CISM course for ALC in Sydney.  The business and risk focus is a unifying thread throughout CISM, from the governance and strategy angle through risk and security management to incident management. In contrast to courses covering the more technical/IT aspects of information security intended for mid- to low-level information security professionals with operational responsibilities, CISM is intended for Information Security Managers and Chief Information Security Officers with governance, strategic and manageme...