I stumbled across one again. One of those networks. Built upon the notion that a perimeter defense strategy is the best defensive mechanism to keep the bad guys out. Sure the strategy has worked and even provided a great flexibility during merger and acquisition phases of the company. Unfortunately this dog is starting to bite it’s own tail. In writing this, I realize that nearly all networks are built this way and that many of you are struggling with the same problems. Although the 11 commandments from the Jericho Forum are a decent set of ‘rule of thumb’ principles; they aren’t enough to tackle the real problem.

The great flexibility from a trust-network approach, such as perimeter-based defense is obvious. You put a number of criteria in place before trusting an entity. If the entity conforms to the criteria they’re in, if not, they’re out. Very easy to extend your network, as long as you can keep the perimeter alive and robust enough. The problem starts when anomalies occur. Most organization I have talked to during or after lectures or conferences still believe that network de-perimeterization is a conscious choice they have to make and struggle with that choice. Most do not realize that de-perimeterization is something that is happing and needs acting upon.

The first thing I notice when looking a an enterprise network with a perimeter based defensive strategy is the effect of internal openness. Within most single trust-domains, flexibility has lead to a great number of interlinking and inter-dependant connections, dispersed over multiple datacenters. Utilizing services and applications from multiple physical locations is relatively easy in a trust-domain. Providing of course that the physical locations are part of that domain. The longer this situation last, or the larger the enterprise becomes, the greater the complexity of these relations will be. From a technology standpoint that doesn’t have to pose a problem, from a process-engineering standpoint, it does. Having a process dispersed over multiple physical locations increases the overall risk to the process, on all three axils of the CIA triad model (to keep it simple), and on all three axils of the famous ‘people’, ‘process’ and ‘technology’ model. You would generally see a grouping on technology within any datacenter operation. i.e. Unix, Wintel, Linux, RACF, etc. People are assigned to any of these clusters and do their best to make sure that their environment is maintained to the standards that where agreed upon, with limited knowledge of the business process that is touched by these systems. Understandable, it is their task to maintain a Unix server, not a business process, especially when they only facilitate a small piece of that process.

Looking at the Jericho forum commandments, I noticed that they are designed to facilitate the design of a target architecture and offer little help in navigating out of the urban jungle.

-- Marco