Resilience as a business continuity mindset

An article written in conjunction with Dejan Kosutic has just been published at ContinuityCentral.com. 

"Most business continuity experts from an IT background are primarily, if not exclusively, concerned with establishing the ability to recover failed IT services after a serious incident or disaster. While disaster recovery is a necessary part of business continuity, this article promotes the strategic business value of resilience: a more proactive and holistic approach for preparing not only IT services, but also other business processes before an incident in order that an organization will survive incidents that would otherwise have taken it down, and so keep the business operating in some form during and following an incident."

We explain how resilience differs from and complements more conventional approaches to business continuity.  It is a cultural issue with strategic implications and benefits for everyday routine business, not just in crisis or disaster situations. It has implications throughout the organization, including business activities/processes, systems, workers and relationships with third parties. It is an integral and essential part of risk management.

The article discusses resilience in the context of ISO 22301 and ISO27k, and includes a maturity model and metric to help organizations put the strategy into practice.

Dejan and I share a passion for this topic that I hope comes across in our writing. Comments welcome!

Regards,

Gary (Gary@isect.com)

Awareness paper on authentication and phishing metrics

We've just republished a management-level security awareness paper on metrics relating to user authentication and phishing.

The introduction asks "How do we tell whether our authentication controls are effective?" and "What does 'effective' even mean in this context?" - two decent questions that could be addressed through suitable metrics.

Questions like these are central to the GQM (goal-question-metric) method (see IT Security Metrics by Lance Hayden), and not just literally in terms of their position in the handy acronym. They link the organization's goals or objectives relating to information security, to the information security metrics that are worth measuring.

In your particular circumstances, the effectiveness of authentication controls might or might not be of sufficient concern to warrant generating the associated metrics. Other aspects might take precedence, for example the amount invested in authentication controls, and the ongoing operating and maintenance costs of those controls. It's usually not too hard to think up a whole raft of aspects, parameters or concerns relating to the topic area, but focusing on the things that are likely to matter most to the organization (business priorities) is a good way to keep the list within reasonable bounds. Once you know what they are, the next step is to figure out the questions arising e.g. "Are we spending appropriately (neither too much nor too little) on authentication?"

From there, it's simply a matter of deciding what data would help address the questions, and those are your metrics!  Job done!  Errr, well, no, not quite: if you have several goals/areas of concern and numerous questions arising, each requiring multiple metrics to generate the answers, there is a distinct risk of being overwhelmed with possibilities. It is infeasible and in fact counterproductive to attempt to measure everything. Less is more! This is where the PRAGMATIC method comes into play as a way to whittle down the long list to a shortlist of metrics showing the most promise. The GQM approach also suggests filtering out the metrics that don't address the questions very well, and trimming down on metrics addressing questions that are only marginally related to the organization's business goals. Both approaches have their merits.

3 more metrics papers

We've just published another three documents on security metrics, written and first released five years ago as part of the management stream in the NoticeBored information security awareness service.

The first paper was concerned with measuring integrity.  Despite being one of the three central pillars of information security, integrity is largely overshadowed by availability and, especially, confidentiality ... and yet, if you interpret 'integrity' liberally, it includes some extremely important information security issues. The 'completeness and correctness' angle is pretty obvious, while 'up to date-ness' and 'appropriateness' are less well appreciated.  Add in the character and trustworthiness of people, and integrity takes on a rather different slant (Bradley Manning, Julian Assange and Edward Snowden springing instantly to mind as integrity failures).  An 'honesty metric' is an innovative idea.

The integrity metrics paper also suggests measuring the integrity of the organization's security metrics program or system of measurements, on the basis that metrics ought to be accurate, complete, up-to-date and relevant. The metrics integrity issue is obvious when you think about it. Managing with poor quality information is less than ideal.  However, in our experience, information security metrics are mostly taken at face value: we usually focus on what the numbers are telling us without even considering that they might perhaps be wrong, misleading, incomplete or inconsequential. Worse still, we get so distracted by the fancy "infographics" that the information content is almost irrelevant.  That's hardly a scientific approach!  We have raised this issue before in relation to treating published security surveys as gospel, blythely ignoring the fact that most are statistically dubious if not patently biased marketing copy. Remember this the next time you search the web for pie charts to illustrate your security investment proposals, or the next time someone tries to persuade you to loosen the purse strings! 

A short, humdrum paper on IT audit metrics suggests a few ways to measure the IT audit function, such as "IT audit program coverage" as well as conventional management metrics.  

The third paper on malware metrics was virtually the same as the version released a year earlier. We made some changes the following year, partly due to the research and thinking that went into writing PRAGMATIC Security Metrics ... but you'll have to wait just a bit longer for the 2009 paper.

Management without metrics - how?

The SEC (Security Executive Council - not the Securities and Exchange Commission!) boldly describes itself as "the leading research and advisory firm that specializes in security risk mitigation."  Their primary interest appears to be physical security, although they also make the odd nod towards IT security, business continuity and 'convergence'.

The SEC conducted an unscientific online poll, asking respondents to self-assess and report the capability maturity of their security programs using the classic 5 point SEI-CMM scale.  Unsurprisingly, the results show a vaguely normal distribution about the middle value ('defined'), skewed towards the low end of the maturity scale.

It appears they may have asked a separate question about metrics:

"When participants were asked about metrics (a higher level of maturity), 64% said they did not use business value metrics (metrics that are beyond initial "counting" of activities such as number of background checks performed or number of badges issued)."

So only about a third of their respondents have security metrics other than the absolute basics - a pathetically low proportion that begs the obvious question "How are they managing security without metrics?"

Answers on a postcard please.  Or comment below.