Rational Survivability

Cloud Computing Security: From DDoS (Distributed Denial Of Service) to EDoS (Economic Denial of Sustainability)

It's Thanksgiving here in the U.S., so in between baking, roasting and watching Risk Astley rickroll millions in the Macy's Thanksgiving Day Parade, 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 -- in between vigorous whisking during cranberry sauce construction -- 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.

Imagine the shock of realizing that the outsourcing to the cloud to reduce CapEx and move to an OpEx model just meant that while availability, confidentiality and integrity of your service and assets are solid, your sustainability and survivability are threatened.

I know there exists the ability to control instance sprawl and constrain costs, but imagine if this is managed improperly or inexactly because we can't distinguish between legitimate and targeted resource consumption from an "attack."

If you're in the business of ensuring availability of service for large events on the web for a timed event, are you really going to limit service when you think it might drive revenues?

I think this is where service governors will have to get much more intelligent regarding how services are being consumed and how that affects the transaction supply chain and embed logic that takes into account financial risk when scaling to ensure EDoS doesn't kill you. 

I can't say that I haven't had similar concerns when dealing with scalability and capacity planning in hosted or dedicated co-location environments, but generally storage and compute were not billable service options I had to worry about, only network bandwidth.

Back to the mashed potatoes.

/Hoff

The Big Four Cloud Computing Providers: Security Compared (Part I)

James Urquhart posted a summary a week or so ago of what he described as the "Big 4" players in Cloud Computing.  It was a slightly humorous pass at describing their approaches and offerings:

Below is a table that lists these key players, and compares their offerings from the perspective of four core defining aspects of clouds. As this is a comparison of apples to oranges to grapefruit to perhaps pastrami, it is not meant to be a ranking of the participants, nor a judgement of when to choose one over the other. Instead, what I hope to do here is to give a working sysadmin's glimpse into what these four clouds are about, and why they are each unique approaches to enterprise cloud computing in their own right.

James provided quite a bit more (serious) detail in the text below his table which I present to you here, tarted up with a column I've added and James left off titled "Security." 

It's written in the same spirit as James' original, so feel free to take this with an equally well-provisioned grain of NaCl.  I'll be adding my own perfunctory comments with a little more detail shortly: The point here is that the quantification of what "security" means in the cloud is as abstracted and varied as the platforms that provide the service.  We're essentially being asked to take for granted and trust that the underlying mechanicals are sound and secure while not knowing where or what they are.

We don't do that with our physically-tethered operating systems today, so why should we do so with virtualization platform hypervisors and the infrastructure "data center operating systems" of the cloud?  The transparency provided by dedicated infrastructure is being obscured by virtualization and the fog of the cloud.  It's a squeezing the balloon problem.

And so far as the argument goes toward suggesting that this is no different than what we deal with n terms of SaaS today, the difference between what we might define as legacy SaaS and "cloud" is that generally it's someone elses' apps and your data in the former (ye olde ASP model.) 

In the case of the "cloud," it could be a mixture of applications and data, some of which you own, some you don't and some you're simply not even aware of, perhaps running in part on your infrastructure and someone elses'.

It should be noted also that not all cloud providers (excluding those above) even own and operate the platforms they provide you service on...they, in turn, could be utilizing shared infrastructure to provide you service, so cross-pollination of service provisioning could affect portability, reliability and security.

That is why the Big4 above stand up their own multi-billion dollar data centers; they keep the architecture proprietary so you don't have to; lots of little clouds everywhere.

/Hoff

P.S. If you're involved with platform security from any of the providers above, do contact me because I'm going to be expounding upon the security "layers" of each of these providers in as much detail as I have here shortly.  I'd suggest you might be interested in assuring it's as complete and accurate as possible ;)

Cloud Providers Are Better At Securing Your Data Than You Are...

"Cloud Providers Are Better At Securing Your Data Than You Are..."

To some, this is a contentious point while to others it seems entirely logical.

I must tell you that I've witnessed this very assertion as it has been raised more times in the last few days than I can count.

Before I get into any more juicy bits regarding this topic, I wonder if you wouldn't mind popping over and reading a blog post I wrote in August, 2007 titled "On-Demand SaaS Vendors Able to Secure Assets Better than Customers?" 

Come to think of it, you can read the follow-on post to that one which clearly indicated my point when Salesforce.com and Monster.com (you know, those so-called "Cloud" providers) were breached.

