Rational Survivability

I had to chuckle and then sob when I saw this posting from Reuven Cohen on the Cloud Computing Interoperability Forum (CCIF) regarding the ViMTruder “virtual machine trojan:”

Sergio Castro has released a functional, open source Virtual Machine Trojan called ViMTruder.

I’ve held off for a few days before posting this news. I wasn’t sure if helping spread the news would do more harm then good but, several other blogs have picked up the story, so why not.

So what is a Virtual Machine Trojan? According to Castro virtual machine trojans are seemingly benign virtual machine you download from the Internet contains a trojan. The objective of the trojan is to remotely take control
of the machine for nefarious purposes: steal information, send spam, conduct click fraud, stage denial of service attacks within a botnet, etc.

ViMtruder is written in Python and consists of a client which is installed within a virtual machine, and a control server, which sits in a host on the Internet. The virtual machine, running Linux, is configured to automatically run the VMT client in the background upon boot up. The VMT tries periodically to contact the control server through the Internet using port 80 outbound. Once the control server links with the VMT, you can send it Nmap commands to scan the target LAN where the VMT is connected.

The types of attacks a VMT can execute are different than a normal trojan. The VMT does not have access to the host machine; rather, it has access to the local network. Therefore, a VMT can be programmed to do the following:

1. Sniff traffic in the local network
2. Actively scan the local network to detect machines, ports and services
3. Do a vulnerability scan to detect exploitable machines in the local network
4. Execute exploits  in the local network
5. Brute force attacks against services such as ftp and ssh
6. Launch DoS attacks within the local network, or against external hosts
7. And of course, send spam and conduct click fraud

My first thought is imagine something like this embedded into an EC2 AMI and the potential damage it would cause.

Direct Link:
http://code.google.com/p/vimtruder/
—
–
Reuven
CCIF Instigator

You can read my response at the bottom of the thread in the link at the top of the page.  I am awe struck at the moment.

Keep in mind that frothy hyperbole misrepresenting security risks as unique and “damaging”  as illustrated above are being made by people invited to advise the U.S. government on how to secure Cloud Computing.  Joy.

/Hoff

My buddy George Hulme wrote a great piece on the efforts of the Cloud Security Alliance and the first draft of our “Security Guidance for Critical Areas of Focus in Cloud Computing.”

I had one important point of departure from his assessment that I feel needs discussion wherein George said:

While there are a number of minor issues I’d question in this paper, these are all fixable challenges — and will be strengthened in time, I’m certain. It’s that, despite its comprehensiveness, what is not in this paper that disappointed.

There is no overarching vision in this paper. There is no call to action for the IT community: whether it be the builders, providers, or consumers of cloud services. There’s no inspiration to motivate broad community involvement. This is no small oversight.

Selling the importance of doing cloud computing right from the beginning is the most “critical area of focus” of all.

I wanted to clear up my disagreement with George on those few points he dinged us on, as I feel that we covered all of these things at both our kick-off session at RSA and while we certainly could have “sold” the idea more within the first release of the guidance, page 5 (the introduction) stated the following:

We are continuously bombarded with news of information technology’s next big thing, a disruptive trend in computing with far reaching implications.  Many of these trends are no more than a marketer’s dream – hype sells technology and it becomes difficult to separate real change from an incremental upgrade.  Cloud Computing is having its moment in the sun, as the concept of utilizing computing as an on-demand subscription creates operating and economic efficiencies. Some deride the cloud as nothing new and in many respects they are correct.  Henry Ford’s Model T was not a new invention, but the revolution that ensued cannot be denied.  We believe Cloud Computing to be a very important trend that in many ways is beginning to fulfill the early promise of the Internet and will create unanticipated change in business with its ubiquitous adoption.  Phase one of the Internet was connectivity, with Cloud Computing we are leveraging that connectivity to optimize the utility of computing.

While we do see Cloud Computing as being a major change coming to every business, as information security practitioners, we recognize that there are verities which must not change: good governance, managing risks and common sense.  Cloud Computing is an unstoppable force and we encourage security practitioners to lead and help accelerate its secure adoption aided by common sense, rather than standing on the sidelines and letting the business move forward without us.

