Rational Survivability

DevOps — what it means and how it applies — is a fascinating topic that inspires all sorts of interesting reactions from people, polarized by their interpretation of what this term really means.

At CloudCamp Denver, adjacent to Gluecon, Aaron Peterson of OpsCode gave a lightning talk titled: “Operations as Code.”  I’ve seen this presentation on-line before, but listened intently as Aaron presented.  You can see John Willis’ version on Slideshare here.  Adrian Cole (@adrianfcole) of jClouds fame (and now Opscode) and I had an awesome hour-long discussion afterwards that was the genesis for this post.

“Operations as Code” (I’ve seen it described also as “Infrastructure as Code”) is really a fantastically sexy and intriguing phrase.  When boiled down, what I extract is that the DevOps “movement” is less about developers becoming operators, but rather the notion that developers can be part of the process whereby they help enable operations/operators to repeatably and with discipline, automate processes that are otherwise manual and prone to error.

[Ed: great feedback from Andrew Shafer: “DevOps isn’t so much about developers helping operations, it’s about operational concerns becoming more and more programmable, and operators becoming more and more comfortable and capable with that.  Further, John Allspaw (@allspaw) added some great commentary below – talking about DevOps really being about tools + culture + communication. Adam Jacobs from Opscode *really* banged out a great set of observations in the comments also. All good perspective.]

Automate, automate, automate.

While I find the message of DevOps totally agreeable, it’s the messaging that causes me concern, not because of the groups it includes, but those that it leaves out.  I find that the most provocative elements of the DevOps “manifesto” (sorry) are almost religious in nature.  That’s to be expected as most great ideas are.

In many presentations promoting DevOps, developers are shown to have evolved in practice and methodology, but operators (of all kinds) are described as being stuck in the dark ages. DevOps evangelists paint a picture that compares and contrasts the Agile-based, reusable componentized, source-controlled, team-based and integrated approach of “evolved” development environments with that of loosely-scripted, poorly-automated, inefficient, individually-contributed, undisciplined, non-source-controlled operations.

You can see how this might be just a tad off-putting to some people.

In Aaron’s presentation, the most interesting concept to me is the definition of “infrastructure.” Take the example to the right, wherein various “infrastructure” roles are described.  What should be evident is that to many — especially those in enterprise (virtualized or otherwise) or non-Cloud environments — is that these software-only components represent only a fraction of what makes up “infrastructure.”

The loadbalancer role, as an example makes total sense if you’re using HAproxy or Zeus ZXTM. What happens if it’s an F5 or Cisco appliance?

What about the routers, switches, firewalls, IDS/IPS, WAFs, SSL engines, storage, XML parsers, etc. that make up the underpinning of the typical datacenter?  The majority of these elements — as most of them exist today — do not present consistent interfaces for automation/integration. Most of them utilize proprietary/closed API’s for management that makes automation cumbersome if not impossible across a large environment.

Many will react to that statement by suggesting that this is why Cloud Computing is the great equalizer — that by abstracting the “complexity” of these components into a more “simplified” set of software resources versus hardware, it solves this problem and without the hardware-centric focus of infrastructure and the operations mess that revolves around it today, we’re free to focus on “building the business versus running the business.”

I’d agree.  The problem is that these are two different worlds.  The mass-market IaaS/PaaS providers who provide abstracted representations of infrastructure are still the corner-cases when compared to the majority of service providers who are entering the Cloud space specifically focused on serving the enterprise, and the enterprise — even those that are heavily virtualized — still very dependent upon hardware.

This is where the DevOps messaging miss comes — at least as it’s described today. DevOps is really targeted (today) toward the software-homogeneity of public, mass-market Cloud environments (such as Amazon Web Services) where infrastructure can be defined as abstract component, software-only roles, not the complex mish-mash of hardware-focused IT of the enterprise as it currently stands. This may be plainly obvious to some, but the messaging of DevOps is obscuring the message which is unfortunate.

DevOps is promoted today as a target operational end-state without explicitly defining that the requirements for success really do depend upon the level of abstraction in the environment; it’s really focused on public Cloud Computing.  In and of itself, that’s not a bad thing at all, but it’s a “marketing” miss when it comes to engaging with a huge audience who wants and needs to get the DevOps religion.

You can preach to the choir all day long, but that’s not going to move the needle.

