Security Architecture - How to do it Properly

My last posting, on the distractions associated with building an enterprise security architecture, may have strayed a little too far towards the cynical side of modern business life. Some people took it to mean, in the words of Private Fraser of Dad’s Army, that “we’re all doomed”. I have to correct this misconception. Because good, useful security architectures can be developed if sensible principles are followed. So I thought I’d set out a few tips of the trade. I invite others to chip in. We could all use some practical guidance. They don’t teach this stuff in schools and universities. You have to discover it by trial and error or at the feet of an experienced practitioner. Here’s my recommended principles.

1. All architecture is a means to an end, not an end in itself. Do not lose sight of the objective and the audience. Models are abstractions – selective reductions – of reality to help people focus on a particular set of features. The ones you decide to highlight should reflect their purpose and audience.

2. There is no single universal way of dividing up the subject area. The real world can be sliced and diced in many ways. There is no perfect contents list. Everybody has a different perspective and much of the detail of the subject is likely to be sparse, incomplete or unknown, perhaps unknowable.

3. The overall presentation should be designed with politics and communication in mind. If it has sufficient depth to be useful, it will need to be subdivided into layers. The top layer should be designed for presentation and political purposes. It could influence future organization designs. And it will be the primary entry and reference point for anyone who wishes to explore the content in more detail.

4. The style of the presentation can vary from block diagrams, through geometric shapes of every shape and size, to logical pseudo-code implementations. Senior managers prefer the former. Development staff appreciate the latter. Don’t get it wrong. I’ve made the mistake of giving a CIO a copy of a pseudo-code expression of an architecture. It was a setback in communications. Yet it was perfect for the practitioners who needed it.

5. Establish whether you are dealing with processes or entities. The former requires verbs and the latter needs nouns. In my view you should not mix the two. I believe it’s better to create separate models for processes and entities. But they should be created together.

6. You need more than one model. For technology alone, each major platform justifies an architecture of its own, as does the central supporting service and the communications model that joins them together. (I’m grateful to Beverley in Royal Mail Group for teaching me this learning point.) John Zachman believes we need 36 models for a complete Business and IT architectural framework. I disagree. It’s overkill. You can design an infinite number of models for security but they will become confusing, unmanageable and expensive to maintain. So keep it simple.

7. Separate long-lasting information, such as general policies and controls, from fast-changing details, such as organizational roles and current technology specifications. Think about how things will change over time. And leave space for additions or changes to entities or classifications. All of this will help make the architecture much easier to maintain.

8. Don’t be frightened by incompleteness. An IT development blueprint needs be complete to be implemented. Security is different. We don’t have all of the solutions, neither the products nor the management systems in place, to meet contemporary business requirements. That’s no reason to concede. Architectures should be forward-looking: aspirational and inspirational. It’s better to have targets for the future, rather than be restricted by the limits of what we can achieve today. As I often say, “a good modern security architecture is ragged around the edges, full of holes and largely in the minds of people”. That’s because if we’re truly addressing today’s problems we simply won’t have all the answers.

9. That last quote reminds me of my closing point, which is that architecture has no value if it is not widely communicated and implemented. It is better that it’s in the hearts and minds of practitioners, than enshrined in tablets of stone. Contratry to what many people assume, you can implement an architecture immediately. You just need a set of ideas, a means of communicating them and a clear focal point for authoritative decisions. You don’t need a hundred page white paper. Just a clear understanding of who is allowed to make and approve architectural decisions.