Search Results

Keyword: ‘infrastructure 2.0’

Infrastructure 2.0 and Virtualized/Cloud Networking: Wait, Where’s My DNS/DHCP Server Again?

December 8th, 2008 5 comments

I read James Urquhart's first blog post written under the Cisco banner today titled "The network: the final frontier for cloud computing" in which he describes the evolving role of "the network" in virtualized and cloud computing environments.

The gist of his post, which he backs up with examples from Greg Ness' series on Infrastructure 2.0, is that in order to harness the benefits of virtualization and cloud computing, we must automate; from the endpoint to the underlying platforms — including the network — manual processes need to be replaced by automated capabilities:

When was the last time you thought “network” when you heard
“cloud computing”? How often have you found yourself working out
exactly how you can best utilize network resources in your cloud
applications?  Probably never, as to date the network hasn’t registered
on most peoples’ cloud radars.

This is understandable, of course, as the early cloud efforts try to
push the entire concept of the network into a simple “bandwidth”
bucket.  However, is it right? Should the network just play dumb and
let all of the intelligence originate at the endpoints?


The writing is on the wall. The next frontier to get explored in
depth in the cloud world will be the network, and what the network can
do to make cloud computing and virtualization easier for you and your
organization

If you walked away from James' blog as I did initially, you might be left with the impression that this isn't really about "the network" gaining additional functionality or innovative capabilities, but rather just tarting up the ability to integrate with virtualization platforms and automate it all.

Doesn't really sound all that sexy, does it.  Well, it's really not, which is why even today in non-virtualized environments we don't have very good automation and most processes still come down to Bob at the helpdesk. Virtualization and cloud are simply giving IT a swift kick in the ass to ensure we get a move on to extract as much efficiency and remove as much cost from IT as possible.

Don't be fooled by the simplicity of James' post, however, because there's a huge moose lurking under the table instead of on top of it and it goes toward the fundamental crux of the battle brewing between all those parties interested in becoming your next "datacenter OS" provider.

There exists one catalytic element that produces very divergent perspectives in IT around what, where, why and who automates things and how, and that's the very definition of "the network" in virtualized and cloud models.

How someone might describe "the network" as either just a "bandwidth bucket" of feeds and speeds or an "intelligent, aware, sentient platform for service delivery" depends upon whether you're really talking about "the network" as a subset or a superset of "the infrastructure" at large.

Greg argues that core network services such as IP adddress management, DNS, DHCP, etc. are part of the infrastructure and I agree, but given what we see today, I would say that they are part-in-parcel NOT a component of "the network" — they're generally separate and run atop the plumbing.  There's interaction, for sure, but one generally relies upon these third party service functions to deliver service.  In fact, that's exactly the sort of thing that Greg's company, Infoblox, sells.

This contributes to part of this definitional quandary.

Now we have this new virtualization layer injected between the network and the rest of the infrastructure which provides a true lever and frictionless capability for some of this automation but further confuses the definition of "the network" since so much of the movement and delivery of information is now done at this layer and it's not integrated with the traditional hardware-based network.*

See what I mean in this post titled "The Network Is the Computer…(Is the Network, Is the Computer…)"

This is exactly why you see Cisco's investment in bringing technologies such as VN-Link and the Nexus-1000v virtual switch to virtualized environments; it homogenizes "the network." It claws back the access layer so they can allow the network teams to manage the network again (and "automate" it) while also getting their hooks deeper into the virtualization layer itself. 

And that's where this gets interesting to me because in order to truly automate virtualized and cloud computing environments, this means one of three things as it relates to where core/critical infrastructure services live:

  1. They  will continue to be separate as stand-alone applications/appliances or bundled atop an OS
  2. They become absorbed by "the (traditional) network" and extend into the virtualization layer
  3. They get delivered as part of the virtualization layer

So if you're like most folks and run Microsoft-based "core network services" for things (at least internally) like DNS, DHCP, etc., what does this mean to you?  Well, either you continue as-is via option #1, you transition to integrated services in "the network" via option #2 or you end up with option #3 by the very virtue that you'll upgrade to Windows Server 2008 and Hyper-V anyway.

SO, this means that the level of integration between, say, Cisco and Microsoft will have to become as strong as it is with VMware in order to support the integration of these services as a "network" function, else they'll continue — in those environments at least — as being a "bandwidth bucket" that provides an environment that isn't really automated.

In order to hit the sweet spot here, Cisco (and other network providers) need to then start offering core network services as part of "the network."  This means wrestling it away from the integrated OS solutions or simply buying their way in by acquiring and then integrating these services ($10 Cisco buys Infoblox…)

We also see emerging vendors such as Arista Networks who are entering the grid/utility/cloud computing network market with high density, high-throughput, lower cost "cloud networking" switches that are more about (at least initially) bandwidth bucketing and high-speed interconnects rather than integrated and virtualized core services.  We'll see how the extensibility of Arista's EOS affects this strategy in the long term.

There *is* another option and that's where third party automation, provisioning, and governance suites come in that hope to tame this integration wild west by knitting together this patchwork of solutions. 

What's old is new again.

/Hoff

*It should be noted, however, that not all things can or should be
virtualized, so physical non-virtualized components pose another
interesting challenge because automating 99% of a complex process isn't
a win if the last 1% is a gating function that requires human
interaction…you haven't solved the problem, you've just made it less
steps that still requires Bob at the helpdesk..

 

Categories: Cloud Computing, Virtualization Tags:

Navigating PCI DSS (2.0) – Related to Virtualization/Cloud, May the Schwartz Be With You!

November 1st, 2010 3 comments

[Disclaimer: I’m not a QSA. I don’t even play one on the Internet. Those who are will generally react to posts like these with the stock “it depends” answer, to which I respond “you’re right, it does.  Not sure where that leaves us other than with a collective sigh, but…]

The Payment Card Industry (PCI) last week released version 2.0 of the Data Security Standard (DSS.) [Legal agreement required]  This is an update from v1.2.1 but strangely does not introduce any major new requirements but instead clarifies language.

Accompanying this latest revision is also a guidance document titled “Navigating PCI DSS: Understanding the Intent of the Requirements, v2.0” [PDF]

One of the more interesting additions in the guidance is the direct call-out of virtualization which, although late to the game given the importance of this technology and its operational impact, is a welcome edition to this reader.  I should mention I’ve sat in on three of the virtualization SIG calls which gives me an interesting perspective as I read through the document.  Let me just summarize by saying that “…you can’t please all the people, all of the time…” 😉

What I find profoundly interesting is that since virtualization is a such a prominent and enabling foundational technology in IaaS Cloud offerings, the guidance is still written as though the multi-tenant issues surrounding cloud computing (as an extension of virtualization) don’t exist and that shared infrastructure doesn’t complicate the picture.  Certainly there are “cloud” providers who don’t use infrastructure shared with other providers beyond themselves in order to deliver service to different customers (I think we call them SaaS providers,) but think about the context of people wanting to use AWS to deliver services that are in scope for PCI.

Here’s what the navigation document has to say specific to virtualization and ultimately how that maps to IaaS cloud offerings.  We’re going to cover just the introductory paragraph in this post with the guidance elements and the actual DSS in a follow-on.  However, since many people are going to use this navigation document as their first blush, let’s see where that gets us:

PCI DSS requirements apply to all system components. In the context of PCI DSS, “system components” are defined as any network component, server or application that is included in, or connected to, the cardholder data environment. System components” also include any virtualization components such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, and hypervisors.

I would have liked to see specific mention of virtual storage here and although it’s likely included by implication in the management system/sub-system mentions above and below, the direct mention of APIs. Thanks to heavy levels of automation, the operational movements related to DevOps and with APIs becoming the interface of the integration and management planes, these are unexplored lands for many.

I’m also inclined to wonder about virtualization approaches that is not server-centric such as physical networking devices, databases, etc.

