Rational Survivability

The hundreds of tweets of folks guessing as to where I might end up may have been a clue.

Then again, some of you are wise to steer well and clear of The Twitters.
In case you haven’t heard, I’ve decided to leave Cisco and journey over to the “new” hotness that is Juniper.

The reasons. C’mon, really?

OK: Lots of awesome people, innovative technology AND execution, a manageable size, some very interesting new challenges and the ever-present need to change the way the world thinks about, talks about and operationalizes “security.”*

The Beakerettes and I are on our way, moving to San Jose next week and I start at the Big J on July 5th.

All my other hobbies, bad habits (Twitter, this here blog) and side projects (HacKid, CloudAudit, etc.) remain intact.

Catch you all on the flip side.

/Hoff

* So this is getting interpreted oddly. I really had a great time working at Cisco. I worked very hard there.  I felt like I moved the needle, mostly internally.  I had exposure to an amazing amount of technology and people for which I am extremely grateful.  What I also found is that I need to work in a smaller company where the change I bring can be absorbed and utilized at a pace that meets my needs as well as my employer’s.  I’m really looking forward to being able to do that at Juniper.

Related articles

• The 25 Most Influential People Tweeting About Cloud Computing (thenextweb.com)
• Cisco Director of Cloud, Virtualization Security Jumps To Juniper
  (CRN)
• Five Companies That Dropped The Ball This Week
  (CRN)
• Cisco’s cloud director leaves for rival Juniper
  (Washington Business Journal)

The premise of my Commode Computing presentation was to reinforce that we desperately require automation in all aspects of “security” and should work toward leveraging APIs in stacks and products to enable not only control but also audit and compliance across physical and virtualized solutions.

There are numerous efforts underway that underscore both this need and the industry’s response to such.  Platform providers (virtualization and cloud) are leading this charge given that much of their stacks rely upon automation to function and the ecosystem of third party solutions which provide value are following suit, also.

Most of the work exists around ensuring that the latest virtualized versions of products/solutions are API-enabled while the CLI/GUI-focused configuration of older products rely in many cases still on legacy management consoles or intermediary automation and orchestration “middlemen” to automate.

Here’s a great example of how one might utilize (Perl) scripting and RESTful APIs against VMware’s vShield Edge solution to provision, orchestrate and even audit firewall policies using their API. It’s a fantastic write-up from Richard Park of SourceFire (h/t to Davi Ottenheimer for the pointer):

Working with VMware vShield REST API in perl:

Here is an overview of how to use perl code to work with VMware’s vShield API.

vShield App and Edge are two security products offered by VMware. vShield Edge has a broad range of functionality such as firewall, VPN, load balancing, NAT, and DHCP. vShield App is a NIC-level firewall for virtual machines.

We’ll focus today on how to use the API to programatically make firewall rule changes. Here are some of the things you can do with the API:

• List the current firewall ruleset
• Add new rules
• Get a list of past firewall revisions
• Revert back to a previous ruleset revision

Awesome post, Richard.  Very useful. Thanks!

/Hoff

Related articles

• Can IPS Appliances Remain Useful in a Virtual-machine World? (pcworld.com)
• Clouds, WAFs, Messaging Buses and API Security… (rationalsurvivability.com)
• AWS’ New Networking Capabilities – Sucking Less 😉 (rationalsurvivability.com)
• Sourcefire Enables Application Control Within Virtual Environments (it-sideways.com)
• Using The Cloud To Manage The Cloud (informationweek.com)
• Virtualizing Your Appliance Is Not Cloud Security (securecloudreview.com)
• OpenFlow & SDN – Looking forward to SDNS: Software Defined Network Security (rationalsurvivability.com)

Cover via Amazon

I don’t think I’m verbalizing something very well…so I decided to write it down. I still don’t think I’m managing to stick my point, but perhaps clarity will come by discussion.

Simon Wardley has written about market dynamics and behaviors associated with the emergence and ultimate commoditization of things many, many times, but I’m not sure that I’ve found satisfaction in being able to accurately describe the dysfunctional co-dependency between consumer, leading vendor and ecosystem supporters to my liking.

Here’s an example…

There’s an uneasy tension that seems to often become nothing more than wink-and-nod-subtext in discussions relating to the various stacks offered by leading cloud and virtualization vendors.  Even those efforts with the “open” or “open source” descriptor bolted on for good measure.

