Last week I joined a web conference about the state of the BC profession. One of the issues that caught my attention was this idea of ‘convergence’ and the observation that more organisations are looking to merge BC and Information Security. I found this strange that after all the years of complaining that BC was seen as an IT discipline, that it would be considered sensible to push it back to IT.
One source of this mode of thinking is potentially CERT at Carnegie Melon University, and in particular their Resiliency Management Model. The model they are proposing is rather complex, so hopefully I can provide an overview and you can delve deeper into it if you are inclined.
Let me start by saying I have long disagreed with the way these guys define capability. Carnegie Melon is the institution that created Capability Maturity Modelling as a tool in Software development – which has since spread to be applied in all corners of the organisation. My objection is that their view of ‘capability’ is totally defined by having a process and the maturity and ongoing improvements to that process. This is not the meaning that everybody associates with the term capability.
CERT comes from the IT Security world. They came to their model of resilience as a means to promote and improve the practice of security within the organisation. The model was developed in collaboration with the FSTC (Financial Services Technology Consortium, a US financial sector group).
Operational Resiliency is the ability of an organisation to adapt to risks that affects its core operational capacities. Their definition is derived from standard terms around resilience – and identifies three basic elements to describe the resiliency properties of an object;
- change (adapt, expand, conform, contort) when a force is enacted
- perform adequately or minimally while the force is in effect
- return to a predefined expected normal state whenever the force is no longer effective
Their concept is rooted in the idea of ‘operational risk’ (which is very prevalent in financial sector) and the need to apply a greater degree of collaboration across the key areas that deal with operational risk. This results in the key areas that need to collaborate to achieve operational resiliency as;
- security
- business continuity, and
- IT operations management.
Their model looks at four assets that support Critical Business Processes. These are;
- People – to perform and monitor the processes
- Information – used by and created in the processes
- Technology – to support and automate the processes
- Facilities – where the process is performed
You could use this part of the model to apply to a range of traditional BC approaches. Unfortunately they assert that the framework describes and defines the processes that enable us to predictably manage operational resiliency by defining processes to be followed before, during and after an incident.
When you claim to predict what may happen, and suggest that resilience is about following a pre-defined process, then you lose me. I do not believe it. When you state that this process approach should be led by security management, you lose me even more.
Essentially they are saying that it is too hard to achieve Organisational (or Enterprise) Resilience as everything you do would have to be process oriented and repeatable. Instead they focus down onto Operational Resiliency, where the focus is on the specific set of assets and the risks at an operational level. Strangely they do not set out a process for managing operational risk – in fact they assert in one of the background papers that operational risk management is broad and poorly defined and may not lend itself to process definition. Despite this we have the key areas that address operational risk targeted as the delivery vehicle for resiliency – Security, BC and IT Operations.
The CERT thinking recognises that resiliency is a property rather than an activity, and also that it is an emergent property. To this end measuring resiliency is difficult. By defining operational resiliency as a collaborative approach to managing operational risk they try to focus on on this often circular argument that Security, BC and IT Ops are the prime movers in managing operational risk and therefore the drivers of operational resiliency.
The framework is very complex and has some material that I am sure anybody will be able to get value from. The framework is made up of the 4 assets I noted earlier, 21 ‘capabilities’ (with more to come) grouped into 4 categories;
- Enterprise Management
- Engineering
- Operations Management
- Process Management
Each capability is further split into Base Practices (the foundation body of knowledge) and Common Practices (defining different levels of maturity). Each of these practices is further refined into ‘SubPractices’. A subpractice is the point where things change from describing what must be done to how it must be done. Subpractices are associated with ‘Process Artifacts’.
The project is ongoing and is mapping their framework to to various international standards within the 3 subject disciplines they seek to have work together – Security, BC and IT.
In summary, if you want to go through this model you will no doubt find something of value. Resilience (sorry but I wont be using the term resiliency going forward) is about holistic approaches and these need to include Security, BC and IT – it also needs to include HR and others.
If you are in the IT Security business you will lap this stuff up. I don’t know anybody who practices in the BC space who aspires to work for IT Security, and I cannot think of any I know who aspire to be led by the Security function.
What do you think?
Is this convergence happening in your company?
Is there more to dealing with operational risk than security, BC and IT Ops?
Rich, thanks for taking the time to read and comment, I consider it an honor. Although it is also akin to that sinking feeling I remember as an undergraduate when the Professor engages you in questioning and you wished you had done better research!
I will certainly contact you offline, but there was part of the discussion I would like to keep here for the benefit of other potential readers. Hopefully you will have the time to share thoughts on two specific questions.
I am in agreement with you on the need to break down silos and to have disciplines work together. I note that you are not promoting organisational restructuring but collaboration. My question is do you see organisations picking up and implementing the model yet? Where would you suggest people start in looking at adopting this framework?
Second, accepting the point about the value of institutionalized processes when we are under pressure, where do you stand on the position that adaptive responses are an essential part of resilience? I am talking about the capability to adapt under the pressure of an incident/impact.
I look forward to the next release of the framework, and please feel free to plug where we can buy the book.
Ken–My name is Rich Caralli, and I am the principal architect of the CERT Resiliency (Resilience) Management Model. I also am the technical manager of the CERT Resilient Enterprise Management Team.
Thank you for your thoughtful treatment of our model. Our work has certainly evolved over the past few months with the development of v1.0 of the model (to be released this month) and a corresponding book (which should be released this summer.)
I must say, however, that I don't completely agree with some of your assertions, but this comment section is not a good medium to itemize my points of rebuttal. To summarize my thoughts, I would make two points: 1) A process orientation provides a better means to measure performance, and provide more predictability of behavior during times of stress. This is very different than saying that “. . . you claim to predict what will happen.” We don't make this claim. We only claim that improving capability provides more process institutionalization, which is a predictor of performance. 2) We do not advocate that security management take the lead. In fact, we don't advocate any organizational structure or approach. Instead, we promote convergence as a means for breaking down silos that impede performance. We have seen BC take the lead in some organizations, and security or IT in others. Because a process model is descriptive, we absolutely do not prescribe that “BC work for IT Security.” One other point on operational risk management: as you stated, we did not set out to develop a capability model for managing operational risk. However, we recognize that managing operational risk is a strong thread in managing resilience, and is certainly one of the drivers of (and arguments for) a convergent approach.
As for your arguments related to capability, my only rebuttal would be that in my travels I find that capability maturity models (and other derivative models) are often poorly understood. We sought to build a model that gave organizations a way to measure capability. Capability in this case is defined by the degree to which a process is institutionalized. Institutionalized processes are more likely to be retained during times of stress–which is exactly what organizations experience when tested by events, incidents, etc. To the extent that an organization can reflect critically on not only base practices but the degree to which these base practices are a part of the way that work is planned, executed, and managed, it should provide them another indicator of how well they will perform when tested. This isn't predicting what will happen next or what the outcome will be–but, it is giving the organization a valuable piece of information about their readiness. Simply verifying the existence of base practices without looking at capability doesn't tell the organization much about whether they'll perform the practice when they need to.
I'm happy to discuss further at your convenience. Please feel free to contact me!
Rich
Rich, thanks for taking the time to read and comment, I consider it an honor. Although it is also akin to that sinking feeling I remember as an undergraduate when the Professor engages you in questioning and you wished you had done better research!
I will certainly contact you offline, but there was part of the discussion I would like to keep here for the benefit of other potential readers. Hopefully you will have the time to share thoughts on two specific questions.
I am in agreement with you on the need to break down silos and to have disciplines work together. I note that you are not promoting organisational restructuring but collaboration. My question is do you see organisations picking up and implementing the model yet? Where would you suggest people start in looking at adopting this framework?
Second, accepting the point about the value of institutionalized processes when we are under pressure, where do you stand on the position that adaptive responses are an essential part of resilience? I am talking about the capability to adapt under the pressure of the incident/response.
I look forward to the next release of the framework, and please feel free to plug where we can buy the book.
Hhm, interesting article Ken. I can't say that I agree wither with Business Continuity falling back to technology (Info Sec), as the CERT model seems to allude to. I've fought for years to try and get BC separate from both IT and Business, so that the best program and processes can be built. Leaving it to one side or the other seems to cause friction between the two and causes assumptions to run rampant. Such things as Business believing that IT “knows” what they – the business – need in a disaster. I did work for one company that had Info Sec and BC under a Risk Management division, separate from both IT and Business. It seemed to work rather well for them, as BC was able to become the bridge – or liaison if you will – between the various divisions/departments in the company.
I agree with your comments and assessment quite heartily.
Thanks for the comment Alex, I think this issue about the most appropriate home for a BC Program is worthy of a longer discussion.
This item from Continuity Central is an example – an interview with IT Security Directors who have taken on the lead for BC in the company. http://www.continuitycentral.com/feature0749.html