Forgot about those breaches, did you?  Oh, that must have been because they were SaaS providers and not Cloud providers at the time.  Gotcha.

As you read these posts, first do so within the context of what we've come to know as software as a service (SaaS.)  Then kindly re-read it and substitute 'SaaS' with 'Cloud,' won't you?

Thanks.

I have more, but I'll wait till you're done.

/Hoff

PDP Says "The Cloud Is Not That Insecure" & Implies Security Concerns Are Trivial...

I haven't been whipped into this much of a frenzy since Hormel changed the labels on the SPAM cans in Hawaii.

PDP (of gnucitizen fame) masterfully stitched together a collection of mixed metaphors, generalizations, reductions to the ridiculous and pejoratives to produce his opus magnum on cloud computing (in)security titled "The Cloud Is Not That Insecure."

Oh.

Since I have spent the better part of my security career building large "cloud-like" services and the products that help, at a minimum, to secure them, I feel at least slightly qualified to dispute many of his points, the bulk of which are really focused on purely technology-driven mechanical analogies and platforms rather than items such as the operational, trust, political, jurisdictional, regulatory, organizational and economical issues that really go toward the "security" (or lack thereof) of "cloud-based" service.

Speaking of which, PDP's definition of the cloud is about as abstract as you can get:

"Cloud technologies are in fact no different than non-cloud technologies. Practically they are the same. I mean the term cloud computing is quite broad and perhaps it is even a buzword rather than a well-thought term which describes a particular study of the IT field. To me cloud computing refers to the process of outsourcing computer cycles and memory keeping scalability in mind."

Well, I'm glad we cleared that up.

At any rate, it's a seriously humorous read that would have me taking apart many of his contradictory assumptions and assertions were it not for the fact that I have actual work to do.  So, in the issue of time, I'll offer up his conclusion and you can go back and read the rest:

So, is the cloud secure? I would say yes if you know what you are doing. A couple of posts back I mentioned that cloud security matters. It still does. Cloud technologies are quite secure because we tend not to trust them. However, because cloud computing can be quite confusing, you still need to spend time in making sure that all the blocks fit together nicely.

So, there you have it.  Those of you who "know what you are doing" are otay and thanks to security by obscurity due to a lack of trust, cloud computing is secure.  That's not confusing at all...

This probably won't end well, but...

Sigh.

/Hoff

Disruption/Delay Tolerant Networking: To Proudly Ping Where No Man Has Pinged Before...

...'cos there ain't no clouds in outer space...

The fine folks at NASA, with notable contributors such as the Internet's baby-daddy Vint Cerf, have been bit twiddling a new communications protocol this month that has been in the works since 1998.  The "launch" of Delay/Disruption Tolerant Networking protocol is currently being field tested on the comet-seeking EPOXI spacecraft.

While TCP/IP has generally worked well beyond its initial design requirements as the terrestrial Internet has scaled unimaginably, it doesn't work so well in interplanetary deep space.

From the fine folks at Ars Technica:

This month, NASA began testing a new protocol for communications in outer space that could extend the reliability and versatility of the Internet out of the Earth's atmosphere. The new protocol, called Disruption-Tolerant Networking, or DTN, has been in the works for ten years, passed a month of testing with a just-launched spacecraft and nine ground stations, but is still scheduled to undergo further tests.
...
Communicating in interplanetary space is hard. While even the most remote regions of the earth can be reached by lightspeed communications in a modest fraction of a second, and voice conversations from the earth to the moon can be carried out with only a barely noticeable delay, several light minutes separate planets even at their closest approaches. Back-and-forth negotiation isn't feasible, and the cost of starting processes from scratch are high. Furthermore, disruptions of communication are numerous  and routine. Satellites and planetary probes have much less power when they're out of the sun, line of sight must be maintained, dishes properly aimed, etc. Solar flares and other environmental factors can shut communications channels unexpectedly.

Under the new DTN protocol, nodes retain data in their own memory until they receive confirmation the data has been received by a suitable target node. This increases the likelihood that data will arrive at its destination with a minimum of back-and-forth, communication even when communication is intermittent or unreliable. 

I wonder if it's IPv6 compatible?  After we assign a DTN/IP-Address to Internet-enable each celestial body, we'll be out of addresses again!