If virtualization is implemented, all components within the virtual environment will need to be identified and considered in scope for the review, including the individual virtual hosts or devices, guest machines, applications, management interfaces, central management consoles, hypervisors, etc. All intra-host communications and data flows must be identified and documented, as well as those between the virtual component and other system components.

It can be quite interesting to imagine the scoping exercises (or de-scoping more specifically) associated with this requirement in a cloud environment.  Even if the virtualized platforms are operated solely on behalf of a single customer (read: no shared infrastructure — private cloud,)  this is still an onerous task, so I wonder how — if at all — this could be accomplished in a public IaaS offering given the lack of transparency we see in today’s cloud operators.  Much of what is being asked for relating to infrastructure and “data flows” between the “virtual component and other system components” represents the CSP’s secret sauce.

The implementation of a virtualized environment must meet the intent of all requirements, such that the virtualized systems can effectively be regarded as separate hardware. For example, there must be a clear segmentation of functions and segregation of networks with different security levels; segmentation should prevent the sharing of production and test/development environments; the virtual configuration must be secured such that vulnerabilities in one function cannot impact the security of other functions; and attached devices, such as USB/serial devices, should not be accessible by all virtual instances.

“…clear segmentation of functions and segregation of networks with different security levels” and “the virtual configuration must be secured such that vulnerabilities in one function cannot impact the security of other functions,” eh? I don’t see how anyone can expect to meet this requirement in any system underpinned with a virtualized infrastructure stack (hardware or software) whether it’s multi-tenant or not.  One vulnerability in the hypervisor makes this an impossibility.  Add in management, storage, networking. This basically comes down to trusting in the sanctity of the hypervisor.

Additionally, all virtual management interface protocols should be included in system documentation, and roles and permissions should be defined for managing virtual networks and virtual system components. Virtualization platforms must have the ability to enforce separation of duties and least privilege, to separate virtual network management from virtual server management.

Special care is also needed when implementing authentication controls to ensure that users authenticate to the proper virtual system components, and distinguish between the guest VMs (virtual machines) and the hypervisor.

The rest is pretty standard stuff, but if you read the guidance sections (next post) it gets even more fun.  This is why the subjectivity, expertise and experience of the QSA is so related to the quality of the audit when virtualization and cloud are involved.  For example, let’s take a sneak peek at section 2.2.1, as it is a bit juicy:

2.2.1 Implement only one primary function per server to prevent functions that require different security levels from co-existing
on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.)
Note: Where virtualization technologies are in use, implement only one primary function per virtual system component
.

I  acknowledge that there are “cloud” providers who are PCI certified at the highest tier.  Many of them are SaaS providers.  Many simply use their own server stacks in co-located facilities but due to their size and services merely call themselves cloud providers — many aren’t even virtualized per the description above.   Further, there are also methods of limiting scope and newer technologies such as tokenization that can assist in solving some of the information-centric issues with what would otherwise be in-scope data, but they offset many of the cost-driven efficiencies marketed by mass-market, low-cost cloud providers today.

Love to hear from an IaaS public cloud provider who is PCI certified (to the VM boundary) with customers that are in turn certified with in-scope applications and cardholder data or even a SaaS provider who sits atop an IaaS provider…

Just read this first before responding, please.

/Hoff

Enhanced by Zemanta

What To Do When Your “Core” Infrastructure Services Aren’t In Your “Core?”

January 21st, 2009 11 comments
Okay.  I am teh lam3r.  I'd be intellectually dishonest if I didn't post this, and it's likely I'll revise it once I get to think about it more, but I've got to get it down.  Thanks to an innocent tweet from @botchagalupe I had an aneurysm epiphany.  Sort of 😉

A little light went on in my head this morning regarding how the cloud, or more specifically layers of clouds and the functions they provide (a-la SOA,) dramatically impact the changing landscape of what we consider "core infrastructure services," our choices on architecture, service provisioning, and how and from whence they are provided.  

Specifically, the synapse fired on the connection between Infrastructure 2.0 as is usually talked about from the perspective of the evolution from the enterprise inside to out versus the deployment of services constructed from scratch to play in the cloud.

You've no doubt seen discussions from Greg Ness (InfoBlox) and Lori Mac Vittie (f5) regarding their interpretation of Infrastructure 2.0 and the notion that by decoupling infrastructure services from their physical affinity we can actually "…enable greater levels of integration between the disparate layers of infrastructure: network, application, the endpoint, and IP address management, necessary to achieve interconnectedness."

Totally agree.  Been there, done that, bought the T-Shirt, but something wasn't clicking as it relates to what this means relative to cloud.

I was slurping down some java this morning and three things popped into my head as I was flipping between Twitter and Google Reader wondering about how I might consider launching a cloud-based service architecture and what impact it would have on my choices for infrastructure and providers.

Here are the three things that I started to think about in regards to what "infrastructure 2.0" might mean to me in this process, beyond the normal criteria related to management, security, scalability, etc…
  1. I always looked at these discussions of Infrastructure 2.0 as ideation/marketing by vendors on how to take products that used to function in the "Infratructure 1.0" dominion, add a service control plane/channel and adapt them for the inside-out version of the new world order that is cloud. This is the same sort of thing we've dealt with for decades and was highlighted when one day we all discovered the Internet and had to connect to it — although in that case we had standards!
  2. Clouds are often discussed in either microcosmic vacuum or lofty, fluffy immensity and it makes it hard to see the stratosphere for the cirrocumulus.  Our "non-cloud" internal enterprises today are conglomerates of technology integration with pockets of core services which provide the underpinnings for much of what keeps the machinery running.  Cloud computing is similar in approach, but in this regard, it brings home again the point that there is no such thing as "THE Cloud" but rather that the overarching integration challenge lays in the notion of overlays or mash-ups of multiple clouds, their functions, and their associated platforms and API's. 
  3. Further, and as to my last blog post on private clouds and location independence, I really do believe that the notion of internal versus external clouds is moot, but that the definitional nuance of public versus private clouds — and their requisite control requirements — are quite important.  Where, why, how and by whom services are provided becomes challenging because the distinction between inside and out can be really, really fuzzy, even more so if you're entirely cloud based in the first place.
For some reason, my thinking never really coalesced on how what relevance these three points have as it relates to the delivery of a service (and thus layers of applications) in a purely cloud based architecture built from scratch without the encumbrance of legacy infrastructure solutions.  

I found this awesome blog post from Mike Brittain via a tweet from @botchagalupe titled "How we built a web hosting infrastructure on EC2" and even though the article is a fascinating read, the single diagram in the post hit me like a hammer in the head…and I don't know why it did, because it's not THAT profound, but it jiggled something loose that is probably obvious to everyone else already:

Ec2-architecture-full
Do you see the first three layers?  Besides the "Internet," as the transport, you'll see two of the most important service delivery functions staring back at you: Akamai's "Site Accelerator Proxy" CDN/Caching/Optimization offering and Neustar's "UltraDNS" distributed, topologically intelligent DNS services

Both of these critical services (one might say "core infrastructure 2.0" services) are, themselves, cloud-based.  Of course, the entire EC2/S3 environment which hosts the web services is cloud-based, too.

The reason the light bulb went on for me is that I found that I was still caught in the old school infrastructure-as-a-box line of thought when it came to how I might provide the CDN/Caching and distributed DNS capabilities of my imaginary service.

It's likely I would have dropped right to the weeds and started thinking about which geographic load balancers (boxes) and/or proxies I might deploy somewhere and how (or if) they might integrate with the cloud "hosting/platform provider" to give me the resiliency and dynamic capabilities I wanted, let alone firewalls, IDP, etc.

Do I pick a provider that offers as part of the infrastructure a specific hardware-based load-balancing platform?  Do I pick on that can accommodate the integration of a software-based virtual appliances. Should I care?  With the cloud I'm not supposed to, but I find that I still, for many reasons — good and bad — do.