Some evangelists of cloud computing encourage us to focus on the model as a black box, the seamless presentation of your information on demand.  Pay no attention to how it works: resources are dynamically allocated, loads are balanced in real time and data is archived automatically.   Our message to the security practitioner is that in these early days of cloud computing, you must look under the hood of your cloud providers and you must do so using the broadest precepts of your profession in order to properly assure that the service engagements meet and exceed the security requirements of your organization.

The Cloud Security Alliance is a grassroots effort to facilitate the mission to create and apply best practices to secure cloud computing.  Incorporated as a not-for-profit organization, our efforts will seek to provide a voice for security practitioners.  However, recognizing that a secure cloud is a shared responsibility, we will be inclusive of all organizations and points of view to fulfill this mission.

What follows is our initial report, outlining areas of concern and guidance for organizations adopting cloud computing.  The intention is to provide security practitioners with a comprehensive roadmap for being proactive in developing positive and secure relationships with cloud providers.  Much of this guidance is also quite relevant to the cloud provider to improve the quality and security of their service offerings.   As with any initial foray, there will certainly be guidance that we could improve upon.  We will quite likely modify the number of domains and change the focus of some areas of concern.  We seek your help to improve this guidance to make version 2.0 of this document an even better asset to the security practitioner and cloud provider.

We will be kicking off numerous online activities and in-person regional events to share our findings and connect with experts to increase our knowledge base.  Here is how you can get involved:

• Visit our website to find out how you can help: www.cloudsecurityalliance.org
• Join our LinkedIn group to collaborate with us: www.linkedin.com/groups?gid=1864210

In my opinion, the introduction conveyed our vision, the call to action, and inspired community involvement.  I’m slightly biased, however.

It could certainly be improved, but I felt that while George did a great job with the rest of his article, he missed the point that we did address these important issues.

Our outreach is currently limited by people’s bandwidth, but as things settle down after RSA and InfoSec UK, you can expect to see much better organizational efforts and messaging around what we are doing and how you can get involved.

Did you come away from reading the paper without a sense of vision, call to action, inspiration or how to get involved?   Please do let me know.

/Hoff

See the diagram to the right?  It is my masterful “Hamster Sine Wave Of Pain.”  The HSWOP demonstrates where and how, over time, we manifest our investment in security controls and approaches.

We waffle between securing the host to the user to information to applications and then to the network and back again.  It’s how it’s always been and how it always will be.  It makes for some timing problems, however.

The gap in approach shows up when we overlay disruptive innovation and technology such as virtualization and Cloud Computing on top of this security response curve and we realize we’re out of synch.  When we’re busy being information-centric from a security perspective and a disruptive networking event occurs…oops.

The inspiration for this post came from a complaint on Twitter this morning from my buddy Rich Mogull in which he lamented that too many people are equating “HIPS (host-based intrusion prevention)” with “Cloud Security.”

The reality is that depending upon the *aaS model you’re referring to, HIPS *is* Cloud Security.  Specifically, in IaaS/PaaS environments when you can’t plumb in virtual network appliances (or physical for that matter) then you’re basically left with whatever the provider gives you at the “network” layer (which is usually not much) or you focus on host-based controls. HIPS is as good as any other solution at that point.

In SaaS environments, you’re dependent upon whatever the provider engineers into their network platforms and the applications themselves.

To generalize, when you’re talking about having security as a visible operational capability presented to the user versus being bundled as part of the service, besides application security and the odd ACL, HIPS/HIDS/AV/Hardening Scripts/etc… is Cloud Security for most folks at the moment.

Ultimately, this Cloud Security gap at the IaaS/PaaS level will close over time as it is beginning to do so technologically with virtualization.

You’ll have more options as the mechanisms for integrating network-based security solutions become available.  At issue here is the fact that security capabilities caused by inflexible policies based on IP addresses, are out of step with connectivity advances and how Cloud services are composed, provisioned, orchestrated and managed.  Hence the host/guest-based security focus.  It’s simply the easiest and most prudent thing to do given our options at the moment.

We’ve seen the hints of advancement with what VMware is doing with VMsafe and their API’s.  As the notion of VDCOS evolves,  I maintain we’ll see this sort of capability appear with IaaS/PaaS vendors in the Cloud, too, and it will expand beyond things like firewalls and IPS’s — we’ll see load balancers and other network-based capabilities emerge through creative plumbing.  We’ll see what other virtualization platforms bring to the table in this scope as introspection capabilities mature (if they do at all…)