BTW, I happen to have access to a DTN-enabled uplink which proxy relays my TCP/IP to DTN through the EPOXI spacecraft.  Check out the round-trip times on this badboy:

Zeitgeist:~ choff$ ping jupiter.solarsystem.com
PING jupiter.solarsystem.com (10.0.0.1): 56 data bytes
64 bytes from 10.0.0.1: icmp_seq=0 ttl=252 time=1662.194 lightyears
64 bytes from 10.0.0.1: icmp_seq=1 ttl=252 time=109.738 lightyears
64 bytes from 10.0.0.1: icmp_seq=2 ttl=252 time=109.098 lightyears
64 bytes from 10.0.0.1: icmp_seq=3 ttl=252 time=109.165 lightyears
64 bytes from 10.0.0.1: icmp_seq=4 ttl=252 time=99.230 lightyears
64 bytes from 10.0.0.1: icmp_seq=5 ttl=252 time=101.702 lightyears
^C
--- jupiter.solarsystem.com ping statistics ---
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max/stddev = 99.230/365.188/1662.194/580.053 lightyears
Zeitgeist:~ choff$

I am interested in understanding if there are any additional security mechanisms built into DTN as it would be a shame if an advanced alien race could perform an interplanetary MITM on our transmissions: "...this is not the planet you are looking for..."

For the sake of humanity I hope so.  I'm going to go read the drafts.

Botnets?  Data leakage?  Clickjacking?  You think you've got problems, just think of the firewalls needed to protect against solar flares ;)*

/Hoff

Beware the Transparent Proxy...Your Faith In VPNs Might Waiver

Aviram from the Securiteam blog wrote a post titled "Who's Your SMTP Daddy?" that caught my eye regarding the false sense of security that use of corporate IPSec VPNs brings to traveling road warriors due to the use by providers of so-called transparent proxies.

Let's say that you've got some sort of IPSec VPN solution installed on your laptop using the standard corporate configuration with your mail client pointing to mail.foo.com.  Your machine has AV, HIPS, firewall, etc.

You connect to a provider's network (wired, wifi, hotel, airport, etc...) and fire up your VPN client which authenticates just fine.  You then launch your mail client and type a quick note to your CEO about the confidential M&A project you're working on.  A few minutes later you get a response from your CEO to proceed with the tender.

You disconnect.

Here's the problem: that SMTP session you thought was encrypted through your VPN back to the corporate mail server was actually sent in the clear.  In fact, it wasn't even sent through your mail relay/server.

Here's a great example of why taken from Aviram's blog:

A quick investigation shows the following: The hotel’s network blocks my VPN (as some of them do) but happily resolves any unresolvable host name (such as my SMTP server’s hostname). This is resolved to a catch-all server that proxies everything. Transparently. (well, almost)

Lesson learned. Changed the hostname to the IP, and will soon switch to SSL based SMTP who will authenticate the server. In the meanwhile - be careful from helpful Beijing wifi providers who are only too happy to forward your mail on! (with some changes, of course).

Aviram is in China, but this example is valid in many countries and you can probably expect that given the behavior of some domestic ISP's, Telcos and Mobile Operators that it is or will go on here too.  It could easily work with other protocols that aren't sensitive to session tampering/MITM.*  Further, Aviram's example was about interception.  There's every reason to believe that one could expect the content of your email to be modified also...

I personally use SSL authenticated SMTP with valid issued certificates so at least if there is tampering with my session, my mail client barfs letting me know something is wrong.  That error probably wouldn't help the average sales droid in the field as he/she would just click OK like most people do to any security error that pops up, but it's worth considering.

/Hoff

* Obviously this example presents a worst case scenario with certain configuration assumptions and license taken for illustration, but take the message for what it's intended: blind faith in VPNs can cause you some serious heartache.  Transparent proxies work very well...

