In a nutshell, private clouds are Amazon-like cost-effective and scalable infrastructures but run by companies themselves within their firewalls.
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.
NOTE: Please see the continued discussion in the post titled “Update on the Cloud (Ontology/Taxonomy) Model…“
Updated: 3/28/09 v1.5
There have been some excellent discussions of late regarding how to classify and explain the relationships between the many Cloud Computing models floating about.
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!
In v1.5 I highlighted the Integration/Middleware layer in a separate color, removed Coghead from the PaaS offering example and made a few other cosmetic alignment changes.
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.
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.
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:
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!
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.
thought got me noodling about how the pay-as-you-go model could
be used for nefarious means.
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.
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
At any rate, here are a couple of interesting related items:
- 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!
- 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
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.
- I always looked at these discussions of Infrastructure 2.0 as ideation/marketing by vendors on how to take products that used to function in the "Infratructure 1.0" dominion, add a service control plane/channel and adapt them for the inside-out version of the new world order that is cloud. This is the same sort of thing we've dealt with for decades and was highlighted when one day we all discovered the Internet and had to connect to it — although in that case we had standards!
- Clouds are often discussed in either microcosmic vacuum or lofty, fluffy immensity and it makes it hard to see the stratosphere for the cirrocumulus. Our "non-cloud" internal enterprises today are conglomerates of technology integration with pockets of core services which provide the underpinnings for much of what keeps the machinery running. Cloud computing is similar in approach, but in this regard, it brings home again the point that there is no such thing as "THE Cloud" but rather that the overarching integration challenge lays in the notion of overlays or mash-ups of multiple clouds, their functions, and their associated platforms and API's.
- Further, and as to my last blog post on private clouds and location independence, I really do believe that the notion of internal versus external clouds is moot, but that the definitional nuance of public versus private clouds — and their requisite control requirements — are quite important. Where, why, how and by whom services are provided becomes challenging because the distinction between inside and out can be really, really fuzzy, even more so if you're entirely cloud based in the first place.
That being said, I've used outsourced "cloud-based" email filtering, vulnerability management, intrusion detection & prevention services, etc., but there are still some functions that for some reason appear to sacrosanct in the recesses of my mind?
A model that makes sense to me is that of GoGrid's "CloudCenter" concept which I'll review under separate cover; there's definitely some creative marketing going on when discussing the blending of traditional co-location capabilities and the dynamic scalability and on-demand usage/billing of the cloud, but we'll weed through this soon enough.
many of them are completely unafraid, however, to make complete idiots of themselves and rock out to the
same musical arrangements in front of total strangers because instead of "karaoke" it's
called "Guitar Hero" and runs on an XBox in the living room rather
than the "Tiki Room" on Wednesday nights?
With all the definitions of the Cloud and the vagaries associated with differentiated value propositions of each, folks have begun to use the phrases "jumping the shark" and "Cloud Computing" in the same breath.
For the sake of argument, if we boil down what Cloud Computing means in simpler and more familiar terms and agree to use rPath's definition (from Cloud Computing in Plain English) as an oversimplified example we get:
Virtualization: Where applications are separated from infrastructure
Utility Computing: Server Capacity is accessed across a a grid as a variably priced shared service
SaaS: Applications are available on-demand on a subscription basis
Again, overly-simplified example notwithstanding, what's interesting to me — and the reason for the goofy title and metaphor associated with this post — is that with the popularity of "Cloud" becoming the umbrella terminology for the application of proven concepts (above) which harness technology and approaches we already have, we're basically re-branding a framework of existing capabilities and looking to integrate them better.
…oh, and make a buck, too.
That's not to diminsh the impact and even value of the macro-trends associated with Cloud such as re-perimeterization, outsourcing, taking cost of the business, economies of scale, etc., it's just a much more marketable way of describing them.
The cloud: a cooler version of Internet karaoke…
*Image of Triston McIntyre from ITKnowledgeExchange
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. 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.
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. I'll generally annoy you into
participating somehow, even if it's just fetching napkins.
Previously I had gracious sponsorship that allowed me to pick up the tab during BeanSec! but the prevailing economic conditions makes that not possible at this time. If you or your company would like to offer to sponsor this excellent networking and knowledge base, please get in contact with me [choff @ packetfilter . com]
See you there.
/Hoff, /0Day, and /Weld