Archive

Archive for the ‘Cloud Computing’ Category

What’s The Problem With Cloud Security? There’s Too Much Of It…

October 17th, 2010 3 comments

Here’s the biggest challenge I see in Cloud deployment as the topic of security inevitably occurs in conversation:

There’s too much of it.

Huh?

More specifically, much like my points regarding networking in highly-virtualized multi-tenant environments — it’s everywhere — we’ve got the same problem with security.  Security is shot-gunned across the cloud landscape in a haphazard fashion…and the buck (pun intended) most definitely does not stop here.

The reality is that if you’re using IaaS, the lines of demarcation for the responsibility surrounding security may in one take seemed blurred but are in fact extremely well-delineated, and that’s the problem.  I’ve seen quite a few validated design documents outlining how to deploy “secure multi-tentant virtualized environments.”  One of them is 800 pages long.

Check out the diagram below.

I quickly mocked up an IaaS stack wherein you have the Cloud provider supplying, operating, managing and securing the underlying cloud hardware and software layers whilst the applications and information (contained within VM boundaries) are maintained by the consumer of these services.  The list of controls isn’t complete, but it gives you a rough idea of what gets focused on. Do you see some interesting overlaps?  How about gaps?

This is the issue; each one of those layers has security controls in it.  There is lots of duplication and there is lots of opportunity for things to be obscured or simply not accounted for at each layer.

Each of these layers and functional solutions is generally managed by different groups of people.  Each of them is generally managed by different methods and mechanisms.  In the case of IaaS, none of the controls at the hardware and software layers generally intercommunicate and given the abstraction provided as part of the service offering, all those security functions are made invisible to the things running in the VMs.

A practical issue is that the FW, VPN, IPS and LB functions at the hardware layer are completely separate from the FW, VPN, IPS and LB functions at the software layer which are in turn completely separate from the FW, VPN, IPS and LB functions which might be built into the VM’s (or virtual appliances) which sit stop them.

The security in the hardware is isolated from the security in the software which is isolated from the security in the workload.  You can, today, quite literally install the same capabilities up and down the stack without ever meeting in the middle.

That’s not only wasteful in terms of resources but incredibly prone to error in both construction, management and implementation (since at the core it’s all software, and software has defects.)

Keep in mind that at the provider level the majority of these security controls are focused on protecting the infrastructure, NOT the stuff atop it.  By design, these systems are blind to the workloads running atop them (which are often encrypted both at rest and in transit.)  In many cases this is why a provider may not be able to detect an “attack” beyond data such as flows/traffic.

To make things more interesting, in some cases the layer responsible for all that abstraction is now the most significant layer involved in securing the system as a whole and the fundamental security elements associated with the trust model we rely upon.

The hypervisor is an enormous liability; there’s no defense in depth when your primary security controls are provided by the (*ahem*) operating system provider.  How does one provide a compensating control when visibility/transparency [detective] are limited by design and there’s no easy way to provide preventative controls aside from the hooks the thing you’re trying to secure grants access to?

“Trust me” ain’t an appropriate answer.  We need better visibility and capabilities to robustly address this issue.  Unfortunately, there’s no standard for security ecosystem interoperability from a management, provisioning, orchestration or monitoring perspective even within a single stack layer.  There certainly isn’t across them.

In the case of Cloud providers who use commodity hardware with big, flat networks with little or no context for anything other than the flows/IP mappings running over them (thus the hardware layer is portrayed as truly commoditized,) how much better/worse do you think the overall security posture is of a consumer’s workload running atop this stack.  No, that’s not a rhetorical question.  I think the case could be argued either side of the line in the sand given the points I’ve made above.

This is the big suck.  Cloud security suffers from the exact same siloed security telemetry problems as legacy operational models…except now it does it at scale. This is why I’ve always made the case that one can’t “secure the Cloud” — at least not holistically — given this lego brick problem.   Everyone wants to make the claim that they’re technology is that which will be the first to solve this problem.  It ain’t going to happen. Not with the IaaS (or even PaaS) model, it won’t.

However, there is a big opportunity to move forward here.  How?  I’ll give you a hint.  It exists toward the left side of the diagram.

/Hoff

Related articles
Enhanced by Zemanta
Categories: Cloud Computing, Cloud Security, Cloud Security Alliance, CloudAudit, Compliance, Virtualization, Virtualization Security Tags: , , , , , ,

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?

