Cloud Computing: Invented By Criminals, Secured By ???
I was reading Reuven Cohen's "Elastic Vapor: Life In the Cloud Blog" yesterday and he wrote an interesting piece on what is being coined "Fraud as a Service." Basically, Reuven describes the rise of botnets as the origin of "cloud" based service utilities as chronicled from Uri Rivner's talk at RSA Europe:
cloud computing. It was criminal technologists, mostly from eastern
Europe who did. Looking back to the late 90's and the use of
decentralized "warez" darknets. These original private "clouds" are the
first true cloud computing infrastructures seen in the wild. Even way
back then the criminal syndicates had developed "service oriented
architectures" and federated id systems including advanced encryption.
It has taken more then 10 years before we actually started to see this
type of sophisticated decentralization to start being adopted by
traditional enterprises.
The one sentence that really clicked for me was the following:
Amen.
One of the obvious benefits of cloud computing is the distribution of applications, services and information. The natural by-product of this is additional resiliency from operational downtime caused by error or malicious activity.
This benefit is a also a forcing function; it will require new security methodologies and technology to allow the security (policies) to travel with the applications and data as well as enforce it.
I wrote about this concept back in 2007 as part of my predictions for 2008 and highlighted it again in a post titled: "Thinning the Herd and Chlorinating the Malware Gene Pool" based on some posts by Andy Jaquith:
Grid and distributed utility computing models will start to creep into security
A
really interesting by-product of the "cloud compute" model is that as
data, storage, networking, processing, etc. get distributed, so shall
security. In the grid model, one doesn't care where the actions take
place so long as service levels are met and the experiential and
business requirements are delivered. Security should be thought of in
exactly the same way.The notion that you can point to a
physical box and say it performs function 'X' is so last Tuesday.
Virtualization already tells us this. So, imagine if your security
processing isn't performed by a monolithic appliance but instead is
contributed to in a self-organizing fashion wherein the entire
ecosystem (network, hosts, platforms, etc.) all contribute in the
identification of threats and vulnerabilities as well as function to
contain, quarantine and remediate policy exceptions.Sort
of sounds like that "self-defending network" schpiel, but not focused
on the network and with common telemetry and distributed processing of
the problem.
Check out Red Lambda's cGrid technology for an interesting view of this model.
This
basically means that we should distribute the sampling, detection and
prevention functions across the entire networked ecosystem, not just to
dedicated security appliances; each of the end nodes should communicate
using a standard signaling and telemetry protocol so that common
threat, vulnerability and effective disposition can be communicated up
and downstream to one another and one or more management facilities.
It will be interesting to watch companies, established and emerging, grapple with this new world.
/Hoff
It's amazing how many people think that cloud security will just take care of itself or is the responsibility of the cloud provider. Sticking your head in the sand isn't the answer. Btw, Thanks for the link.
Clouds, the Criminal Element and V12N to the Rescue
What you're describing amounts to blind faith at this point. Until service providers "open the kimono" we'll have no way to verify compliance. See your own thoughts on PCI in the cloud as evidence that we're not even close to the point where we can rely on "the cloud" as defined by Amazon, et al.
In no particular order, I need:
*Encryption
*Federation
*Verification of compliance with federal and state laws/regulations, including federal telecommunications regulation and recent state privacy laws
*Verification of compliance with PCI (what my bank wants, not what your QSA says is acceptable because you're using the compensating control of the month)
*Architecture that will work with whatever technology I decide to use (don't lock me in to Microsoft ala Azure)
Until service providers can give me what I need I'll continue building my own cloud. Sure it's expensive, but it has what I need to be secure (not just feel secure).
-Dryden
Thanks Chris – This inspired me to post something on distributed intelligence… http://techbuddha.wordpress.com/2008/11/03/cloud-…
Chris:
I think your vision of infratsructure that stays connected to applications (in order to enforce "location-anywhere" security policies will require connectivity intelligence and automation.
I'm still wondering how a cloudplex of blades can really scale, when their are considerable manual labor (tuning, managing IP addresses/domains and so on)components. Ture, hypervisors automate much of the server infrastructure practices… but the network is still static…
Thx
Greg
@Greg: Welcome to my world. The automation, governance, provisioning adaptation, re-purposing and orchestration make up exactly the problem space that RTI (real time infrastructure) solves.
It doesn't require virtualization, either…we're talking being able to bare-metal re-purpose infrastructure (that can be) without hypervisors present.
Now, if I can get the policy affinity, portability, and rich set of API's in the security space working (not holding breath) it will be even more fun — and achievable.
The security functionality described above is still nascent, the rest of what you describe, doable.
This is exactly my day job, btw.
/Hoff
"This benefit is a also a forcing function; it will require new security methodologies and technology to allow the security (policies) to travel with the applications and data as well as enforce it."
How refreshing to see this comment; unfortunately, in spite of the correctness of the statement, it is an important (perhaps essential) aspect that seems to have eluded most commentators and industry 'experts', as well as those hoping to sell such services.
Chris:
Have you checked out IF-MAP? Here is a link to some info at the Infoblox site: http://www.infoblox.com/solutions/pdf/IFMAP-tutor…
Keep your day job! I think you'll see a ton of breakthroughs in app, endpoint and infrastructure intelligence as connectivity intelligence and automation take hold. You should also take a look at the FIRE conference in San Diego for a panel on infrastructure 2.0 with Cisco, F5, Infoblox and a fe wothers participating. Should be quite interesting. San Diego in May…
FYI
G
In theory VMware's VMsafe technology is a step towards the goal of allowing "security policies to travel with the applications and data as well as enforce it." VMware claims that VMsafe will enable "stateful security" that travels with the VM from host to host via VMotion. Not sure how that one will pan out though as VMsafe is little more than a security API.
@Rick:
Not so much…VMsafe (vNetworking) will certainly be an enabler for applying policy as elements move, but it doesn't get to the heart of what I'm referring to, specifically that the policies that define the security profiles which in turn dictate the configuration and controls needed to protect the assets contained within the VM do not travel with the VM.
When I say "travel with the VM," I mean that the "service contracts" maintain affinity with the VM as part of the OVF definition and are not dependent upon the management console for definition. THis way, no matter where the VM goes or what VMM it runs atop of, the policy definitions are always there.
VMsafe as part of vNetworking entails a lot more than just an API; it's a wholesale architectural change in the way in which networking and security interoperate with each other and ISV software. It's not a panacea, but VM introspection across the 4 domains is NOT trivial.
I've written extensively about VMsafe/vNetworking. It's a step in the right direction, but it's only one piece of the puzzle…and it doesn't do anything for non-VMware environments which is why I want to see the policy definitions as part of an open standard.
/Hoff