I never really thought about simply using a cloud-based service as a component in a mash-up of services that already does these things in ways that would be much cheaper, simpler, resilient and scalable than I could construct with "infrastructure 1.0" thinking.   Heck, I could pick 2 or 3 of them, perhaps. 

That being said, I've used outsourced "cloud-based" email filtering, vulnerability management, intrusion detection & prevention services, etc., but there are still some functions that for some reason appear to sacrosanct in the recesses of my mind?

I think I always just assumed that the stacking of outsourced (commoditized) services across multiple providers would be too complex but in reality, it's not very different from my internal enterprise that has taken decades to mature many of these functions (and consolidate them.)

Despite the relative immaturity of the cloud, it's instantly benefited from this evolution. Now, we're not quite all the way there yet.  We still are lacking standards and that service control plane shared amongst service layers doesn't really exist.

I think it's a huge step to recognize that it's time to get over the bias of applying so called "infrastructure 1.0" requirements to the rules of engagement in the cloud by recognizing that many of these capabilities don't exist in the enterprise, either.

Now, it's highly likely that the two players above (Neustar and Akamai) may very well use the same boxes that *I* might have chosen anyway, but it's irrelevant.  It's all about the service and engineering enough resiliency into the design (and choices of providers) such that I mitigate the risk of perhaps not having that "best of breed" name plate on a fancy set of equipment somewhere.

I can't believe the trap I fell into in terms of my first knee-jerk reaction regarding architecture, especially since I've spent so much of the last 5 years helping architect and implement "cloud" or "cloud-like" security services for outsourced capabilities.

So anyway, you're probably sitting here saying "hey, idiot, this is rather obvious and is the entire underlying premise of this cloud thing you supposedly understand inside and out."  That comment would be well deserved, but I had to be honest and tell you that it never really clicked until I saw this fantastic example from Mike.

Huh.

/Hoff

Secure Services in the Cloud (SSaaS/Web2.0) – InternetOS Service Layers

July 13th, 2007 2 comments

Internet
The last few days of activity involving Google and Microsoft have really catalyzed some thinking and demonstrated some very intriguing indicators as to how the delivery of applications and services is dramatically evolving. 

I don’t mean the warm and fuzzy marketing fluff.  I mean some real anchor technology investments by the big-boys putting their respective stakes in the ground as they invest hugely in redefining their business models to setup for the future.

Enterprises large and small are really starting to pay attention to the difference between infrastructure and architecture and this has a dramatic effect on the service providers and supply chain who interact with them.

It’s become quite obvious that there is huge business value associated with divorcing the need for "IT" to focus on physically instantiating and locating "applications" on "boxes" and instead  delivering "services" with the Internet/network as the virtualized delivery mechanism.

Google v. Microsoft – Let’s Get Ready to Rumble!

My last few posts on Google’s move to securely deliver a variety of applications and services represents the uplift of the "traditional" perspective of backoffice SaaS offerings such as Salesforce.com but also highlights the migration of desktop applications and utility services to the "cloud" also.

This is really executing on the vision of the thin-client Internet-centric vision from back in the day o’ the bubble when we saw a ton of Internet-borne services such as storage, backup, etc.  using the "InternetOS" as the canvas for service.

So we’ve talked about Google.  I maintain that their strategy is to ultimately take on Microsoft — including backoffice, utility and desktop applications.  So let’s look @ what the kids from Redmond are up to.

What Microsoft is developing towards with their vision of CloudOS was just recently expounded upon by one Mr. Ballmer.

Not wanting to lose mindshare or share of wallet, Microsoft is maneuvering to give the customer control over how they want to use applications and more importantly how they might be delivered.  Microsoft Live bridges the gap between the traditional desktop and puts that capability into the "cloud."

Let’s explore that a little:

In addition to making available its existing services, such as mail and
instant messaging, Microsoft also will create core infrastructure
services, such as storage and alerts, that developers can build on top
of. It’s a set of capabilities that have been referred to as a "Cloud OS," though it’s not a term Microsoft likes to use publicly.

Late last month, Microsoft introduced two new Windows Live Services,
one for sharing photos and the other for all types of files. While
those services are being offered directly by Microsoft today, they
represent the kinds of things that Microsoft is now promising will be
also made available to developers.

Among the other application and infrastructure components,
Microsoft plans to open are its systems for alerts, contact management,
communications (mail and messenger) and authentication.

As it works to build out the underlying core services, Microsoft is
also offering up applications to partners, such as Windows Live
Hotmail, Windows Live Messenger and the Spaces blogging tool.

Combine the emerging advent of "thinner" end-points (read: mobility products) with high-speed, lower latency connectivity and we can see why this model is attractive and viable.  I think this battle is heating up and the consumer will benefit.

A Practical Example of SaaS/InternetOS Today?

So if we take a step back from Google and Microsoft for a minute, let’s take a snapshot of how one might compose, provision, and deploy applications and data as a service using a similar model over the Internet with tools other than Live or GoogleGear.

Let me give you a real-world example — deliverable today — of this capability with a functional articulation of this strategy; on-demand services and applications provided via virtualized datacenter delivery architectures using the Internet as the transport.  I’m going to use a mashup of two technologies: Yahoo Pipes and 3tera’s AppLogic.

Yahoo Pipes is  "…an interactive data aggregator and manipulator that lets you mashup your favorite online data sources."  Assuming you have data from various sources you want to present an application environment such as Pipes will allow you to dynamically access, transform and present this information any way you see fit.

This means that you can create what amounts to application and services on demand. 

Let’s agree however that while you have the data integration/presentation layer, in many cases you would traditionally require a complex collection of infrastructure from which this source data is housed, accessed, maintained and secured. 

However, rather than worry about where and how the infrastructure is physically located, let’s use the notion of utility/grid computing to make available dynamically an on-demand architecture that is modular, reusable and flexible to make my service delivery a reality — using the Internet as a transport.

Enter 3Tera’s AppLogic:

3Tera’s AppLogic is used by hosting providers to offer true utility computing. You get all the control of having your own virtual datacenter, but without the need to operate a single server.

Deploy and operate applications in your own virtual private datacenter

Set up infrastructure, deploy apps and manage operations with just a browser    
Scale from a fraction of a server to hundreds of servers in days

Deploy and run any Linux software without modifications

Get your life back: no more late night rushes to replace failed equipment

In fact, BT is using them as part of the 21CN project which I’ve written about many times before.

So check out this vision, assuming the InternetOS as a transport.  It’s the drag-and-drop, point-and-click Metaverse of virtualized application and data combined with on-demand infrastructure.

You first define the logical service composition and provisioning through 3Tera with a visual drag-drop canvas, defining firewalls, load-balancers, switches, web servers, app. servers, databases, etc.  Then you click the "Go" button.  AppLogic provisions the entire thing for you without you even necessarily knowing where these assets are.

Then, use something like Pipes to articulate how data sources can be accessed, consumed and transformed to deliver the requisite results.  All over the Internet, transparent to you securely.

Very cool stuff.

Here are some screen-caps of Pipes and 3Tera.

Yahoopipes

3tera

 

 

 

Hack The Stack Or Go On a Bender With a Vendor?

September 24th, 2010 4 comments
Cloud computing icon
Image via Wikipedia

I have the privilege of being invited around the world to talk with (and more importantly) listen to some of the biggest governments, enterprises and service providers about their “journey to cloud computing.”

I feel a bit like Kwai Chang Caine from the old series Kung-Fu at times; I wander about blind but full of self-assured answers to the questions I seek to ask, only to realize that asking them is more important than knowing the answer — and that’s the point.  Most people know the answers, they just don’t know how — or which — questions to ask.

Yes, it’s a Friday.  I always get a little philosophical on Fridays.

