Cloud Security Frameworks: A Journey or a Destination?

If you've read any of my previous blogs about the eight fundamental truths of enterprise cloud strategy, you may remember that I sometimes allude to my passion for anything with wings or wheels. Anyone who's gone through basic flight training has had to learn how to recover from a stall. A stall is the point where, due to any number of factors, the wings of the aircraft lose lift. Every aircraft has a stall speed. In basic terms, when you stall, your aircraft becomes immediately vulnerable to the laws of gravity-in the worst way. Depending on a number of variables, it's possible (in fact, likely) that one wing will stall before the other, sending you into a diving spin. Recovery procedures are pretty basic for a spin instigated by a stall (trust me when I tell you it's drilled into pilot's subconscious). Remembering to execute all the steps simultaneously, basic stall recovery involves:

• 1. Throttle back
  
• 2. Nose down
  
• 3. Opposite rudder to spin direction and
  
• 4. Once the spin stops, putting the nose and throttle up to regain control

Unfortunately, no two stalls are exactly the same, so results may vary. Further, each aircraft exhibits slightly different stall characteristics, so these basic recovery procedures may become a bit more involved depending on altitude, nature of the spin (flat or inverted being examples), and how your aircraft responds while in stall. In fact, some aircraft after they enter a stall are exceedingly difficult if not impossible to pull out of a spin initiated by that stall; you can do everything right in your recovery attempt and still end up having a very bad day. Thus, what on the surface is a relatively straightforward recovery process suddenly becomes much more complex. (This is one of the reasons you hope to have an experienced command pilot in the left seat on your flight to Sheboygan.)

A viable cloud security framework is similar. On the surface, it seems pretty basic and should mirror whatever security framework(s) your company has built around your legacy business systems. The problem I see, though, with this simple idea is that not many companies have approached security as an integrated, end-to-end (E2E) framework. An E2E framework begins in your data center, extends to end-user devices, and includes networks, software, staff, attitudes, management, and implementation.

How Do You Define Security?
Let's start with something really basic. How does your company define security? When I was last in Santa Clara, as part of a discussion on security frameworks, a colleague asked me this exact question. After thinking about it, I replied that for me, security equals threat assessment as it relates to risk as a factor of cost (perhaps reflecting some of what I learned in the Air Force).

Shaking his head, my colleague said that in his opinion, security equals insurance. I thought about his answer and how it differed from mine. Perhaps it was a higher-level description? By default, the term "insurance" implies a measure of agreed-upon value. While I think the concept is sound, I'm not sure many companies would be able to put a hard dollar value on security framework breaches. How much is your IP worth? What's the value of a hacked email system? Maybe the cost of a security breach is more qualitative than quantitative? I'd greatly appreciate your feedback on this point.

Next, I recalled another Intel colleague who defined security as a way to provide a safe and secure experience for users. What makes these definitions so interesting is that they're all correct in their original context. Yet, given the community orientation of the cloud, you can understand why this also creates some significant challenges.

How can you possibly prioritize and maximize the value of enterprise security investments if you can't agree on something as fundamental as your organization's E2E security definition? Now you see why I opened this blog with an analogy to recovering an aircraft after it stalls. While it would be nice to believe that one approach to recovery (security) always works, factors outside your influence simply don't allow that to happen. So, whatever your goal for recovering from a stall, you need to have a solid framework to connect whatever scenarios you might encounter, from takeoff to landing (E2E), as events unfold. Even then, there will be instances where you are powerless to avoid the effects of gravity (security breach).

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? 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.