We ought to see a bunch of innovative solutions that will emerge slowly as the “internal” virtualization and unified computing capabilities make their way “outward” and become the same platforms powering more mainstream Cloud offerings.  This might take a while.  Perhaps a very long while.

Until then, enjoy your agents.

Same as it ever was…same as it ever was.

/Hoff

GigaOm’s Structure ’09 “Putting Cloud Computing to Work” conference sounded really good. I thought I’d submit a response to their CFP with a perspective on Cloud Security that I’m pretty sure would be unique.

I was excited when I saw a response from GigaOm’s Surj Patel titled: GigaOM’s Structure 09: Speaker Application Status

I was slightly less excited when I read the contents of the email which you can see by clicking on the image below to expand it:

I loved this.  “We ask you to consider engaging our audience not by speaking but via sponsorship.”

So while my talk doesn’t satisfy their requirements, cash does.  Yup, that’s adding value alright.  I don’t mind not meeting their speaking requirements, but slapping me in the face with this kiss-off is insulting.

Bite me.

/Hoff

Mary Jo Foley asked the question in her blog titled: ‘Private cloud’ = just another buzzword for on-premise datacenter?

What’s really funny is that she’s not really asking.  She’s already made her mind up:

Whether or not they admit it publicly (or just express their misgivings relatively privately), Microsoft officials know the “private cloud” is just the newest way of talking about an on-premise datacenter. Sure, it’s not exactly the same mainframe-centric datacenter IT admins may have found themselves outfitting a few years ago. But, in a nutshell, server + virtualization technology + integrated security/management/billing  = private cloud.

Microsoft’s “official” description of the distinction between private and public clouds basically says as much. From a press release the company issued this morning:

The private cloud: “By employing techniques like virtualization, automated management, and utility-billing models, IT managers can evolve the internal datacenter into a ‘private cloud’ that offers many of the performance, scalability, and cost-saving benefits associated with public clouds. Microsoft provides the foundation for private clouds with infrastructure solutions to match a range of customer sizes, needs and geographies.

The public cloud: “Cloud computing is expanding the traditional web-hosting model to a point where enterprises are able to off-load commodity applications to third-party service providers (hosters) and, in the near future, the Microsoft Azure Services Platform. Using Microsoft infrastructure software and Web-based applications, the public cloud allows companies to move applications between private and public clouds.”

Firstly, Microsoft defines their notion of Public and Private Clouds based upon the limits of their product offerings.  In their terms, Private Clouds = Hyper-V, Public Clouds = Azure.  Never the two shall meet. So using these definitions, sure, Private Clouds are just “on-premise datacenters.”  She ought to know.  She wrote about it here and I responded in a post titled “Incomplete Thought: Looking At An “Open & Interoperable Cloud” Through Azure-Colored Glasses”

Private Clouds aren’t just virtualized datacenters with chargeback/billing.

As I’ve said here many, many times, this sort of definition is short-sighted, inaccurate and limiting:

Private Clouds: Even A Blind Squirrel Finds A Nut Once In A While
The Vagaries Of Cloudcabulary: Why Public, Private, Internal & External Definitions Don’t Work…
Internal v. External/Private v. Public/On-Premise v. Off- Premise: It’s all Cloud But How You Get There Is Important.
Private Clouds: Your Definition Sucks
Mixing Metaphors: Private Clouds Aren’t Defined By Their Location…

Can we stop butchering this term now, please?

So no, Private Cloud is NOT just a euphemism for on-premise datacenters.

/Hoff

Here are some interesting nuggets that I find compelling:

Trend Micro is buying Third Brigade – One of my favorite Canadian companies is getting hitched. Third Brigade has always been measured and understated in their approach to Virtualiation Security and their entry into Cloud and their solutions tend to deliver good value.  Their “acquisition” of OSSEC was also smart given the nature of guest-oriented controls for Cloud environments.  This is a good move for Trend as it gets them a solution suite they didn’t have previously.

Panda gets cute and cuddly with AV in the Cloud -Take a thin-client, add “Cloud” based scanning and you get a revised model for AV.  I like this idea for a couple of reasons, the most interesting of which relates to the notion of what the aggregated telemetry from all the client interactions will mean to more real-time threat mitigation.  I wrote about this sort of thing a while ago with one of my favorites being a post titled “Thinning the Herd and Chlorinating the Malware Gene Pool”  I’ll be very interested to see how functionally the service compares with traditional AV in terms of efficacy and what sort of performance one might expect.