My biggest gripe with the DevOps messaging is with the name itself. If you expect to truly automate “infrastructure as code,” we really should call it NetSecDevOps. Leaving the network and security teams — and the infrastructure they represent — out of the loop until they are either subsumed by software (won’t happen) or get religion (probable but a long-haul exercise) is counter-productive.

Take security, for example. By design, 95% of security technology/solutions are — by design — not easily automatable or are built to require human interaction given their mission and lack of intelligence/correlation with other tools.  How do you automate around that?  It’s really here that the statement I’ve made that “security doesn’t scale” is apropos. Believe me, I’m not making excuses for the security industry, nor am I suggesting this is how it ought to be, but it is how it currently exists.

Of course we’re seeing the next generation of datacenters in the enterprise become more abstract. With virtualization and cloud-like capabilities being delivered with automated provisioning, orchestration and governance by design for BOTH hardware and software and the vision of private/public cloud integration baked into enterprise architecture, we’re actually on a path where DevOps — at its core — makes total sense.

I only wish that (NetSec)DevOps evangelists — and companies such as Opscode — would  address this divide up-front and start to reach out to the enterprise world to help make DevOps a goal that these teams aspire to rather than something to rub their noses in.  Further, we need a way for the community to contribute things like Chef recipes that allow for flow-through role definition support for hardware-based solutions that do have exposed management interfaces (Ed: Adrian referred to these in a tweet as ‘device’ recipes)

/Hoff

Related articles by Zemanta

• 3 Companies That Tackle Complexity in the Cloud (readwriteweb.com)
• Are You Ready for the New Network? (devcentral.f5.com)
• Understanding cloud and devops–part 1 (news.cnet.com)
• The New DevOps Designers: Cloud and The Big Rethink (slideshare.net)
• Incomplete Thought: The Other Side Of Cloud – Where The (Wild) Infrastructure Things Are… (rationalsurvivability.com)
• Devops (slideshare.net)
• Patching the (Hypervisor) Platform: How Do You Manage Risk? (rationalsurvivability.com)
• Incomplete Thought: “The Cloud in the Enterprise: Big Switch or Little Niche?” (rationalsurvivability.com)
• Security: In the Cloud, For the Cloud & By the Cloud… (rationalsurvivability.com)
• Virtualization & Cloud Don’t Offer An *Information* Security Renaissance… (rationalsurvivability.com)
• Rise of devops (slideshare.net)
• Patching the (Hypervisor) Platform: How Do You Manage Risk? (rationalsurvivability.com)
• Incomplete Thought: “The Cloud in the Enterprise: Big Switch or Little Niche?” (rationalsurvivability.com)
• Security: In the Cloud, For the Cloud & By the Cloud… (rationalsurvivability.com)
• Virtualization & Cloud Don’t Offer An *Information* Security Renaissance… (rationalsurvivability.com)
• Rise of devops (slideshare.net)

Just to point out a fact many/most of you may not be aware of, but Amazon Web Services hired (transferred (?) since he was an AWS insider) Stephen Schmidt as their CISO earlier this year.  He has a team that goes along with him, also.

That’s a very, very good thing. I, for one, am very glad to see it. Combine that with folks like Steve Riley and I’m enthusiastic that AWS will make some big leaps when it comes to visibility, transparency and interaction with the security community.

See. Christmas wishes can come true! Thanks, Santa! 😉

You can find more about Mr. Schmidt by checking out his LinkedIn profile.

/Hoff

Speechless.

The embedded version (Flash) appears below. Direct link here.

“Cloud: Security Doesn’t Matter (Or, In Cloud, Nobody Can Hear You Scream)” by Chris Hoff from Novell, Inc. on Vimeo.

Hysterical.

/Hoff

Last night we saw coverage by Carl Brooks Jo Maitland (sorry, Jo) of an announcement from RackSpace that they were transitioning their IaaS Cloud offerings based on the FOSS Xen platform and moving to the commercially-supported Citrix XenServer instead:

Jaws dropped during the keynote sessions [at Citrix Synergy] when Lew Moorman, chief strategy officer and president of cloud services at Rackspace said his company was moving off Xen and over to XenServer, for better support. Rackspace is the second largest cloud provider after Amazon Web Services. AWS still runs on Xen.