In the midst of all this buzz and churn, there’s a lot of talk but depending upon the timezone and what dialect of IT is spoken, not necessarily a lot of compelling action.  Frankly, there’s a lot of analysis paralysis as companies turn inward to ask questions of themselves about what cloud computing does or does not mean to them. (Ed: This comment seemed to suggest to some that cloud adoption was stalled. Not what I meant. I’ll clarify by suggesting that there is brisk uptake in many areas, but it’s diversified, split between many parallel paths I reference below; public and private deployments. It doesn’t mean it’s harmonious, however.)

There is, however, a recurring theme across geography, market segment, culture and technology adoption appetites; everyone is seriously weighing their options regarding where, how and with whom to make their investments in terms of building cloud computing infrastructure (and often platform) as-a-service strategy.  The two options, often discussed in parallel but ultimately bifurcated based upon explored use cases come down simply to this:

  1. Take any number of available open core or open source software-driven cloud stacks, commodity hardware and essentially engineer your own Amazon, or
  2. Use proprietary or closed source virtualization-nee-cloud software stacks, high-end “enterprise” or “carrier-class” converged compute/network/storage fabrics and ride the roadmap of the vendors

One option means you expect to commit to an intense amount of engineering and development from a software perspective, the other means you expect to focus on integration of other companies’ solutions.  Depending upon geography, it’s very, very unclear to enterprises of service providers what is the most cost-effective and risk-balanced route when use-cases, viability of solution providers and the ultimate consumers of these use-cases are conflated.

There is no one-size-fits-all solution.  There is no ‘THE Cloud.”

This realization is why most companies are spinning around, investigating the myriad of options they have available and the market is trying to sort itself out, polarized at one end of the spectrum or trying to squeeze out a happy balance somewhere in the middle.

The default position for many is to go with what they know and “bolt on” new technology both tactically (in absence of an actual long-term strategy) to revamp what they already have.

This is where the battle between “public” versus “private” cloud rages — where depending upon which side of the line you stand, the former heralds the “new” realized model of utility computing and the latter is seen as building upon virtualization and process automation to get more agile.  Both are realistically approaching a meet-in-the-middle strategy as frustration mounts, but it’s hard to really get anyone to agree on what that is.  That’s why we have descriptions like “hybrid” or “virtual private” clouds.

The underlying focus for this discussion is, as one might imagine, economics.  What architects (note I didn’t say developers*) quickly arrive at is that this is very much a “squeezing the balloon problem.” Both of these choices hold promise and generally cause copious amounts of iteration and passionate debate centered on topics like feature agility, compliance, liability, robustness, service levels, security, lock-in, utility and fungibility  of the solutions.  But it always comes back to cost.

Hard costs are attractive targets that are easily understood and highly visible.  Soft costs are what kill you.  The models by which the activity and operational flow-through — and ultimate P&L accountability of IT — are still black magic.

The challenge is how those costs are ultimately modeled and accounted for and how to appropriately manage risk. Nobody wants the IT equivalent of credit-default swaps where investments are predicated on a house of cards and hand-waving and at the same time, nobody wants to be the guy whose obituary reads “didn’t get fired for buying IBM.”

Interestingly, the oft-cited simplicity of the “CapEx vs. OpEx” discussion isn’t so simple in hundred year old companies whose culture is predicated upon the existence of processes and procedures whose ebb and flow quite literally exist on the back of TPM reports.  You’d think that the way many of these solutions are marketed — both #1 and #2 above — that we’ve reached some sort of capability/maturity model inflection point where either are out of diapers.

If this were the case, these debates wouldn’t happen and I wouldn’t be writing this blog.  There are many, many tradeoffs to be made here. It’s not a simple exercise, no matter who it is you ask — vendors excluded 😉

Ultimately these discussions — and where these large companies and service providers with existing investment in all sorts of solutions (including previous generations of things now called cloud) are deciding to invest in the short term — come down to the following approaches to dealing with “rolling your own” or “integrating pre-packaged solutions”:

  1. Keep a watchful eye on the likes of mass-market commodity cloud providers such as Amazon and Google. Use (enterprise) and/or emulate the capabilities (enterprise and service providers) of these companies in opportunistic and low-risk engagements which distribute/mitigate risk by targeting non-critical applications and information in these services.  Move for short-term success while couching wholesale swings in strategy with “pragmatic” or guarded optimism.
    .
  2. Distract from the back-end fracas by focusing on the consumption models driven by the consumerization of IT that LOB and end users often define as cloud.  In other words, give people iPhones, use SaaS services that enrich user experience, don’t invest in any internal infrastructure to deliver services and call it a success while trying to figure out what all this really means, long term.
    .
  3. Stand up pilot projects which allow dabbling in both approaches to see where the organizational, operational, cultural and technological landmines are buried.  Experiment with various vendors’ areas of expertise and functionality based upon the feature/compliance/cost see-saw.
    .
  4. Focus on core competencies and start building/deploying the first iterations of “infrastructure 2.0” with converged fabrics and vendor-allied pre-validated hardware/software, vote with dollars on cloud stack adoption, contribute to the emergence/adoption of “standards” based upon use and quite literally *hope* that common formats/packaging/protocols will arrive at portability and ultimately interoperability of these deployment models.
    .
  5. Drive down costs and push back by threatening proprietary hardware/software vendors with the “fact” that open core/open source solutions are more cost-effective/efficient and viable today whilst trying not to flinch when they bring up item #2 questioning where and how you should be investing your money and what your capabilities really are is it relates to development and support.  React to that statement by threatening to move all your apps atop  someone elses’ infrastructure. Try not to flinch again when you’re reminded that compliance, security, SLA’s and legal requirements will prevent that.  Rinse, lather, repeat.
    .
  6. Ride out the compliance, security, trust and chasm-crossing comfort gaps, hedging bets.

If you haven’t figured it out by now, it’s messy.

If I had to bet which will win, I’d put my money on…<carrier lost>

/Hoff

*Check out Bernard Golden’s really good post “The Truth About What Really Runs On Amazon” for some insight as to *who* and *what* is running in public clouds like AWS.  The developers are leading the charge.  Often times they are disconnected from the processes I discuss above, but that’s another problem entirely, innit?

Enhanced by Zemanta
Categories: Cloud Computing Tags:

Don’t Hassle the Hoff: Recent Press & Podcast Coverage & Upcoming Speaking Engagements

February 19th, 2010 No comments

Here is some of the recent coverage from the last couple of months or so on topics relevant to content on my blog, presentations and speaking engagements.  No particular order or priority and I haven’t kept a good record, unfortunately.

Important Stuff I’m Working On:

Press/Technology & Security eZines/Website/Blog Coverage/Meaningful Links:

Recent Speaking Engagements/Confirmed to  speak at the following upcoming events:

  • Govt Solutions Forum Feb 1-2 (panel |n DC)
  • Govt Solutions Forum Feb 24 D.C.
  • ESAF, San Francisco, March 1
  • Cloud Security Alliance Summit, San Francisco, March 1
  • RSA Security Conference March 1-5 San Francisco
  • Microsoft Bluehat Buenos Aires, Argentina – March 16-19th
  • ISSA General Assembly, Belgium
  • Infosec.be, Belgium
  • Codegate, South Korea, April 7-8
  • SOURCE Boston, April 21-23
  • Shot the Sherrif – Brazil – May 17th
  • Gluecon , Denver, May 26/27
  • FIRST, Miami, FL,  June 13-18
  • SANS DC – August 19th-20th

Conferences I am tentatively attending, trying to attend and/or working on logistics for speaking:

  • InterOp April 25-29 Vegas
  • Cisco Live – June 27th – July 1st Vegas
  • Blackhat 2010 – July 24-29 Vegas
  • Defcon
  • Notacon

Oh, let us not forget these top honors (buahahaha!)

  • Top 10 Sexy InfoSec Geeks (link)
  • The ThreatPost “All Decade Interview Team” (link)
  • ‘Cloud Hero’ and ‘Best Cloud Presentation’ – 2009 Cloudies Awards (link), and
  • 2010 RSA Social Security Bloggers Award nomination (link) 😉