Related articles by Zemanta
Enhanced by Zemanta
Categories: Cloud Computing Tags:

VMware vCloud Director Security Hardening Guide Is Available

September 23rd, 2010 No comments
Image representing VMware as depicted in Crunc...
Image via CrunchBase

I’ll be adding a material review of this document here later, but I wanted to make sure folks know this resource exists.

It’s titled the “VMware vCloud Director Security Hardening Guide”

You can download it here (PDF)

The Table of Contents appears reasonably robust…content is TBD

/Hoff

Related articles by Zemanta
Enhanced by Zemanta
Categories: Cloud Computing, Cloud Security, Virtualization, Virtualization Security, VMware Tags: , , , ,

An Ode to Oracle’s Cloud…

September 22nd, 2010 2 comments
SAN FRANCISCO - SEPTEMBER 24: Oracle CEO Larr...
Image by Getty Images via @daylife

Try not to be
such an Oracle Hater,
Build a big, honkin’ Cloud:
Exalogic &  -data

It’s fluffy & shiny
it’s new & fantastic
It scales like butta,
cos it’s so damned elastic

It may cost you millions,
but it’ll save you a buck.
Is it really a cloud?
Larry don’t give a f*ck.

It’ll castigate partners
and alienate friends
it’s got unbreakable linux
and it also self-mends

The kernel is magic,
OVM’s where it’s at
Some might disagree,
especially RedHat

Infiniband, ten Gig,
many Sun-powered cores
It’s got enough cycles
for HPC chores

The issue some have,
is Larry’s evil plot
It’s really quite simple,
a mortgage and yacht.

It’s like “War of the Roses,”
‘tween Big O, Salesforce
Gets ugly in the  Valley
when partners divorce

Some CEO’s chide Larry,
and others, they scoff.
Some fire back with venom
like Mark Benioff

It’s a False Cloud, a Non-Cloud
“We’re like A-W-S”
this marketing plan
is one freakin’ mess

Just one file to patch it,
it’s IT on demand.
It’s a mainframe with JBoss,
can’t you understand!?

It’ll take all you can give it,
all you can muster,
It scales from one
to an eight headed cluster

At the end of the day,
from morning to nox
take comfort that Cloud
now comes in a box.

—

P.S. You may be interested in other little ditties I have scratched into existence, here.

Related articles by Zemanta

Enhanced by Zemanta
Categories: Cloud Computing, Poetry Tags: , , , , ,

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

September 20th, 2010 1 comment
Recent Speaking Engagements/Confirmed to  speak at the following upcoming events:

There are a ton of venues I haven’t added here because they are directly related to customer visits that may not wish to be disclosed.  You can see the prior list of speaking engagements listed here.

[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.  It also allows folks to plan meet-ups]

/Hoff

Categories: Cloud Computing, Cloud Security, Cloud Security Alliance, CloudAudit, Conferences, Presentations, Security Conferences, Speaking Engagements Tags:

VMware’s (New) vShield: The (Almost) Bottom Line

September 1st, 2010 2 comments