Links for 2008-11-17 [No, I don't use de.licio.us]

Too many blogs and not enough time for full-blown analysis right now.  Will likely write about most of these if I can.  Here are some links to things I find very interesting:

• James Governor’s Monkchips » 15 Ways I Am Wrong About Enterprise Cloud Computing
  
• Greg Ness' Archimedus » The Beginning Of the End Of Static Infrastructure
• Jon Brodkin, Network World (US) » Private cloud networks predicted for corporate IT
  
• Dave Rosenberg, CNET » Gartner: Internal clouds are coming
• LynxSecure Embedded Hypervisor and Separation Kernel (EAL-7!)
• Storagezilla >> EMC's Atmos - Cloud Storage and ILM strategy
  
• David Marshall, Virtual Strategy >> [BlueLane/VMware]: The Rumor Is True, But Why the Secrecy?
• Eric Siebert, Virtual Strategy >> Top 10 things you must read about processors (CPUs) and virtualization
• Eric Siebert, Virtual Strategy >> Top 10 things you MUST read about virtualization and compliance
• Joel Hruska, Ars Technica: [Intel] Nehalem [Processor] by the numbers
• Virtualization.com Video: Interview Simon Crosby, CTO of XenSource - Citrix (VMworld 2008) part 1/2
• Virtualization.com Video: Interview Simon Crosby, CTO of XenSource - Citrix (VMworld 2008) part 2/2
• James Urquhart, Wisdom Of the Clouds >> A Quick Guide To The "Big Four" Cloud Offerings
• James Urquhart, Wisdom Of the Clouds >> In Cloud Computing, a Good Network Gives You Control...

Enjoy!

/Hoff

CohesiveFT VPN-Cubed: Not Your Daddy's Encrypted Tunnel

I had a  briefing with Patrick Kerpan and Craig Heimark of CohesiveFT last week in response to some comments that Craig had left on my blog post regarding PCI compliance in the Cloud, here. 

I was intrigued, albeit skeptically, with how CohesiveFT was positioning the use of VPNs within the cloud and differentiating their solution from the very well established IPSec and SSL VPN capabilities we all know and love.  What's so special about tunnels across the Intertubes?  Been there, done that, bought the T-Shirt, right?

So I asked the questions...

I have to say that unlike many other companies rushing to associate their brand by rubber cementing the word "cloud" and "security" onto their product names and marketing materials, CohesiveFT spent considerable time upfront describing what they do not do so as to effectively establish what they are and what they do.  I'll let one of their slides do the talking:

Okay, so they're not a cloud, but they provide cloud and virtualization services...and VPN-Cubed provides some layer of security along with their products and services...check. But...

Digging a little deeper, I still sought to understand why I couldn't just stand up an IPSec tunnel from my corporate datacenter to one or more cloud providers where my assets and data were hosted.  I asked for two things: (1) A couple of sentences summarizing their elevator pitch for VPN-Cubed and (2) a visual representation of what this might look like.

Here's what I got as an answer to question (1):

"VPN-Cubed is a novel implementation of VPN concepts which provides a customer controlled security perimeter within a third-party controlled (cloud, utility infra, hosting provider) computing facility, across multiple third-party controlled computing facilities, or for use in private infrastructure.  It enables customer control of their infrastructure topology by allowing control of the network addressing scheme, encrypted communications, and the use of what might normally be unrouteable protocols such as UDP Multicast."

Here are two great visuals to address question (2):

 

So the differences between a typical VPN and VPN-Cubed comes down to being able to securely extend your "internal clouds infrastructure" in your datacenters (gasp! I said it) in a highly-available manner to include your externally hosted assets which in turn run on infrastructure you don't own.  You can't stand up an ASA or Neoteris box on a network you can't get to.  The VPN-Cubed Managers are VM's/VA's that run as a complement to your virtual servers/machines hosted by your choice of one or multiple cloud providers.

They become the highly-available, multiprotocol aribters of access via standardized IPSec protocols but do so in a way that addresses the dynamic capabilities of the cloud which includes service governance, load, and "cloudbursting" failover between clouds -- in a transparent manner.

Essentially you get secure access to your critical assets utilizing an infrastructure independent solution, extending the VLAN segmentation, isolation and security capabilities your providers may put in place while also controlling your address spaces within the cloudspaces encompassing your VM's "behind" the VPN Managers.

VPN-Cubed is really a prime example of the collision space of dynamic application/service delivery, virtualization, security and cloud capacity governance.  It speaks a lot to re-perimeterization that I've been yapping about for quite some time and hints at Greg Ness' Infrastructure 2.0 meme.

Currently VPN-Cubed is bundled as a package which includes both product and services and supports the majority of market-leading virtualization formats, operating systems and cloud providers such as Amazon EC2, Flexiscale, GoGrid, Mosso, etc.

It's a very slick offering.

/Hoff

BeanSec! Wednesday, November 19th, 2008 - 6PM to ?

Yo!  BeanSec! is once again upon us.  Wednesday, November 19th, 2008. 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.

This week we have a special guest attendee from the UK/France/Hungary*: Craig Balding - Security Pro and Cloud Security Blogger (www.cloudsecurity.org)

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.

In case you're wondering, we're getting about 30 people on average per BeanSec! Weld, 0Day and I have been at this for just almost 2 years and without actually *doing* anything, it's turned out swell.

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. I'll generally annoy you into participating somehow, even if it's just fetching napkins. ;)