…and so does McAfee – This appears to be simply a SaaS offering that replaces typical on-premise gateway solutions unlike Panda’s which includes a thin-client endpoint client.  Expect everyone and their mother (and their VC’s mother) to provide this in the short term.

IBM re-enters the networking market via Brocade deal – IBM is extending its existing OEM arrangement with Brocade to include the Ethernet switching and routing products from the Foundry acquisition.   Huh.  I thought they’d already done that with Juniper?  Oh, they’re going to do that, too.  Response to Cisco ya think?  IBM is good at hedging bets.

Forrester Backs Private Clouds – Will Others Follow Suit? – This is both gratifying and personally annoying. Firstly, Forrester is NOT the only analyst company backing Private Clouds.  Gartner is and has (although their definition seems to have morphed) well before Forrester and some of us have been proponents of Private Clouds before they became pop culture. Ugh.

Google Fires Back at VMware about Virtualization for Cloud Computing – Well, of course they do.  Google doesn’t utilize virtualization — they deploy millions of servers instead. It’s a “diabolically-opposed” approach.  Welcome to religious debates 101, please take a seat…or stand.

DMTF announces the Open Cloud Standards Incubator – I don’t know what to think about this.  It sounds like a good idea and has some solid backers.  I noticed that the charter is focused on IaaS/PaaS but not SaaS.  Telling.

Randy Bias says the Open Cloud Is Coming – I reviewed Randy’s original draft and he’s done a good job refining his points although I don’t agree with all of them.  His last statement is a good summary “Ignore the naysayers.  Customers want choice and they will have it.  Choice is driven by open standards, cheap resources, and easy ’self-service’ access.”  Yep, customers want choice, but choice isn’t driven by “open standards.” It’s driven by “open-enough standards” that customers feel meet their needs.

More later.

/Hoff

I’ve said it before and I’ll say it again: SaaS is not the definition of Cloud Computing.  It’s one element of Cloud Computing.  In the same vein, when you mention “Cloud Security,” it means more than the security features integrated by a SaaS provider to protect their stack.  Oh, it’s an interesting discussion point, but Google and SalesForce.com are not the end-all, be-all of “Cloud Security.”  Unfortunately, they are the face of Cloud Security these days.  Read on as I explain why.

Almost every webinar, presentation and panel I’ve seen in the last six months that promises to discuss “Security Services in the Cloud” usually ends up actually focused on three things:

1. Managed security services (on-premises or off-premises) of traditional security capabilities/solutions, re-branded as Cloud offerings and
2. Managed services utilizing a SaaS model for one or more security functions, re-branded as Cloud offerings
3. A hybrid model involving both managed services of devices/policies and one or more hosted applications (nee SaaS) re-branded as Cloud offerings

Let’s take a look at what these use cases really mean within the context of Cloud Computing.

Managed security services (on-premises or off-premises) of traditional security capabilities/solutions:
Basically, these services are the same old managed services you’ve seen forever with the word “Cloud” stuck somewhere in the description for marketing purposes.
An example is a provider has NOCs/SOCs and manages security infrastructure on your behalf.  This equipment and software can be located on your premises or externally
and because it’s Internet connected, it’s now magically Cloud based.  These services have nothing to do with protecting Cloud-based services, but rather they suggest that
they *use* the Cloud to deliver service.

Managed security services utilizing a SaaS model for one or more security functions:
Any managed services provider who uses a SaaS stack to process information on behalf of their customers via the Internet is re-branding to say they are Cloud based.
The same is true from a security perspective.  Anti-spam, anti-virus, DDoS, URL filtering services, vulnerability management,  etc. are all game. From Google’s Postini
to OpenDNS’ services to Qualys’ vulnerability management, we’re seeing the rampant use of Cloud in these marketing efforts.  Further, vendors who offer
some sort of Cloud-based service that has integrated security functionality (as it should) claim to offer “Cloud Security.”  In all of these cases, scaling is traditionally
done at the software layer and is generally hidden from the customer and how the service scales isn’t usually based on Cloud Computing capabilities at all.

The Hybrid Model
Some providers offer a combination of managed on/off-premise security devices used in conjunction with SaaS offerings to broaden the solution.  There are any number
of MSSP’s who have an Internet-based portal (via VPN) and an on- or off-premise set of capabilities involving appliances and SaaS to deliver some combination of service.
This model can extend to fixed or mobile computing services where things like Clean Pipes are provided.

