Now let's consider today's topic. While attending the University of Southern California, I was introduced to the concept of systems engineering and management. The premise of this discipline is disarmingly simple. First, the boundaries of any system are defined-sometimes erroneously-by the collective perspective of those participating in the effort. Second, the more complex the effort, the greater the interactions and the more difficult the solution. Finally, if you try to focus on a single technology or business component of that system to the exclusion of others, the success and effectiveness of the effort will likely suffer.

In theory, this approach makes sense. But from a more realistic perspective, business, technologists and technology vendors often decide to focus on a single element of a solution and-perhaps intentionally-ignore or overlook proposing solutions from an end-to-end perspective.

I wrote about the potential impact of this approach in a blog titled Cloud Lessons and LeMans. The key takeaway was that to build a workable cloud solution framework, you must understand and react to considerations larger than IT and the data center. In many respects, cloud security requires exactly the same considerations.

Organizational Behavior
A typical IT organization has a stratification of skills, responsibilities, and associated budgets. These are generally structured along platform, operations, and increasingly, lines of business.

Stratification is an inherent byproduct of organizational dynamics and how the success of each group is measured (and, in turn, compensated). In this environment, each group becomes detached from the needs of other groups and tends to define trust and risk based on their needs. The cloud is a community of players made up of many diverse groups. These can include cloud service providers, telco service providers, and perhaps thousands of end users running any number of platforms. If you look at it this way, you begin to understand that the business problems associated with cloud security are significantly harder to resolve than the technical challenges.

Are Security Breaches Linear?
So let's say security breaches are linear in nature (subject to discussion). How does a typical organization defend itself? In a blog written by Billy Cox that discusses both physical and virtual cloud security measures to separate systems, one might envision this defense as a string of very strong fortifications, erected around your platforms or line of business units, which are purpose-built to keep the bad guys out. I like to call this approach the Fort Knox Syndrome. While I wish I could claim this term as my own, that honor goes to Ed Gerck, PhD, in a paper titled End-To-End IT Security that was originally published in 2002 and later republished in 2009.

Otherwise known as the United States Bullion Depository, Fort Knox is a fortified vault in Kentucky that can hold 4,577 metric tons (147.2 million oz. troy) of gold bullion. As you might imagine security in and around the building and its grounds is impressive.

Given the stratification of skills, responsibilities, and budgets described earlier, it shouldn't come as a great surprise that for most organizations, security means building the equivalent of a Fort Knox-type fortification around their platforms and, by default, their application portfolio.

Figure 1 shows how this might look at a platform level.

Although the slide is a bit busy, it shows how the Fort Knox Syndrome works in many enterprises today. Each component is protected by its own firewall (represented by the red line surrounding each of the blue ovals). Within each component of the framework, nobody is really concerned about how their firewall impacts any other component of the system. This acknowledges some of the group-based detachment I mentioned earlier. Each component of the model demands some level of security compliance and ultimately has the right to determine who will-or will not-play within their domain.

The small cylinders in the figure-which represent identity, policy, and compliance-are the enforcers. Think of the identity cylinder as a simple device authentication capability. The policy cylinder represents a set of rules defining who can have access, the conditions, and under what criteria a device or its user is granted access. The compliance cylinder enforces policies such as maintenance of patch levels, firewall uptime, anti-virus definitions, and configuration vulnerability throughout the infrastructure. In a centralized IT shop today, it's likely the data center component of this framework drives compliance of the associated elements.

But even with this simple model, problems are plentiful. When was the last time your organization experienced some type of security glitch when one component was updated and perhaps not fully tested against the umbrella security framework? I think it's safe to conclude that the more federated your framework becomes (via a cloud ecosystem), the more the problems the Fort Knox model generates.

I'm interested in your feedback on today's blog in general and, specifically, on how your enterprise is approaching end-to-end security and end-to-end cloud security. Do you consider the two topics separate but equal, or as one discussion? To join the conversation, please contact me through Twitter.

As a principal enterprise architect, Bob Deutsche provides business and technical advisory services as well as thought leadership to mid- and senior-level executives in the Global 50 and public sector. With 30 years of experience in industry, Bob joined Intel in October 2004. With a varied background that includes data center operations, software development and CIO positions. Bob is a retired Lt. Colonel in the U.S. Air Force and holds a Master's of Science in Systems Management from the University of Southern California, Viterbi School of Engineering.

The above insights were provided to InformationWeek by Intel Corporation as part of a sponsored content program. The information and opinions expressed in this content are those of Intel Corporation and its partners and not InformationWeek or its parent, UBM TechWeb.