Here's the next security awareness paper in the series, describing metrics relating to contingency and business continuity management . "Measuring the effectiveness of contingency arrangements is a tough challenge, not least because (like insurance policies) we hope we will never need to use them. However it makes sense to measure our investment in contingency plans and preparations, and to confirm whether management is sufficiently confident in them, prior to enacting them as by that stage it will be too late." Possible contingency metrics suggested in the paper include: RTO and RPO - classic disaster recovery metrics in their own right Resilience - measured by incidents Recovery - proportions of systems for which RTP/RPO are defined, tested and met Costs - easier to measure than benefits, and yet an uncommon metric in practice Management confidence - to what extent do managers believe in the congtingency arrangements? There are many other possible metrics in this area. ...

A security metrics opinion piece by Elden Nelson in CSO Online  identifies and expands on the following four issues: "Communications problems are due to a tool-centric rather than risk-centric view of security." While I accept that tool-centrism is not good, I disagree with the casual but simplistic implications that 'a tool-centric view of security' is the cause of communications problems, or that a 'risk-centric view of security' is necessarily the alternative. It sems to me there are many problems in communicating security metrics. The security or security reporting tools per se are less of an issue, in my opinion, than factors such as many technologists' fundamental misunderstandings about their own roles in the organization, about business management, strategy, risk and statistics, plus their apalling communications skills. Furthermore, communications problems are surmountable: given enough time and effort, we can get better at communicating things, p...

The  security awareness  module from which we've plucked this management-level discussion paper covered information security issues relevant to the typical office or corporate workplace. In effect, offices are  information factories.  Office information security controls are essential to keep the factory, its machine tools, operators and production processes running smoothly, efficiently and profitably, and to protect office-based and accessible information assets (paperwork, computer files, and white-collar workers) from all manner of risks. Office security concerns include: Intruders - burglars, industrial spies and 'lost' visitors wandering loose about the place Fires, floods and accidents  Various logical/IT security incidents affecting the office network and file system, workstations, email and other applications Procedural issues such as workers' and visitors' failure to comply with office information security policies and procedures. This short awareness ...

The 2014 Data Breach Investigations Report (DBIR) by Verizon  concerns more than ~63,000 incidents across 95 countries that were investigated by 50 organizations, including Verizon of course. Fair enough ... but what exactly qualifies as an "incident"?  According to the report: Incident : A security event that compromises the integrity, confidentiality, or availability of an information asset.  Breach : An incident that results in the disclosure or potential exposure of data.  Data disclosure : A breach for which it was confirmed that data was actually disclosed (not just exposed) to an unauthorized party. Those definitions are useful, although for various reason I suspect that the data are heavily biased towards IT (a.k.a. "cyber") incidents.  ~1,300 of the ~63,000 incidents were classified as breaches - an interesting metric in its own right: ~98% of incidents evidently did not result in the disclosure or potential exposure of data. For the beleaguered Chief I...

Today I caught up with a panel session on security metrics at the May 2014 RSA conference  involving Alan Shimel, Andrew McCullough, Ivana Cojbasic and Jody Brazil. Alan told us more than once that security metrics are 'more art than science', implying (possibly) that this stuff is difficult and irrational.   The key questions were: What should we measure? Who should we show it to? How  should we show it? I guess we could add Where , When and Why to complete the set . Andrew's main point was that metrics must be actionable .  Well, yes, Andrew, actionability is an important characteristic of metrics ... but wait, there's more! At least  eight more  in fact. Ivana identified three audiences for security metrics: executives, managers and [security] operations/technicians.  According to Ivana, "trends" are the best metrics to present to the execs and managers, while technicians need detailed technical metrics, apparently.  "Trends" aren't metric...

A mediocre article  based presumably on a press release from Deloitte hints at a financial metric concerning not the size of an organization's information security budget per se but its shape , specifically the proportions of the budget allocated to preventive, detective and corrective actions (albeit using Deloitte's versions of those labels). The journalist and/or his source implies that Australian organizations ought to be emulating North American and British ones by spending a greater proportion of their security budgets on detection and correction. Although that advice runs counter to conventional wisdom, the article doesn't adequately explain the reasoning: one could just as easily argue that the Australians are ahead of the game in focusing more on prevention, hence the rest of the world ought to catch up!  Anyway, a pie chart is an obvious way to represent proportions. The example below, for instance, uses nested pies to compare the budget breakdowns for two fiction...

Security awareness is the primary control against social engineering, hence this is an essential core topic for the awareness program. Making managers aware of how they might measure [the risks and controls relating to] social engineering is the purpose of this awareness paper . The paper illustrates how elaborating on the control objectives helps to identify relevant security metrics. For example, the objective to 'make the entire workforce aware of social engineering' suggests the need to measure the security awareness program's coverage.  The paper identifies just three security awareness metrics. There is nothing special about those particular metrics, and they are certainly not the only ways to measure awareness. It is deliberately left as an exercise for the reader to determine firstly whether it might indeed be worth measuring coverage of the awareness program, and if so secondly how best to do that. By the way, in conjunction with fellow author Walt Williams, I...