[I often get a bunch of guff as to why I make these lists: ego, horn-tooting, self-aggrandizement. I wish I thought I were that important. 😉 The real reason is that it helps me keep track of useful stuff focused not only on my participation, but that of the rest of the blogosphere.]

/Hoff

From the X-Files – The Cloud in Context: Evolution from Gadgetry to Popular Culture

November 27th, 2009 4 comments

apple1984

[This post was originally authored November 27, 2009.  I pushed it back to the top of the stack because I think it’s an interesting re-visitation of the benefits and challenges we are experiencing in Cloud today]

Below is an article I wrote many months ago prior to all the Nicholas Carr “electricity ain’t Cloud” discussions.  The piece was one from a collection that was distributed to “…the Intelligence Community, the DoD, and Congress” with the purpose of giving a high-level overview of Cloud security issues.

The Cloud in Context: Evolution from Gadgetry to Popular Culture

It is very likely that should one develop any interest in Cloud Computing (“Cloud”) and wish to investigate its provenance, one would be pointed to Nicholas Carr’s treatise “The Big Switch” for enlightenment. Carr offers a metaphoric genealogy of Cloud Computing, mapped to, and illustrated by, a keenly patterned set of observations from one of the most important catalysts of a critical inflection point in modern history: the generation and distribution of electricity.

Carr offers an uncannily prescient perspective on the evolution and adaptation of computing by way of this electric metaphor, describing how the scale of technology, socioeconomic, and cultural advances were all directly linked to the disruptive innovation of a shift from dedicated power generation in individual factories to a metered utility of interconnected generators powering distribution grids feeding all. He predicts a similar shift from insular, centralized, private single-function computational gadgetry to globally-networked, distributed, public service-centric collaborative fabrics of information interchange.

This phenomenon will not occur overnight nor has any other paradigm shift in computing occurred overnight; bursts of disruptive innovation have a long tail of adoption. Cloud is not the product or invocation of some singular technology, but rather an operational model that describes how computing will mature.

There is no box with blinking lights that can be simply pointed to as “Cloud” and yet it is clearly more than just timesharing with Internet connectivity. As corporations seek to drive down cost and gain efficiency force-multipliers, they have ruthlessly focused on divining what is core to their businesses, and expensive IT cost-centers are squarely in the crosshairs for rigorous valuation.

To that end, Carr wrote another piece on this very topic titled “IT Doesn’t matter” in which he argued that IT was no longer a strategic differentiator due to commoditization, standardization, and cost. This was followed by “The End of Corporate Computing” wherein he suggested that IT will simply subscribe to IT services as an outsourced function. Based upon these themes, Cloud seems a natural evolutionary outcome motivated primarily by economics as companies pare down their IT investment — outsourcing what they can and optimizing what is left.

Enter Cloud Computing

The emergence of Cloud as cult-status popular culture also has its muse anchored firmly in the little machines nestled in the hands of those who might not realize that they’ve helped create the IT revolution at all: the consumer. The consumer’s shift to an always-on, many-to-many communication model with unbridled collaboration and unfettered access to resources, sharply contrasts with traditional IT — constrained, siloed, well-demarcated, communication-restricted, and infrastructure-heavy.

Regardless of any value judgment on the fate of Man, we are evolving to a society dedicated to convenience, where we are not tied to the machine, but rather the machine is tied to us, and always on. Your applications and data are always there, consumed according to business and pricing models that are based upon what you use while the magic serving it up remains transparent.

This is Cloud in a nutshell; the computing equivalent to classical Greek theater’s Deus Ex Machina.

For the purpose of this paper, it is important that I point out that I refer mainly to so-called “Public Cloud” offerings; those services provided by parties external to the data owner who provides an “outsourced” service capability on behalf of the consumer.

This graceful surrender of control is the focus of my discussion. Private Clouds — those services that may operate on the corporation’s infrastructure or those of a provider but managed under said corporation’s control and policies, offers a different set of benefits and challenges but not to the degree of Public Cloud.

There are also hybrid and brokered models, but to keep focused, I shall not address these directly.

Cloud Reference Model

Cloud Reference Model

A service is generally considered to be “Cloud-based” should it meet the following characteristics and provide for:

  • The abstraction of infrastructure from the resources that deliver them
  • The democratization of those resources as an elastic pool to be consumed
  • Services-oriented, rather than infrastructure or application-centric
  • Enabling self-service, scale on-demand elasticity and dynamism
  • Employs a utility-like model of consumption and allocation

Cloud exacerbates the issues we have faced for years in the information security, assurance, and survivability spaces and introduces new challenges associated with extreme levels of abstraction, mobility, scale, dynamism and multi-tenancy. It is important that one contemplate the “big picture” of how Cloud impacts the IT landscape and how given this “service- centric” view, certain things change whilst others remain firmly status quo.

Cloud also provides numerous challenges to the way in which computing and resources are organized, operated, governed and secured, given the focus on:

  • Automated and autonomic resource provisioning and orchestration
  • Massively interconnected and mashed-up data sources, conduits and results
  • Virtualized layers of software-driven, service-centric capability rather than infrastructure or application- specific monoliths
  • Dynamic infrastructure that is aware of and adjusts to the information, applications and services (workloads) running over it, supporting dynamism and abstraction in terms of scale, policy, agility, security and mobility

As a matter of correctness, virtualization as a form of abstraction may exist in many forms and at many layers, but it is not required for Cloud. Many Cloud services do utilize virtualization to achieve scale and I make liberal use of this assumptive case in this paper. As we grapple with the tradeoffs between convenience, collaboration, and control, we find that existing products, solutions and services are quickly being re-branded and adapted as “Cloud” to the confusion of all.keep focused, I shall not address these directly.

Modeling the Cloud

There exist numerous deployment, service delivery models and use cases for Cloud, each offering a specific balance of integrated features, extensibility/ openness and security hinged on high levels of automation for workload distribution.

Three archetypal models generally describe cloud service delivery, popularly referred to as the “SPI Model,” where “SPI” refers to Software, Platform and Infrastructure (as a service) respectively.

NIST - Visual Cloud Model

NIST – Visual Cloud Model

Using the National Institute of Standards and Technology’s (NIST) draft working definition as the basis for the model:

Software as a Service (SaaS)

The capability provided to the consumer is to use the provider’s applications running on a cloud infrastructure and accessible from various client devices through a thin client interface such as a Web browser (e.g., web-based email).

The consumer does not manage or control the underlying cloud infrastructure, network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

Platform as a Service (PaaS)

The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created applications using programming languages and tools supported by the provider (e.g., Java, Python, .Net). The consumer does not manage or control the underlying cloud infrastructure,

Infrastructure as a Service (IaaS)

The capability provided to the consumer is to rent processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly select networking components (e.g., firewalls, load balancers).

Understanding the relationship and dependencies between these models is critical. IaaS is the foundation of all Cloud services with PaaS building upon IaaS, and SaaS — in turn — building upon PaaS. We will cover this in more detail later in the document.

Peanut Butter & Jelly — Making the Perfect Cloud Sandwich

Infostructure/Metastructure/Infrastructure

Infostructure/Metastructure/Infrastructure

To understand how Cloud will affect security, visualize its functional structure in three layers:

  • The Infrastructure layer represents the traditional compute, network and storage hardware and operating systems familiar to us all. Virtualization platforms also exist at this layer and expose their capabilities northbound.
  • The Infostructure layer represents the programmatic components such as applications and service objects that produce, operate on or interact with the content, information and metadata.
  • Sitting in between Infrastructure and Infostructure is the Metastructure layer. This layer represents the underlying set of protocols and functions with layers such as DNS, BGP, and IP address management, which “glue” together and enable the applications and content at the Infostructure layer to in turn be delivered by the Infrastructure.

Certain areas of Cloud Computing’s technology underpinnings are making progress, but those things that will ultimately make Cloud the ubiquitous and transparent platform for our entire computing experience remain lacking.

