Cloud Security Frameworks: The Current State

Please note: A verision of this blog appeared on in the Cloud Section as an Intel sponsored post.

Before we jump into discussing cloud security frameworks, I’d like to thank all who responded to my first blog on through Twitteror LinkedIn. It’s rewarding to know that you found my initial blog on cloud security frameworksworthy of comment. I hope you continue to find my ideas interesting.

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 security air gapsto 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 by Network Middleware Applications (NMA), Inc.)

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.

Fort Knox Syndrome.jpg

Figure 1. Typical Enterprise Security Platform

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.

Please join me as I explore the topic of cloud security across upcoming blogs. For now, and reserving the right to add or modify these topics as we move forward, here are the areas I’ll address in the coming months:

  1. Current state security
  2. Security as a factor of cost
  3. Business issues surrounding security
  4. Evaluating new-world security model Investments
  5. Security, data architecture, and big data
  6. Security in Depth (E2E Frameworks)

I’m interested in your feedback on today’s blog in general and, specifically, how your enterprise is approaching E2E security and E2E cloud security. Do you consider the two topics as separate but equal or as one and the same discussion?