People really shouldn’t be that surprised. What we’re playing witness to is the evolution of the next phase of provider platform selection in Cloud environments.

Many IaaS providers (read: the early-point market leaders) are re-evaluating their choices of primary virtualization platforms and some are actually adding support for multiple offerings in order to cast the widest net and meet specific requirements of their more evolved and demanding customers.  Take Terremark, known for their VMware vCloud-based service, who is reportedly now offering services based on Citrix:

Hosting provider Terremark announced a cloud-based compliance service using Citrix technology. “Now we can provide our cloud computing customers even greater levels of compliance at a lower cost,” said Marvin Wheeler, chief strategy officer at Terremark, in a statement.

Demand for services will drive hypervisor-specific platform choices on the part of provider with networking and security really driving many of those opportunities. IaaS Providers who offer bare-metal boot infrastructure that allows flexibility of multiple operating environments (read: hypervisors) will start to make in-roads.  This isn’t a mass-market provider’s game, but it’s also not a niche if you consider the enterprise as a target market.

Specifically, the constraints associated with networking and security (via the hypervisor) limit the very flexibility and agility associated with what IaaS/PaaS clouds are designed to provide. What many developers, security and enterprise architects want is the ability to replicate more flexible enterprise virtualized networking (such as multiple interfaces/IP’s) and security capabilities (such as APIs) in Public Cloud environments.