After my initial post yesterday (How To Wield the New vShield (Edge, App & Endpoint) remarking on the general sessions I sat through on vShield, I thought I’d add some additional color given my hands-on experience in the labs today.

I will reserve more extensive technical analysis of vShield Edge and App (I didn’t get to play with endpoint as there is not a lab for that) once I spend some additional quality-time with the products as they emerge.

Because people always desire for me to pop out of the cake quickly, here you go:

You should walk away from this post understanding that I think the approach holds promise within the scope of what VMware is trying to deliver. I think it can and will offer customers choice and flexibility in their security architecture and I think it addresses some serious segmentation, security and compliance gaps. It is a dramatically impactful set of solutions that is disruptive to the security and networking ecosystem. It should drive some interesting change. The proof, as they say, will be in the vPudding.

Let me first say that from VMware’s perspective I think vShield “2.0” (which logically represents many technologies and adjusted roadmaps both old and new) is clearly an important and integral part of both vSphere and vCloud Director’s future implementation strategies. It’s clear that VMware took a good, hard look at their security solution strategy and made some important and strategically-differentiated investments in this regard.

All things told, I think it’s a very good strategy for them and ultimately their customers. However, there will be some very interesting side-effects from these new features.

vShield Edge is as disruptive to the networking space (it provides L3+ networking, VPN, DHCP and NAT capabilities at the vDC edge) as it is to the security arena. When coupled with vShield App (and ultimately endpoint) you can expect VMware’s aggressive activity in retooling their offers here to cause further hastened organic development, investment, and consolidation via M&A in the security space as other vendors seek to play and complement the reabsorption of critical security capabilities back into the platform itself.

Now all of the goodness that this renewed security strategy brings also has some warts. I’ll get into some of them as I gain more hands-on experience and get some questions answered, but here’s the Cliff Note version with THREE really important points:

  1. The vShield suite is the more refined/retooled/repaired approach toward what VMware promised in delivery three years ago when I wrote about it in 2007 (Opening VMM/HyperVisors to Third Parties via API’s – Goodness or the Apocalypse?) and later in 2008 (VMware’s VMsafe: The Good, the Bad, and the Bubbly…“) and from 2009, lest we forget The Cart Before the Virtual Horse: VMware’s vShield/Zones vs. VMsafe API’s…
    _
    Specifically, as the virtualization platform has matured, so has the Company’s realization that security is something they are going to have to take seriously and productize themselves as depending upon an ecosystem wasn’t working — mostly because doing so meant that the ecosystem had to uproot entire product roadmaps to deliver solutions and it was a game of “supply vs. demand chicken.”
    _
    However, much of this new capability isn’t fully baked yet, especially from the perspective of integration and usability and even feature set capabilities such as IPv6 support. Endpoint is basically the more streamlined application of APIs and libraries for anti-malware offloading so as to relieve a third party ISV from having to write fastpath drivers that sit in the kernel/VMM and disrupt their roadmaps. vShield App is the Zones solution polished to provide inter-VM firewalling capabilities.
    _
    Edge is really the new piece here and represents a new function to represent vDC perimeterized security capabilities.Many of these features are billed — quite openly — as relieving a customer from needing to use/deploy physical networking or security products. In fact, in some cases even virtual networking products such as the Cisco Nexus 1000v are not usable/supportable. This is and example of a reasonably closed, software-driven world of Cloud where the underlying infrastructure below the hypervisor doesn’t matter…until it does.
    _
  2. vShield Edge and App are, in the way they are currently configured and managed, very complex and unwieldy and the performance, resiliency and scale described in some of the sessions is yet unproven and in some cases represents serious architectural deficiencies at first blush. There are some nasty single points of failure in the engineering (as described) and it’s unclear how many reference architectures for large enterprise and service provider scale Cloud use have really been thought through given some of these issues.
    _
    As an example, only being able to instantiate a single (but required) vShield App virtual appliance per ESX host brings into focus serious scale, security architecture and resilience issues. Being able to deploy numerous Edge appliances brings into focus manageability and policy sprawl concerns.There are so many knobs and levers leveraged across the stack that it’s going to be very difficult in large environments to reconcile policy spread over the three (I only interacted with two) components and that says nothing about then integrating/interoperating with third party vSwitches, physical switches, virtual and physical security appliances. If you think it was challenging before, you ain’t seen nothin’ yet.
    _
  3. The current deployment methodology reignites the battle that started to rage when security teams lost visibility into the security and networking layers and the virtual administrators controlled the infrastructure from the pNIC up. This takes the gap-filler virtual security solutions from small third parties such as Altor which played nicely with vCenter but allowed the security teams to manage policy and blows that model up. Now, security enforcement is a commodity feature delivered via the virtualization platform but requires too complex a set of knowledge and expertise of the underlying virtualization platform to be rendered effective by role-driven security teams.

While I’ll cover items #1 and #2 in a follow-on post, here’s what VMware can do in the short term to remedy what I think is a huges issue going forward with item #3, usability and management.

Specifically, in the same way vCloud Director sits above vCenter and abstracts away much of the “unnecessary internals” to present a simplified service catalog of resources/services to a consumer, VMware needs to provide a dedicated security administrator’s “portal” or management plane which unites the creation, management and deployment of policy from a SECURITY perspective of the various disparate functions offered by vShield App, Edge and Endpoint. [ED: This looks as though this might be what vShield Manager will address. There were no labs covering this and no session I saw gave any details on this offering (UI or API)]

If you expect a security administrator to have the in-depth knowledge of how to administer the entire (complex) virtualization platform in order to manage security, this model will break and cause tremendous friction. A security administrator shouldn’t have access to vCenter directly or even the vCloud Director interfaces.

Since much of the capability for automation and configuration is made available via API, the notion of building a purposed security interface to do so shouldn’t be that big of a deal. Some people might say that VMware should focus on building API capabilities and allow the ecosystem to fill the void with solutions that take advantage of the interfaces. The problem is that this strategy has not produced solutions that have enjoyed traction today and it’s quite clear that VMware is interested in controlling their own destiny in terms of Edge and App while allowing the rest of the world to play with Endpoint.

I’m sure I’m missing things and that given the exposure I’ve had (without any in-depth briefings) there may be material issues associated with where the products are given their early status, but I think it important to get these thoughts out of my head so I can chart their accuracy and it gives me a good reference point to direct the product managers to when they want to scalp me for heresy.

There’s an enormous amount of detail that I want to/can get into. The last time I did that it ended up in a 150 slide presentation I delivered at Black Hat…

Allow me to reiterate what I said in the beginning:

You should walk away from this post understanding that I think the approach holds promised within the scope of what VMware is trying to deliver. I think it can and will offer customers choice and flexibility in their security architecture and I think it addresses some serious segmentation, security and compliance gaps. It is a dramatically impactful set of solutions that is disruptive to the security and networking ecosystem. It should drive some interesting change. The proof, as they say, will be in the vPudding.

…and we all love vPudding.

/Hoff

Related articles by Zemanta
Enhanced by Zemanta
Categories: Cloud Computing, Cloud Security, Virtualization, Virtualization Security, VMware Tags: , , , , , , , , ,

How To Wield the New vShield (Edge, App & Endpoint)

August 30th, 2010 4 comments
Image representing VMware as depicted in Crunc...
Image via CrunchBase

Today at VMworld I spent my day in and out of sessions focused on the security of virtualized and cloud environments.

Many of these security sessions hinged on the release of VMware‘s new and improved suite of vShield product offerings which can be simply summarized by a deceptively simple set of descriptions:

  • vShield Edge – Think perimeter firewalling for the virtual datacenter (L3 and above)
  • vShield App – Think internal segmentation and zoning (L2)
  • vShield Endpoint – Anti-malware service offload

The promised capabilities of these solutions offer quite a well-rounded set of capabilities from a network and security perspective but there are many interesting things to consider as one looks at the melding of the VMsafe API, vShield Zones and the nepotistic relationship enjoyed between the vCloud (nee’ VMware vCloud Director) and vSphere platforms.

There are a series of capabilities emerging which seek to solve many of the constraints associated with multi-tenancy and scale challenges of heavily virtualized enterprise and service provider virtual data center environments.  However, many of the issues associated with those I raised in the Four Horsemen of the Virtualization Security Apocalypse still stand (performance, resilience/scale, management and cost) — especially since many of these features are delivered in the form of a virtual appliance.

Many of the issues I raise above (and asked again today in session) don’t have satisfactory answers which just shows you how immature we still are in our solution portfolios.

I’ll be diving deeper into each of the components as the week proceeds (and more details around vCloud Director are made available,) but one thing is certain — there’s a very interesting amplification of the existing tug-of-war  between the security capabilities/functionality provided by the virtualization/cloud platform providers and the network/security ecosystem trying to find relevance and alignment with them.

There is going to be a wringing out of the last few smaller virtualization/Cloud security players who have not yet been consolidated via M&A or attrition (Altor Networks, Catbird, HyTrust, Reflex, etc) as the three technologies above either further highlight an identified gap or demonstrate irrelevance in the face of capabilities “built-in” (even if you have to pay for them) by VMware themselves.

Further, the uneasy tension between  the classical physical networking vendors and the virtualization/cloud platform providers is going to come to a boil, especially as it comes to configuration management, compliance, and reporting as the differentiators between simple integration at the API level of control and data plane capabilities and things like virtual firewalling (and AV, and overlay VPNs and policy zoning) begins to commoditize.

As I’ve mentioned before, it’s not where the network *is* in a virtualized environment, it’s where it *isn’t* — the definition of where the network starts and stops is getting more and more abstracted.   This in turn drives the same conversation as it relates to security.  How we’re going to define, provision, orchestrate, and govern these virtual data centers concerns me greatly as there are so many touchpoints.

Hopefully this starts to get a little more clear as more and more of the infrastructure (virtual and physical) become manageable via API such that ultimately you won’t care WHAT tool is used to manage networking/security or even HOW other than the fact that policy can be defined consistently and implemented/instantiated via API across all levels transparently, regardless of what’s powering the moving parts.

This goes back to the discussions (video) I had with Simon Crosby on who should own security in virtualized environments and why (blog).

Now all this near term confusion and mess isn’t necessarily a bad thing because it’s going to force further investment, innovation and focus on problem solving that’s simply been stalled in the absence of both technology readiness, customer appetite and compliance alignment.

More later this week. [Ed: You can find the follow-on to this post here “VMware’s (New) vShield: The (Almost) Bottom Line]

/Hoff

Related articles by Zemanta

Categories: Cloud Computing, Cloud Security, Compliance, Virtualization, Virtualization Security, VMware Tags: , , , , , , , , , ,

Why Is NASA Re-Inventing IT vs. Putting Men On the Moon? Simple.

August 26th, 2010 4 comments
The NASA insignia.
Image via Wikipedia

I was struck with a sense of disappointment as I read Bob Wardspan’s (Smoothspan) blog today “NASA Fiddles While Rome Is Burning.”  So as Bob was rubbed the wrong way by Alex Howard’s post (below,) so too was I by Bob’s perspective.  All’s fair in love and space, I suppose.

In what amounts to a scathing indictment of new areas of innovation and research, he laments the passing of the glory day’s of NASA’s race to space, bemoans the lack of focus on planet-hopping, and chastises the organization for what he suggests is their dabbling in spaces they don’t belong:

Now along comes today’s NASA, trying to get a little PR glory from IT technology others are working on.  Yeah, we get to hear Vinton Cerf talk about the prospects for building an Internet in space.  Nobody will be there to try to connect their iGadget to it, because NASA can barely get there anymore, but we’re going to talk it up.  We get Lewis Shepherd telling us, “Government has the ability to recognize long time lines, and then make long term investment decisions on funding of basic science.”  Yeah, we can see that based on NASA’s bright future, Lewis.

Bob’s upset about NASA (and our Nation’s lost focus on space exploration.  So am I.  However, he’s barking up the wrong constellation.  Sure, the diversity of different technologies mentioned in Alex Howard’s blog on the NASA IT Summit are wide and far, but NASA has always been about innovating in areas well beyond the engineering of solid rocket boosters…

Let’s look at Cloud Computing — one of those things that you wouldn’t necessarily equate with NASA’s focus.  Now you may disagree with their choices, but the fact that they’re making them is what is important to me.  They are, in many cases, driving discussion, innovation and development.  It’s not everyone’s cup of tea, but then again, neither is a Saturn V.

NASA didn’t choose to cut space exploration and instead divert all available resources and monies toward improving the efficiency and access to computing resources and reducing their cost to researchers.  This was set in motion years ago and was compounded by the global economic meltdown.

The very reasons the CIO’s (Chief Information Officers) — the people responsible for IT-related mission support — are working diligently on new computing platforms like Nebula is in many ways a direct response to the very cause of this space travel deficit — budget cuts.  They, like everyone else, are trying to do more with less, quicker, better and cheaper.

The timing is right, the technology is here and it’s an appropriate response.  What would you have NASA IT do, Bob? Go on strike until a Saturn V blasts off?  The privatization of space exploration will breed all new sets of public-private partnership integration and information collaboration challenges.  These new platforms will enable that new step forward when it comes.

The fact that the IT divisions of NASA (whose job it is to deliver services just like this) are innovating simply shines a light on the fact that for their needs, the IT industry is simply too slow.  NASA must deal with enormous amounts of data, transitive use, hugely collaborative environments across multiple organizations, agencies, research organizations and countries.

Regardless of how you express your disappointment with NASA’s charter and budget, it’s unfortunate that Bob chose to suggest that this is about “…trying to get a little PR glory from IT technology others are working on” since in many cases NASA has led the charge and made advancements and innovated where others are just starting.  Have you met Linda Cureton or Chris Kemp from NASA?  They’re not exactly glory hunters.  They are conscientious, smart, dedicated and driven public servants, far from the picture you paint.

In my view, NASA IT (which is conflated as simply “NASA”) is doing what they should — making excellent use of taxpayer dollars and their budget to deliver services which ultimately support new efforts as well as the very classically-themed remaining missions they are chartered to deliver:

  • To improve life here,
  • To extend life to there,
  • To find life beyond.

I think if you look at the missions that the efforts NASA IT is working on, it certainly maps to those objectives.

To Bob’s last point:

What’s with these guys?  Where’s my flying car, dammit!

I find it odd (and insulting) that some seek to blame those whose job is mission support — and doing a great job of it — as if they’re the cause of the downfall of space exploration.  Like the rest of us, they’re doing the best they can…fly a mile in their shoes.

Better yet, take a deeper look at to what they’re doing and how it maps to supporting the very things you wish were NASA’s longer term focus — because at the end of the day when the global economy recovers, we’ll certainly be looking to go where no man and his computing platform has gone before.

/Hoff

Related articles by Zemanta
Enhanced by Zemanta
Categories: Cloud Computing, Cloud Security, Current Affairs, General Rants & Raves Tags: , , , , , , ,

Dear Verizon Business: I Have Some Questions About Your PCI-Compliant Cloud…

August 24th, 2010 5 comments

You’ll forgive my impertinence, but the last time I saw a similar claim of a PCI compliant Cloud offering, it turned out rather anti-climatically for RackSpace/Mosso, so I just want to make sure I understand what is really being said.  I may be mixing things up in asking my questions, so hopefully someone can shed some light.

This press release announces that:

“…Verizon’s On-Demand Cloud Computing Solution First to Achieve PCI Compliance” and the company’s cloud computing solution called Computing as a Service (CaaS) which is “…delivered from Verizon cloud centers in the U.S. and Europe, is the first cloud-based solution to successfully complete the Payment Card Industry Data Security Standard (PCI DSS) audit for storing, processing and transmitting credit card information.”

It’s unclear to me (at least) what’s considered in scope and what level/type of PCI certification we’re talking about here since it doesn’t appear that the underlying offering itself is merchant or transactional in nature, but rather Verizon is operating as a service provider that stores, processes, and transmits cardholder data on behalf of another entity.

Here’s what the article says about what Verizon undertook for DSS validation:

To become PCI DSS-validated, Verizon CaaS underwent a comprehensive third-party examination of its policies, procedures and technical systems, as well as an on-site assessment and systemwide vulnerability scan.

I’m interested in the underlying mechanicals of the CaaS offering.  Specifically, it would appear that the platform – compute, network, and storage — are virtualized.  What is unclear is if the [physical] resources allocated to a customer are dedicated or shared (multi-tenant,) regardless of virtualization.

According to this article in The Register (dated 2009,) the infrastructure is composed like this:

The CaaS offering from Verizon takes x64 server from Hewlett-Packard and slaps VMware’s ESX Server hypervisor and Red Hat Enterprise Linux instances atop it, allowing customers to set up and manage virtualized RHEL partitions and their applications. Based on the customer portal screen shots, the CaaS service also supports Microsoft’s Windows Server 2003 operating system.

Some details emerge from the Verizon website that describes the environment more:

Every virtual farm comes securely bundled with a virtual load balancer, a virtual firewall, and defined network space. Once the farm is designed, built, and named – all in a matter of minutes through the CaaS Customer Management Portal – you can then choose whether you want to manage the servers in-house or have us manage them for you.

If the customer chooses to manage the “servers…in-house (sic)” is the customer’s network, staff and practices now in-scope as part of Verizon’s CaaS validation? Where does the line start/stop?

I’m very interested in the virtual load balancer (Zeus ZXTM perhaps?) and the virtual firewall (vShield? Altor? Reflex? VMsafe-API enabled Virtual Appliance?)  What about other controls (preventitive or detective such as IDS, IPS, AV, etc.)

The reason for my interest is how, if these resources are indeed shared, they are partitioned/configured and kept isolated especially in light of the fact that:

Customers have the flexibility to connect to their CaaS environment through our global IP backbone or by leveraging the Verizon Private IP network (our Layer 3 MPLS VPN) for secure communication with mission critical and back office systems.

It’s clear that Verizon has no dominion over what’s contained in the VM’s atop the hypervisor, but what about the network to which these virtualized compute resources are connected?

So for me, all this all comes down to scope. I’m trying to figure out what is actually included in this certification, what components in the stack were audited and how.  It’s not clear I’m going to get answers, but I thought I’d ask any way.

Oh, by the way, transparency and auditability would be swell for an environment such as this. How about CloudAudit? We even have a PCI DSS CompliancePack 😉

Question for my QSA peeps: Are service providers required to also adhere to sections like 6.6 (WAF/Binary analysis) of their offerings even if they are not acting as a merchant?

/Hoff

Related articles by Zemanta

Enhanced by Zemanta
Categories: A6, Cloud Computing, Cloud Security, Cloud Security Alliance, CloudAudit, PCI Tags: , , , , , , , , , , , ,

Hoff’s 5 Rules Of Cloud Security…

August 21st, 2010 5 comments

Mike Dahn pinged me via Twitter with an interesting and challenging question:

I took this as a challenge in 5 minutes or less to articulate this in succinct, bulleted form.  I timed it. 4 minutes & 48 seconds. Loaded with snark and Hoffacino-fueled dogma.

Here goes:

  1. Get an Amazon Web Services [or Rackspace or Terremark vCloud Express, etc.] account, instantiate a couple of instances as though you were deploying a web-based application with sensitive information that requires resilience, security, survivability and monitoring. If you have never done this and you’re in security spouting off about the insecurities of Cloud, STFU and don’t proceed to step 2 until you do.  These offerings put much of the burden on you to understand what needs to be done to secure Cloud-based services (OS, Apps, Data) which is why I focus on it. It’s also accessible and available to everyone.
    –
  2. Take some time to be able to intelligently understand that as abstracted as much of Cloud is in terms of  the lack of exposed operational moving parts, you still need to grok architecture holistically in order to be able to secure it — and the things that matter most within it.  Building survivable systems, deploying securable (and as secure as you can make it) code, focusing on protecting information and ensuring you understand system design and The Three R’s (Resistance, Recognition, Recovery) is pretty darned important.  That means you have to understand how the Cloud provider actually works so when they don’t you’ll already have planned around that…
    –
  3. Employ a well-developed risk assessment/management framework and perform threat modeling. See OCTAVE, STRIDE/DREAD, FAIR.  Understanding whether an application or datum is OK to move to “the Cloud” isn’t nuanced. It’s a simple application of basic, straightforward and prudent risk management. If you’re not doing that now, Cloud is the least of your problems. As I’ve said in the past “if your security sucks now, you’ll be pleasantly surprised by the lack of change when you move to Cloud.”
    –
  4. Proceed to the Cloud Security Alliance website and download the guidance. Read it. Join one or more of the working groups and participate to make Cloud Security better in any way you believe you have the capacity to do so.  If you just crow about how “more secure” the Cloud is or how “horribly insecure by definition” it is, it’s clear you’ve not done steps 1-3. Skip 1-3, go to #5 and then return to #1.
    –
  5. Use common sense.  There ain’t no patch for stupid.  Most of us inherently understand that this is a marathon and not a sprint. If you take steps 1-4 seriously you’re going to be able to logically have discussions and make decisions about what deployment models and providers suit your needs. Not everything will move to the Cloud (public, private or otherwise) but a lot of it can and should. Being able to layout a reasonable timeline is what moves the needle. Being an idealog on either side of the tarpit does nobody any good.  Arguing is for Twitter, doing is for people who matter.

Cloud is only rocket science if you’re NASA and using the Cloud for rocket science.  Else, for the rest of us, it’s an awesome platform upon which we leverage various opportunities to improve the way in which we think about and implement the practices and technology needed to secure the things that matter most to us.

/Hoff

(Yeah, I know. Not particularly novel or complex, right? Nope. That’s the point. Just like  “How to Kick Ass in Information Security — Hoff’s Spritually-Enlightened Top Ten Guide to Health, Wealth and Happiness“)

Related articles by Zemanta

Enhanced by Zemanta
Categories: Cloud Computing, Cloud Security, Cloud Security Alliance, CloudAudit, Compliance, DevOps Tags: , , ,