Unsurprisingly, most of the deficient categories of technology or capabilities are those that need to be delivered from standards and consensus-driven action; things that have always posed challenges such as management, governance, provisioning, orchestration, automation, portability, interoperability and security. As security solutions specific to Cloud are generally slow in coming while fast innovating attackers are unconstrained by rules of engagement, it will come as no surprise that we are constantly playing catch up.

Cloud is a gradual adaptation rather than a wholesale re-tooling, and represents another cycle of investment which leaves us to consider where to invest our security dollars to most appropriately mitigate threat and vulnerability:

Typically, we react by cycling between investing in host-based controls > application controls > information controls > user controls > network controls and back again. While our security tools tend to be out of phase and less innovative than the tools of our opposition, virtualization and Cloud may act as much needed security forcing functions that get us beyond solving just the problem du jour.

The need to apply policy to workloads throughout their lifecycle, regardless of state, physical location, or infrastructure from which they are delivered, is paramount. Collapsing the atomic unit of the datacenter to the virtual machine boundary may allow for a simpler set of policy expressions that travel with the VM instance. At the same time, Cloud’s illusion of ubiquity and infinite scale means that we will not know where our data is stored, processed, or used.

Combine mobility, encryption, distributed resources with multiple providers, and a lack of open standards with economic cost pressure and even basic security capabilities seem daunting. Cloud simultaneously re-centralizes some resources while de-perimeterizing trust boundaries and distributing data. Understanding how the various layers map to traditional non-Cloud architecture is important, especially in relation to the Cloud deployment model used; there are significant trade-offs in integration, extensibility, cost, management, governance, compliance, and security.

Live by the Cloud, Die by the Cloud

Despite a tremendous amount of interest and momentum, Cloud is still very immature — pockets of innovation spread out across a long-tail of mostly-proprietary infrastructure-, platform-, and software-as-a-service offerings that do not provide for much in the way of or workload portability or interoperability.

Cloud is not limited to lower cost “server” functionality. With the fevered adoption of netbooks, virtualization, low-cost storage services, fixed/mobile convergence, the proliferation of “social networks,” and applications built to take advantage of all of this, Cloud becomes a single pane of glass for our combined computing experience. N.B., these powers are not inherently ours alone; the same upside can be used for wrongdoing.

In an attempt to whet the reader’s appetite in regards to how Cloud dramatically impacts the risk modeling, assumptions, and security postures of today, I will provide a reasonably crisp set of examples, chosen to bring pause:

Organizational and Operational Misalignment

The way in which most enterprise IT organizations are structured — in functional silos optimized to specialized, isolated functions — is diametrically opposed to the operational abstraction provided by Cloud.

The on-demand, elastic and self-service capabilities through simple interfaces and automated service layers abstract away core technology and support staff alike.

Few IT departments are prepared for what it means to apply controls, manage service levels, implement and manage security capabilities, and address compliance when the IT department is operationally irrelevant in that process. This leaves huge gaps in both identifying and managing risk, especially in outsourced models where ultimately the operational responsibility is “Cloudsourced” but the accountability is not.

The ability to apply specific security controls and measure compliance in mass-marketed Public Cloud services presents very real barriers to entry for enterprises who are heavily regulated, especially when balanced against the human capital (expertise) built-up by organizations.

Monoculture of Operating Systems, Virtualized Components, and Platforms

The standardization (de facto and de jure) on common interfaces to Cloud resources can expose uniform attack vectors that could affect one consumer, or, in the case of multi-tenant Public Cloud offerings, affect many. This is especially true in IaaS offerings where common sets of abstraction layers (such as hypervisors,) prototyped OS/application bundles (usually in the form of virtual machines) and common sets of management functions are used — and used to extend and connect the walled garden internal assets of enterprises to the public or semi-public Cloud environments of service providers operating infrastructure in proxy.

While most attack vectors target applications and information at the Infostructure layer or abuse operating systems and assorted hardware at the Infrastructure layer, the Metastructure layer is beginning to show signs of stress also. Recent attacks against key Metastructure elements such as BGP and DNS indicate that aging protocols do not fare well.

Segmentation and Isolation In Multi-tenant environments

Multi-tenancy in the Cloud (whether in the Public or Private Cloud contexts) brings new challenges to trust, privacy, resiliency and reliability model assertions by providers.  Many of these assertions are based upon the premise that that we should trust — without reliably provable models or evidence — that in the absence of relevant illustration, Cloud is simply trustworthy in all of these dimensions, despite its immaturity. Vendors claim “airtight” information, process, application, and service, but short of service level agreements, there is little to demonstrate or substantiate the claims that software-enabled Cloud Computing — however skinny the codebase may be — is any more (or less) secure than what we have today, especially with commercialized and proprietary implementations.

In multi-tenant Cloud offerings, exposures can affect millions, and placing some types of information in the care of others without effective compensating controls may erode the ROI valuation offered by Cloud in the first place, and especially so as the trust boundaries used to demarcate and segregate workloads of different consumers are provided by the same monoculture operating system and virtualization platforms described above.

Privacy of Data/Metadata, Exfiltration, and Leakage

With increased adoption of Cloud for sensitive workloads, we should expect innovative attacks against Cloud assets, providers, operators, and end users, especially around the outsourcing and storage of confidential information. The uptake is that solutions focused on encryption, at rest and in motion, will have the side effect of more and more tools (legitimate or otherwise) losing visibility into file systems, application/process execution, information and network traffic. Key management becomes remarkably relevant once again — on a massive scale.

Recent proof-of-concepts such as so-called side- channel attacks demonstrate how it is possible to determine where a specific virtual instance is likely to reside in a Public multi-tenant Cloud and allow an attacker to instantiate their own instance and cause it to be located such that it is co-resident with the target. This would potentially allow for sniffing and exfiltration of confidential data — or worse, potentially exploit vulnerabilities which would violate the sanctity of isolated workloads within the Cloud itself.

Further, given workload mobility — where the OS, applications and information are contained in an instance represented by a single atomic unit such as a virtual machine image — the potential for accidental or malicious leakage and exfiltration is real. Legal intercept, monitoring, forensics, and attack detection/incident response are heavily impacted, especially at the volume and levels of traffic envisioned by large Cloud providers, creating blind spots in ways we can’t fathom today.

Inability to Deploy Compensating or Detective Controls

The architecture of Cloud services — as abstract as they ought to be — means that in many cases the security of workloads up and down the stack are still dependent upon the underlying platform for enforcement. This is problematic inasmuch as the constructs representing compute, networking and storage resources — and security — are in many cases themselves virtualized.

Further we are faced with more stealthy and evasive malware that is able to potentially evade detection while co-opting (or rootkitting) not only software and hypervisors, but exploiting vulnerabilities in firmware and hardware such as CPU chipsets.

These sorts of attack vectors are extremely difficult to detect let alone defend against. Referring back to the monoculture issue above, a so-called blue- pilled hypervisor, uniform across tens of thousands of compute nodes providing multi-tenant Cloud services could be catastrophic. It is simply not yet feasible to provide parity in security capabilities between physical and Cloud environments; the maturity of solutions just isn’t there.

These are heady issues and should not be taken lightly when considering what workloads and services are candidates for various Cloud offerings.

What’s old is news again…

Perhaps it is worth adapting familiar attack taxonomies to Cloud.

Botnets that previously required massive malware- originated endpoint compromise in order to function can easily activate in standardized fashion, in apparently legitimate form, and in large numbers by criminals who wish to harness the organized capabilities of Bots without the effort. Simply use stolen credit cards to establish fake accounts using a provider’s Infrastructure-as-a-Service and hundreds or thousands of distributed images could be activated in a very short timeframe.

Existing security threats such as DoS/DDoS attacks, SPAM and phishing will continue to be a prime set of tools for the criminal ecosystem to leverage the distributed and well-connected Cloud as well as targeted attacks against telecommuters using both corporate and consumerized versions of Cloud services.