It occurs to me that this can be attributed to many things; the business and licensing model of the solution provider, the ultimate “consumer” the offering targets, the area(s) of differentiation around technology, the maturity of the ecosystem, and the amount of self-integration versus vendor support required to successfully operationalize and maintain the solution.

More directly, the tension I refer to is the desire (or at least oft-verbalized complaints) on the behalf of “consumers” of cloud and virtualization stacks to not be “locked in” to a single vendor balanced against the odd juxtaposition — but not entirely unreasonable requirement — of simultaneously not being subject to the “integrator’s dilemma,” and having to support it all themselves.

Stir in the ecosystem of ISVs and solutions providers who orbit around these stacks, adding value where they have the “permission” to do so before either the stack provider obviates their existence by baking those features in directly, or simply makes it increasingly more difficult to roadmap given engineering dependencies they can’t control or count on.

I alluded to some of this in my blog titled Cloud Computing, Open* and the Integrator’s Dilemma wherein I mused:

I am just as worried about the fate of OpenStack and its enterprise versus service provider audience and how it’s being perceived as they watch the mad scramble by tech companies to add value and get a seat at the table.

Each of these well-intentioned projects are curated by public cloud operators and technology vendors and are indirectly positioned for the benefit of enterprises, but not really meant for their consumption — at least not if they don’t end up putting enterprises right back where they were trying to escape from in the first place with cloud computing: the integrator’s dilemma.

If you look at the underlying premise of OpenStack — it’s modularity, flexibility and open design — what you get is the ability to craft a solution finely tuned to an operating environment of your design. Integrate solutions into the stack as you see fit.  Contribute code.  Develop an ecosystem. Integrate, manage, maintain…

This is as much a problem as it is a solution for an enterprise.  This is why, in many cases, enterprises choose to use a single vendor with a single neck to choke in order to avoid having to act as an integrator in the first place or simply look to outsource to one or more public cloud providers and avoid this in the first place.

Chances are, most are realistically caught up somewhere in the nether-regions in between the two.

This all sounds so eerily familiar…

Related articles

• Cloud Computing, Open* and the Integrator’s Dilemma(rationalsurvivability.com)
• Citrix Leverages OpenStack With Project Olympus Cloud Platform (ostatic.com)
• RackSpace’s OpenStack Targets Cloud Lock-in (pcworld.com)
• More Signs of the Multiple-OS, Virtualized Future Are Appearing (ostatic.com)
• On balancing economic power in the FLOSS ecosystem (markshuttleworth.com)
• Citrix Commercializes OpenStack & Takes on VMware (gigaom.com)
• Impact of OpenStack Project Goes Beyond the Cloud Industry Leaders (readwriteweb.com)
• Incomplete Thought: The Curious Case Of the Carnival Cloud (rationalsurvivability.com)

Martin McKeay (@mckeay) reminded me of something this morning with his tweet:

To which I am compelled to answer with another question from one of my slides in my “Commode Computing” talk, which is to say “which part of “security” are you referring to?:

“Security” is so heavily fragmented, siloed, specialized and separated from managing “risk,” that Martin’s question, while innocent enough, opens a can of worms not even anti-virus can contain (and *that* is obviously a joke.)

/Hoff

Image via Wikipedia

In my Commode Computing talk, I highlighted the need for security automation through the enablement of APIs.  APIs are centric in architectural requirements for the provisioning, orchestration and (ultimately) security of cloud environments.

So there’s a “dark side” with the emergence of APIs as the prominent method by which one now interacts with stacks — and it’s highlighted in VMware’s vCloud Director Hardening Guide wherein beyond the normal de rigueur deployment of stateful packet filtering firewalls, the deployment of a Web Application Firewall is recommended.

Why?  According to VMware’s hardening guide:

In summary, a WAF is an extremely valuable security solution because Web applications are too sophisticated for an IDS or IPS to protect. The simple fact that each Web application is unique makes it too complex for a static pattern-matching solution. A WAF is a unique security component because it has the capability to understand what characters are allowed within the context of the many pieces and parts of a Web page.

I don’t disagree that web applications/web services are complex. I further don’t disagree that protecting the web services and messaging buses that make up the majority of the exposed interfaces in vCloud Director don’t require sophisticated protection.

This, however, brings up an interesting skill-set challenge.

