Principles of good security architecture

If Kit Cameron can come up with a set of laws of identity when arguably there aren’t any, then the least I can do is have a stab at setting out some principles of good security architecture. If nothing else, it might stimulate some much-needed debate on how to best exploit a double-edged sword that’s equally capable of adding value or creating confusion. Here are my suggestions.

1.  Set clear, defined objectives:  A model is a means to an end, not an end in itself. Start by defining why you need it and who will use it. Only then can you determine the scope, size, content and presentation. Drivers and benefits can vary widely. They can help organize work, standardize activities, demonstrate compliance, act as a sales device for a vendor, or simply serve as a therapeutic exercise for the compiler. Never lose sight of the original purpose and audience. Otherwise it will not be fit for purpose.

2.  Small is beautiful:  Whatever you’re using it for, the whole point of using a model is to define and communicate a set of selected, relevant facts to a specific group of users. Unnecessary detail should be filtered out or hidden from the sight of the user. The information conveyed should be as brief and simple as possible to meet the objectives of the model.   

3.  One size does not fit all:  Modern security management requires a range of different models, each serving a different purpose. They can be used to communicate or assess controls, responsibilities, activities, services, project tasks or specifications. Different models can be linked or combined but the contents will not map together neatly. A model designed for one particular purpose or audience might not be appropriate for another, though there are always exceptions.

4.  Call it anything you like:  It doesn’t matter much whether you use the term “model”, “framework”, “architecture”, “method” or anything else, though some terms are stickier than others. Architecture, for example, sounds grandiose and suggests a blueprint for building something. But it’s mainly just a matter of taste. What really counts is how it is perceived by users and other stakeholders.

5.  There is no set format:  I’ve designed, commissioned and used many different types of security framework. They have taken the form of word documents, glossy publications, wall charts, slide packs, databases, software, hypertext and pseudocode. Each approach offers different benefits. What works best for one audience might not translate to another.

6.  Incompleteness is good:  Security frameworks are more fragmented in their coverage than business, data and IT architectures. It’s because the security solution space is sparse, volatile and lags behind a problem space that’s largely hidden and unpredictable. If you end up with a complete, balanced, filled-in matrix, then you’ve either excluded a good number of unsolved issues or incorporated a large degree of worthless padding. 

7.  Steal with caution:  Copying or adapting other people’s ideas and material is a useful shortcut if the material is sufficiently general and designed for a similar audience. But be warned: organizations vary widely in their tastes, risk profile and governance style. What works in one enterprise for one particular purpose at one particular time, might not translate to other situations. 

8.  Security is event driven:  Security requirements are primarily driven by events, exposures and compliance demands, rather than business needs. Business goals and risk appetites will of course shape all decisions on countermeasures and priorities. But controls and requirements cannot be directly derived from business, data or technology models.  

9.  Cosmetics and politics matter:  The top-level presentation of any model is not critical to the content and is best determined by cosmetic and political considerations. Ease of navigation by the intended user is also an important consideration. Essentially, if it doesn’t look appealing or reflect the politics of organization it won’t be accepted. And if it’s difficult to navigate it won’t get used. 

10.  Design with the future in mind:  The sell-by dates of models or their underlying content can vary widely. Some are highly volatile, others more enduring. Some content can be rendered obsolescent by unanticipated organizational or technological changes. For ease of maintenance, separate fast-changing detail from long-lasting content. And consider the impact of longer-term changes on structures and metadata.

I could of course go on longer, but I think ten suggestions represents about the limit for a memorable set of principles. Any observations?