The challenge is trying to understand how, where and why the word “Cloud” ought to be applied to these services.  Now I want to be clear that there’s nothing particularly “wrong” with branding these services as “Cloud” except for the following:

If you look at the definition of Cloud (at least mine,) it involves the following:

• Abstraction of Infrastructure
• Resource Democratization
• Services Oriented
• Elasticity/Dynamism
• Utility Model Of Consumption & Allocation

In the case of security solutions which are generally based on static allocation of resources, static policies, application controls built into an application and in many cases dedicated physical appliances (or fixed-utilization shared virtualized instances,) customers can’t log into a control panel and spin up another firewall, IDP or WAF on-demand. In some cases, they don’t even know these resources exist.  Some might argue that is a good thing.  I’m not debating the efficacy of these solutions, but rather how they are put forward.

Also important is that customers don’t get to pay for only the resources used for the same reasons.

So whilst many services/solutions may virtualize the network stack or even policy, the abstraction of infrastructure from resources and resource democratization get a little fuzzy definitionally.  That’s a minor point, really.

What’s really interesting is the two items I highlighted in boldfaced: Elasticity and the utility model of consumption and allocation.  Traditional security capabilities such as firewalls, IDP, A/V, etc. are generally implemented on physical appliances/networking equipment which from a provisioning and orchestration perspective don’t really subscribe to either the notion of self-administered elasticity or the utility model of consumption/allocation whereby the customer is charged only for what they use.

