I’ve commented a few times already on the use, and misuse, of standards, architectures and other forms of model to help us to manage information security. There are now so many control frameworks, process maturity models and Zachman-style architectures appearing on the scene that we’re in danger of drowning in a sea of frameworks.
“Give me a framework and I’m free” was a quotation I vaguely remember from my time at Cass Business School. We might equally add “Give me too many frameworks and I’m lost”. In fact, as more and more people enter the security profession, it’s inevitable that yet more models will be developed. It would be a nice aspiration to imagine that we could all agree on one, single, standard framework. But in practice they don’t serve the same purpose, so it’s natural that they will vary in style, terminology and perspective. And the richness of the solution space suggests that a single, universal framework would be impossibly broad and complex to manage. We all know that it’s far better to eat a barbecued elephant in bite-size pieces.
Many models share common definitions and concepts, but that doesn’t always help the situation. To paraphrase Eric Morecambe, they use “all the right words but not necessarily in the right order”. We’re faced with a rag bag of overlapping, inconsistent and sometimes contradictory tools. And that won’t go away. It’s just part and parcel of the rich tapestry of contemporary security management. The missing link is the lack of accepted wisdom on where we should start, what we should build ourselves and what we should steal or adapt from others.
To be fair, frameworks are very useful devices. They help us to define, structure, and communicate ideas and requirements. And their potential is surprisingly broad. We can develop different structures at varying levels of abstraction to structure policies, processes, standards, principles, commandments, risks, activities, services, compliance requirements, projects or technologies. In fact, any interesting set of artifacts you might wish to model for one purpose or another.
We can call them models, frameworks, architectures or management systems. We can present them as shapes, tables, guidelines, standards or position papers. They can be general or specific, and flexible or prescriptive. They can describe who does what, when, where or how. They can represent long range aspirations or short term goals. They can define evolutionary steps or methodologies, or just serve as a snapshot of the current situation.
Each approach is generally designed to serve a particular purpose or audience. Some are primarily for the benefit of the developers. Some will save significant time and money. Others will turn out to be an expensive drain and distraction. A small number of good frameworks will survive the test of time, enduring for a decade or more. A lot more will be consigned to the scrapheap, quickly sinking without trace after years of patient development. And one or two will grow into powerful vehicles for selling related products and services.
What we really need is not more frameworks, but better guidance on how to use them. we need to know which models to pick, what to use them for, and how best to develop and exploit them. My book Managing the Human Factor in Information Security provides a few suggestions in this area. But more guidance is needed. So I’ve decided that over the next few blog postings I’ll try to set out some suggestions on how best to surf this expanding ocean of frameworks, whilst avoiding the many sharks that lurk in wait for the inexperienced practitioner.