See you there.

/Hoff, /0Day, and /Weld

*The "France" thing was a joke but my strikethrough formatting didn't come out right...you can tell it worked by Craig's comments below ;)

Cloud Security Macro Layers? I'll Take "It'll Never Sell" For $1000, Alex...

Mogull commented yesterday on my post regarding TCG's IF-MAP and remarked that in discussing cloud security and security models, the majority of folks, myself included, were focusing on the network:

Chris’s posting, and most of the ones I’ve seen, are heavily focused on network security concepts as they relate to the cloud. But if we look at cloud computing at the macro level, there are additional layers which are just as critical (in no particular order):

• Network: The usual network security controls.
• Service: Security around the exposed APIs and services.
• User: Authentication- which in the cloud world, needs to move to more adaptive authentication, rather than our current static username/password model.
• Transaction: Security controls around individual transactions- via transaction authentication, adaptive authorization, and other approaches.
• Data: Information-centric security controls for cloud based data. How’s that for buzzword bingo? Okay, this actually includes security controls for the back-end data, distributed data, and any content exchanged with the user.

I'd say that's a reasonable assertion and a valid set of additional "layers."  There also not especially unique and as such, I think Rich is himself a little disoriented by the fog of the cloud because as you'll read, the same could be said of any networked technology.

The reason we start with the network and usually find ourselves back where we started in this discussion is because the other stuff Rich mentions is just too damned hard, costs too much, is difficult to sell, isn't standardized, is generally platform dependent and is really intrusive.  See this post (Security Will Not End Up In the Network) as an example.

Need proof of how good ideas like this get mangled?  How about Web 2.0 or SOA which is for lack of a better description, exactly what RIch described in his model above; loosely coupled functional components of a modular architecture. 

We haven't even gotten close to having this solved internally on our firewalled enterprise LANs so it's somewhat apparent why it might appear to be missing in conversations regarding "the cloud."  It shouldn't be, but it is. 

It should be noted, however that there is a ton of work, solutions and initiatives that exist and continue to be worked on these topics, it's just not a priority as is evidenced by how people exercise their wallets.

And finally:

Down the road we’ll dig into these in more detail, but any time we start distributing services and functionality over an open public network with no inherent security controls, we need to focus on the design issues and reduce design flaws as early as possible. We can’t just look at this as a network problem- our authentication, authorization, information, and service (layer 7) controls are likely even more important.

I believe we call this thing of which he speaks, "the Internet."  I think we're about 20 years late. ;)

/Hoff

When The Carrot Doesn't Work, Try a Stick: VMware Joins PCI SSC...

I've made no secret of my displeasure with the PCI Security Standards Council's lack of initiative when it comes to addressing the challenges and issues associated with virtualization and PCI compliance*. 

My last post on the topic  brought to light an even more extreme example of the evolution of virtualization's mainstream adoption and focused on the implications that cloud computing brings to bear when addressing the PCI DSS.

I was disheartened to find that upon inquiring as to status of the formation of and participation in a virtualization-specific special interest group (SIG,) the SSC's email response to me was as follows:

On Oct 29, 2008, at 1:24 PM, PCI Participation wrote:

Hello Christofer,

Thank you for contacting the PCI Security Standards Council. At this
time, there is currently no Virtualization SIG. The current SIGs are
Pre-Authorization and Wireless.

Please let us know if you are interested in either of those groups.

Regards,
The PCI Security Standards Council

-----Original Message-----
From: Christofer Hoff [mailto:[email protected]]
Sent: Wednesday, October 29, 2008 12:58 PM
To: PCI Participation
Subject: Participation in the PCI DSS Virtualization SIG?

How does one get involved in the PCI DSS Virtualization SIG?

Thanks,

Christofer Hoff