Support of specific virtualization platforms can enable these capabilities whether they are open or proprietary (think Open vSwitch versus Cisco Nexus 1000v, for instance.)  In fact, Citrix just announced a partnership with McAfee to address integrated security between the ecosystem and native hypervisor capabilities. See Simon Crosby’s announcement here titled “Taming the Four Horsemen of the Virtualization Security Apocalypse” (it’s got a nice title, too 😉

To that point, are some comments I made on Twitter that describe these points at a high level:

I wrote about this in my post titled “Where Are the Network Virtual Appliances? Hobbled By the Virtual Network, That’s Where…” and what it means technically in my “Four Horsemen of the Virtualization Security Apocalypse” presentation.  Funny how these things come back around into the spotlight.

I think we’ll see other major Cloud providers reconsider their platform architecture from the networking and security perspectives in the near term.

/Hoff

Related articles by Zemanta

• Incomplete Thought: The Cloud Software vs. Hardware Value Battle & Why AWS Is Really A Grid… (rationalsurvivability.com)
• Cloud Providers and Security “Edge” Services – Where’s The Beef? (rationalsurvivability.com)
• Standards Or Openness? (cloudave.com)
• Virtual Networking Battle Heating Up: Citrix Leads $10 Million Investment In Vyatta (rationalsurvivability.com)
• Citrix Unveils Open, Extensible, Turnkey Cloud Solutions (eon.businesswire.com)
• McAfee and Citrix Partner to Make Virtual Desktop Security Simpler and More Scalable (eon.businesswire.com)
• Citrix Unveils Next XenServer Release as New Reports Show Rapid Server Virtualization Market Share Growth (eon.businesswire.com)

I was reading the @emccorp Twitter stream this morning from EMC World and noticed some interesting quotes from RSA’s Art Coviello as he spoke about Cloud Computing and security:

Fundamentally, I don’t disagree that virtualization (and Cloud) can act as fantastic forcing functions that help us focus on securing the things that matter most if we agree on what that is, exactly.

We’re certainly gaining better tools to help us understand how dynamic infrastructure, amorphous perimeters, mobility and  collaboration are affecting our “craft,” however, I disagree with the fact that we’re going to enjoy anything resembling a “turnaround.” I’d suggest it’s more accurate to describe it as a “reach around.”

How, what, where, who and why we do what we do has been dramatically impacted by virtualization and Cloud. For the most part, these impacts are largely organizational and operational, not technological.  In fact, most of the security industry (and networking for that matter) have been caught flat-footed by this shift which is, unfortunately, well underway with the majority of the market leaders scrambling to adjust roadmaps.

The entire premise that you have to consider that your information in a Public Cloud Computing model can be located and operated on by multiple actors (potentially hostile) means we have to really focus back on the boring and laborious basics of risk management and information security.

Virtualization and Cloud computing are simply platforms and operational models respectively.  Security is as much a mindset as it is the cliche’ three-legged stool of “people, process and technology.”  While platforms are important as “vessels” within and upon which we build our information systems, it’s important to realize that at the end of the day, the stuff that matters most – regardless of disruption and innovation in technology platforms — is the information itself.

“Embed[ding] security in” to the platforms is a worthy goal and building survivable systems is paramount and doing a better job of ensuring we consider security at an inflection point such as this is very important for sure.  However, focusing on infrastructure alone reiterates that we are still deluded from the reality that applications and information (infostructure,)  and the protocols that transport them (metastructure) are still disconnected from the cogs that house them (infrastructure.)

Focusing back on infrastructure is not heaven and it doesn’t represent a “do-over,” it’s simply perpetuating a broken model.

We’re already in security hell — or at least one of Dante’s circles of the Inferno. You can’t dig yourself out of a hole by continuing to dig…we’re already not doing it right.  Again.

Two years ago at the RSA Security Conference, the theme of the show was “information centricity” and unfortunately given the hype and churn of virtualization and Cloud, we’ve lost touch with this focus.  Abstraction has become a distraction.  Embedding security into the platforms won’t solve the information security problem. We need to focus on being information centric and platform independent.

By the way, this is exactly the topic of my upcoming Blackhat 2010 talk: “CLOUDINOMICON: Idempotent Infrastructure, Survivable Systems & Bringing Sexy Back to Information Centricity”  Go figure.

/Hoff

Related articles by Zemanta

• Slides from My Cloud Security Alliance Keynote: The Cloud Magic 8 Ball (Future Of Cloud) (rationalsurvivability.com)
• Security: In the Cloud, For the Cloud & By the Cloud… (rationalsurvivability.com)
• [Webinar] Cloud Based Security Services: Saving Cloud Computing Users From Evil-Doers (rationalsurvivability.com)
• You Can’t Secure The Cloud… (rationalsurvivability.com)
• Incomplete Thought: Storage In the Cloud: Winds From the ATMOS(fear) (rationalsurvivability.com)
• Can We Secure Cloud Computing? Can We Afford Not To? (rationalsurvivability.com)
• Cloudifornication: Indiscriminate Information Intercourse Involving Internet Infrastructure (rationalsurvivability.com)
• These Apocalyptic Assessments Of Cloud Security Readiness Are Irrelevant… (rationalsurvivability.com)

When my I interact with folks and they bring up the notion of “Cloud Security,” I often find it quite useful to stop and ask them what they mean.  I thought perhaps it might be useful to describe why.

In the same way that I differentiated “Virtualizing Security, Securing Virtualization and Security via Virtualization” in my Four Horsemen presentation, I ask people to consider these three models when discussing security and Cloud:

1. In the Cloud: Security (products, solutions, technology) instantiated as an operational capability deployed within Cloud Computing environments (up/down the stack.) Think virtualized firewalls, IDP, AV, DLP, DoS/DDoS, IAM, etc.
2. For the Cloud: Security services that are specifically targeted toward securing OTHER Cloud Computing services, delivered by Cloud Computing providers (see next entry) . Think cloud-based Anti-spam, DDoS, DLP, WAF, etc.
3. By the Cloud: Security services delivered by Cloud Computing services which are used by providers in option #2 which often rely on those features described in option #1.  Think, well…basically any service these days that brand themselves as Cloud… 😉

At any rate, I combine these with other models and diagrams I’ve constructed to make sense of Cloud deployment and use cases. This seems to make things more clear.  I use it internally at work to help ensure we’re all talking about the same language.

/Hoff

Related articles by Zemanta

• [Webinar] Cloud Based Security Services: Saving Cloud Computing Users From Evil-Doers (rationalsurvivability.com)
• The Four Horsemen Of the Virtualization (and Cloud) Security Apocalypse… (rationalsurvivability.com)
• DDoS – A Moose On Cloud’s Table Or A Pea Under The Mattress? (rationalsurvivability.com)
• Six Year Old Rationalizes the Cloud (rationalsurvivability.com)
• Cloud Computing Security: (Orchestral) Maneuvers In the Dark? (rationalsurvivability.com)
• Cloudifornication: Indiscriminate Information Intercourse Involving Internet Infrastructure (rationalsurvivability.com)
• You Can’t Secure The Cloud… (rationalsurvivability.com)
• Security and the Cloud – What Does That Even Mean? (rationalsurvivability.com)