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

 

 

 

 

diving airplaneIf 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:
Via flickr user TGIGreeny:

 

 

 

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

 

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?   Please contact me through Twitter.

Filter Blog

By author:
By date:
By tag: