Rational Survivability

IMPORTANT: Moving My Blog & RSS Feed

This is generally a messy thing to do and I'm sure it's going to screw some things up for folks, but I'm moving my blog.  I've decided that after 3 years at TypePad, I need some flexibility to control my own destiny and manage my brand a little better.

This will be my last post here, so please adjust your landing accordingly to now point to:

www.rationalsurvivability.com/blog

If you're using an RSS reader for raw RSS feeds, please adjust your feed to:

feed://www.rationalsurvivability.com/blog/?feed=rss2

If you're using Feedburner, I'm going to adjust the feeds tonight. Hopefully it will work:

Feed Title: Rational Survivability
Feed Address: http://feeds2.feedburner.com/rationalsurvivability/blog

I'm sure this is going to cause pandaemonium, but c'est la vie.

Thanks for your patience.

/Hoff

IMPORTANT REMINDER: My Blog and RSS Feed Have Moved To http://www.rationalsurvivability.com/blog

This will be my last post here, so please adjust your landing accordingly to now point to:

www.rationalsurvivability.com/blog

If you're using an RSS reader for raw RSS feeds, please adjust your feed to:

feed://www.rationalsurvivability.com/blog/?feed=rss2

If you're using Feedburner, I'm going to adjust the feeds tonight. Hopefully it will work:

Feed Title: Rational Survivability
Feed Address: http://feeds2.feedburner.com/rationalsurvivability/blog

Thanks for your patience.

/Hoff

IMPORTANT REMINDER: My Blog and RSS Feed Have Moved

This is generally a messy thing to do and I'm sure it's going to screw some things up for folks, but I'm moving my blog.  I've decided that after 3 years at TypePad, I need some flexibility to control my own destiny and manage my brand a little better.

This will be my last post here, so please adjust your landing accordingly to now point to:

www.rationalsurvivability.com/blog

If you're using an RSS reader for raw RSS feeds, please adjust your feed to:

feed://www.rationalsurvivability.com/blog/?feed=rss2

If you're using Feedburner, I'm going to adjust the feeds tonight. Hopefully it will work:

Feed Title: Rational Survivability
Feed Address: http://feeds2.feedburner.com/rationalsurvivability/blog

Thanks for your patience.

/Hoff

BeanSec! Wednesday, March 18, 2009 - 6PM to ?

Yo!  BeanSec! is once again upon us.  Wednesday, March 18, 2009.

Middlesex Lounge: 315 Massachusetts Ave, Cambridge 02139. 

BeanSec! is an informal meetup of information security professionals, researchers and academics in the Greater Boston area that meets the third Wednesday of each month.

I say again, BeanSec! is hosted the third Wednesday of every month.  Add it to your calendar.

Come get your grub on and have a drink.  Lots of good people show up.  Really.

Unlike other meetings, you will not be expected to pay dues, “join up”, present a zero-day exploit, or defend your dissertation to attend.

Don't worry about being "late" because most people just show up when they can. 6:30 is a good time to aim for. We'll try and save you a seat. There is a plenty of parking around or take the T.

The food selection is basically high-end finger-food appetizers and the drinks are really good; an attentive staff and eclectic clientèle make the joint fun for people watching. Zach and I will generally annoy you into participating somehow, even if it's just fetching napkins. ;)

This week's BeanSec refreshments sponsored by: IOActive

We often retire across the street to Asgard for more substantive fare after the event and then to Tosci's for coffee...

A little administrivia note: After 2 years, we're finally getting the beansec.org domain, blog, email, etc. setup...expect completion in about a week.

See you there!

/Hoff

How To Be PCI Compliant in the Cloud...

I kicked off a bit of a dust storm some months ago when I wrote a tongue-in-cheek post titled "Please Help Me: I Need a QSA to Assess PCI/DSS Compliance In the Cloud."  It may have been a little contrived, but it asked some really important questions and started some really good conversations on my blog and elsewhere.

At SourceBoston I sat in on Mike Dahn's presentation titled "Cloud Compliance and Privacy" in which he did an excellent job outlining the many issues surrounding PCI and Compliance and it's relevance to Cloud Computing.  

Shortly thereafter, I was speaking to Geva Perry and James Urquhart on their "Overcast" podcast and the topic of PCI and Cloud came up. 

Geva asked me if after my rant on PCI and Cloud if what I was saying was that one could never be PCI compliant in the Cloud.  I basically answered that one could be PCI compliant in the Cloud depending upon the services used/offered by the provider and what sort of data you trafficked in.

Specifically, Geva made reference to the latest announcement by Rackspace regarding their Mosso Cloud offering and PCI compliance in which they tout that by using Mosso, a customer can be "PCI Compliant"  Since I hadn't seen the specifics of the offering, I deferred my commentary but here's what I found:

Cloud Sites, Mosso|The Rackspace Cloud’s Flagship offering, is officially the very first cloud hosting solution to enable an Internet merchant to pass PCI Compliance scans for both McAfee’s PCI scans and McAfee Secure Site scans. 

This achievement occurred just after Computer World published an article where some CIO’s shared their concern that Cloud Computing is still limited to “things that don’t require full levels of security.”  This landmark breakthrough may be the beginning of an answer to those fears, as Mosso leads Cloud Hosting towards a solid future of trust and reliability.

Mosso's blog featured an example of a customer -- The Spreadsheet Store -- who allegedly attained PCI compliance by using Mosso's offering. Pay very close attention to the bits below:

“We are making the Cloud business-ready.  Online merchants, like The Spreadsheet Store can now benefit from the scalability of the Cloud without compromising the security of online transactions,” says Emil Sayegh, General Manager of Mosso|The Rackspace Cloud.  “We are thrilled to have worked with The Spreadsheet Store to prepare the Cloud for their online transactions.”

...

The Spreadsheet Store set up their site using aspdotnetstorefront, “Which is, in our opinion, the best shopping cart solution on the market today,” says Murphy.  “It also happens to be fully compatible with Mosso.”  Using Authorize.Net, a secure payment gateway, to handle credit card transaction, The Spreadsheet Store does not store any credit card information on the servers.  Murphy and team use MaxMind for fraud prevention, Cardinal Commerce for MasterCard Secure Code and Verified by Visa, McAfee for PCI and daily vulnerability scans, and Thawte for SSL certification.

So after all of those lofty words relating to "...preparing the Cloud for...online transactions," what you can decipher is that Mosso doesn't seem to provide services to The Spreadsheet Store which are actually in scope for PCI in the first place!*

The Spreadsheet store redirects that functionality to a third party card processor!  

So what this really means is if you utilize a Cloud based offering and don't traffic in data that is within PCI scope and instead re-direct/use someone else's service to process and store credit card data, then it's much easier to become PCI compliant.  Um, duh. 

The goofiest bit here is that in Mosso's own "PCI How-To" (warning: PDF) primer, they basically establish that you cannot be PCI compliant by using them if you traffic in credit card information:

Cloud Sites is not currently designed for the storage or archival of credit card information.  In order to build a PCI compliant e-commerce solution, Cloud Sites needs to be paired up with a payment gateway partner.

Doh!

I actually wrote quite a detailed breakdown of this announcement for this post yesterday, but I awoke to find my buddy Craig Balding had already done a stellar job of that (curses, timezones!)  I'll refer you to his post on the matter, but here's the gem in all of this.  Craig summed it up perfectly:

The fact that Mosso is seeking ways to help their customers off-load as much PCI compliance requirements to other 3rd parties is fine - it makes business sense for them and their merchant customers.  It’s their positioning of the effort as a “landmark breakthrough” and that they are somehow pioneers which leads to generalisations rooted in misunderstandings that is the problem.
Next time you hear someone say ‘Cloud Provider X is PCI compliant’, ask the golden PCI question: is their Cloud receiving, processing, storing or transmitting Credit Card data (as defined by the PCI DSS)?  If they say ‘No’, you’ll know what that really means…marketecture.

There's some nifty marketing for you, eh?

--

* Except for the fact that the web servers housed at Mosso must undergo regularly-scheduled vulnerability scans -- which Mosso doesn't do, either.

On the Overcast Podcast with Geva Perry and James Urquhart

Geva and James were kind (foolish?) enough to invite me onto their Overcast podcast today:

In this podcast we talk to Christopher Hoff, renowned information security expert, and especially security in the context of virtualization and cloud computing. Chris is the author of the Rational Survivability blog, and can be followed as @Beaker on Twitter.
Show Notes:

• Chris talks about some of the myths and misconceptions about security in the cloud. He addresses the claim that Cloud Providers Are Better At Securing Your Data Than You Are and the benefits and shortcomings of security in the cloud.
• We talk about Chris's Taxonomy of Cloud Computing (excuse me, model of cloud computing)
• Chris goes through some specific challenges and solutions for PCI-compliance in the cloud
• Chris examines some of the security issues associated with multi-tenant architecture and virtualization

Check it out here.

/Hoff 

More On Clouds & Botnets: MeatClouds, CloudFlux, LeapFrog, EDoS and More!

After my "Frogs" talk at Source Boston yesterday, Adam O'Donnell and I chatted about one of my chuckle slides I threw up in the presentation in which I give some new names to some (perhaps not new) attack/threat scenarios which involve Cloud Computing:

• MeatCloud - Essentially abusing Amazon's Mechanical Turk and using it to produce the Cloud version of a sweat shop; exploiting the ignorant for fun and profit to perform menial illegal muling tasks on your behalf...think SETI meets underage garment workers...
• CloudFlux - Take a mess of stolen credit cards, open up  a slew of Amazon AWS accounts using them, build/scale to thousands of instances overnight, launch carpet bomb attack (you choose,) tear it down/have it torn down, and move your botnet elsewhere...rinse, lather, repeat...
• LeapFrog - As we move to hybrid private/public clouds and load balancing/cloudbursting across multiple cloud providers, we'll interconnect Clouds via VPNs to the "trusted internals" of your Cloudbase... Attackers will thank us by abusing these tunnels to penetrate your assets through the, uh, back door.
• vMotion Poison Potion - When VMware's vCloud makes its appearance and we start to allow vMotion across datacenters and across Clouds (in the clear?,) imagine the fun we'll have as we see attacks against vMotion protocols and VM state...  
• EDoS - Economic Denial of Sustainability - Covered previously here. 

Adam mentioned that I might have considered that Botnets were a great example of a Cloud-based service and wrote a very cool piece about it on ZDNet here.

I remembered after the fact that I wrote a related blog on the topic several months ago titled "Cloud Computing: Invented by Criminals, Secured by ???" as a rif on something Reuven Cohen wrote.

/Hoff

Source Boston - Video Interviews of Security Rockstars...

Source Boston has officially wound down, but I'm still on Cloud 9 (sorry) following the amazing sessions and interaction I had with my fellow attendees and speakers.

My presentation was well received and with Marcus Ranum, Dan Geer, and Adam Shostack sitting six feet in front of me, I didn't choke as badly as I could have.  I had a ton of fun giving this first run preso and got a lot of great feedback and questions.

One of the most excellent things I got to do was spend some time walking about with Zach Lanier (@quine on Twitter) and interview many of the vendors and speakers extemporaneously on various subjects.

I'll be updating this post with links to the interviews as I get them cleaned up and uploaded to YouTube...

Here's a sampling of what you can expect:

• David Mortman, "I Can Haz Privacy"
• Dmitry McKay, LogLogic
• Chris Wysopal - Veracode 
• Peter Kuper - "Silver Linings"
• Jose Nazario, Arbor, "Politically Motivated DDoS Attacks" 
• Christien Rioux, Source
• Jeremiah Grossman, Whitehat Security, "Get Rich or Die Trying, Making Money the Black Hat Way"
• Amrit Williams, BigFix, "The Economics of CyberCrime & the Law of Malware Probability"  
• Adam Shostack, Microsoft, "The Crisis In Information Security"  
• Dan Kaminsky, IOActive, "DNS - Toward a Secure Infrastructure" 
• Chris Weber, Casaba Security, "Exploiting Unicode-Enabled Software"  
• Rob Cheyne, SafeLight, "The End Of Our Rope: The On-Going Discussion Between Business & Security" 

You'll laugh, you'll cry, you'll wonder why people gave me this task...

But seriously, we discuss such mega-issues such as DDoS, Snuggies, Bedazzlers, Zombies and Estonian dissident groups (and that's in just ONE of the talks.)  

I think I've found something I absolutely LOVE doing -- vlogging (video blogging) and will try and do more of it.

Check back for updates to the links over the weekend.

/Hoff

Oh Noes: We Can't Monitor/Protect Against Intra-VM Traffic!

I got a press release in my inbox this morning that made me cringe.  It came from a vendor who produces a "purpose-built virtual firewall."

The press release details a customer case study that I found typical of how security solutions are being marketed in the virtualization space today, which again is really more about visibility than pure "security" and preys mostly on poor planning and fundamental issues stemming from treating "security" like a band-aid instead of an element of enterprise architecture.

When we start to cross the streams as to the realities of virtualization, the security implications thereof and making promises to solve problems with products which may or may not be deserving of investment given an assessment of risk, especially in today's trying economic climate, it makes me cranky.

I'm just tiring of the mixing of metaphors in the marketing of these "solutions."

I was specifically annoyed by a couple of statements in the press release and since I haven't had my coffee, I thought I'd point out a few to further underscore what I present in my Four Horsemen presentation regarding where we are in the solution continuum today.

To wit:

[Customer] has selected the [Vendor's] virtual firewall to secure its virtual environment and mitigate an attack before it could hit their network. 

Given the fact that to get to a VM you generally have to (1) utilize the physical network and (2) transit the vSwitch in the VMM, the reality is that an attack has already "hit their network" long before it gets to the VM or the virtual firewall, at least given today's available offerings.  There is no magic security fairy dust that will mitigate an attack presciently.

If you put VM's into production that are already infected, you have other problems to solve...

“After moving our production applications to a virtualized environment we realized that we lacked security; I had no visibility into what was going on between VMs and a virtual attack could take down our network,” said [Customer.]  “We sought the same level of security for our virtual environment that we had with our physical network.”

This indicates a lack of proper risk management and planning on the part of the [Customer.]  Further, it underscores an example I use in the Four Horsemen which concerns which tools in a multi-server physical deployment did the [Customer] use to monitor/protect in-line traffic between these physical machines? 

The {Customer] must have done this since the press release suggests they demand the "...same level of security for [their] virtual environment that [they] had with [their] physical network."

Did the [Customer] have each physical server on it's own VLAN/subnet, isolated with firewalls?  Did he SPAN every single port to an IDS/IPS?  If not, what's the difference here?  The Hypervisor?  What protection mechanisms has the fancy virtual firewall put in place to protect it?  None.

[Customer] was increasingly concerned about the risks of virtual networks, which range from security policy violations such as mixing trusted and un-trusted systems to malware exploits that can propagate undetected within a virtual network. 

Based upon the second paragraph above where the [Customer] admitted they put their virtualized environment into production without visibility or security, they clearly weren't that concerned with the risks.

A large amount of data center network traffic was moving between VMs and [Customer] had no visibility or control over the communication on the virtual network.

So if there were no security or visibility tools in place, how was it determined that traffic was moving between VM's?

Does this mean that all the customer's VM's were in a single VLAN and not segmented? If not and vSwitch configurations via port groups and VLANs were configured around VM criticality, role or function, then they certainly had some insight into what was moving between VM's and the "data center," right?

I must be confused. 

[Customer's] traditional network security tools could not monitor, analyze or troubleshoot inter-VM traffic because communications between VMs on the same physical host never touch the traditional network. 

Assuming that the VM's weren't in a single VLAN/portgroup on a single vSwitch and instead were segmented via VLANs/subnets, then the only way to get traffic from VLAN/IP Subnet A to VLAN/IP Subnet B (and thus VM A to VM B in these VLAN's) is though a layer 3 routing process which generally means traffic exits the virtual network and hits the physical network...where said "traditional security tools" could see it.

Of course, this doesn't help intra-VM traffic on the same portgroup/VLAN/vSwitch, but that's not what they pointed to above, but assuming they don't look at inter-machine traffic in their physical network on the same VLAN, again I ask what's the difference?

VMs were able to communicate with each other without observation or policy-based inspection and filtering, which left them highly vulnerable to malicious exploits. Additionally, worms and viruses could further spread among physical hosts via unintentional VMotion of an infected VM.

Back to my point above about how the [Customer] monitored traffic between physical hosts...if you don't do it in physical environments, why the fret in the virtual?

Oh and "unintentional VMotion!?" ZOMG!  For a VM to be "infected," excluding direct physical access, wouldn't the threat vector be the network in the first place?  

The [Vendor] virtual firewall was specifically created to mitigate the risks of virtual networks, while maintaining the ROI of virtualization.

What "risks of virtual networks" does this product mitigate in the absence of vulnerability or clearly defined threats that aren't faced in the physical realm?  Let me tell you.  It goes back to the very valid claim that you get better visibility given the integration with the virtualization platform configuration managers to call attention to when CHANGE occurs.

This is the real value of products like this from [Vendor.]  In the long run, the big boys who make mature firewalls and IPS products will get to harness API's like VMsafe and combined with the compartmentalization and segmentation capabilities of vShield Zones leaves a very short runway for products like this.

I'm not suggesting that products like this from [Vendor] don't offer value and solve an immediate pain point. I'd even consider deploying them to solve very specific problems I might have, but then again, I know what problem I'd be trying to solve. ROI?  Oy.

However, unlike the picture painted of the [Customer] above, I plan a little better and understand the impact virtualization has on my security posture and how that factors into my assessment and management of risk BEFORE I put it into production.  You should too.

</rant>

{Ed: I use 'intra-' instead of 'inter-' to reflect the "internal" passing of traffic between VM's using the vSwitch. Should traffic exit the vSwitch/host and hit the network as part of interchange between two VM's, I'd count this as 'inter-" VM traffic.}

Sun vs. Cisco? I'm Getting My Popcorn...

Scott Lowe wrote an interesting blog today wondering if Sun was preparing to take on Cisco in the virtualization space, referencing the development of virtualized networking functionality featuring the novel combination of commodity hardware and open source software to unseat the Jolly Green Giant:

A while back in Virtualization Short Take #25 I briefly mentioned Sun’s Crossbow network virtualization software, which brings new possibilities to the Solaris networking world. Not being a Solaris expert, it was hard for me at the time to really understand why Solaris fans were so excited about it; since then, though, I’ve come to understand that Crossbow brings to Solaris the same kind of full-blown virtual network interfaces and such that I use daily with VMware ESX. Now I’m beginning to understand why people are so thrilled!

In any case, an astute reader picked up on my mention of Crossbow and pointed me to this article by Jonathan Schwartz of Sun, and in particular this phrase:

You’re going to see an accelerating series of announcements over the coming year, from amplifying our open source storage offerings, to building out an equivalent portfolio of products in the networking space…

That seemingly innocuous mention was then coupled with this blog post and the result was this question: is Sun preparing to take on Cisco? Is Sun getting ready to try to use commodity hardware and open source software to penetrate the networking market in the same way that they are using commodity hardware and open source software to try to further penetrate the storage market with their open storage products (in particular, the 7000 series)?

It’s an interesting thought, to say the least. Going up against Cisco is a bold move, though, and I question Sun’s staying power in that sort of battle. Of course, with Cisco potentially distracted by the swirling rumors regarding the networking giant’s entry into the server market, now may be the best time to make this move.

It's really the last paragraph that is of interest to me, specifically the boldfaced sentence I highlighted.  I think the "rumors" have pretty much been substantiated by the mainstream press, so let's assume "California" is going to happen.

Let's make a couple of things really, really clear:

1. I don't know how anyone can think that Cisco is "distracted" by bringing to market the logical extension of virtualized infrastructure -- the compute function -- as anything other than a shrewd business decision to offer a complete end-to-end solution to customers.  I talked about it here in blog post titled "Cisco Is NOT Getting Into the Server Business..." This is an Enterprise Architecture play, pure and simple.
2. Honestly, if we're discussing commoditization, a server is a server is a server, whether it's in a blade form factor or not, and it's not like Cisco has to worry about building things from scratch. The availability of OEM/ODM components (raw or otherwise) means they don't have to start from scratch.  Oh yes, I know HP spent a bazillion dollars on C-Class fan engineering and IBM's BCHT is teh awesome and...
3. The whole game is Unified Computing; bringing together enterprise class compute, network and storage as a solution with integrated virtualization, management and intelligence; you take the biggest pain point out of the equation -- integration -- and you drive down cost while increasing utility, agility and efficiency.
4. If you look at what "California" is slated to deliver it's hard to see how Sun would compete: A blade based chassis with integrated Nexus converged networking/storage, integrated virtualization from VMware (with Nexus/VN-Link,) and management from BMC.  You know, Enterprise stuff, not integration hodge podge. 

So, I ask, does this look like a distraction to you? 

I'm not knocking Sun (or Scott to be clear,) but if I were they, I'd be much more worried about HP or IBM or even Microsoft and Redhat.

I'm grabbing my popcorn, but this battle might be over before the kernels (ha!) start popping.

/Hoff

Cloud Computing Not Ready For Prime Time?

I just read another in a never-ending series of articles that takes a polarized view of Cloud Computing and its readiness for critical applications and data.

In the ComputerWorld article titled "Cloud computing not ready for critical apps,", Craig Steadman and Patrick Thibodeau present some very telling quotes from CIO's of some large enterprises regarding their reticence toward utilizing "Cloud Computing" and it's readiness for their mission critical needs.

The reasons are actually quite compelling, and I speak to them (and more) in my latest Cloud Computing presentation which I am giving at Source Boston this week:

Reliability, availability and manageability are all potential show-stoppers for the CIO's in this article, but these are issues of economic and adoptive context that don't present the entire picture. 

What do I mean?

At the New England Cloud Computing Users' Group, a Cloud-based startup called Pixily presented on their use of Amazon's AWS services. They painted an eye-opening business case which detailed the agility and tremendous cost savings that the "Cloud" offers.  "The Cloud" provides them with reduced time-to-market, no up-front capital expenditures and allows them to focus on their core competencies. 

All awesome stuff.

I asked them about how their use of AWS and what amounted to a sole-source service provider did to their disaster recovery, redundancy/resiliency and risk management processes.  They had to admit that the day they went live with feature coverage on the front page of several newspapers also happened to be the day that Amazon suffered an 8 hour outage, and thus, so did they.

Now, for a startup, the benefits often outweigh the risks associated for downtime and vendor lock-in. For an established enterprise with cutthroat service levels, regulatory pressures and demanding customers who won't/can't tolerate outages, this is not the case.

Today we're suffering from issues surrounding the fact that emerging offerings in Cloud Computing are simply not mature if what you're looking for involves the holistic and cohesive management, reliability, resilience and transparency across suppliers of Cloud services.

We will get there as adoption increases and businesses start to lean on providers to create and adopt standards that answer the issues above, but today if you're an enterprise who needs five 9's, you may come to the same conclusion as the CIO's in the CW article.  If you're an SME/SMB/Startup, you may find everything you need in the Cloud.

It's important, however, to keep a balanced, realistic and contextual perspective when addressing Cloud Computing and its readiness -- and yours -- for critical applications.  Polarizing the discussion to one hyperbolic end or the other is not really helpful.

/Hoff

If Virtualization is a Religion, Does That Make Cloud a Cult?

I had just finished reading Virtual Gipsy's post titled "VMware as religion" when my RSS reader featured a referential post from VM/ETC's Rich titled "vTheology: the study of virtualization as religion."

While I appreciated the humor surrounding the topic, I try never to mix friends politics, and religion* so I'll not wade into the deep end on this one except to suggest what my title asks: 

If virtualization is a religion, does that make cloud a cult?

If so, to whom do I send my tidings?  Who is the Cardinal of the Cloud?  The Pope of PaaS?  The Shaman of Service?

...and where's my phenobarbital, vodka and purple cape?

/Hoff

*...and truth be told, I'm not feeling particularly witty this morning.

Incomplete Thought: Offensive Computing - The Empire Strikes Back

Yesterday at IANS, Greg Shipley gave a great keynote that focused on a lot of things we do today in InfoSec that aren't necessarily as effective as they should be. Greg called for a change in our behavior as a community to address the gaps we have.

In the Q&A section, it occurred to me that for the sake of argument, I would ask Greg about his thoughts on changing our behavior and position in dealing with security and our adversaries by positing that instead of always playing defense, we should play some offense.

I didn't constrain what I meant by "offense" other to suggest that it could include "active countermeasures," but what is obvious is that people immediately throw up walls around being "offensive" without spending much time defining what it actually means.

I've written and spoken about this before, but it's a rather contentious issue. It gets shelved pretty quickly by most but it really shouldn't in my opinion.

In a follow-on discussion after the keynote, Marcus Ranum, Richard Bejtlich, Rocky DeStefano and I were standing around shooting the, uh, stuff, when I brought this up again.

We had a really interesting dialog wherein we explored what "offensive computing" meant to each of us and it was clear that simply playing defense alone would never allow us to do anything more than spend money and hope.

There's not been a war yet that has been won with defense alone, so why do we expect we can win this one by simply piling on more barbed wire when the enemy is dropping smart bombs? This is the definition of insanity and a behavior that we don't talk about changing.

"Don't spend money on AV because it's not effective" is an interesting behavioral change from the perspective of how you invest. Don't lay down and take it up the assets by only playing defense is another.

I'm being intentionally vague, obtuse and non-specific when it comes to defining what I mean by "offensive," but we're at a point in time where at a minimum we have the technology and capability to add a little "offense" to our defense.  

You want a change in behavior?  How about not playing the victim?

What are your thoughts on "offensive computing?"  

/Hoff

Ron Popeil and Cloud Computing In Poetic Review...

The uptake of computing
using the cloud,
would make the king of all marketeers
-- Ron Popeil -- proud

He's the guy who came out
with the canned spray on hair,
the oven you set and forget
without care

He had the bass fishing rod
you could fit in your pocket,
the Veg-O-Matic appliance
with which you could chop it

Mr. Microphone, it seems, 
was ahead of its time
Karaoke meets Facebook
Oh, how divine!

The smokeless ashtray,
the Cap Snaffler, drain buster
selling you all of the crap
Infomercials could muster

His inventions solved problems
some common, some new
If you ordered them quickly
he might send you two!

Back to the Cloud
and how it's related
to the many wonders
that Sir Ron has created

The cloud fulfills promises
that IT has made:
agility, better service
at a lower pay grade

You can scale up, scale down
pay for just what you use
Elastic infrastructure
what you get's what you choose

We've got public and private,

outside and in,

on-premise, off-premise

thick platforms or thin

The offerings are flooding
the wires en masse
Everything, it now seems,
is some sort of *aaS

You've got infrastructure,
platforms, software and storage.
Integration, SOA 
with full vendor whoreage

Some folks equate
virtualization with cloud
The platform providers
shout this vision out loud

'Course the OS contingent
has something to say
that cloud and virt
is part of their play

However you see it,
and whatever its form
the Cloud's getting bigger
it's starting to storm

Raining down on us all
is computational glory
but I wonder, dear friends,
'bout the end of this story

Will the Cloud truly bring value?
Solve problems that matter?
Or is it about 
vendors' wallets a-fatter?

*I* think the Cloud
has wonderful promise
If the low-hanging IT fruit
can be lifted 'way from us

The Cloud is a function
that's forging new thought
Pushing the boundaries
and theories we've bought

It's profoundly game changing

and as long as we focus

and don't buy into the 

hyped hocus pocus

So before we end up
with a Cloud that "slices and dices"
that never gets dull,
mashes, grates, grinds and rices

It's important to state

what problem we're solving

so the Cloud doesn't end up

with its value de-evolving

----

BTW, if you want to see more of my Cloud and Security poems, just check here.

I'm Sorry, But Did Someone Redefine "Open" and "Interoperable" and Not Tell Me?

I've got a problem with the escalation of VMware's marketing abuse of the terms "open," "interoperable," and "standards."  I'm a fan of VMware, but this is getting silly.

When a vendor like VMware crafts an architecture, creates a technology platform, defines an API, gets providers to subscribe to offering it as a service and does so with the full knowledge that it REQUIRES their platform to really function, and THEN calls it "open" and "interoperable," because an API exists, it is intellectually dishonest and about as transparent as saran wrap to call that a "standard" to imply it is available regardless of platform.

We are talking about philosophically and diametrically-opposed strategies between virtualization platform players here, not minor deltas along the bumpy roadmap highway.  What's at stake is fundamentally the success or failure of these companies.  Trying to convince the world that VMware, Microsoft, Citrix, etc. are going to huddle for a group hug is, well, insulting.

This recent article in the Register espousing VMware's strategy really highlighted some of these issues as it progressed. Here's the first bit which I agree with:

There is, they fervently say, no other enterprise server and data centre virtualisation play in town. Businesses wanting to virtualise their servers inside a virtualising data centre infrastructure have to dance according to VMware's tune. Microsoft's Hyper-V music isn't ready, they say, and open source virtualisation is lagging and doesn't have enterprise credibility.

Short of the hyperbole, I'd agree with most of that.  We can easily start a religious debate here, but let's not for now.  It gets smelly where the article starts talking about vCloud which, given VMware's protectionist stance based on fair harbor tactics, amounts to nothing more (still) than a vision.  None of the providers will talk about it because they are under NDA.  We don't really know what vCloud means yet: 

Singing the vcloud API standard song is very astute. It reassures all people already on board and climbing on board the VMware bandwagon that VMware is open and not looking to lock them in. Even if Microsoft doesn't join in this standardisation effort with a whole heart, it doesn't matter so long as VMware gets enough critical mass.

How do you describe having to use VMware's platform and API as VMware "...not looking to lock them in?" Of course they are!  

To fully leverage the power of the InterCloud in this model, it really amounts to either an ALL VMware solution or settling for basic connectors for coarse-grained networked capability.

Unless you have feature-parity or true standardization at the hypervisor and management layers, it's really about interconnectivity not interoperability.  Let's be honest about this.

By having external cloud suppliers and internal cloud users believe that cloud federation through VMware's vCloud infrastructure is realistic then the two types of cloud user will bolster and reassure each other. They want it to happen and, if it does, then Hyper-V is locked out unless it plays by the VMware-driven and VMware partner-supported cloud standardisation rules, in which case MIcrosoft's cloud customers are open to competitive attack. It's unlikely to happen.

"Federation" in this context really only applies to lessening/evaporating the difference between public and private clouds, not clouds running on different platforms.  That's, um, "lock-in."

Standards are great, especially when they're yours. Now we're starting to play games.  VMware should basically just kick their competitors in the nuts and say this to us all:

"If you standardize on VMware, you get to leverage the knowledge, skills, and investment you've already made -- regardless of whether you're talking public vs. private.  We will make our platforms, API's and capabilities as available as possible.  If the other vendors want to play, great.  If not, your choice as a customer will determine if that was a good decision for them or not."

Instead of dancing around trying to muscle Microsoft into playing nice (which they won't) or insulting our intelligence by handwaving that you're really interested in free love versus world domination, why don't you just call a spade a virtualized spade.

And by the way, if it weren't for Microsoft, we wouldn't have this virtualization landscape to begin with...not because of the technology contributions to virtualization, but rather because the inefficiencies of single app/OS/hardware affinity using Microsoft OS's DROVE the entire virtualization market in the first place!

Microsoft is no joke.  They will maneuver to outpace VMware. HyperV and Azure will be a significant threat to VMware in the long term, and this old Microsoft joke will come back to haunt to VMware's abuse of the words above:

Q: How many Microsoft engineers does it take to change a lightbulb?  
A: None, they just declare darkness a standard.

is it getting dimmer in here?

/Hoff

Amazon's Kindle: Some Interesting Security Thoughts

My Kindle2 showed up yesterday. I un-boxed it, turned it on and within 3 minutes had downloaded my first book and was reading away (Thomas Barnett's "Great Powers," if you must know.)

So this morning after I checked my email on my other indispensable tool/toy, my iPhone, I realized something was missing from the Kindle: a password.

So you might think "Hoff, why would you need a password for a device that lets you read books?'

Well, while it's true that the majority of users will simply read "off-the-shelf" books/blogs/magazines they download from Amazon.com's storefront on their Kindles, there are a couple of other interesting scenarios that ran through my mind:

1. To purchase a book using the Kindle, the device is linked to Amazon's One-Click purchase capability.  This means that once I choose to purchase a book, I simply click "Buy" and it's delivered to the device, automagically charging my credit card.  If I lost my device, someone who found it could literally download hundreds of books to the Kindle on my nickel until I am able to do something about it.  This would be short-lived, but really annoying.
2. It is possible using an Amazon web service to convert documents into the Kindle Format and download them over WhisperNet to your device.  Given how convenient this is for reading, imagine what would happen if some crafty person decided to convert and download a sensitive document to the Kindle and then lose the device.  Imagine if that document contained PII or other confidential/sensitive information?  I wager we'll see a breach notification being issued based on someone losing a Kindle.

Yes, I know it's a piece of "consumer" equipment, but look a little further down the line: college students using it for textbooks and all sorts of other communications, business people using it for reading corporate materials, etc...

I am interested in exploring the following elements in the long term:

1. An option for password-protected access to the device itself.
2. A content-rating based password-controlled parental rating system for certain materials. My kids already grabbed my Kindle and (see #1 above) downloaded 3 kids books to it.  I may not want them to read certain content.
3. Remote self-destruct 
4. Encryption of content (at rest, in motion)
5. Security of Whispernet itself
6. WiFi (and it's attendant issues)

I'm sure as I dwell on this, there will be other issues that crop up, but the security wonk in me was in full gear this morning.

You have any other security shortcomings or concerns you've thought of re: the Kindle? 

/Hoff

Interesting Read: The World Privacy Forum's Cloud Privacy Report

The World Privacy Forum released their "Cloud Privacy Report" written by Robert Gellman two days ago. It's an interesting read that describes the many facets of data privacy concerns in Cloud environments: 

This report discusses the issue of cloud computing and outlines its implications for the privacy of 
personal information as well as its implications for the confidentiality of business and 
governmental information. The report finds that for some information and for some business 
users, sharing may be illegal, may be limited in some ways, or may affect the status or 
protections of the information shared. The report discusses how even when no laws or 
obligations block the ability of a user to disclose information to a cloud provider, disclosure may 
still not be free of consequences. The report finds that information stored by a business or an 
individual with a third party may have fewer or weaker privacy or other protections than 
information in the possession of the creator of the information. The report, in its analysis and 
discussion of relevant laws, finds that both government agencies and private litigants may be 
able to obtain information from a third party more easily than from the creator of the 
information. A cloud provider’s terms of service, privacy policy, and location may significantly 
affect a user’s privacy and confidentiality interests.

I plan to spend some time reading through the report in more depth, but I enjoyed my cursory review thus far, especially some of the coverage related to issues such as FCRA, bankruptcy, Cloud provider ownership, disclosure, etc.  Many of these issues are near and dear to my heart.

You can download the report here.

/Hoff

Internal v. External/Private v. Public/On-Premise v. Off- Premise: It's all Cloud But How You Get There Is Important.

I've written about the really confusing notional definitions that seem to be hung up on where the computing actually happens when you say "Cloud:" in your datacenter or someone else's.  It's frustrating to see how people mush together "public, private, internal, external, on-premise, off-premise" to all mean the same thing.

They don't, or at least they shouldn't, at least not within the true context of Cloud Computing.

In the long run, despite all the attempts to clarify what we mean by defining "Cloud Computing" more specifically as it relates to compute location, we're going to continue to call it "Cloud."  It's a sad admission I'm trying to come to grips with.  So I'll jump on this bandwagon and take another approach.

Cloud Computing will simply become ubiquitous in it's many forms and we are all going to end up with a hybrid model of Cloud adoption -- a veritable mash-up of Cloud services spanning the entire gamut of offerings.  We already have today.

Here are a few, none-exhaustive examples of what a reasonably-sized enterprise can expect from the move to a hybrid Cloud environment:

1. If you're using one or more SaaS vendors who own the entire stack, you'll be using their publicly-exposed Cloud offerings.  They manage the whole kit-and-kaboodle, information and all. 
2. SaaS and PaaS vendors will provide ways of integrating their offerings (some do today) with your "private" enterprise data stores and directory services for better integration and business intelligence.
3. We'll see the simple evolution of hosting/colocation providers add dynamic scalability and utility billing and really push the Cloud mantra.  
4. IaaS vendors will provide (ala GoGrid) ways of consolidating and reducing infrastructure footprints in your enterprise datacenters by way of securely interconnecting your private enterprise infrastructure with managed infrastructure in their datacenters. This model simply calls for the offloading of the heavy tin. Management options abound: you manage it, they manage it, you both do...
5. Other IaaS players will continue to offer a compelling suite of soup-to-nuts services (ala Amazon) that depending upon your needs and requirements, means you have very little (or no) infrastructure to speak of.  You may or may not be constrained by what you can or need to do as you trade of flexibility for conformity here.
6. Virtualization platform providers will no longer make a distinction in terms of roadmap and product positioning between internal/external or public/private. What is enterprise virtualization today simply becomes "Cloud."  The same services, split along virtualization platform party lines, will become available regardless of location. 
7. This means that vendors who today offer proprietary images and infrastructure will start to drive or be driven to integrate more open standards across their offerings in order to allow for portability, interoperability and inter-Cloud scalability...and to make sure you remain a customer.
8. Even though the Cloud is supposed to abstract infrastructure from your concern as a customer, brand-associated moving parts will count; customers will look for pure-play vetted integration between the big players (networking, virtualization, storage) in order to fluidly move information and applications into and out of Cloud offerings seamlessly 
9. The notion of storage is going to be turned on its head; the commodity of bit buckets isn't what storage means in the Cloud.  All the chewy goodness will start to bubble to the surface as value-adds come to light: DeDup, backup, metadata, search, convergence with networking, security...
10. More client side computing will move to the cloud (remember, it doesn't matter whether it's internal or external) with thin client connectivity while powerful smaller-footprint mobile platforms (smartphones/netbooks) with native virtualization layers will also accelerate in uptake

Ultimately, what powers your Cloud providers WILL matter.  What companies adopt internally as their virtualization, networking, application delivery, security and storage platforms internally as they move to consolidate and then automate will be a likely choice when evaluating top-rung weighting when they identify what powers many of their Cloud providers' infrastructure.

If a customer can take all the technology expertise, the organizational and operational practices they have honed as they virtualize their internal infrastructure (virtualization platform, compute, storage, networking, security) and basically be able to seamlessly apply that as a next step as the move to the Cloud(s), it's a win.

The two biggest elements of a successful cloud: integration and management. Just like always.

I can't wait.

/Hoff

*Yes, we're concerned that if "stuff" is outside of our direct control, we'll not be able to "secure" it, but that isn't exactly a new concept, nor is it specific to Cloud -- it's just the latest horse we're beating because we haven't made much gains in being able to secure the things that matter most in the ways most effective for doing that.

Virtualization & Security: Disruptive Technologies - A Four Part Video Miniseries...

About nine months ago, Dino Dai Zovi, Rich Mogull and I sat down for about an hour as Dennis Fisher from TechTarget interviewed us in a panel style regarding the topic of virtualization and security.  It has just been released now.

Considering it was almost a lifetime ago in Internet time, almost all of the content is still fresh and the prognostication is pretty well dead on.

Enjoy:

Part 1: The Greatest Threats to Virtualized Environments

Part 2: The Security Benefits of Virtualization

Part 3: The Organizational Challenges of Virtualization

Part 4: Virtualization and Security Vendors

/Hoff

P.S. The camera adds like 40 pounds, really ;)

Hire the Hoff - I'm On the Market, Whatcha Need? ;)

The last two years have been a blast but all things must come to an end.

At the conclusion of March, I am moving on to newer pastures.  Where that is may be up to you.

I am exploring all options with a focus on traditional security roles including CISO/CSO, but I'd prefer architect/evangelist/CTO roles that focus more on virtualization and Cloud Computing security.

If you've got an opportunity that you think we'd both be a match for, feel free to reach out.  

A dose of reality: If you're not serious about envelope pushing, thought/industry leadership, world domination and unabashed enthusiasm sprinkled with rational pragmatism, I'm not your guy...

My LinkedIn profile is here.  My email is here. 

Thanks,

/Hoff

Trust But Verify? That's An Oxymoron...

In response to my post regarding Cloud (SaaS, really) providers' security, Allen Baranov asked me the following excellent question in the comments:

Hoff,

What would make you trust "the Cloud"? Scrap that... stupid question...

What would make you trust SaaS providers?

To which I responded:

Generally, my CEO or CFO. :(  

I don't "trust" third party vendors with my data. I never will. I simply exercise the maximal amount of due diligence that I am afforded given prevailing time, money, resources and transparency and assess risk from there.

Even if the data is not critical/sensitive, I don't "trust" that it's not going to be mishandled. Not in today's world.  (Ed: How I deal with that mishandling is the secret sauce...)

I then got thinking about the line that Ronald Reagan is often credited with wherein he described managing relations with the former Soviet Union:

Trust but verify.

Security professionals use that phrase a lot. They shouldn't. It's oxymoronic.

The very definition of "trust" is:

trust |trəst|
noun
1 firm belief in the reliability, truth, ability, or strength of someone or something : relations have to be built on trust | they have been able to win the trust of the others.
• acceptance of the truth of a statement without evidence or investigation : I used only primary sources, taking nothing on trust.
• the state of being responsible for someone or something : a man in a position of trust.
• poetic/literary a person or duty for which one has responsibility : rulership is a trust from God.
• poetic/literary a hope or expectation : all the great trusts of womanhood.

See the second bullet above "....without evidence or investigation"?  I don't "trust" people over which I have no effective control. With third parties handling your data, you have no effective "control." You have the capability to audit, assess and recover, but control?  Nope.

Does that mean I think you should not put your information into the hands of a third party?  Of course not.  It's inevitable.  You already have. However, admitting defeat and working from there may make Jack a dull boy, but he's also not unprepared for when the bad stuff happens.  And it will.

I stand by my answer to Allen.

You?

/Hoff

What People REALLY Mean When They Say "THE Cloud" Is More Secure...

Over the last two days, I've seen a plethora (yes, Jefe, a plethora) of trade rag and blog articles espousing that The Cloud is more secure than an enterprise's datacenter and that Cloud security concerns are overblown.  I'd pick these things apart, but honestly, I've got work to do.

<sigh>

Here's the problem with these generalizations, even when some of the issues these people describe are actually reasonably good points:

Almost all of these references to "better security through Cloudistry" are drawn against examples of Software as a Service (SaaS) offerings.  SaaS is not THE Cloud to the exclusion of everything else.  Keep defining SaaS as THE Cloud and you're being intellectually dishonest (and ignorant.)

But since people continue to attest to SaaS==Cloud, let me point out something relevant.

There are two classes of SaaS vendors: those that own the entire stack including the platform and underlying infrastructure and those those that don't.  

Those that have control/ownership over the entire stack naturally have the opportunity for much tighter control over the "security" of their offerings.  Why?  because they run their business and the datacenters and applications housed in them with the same level of diligence that an enterprise would.

They have context.  They have visibility.  They have control.  They have ownership of the entire stack.  

The HUGE difference is that in many cases, they only have to deal with supporting a limited number of applications.  This reflects positively on those who say "Cloud SaaS providers are "more secure," mostly because they have less to secure.

Meanwhile those SaaS providers that simply run their appstack atop someone else's platform and infrastructure are, in turn, at the mercy of their providers.  The information and applications are abstracted from the underlying platforms and infrastructure to the point that there is no unified telemetry or context between the two.  Further, add in the multi-tenancy issue and we're now talking about trust boundaries that get very fuzzy and hard to define: who is responsible for securing what.

Just. Like. An. Enterprise. :(

Check out the Cloud model below which shows the demarcation between the various layers of the SPI model of which SaaS is but ONE:

The further up the offering stack you go, the more control you have over your information and the security thereof. Oh, and just one other thing.  The notion that Cloud offerings diminish attack surfaces is in many cases a good thing for sophisticated attackers as much as it may act as a deterrent.  Why?  Because now they have a more clearly defined set of attack surfaces -- usually at the application layer -- that makes their job easier.

Next time one of these word monkeys makes a case for how much more secure The Cloud is and references a SaaS vendor like SalesForce.com (a single application) in comparison to an enterprise running (and securing) hundreds of applications, remind them about this and this, both Cloud providers. I wrote about this last year in an article humorously titled "Cloud Providers Are Better At Securing Your Data Than You Are."

Like I said on Twitter this morning "I *love* the Cloud. I just don't trust it.  Sort of like why I don't give my wife the keys to my motorcycles."

We done now?

/Hoff

Coghead Closes and It's the Death Knell For Cloud Computing!? Holy Hyperbole, Batman!

This InformationWeek article took artistic license to lofty new levels in a single sentence as it described the demise of Cloud Computing PaaS vendor Coghead and the subsequent IP/Engineering purchase by SAP:

Bad news for cloud computing: Coghead -- a venture-backed, online application development platform -- is closing, leaving customers with a problem to solve.

It's indeed potentially bad news for Coghead's customers who as early adopters took a risk by choosing to invest in a platform startup in an emerging technology sector.  It's hardly indicative of an established trend that somehow predicts "bad news for Cloud Computing" as a whole.

It's a friendly reminder that "whens you rolls da dice, you takes your chances." Prudent and pragmatic risk assessment and relevant business decisions still have to be made when you decide to place your bets on a startup.  Just because you move to the Cloud doesn't mean you stop employing pragmatic common sense. I hope these customers have a Plan B.

This is the problem again with lumping all of the *aaS'es into a bucket called Cloud; are we to assume Amazon's AWS (IaaS) and SalesForce.com (SaaS) are going to shutter next week?  No, of course not. Will there be others who close their doors and firesale?  Most assuredly yes, just like there are in most tech markets.

Here's what Coghead's CEO (in the same article, mind you) explained as the reason for the closure:

Though McNamara said business was continuing to grow rapidly, the recession ultimately did Coghead in, and Coghead began looking for buyers a few months ago. "Faced with the most difficult economy in memory and a challenging fundraising climate, we determined that the SAP deal was the best way forward for the company," McNamara wrote in a letter to customers that went out late Thursday

That's correct kids, even the almighty Cloud, the second coming of computing, is not immune to the pressures of running a business in a tough economy, especially the platform business...

First it was hype around the birth of Cloud and now it's raining epitaphs.  I call dibs on Amazon's SAN arrays!

/Hoff

Berkeley RAD Lab Cloud Computing Paper: Above the Clouds or In the Sand?

I've waffled on how, or even if, I would write my critique of the Berkeley RAD Lab's paper titled "Above the Clouds: A Berkeley View of Cloud Computing." 

I think I've had a hard time deciding where the authors have their heads, hence the title.

Those of you who know me are probably chuckling at the fact that I was a good boy and left off the potential third cranial location option...

Many people have written their respective reviews of the work including James Urquhart, David Linthicum and Chuck Hollis who all did a nice job summarizing various perspectives.

I decided to add my $0.02 because it occurred to me that despite several issues I have with the paper, two things really haven't been appropriately discussed:

1. The audience for the paper
2. Expectations of the reader 

The goals of the paper were fairly well spelled out and within context of what was written, the authors achieved many of them.

Given that it was described as a "view" of Cloud Computing and not the definitive work on the subject, I think perhaps the baby has been unfairly thrown out with the bath water even when balanced with the "danger" that the general public or press may treat it as gospel.

I think the reason there has been so much frothy reaction to this paper by the "Cloud community" is that because the paper comes from the Electrical Engineering/Computer Science department of UC Berkeley, a certain level of technical depth and a more holistic (dare I say empirical) model for analysis is expected by many readers and their expectations are therefore set a certain way.  

Most of the reviews that might be perceived as negative are coming from folks who are reasonably technical, of which I am one.

To that point and that of item #1 above, I don't feel that "we" are the intended audience for this paper and thus, to point #2 above, our expectations -- despite the goals of the paper -- were not met.

That being said, I do have issues with the authors' definition of cloud computing as unnecessarily obtuse, their refusal to discuss the differences between the de facto SPI model and its variants is annoying and short-sighted, and their dismissal of private clouds as relevant is quite disturbing.  The notion that Cloud Computing must be "external" to an enterprise and use the Internet as a transport is simply delusional. 

Eschewing de facto models of reference because the authors could not agree amongst themselves on the differences between them -- despite consensus in industry outside of academia and even models like the one I've been working on -- comes across as myopic and insulated.  

Ultimately I think the biggest miss of the paper was the fact that they did not successfully answer "What is Cloud Computing and how is it different from previous paradigm shifts such as Software as a Service (SaaS)?"  In fact, I came away from the paper with the feeling that Cloud Computing is SaaS...

However, I found the coverage of the business drivers, economic issues and the top 10 obstacles to be very good and that people unfamiliar with Cloud Computing would come away with a better understanding -- not necessarily complete -- of the topic.

It was an interesting read that is complimentary to much of the other work going on right now in the field.  I think we should treat it as such and move on.

/Hoff

Incomplete Thought: Separating Virtualization From Cloud?

I was referenced in a CSO article recently titled "Four Questions On Google App Security." I wasn't interviewed for the story directly, but Bill Brenner simply referenced our prior interviews and my skepticism for virtualization security and cloud Security as a discussion point.

Google's response was interesting and a little tricky given how they immediately set about driving a wedge between virtualization and Cloud.  I think I understand why, but if the article featured someone like Amazon, I'm not convinced it would go the same way...

As I understand it, Google doesn't really leverage much in the way of virtualization (from the classical compute/hypervisor perspective) for their "cloud" offerings as compared to Amazon. That may be in large part due to the fact of the differences in models and classification -- Amazon AWS is an IaaS play while GoogleApps is a SaaS offering.

You can see why I made the abstraction layer in the cloud taxonomy/ontology model "optional."

This post dovetails nicely with Lori MacVittie's article today titled "Dynamic Infrastructure: The Cloud Within the Cloud" wherein she highlights how the obfuscation of infrastructure isn't always a good thing. Given my role, what's in that cloudy bubble *does* matter.

So here's my incomplete thought -- a question, really:

How many of you assume that virtualization is an integral part of cloud computing? From your perspective do you assume one includes the other?  Should you care?

Yes, it's intentionally vague.  Have at it.

/Hoff

First Oracle with "Unbreakable" Now IBM "Guarantees Cloud Security"

I'm heading out in a few minutes for an all day talk, but I choked on my oatmeal when I read this:

In a CBR article titled "We Can Guarantee Cloud Security" Kristof Kloeckner, IBM's Cloud Computing CTO was quoted at the IBM's Pulse 2009 conference as he tried to "...ease worries over security in the cloud":

Despite all the hype surrounding cloud computing, the issue of security is one debate that will not go away. It is regularly flagged as one of the potential stumbling blocks to widespread cloud adoption.

He said: “We’ve developed some interesting technologies that allow the separation of applications and data on the same infrastructure. We guarantee the security through Tivoli Security and Identity Management and Authentication software, and we also ensure the separation of workloads through the separation of the virtual machines and also the separation of client data in a shared database.” Speaking to CBR after the press conference, Kloeckner went into more detail about IBM’s cloud security offering.

“Security is not essentially any different from securing any kind of open environment; you have to ensure that you know who accesses it and control their rights. We have security software that allows you to manage identities from an organisational model, from whoever is entitled to use a particular service. We can actually ensure that best practices are followed,” Kloeckner said.

Kloeckner added that most people do not realise just how vulnerable they really are. He said: “Most people, unless forced by regulations, usually treat security as a necessary evil. They say it’s very high on their list, but if you really scratch the service, it’s not obvious to me that best practices are followed.”

I wonder if this guarantee is backed up with anything else short of a "sorry" if something bad happens?

This will make for some very interesting discussion when I return today.

/Hoff

Old MacDonald Had a (Virtual Server) Farm, I/O, I/O, Oh!

It's all about the I/O and your ability to shuffle packets...or see them in the first place...

In reading Neil macDonald's first post under the Gartner-branded blog titled "Virtualization Security Is Transformational -- If the legacy Security Vendors Would Stop Fighting It," I find myself nodding in violent agreement whilst also shaking my head in bewilderment.  Perhaps I missed the point, but I'm really confused.

Neil sets the stage by suggesting that "established" security vendors who offer solutions for non-virtualized environments simply "...don't get it" when it comes to realizing the shortcomings of their existing solutions in virtualized contexts and that they are "fighting" the encroachment of virtualization on their appliance sales:

Many are clinging to business models based on their overpriced hardware-based solutions and not offering virtualized versions of their solutions. They are afraid of the inevitable disruption (and potential cannibalization) that virtualization will create. However, you and I have real virtualization security needs today and smaller innovative startups have rushed in to fill the gap. And, yes, there are pricing discontinuities. A firewall appliance that costs $25,000 in a physical form can cost $2500 or less in a virtual form from startups like Altor Networks or Reflex Systems.

I'm very interested in which "established" vendors are supposedly clinging to their overpriced hardware-based solutions and avoiding virtualization besides niche players in niche markets that are hardware-bound.  

As far as I can tell the top five vendors by revenue in the security space (that sell hardware, not just software) are all actively engaged in both supporting these environments with the limitations that currently exist based on the virtualization platforms today and are very much investing in development of new solutions to work properly in virtual environments given the unique requirements thereof.

Neil is really comparing apples to muffler brackets.  He points out in his blog that physical appliances can offer multi-gigabit performance whereas software-based VA's cannot, and yet we're surprised that pricing differentials in orders of magnitude exist?  You get what you pay for.

As I pointed out in my Four Horsemen presentation (and is alluded to in the remainder of Neil's post below) EVERY SINGLE VENDOR is currently hamstrung by the same level of integration and architectural limitations involved with the current state of virtual appliance performance in the security space, including those he mentions such as Altor and Reflex.  They are all in a holding pattern.  I've written about that numerous times.

In fact, as I mentioned in my post titled "Visualization Through Virtualization", the majority of these new-fangled, virtualization-specific "security" tools are actually (now) more focused on visibility, management and change montoring/control than they are pure network-level security because they cannot compete from a performance and scalability perspective with hardware-based solutions.

Here's where I do agree with Neil, based upon what I mention above: 

Feature-wise, the security protection services delivered are similar. But, there is a key difference — throughput. What the legacy security vendors forget is that there is still a role for dedicated hardware. There is no way you are going to get full multi-gigabit line speed deep-packet inspection and protocol decode for intrusion prevention from a virtual appliance. A next-generation data center will need both physical and virtualized security controls — ideally, from a vendor that can provide both. I’ll argue that the move to virtualize security controls will grow the overall use of security controls. 

So this actually explains the disparity in both approach and pricing that he alluded to above.  How does this represent vendors "fighting" virtualization?  I see it as hanging on for as long as possible to preserve and milk their investment in the physical appliances Neil says we'll still need while they perform the R&D on their virtualized versions.  They can't deploy the new solutions until the platform to support them exists!

The move to virtualize security controls reduces barriers to adoption. Rather than a sprinkle a few physical appliance here and there based on network topology, we can now place controls when and where they are needed, including physical appliances as appropriate. If fact, the legacy vendors have a distinct advantage over virtualization security startups since you prefer a security solution that spans both your physical and virtual environments with consistent management.

Exactly.  So again, how is this "fighting" virtualization?  

Here's where we ignore reality again:

Over the past six months, I’ve seen signs of life from the legacy physical security vendors. However, some of the legacy physical security vendors have simply taken the code from their physical appliance and moved it into a virtual machine. This is like wrapping a green-screen terminal application with a web front end — it looks better, but the guts haven’t changed. In a data center where workloads move dynamically between physical servers and between data centers, it makes no sense to link security policy to static attributes such as TCP/IP addresses, MAC addresses or servers. 

First of all, what we're really talking about in the enterprise space is VMware, since given its market dominance, this is where the sweet spot is for security vendors.  This will change over time, but for now, it's VMware.

That being the case, the moment VMsafe was announced/hinted at two years ago, 20+ security vendors -- big and small -- have been diligently working within the constructs of what is made available from VMware to re-engineer their products to take advantage of the API's that will be coming in VMware's upcoming release.  This is no small feat.  Distributed virtual switching and the two-tier driver architecture with DVfilters means re-engineering your products and approach.

Until VMware's next platform is released, every security vendor -- big or small -- is hamstrung by having to do exactly what Neil says; creating a software instantiation of their hardware products which is integration-limited for the reasons I've already stated.  What should vendors do?  Firesale their inventories and wait it out?  

I ask again: how is this "fighting" virtualization?

The reason there hasn't been a lot of movement is because the entire industry is in a holding pattern. Pretending otherwise is absolutely ridiculous.  The obvious exception is Cisco which has invested in and developed substantial solutions such as the Nexus 1000v and VN-Link (which is again awaiting the availability of VMware's next release.)

Security policy in a virtualized environment must be tied to logical identities - like identities of VM workloads, identities of application flows and identities of users. When VMs move, policies need to move. This requires more than a mere port of an existing solution, it requires a new mindset.

Yep.  And most of them are adapting their products as best they can.  Many companies will follow the natural path of consolidation and wait to buy a startup in this space and integrate it...much like VMware did with BlueLane, for example.  Others will look to underlying enablers such as Cisco's VN-Link/Nexus 1000v and chose to integrate at the virtual networking layer there and/or in coordination with VMsafe.

The legacy vendors need to wake up. If they don’t offer robust virtualization security capabilities (and, yes, potentially cannibalize the sales of some of their hardware), another vendor will. With virtualization projects on the top of the list of IT initiatives for 2009, we can’t continue to limp along without protection. It’s time to vote with our wallets and make support of virtual environments a mandatory part of our security product evaluation and selection.

Absolutely!  And every vendor -- big and small -- that I've spoken to is absolutely keen on this concept and are actively engaged in developing solutions for these environments with these unique requirements in mind. Keep in mind that VMsafe is about more than just network visibility via the VMM, it also includes disk, memory and CPU...most network-based appliances have never had this sort of access before (since they are NETWORK appliances) and so OF COURSE products will have to be re-tooled.

Overall, I'm very confused by Neil's post as it seems quite contradictory and at odds with what I've personally been briefed on by vendors in the space and overlooks the huge left turns being made by vendors over the last 18 months who have been patiently waiting for VMsafe and other introspection capabilities of the underlying platforms.

I think the windshield needs cleaning on the combine harvester...

/Hoff

Cisco Is NOT Getting Into the Server Business...

Yes, yes. We've talked about this before here. Cisco is introducing a blade chassis that includes compute capabilities (heretofore referred to as a 'blade server.')  It also includes networking, storage and virtualization all wrapped up in a tidy bundle.

So while that looks like a blade server (quack!,) walks like a blade server (quack! quack!) that doesn't mean it's going to be positioned, talked about or sold like a blade server (quack! quack! quack!)

What's my point?  What Cisco is building is just another building block of virtualized INFRASTRUCTURE. Necessary infrastructure to ensure control and relevance as their customers' networks morph.

My point is that what Cisco is building is the natural by-product of converged technologies with an approach that deserves attention.  It *is* unified computing.  It's a solution that includes integrated capabilities that otherwise customers would be responsible for piecing together themselves...and that's one of the biggest problems we have with disruptive innovation today: integration.

While the analysts worry about margin erosion and cannibalizing the ecosystem (which is inevitable as a result of both innovation and consolidation,) this is a great move for Cisco, especially when you recognize that if they didn't do this, the internalization of network and storage layers within the virtualization platforms  would otherwise cause them to lose relevance beyond dumb plumbing in virtualized and cloud environments.

Also, let us not forget that one of the beauties of having this "end-to-end" solution from a security perspective is the ability to leverage policy across not only the network, but compute and storage realms also.  You can whine (and I have) about the quality of the security functionality offered by Cisco, but the coverage you're going to get with centralized policy that has affinity across the datacenter (and beyond,) iis  going to be hard to beat.

(There, I said it...OMG, I'm becoming a fanboy!)

And as far as competency as a "server" vendor, c'mon. Firstly, you can't swing a dead cat without hitting a commoditzed PC architecture that Joe's Crab Shack could market as a solution and besides which, that's what ODM's are for.  I'm sure we'll see just as much "buy and ally" with the build as part of this process. 

What's the difference between a blade chassis with intel line processors and integrated networking and a switch these days?  Not much.

So, what Cisco may lose in margin in the "server" sale, they will by far make up with the value people will pay for with converged compute, network, storage, virtualization, management, VN-Link, the Nexus 1000v, security and the integrated one-stop-shopping you'll get.  And if folks want to keep buying their HP's and IBM's, they have that choice, too.

QUACK!

/Hoff

Incomplete Thought: What Should Come First...Cloud Portability or Interoperability

It seems that my incomplete thoughts are more popular with folks than the one's I take the time to think all the way through and conclude, so here's the next one...

Here it is:

There is a lot of effort being spent now on attempts to craft standards and definitions in order to provide interfaces which allow discrete Cloud elements and providers to interoperate. Should we not first focus our efforts on ensuring portability between Clouds of our atomic instances (however you wish to define them) and the metastructure* that enables them?

/Hoff

*Within this context I mean 'metastructure' to define not only the infrastructure but all the semantic configuration information and dynamic telemetry needed to support such.

Dear Mr. Oberlin: Here's Your Sign...

No Good Deed Goes Unpunished...

I've had some fantastic conversations with folks over the last couple of weeks as we collaborated from the perspective of how a network and security professional might map/model/classify various elements of Cloud Computing.

I just spent several hours with folks at ShmooCon (a security conference) winding through the model with my peers getting excellent feedback.  

Prior to that, I've had many people say that the collaboration has yielded a much simpler view on what the Cloud means to them and how to align solutions sets they already have and find gaps with those they don't.

My goal was to share my thinking in a way which helps folks with a similar bent get a grasp on what this means to them.  I'm happy with the results.

And then....one day at Cloud Camp...

However, it seems I chose an unfortunate way of describing what I was doing in calling it a taxonomy/ontology, despite what I still feel is a clear definition of these words as they apply to the work.

I say unfortunate because I came across a post by Steve Oberlin, Cassat's Chief Scientist on his "Cloudology" blog titled "Cloud Burst" that resonates with me as the most acerbic, condescending and pompous contributions to nothingness I have read in a long time.

Steve took 9 paragraphs and 7,814 characters to basically say that he doesn't like people using the words taxonomy or ontology to describe efforts to discuss and model Cloud Computing and that we're all idiots and have provided nothing of use.

The most egregiously offensive comment was one of his last points:

I do think some blame (a mild chastisement) is owed to anyone participating in the cloud taxonomy conversation that is not exercising appropriately-high levels of skepticism and insisting on well-defined and valid standards in their frameworks.  Taxonomies are thought-shaping tools and bad tools make for bad thinking.   One commenter on one of the many blogs echoing/amplifying the taxonomy conversation remarked that some of the diagrams were mere “marketecture” and others warned against special interests warping the framework to suit their own ends.  We should all be such critical thinkers.

What exactly in any of my efforts (since I'm not speaking for anyone else) suggests that in collaborating and opening up the discussion for unfettered review and critique, constitutes anything other than high-levels of skepticism?  The reason I built the model in the first place was because I didn't feel the others accurately conveyed what was relevant and important from my perspective.  I was, gasp!, skeptical. 

We definitely don't want to have discussions that might "shape thought."  That would be dangerous.  Shall we start burning books too?

From the Department of I've Had My Digits Trampled..

So what I extracted from Oberlin's whine is that we are all to be chided because somehow only he possesses the yardstick against which critical thought can be measured?  I loved this bit as he reviewed my contribution:

I might find more constructive criticism to offer, but the dearth of description and discussion of what it really means (beyond the blog’s comments, which were apparently truncated by TypePad) make the diagram something of a Rorschach test.  Anyone discussing it may be revealing more about themselves than what the concepts suggested by the diagram might actually mean.

Interestingly, over 60 other people have stooped low enough to add their criticism and input without me "directing" their interpretation so as not to be constraining, but again, somehow this is a bad thing.

So after sentencing to death all those poor electrons that go into rendering his rant about how the rest of us are pissing into the wind, what did Oberlin do to actually help clarify Cloud Computing?  What wisdom did he impart to set us all straight?  How did he contribute to the community effort -- no matter how misdirected we may be -- to make sense of all this madness?

Let me be much more concise than the 7,814 characters Oberlin needed and sum it up in 8:

NOTHING.

So it is with an appropriate level of reciprocity that I thank him for it accordingly.

 /Hoff

P.S. Not to be outdone, William Vanbenepe has decided to bestow upon Oberlin a level of credibility not due to his credentials or his conclusions, but because (and I quote) "...[he] just love[s] sites that don't feel the need to use decorative pictures. His doesn't have a single image file which means that even if he didn't have superb credentials (which he does) he'd get my respect by default."

Yup, we bottom feeders who have to resort to images really are only in it for the decoration. Nice, jackass.

Update: The reason for the strikethrough above -- and my public apology here -- is that William contacted me and clarified he was not referring to me and my pretty drawings (my words,) although within context it appeared like he was.  I apologize, William and instead of simply deleting it, I am admitting my error, apologizing and hanging it out to dry for all to see.  William is not a jackass. As is readily apparent, I am however. ;)

Incomplete Thought: Support of IPv6 in Cloud Providers...

This is the first of my "incomplete thought" entries; thoughts too small for a really meaty blog post, but too big for Twitter.  OK wiseguy.  I know *most* of my thoughts are incomplete, but don't quash my artistic license, mkay?

Here it is:

How many of the cloud providers (IaaS, PaaS) support IPv6 natively or support tunneling without breaking things like NAT and firewalls?  As part of all this Infrastruture 2.0 chewy goodness, from a networking (and security) perspective, it's pretty important.

/Hoff

How I Know The Cloud Ain't Real...

You want to know how I know that The Cloud is all hot air and will never catch on?

...because I can't order it on Amazon.com and get free shipping with Prime.

FAIL!  FAIL, I say.

/Hoff

You Keep Calling Cloud Computing "Confusing, Over-Hyped & a Buzzword" & It Will Be...

A word of unsolicited advice to those of us trying to help "sort out" Cloud Computing -- myself included:

The more times we lead off a description of Cloud Computing as "Confusing," "Over-hyped" and "a Buzzword" then people are going to start to believe us.  The press is going to start to believe us.  Our customers are going to start to believe us.  Pretty soon we won't be able to escape the gravity of our own message.

Granted, we mean well in our cautious and guarded admonishment, but it's starting to wear as thin as those who promote Cloud Computing as the second coming (when we all know full well that is Fiber Channel over Token Ring.)

We don't all have to chant the same mantra and we don't have to preach rainbows and unicorns, but it's important to be accurate and balanced.

I, too, am waiting for the day Cloud Computing will wash my car, bring me a beer and make me a ham sandwich. Until that day, instead of standing around trying to look smart by telling everybody that Cloud Computing is nothing more than hot air, how about making a difference by not playing a game of bad news telephone and add something constructive.

There's value in Cloud Computing so how about we move past the "confusing, over-hyped and buzzword" stage and get to work making it straight-forward, realistic and meaningful instead.

/Hoff

Privacy Execs: Orange Jumpsuits In Your Future? Google's Privacy Counsel Criminally Charged

I find this case extremely fascinating on many levels.  From eWeek:

Italian officials charge Google Global Privacy Counsel Peter Fleischer* with criminal charges of defamation and failure to exercise control over personal data two years after Google posted a video depicting fellow students harassing a student with Down syndrome.

Unlike Italian Internet service providers, who are not responsible for posted content, content providers like Google can be held liable for delivered materials.

According to the International Association of Privacy Professionals, the charges are thought to be the first criminal sanction ever pursued against a privacy professional for his company's actions.

You can see the original story from the International Association of Privacy Professionals (IAPP) here.

The implications of this are quite profound as you can imagine.  CEO's and CFO's can be held accountable for crimes committed under their watch, so it's not too far of a stretch to see how privacy officers like Fleischer will have their feet held to the fire when subject to international law that takes a different perspective on the responsibilities associated with privacy than we might. 

How many indictments have we had in the U.S. for the release of information in corporate breaches?  The U.K.?

I'm not making a judgment call on this particular case because I certainly don't have all of the details, but it sets a very interseting precedent.

Imagine if you were a Chief Privacy Officer or perhaps a Chief Information Officer subject to this sort of scrutiny outside of the due care and stewardship requirements of the job in general.  If something bad happens, generally the worst thing that might occur is you lose your job.

Imagine if you were personally liable for the posting of content from millions of users globally and could be sentenced to share a shower and a cell with an angry Italian man who can't get a decent cappuccino.  I can't imagine what that would be like.

This may be the first time a privacy professional has been charged on behalf of the company he/she is employed by, but I will bet this won't be the last time it happens, either.

Besides the impact this can have on employees of providers of service, Google suggests it calls into focus larger issues of Net Neutrality:

Google issued a statement late Feb. 2 stressing the company's sympathy for the victim and his family, but insisted, "We feel that bringing this case to court is totally wrong. It's akin to prosecuting mail service employees for hate speech letters sent in the post. 

What's more, seeking to hold neutral platforms liable for content posted on them is a direct attack on a free, open Internet. We will continue to vigorously defend our employees in this prosecution."

An interesting argument for sure and one I can see being debated vigorously.  It's clear Google operates globally, so they must understand this sort of thing could happen.  What about Facebook (sorry, Chris) or MySpace?  What happens when Amazon is used to host data that is mishandled by someone.  What then?

Imagine what fun it's going to be when we're all cloudified and the mash-up frenzy makes the cross-pollenization of information today look orderly; who's responsible then?

What do you think?  Should privacy officers be liable for events like this?  Should CSO's/CISO's and Compliance Managers be liable when a breach occurs exposing protected information?  Think about that answer very carefully.

/Hoff

*You can find Peter Fleischer's blog here.

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

Here is some of the recent coverage from the last couple of months on topics relevant to content on my blog, presentations and speaking engagements.  No particular order or priority.

Press/Technology & Security eZines:

• Byte & Switch: Securing data wherever it travels
• CSO Online: Hoff - Commode Computing
• Computerworld & CSO Online:  Four questions on Google App Security 
• Dark Reading: Crossing the streams virtually 
• SearchSecurity: PCI needs to address virtualization, experts say
• CSO Online: The myth of Cloud Computing 
• CSO Online: Chris Hoff - On Virtualization and Cloud Computing 
• Computerworld: How can you secure a buzzword? 
• CSO: Security Predictions - What happens next? 
• ITWorld Canada: Security admins offer their risk management pitch

Website/Blog Coverage/Meaningful Links:

• Server Zone: Cloud Ontology - to boldly go where ITIL, Grid and SOA have gone before
• Virtualization.info: Top virtualization blogs of 2008 
• VMware-land: Top 10 Virtualization blogs 
• ebizQ: Naming the part of the cloud
• IT Management & Cloud Blog: And the 2009 Cloudie Award goes to...  
• C|Net Wisdom Of the Clouds: Two ontologies shed light on Cloud Computing 
• SeekingAlpha: Peak IT - The network industry's core challenge
• System Advancements at the Monastery: Recent Cloud Postings
• Meedabyte: Be open to winds of change 
• ZDNet: Will EDoS be the next DDoS?
• Data Center Knowledge: Cloudy Day: CloudSwitch, AWS Torrents, eDoS
• SoftSecurity.com: Will EDoS be the next DDoS?
• The GridPlace.com: In Cloud Computing, a good network gives you control
• RiskAnalys.is: Penetration testing not dead, probably just pining for the fjord
• SYS-CON: How difficult is securing Cloud platforms? Services in a Cloud Computing Environment 
• Data Center Networks (Cisco): Services in a Cloud Computing Environment
• Data Center Links: January Cloud Report
• Symantec Forums: How we win at securing customers in a virtual world
• VMBlog: The Future of virtualization
• Prism: Security - A casualty in the Sovereighnity vs Efficiency tradeoff
• Securosis: How the Cloud destroys everythng I love (about Web App Security)
• CloudAve: Cloud Computing Risks - EDoS
• Elastic Vapor: Cloud attack: Economic denial of sustainability (EDoS)
• Tripwire: Regulations need to get unreal
• Blog Of Trust: Be an IF-MAP Innovator
• DevCentral: The Context-Aware Cloud 
• Law.com: Old habits persist in virtual security 
• Brian Madden: What does Microsoft Azure have to do with us?
• Securosis: Everything old is new again in the fog of the cloud
• Securosis: Cloud Security macro layers
• Telematique: Clouds, the criminal element & V12N to the rescue
• Network Security Blog: PCI Compliance - get it in writing!
• Citrix Community Blog: Hoff is still confused 
• ZDNet: Security will suffer in the financial crisis

I should note that many of my cloud computing writing is being republished over at the SYSCON Cloud Computing Journal with a self-branded mini-site: ChristoferHoff.Sys-Con.com

Podcasts/Webcasts/Video:

• Network Security Podcast Episode 131: Co-hosted with Rich Mogull
• Briefings Direct: Improved insights and analysis from systems logs reduce complexity risks from virtualization
• Virtualization.com: Video interview with Simon Crosby, Citrix CTO (not in it, mentioned) 
• Cisco Data Center Blog: Data Center 3.0 anniversary note & new products video

I am confirmed to  speak at the following upcoming events:

• Source Boston  - Boston, MA - March 11-13
• TechTarget Threat Management Decisions Summit - New York, NY - March 26
• Americas Growth Capital InfoSec Conference (keynote) - San Francisco, CA, April 20
• RSA 2009 (multiple sessions) - San Francisco, CA, April 21-24
• Virtualization Congress - Las Vegas, NV, May 4-7
• (there are others being sorted at the moment) 

I should/will be attending the following events:

• Shmoocon
• Cloud Computing Expo   

/Hoff

Rational Security: This Site May Harm Your Computer (Damned Right It Will!)

HA!  Finally someone (Google) has recognized that my blog is harmful and not fit for either human or computational consumption:

Sweet!

/Hoff

Private Clouds: Your Definition Sucks

I think we have a failure to communicate...or at least I do.

Tonight I was listening to David Linthicum's podcast titled "The Harsh Realities Of Private Clouds" in which he referenced and lauded Dimitry Sotnikov's blog of the same titled "No Real Private Clouds Yet?"

I continue to scratch my head not because of David's statements that he's yet to find any "killer applications" for Private Clouds but rather the continued unappetizing use of the definition (quoting Dimitry) of a Private Cloud:

In a nutshell, private clouds are Amazon-like cost-effective and scalable infrastructures but run by companies themselves within their firewalls.

This seems to be inline with Gartner's view of Private Clouds also:

The future of corporate IT is in private clouds, flexible computing networks modeled after public providers such as Google and Amazon yet built and managed internally for each business's users

My issue is again that of the referenced location and perimeter.  It's like we've gone back to the 80's with our screened subnet architectural Maginot lines again!  "This is inside, that is outside." 

That makes absolutely zero sense given the ubiquity, mobility and transitivity of information and platforms today.  I understand the impetus to return back to the mainframe in the sky, but c'mon...

For me, I'd take a much more logical and measured approach to this definition. I think there's a step missing in the definitions above and how Private Clouds really ought to be described and transitioned to.

I think that the definitions above are too narrow end exculpatory in definition when you consider that you are omitting solutions like GoGrid's CloudCenter concepts -- extending your datacenter via VPN onto a cloud IaaS provider whose infrastructure is not yours, but offers you the parity in platform and support to your native datacenter.

In this scenario, the differentiator between the "public" and "private" is then simply a descriptor defining from whom and where the information and applications running on that cloud may be accessed:

From the "Internet" = Public Cloud.  From the "Intranet" (via a VPN connection between the internal datacenter and the "outsourced" infrastructure) = Private Cloud. 

Check out James Urquhart's thoughts along these lines in his post titled "The Argument For Private Clouds."

As I wrote in my post titled "Mixing Metaphors: Private Clouds Aren't Defined By Their Location":

Private clouds are about extending the enterprise to leverage infrastructure that makes use of cloud computing capabilities and is not (only) about internally locating the resources used to provide service.  It's also not an all-or-nothing proposition.

It occurs to me that private clouds make a ton of sense as an enabler to enterprises who want to take advantage of cloud computing for any of the oft-cited reasons, but are loathe to (or unable to) surrender their infrastructure and applications without sufficient control.

Private clouds mean that an enterprise can decide how and how much of the infrastructure can/should be maintained as a non-cloud operational concern versus how much can benefit from the cloud.

Private clouds make a ton of sense; they provide the economic benefits of outsourced scaleable infrastructure that does not require capital outlay, the needed control over that infrastructure combined with the ability to replicate existing topologies and platforms and ultimately the portability of applications and workflow.

These capabilities may eliminate the re-write and/or re-engineering of applications like is often required when moving to typical IaaS (infrastructure as a Service) player such as Amazon.

From a security perspective -- which is very much my focus -- private clouds provide me with a way of articulating and expressing the value of cloud computing while still enabling me to manage risk to an acceptable level as chartered by my mandate.

So why wouldn't a solution like GoGrid's CloudCenter offering paired with CohesiveFT's VPN Cubed and no direct "public" Internet originated access to my resources count as Private Cloud Computing?  

I get all the benefits of elasticity, utility billing, storage, etc., don't have to purchase the hardware, and I decide based upon risk what I am willing to yield to that infrastructure.

David brought up the notion of proprietary vendor lock-in, but yet we see GoGrid has also open sourced their CloudCenter API OpenSpec...

Clearly I'm mad because I simply don't see why folks are painting Private Clouds into a corner only to say that we're years away from recognizing their utility when in fact we have the technology, business need and capability to deliver them today.

/Hoff

Cloud Computing Taxonomy & Ontology :: Please Review

Updated: 2/10/09 10:07 EST - v1.4

There have been some excellent discussions of late regarding how to classify and explain the relationships between the many Cloud Computing models floating about.

I was inspired by John Willis' blog post this morning titled "Unified Ontology of Cloud Computing" in which he scraped together many ideas on the subject.

I'm building a number of presentations for discussing Cloud Security and I've also been working on how to show both the the taxonomy and ontology of various Cloud components and models.  I think it's really a blind mash-up of many of the things John points to, but the others I've seen don't serve my needs completely.  My goal is to gain consensus on the model and the explore each layer and its security requirements and impacts on the model as a whole.

Here's my first second third draft based on the awesome feedback I've received so far.

I'm not going to explain the layers/levels or groupings because I want people's reactions and feedback to what they get from the diagram without color from me first.  There will likely be things that aren't clear enough or even inaccuracies and missing elements.

If you could kindly give me your feedback on your first (unabashed) impressions, I'd really appreciate it.

Thanks!

NOTE: TypePad's comment subsystem is having problems.  I'm going to close the comments until it's resolved as the excellent (16 or so) comments are not showing up and I don't want people adding comments using the old system... Please send me comments via email (choff @ packetfilter.com or via Twitter @beaker) in the meantime.  Thanks SO much.

The comments are working again.  I've had 30-40 comments via email/twitter, so if something you wanted to communicate isn't addressed, fire away below in the comments!

Version 1.4 Diagram:

In v1.4 I added the API layer above 'Applications' in the SaaS grouping. I split out "data, metadata and content" as three separate elements and added structured/unstructured to the right.  I also separated the presentation layer into "modality and platform."  Added some examples of layers to the very right.

To do: Break out the uber-bubbles on the left, add more examples in the middle column.

 

The v1.3 diagram is here.

The v1.2 diagram is here.

The v1.1 diagram is here.

The original v1.0 diagram is here.  

Cloud Security Link Love: Monk Style...

John Gerber from the Syetem Advancements at the Monastery blog compiled an awesome round-up of Cloud related news/postings.

The blog entry covers many areas of the cloud including security, which I greatly appreciate.

Check it out here.  Well worth the read and the perspective.

/Hoff

PCI Security Standards Council to Form Virtualization SIG...

I'm happy to say that there appears to be some good news on the PCI DSS front with the promise of a SIG being formed this year for virtualization.  This is a good thing. 

You'll remember my calls for better guidance for both virtualization and ultimately cloud computing from the council given the proliferation of these technologies and the impact they will have on both security and compliance.

In that light, news comes from Troy Leach, technical director of the PCI Security Standards Council via a kind note to me from Michael Hoesing:

A PCI SSC Special Interest Group (SIG) for virtualization is most likely coming this year but we don't have any firm dates or objectives as of yet.  We will be soliciting feedback from our Participating Organizations which is comprised of more than 500 companies (which include Vmware, Microsoft, Dell, etc) as well as industry subject matter experts such as the 1,800+ security assessors that currently perform assessments as either a Qualified Security Assessor or Approved Scanning Vendor (ASV).

The PCI SSC Participating Organization program allows industry stakeholders an opportunity to provide feedback on all standards and supporting procedures.  Information to join as a Participating Organization can be found here on our website.

This is a good first step.  if you've got input, make sure to contribute!

/Hoff

A Couple Of Follow-Ups On The EDoS (Economic Denial Of Sustainability) Concept...

I wrote about the notion of EDoS (Economic Denial Of Sustainability) back in November.  You can find the original blog post here.

The basic premise of the concept was the following:

I had a thought about how the utility and agility of the cloud computing models such as Amazon AWS (EC2/S3) and the pricing models that go along with them can actually pose a very nasty risk to those who use the cloud to provide service.

That thought got me noodling about how the pay-as-you-go model could be used for nefarious means.

Specifically, this usage-based model potentially enables $evil_person who knows that a service is cloud-based to manipulate service usage billing in orders of magnitude that could be disguised easily as legitimate use of the service but drive costs to unmanageable levels. 

If you take Amazon's AWS usage-based pricing model (check out the cost calculator here,) one might envision that instead of worrying about a lack of resources, the elasticity of the cloud could actually provide a surplus of compute, network and storage utility that could be just as bad as a deficit.

Instead of worrying about Distributed Denial of Service (DDos) attacks from botnets and the like, imagine having to worry about delicately balancing forecasted need with capabilities like Cloudbursting to deal with a botnet designed to make seemingly legitimate requests for service to generate an economic denial of sustainability (EDoS) -- where the dyamicism of the infrastructure allows scaling of service beyond the economic means of the vendor to pay their cloud-based service bills.

At any rate, here are a couple of interesting related items:

1. Wei Yan, a threat researcher for Trend Micro, recently submitted an IEEE journal submission titled "Anti-Virus In-the-Cloud Service: Are We Ready for the Security Evolution?" in which he discusses and interesting concept for cloud-based AV and also cites/references my EDoS concept.  Thanks, Wei!
    
2. There is a tangential story making the rounds recently about how researcher Brett O'Connor has managed to harness Amazon's EC2 to harvest/host/seed BitTorrent files.
   
   The relevant quote from the story that relates to EDoS is really about the visibility (or lack thereof) as to how cloud networks in their abstraction are being used and how the costs associated with that use might impact the cloud providers themselves.  Remember, the providers have to pay for the infrastructure even if the "consumers" do not:
   
   "This means, says Hobson, that hackers and other interested parties can simply use a prepaid (and anonymous) debit card to pay the $75 a month fee to Amazon and harvest BitTorrent applications at high speed with little or no chance of detection...
   
   It's not clear that O'Connor's clever work-out represents anything new in principle, but it does raise the issue of how cloud computing providers plan to monitor and manage what their services are being used for."

It's likely we'll see additional topics that relate to EDoS soon.

UPDATE: Let me try and give a clear example that differentiates EDoS from DDoS in a cloud context, although ultimately the two concepts are related:

DDoS (and DoS for that matter) 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 $evil_doers.  Example: a 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 are death by 1000 cuts.  EDoS can also utilize distributed $evil_doers 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.  Example: a botnet is ativated to visit a website whose income results from ecommerce purchases.  The requests are all legitimate but the purchases never made.  The vendor has to pay the cloud provider for increased elastic use of resources where revenue was 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 busines logic is not present in most applications or stacks of applications and infrastructure to provide the correlation between "requests" and " successful transactions."  In the example above, increased requests may look like normal activity.

Given the attractiveness of startups and SME/SMB's to the cloud for cost and agility, this presents a problem  The SME/SMB customers do not generally invest in this sort of integration, the cloud computing platform providers generally do not have the intelligence and visibility into these applications which they do not own, and typical DDoS tools don't, either.

So DDoS and EDoS ultimately can end with the same outcome: the target whithers and ceases to be able to offer service, but I think that EDoS is something significant that should be discussed and investigated.

/Hoff