I was approached by a number of people recently, asking my opinion on frameworks. TOGAF, SABSA, COBIT 5, CMMI, and the list go on. Their roles include CISO, security engineer, consultant and so on. A simplistic answer to their question could easily be given and the matter forgotten. However, the question being asked repeatedly clearly indicates a heightened interest and some inherent confusion about frameworks.
So it is worthwhile to consider them in more details. I will be as generic as possible in my discussion since I know there is much emotional attachment to individual frameworks. My aim is not to critique any of them, but to provide some approaches to assess them.
Main considerations
In order to have a better understanding and being able to give an informed opinion on frameworks, at least the following three areas need to be explored:
- What are the origins of knowledge and knowledge systems accumulated in a given framework?
- What are the creative and intellectual processes by which such knowledge was created?
- How can one participate – even as a passive observer – in these processes?
Considering the first question, a few other questions can be asked:
- What is the problem the framework tries to solve?
- Is this framework the best solution for that problem?
- What is the problem I have, that needs a solution?
- Is that framework the best solution for my problem?
Consideration needs to be undertaken, whether the given framework is a generalist or a specialist one. Just because a framework exists, it doesn’t necessarily mean it is useful for everything. Not even if it is popular. Not even if it is made by the most reputable sources.
Most information security problems an organisation needs to solve would have some unique elements. I am rather weary of frameworks that are mapped to everything else in the world and touted as all-encompassing solutions. I found that only in rare occasions can a single framework provide a full solution to the problems I have to solve.
History and background
The second question focuses on how the framework came into existence. A few more questions can be asked here, too:
- Who created it?
- For what purpose?
- How is it revised or developed further?
Learning a bit of history of any framework can be illuminating. It can also help to separate marketing hype from true value. Some frameworks got on their own life, independent from the original purpose of its creators. Some still suffer from the self-interest of their creators.
Frameworks created by academics differ in value from frameworks developed by field practitioners. I always try to identify academics’ ontological, epistemological and axiological underpinnings to understand what point of view they are taking. In corporate governance for example there is a huge difference between shareholder and stakeholder theory representatives. The framework built on such different theoretical underpinnings can lead to quite different outcomes.
A framework created by and for architects serves a different purpose and hence has a different value than a framework created by – let’s say – auditors. This doesn’t necessarily mean one is better than the other. It simply means they are different. Consequently, more often than not, they can’t and should not be used interchangeably.
How is it improved?
Not every update improves a product. Sometimes the changes are cosmetic, or just simply confusing, making the earlier version more workable. There is nothing wrong settling on a solid earlier version; however audit might take an exception to this.
Committee members of framework development also provide different value. Some are sitting on a joint committee as representatives of their company, not necessarily as real experts in the field the framework tries to address. Others are true experts. Identifying them and taking up conversations with those experts is always a pleasure and a learning experience for me.
Slave master or enabler
The third question takes me back to the beginning; to my opinion on frameworks. A framework provides guidance to the thought process, solving a problem. No more, no less. It helps ensuring that most issues are dealt with and dealt with thoroughly and systematically.
However no practitioner should become a slave to a framework. I use elements of many frameworks to solve my information security challenges. They help me conceptualising the problem and to identify the underlying core elements. Once the core elements are identified, I attempt to reconstruct the concept – preferably isolating and eliminating inherent shortcomings.
Frameworks can pose some dangers, too. Inevitably, following a framework means following someone else’s thought process. This can generate mental laziness. Furthermore, what assurances can one have that the thought process followed is actually correct or at least applicable? The checking mentality auditors apply as a thought process is quite different from the creative though process security architects practice.
Create your own
I make every effort trying to avoid group think and mental laziness. That’s why I create my own frameworks, dependent on the needs of the organisation I work for. They range from governance to risk management, to security education and so on. They are modular and there are sub-frameworks within each one. I use dozens of standards and industry frameworks in creating my frameworks. I am able in this way to build on existing knowledge and create new knowledge.
In summary, frameworks are useful. However, they need to be carefully examined. The good thoughts and the applicable elements should be retained and integrated into a coherent solution. Standing on the shoulders of giants and seeing further worked for Isaac Newton. It works for all of us, even in the context of frameworks.