Consider a new take on an old problem based on ecommerce: Click-fraud. I frame this new embodiment as something called EDoS — economic denial of sustainability. Distributed Denial of Service (DDoS) attacks are blunt force trauma. The goal, regardless of motive, is to overwhelm infrastructure and remove from service a networked target by employing a distributed number of attackers. An example of DDoS is where a traditional botnet is activated to swarm/overwhelm an Internet connected website using an asynchronous attack which makes the site unavailable due to an exhaustion of resources (compute, network, or storage.)

EDoS attacks, however, are death by a thousand cuts. EDoS can also utilize distributed attack sources as well as single entities, but works by making legitimate web requests at volumes that may appear to be “normal” but are done so to drive compute, network, and storage utility billings in a cloud model abnormally high.

An example of EDoS as a variant of click fraud is where a botnet is activated to visit a website whose income results from ecommerce purchases. The requests are all legitimate but purchases are never made. The vendor has to pay the cloud provider for increased elastic use of resources but revenue is never recognized to offset them.

We have anti-DDoS capabilities today with tools that are quite mature. DDoS is generally easy to spot given huge increases in traffic. EDoS attacks are not necessarily easy to detect, because the instrumentation and business logic is not present in most applications or stacks of applications and infrastructure to provide the correlation between “requests” and “ successful transactions.” In theexample above, increased requests may look like normal activity. Many customers do not invest in this sort of integration and Cloud providers generally will not have visibility into applications that they do not own.

Ultimately the most serious Cloud concern is presented by way of the “stacked turtles” analogy: layer upon layer of complex interdependencies at the Infastructure, Metastructure and Infostructure layers, predicated upon fragile trust models framed upon nothing more than politeness. Without re-engineering these models, strengthening the notion of (id)entity management, authentication and implementing secure protocols, we run the risk of Cloud simply obfuscating the fragility of the supporting layers until something catastrophic occurs.

Combined with where and how our data is created, processed, accessed, stored, and backed up — and by whom and using whose infrastructure — Cloud yields significant concerns related to on-going security, privacy, compliance and resiliency.

Moving Forward – Critical Areas of Focus