The follow-on email to that said there were no firm plans to form a virtualization SIG. <SIGh>

So assuming that was the carrot approach, I'm happy to see that VMware has taken the route that only money, influence and business necessity can bring: the virtualization vendor 'stick.'  To wit (and a head-nod to David Marshall:)

VMware is Joining PCI Security Standards Council as Participating Organization

VMware, the global leader in virtualization solutions from the desktop to the datacenter, announced today that it is joining the PCI Security Standards Council. As a participating organization, VMware will work with the council to evolve the PCI Data Security Standard (DSS) and other payment card data protection standards. This will help those VMware customers in the retail industry who are required to meet these standards to remain compliant while leveraging VMware virtualization. VMware has also launched the VMware Compliance Center Web site, an initiative to help educate merchants and auditors about how to achieve, maintain and demonstrate compliance in virtual environments to meet a number of industry standards, including the PCI DSS.

As a participating organization, VMware will now have access to the latest payment card security standards from the council, be able to provide feedback on the standards and become part of a growing community that now includes more than 500 organizations. In an era of increasingly sophisticated attacks on systems, adhering to the PCI DSS represents a significant aspect of an entity’s protection against data criminals. By joining as a participating organization, VMware is adding its voice to the process.

“The PCI Security Standards Council is committed to helping everyone involved in the payment chain protect consumer payment data,” said Bob Russo, general manager of the PCI Security Standards Council. “By participating in the standards setting process, VMware demonstrates it is playing an active part in this important end goal.”

Let's see if this leads to the formation of a virtualization SIG or at least a timetable for when the DSS will be updated with virtualization-specific guidelines.   I'd like to see other virtualization vendors also become participating organizations in the PCI SSC.

/Hoff

* Here are a couple of my other posts on PCI compliance and virtualization:

• All Your Virtualized PCI Compliance Are Belong To Us
• Risky Business -- The Next Audit Cycle: Bellweather Test for Critical Production Virtualized Infrastructure

I Can Haz TCG IF-MAP Support In Your Security Product, Please...

In my previous post titled "Cloud Computing: Invented By Criminals, Secured By ???" I described the need for a new security model, methodology and set of technologies in the virtualized and cloud computing realms built to deal with the dynamic and distributed nature of evolving computing:

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.

Greg Ness from Infoblox reminded me in the comments of that post of something I was very excited about when it became news at InterOp this last April: the Trusted Computing Group's (TCG) extension to the Trusted Network Connect (TNC) architecture called IF-MAP.

IF-MAP is a standardized real-time publish/subscribe/search mechanism which utilizies a client/server, XML-based SOAP protocol to provide information about network security objects and events including their state and activity:

IF-MAP extends the TNC architecture to support standardized, dynamic data interchange among a wide variety of networking and security components, enabling customers to implement multi-vendor systems that provide coordinated defense-in-depth.
 
Today’s security systems – such as firewalls, intrusion detection and prevention systems, endpoint security systems, data leak protection systems, etc. – operate as “silos” with little or no ability to “see” what other systems are seeing or to share their understanding of network and device behavior. 

This limits their ability to support coordinated defense-in-depth.  In addition, current NAC solutions are focused mainly on controlling network access, and lack the ability to respond in real-time to post-admission changes in security posture or to provide visibility and access control enforcement for unmanaged endpoints.  By extending TNC with IF-MAP, the TCG is providing a standard-based means to address these issues and thereby enable more powerful, flexible, open network security systems.

While the TNC was initially designed to support NAC solutions, extending the capabilities to any security product to subscribe to a common telemetry and information exchange/integration protocol is a fantastic idea.

I'm really interested in how many vendors outside of the NAC space are including IF-MAP in their roadmaps. While IF-MAP has potential in convential non-virtualized infrastructure, I see a tremendous need for it in our move to Infrastructure 2.0 with virtualization and Cloud Computing. 

Integrating, for example, IF-MAP with VM-Introspection capabilities (in VMsafe, XenAccess, etc.) would be fantastic as you could tie the control planes of the hypervisors, management infrastructure, and provisioning/governance engines with that of security and compliance in near-time.

You can read more about the TCG's TNC IF-MAP specification here.

/Hoff

 

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:

I hate to tell you this, it wasn't Amazon, IBM or even Sun who invented 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:

In this new world order, cloud computing will not just be a requirement for scaling your data center but also protecting it.

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