How many infrastructure security folks do you know that are experts in protecting, monitoring and managing MBeans, JMS/JMX messaging and APIs?  More specifically, how many shops do you know that have WAFs deployed (in-line, actively protecting applications not passively monitoring) that did not in some way blow up every app they sit in front of as well as add potentially significant performance degradation due to SSL/TLS termination?

Whether you’re deploying vCloud or some other cloud stack (I just happen to be reading these docs at the moment,) the scope of exposed API interfaces ought to have you re-evaluating your teams’ skillsets when it comes to how you’re going to deal with the spotlight that’s now shining directly on the infrastructure stacks (hardware and software) their private and public clouds.

Many of us have had to get schooled on web services security with the emergence of SOA/Web Services application deployments.  But that was at the application layer.  Now it’s exposed at the “code as infrastructure” layer.

Think about it.

/Hoff

[Update 6/7/11 – Here are two really timely and interesting blog posts on the topic of RESTful APIs:

• George Reese’s The Good, the Bad, and the Ugly of REST APIs and
• Mark O’Neill’s The REST Doggy Door

Mark’s post has some links to some videos on secure API deployment]

Related articles

• I love WAFs and so should you. (jarrodloidl.blogspot.com)
• AWS’ New Networking Capabilities – Sucking Less 😉 (rationalsurvivability.com)
• Should We Be Limiting Developers API Usage? (programmableweb.com)
• Glass House Syndrome and the Security Industry (ashimmy.com)
• Securing VMware (imperva.com)
• Barracuda Networks Breached (acunetix.com)

Image via Wikipedia

As a follow-on example to my blog titled The Curious Case of the MBO Cloud, in which I detailed the mad rush of companies to deploy something — anything — that looks like a “cloud” to achieve an artificial benchmark of cloudiness, I present you the oft-experienced “Carnival Cloud.”

What’s a Carnival Cloud?

Have you been to Disneyland?  Perhaps a Six Flags theme park?  Perhaps even Coney Island?  If so,  you’ve likely marveled at the engineering and physics associated with some of the rides.  Seeing a train of interconnected people haulers hurtling around a steel (or wooden) substructure of vomit-inducing gravity abuse is a marvelous thing.

I saw a documentary on the construction of some of these modern wonders.  Amazing.  Well modeled, precision engineered, expertly designed and a remarkably good track record of safety.  Yes, sometimes bad things happen, but rarely do you see a rollercoaster at a theme park decommissioned due to inherent design flaws.

I do however sometimes reflect on these rides and the notion that one willingly slaps down some money, straps in, gets rocketed around at 60+ mph pulling G’s rivaling that of some fighter aircraft and realize there’s really no Plan B should something go ass over tea kettles.

One simply has to trust in the quality of design, the skills of the engineering, the on-going maintenance efforts and the 16 year old who pushes the go-button after your crotch-squashing safety bar is slammed into one’s lap and morphs your unmentionables.

…keep your hands inside the ride at all times…

We trust that we’ll come out the other side and give no pause to the fact that the hopes for such are granted by the fact that these rides are often heavily automated, computer controlled and are instrumented to detect failure or flaw.

Now, have you been to a local fair or carnival?

Contrast your experience at Six Flags — often with the same level of risk — with a local carnival ride that’s unloaded from the back of a 1972 Chevy Stepsider, bolted together (and repeatedly unbolted) with some handtools and the sticky residue of lubricating oil and cotton candy.

I don’t know about you, but putting my life in the hands of carnie who does double duty as the bearded lady doesn’t inspire confidence, especially when the Tilt-o-whirl has the potential to demonstrate the unfortunate ramifications of cascading failure domains in physics that run well beyond the fact the some of these operators can’t count past the 4 missing fingers they have on their right hand.

This isn’t saying that carnivals aren’t fun.  This isn’t implying that toothliness ain’t close to Godliness (especially when the afterlife is one missing bolt away.) This isn’t saying you shouldn’t go, thereby missing the nacho cheese-dipped pretzel logs and colon-clogging funnel cakes.

Nay, the point is to simply suggest that there’s a lot to be said for solid infrastructure — regardless of where it’s sourced — that’s performant, safe, operated and maintained in a ruthlessly diligent manner, instrumented well and is subject to constant rigor and inspection.

Relating that to cloud, your experience — depending upon your appetite for risk (and nacho cheese) — will dictate whether your E-ticket ride ends well or as a footnote on MSNBC.