The Cloud Security Alliance (http://www. cloudsecurityalliance.org) issued its “Guidance for Critical Areas of Focus” related to Cloud Computing Security and defined fifteen domains of concern:

  • Cloud Architecture
  • Information lifecycle management
  • Governance and Enterprise Risk Management
  • Compliance & Audit
  • General Legal
  • eDiscovery
  • Encryption and Key Management
  • Identity and Access Management
  • Storage
  • Virtualization
  • Application Security
  • Portability & Interoperability
  • Data Center Operations Management
  • Incident Response, Notification, Remediation
  • “Traditional” Security impact (business continuity, disaster recovery, physical security)

The sheer complexity of the interdependencies between the Infrastructure, Metastructure and Infostructure layers makes it almost impossible to recommend focusing on only a select subset of these items since all are relevant and important.

Nevertheless, those items in boldface most deserve initial focus just to retain existing levels of security, resilience, and compliance while information and applications are moved from the walled gardens of the private enterprise into the care of others.

Attempting to retain existing levels of security will consume the majority of Cloud transition effort.  Until we see an expansion of available solutions to bridge the gaps between “traditional” IT and dynamic infrastructure 2.0 capabilities, any company can only focus on the traditional security elements of sound design, encryption, identity, storage, virtualization and application security. Similarly, until a standardized set of methods allow well-defined interaction between the Infrastructure, Metastructure and Infostructure layers, companies will be at the mercy of industry for instrumenting, much less auditing,

Cloud elements — yet, as was already stated, the very sameness of standardization creates shared risk. As with any change of this magnitude, the potential of Cloud lies between its trade-offs. In security terms, this “big switch” surrenders visibility and control so as to gain agility and efficiency. The question is, how to achieve a net positive result?

Well-established enterprise security teams who optimize their security spend on managing risk versus purely threat, should not be surprised by Cloud. To these organizations, adapting their security programs to the challenges and opportunities provided by Cloud is business as usual. For organizations unprepared for Cloud, the maturity of security programs they can buy will quickly be outmoded.

Summary

The benefits of Cloud are many. The challenges are substantial. How we deal with these challenges and their organizational, operational, architectural, and technical impacts will fundamentally change the way in which we think about assessing and assuring the security of our assets.

Don’t Hassle the Hoff: Recent Press & Podcast Coverage & Upcoming Speaking Engagements

October 26th, 2009 1 comment

Microphone

Here is some of the recent coverage from the last month or so on topics relevant to content on my blog, presentations and speaking engagements.  No particular order or priority and I haven’t kept a good record, unfortunately.

Press/Technology & Security eZines/Website/Blog Coverage/Meaningful Links:

Podcasts/Webcasts/Video:

Recent Speaking Engagements/Confirmed to  speak at the following upcoming events:

  • Enterprise Architecture Conference, D.C.
  • Intel Security Summit 2009, Hillsboro OR
  • SecTor 2009, Toronto CA
  • EMC Innovation Forum, Franklin MA
  • NY Technology Forum, NY, NY
  • Microsoft Bluehat v9, Redmond WA
  • Office of the Comptroller & Currency, San Antonio TX
  • Intercloud Working Group, GooglePlex CA 😉
  • CSC Leading Edge Forum, VA
  • DojoCon, VA

I also forgot to thank Eric Siebert for putting together the VMware Top 20 blog list and putting me on it as well as the fact that Rational Survivability made the Datamation 2009 Top 200 Tech Blogs list.

/Hoff

The Emotion of VMotion…

September 29th, 2009 8 comments
VMotion - Here's Where We Are Today

VMotion - Here's Where We Are Today

A lot has been said about the wonders of workload VM portability.

Within the construct of virtualization, and especially VMware, an awful lot of time is spent on VM Mobility but as numerous polls and direct customer engagements have shown, the majority (50% and higher) do not use VMotion.  I talked about this in a post titled “The VM Mobility Myth:

…the capability to provide for integrated networking and virtualization coupled with governance and autonomics simply isn’t mature at this point. Most people are simply replicating existing zoned/perimertized non-virtualized network topologies in their consolidated virtualized environments and waiting for the platforms to catch up. We’re really still seeing the effects of what virtualization is doing to the classical core/distribution/access design methodology as it relates to how shackled much of this mobility is to critical components like DNS and IP addressing and layer 2 VLANs.  See Greg Ness and Lori Macvittie’s scribblings.

Furthermore, Workload distribution (Ed: today) is simply impractical for anything other than monolithic stacks because the virtualization platforms, the applications and the networks aren’t at a point where from a policy or intelligence perspective they can easily and reliably self-orchestrate.

That last point about “monolithic stacks” described what I talked about in my last post “Virtual Machines Are the Problem, Not the Solution” in which I bemoaned the bloat associated with VM’s and general purpose OS’s included within them and the fact that VMs continue to hinder the notion of being able to achieve true workload portability within the construct of how programmatically one might architect a distributed application using an SOA approach of loosely coupled services.

Combined with the VM bloat — which simply makes these “workloads” too large to practically move in real time — if one couples the annoying laws of physics and current constraints of virtualization driving the return to big, flat layer 2 network architecture — collapsing core/distribution/access designs and dissolving classical n-tier application architectures — one might argue that the proposition of VMotion really is a move backward, not forward, as it relates to true agility.

That’s a little contentious, but in discussions with customers and other Social Media venues, it’s important to think about other designs and options; the fact is that the Metastructure (as it pertains to supporting protocols/services such as DNS which are needed to support this “infrastructure 2.0”) still isn’t where it needs to be in regards to mobility and even with emerging solutions like long-distance VMotion between datacenters, we’re butting up against laws of physics (and costs of the associated bandwidth and infrastructure.)

While we do see advancements in network-driven policy stickiness with the development of elements such as distributed virtual switching, port profiles, software-based vSwitches and virtual appliances (most of which are good solutions in their own right,) this is a network-centric approach.  The policies really ought to be defined by the VM’s themselves (similar to SOA service contracts — see here) and enforced by the network, not the other way around.

Further, what isn’t talked about much is something that @joe_shonk brought up, which is that the SAN volumes/storage from which most of these virtual machines boot, upon which their data is stored and in some cases against which they are archived, don’t move, many times for the same reasons.  In many cases we’re waiting on the maturation of converged networking and advances in networked storage to deliver solutions to some of these challenges.

In the long term, the promise of mobility will be delivered by a split into three four camps which have overlapping and potentially competitive approaches depending upon who is doing the design:

  1. The quasi-realtime chunking approach of VMotion via the virtualization platform [virtualization architect,]
  2. Integration distribution and “mobility” at the application/OS layer [application architect,] or
  3. The more traditional network-based load balancing of traffic to replicated/distributed images [network architect.]
  4. Moving or redirecting pointers to large pools of storage where all the images/data(bases) live [Ed. forgot to include this from above]

Depending upon the need and capability of your application(s), virtualization/Cloud platform, and network infrastructure, you’ll likely need a mash-up of all three four.  This model really mimics the differences today in architectural approach between SaaS and IaaS models in Cloud and further suggests that folks need to take a more focused look at PaaS.

Don’t get me wrong, I think VMotion is fantastic and the options it can ultimately delivery intensely useful, but we’re hamstrung by what is really the requirement to forklift — network design, network architecture and the laws of physics.  In many cases we’re fascinated by VM Mobility, but a lot of that romanticization plays on emotion rather than utilization.

So what of it?  How do you use VM mobility today?  Do you?

/Hoff

Incomplete Thought: Virtual Machines Are the Problem, Not the Solution…

September 25th, 2009 40 comments

simplicity_complexityI’m an infrastructure guy. A couple of days ago I had a lightbulb go on.  If you’re an Apps person, you’ve likely already had your share of illumination.  I’ve just never thought about things from this perspective.  Please don’t think any less of me 😉

You can bet I’m talking above my pay grade here, but bear with my ramblings for a minute and help me work through this (Update: I’m very happy to see that Surendra Reddy [@sureddy – follow him] did just that with his excellent post – cross-posted in the comments below, here. Also, check out Simon Crosby’s (Citrix CTO) post “Wither the venerable OS“)

It comes down to this:

Virtual machines (VMs) represent the symptoms of a set of legacy problems packaged up to provide a placebo effect as an answer that in some cases we have, until lately, appeared disinclined and not technologically empowered to solve.

If I had a wish, it would be that VM’s end up being the short-term gap-filler they deserve to be and ultimately become a legacy technology so we can solve some of our real architectural issues the way they ought to be solved.

That said, please don’t get me wrong, VMs have allowed us to take the first steps toward defining, compartmentalizing, and isolating some pretty nasty problems anchored on the sins of our fathers, but they don’t do a damned thing to fix them.

VMs have certainly allowed us to (literally) “think outside the box” about how we characterize “workloads” and have enabled us to begin talking about how we make them somewhat mobile, portable, interoperable, easy to describe, inventory and in some cases more secure. Cool.

There’s still a pile of crap inside ’em.

What do I mean?

There’s a bloated, parasitic resource-gobbling cancer inside every VM.  For the most part, it’s the real reason we even have mass market virtualization today.

It’s called the operating system:

Virtualization

If we didn’t have resource-inefficient operating systems, handicapped applications that were incestuously hooked to them, and tons of legacy networking stuff to deal with that unholy affinity, imagine the fun we could have.  Imagine how agile and flexible we could become.

But wait, isn’t server virtualization the answer to that?

Not really.  Server virtualization like that pictured in the diagram above is just the first stake we’re going to drive into the heart of the frankenmonster that is the OS.  The OS is like Cousin Eddie and his RV.

The approach we’ve taken today is that the VMM/Hypervisor abstracts the hardware from the OS.  The applications are still stuck on top of operating systems that don’t provide much in the way of any benefit given the emergence of development frameworks/languages such as J2EE, PHP, Ruby, .NET, etc. that were built around the notions of decoupled, distributed and mashable application “fabrics.”

Every ship travels with an anchor, in the case of the VM it’s the OS.

Imagine if these applications didn’t have to worry about the resource-hogging, control-freak, I/O limiting, protected mode schizophrenia and de-privileged ring spoofing of hypervisors associated with trying not conflict with or offend the OS’s sacred relationship with the hardware beneath it.

Imagine if these application constructs were instead distributed programmatically, could intercommunicate using secure protocols and didn’t have to deal with legacy problems. Imagine if the VMM/Hypervisor really was there to enable scale, isolation, security, and management.  We’d be getting rid of an entire layer.

If that crap in the middle of the sandwich makes for inefficiency, insecurity and added cost in virtualized enterprises, imagine what it does at the Infrastructure as a Service (IaaS) layer in Cloud deployments where VMs — in whatever form — are the basis for the operational models.  We have these fat packaged VMs with OS overhead and attack surfaces that really don’t need to be there.

For example, most of the pre-packaged AMIs found on AWS are bloated general purpose operating systems with some hardening applied (if at all) but there’s just all that code… sitting there…doing nothing except taking up storage, memory and compute resources.

Why do we need this?   Why don’t we at at least see more of a push towards JEOS (Just Enough OS) in the meantime?

I think most virtualization vendors today who are moving their virtualization offerings to adapt to Cloud, are asking themselves the same questions and answering them by realizing that the real win in the long term — once enterprises are done with consolidation and virtualization and hit the next “enterprise application modernization” cycle — will be  to develop and engineer applications directly around platforms which obviate the OS.

So these virtualization players are  making acquisitions to prepare them for this next wave — the real emergence of Platform as a Service (PaaS.)

Some like Microsoft with Azure are simply starting there.  Even SaaS vendors have gone down-stack and provided PaaS offerings to further allow for connectivity, integration and security in the place they think it belongs.

In the case of VMware and their acquisition of SpringSource, that piece of bloat in the middle can be seen as simply going away; whatever you call it, it’s about disintermediating the OS completely and it seems to me that the entire notion of vApps addresses this very thing.  I’m sure there are a ton of other offerings that I simply didn’t get before that are going to make me go “AHA!” now.

I’m not sure organizationally or operationally that most enterprises can get their arms around what it means to not have that OS layer in the middle in the short term, but this new platform-oriented Cloud is really interesting.  It makes those folks who may have made the conversion from server-hugger to VM-hugger and think they were done adapting, quite uncomfortable.

It makes me uncomfortable…and giddy.

All the things I know and understand about how things at the Infrastructure layer s interacts with applications and workloads at the Infostructure layer will drastically change.  The security models will change.  The solutions will change.  Even the notion of vMotion — moving VM’s around — will change.  In fact, in this model, vMotion isn’t really relevant.

Admittedly, I’ve had to call into question over the last few days just how relevant the notion of “Infrastructure 2.0” is within this model — at least how it’s described today.

Cloud v1.0 with all it’s froth and hype is going to be nothing compared to Cloud 2.0 — the revenge of SOA, web services, BPM, enterprise architecture and the developer.  Luckily for the sake of us infrastructure folks we still have time to catch up and see the light as the VMM buys us visibility and a management plane.  However, the protocols and models for how applications interact with the network are sure going to change and accelerate due to Cloud — at least they should.

Just look at how developments such as XMPP and LISP are going to play in a PaaS-centric world…

Like I said, it’s an incomplete thought and I’m not enlightened enough to frame a better discussion in written form, but I can’t wait until the next Infrastructure 2.0 Working Group to bring this up.

I have an appreciation for such a bigger piece of the conversation now.  I just need to get more edumacated.

My head ahsplodes.

Any of this crap make sense to you?

/Hoff