To me, if your Cloud Security solution does not provide for all of these definitional elements of Cloud, it’s intellectually dishonest (the definition of marketing? 😉 to call it “Cloud Security.”

This is important because “security” is being thought of from the perspective of SaaS or IaaS and each of these models have divergent provisioning, orchestration and management methods that don’t really jive with multi-tenant Cloud models for security.*  As it turns out, the most visible and vocal providers of application services are really the ones peddling “secure cloud” to serve their own messaging needs and so in SaaS stacks, the bundled security integrated into the application is usually a no-cost item.  In other models, it *is* the service that one pays for.

I’ve talked about this quite a bit in my Frogs presentation in which I demonstrate how the lower down the stack provider stops (from SaaS down to Iaas,) the more security a customer is generally still responsible for — or that of a provider.  Much of this is due to the lack of scale in security technology today and static policies with a network disconnected from context and state and unaware of the dynamism of the layers above it:

Without invoking the grumpy-magic-anachronism-damage +4 spell, I am compelled to mention the following.

Back in 1995 I architected one of the world’s first global managed security services using a combination of multi-layered VPNs from across the globe to a set of four regional Internet gateways through which all Internet traffic was tunneled. We manually scaled each set of dedicated clustered firewalls for each customer based on load.  We didn’t even have centralized management for all these firewalls at the time (Provider-1 and VSX weren’t born yet — we helped in their birth) so everything was pretty much a manual process.  This was better than managing CPE devices and allowed us to add features/functions centrally…you know, like the “Cloud.” 😉

Not much has changed with managed security services and their models today.  While they have better centralized management, virtualized policy and even container-based virtual security functions, but we’re still stuck with mostly manually provisioning and a complete disconnect of the security policies from the network and virtualization layers.  Scale is not dynamic.  Neither is pricing.

At the end of the day, from a managed security perspective, be wary of claims of “Cloud Security” and what it means to you.

/Hoff

*This is one of the compelling elements of converged/unified compute fabrics; the ability to tie all the elements together and focus on consistent policy enforcement up and down the stack but for managed security providers, this will take years to make its way into their networks as the revenue models and cost structures for most MSSP’s are simply not aligned with virtualization platform providers.  Perhaps we’ll see a bigger uptake of OSS virtualization platforms in order to deliver these converged services.

Two years ago VMware announced their intention to develop and release a set of capabilities which would provide a more resilient and secure hypervisor while also extending a set of API’s to a limited number of vetted third-party security ISV’s.

These APIs were designed to regain visibility and add capabilities such as virtual introspection across compute, network and storage realms in order to solve some really difficult issues that I’ve spoken about extensively in my Four Horsemen of the Virtualization Security Apocalypse talks.

The reality is that VMsafe required two very important things to happen before it could see the light of day:

1. A new version of VMware platform with a substantial overhaul of virtual networking capabilities and
2. New versions of every ISV’s products who wish to take advantage of the API’s

Both of these things take substantial time and engineering effort and make for some very challenging integration, testing and product management challenges for both VMware and the security ISVs in the ecosystem.  I’ve lived this life on both sides of the fence and it ain’t pretty folks.

Here’s the cool thing, although it’s arrived out of order, the integration of technology from the Blue Lane acquisition (with the IPS and patch proxy functions removed) adds the capability to provide for logical zoning and policy/firewalling enforcement and yields a very interesting side effect..

For all those vendors struggling with having to retool their virtual appliances and write kernel-level drivers for fastpath functionality in order to work with VMsafe API’s as well as their own slowpath drivers in the VA, vShield ultimately offers a solution that instead depends upon VMware’s dvFilters to redirect certain protocols to a virtual appliance based upon zones.

I saw a demo of how RSA has taken their DLP solution (from the Tablus acquisition) and by using  vShield/Zones to provide for the filtering and agreeing on a comms. path between the VMM and the RSA virtual appliance, they can integrate their solution without having to re-write their code or  develop fast path drivers!

Now, there’s a trade-off in extensibility because the capabilities of what are exposed are limited since VMware effectively controls that in this scenario; you might expect only fixed protocol redirection or some other prescribed limitation.

Regardless of how this plays out functionally, both ISV’s and customers now have an expanded choice when it comes to deciding how they might integrate security controls:

1. Use VMsafe API’s but wait for a vendor to re-write their code, integrate and test and get the best balance of performance, extensibility and customization of the solution or
2. Use vShield/Zones with shorter development and test cycles without having to modify their code.  This offers potentially less optimized performance, less extensibility but again potentially less attack surface since API’s are not exposed and there is no third party code in the VMM.

vShield/Zones will help the security ISV’s integrate their solutions more easily and hopefully quicker and will give customers the CHOICE of the trade-off between security, performance and functionality in terms of security solution integration.  It also means that the number and choice of ISVs in the ecosystem should expand.

Further, it may mean easier integration of security controls in Cloud scenarios as VMware extends vCloud.

I eagerly await more information regarding how vShield and the VMware/RSA proof-of-concept develops.  I hope that the PoC generates interest and accelerates the delivery of security solutions from ISVs who may not have previously been able to participate in the VMsafe API program.

/Hoff

Hopefully by now you’ve heard that the Cloud Security Alliance team released out initial efforts aimed at identifying key elements and practices in securing Cloud Computing.  Check the link below to download it.

There was a ton of work done in an extremely short timeframe.  There’s still a ton of work to be done. The 83 pages or so represent a good first-pass.  It’s not perfect and we didn’t aim for it to be so.  You’ll find things you may disagree with or think need clarification, please let us know.

As we break down these sections further, we really want people to get involved with subject matter expertise in each of the domains.  We want to take what we have an make it more valuable, more specific and more actionable.

We hope you’ll join us in this effort.

Cloud Security Alliance identifies key practices for secure adoption of Cloud Computing

San Francisco, CA, April 22, 2009 – The information security industry is taking on the task of providing guidance to enable secure Cloud Computing with today’s formal launch of the Cloud Security Alliance. The Cloud Security Alliance’s inaugural whitepaper, “Security Guidance for Critical Areas of Focus in Cloud Computing”, is now available on the Cloud Security Alliance website, and a presentation of the findings will be made at the RSA conference today at 2:45pm at Orange Room 312 in the Moscone Center.

The Cloud Security Alliance is a not-for-profit organization with a mission to promote the use of best practices for providing security assurance within Cloud Computing, and to provide education on the uses of Cloud Computing to help secure all other forms of computing. The founding thought leaders behind the formation of the Cloud Security Alliance are leading security practitioners from a range of private and public organizations and leading security companies PGP Corporation, Qualys, Inc. and Zscaler, Inc.

“Aggressive adoption of cloud computing is clearly underway. The convergence of inexpensive computing, pervasive mobility and virtualization technologies has created a platform for more agile and cost effective business applications and IT infrastructure,” said Jerry Archer, Chief Information Security Officer at Intuit, Inc. and part of the CISO leadership at the Cloud Security Alliance, “The cloud is forcing thoughtful adaptation of certain security controls, while creating an even greater demand for best practices in security program governance.”

The whitepaper being presented at RSA, “Security Guidance for Critical Areas of Focus in Cloud Computing”, outlines key issues and provides advice for both Cloud Computing customers and providers within 15 strategic domains. According to Alliance co-founders Nils Puhlmann and Jim Reavis, the several months of collaboration was worth the effort, “We would like to thank the many contributors to this initial effort. The great diversity of services offered via cloud computing requires careful analysis to understand the risks and mitigation appropriate in each case. At the same time, we see enormous potential for the cloud model to eventually simplify many difficult security problems. This initial deliverable is just the beginning of our efforts, and we would like to extend an open invitation to industry experts to help us create additional best practices for practitioners and the industry.”

The Cloud Security Alliance is building its guidance by engaging with experts from a variety of backgrounds to reflect the many organizational participants that will be involved in cloud computing decisions. Joshua Davis, Director of Information Security & Compliance at Qualcomm and a member of the Cloud Security Alliance, sees this collaboration as timely. “The information risk management factors one must consider when leveraging cloud computing, especially legal and regulatory compliance issues, represent unchartered territory for many enterprises. The Cloud Security Alliance is bringing together information security and legal experts, along with many other domains of knowledge, to see these issues from every stakeholder’s point of view.”

The guidance whitepaper is available online at www.cloudsecurityalliance.org/guidance. Open discussion is welcome at our LinkedIn group and on Twitter at #cloudsa.

About Cloud Security Alliance

The Cloud Security Alliance is a not-for-profit organization with a mission to promote the use of best practices for providing security assurance within Cloud Computing, and to provide education on the uses of Cloud Computing to help secure all other forms of computing. The Cloud Security Alliance is led by industry practitioners and supported by founding charter companies PGP Corporation, Qualys, Inc. and Zscaler, Inc. For further information, the Cloud Security Alliance website is www.cloudsecurityalliance.org

/Hoff

It finally dawned on me that if I have a few hundred to a thousand people sitting in front of me at one of my presentations, I should take advantage of that collective intelligence to perform a little selfish information gathering.

I’ve had an opinion for quite some time that the rampant squawking and generalizations regarding hyper-mobility suggesting VM sprawl and uncontrolled instance spawning was nothing more than FUD given where we are today with the technology and platforms that supposedly enable it.

We constantly hear how organizations big and small are suffering (or will) from the evils of virtualization by way of VM’s and information turning up everywhere, putting your data and assets at risk. It gets worse with the multi-tenancy issues surrounding moving to “The Cloud,” they say.

So in a couple of my panels at RSA, I asked for some sanity and fact checking.

Informally, 95% of those in attendance at the two RSA panels I engaged run VMware in production. I asked that in cases OTHER than failure, how many of those in the audience take advantage of VM mobility (such as VMotion) or some other technological capability to provide autonomic mobility of VM’s in their enterprises.

About 5 people (in crowds of 100+ and 500+ respectively) raised their hands.  Given that I asked this question the second time in front of a huge audience at RSA sitting next to the CTO’s of Citrix and VMware, I’m sure they were pretty surprised by the answer, too.

The reality is that in these environments — even extremely complex and large examples — there simply isn’t that much mobility and customers are more interested in resilience than they are agility in terms of what this feature brings. That’s a really interesting and important point.

The reason for this is pretty simple; 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 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.

Don’t get me wrong, autonomics and business process/governance feedback loops are most definitely coming — and are absolutely required for Cloud — but they’re not here and not used much today.  This is the hard stuff we’ve skipped over because it’s really freaking hard.  Don’t believe me?  See how long folks like HP have been at their “Adaptive Enterprise” solutions.  That’s why unified fabrics make so much sense; you can get your arms around automating much, much more with a consistent set of enforceable policies and SLAs.

So the next time someone brings up this epidemic of runaway VM’s, ask them to kindly provide you with empirical data demonstrating such as just because it *might* happen, doesn’t mean it *does* happen.

So much of the purported risks associated with virtualization and Cloud are things based on what might happen. There’s a huge difference between possibility and probability. One of them is used for prudent analysis and risk assessment, the other for selling you something. I’ll let you figure out which is which.

The management, visibility and security tools and capabilities are arriving on our doorsteps. When and if this sort of problem actually becomes a problem, it’s quite likely we’ll have a good set of solutions to deal with it.

Until then, challenge these assertions and fears, and ask for proof not pandering to panic.