Mmmm. Ableskivers and giant stuffed armadillos.  Anyone got change for a $20?

/Hoff

Related articles

• NY and PA Injury Lawyer: Dangers Lurk at Fairs, Carnivals and Amusement Parks (zifflaw.com)
• 3 rescued from carnival ride (faircarnivals.com)
• Cloud Computing, Open* and the Integrator’s Dilemma (rationalsurvivability.com)

…is still firewalls and SSL.

It is so tempting to write about VMware‘s overarching strategy of enterprise and cloud domination, but this blog entry really speaks to an important foundational element in their stack of offerings which was released today: Horizon App Manager.

Check out @Scobleizer’s interview with Noel Wasmer (Dir. of Product Management for VMware) on the ins-and-outs of HAM.

Frankly, federated identity and application entitlement is not new.

Connecting and extending identities from inside the enterprise using native directory services to external applications (SaaS or otherwise) is also not new.

What’s “new” with VMware’s Horizon App Manager is that we see the convergence and well-sorted integration of a service-driven federated identity capability that ties together enterprise “web” and “cloud” (*cough*)-based SaaS applications with multi-platform device mobility powered by the underpinnings of freshly-architected virtualization and cloud architecture.  All delivered as a service (SaaS) by VMware for $30 per user/per year.

[Update: @reillyusa and I were tweeting back and forth about the inside -> out versus outside -> in integration capabilities of HAM.  The SAML Assertions/OAuth integration seems to suggest this is possible.  Moreover, as I alluded to above, solutions exist today which integrate classical VPN capabilities with SaaS offers that provide SAML assertions and SaaS identity proxying (access control) to well-known applications like SalesForce.  Here’s one, for example.  I simply don’t have any hands-on experience with HAM or any deeper knowledge than what’s publicly available to comment further — hence the “Quick Ping.”]

Horizon App Manager really is a foundational component that will tie together the various components of  VMware’s stack offers for seamless operation including such products/services as Zimbra, Mozy, SlideRocket, CloudFoundry, View, etc.  I predict even more interesting integration potential with components such as elements of the vShield suite — providing identity-enabled security policies and entitlement at the edge to provision services in vCloud Director deployments, for example (esp. now that they’ve acquired NeoAccel for SSL VPN integration with Edge.)

“Securely extending the enterprise to the Cloud” (and vice versa) is a theme we’ll hear more and more from VMware.  Whether this thin client, virtual machines, SaaS applications, PaaS capabilities, etc., fundamentally what we all know is that for the enterprise to be able to assert control to enable “security” and compliance, we need entitlement.

I think VMware — as a trusted component in most enterprises — has the traction to encourage the growth of their supported applications in their catalog ecosystem which will in turn make the enterprise excited about using it.

This may not seem like it’s huge — especially to vendors in the IAM space or even Microsoft — but given the footprint VMware has in the enterprise and where they want to go in the cloud, it’s going to be big.

/Hoff

(P.S. It *is* interesting to note that this is a SaaS offer with an enterprise virtual appliance connector.  It’s rumored this came from the TriCipher acquisition.  I’ll leave that little nugget as a tickle…)

(P.P.S. You know what I want? I want a consumer version of this service so I can use it in conjunction with or in lieu of 1Password. Please.  Don’t need AD integration, clearly)

Related articles

• VMware boots up Horizon cloudy app manager (go.theregister.com)
• VMware Is The New Microsoft, Just Without an OS (gigaom.com)
• Cloud Computing, Open* and the Integrator’s Dilemma (rationalsurvivability.com)

• VMware Is The New Microsoft, Just Without an OS (gigaom.com)
• Cloud Computing, Open* and the Integrator’s Dilemma (rationalsurvivability.com)

Whilst at CloudConnect I filmed some comments with Intel, RSA, Terremark and HyTrust on Intel’s Trusted Execution Technology (TXT) and its implications in the Cloud Computing space specific to “trusted cloud” and using the underlying TPM present in many of today’s compute platforms.

The 30 minute session got cut down into more consumable sound bites, but combined with the other speakers, it does a good job setting the stage for more discussions regarding this important technology.

I’ve written previously on cloud and TXT with respect to measured launch environments and work done by RSA, Intel and VMware: More On High Assurance (via TPM) Cloud Environments. Hopefully we’ll see more adoption soon.

Related articles

• Video: Intel’s Cloud Computing Vision (insidehpc.com)