Developing a coherent security strategy that focuses on real risks as opposed to the perceived risks in an environment is a notorious challenge. In most cases organizations rely on an ad-hoc approach that is informed by industry experts. Of course there is nothing wrong with this because in some cases these experts get it right. But trends in the industry, however reliable, should not be the primary justification for integrating these recommendations into an organization’s overall strategy. What I’ve been playing with for the past several months is a way to graphically represent the primary components of information systems.

This somewhat abstract representation provides, I think, a method for appropriately mapping the variety of security related concepts onto these primary components. It allows you to see the logical relationships between these primary components. This mapping and relationship allows you to “see” all the security-related practices, controls and technologies as a large story. It presents it as the forest rather than isolated collections of trees to use the “forest in the trees” analogy. I know, it sounds rather obvious doesn’t it? Sadly, there are not many working on this forest view. Sure there are some attempts being made and while they are still useful they have a hard time showing the relationships between the categories. Understanding this interaction is necessary in order to identify and understand real risk.

After many, many sketches, some thinking, research and more sketching I’ve come up with four large abstract classes in this taxonomy. They are not so large as to lose meaning and not small that they become too specific. The real challenge to this is graphically representing these classes while still maintaining their relationship to one another. It is easy to draw a pretty set of circles with data in the innermost circle and the relevant classes of security controls, but such a picture does not accurately communicate the common relational qualities of the individual classes and this is what we are trying to achieve in order to see the risks and develop a practical strategy.

Application - All services, components and applications that are not a required part of an operating system

Platform - The combination of the instruction set architecture and operating system

Persistence - The location and mechanism used to maintain data at rest

Data - The elements that are Created, Read, Updated and Deleted (Yes, this is also an abstraction)

Yes, that really is it. Using logical (for network-based) and physical access methods gives the classes the necessary linkage to one another. Adding actors, entities or whatever term you’d like to use to identify a thing responsible for accessing systems allows you to map the end-to-end relationship of generic (or specific if you’d like) information flow. Before I completely define what these classes are and explain why something like ‘network’ is conspicuously absent I’ll let you think about it for a bit. Oh, I almost forgot. There is a another taxonomy of people, process and technology elements that you can use to “inspect” these other classes to determine what level of security maturity they possess. I’ll give you some ideas on what those are in a later post.