Rational Survivability

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

It's Virtualization March Madness! Up First, Montego Networks

If you want to read about Montego Networks right off the bat, you can skip the Hoff-Tax and scroll down to the horizontal rule and start reading.  Though I'll be horribly offended, I'll understand...

I like being contradictory, even when it appears that I'm contradicting myself.  I like to think of it as giving a balanced perspective on my schizophrenic self...

You will likely recall that my latest post suggested that the real challenge for virtualization at this stage in the game is organizational and operational and not technical. 

Well, within the context of this post, that's obviously half right, but it's an incredibly overlooked fact that is causing distress in most organizations, and it's something that technology -- as a symptom of the human condition -- cannot remedy.

But back to the Tech.

The reality is that for reasons I've spoken of many times, our favorite ISV's have been a little handicapped by what the virtualization platforms offer up in terms of proper integration against which we can gain purchase from a security perspective.  They have to sell what they've got while trying to remain relevant all the while watching the ground drop out beneath them.

These vendors have a choice: employ some fancy marketing messaging to make it appear as though the same products you run on a $50,000+ dedicated security appliance will actually perform just as well in a virtual form.

Further, tell you that you'll enjoy just as much visibility without disclosing limitations when interfaced to a virtual switch that makes it next to impossible to replicate most complex non-virtualized topologies. 

Or, just wait it out and see what happens hoping to sell more appliances in the meantime.

Some employ all three strategies (with a fourth being a little bit of hope.)

Some of that hoping is over and is on it's way to being remedied with enablers like VMware's VMsafe initiative.  It's a shame that we'll probably end up with a battle of API's with ISV's having to choose which virtualization platform providers' API to support rather than a standard across multiple platforms.

Simon Crosby from Xen/Citrix made a similar comment in this article:

Officials at VMware-rival Citrix Systems said they agreed that partnerships between security vendors and virtualization tool providers are the way to go—as long as everyone is on the same page. The objective is to work together with security vendors and allow them to do their jobs across all virtualization platforms, said Simon Crosby, chief technology officer of the Virtualization and Management Division at Citrix.

“I would like VMware to invite [Citrix] and Microsoft to that forum … so that there’s a common set of APIs [that security vendors] can use to inspect against traffic, inspect against memory and evoke security policy,” Crosby said. “I think that’s an important thing to do. I don’t see any point in trying to force vendors to retool for a different hypervisor.”

While I totally agree with his sentiment, I'm not sure Simon would be as vocal or egalitarian had Citrix been first out of the gate with their own VMsafe equivalent.  It's always sad when one must plead for standardization when you're not in control of the standards...and by the way, Simon, nobody held a gun to the heads of the 20 companies that rushed for the opportunity to be the first out of the gate with VMsafe as it's made available.

While that band marches on, some additional measure of aid may come from innovative youngbloods looking to build and sell you the next better mousetrap.

---

As such, in advance of the RSA Conference in a couple of weeks, the security world's all aflutter with the sounds of start-ups being born out of stealth as well as new-fangled innovation clawing its way out of up-starts seeking to establish a beachhead in the attack on your budget.

With the normal blitzkrieg of press releases that will undoubtedly make their way to your doorstop, I thought I'd comment on a couple of these companies in advance of the noise.

A lot of what I want to say is sadly under embargo, but I'll get further in-depth later when I'm told I can take the wraps off.  You should know that almost all of these emerging solutions, as with the one below, operate as virtual appliances inside your hosts and require close and careful configuration of the virtual networking elements therein.

If you go back to the meat of the organization/operational issue I describe above, who do you think has access and control over the virtual switch configurations?  The network team?  The security team?  How about the virtual server admin. team...are you concerned yet?

Here's my first Virtualized March Madness (VMM, get it!) ISV:

• Montego Networks - John Peterson used to be the CTO at Reflex, so he knows a thing or two about switching, virtualization and security.  I very much like Montego's approach to solving some of the networking issues associated with vSwitch integration and better yet, they've created a very interesting business model that actually is something like VMsafe in reverse. 
  
  Essentially Montego's HyperSwitch works in conjunction with the integrated vSwitch in the VMM and uses some reasonably elegant networking functionality to classify traffic and either enforce dispositions natively using their own "firewall" technologies (L2-L4) or -- and this is the best part -- redirect traffic to other named security software partners to effect disposition. 
  
  If you look on Montego's website, you'll see that they show StillSecure and BlueLane as candidates as what they call HyperVSecurity partners.  They also do some really cool stuff with Netflow.
  
  Neat model.  When VMsafe is available, Montego should then allow these other third party ISV's to take advantage of VMsafe (by virtue of the HyperSwitch) without the ISV's having to actually modify their code to do so - Montego will build that to suit.  There's a bunch of other stuff that I will write about once the embargo is lifted.
  
  I'm not sure how much runway and strategic differentiation Montego will have from a purely technical perspective as VMsafe ought to level the playing field for some of the networking functionality with competitors, but the policy partnering is a cool idea. 
  
  We'll have to see what the performance implications are given the virtual appliance model Montego (and everyone else) has employed.  There's lots of software in them thar hills doing the flow/packet processing and enacting dispositions...and remember, that's all virtualized too.
  
  In the long term, I expect we'll see some of this functionality appear natively in other virtualization platforms.
  
  We'll see how well that prediction works out over time as well as keep an eye out for that Cisco virtual switch we've all been waiting for...*

I'll be shortly talking about Altor Networks and Blue Lane's latest goodies.

If you've got a mousetrap you'd like to see in lights here, feel free to ping me, tell me why I should care, and we'll explore your offering.  I guarantee that if it passes the sniff test here it will likely mean someone else will want a whiff.

/Hoff

* Update: Alan over at the Virtual Data Center Blog did a nice write-up on his impressions and asks why this functionality isn't in the vSwitch natively.  I'd pile onto that query, too.  Also, I sort of burned myself by speaking to Montego because the details of how they do what they do is under embargo based on my conversation for a little while longer, so I can't respond to Alan...

VMWare's VMSafe: Security Industry Defibrilator....Making Dying Muscle Twitch Again.

Nurse, 10 cc's of Adrenalin, stat!

As I mentioned in a prior posting, VMware's VMsafe has the potential to inject life back into the atrophied and withering heart muscle of the security industry and raise the prognosis from DOA to the potential for a vital economic revenue stream once more.

How?  Well, the answer to this question really comes down to whether you believe that keeping a body on assisted life support means that the patient is living or simply alive, and the same perspective goes for the security industry.

With the inevitable consolidation of solutions and offerings in the security industry over the last few years, we have seen the commoditization of many markets as well as the natural emergence of others in response to the ebb and flow of economic, technological, cultural and political forces.

One of the most impacting disruptive and innovative forces that is causing arrhythmia in the pulse of both consumers and providers and driving the emergence of new market opportunities is virtualization. 

For the last two years, I've been waving my hands about the fact that virtualization changes everything across the information lifecycle.  From cradle to grave, the evolution of virtualization will profoundly change what, where, why and how we do what we do.

I'm not claiming that I'm the only one, but it was sure lonely from a general security practitioner's perspective up until about six months ago.  In the last four months, I've given two keynotes and three decently visible talks on VirtSec, and I have 3-4 more tee'd up over the next 3 months, so somebody's interested...better late than never, I suppose.

How's the patient?

For the purpose of this post, I'm going to focus on the security implications of virtualization and simply summarize by suggesting that virtualization up until now has quietly marked a tipping point where we see the disruption stretch security architectures and technologies to their breaking point and in many cases make much of our invested security portfolio redundant and irrelevant.

I've discussed why and how this is the case in numerous posts and presentations, but it's clear (now) to most that the security industry has been clearly out of phase with what has plainly been a well-signaled (r)evolution in computing.

Is anyone really surprised that we are caught flat-footed again?  Sorry to rant, but...

This is such a sorry indicator of why things are so terribly broken with "IT/Information Security" as it stands today; we continue to try and solve short term problems with even shorter term "solutions" that do nothing more than perpetuate the problem -- and we do so in a horrific display of myopic dissonance, it's a wonder we function at all.   Actually, it's a perfectly wonderful explanation as to why criminals are always 5 steps ahead -- they plan strategically while acting tactically against their objectives and aren't afraid to respond to the customers proactively.

So, we've got this fantastic technological, economic, and cultural transformation occurring over the last FIVE YEARS (at least,) and the best we've seen as a response from most traditional security vendors is that they have simply marketed their solutions slimly as "virtualization ready" or "virtualization aware" when in fact, these are simply hollow words for how to make their existing "square" products fit into the "round" holes of a problem space that virtualization exposes and creates.

Firewalls, IDS/IPSs, UTM, NAC, DLP -- all of them have limited visibility in this rapidly "re-perimeterized" universe in which our technology operates, and in most cases we're busy looking at uninteresting and practically non-actionable things anyway.  As one of my favorite mentors used to say, "we're data rich, but information poor."

The vendors in these example markets -- with or without admission -- are all really worried about what virtualization will do to their already shrinking relevance.  So we wait.

Doctor, it hurts when I do this...

VMSafe represents a huge opportunity for these vendors to claw their way back to life, making their solutions relevant once more, and perhaps even more so.

Most of the companies who have so far signed on to VMsafe will, as I mentioned previously, need to align roadmaps and release new or modified versions of their product lines to work with the new API's and management planes. 

This is obviously a big deal, but one that is unavoidable for these companies -- most of which are clumbsy and generally not agile or responsive to third parties.  However, you don't get 20 of some of the biggest "monoliths" of the security world scrambling to sign up for a program like VMsafe just for giggles -- and the reality is that the platform version of VMware's virtualization products that will support this technology aren't even available yet.

I am willing to wager that you will, in extremely short time given VMware's willingness to sign on new partners, see many more vendors flock to the program.  I further maintain that despite their vehement denial, NAC vendors (with pressure already from the oncoming tidal wave of Microsoft's NAP) will also adapt their wares to take advantage of this technology for reasons I've outlined here.

They literally cannot afford not to.

I am extremely interested in what other virtualization vendors' responses will be -- especially Citrix.  It's pretty clear what Microsoft has in mind.  It's going to further open up opportunities for networking vendors such as Cisco, f5, etc., and we're going to see the operational, technical, administrative, "security" and governance lines  blur even further.

Welcome back from the dead, security vendors, you've got a second chance in life.  I'm not sure it's warranted, but it's "natural" even though we're going to end up with a very interesting Frankenstein of a "solution" over the long term.

The Doctor prescribes an active lifestyle, healthy marketing calisthenics, a diet with plenty of roughage, and jumping back on the hamster wheel of pain for exercise.

/Hoff

A Worm By Any Other Name Is...An Information Epidemic?

Martin McKeay took exception to some interesting Microsoft research that suggested that the similar methodologies and tactics used by malicious software such as worms/viri, could also be used as an effective distributed defense against them:

Microsoft researchers are hoping to use "information epidemics" to distribute software patches more efficiently.

Milan Vojnović and colleagues from Microsoft Research in Cambridge, UK, want to make useful pieces of information such as software updates behave more like computer worms: spreading between computers instead of being downloaded from central servers.

The research may also help defend against malicious types of worm, the researchers say.

Software worms spread by self-replicating. After infecting one computer they probe others to find new hosts. Most existing worms randomly probe computers when looking for new hosts to infect, but that is inefficient, says Vojnović, because they waste time exploring groups or "subnets" of computers that contain few uninfected hosts.

Despite the really cool moniker (information epidemic,) this isn't a particularly novel distribution approach and in fact, we've seen malware do this.  However, it is interesting to see that an OS vendor (Microsoft) is continuing to actively engage in research to explore this approach despite the opinions of others who simply claim it's a bad idea.  I'm not convinced either way, however.

I, for one, am all for resilient computing environments that are aware of their vulnerabilities and can actively defend against them.  I will be interested to see how this new paper builds off of work previously produced on the subject and its corresponding criticism.

Vojnović's team have designed smarter strategies that can exploit the way some subnets provide richer pickings than others.

The ideal approach uses prior knowledge of the way uninfected computers are spread across different subnets. A worm with that information can focus its attention on the most fruitful subnets – infecting a given proportion of a network using the smallest possible number of probes.

But although prior knowledge could be available in some cases – a company distributing a patch after a previous worm attack, for example – usually such perfect information will not be available. So the researchers have also developed strategies that mean the worms can learn from experience.

In the best of these, a worm starts by randomly contacting potential new hosts. After finding one, it uses a more targeted approach, contacting only other computers in the same subnet. If the worm finds plenty of uninfected hosts there, it keeps spreading in that subnet, but if not, it changes tack.

That being the case, here's some of Martin's heartburn:

But the problem is, if both beneficial and malign software show the same basic behavior patterns, how do you differentiate between the two? And what’s to stop the worm from being mutated once it’s started, since bad guys will be able to capture the worms and possibly subverting their programs.

The article isn’t clear on how the worms will secure their network, but I don’t believe this is the best way to solve the problem that’s being expressed. The problem being solved here appears to be one of network traffic spikes caused by the download of patches. We already have a widely used protocols that solve this problem, bittorrents and P2P programs. So why create a potentially hazardous situation using worms when a better solution already exists. Yes, torrents can be subverted too, but these are problems that we’re a lot closer to solving than what’s being suggested.

I don’t want something that’s viral infecting my computer, whether it’s for my benefit or not. The behavior isn’t something to be encouraged. Maybe there’s a whole lot more to the paper, which hasn’t been released yet, but I’m not comfortable with the basic idea being suggested. Worm wars are not the way to secure the network.

I think that some of the points that Martin raises are valid, but I also think that he's reacting mostly out of fear to the word 'worm.'  What if we called it "distributed autonomic shielding?" ;)

Some features/functions of our defensive portfolio are going to need to become more self-organizing, autonomic and intelligent and that goes for the distribution of intelligence and disposition, also.  If we're not going to advocate being offensive, then we should at least be offensively defensive.  This is one way of potentially doing this.

Interestingly, this dovetails into some discussions we've had recently with Andy Jaquith and Amrit Williams; the notion of herds or biotic propagation and response are really quite fascinating.  See my post titled "Thinning the Herd & Chlorinating the Gene Pool"

I've left out most of the juicy bits of the story so you should go read it and churn on some of the very interesting points raised as part of the discussion.

/Hoff

Update: Schneier thinks this is a lousy idea. That doesn't move me one direction or the other, but I think this is cementing my opinion that had the author not used the word 'worm' in his analog the idea might not be dismissed so quickly...

Also, Wismer via a comment on Martin's blog pointed to an interesting read from Vesselin Bontchev titled "Are "Good" Computer Viruses Still a Bad Idea?"

Update #2: See the comments section about how I think the use case argued by Schneier et. al. is, um, slightly missing the point.  Strangely enough, check out the Network World article that just popped up which says ""This was not the primary scenario targeted for this research," according to a statement."

Duh.

Security Innovation & the Bendy Hammer

See that odd looking hammer to the left?  It's called the MaxiStrike from Redback Tools.

No, it hasn't been run over by a Panzer, nor was there grease on the lens  during the photography session. 

Believe it or not, that odd little bend enables this 20 ounce mallet with the following features:

     > maximize strike force

     > reduce missed hits

     > leave clearance for nailing in cramped areas

All from that one little left hand turn from linear thought in product design.

You remember that series of posts I did on Disruptive Innovation?

This is a perfect illustration of how innovation can be "evolutionary" as opposed to revolutionary.

Incrementalism can be just as impacting as one of those tipping point "big-bang" events that have desensitized us to some of the really cool things that pop up and can actually make a difference.

So I know this hammer isn't going to cure cancer, but it makes for easier, more efficient and more accurate nailing.  Sometimes that's worth a hell of a lot to someone who does a lot of hammering...

Things like this happen around us all the time -- even in our little security puddle of an industry. 

It's often quite fun when you spot them.

I bet if you tried, you can come up with some examples in security.

Well?

Ginko Financial Collapse Ultimately Yields Real Virtual Risk (Huh?)

I'm feeling old lately.  First it was my visceral reaction to the paranormal super-poking goings-on on Facebook and now it's this news regarding Linden Lab's Second Life that has my head spinning. 

It seems that the intersection between the virtual and physical worlds is continuing to inch ever closer.

In fact, it's hitting people where it really counts, their (virtual) wallets. 

We first saw something like this bubble up with in-world gambling issues and now Linden announced in their blog today that any virtual "in-world banks" must be registered with real-world financial/banking regulatory agencies:

As of January 22, 2008, it will be prohibited to offer interest or any direct return on an investment (whether in L$ or other currency) from any object, such as an ATM, located in Second Life, without proof of an applicable government registration statement or financial institution charter. We’re implementing this policy after reviewing Resident complaints, banking activities, and the law, and we’re doing it to protect our Residents and the integrity of our economy.

Why?  It seems there's more bad juju brewin'.  A virtual bank shuts down and defaults.  What's next?  A virtual sub-prime loan scandal?

Since the collapse of Ginko Financial in August 2007, Linden Lab has received complaints about several in-world “banks” defaulting on their promises. These banks often promise unusually high rates of L$ return, reaching 20, 40, or even 60 percent annualized.

Usually, we don’t step in the middle of Resident-to-Resident conduct – letting Residents decide how to act, live, or play in Second Life.

But these “banks” have brought unique and substantial risks to Second Life, and we feel it’s our duty to step in. Offering unsustainably high interest rates, they are in most cases doomed to collapse – leaving upset “depositors” with nothing to show for their investments. As these activities grow, they become more likely to lead to destabilization of the virtual economy. At least as important, the legal and regulatory framework of these non-chartered, unregistered banks is unclear, i.e., what their duties are when they offer “interest” or “investments.”

There is no workable alternative. The so-called banks are not operated, overseen or insured by Linden Lab, nor can we predict which will fail or when. And Linden Lab isn’t, and can’t start acting as, a banking regulator.

Some may argue that Residents who deposit L$ with these “banks” must know they’re assuming a big risk – the high interest rates promised aren’t guaranteed, and the banks aren’t overseen by Linden Lab or anyone else. That may be true. But for all of the other reasons we’ve set out above, we can’t let this activity continue.

Thus, as we did in the past with gambling, as of January 22, 2008 we will begin removing any virtual ATMs or other objects that facilitate the operation or facilitation of in-world “banking,” i.e., the offering of interest or a rate of return on L$ invested or deposited. We ask that between now and then, those who operate these “banks” settle up on any promises they have made to other Residents and, of course, honor valid withdrawals. After that date, we may sanction those who continue to offer these services with suspension, termination of accounts, and loss of land.

Wow.  Loss of land!  I thought overdraft fees were harsh!?

Ed Felten from Freedom to Tinker summed it up nicely:

This was inevitable, given the ever-growing connections between the virtual economy of Second Life and the real-world economy. In-world Linden Dollars are exchangeable for real-world dollars, so financial crime in Second Life can make you rich in the real world. Linden doesn’t have the processes in place to license “banks” or investigate problems. Nor does it have the enforcement muscle to put bad guys in jail.

Expect this trend to continue. As virtual world “games” are played for higher and higher stakes, the regulatory power of national governments will look more and more necessary.

So far I've stayed away from Second Life; I've got enough to manage in my First one.  Perhaps it's time to take a peek and see what all the fuss is about?

/Hoff

Thinning the Herd & Chlorinating the Malware Gene Pool...

Alan Shimel pointed us to an interesting article written by Matt Hines in his post here regarding the "herd intelligence" approach toward security.  He followed it up here. 

All in all, I think both the original article that Andy Jaquith was quoted in as well as Alan's interpretations shed an interesting light on a problem solving perspective.

I've got a couple of comments on Matt and Alan's scribbles.

I like the notion of swarms/herds.  The picture to the right from Science News describes the notion of "rapid response," wherein "mathematical modeling is explaining how a school of fish can quickly change shape in reaction to a predator."  If you've ever seen this in the wild or even in film, it's an incredible thing to see in action.

It should then come as no surprise that I think that trying to solve the "security problem" is more efficiently performed (assuming one preserves the current construct of detection and prevention mechanisms) by distributing both functions and coordinating activity as part of an intelligent "groupthink" even when executed locally.  This is exactly what I was getting at in my "useful predictions" post for 2008:

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.

This is what Andy was referring to when he said:

As part of the effort, security vendors may also need to begin sharing more of that information with their rivals to create a larger network effect for thwarting malware on a global basis, according to the expert.

It may be hard to convince rival vendors to work together because of the perception that it could lessen differentiation between their respective products and services, but if the process clearly aids on the process of quelling the rising tide of new malware strains, the software makers may have little choice other than to partner, he said.

Secondly, Andy suggested that basically every end-node would effectively become its own honeypot:

"By turning every endpoint into a malware collector, the herd network effectively turns into a giant honeypot that can see more than existing monitoring networks," said Jaquith. "Scale enables the herd to counter malware authors' strategy of spraying huge volumes of unique malware samples with, in essence, an Internet-sized sensor network."

I couldn't agree more!  This is the sort of thing that I was getting at back in August when I was chatting with Lance Spitzner regarding using VM's for honeypots on distributed end nodes:

I clarified that what I meant was actually integrating a HoneyPot running in a VM on a production host as part of a standardized deployment model for virtualized environments.  I suggested that this would integrate into the data collection and analysis models the same was as a "regular" physical HoneyPot machine, but could utilize some of the capabilities built into the VMM/HV's vSwitch to actually make the virtualization of a single HoneyPot across an entire collection of VM's on a single physical host.

Thirdly, the notion of information sharing across customers has been implemented cross-sectionally in industry verticals with the advent of the ISAC's such as the Financial Services Information Sharing and Analysis Center which seeks to inform and ultimately leverage distributed information gathering and sharing to protect it's subscribing members.  Generally-available services like Symantec's DeepSight have also tried to accomplish similar goals.

Unfortunately, these offerings generally lack the capacity to garner ubiquitous data gathering and real-time enforcement capabilities.

As Matt pointed out in his article, gaining actionable intelligence on the monstrous amount of telemetric data from participating end nodes means that there is a need to really prune for false positives.  This is the trade-off between simply collecting data and actually applying intelligence at the end-node and effecting disposition. 

This requires technology that we're starting to see emerge with a small enough footprint when paired with the compute power we have in endpoints today. 

Finally, as the "network" (which means the infrastructure as well as the "extrastructure" delivered by services in the cloud) gains more intelligence and information-centric granularity, it will pick up some of the slack -- at least from the perspective of sloughing off the low-hanging fruit by using similar concepts.

I am hopeful that as we gain more information-centric footholds, we shouldn't actually be worried about responding to every threat but rather only those that might impact the most important assets we seek to protect. 

Ultimately the end-node is really irrelevant from a protection perspective as it should really be little more than a presentation facility; the information is what matters.  As we continue to make progress toward more resilient operating systems leveraging encryption and mutual authentication within communities of interest/trust, we'll start to become more resilient and information assured.

The sharing of telemetry to allow these detective and preventative/protective capabilities to self-organize and perform intelligent offensive/evasive actions will evolve naturally as part of this process.

Mooooooo.

/Hoff

Take5 (Episode #5) - Five Questions for Allwyn Sequeira, SVP of Product Operations, Blue Lane

This fifth episode of Take5 interviews Allwyn Sequeira, SVP of Product Operations for Blue Lane.  

First a little background on the victim:

Mr. Palmer is the President and Chief Executive Officer of Blue Lane Technologies. Previously, Jeff served as President of GetThere, the leading online corporate travel procurement solution, based in Menlo Park, CA. While at the company, GetThere grew to become the largest factor in the corporate online travel market, holding 70% market share among the top 100 US corporations, #1 share in the overall market with more than 3000 customers worldwide, and transaction volumes exceeding one million per month. GetThere went public on the NASDAQ in 1999 and was acquired by Sabre Holdings (NYSE: TSG) for $750 million in 2000.
         
Earlier in his career, Mr. Palmer served in a variety of general management and marketing officer roles at Tristrata Security, Memco Software, Pilot Software and BBN, establishing experience in enterprise networking, security, and applications software.
         
Mr. Palmer holds a Bachelor of Science degree from the Massachusetts Institute of Technology and an MBA from Harvard Business School.

Allwyn Sequeira is Senior Vice President of Product Operations at Blue Lane Technologies, responsible for managing the overall product life cycle, from concept through research, development and test, to delivery and support. He was previously the Senior Vice President of Technology and Operations at netVmg, an intelligent route control company acquired by InterNap in 2003, where he was responsible for the architecture, development and deployment of the industry-leading flow control platform. Prior to netVmg, he was founder, Chief Technology Officer and Executive Vice President of Products and Operations at First Virtual Corporation (FVC), a multi-service networking company that had a successful IPO in 1998. Prior to FVC, he was Director of the Network Management Business Unit at Ungermann-Bass, the first independent local area network company. Mr. Sequeira has previously served as a Director on the boards of FVC and netVmg.

Mr. Sequeira started his career as a software developer at HP in the Information Networks Division, working on the development of TCP/IP protocols. During the early 1980's, he worked on the CSNET project, an early realization of the Internet concept. Mr. Sequeira is a recognized expert in data networking, with twenty five years of experience in the industry, and has been a featured speaker at industry leading forums like Networld+Interop, Next Generation Networks, ISP Con and RSA Conference.

Mr. Sequeira holds a Bachelor of Technology degree in Computer Science from the Indian Institute of Technology, Bombay, and a Master of Science in Computer Science from the University of Wisconsin, Madison.   

Allwyn, despite all this good schoolin' forgot to send me a picture, so he gets what he deserves ;)
(Ed: Yes, those of you quick enough were smart enough to detect that the previous picture was of Brad Pitt and not Allwyn.  I apologize for the unnecessary froth-factor.)

 Questions:

1) Blue Lane has two distinct product lines, VirtualShield and PatchPoint.  The former is a software-based solution which provides protection for VMware Infrastructure 3 virtual servers as an ESX VM plug-in whilst the latter offers a network appliance-based solution for physical servers.  How are these products different than either virtual switch IPS' like Virtual Iron or in-line network-based IPS's?

IPS technologies have been charged with the incredible mission of trying to protect everything from anything.  Overall they've done well, considering how much the perimeter of the network has changed and how sophisticated hackers have become. Much of their core technology, however, was relevant and useful when hackers could be easily identified by their signatures. As many have proclaimed, those days are coming to an end.

A defense department official recently quipped, "If you offer the same protection for your toothbrushes and your diamonds you are bound to lose fewer toothbrushes and more diamonds."  We think that data center security similarly demands specialized solutions.  The concept of an enterprise network has become so ambiguous when it comes to endpoints and devices and supply chain partners, etc. we think its time to think more realistically in terms of trusted, yet highly available zones within the data center.

It seems clear at this point that different parts of the network need very different security capabilities.  Servers, for example need highly accurate solutions that do not block or impede good traffic and can correct bad traffic, especially when it comes to closing network-facing vulnerability windows.  They need to maintain availability with minimal latency for starters; and that has been a sort of Achilles heel for signature-based approaches.  Of course, signatures also bring considerable management burdens over and beyond their security capabilities.

No one is advocating turning off the IPS, but rather approaching servers with more specialized capabilities.  We started focusing on servers years ago and established very sophisticated application and protocol intelligence, which has allowed us to correct traffic inline without the noise, suspense and delay that general purpose network security appliance users have come to expect.

IPS solutions depend on deep packet inspection typically at the perimeter based on regexp pattern matching for exploits.  Emerging challenges with this approach have made alert and block modes absolutely necessary as most IPS solutions aren't accurate enough to be trusted in full library block. 

Blue Lane uses a vastly different approach.  We call it deep flow inspection/correction for known server vulnerabilities based on stateful decoding up to layer 7.  We can alert, block and correct, but most of are deployments are in correct mode, with our full capabilities enabled. From an operational standpoint we have substantially different impacts.

A typical IPS may have 10K signatures while experts recommend turning on just a few hundred.  That kind of marketing shell game (find out what really works) means that there will be plenty of false alarms, false positives and negatives and plenty of tuning.  With polymorphic attacks signature libraries can increase exponentially while not delivering meaningful improvements in protection. 

Blue Lane supports about 1000 inline security patches across dozens of very specific server vulnerabilities, applications and operating systems.  We generate very few false alarms and minimal latency.  We don't require ANY tuning.  Our customers run our solution in automated, correct mode.

The traditional static signature IPS category has evolved into an ASIC war between some very capable players for the reasons we just discussed.Exploding variations of exploits and vectors means that exploit-centric approaches will require more processing power.

Virtualization is pulling the data center into an entirely different direction, driven by commodity processors.  So of course our VirtualShield solution was a much cleaner setup with a hypervisor; we can plug into the hypervisor layer and run on top of existing hardware, again with minimal latency and footprint.

You don't have to be a Metasploit genius to evade IPS signatures.  Our higher layer 7 stateful decoding is much more resilient. 

2) With zero-days on the rise, pay-for-play vulnerability research and now Zero-Bay (WabiSabiLabi) vulnerability auctions and the like, do you see an uptake in customer demand for vulnerability shielding solutions?

Exploit-signature technologies are meaningless in the face of evanescent, polymorphic threats, resulting in 0-day exploits. Slight modifications to signatures can bypass IPSes, even against known vulnerabilities.  Blue Lane technology provides 0-day protection for any variant of an exploit against known vulnerabilities.  No technology can provide ultimate protection against 0-day exploits based on 0-day vulnerabilities. However, this requires a different class of hacker.

3) As large companies start to put their virtualization strategies in play, how do you see customers addressing securing their virtualized infrastructure?  Do they try to adapt existing layered security methodologies and where do these fall down in a virtualized world?

I've explored this topic in depth at the Next Generation Data Center conference last week. Also, your readers might be interested in listening to a recent podcast: The Myths and Realities of Virtualization Security: An Interview. 

To summarize, there are a few things that change with virtualization, that folks need to be aware of.  It represents a new architecture.  The hypervisor layer represents the un-tethering and clustering of VMs, and centralized control.  It introduces a new virtual network layer.  There are entirely new states of servers, not anticipated by traditional static security approaches (like instant create, destroy, clone, suspend, snapshot and revert to snapshot). 

Then you'll see unprecedented levels of mobility and new virtual appliances and black boxing of complex stacks including embedded databases.  Organizations will have to work out who is responsible for securing this very fluid environment.  We'll also see unprecedented scalability with Infiniband cores attaching LAN/SAN out to 100's of ESX hypervisors and thousands of VMs.

Organizations will need the capability to shield these complex, fluid environments; because trying to keep track of individual VMs, states, patch levels, locations will make tuning an IPS for polymorphic attacks look like childs play in comparison.   Effective solutions will need to be highly accurate, low latency solutions deployed in correct mode. Gone will be the days of man-to-man blocking and tuning.  Here to stay are the days of zone defense.

4) VMware just purchased Determina and intends to integrate their memory firewall IPS product as an ESX VM plug-in.  Given your early partnership with VMware, are you surprised by this move?  Doesn't this directly compete with the VirtualSheild offering?

I wouldn't read too much into this. Determina hit the wall on sales, primarily because it's original memory wall technology was too intrusive, and fell short of handling new vulnerabilities/exploits.

This necessitated the LiveShield product, which required ongoing updates, destroying the value proposition of not having to touch servers, once installed. So, this is a technology/people acquisition, not a product line/customer-base acquisition.

VMware was smart to get a very bright set of folks, with deep memory/paging/OS, and a core technology that would do well to be integrated into the hypervisor for the purpose of hypervisor hardening, and interVM isolation. I don't see VMware entering the security content business soon (A/V, vulnerabilities, etc.). I see Blue Lane's VirtualShield technology integrated into the virtual networking layer (vSwitch), as a perfect complement to anything that will come out of the Determina acquisition.

5) Citrix just acquired XenSource.  Do you have plans to offer VirtualShield for Xen? 

A smart move on Citrix's part to get back into the game. Temporary market caps don't matter. Virtualization matters. If Citrix can make this a two or three horse race, it will keep the VMware, Citrix, Microsoft triumvirate on their toes, delivering better products, and net good for the customer.

Regarding BlueLane, and Citrix/Xensource, we will continue to pay attention to what customers are buying as they virtualize their data centers. For now, this is a one horse show :-)

Oh SNAP! VMware acquires Determina! Native Security Integration with the Hypervisor?

Hot on the trails of becoming gigagillionaires, the folks at VMware make my day with this.  Congrats to the folks @ Determina.

Methinks that for the virtualization world, it's a very, very good thing.  A step in the right direction.

I'm going to prognosticate that this means that Citrix will buy Blue Lane or Virtual Iron next (see bottom of the post) since their acquisition of XenSource leaves them with the exact same problem that this acquisition for VMware tries to solve:

VMware Inc., the market leader in virtualization software, has acquired Determina Inc., a Silicon Valley maker of host intrusion prevention products.

...the security of virtualized environments has been something of an unknown quantity due to the complexity of the technology and the ways in which hypervisors interact with the host OS.  Determina's technology is designed specifically to protect the OS from malicious code, regardless of the origin of the attack, so it would seem to be a sensible fit for VMware, analysts say.

In his analysis of the deal, Gartner's MacDonald sounded many of the same notes. "By potentially integrating Memory Firewall into the ESX hypervisor, the hypervisor itself can provide an additional level of protection against intrusions. We also believe the memory protection will be extended to guest OSs as well: VMware's extensive use of binary emulation for virtualization puts the ESX hypervisor in an advantageous position to exploit this style of protection," he wrote.

I've spoken a lot recently  about how much I've been dreading the notion that security was doomed to repeat itself with the accelerated take off of server virtualization since we haven't solved many of the most basic security problem classes.  Malicious code is getting more targeted and more intelligent and when you combine an emerging market using hot technology without an appropriate level of security... 

Basically, my concerns have stemmed from the observation that if we can't do a decent job protecting physically-seperate yet interconnected network elements with all the security fu we have, what's going to happen when the "...network is the computer" (or vice versa.)  Just search for "virtualization" via the Lijit Widget above for more posts on this...

Some options for securing virtualized guest OS's in a VM are pretty straight foward:

1. Continue to deploy layered virtualized security services across VLAN segments of which each VM is a member (via IPS's, routers, switches, UTM devices...)
2. Deploy software like Virtual Iron's which looks like a third party vSwitch IPS on each VM
3. Integrate something like Blue Lane's ESX plugin-in which interacts with and at the VMM level
4. As chipset level security improves, enable it
5. Deploy HIPS as part of every guest OS.

Each of these approaches has its own sets of pros and cons, and quite honestly, we'll probably see people doing all five at the same time...layered defense-in-depth.  Ugh.

What was really annoying to me, however, is that it really seemed that in many cases, the VM solution providers were again expecting that we'd just be forced to bolt security ON TO our VM environments instead of BAKING IT IN.  This was looking like a sad reality.

I'll get into details in another post about Determina's solution, but I am encouraged by VMware's acquisition of a security company which will be integrated into their underlying solution set.  I don't think it's  a panacea, but quite honestly, the roadmap for solving these sorts of problems were blowing in the wind for VMware up until this point.

"Further, by using the LiveShield capabilities, the ESX hypervisor could be used 'introspectively' to shield the hypervisor and guest OSs from attacks on known vulnerabilities in situations where these have not yet been patched. Both Determina technologies are fairly OS- and application-neutral, providing VMware with an easy way to protect ESX as well as Linux- and Windows-based guest OSs."

Quite honestly, I hoped they would have bought Blue Lane since the ESX Hypervisor is now going to be a crowded space for them...

We'll see how well this gets integrated, but I smiled when I read this.

Oh, and before anyone gets excited, I'm sure it's going to be 100% undetectable! ;)

/Hoff

Secure Services in the Cloud (SSaaS/Web2.0) - InternetOS Service Layers

The last few days of activity involving Google and Microsoft have really catalyzed some thinking and demonstrated some very intriguing indicators as to how the delivery of applications and services is dramatically evolving. 

I don't mean the warm and fuzzy marketing fluff.  I mean some real anchor technology investments by the big-boys putting their respective stakes in the ground as they invest hugely in redefining their business models to setup for the future.

Enterprises large and small are really starting to pay attention to the difference between infrastructure and architecture and this has a dramatic effect on the service providers and supply chain who interact with them.

It's become quite obvious that there is huge business value associated with divorcing the need for "IT" to focus on physically instantiating and locating "applications" on "boxes" and instead  delivering "services" with the Internet/network as the virtualized delivery mechanism.

Google v. Microsoft - Let's Get Ready to Rumble!

My last few posts on Google's move to securely deliver a variety of applications and services represents the uplift of the "traditional" perspective of backoffice SaaS offerings such as Salesforce.com but also highlights the migration of desktop applications and utility services to the "cloud" also.

This is really executing on the vision of the thin-client Internet-centric vision from back in the day o' the bubble when we saw a ton of Internet-borne services such as storage, backup, etc.  using the "InternetOS" as the canvas for service.

So we've talked about Google.  I maintain that their strategy is to ultimately take on Microsoft -- including backoffice, utility and desktop applications.  So let's look @ what the kids from Redmond are up to.

What Microsoft is developing towards with their vision of CloudOS was just recently expounded upon by one Mr. Ballmer.

Not wanting to lose mindshare or share of wallet, Microsoft is maneuvering to give the customer control over how they want to use applications and more importantly how they might be delivered.  Microsoft Live bridges the gap between the traditional desktop and puts that capability into the "cloud."

Let's explore that a little:

In addition to making available its existing services, such as mail and instant messaging, Microsoft also will create core infrastructure services, such as storage and alerts, that developers can build on top of. It's a set of capabilities that have been referred to as a "Cloud OS," though it's not a term Microsoft likes to use publicly.

...

Late last month, Microsoft introduced two new Windows Live Services, one for sharing photos and the other for all types of files. While those services are being offered directly by Microsoft today, they represent the kinds of things that Microsoft is now promising will be also made available to developers.

Among the other application and infrastructure components, Microsoft plans to open are its systems for alerts, contact management, communications (mail and messenger) and authentication.

...

As it works to build out the underlying core services, Microsoft is also offering up applications to partners, such as Windows Live Hotmail, Windows Live Messenger and the Spaces blogging tool.

Combine the emerging advent of "thinner" end-points (read: mobility products) with high-speed, lower latency connectivity and we can see why this model is attractive and viable.  I think this battle is heating up and the consumer will benefit.

A Practical Example of SaaS/InternetOS Today?

So if we take a step back from Google and Microsoft for a minute, let's take a snapshot of how one might compose, provision, and deploy applications and data as a service using a similar model over the Internet with tools other than Live or GoogleGear.

Let me give you a real-world example -- deliverable today -- of this capability with a functional articulation of this strategy; on-demand services and applications provided via virtualized datacenter delivery architectures using the Internet as the transport.  I'm going to use a mashup of two technologies: Yahoo Pipes and 3tera's AppLogic.

Yahoo Pipes is  "...an interactive data aggregator and manipulator that lets you mashup your favorite online data sources."  Assuming you have data from various sources you want to present an application environment such as Pipes will allow you to dynamically access, transform and present this information any way you see fit.

This means that you can create what amounts to application and services on demand. 

Let's agree however that while you have the data integration/presentation layer, in many cases you would traditionally require a complex collection of infrastructure from which this source data is housed, accessed, maintained and secured. 

However, rather than worry about where and how the infrastructure is physically located, let's use the notion of utility/grid computing to make available dynamically an on-demand architecture that is modular, reusable and flexible to make my service delivery a reality -- using the Internet as a transport.

Enter 3Tera's AppLogic:

3Tera's AppLogic is used by hosting providers to offer true utility computing. You get all the control of having your own virtual datacenter, but without the need to operate a single server.

Deploy and operate applications in your own virtual private datacenter

Set up infrastructure, deploy apps and manage operations with just a browser    
Scale from a fraction of a server to hundreds of servers in days

Deploy and run any Linux software without modifications

Get your life back: no more late night rushes to replace failed equipment

In fact, BT is using them as part of the 21CN project which I've written about many times before.

So check out this vision, assuming the InternetOS as a transport.  It's the drag-and-drop, point-and-click Metaverse of virtualized application and data combined with on-demand infrastructure.

You first define the logical service composition and provisioning through 3Tera with a visual drag-drop canvas, defining firewalls, load-balancers, switches, web servers, app. servers, databases, etc.  Then you click the "Go" button.  AppLogic provisions the entire thing for you without you even necessarily knowing where these assets are.

Then, use something like Pipes to articulate how data sources can be accessed, consumed and transformed to deliver the requisite results.  All over the Internet, transparent to you securely.

Very cool stuff.

Here are some screen-caps of Pipes and 3Tera.

 

 

 

I see your "More on Data Centralization" & Raise You One "Need to Conduct Business..."

Bejtlich continues to make excellent points regarding his view on centralizing data within an enterprise.  He cites the increase in litigation regarding inadequate eDiscovery investment and the increasing pressures amassed from compliance.

All good points, but I'd like to bring the discussion back to the point I was trying to make initially and here's the perfect perch from which to do it.  Richard wrote:

Christopher Christofer Hoff used the term "agile" several times in his good blog post. I think "agile" is going to be thrown out the window when corporate management is staring at $50,000 per day fines for not being able to produce relevant documents during ediscovery. When a company loses a multi-million dollar lawsuits because the judge issued an adverse inference jury instruction, I guarantee data will be centralized from then forward. "

...how about when a company loses the ability to efficiently and effectively conduct business because they spend so much money and time on "insurance policies" against which a balanced view of risk has not been applied?  Oh, wait.  That's called "information security." ;)

Fear.  Uncertainty.  Doubt.  Compliance.  Ugh.  Rinse, later, repeat.

I'm not taking what you're proposing lightly, Richard, but the notion of agility, time to market, cost transformation and enhancing customer experience are being tossed out with the bathwater here. 

Believe it or not, we have to actually have a sustainable business in order to "secure" it. 

It's fine to be advocating Google Gears and all these other Web 2.0 applications and systems. There's one force in the universe that can slap all that down, and that's corporate lawyers. If you disagree, whom do you think has a greater influence on the CEO: the CTO or the corporate lawyer? When the lawyer is backed by stories of lost cases, fines, and maybe jail time, what hope does a CTO with plans for "agility" have?

But going back to one of your own mantras, if you bake security into your processes and SDLC in the first place, then the CEO/CTO/CIO and legal counsel will already have assessed the position the company has and balance the risk scorecard to ensure that they have exercised the appropriate due care in the first place. 

The uncertainty and horrors associated with the threat of punitive legal impacts have, are, and will always be there...and they will continue to be exploited by those in the security industry to buy more stuff and justify a paycheck.

Given the business we're in, it's not a surprise that the perspective presented is very, very siloed and focused on the potential "security" outcomes of what happens if we don't start centralizing data now; everything looks like a nail when you're a hammer.

However, you still didn't address the other two critical points I made previously:

1. The underlying technology associated with decentralization of data and applications is at complete odds with the "curl up in a fetal position and wait for the sky to fall" approach
2. The only reason we have security in the first place is to ensure survivability and availability of service -- and make sure that we stay in business.  That isn't really a technical issue at all, it's a business one.  I find it interesting that you referenced this issue as the CTO's problem and not the CIO.

As to your last point, I'm convinced that GE -- with the resources, money and time it has to bear on a problem -- can centralize its data and resources...they can probably get cold fusion out of a tuna fish can and a blow pop, but for the rest of us on planet Earth, we're going to have to struggle along trying to cram all the 'agility' and enablement we've just spent the last 10 years giving to users back into the compliance bottle.

/Hoff

Security Application Instrumentation: Reinventing the Wheel?

Two of my favorite bloggers engaged in a trackback love-fest lately on the topic of building security into applications; specifically, enabling applications as a service delivery function to be able to innately detect, respond to and report attacks.

Richard Bejtlich wrote a piece called Security Application Instrumentation and Gunnar Peterson chimed in with Building Coordinated Response In - Learning from the Anasazis.  As usual, these are two extremely well-written pieces and arrive at a well constructed conclusion that we need a standard methodology and protocol for this reporting.  I think that this exquisitely important point will be missed by most of the security industry -- specifically vendors.

While security vendor's hearts are in the right place (stop laughing,) the "security is the center of the universe" approach to telemetry and instrumentation will continue to fall on deaf ears because there are no widely-adopted standard ways of reporting across platforms, operating systems and applications that truly integrate into a balanced scorecard/dashboard that demonstrates security's contribution to service availability across the enterprise.   I know what you're thinking..."Oh God, he's going to talk about metrics!  Ack!"  No.  That's Andy's job and he does it much better than I.

This mess is exactly why the SEIM market emerged to clean up the cesspool of log dumps that spew forth from devices that are, by all approximation, utterly unaware of the rest of ecosystem in which they participate.  Take all these crappy log dumps via Syslog and SNMP (which can still be proprietary,) normalize if possible, correlate "stuff" and communicate that something "bad" or "abnormal" has occurred.

How does that communicate what this really means to the business, its ability to function, deliver servce and ultimately the impact on risk posture?  It doesn't because security reporting is the little kid wearing a dunce hat standing in the corner because it doesn't play well with others.

Gunnar stated this well:

Coordinated detection and response is the logical conclusion to defense in depth security architecture. I think the reason that we have standards for authentication, authorization, and encryption is because these are the things that people typically focus on at design time. Monitoring and auditing are seen as runtime operational acitivities, but if there were standards based ways to communicate security information and events, then there would be an opportunity for the tooling and processes to improve, which is ultimately what we need.

So, is the call for "security application instrumentation" doomed to fail because we in the security industry will try to reinvent the wheel with proprietary solutions and suggest that the current toolsets and frameworks which are available as part of a much larger enterprise management and reporting strategy not enough? 

Bejtlich remarked on the need for mechanisms that report application state must be built into the application and must report more than just performance:

Today we need to talk about applications defending themselves. When they are under attack they need to tell us, and when they are abused, subverted, or breached they would ideally also tell us

I would like to see the next innovation be security application instrumentation, where you devise your application to report not only performance and fault logging, but also security and compliance logging. Ideally the application will be self-defending as well, perhaps offering less vulnerability exposure as attacks increase (being aware of DoS conditions of course).

I would agree, but I get the feeling that without integrating this telemetry and the output metrics and folding it into response systems whose primary role is to talk about delivery and service levels -- of which "security" is a huge factor -- the relevance of this data within the visible single pane of glass of enterprise management is lost.

So, rather than reinvent the wheel and incrementally "innovate," why don't we take something like the Open Group's Application Response Measurement (ARM) standard, make sure we subscribe to a telemetry/instrumentation format that speaks to the real issues and enable these systems to massage our output in terms of the language of business (risk?) and work to extend what is already a well-defined and accepted enterprise response management toolset to include security?

To wit:

The Application Response Measurement (ARM) standard describes a common method for integrating enterprise applications as manageable entities. The ARM standard allows users to extend their enterprise management tools directly to applications creating a comprehensive end-to-end management capability that includes measuring application availability, application performance, application usage, and end-to-end transaction response time.

Or how about something like EMC's Smarts:

Maximize availability and performance of mission-critical IT resources—and the business services they support. EMC Smarts software provides powerful solutions for managing complex infrastructures end-to-end, across technologies, and from the network to the business level. With EMC Smarts innovative technology you can:

• Model components and their relationships across networks, applications, and storage to understand effect on services.
• Analyze data from multiple sources to pinpoint root cause problems—automatically, and in real time.
• Automate discovery, modeling, analysis, workflow, and updates for dramatically lower cost of ownership.

            

...add security into these and you've got a winner.   

There are already industry standards (or at least huge market momentum) around intelligent automated IT infrastructure, resource management and service level reporting. We should get behind a standard that elevates the perspective of how security contributes to service delivery (and dare I say risk management) instead of trying to reinvent the wheel...unless you happen to like the Hamster Wheel of Pain...

/Hoff

Really, There's More to Security than Admission/Access Control...

Dr. Joseph Tardo over at the Nevis Networks Illuminations blog composed a reasonably well-balanced commentary regarding one or more of my posts in which I was waxing on philosophically about about my beliefs regarding keeping the network plumbing dumb and overlaying security as a flexible, agile, open and extensible services layer.

It's clear he doesn't think this way, but I welcome the discourse.  So let me make something clear:

Realistically, and especially in non-segmented flat networks, I think there are certain low-level security functions that will do well by being served up by switching infrastructure as security functionality commoditizes, but I'm not quite sure for the most part how or where yet I draw the line between utility and intelligence.  I do, however, think that NAC is one of those utility services.

I'm also unconvinced that access-grade, wiring closet switches are architected to scale in either functionality, efficacy or performance to provide any more value or differentiation other than port density than the normal bolt-on appliances which continue to cause massive operational and capital expenditure due to continued forklifts over time.  Companies like Nevis and Consentry quietly admit this too, which is why they have both "secure switches" AND appliances that sit on top of the network...

Joseph suggested he was entering into a religious battle in which he summarized many of the approaches to security that I have blogged about previously and I pointed out to him on his blog that this is exactly why I practice polytheism ;) :

In case you aren’t following the religious wars going on in the security blogs and elsewhere, let me bring you up to date.

It goes like this. If you are in the client software business, then security has to be done in the endpoints and the network is just dumb “plumbing,” or rather, it might as well be because you can’t assume anything about it. If you sell appliances that sit here and there in the network, the network sprouts two layers, with the “plumbing” part separated from the “intelligence.” Makes sense, I guess. But if you sell switches and routers then the intelligence must be integrated in with the infrastructure. Now I get it. Or maybe I’m missing the point, what if you sell both appliances and infrastructure?

I believe that we're currently forced to deploy in defense in depth due to the shortcomings of solutions today.  I believe the "network" will not and cannot deliver all the security required.  I believe we're going to have to invest more in secure operating systems and protocols.  I further believe that we need to be data-centric in our application of security.  I do not believe in single-point product "appliances" that are fundamentally functionally handicapped.  As a delivery mechanism to deliver security that matters across network I believe in this.

Again, the most important difference between what I believe and what Joseph points out above is that the normal class of "appliances" he's trying to suggest I advocate simply aren't what I advocate at all.  In fact, one might surprisingly confuse the solutions I do support as "infrastructure" -- they look like high-powered switches with a virtualized blade architecture integrated into the solution.

It's not an access switch, it's not a single function appliance and it's not a blade server and it doesn't suffer from the closed proprietary single vendor's version of the truth.  To answer the question, if you sell and expect to produce both secure appliances and infrastructure, one of them will come up short.   There are alternatives, however.

So why leave your endpoints, the ones that have all those vulnerabilities that created the security industry in the first place, to be hit on by bots, “guests,” and anyone else that wants to? I don’t know about you, but I would want both something on the endpoint, knowing it won’t be 100% but better than nothing, and also something in the network to stop the nasty stuff, preferably before it even got in.

I have nothing to disagree with in the paragraph above -- short of the example of mixing active network defense with admission/access control in the same sentence; I think that's confusing two points.   Back to the religious debate as Joseph drops back to the "Nevis is going to replace all switches in the wiring closet" approach to security via network admission/access control:

Now, let’s talk about getting on the network. If the switches are just dumb plumbing they will blindly let anyone on, friend or foe, so you at least need to beef up the dumb plumbing with admission enforcement points. And you want to put malware sensors where they can be effective, ideally close to entry points, to minimize the risk of having the network infrastructure taken down. So, where do you want to put the intelligence, close to the entry enforcement points or someplace further in the bowels of the network where the dumb plumbing might have plugged-and-played a path around your expensive intelligent appliance?

That really depends upon what you're trying to protect; the end point, the network or the resources connected to it.  Also, I won't/can't argue about wanting to apply access/filtering (sounds like IPS in the above example) controls closest to the client at the network layer.  Good design philosophy.   However, depending upon how segmented your network is, the types, value and criticality of the hosts in these virtual/physical domains, one may choose to isolate by zone or VLAN and not invest in yet another switch replacement at the access layer.

If the appliance is to be effective, it has to sit at a choke point and really be and enforcement point. And it has to have some smarts of its own. Like the secure switch that we make.

Again, that depends upon your definition of enforcement and applicability.  I'd agree that in flat networks, you'd like to do it at the port/host level, though replacing access switches to do so is usually not feasible in large networks given investments in switching architectures.  Typical fixed configuration appliances overlaid don't scale, either.

Furthermore, depending upon your definition of what an enforcement zone and it's corresponding diameter is (port, VLAN, IP Subnet) you may not care.  So putting that "appliance" in place may not be as foreboding as you wager, especially if it overlays across these boundaries satisfactorily.

We will see how long before these new-fangled switch vendors that used to be SSL VPN's, that then became IPS appliances that have now "evolved" into NAC solutions, will become whatever the next buzzword/technology of tomorrow represents...especially now with Cisco's revitalized technology refresh for "secure" access switches in the wiring closets.  Caymas, Array, and Vernier (amongst many) are perfect examples.

When it comes down to it, in the markets Crossbeam serves -- and especially the largest enterprises -- they are happy with their switches, they just want the best security choice on top of it provided in a consolidated, agile and scalable architecture to support it.

Amen.

/Hoff

McAfee's Bolin suggests Virtual "Sentinel" Security Model for Uncompromised Security

Christopher Bolin, McAfee's EVP & CTO blogged an interesting perspective on utilizing virtualization technology to instantiate security functionality in an accompanying VM on a host to protect one or more VM's on the same host.  This approach differs than the standard approach of placing host-based security controls on each VM or the intra-VS IPS models from companies such as Reflex (blogged about that here.)

I want to flush out some of these concepts with a little more meat attached

He defines the concept of running security software alongside the operating system it is protecting as "the sentinel":

In this approach, the security software itself resides in its own virtual machine outside and parallel to the system it is meant to protect, which could be another virtual machine running an operating system such as Windows. This enables the security technology to look omnisciently into the subject OS and its operation and take appropriate action when malware or anomalous behavior is detected.

Understood so far...with some caveats, below.

The security software would run in an uncompromised environment monitoring in real-time, and could avoid being disabled, detected or deceived (or make the bad guys work a lot harder.)

While this supposedly uncompromised/uncompromisable OS could exist, how are you going to ensure that the underlying "routing" traffic flow control actually forces the traffic through the Sentinel VM in the first place? If the house of cards rests on this design element, we'll be waiting a while...and adding latency.  See below.

This kind of security is not necessarily a one-to-one relationship between sentinel and OSs. One physical machine can run several virtual machines, so one virtual sentinel could watch and service many virtual machines.

I think this is a potentially valid and interesting alternative to deploying more and more host-based security products (which seems odd coming from McAfee) or additional physical appliances, but there are a couple of issues with this premise, some of which Bolin points out, others I'll focus on here:

1. Unlike other applications which run in a VM and just require a TCP/IP stack, security applications are extremely topology sensitive.  The ability to integrate sentinels in a VM environment with other applications/VM's at layer 2 is extremely difficult, especially if these security applications are to act "in-line." 
   
   Virtualizing transport while maintaining topology context is difficult and when you need to then virtualize the policies based upon this topology, it gets worse.  Blade servers have this problem; they have integrated basic switch/load balancing modules, but implementing policy-driven "serialization" and "parallelization" (which is what we call it @ Crossbeam) is very, very hard.



2. The notion that the sentinel can "...look omnisciently into the subject OS and its operation and take appropriate action when malware or anomalous behavior is detected" from a network perspective is confusing.  If you're outside the VM/Hypervisor, I don't understand the feasibility of this approach.  This is where Blue Lane's VirtualShiel ESX plug-in kicks ass -- it plugs into the Hypervisor and protects not only directed traffic to the VM but also intra-VM traffic with behavioral detection, not just signatures.
   
   
3. Resource allocation of the sentinel security control as a VM poses a threat vector inasmuch as one could overwhelm/DoS the Sentinel VM and security/availability of the entire system could be compromised; the controls protecting the VMs are competing for the same virtualized resources that the resources are after.
   
   
4. As Bolin rightfully suggests, a vulnerability in the VM/VMM/Chipsets could introduce a serious set of modeling problems.

I maintain that securing virtualization by virtualizing security is nascent at best, but as Bolin rightfully demonstrates, there are many innovative approaches being discussed to address these new technologies.

/Hoff

Evan Kaplan and Co. (Aventail) Take the Next Step

So Aventail's being acquired by SonicWall?  I wish Evan Kaplan and his team well and trust that SonicWall will do their best to integrate the best of Aventail's technology into their own.  It's interesting that this news pops up today because I was just thinking about Aventail's CEO today as part of a retrospective of security over the last 10+ years.

I've always admired Evan Kaplan's messaging from afar and a couple of months ago I got to speak with him for an hour or so.  For someone who has put his stake in the ground the ground for last 11 years as a leader in the SSL VPN market, you might be surprised to know that Evan's perspective on the world of networking and security isn't limited to "tunnel vision" as one might expect.

One of my favorite examples of Evan's beliefs is this article in Network World back in 2005 that resonated so very much with me then and still does today.  The title of the piece is "Smart Networks are Not a Good Investment" and was a "face off" feature between Evan and Cisco's Rob Redford.

Evan's point here -- and what resonates at the core of what I believe should happen to security -- is that the "network" ought to be separated into two strata, the "plumbing" (routers, switches, etc.) and intelligent "service layers" (security being one of them.)

Evan calls these layers "connectivity" and "intelligence."

The plumbing should be fast, resilient, reliable, and robust providing the connectivity and the service layers should be agile, open, interoperable, flexible and focused on delivering service as a core competency.   

Networking vendors who want to leverage the footprint they already have in port density and extend their stranglehold single vendor version of the truth obviously disagree with this approach.  So do those who ultimately suggest that "good enough" is good enough.

Evan bangs the drum:

Network intelligence as promoted by the large network vendors is the Star Wars defense system of our time - monolithic, vulnerable and inherently unreliable. Proponents of smart networks want to extend their hegemony by incorporating application performance and security into a unified, super-intelligent infrastructure. They want to integrate everything into the network and embed security into every node. In theory, you would then have centralized control and strong perimeter defense.

Yup.  As I blogged recently, "Network Intelligence is an Oxymoron."  The port puppets will have you believe that you can put all this intelligence in the routers in switches and solve all the problems these platforms were never designed to solve whilst simultaneously scale performance and features against skyrocketing throughput requirements, extreme latency thresholds, emerging technologies and an avalanche of compounding threats and vulnerabilities...all from one vendor, of course.

While on the surface this sounds reasonable, a deeper look reveals that this kind of approach presents significant risk for users and service providers. It runs counter to the clear trends in network communication, such as today's radical growth in broadband and wireless networks , and increased virtualization of corporate networks through use of public infrastructure. As a result of these trends, much network traffic is accessing corporate data centers from public networks rather than the private LAN, and the boundaries of the enterprise are expanding. Companies must grow by embracing these trends and fully leveraging public infrastructure and the power of the Internet.

Exactly.  Look at BT's 21CN network architecture as a clear and unequivocal demonstration of this strategy; a fantastic high-performance, resilient and reliable foundational transport coupled with an open, agile, flexible and equally high-performance and scalable security service layer.  If BT is putting 18 billion pounds of their money investing in a strategy like this and don't reckon they can rely on "embedded" security, why would you?

Network vendors are right in recognizing and trying to address the two fundamental challenges of network communications: application performance and security. However, they are wrong in believing the best way to address these concerns is to integrate application performance and security into the underlying network.

The alternative is to avoid building increasing intelligence into the physical network, which I call the connectivity lane, and building it instead into a higher-level plane I call the intelligence plane.                      

The connectivity plane covers end-to-end network connectivity in its broadest sense, leveraging IPv4 and eventually IPv6 . This plane's characteristics are packet-level performance and high availability. It is inherently insecure but incredibly resilient. The connectivity plane should be kept highly controlled and standardized, because it is heavy to manage and expensive to build and update. It should also be kept dumb, with change happening slowly.

He's on the money here again.  Let the network evolve at its pace using standards-based technology and allow innovation to deliver service at the higher levels.  The network evolves much more slowly and at a pace that demands stability.  The experientially-focused intelligence layer needs to be much more nimble and agile, taking advantage of the opportunism and the requirements to respond to rapidly emerging technologies and threat/vulnerabilities.

Look at how quickly solutions like DLP and NAC have stormed onto the market.  If we had to wait for Cisco to get their butt in gear and deliver solutions that actually work as an embedded function within the "network," we'd be out of business by now.

I don't have the time to write it again, but the security implications of having the fox guarding the henhouse by embedding security into the "fabric" is scary.  Just look at the number of security vulnerabilities Cisco has had in their routing, switching, and security products in the last 6 months.  Guess what happens when they're all one?   I sum it up here and here as examples.

Conversely, the intelligence plane is application centric and policy driven, and is an overlay to the connectivity plane. The intelligence plane is where you build relationships, security and policy, because it is flexible and cost effective. This plane is network independent, multi-vendor and adaptive, delivering applications and performance across a variety of environments, systems, users and devices. The intelligence plane allows you to extend the enterprise boundary using readily available public infrastructure. Many service and product vendors offer products that address the core issues of security and performance on the intelligence plane.

Connectivity vendors should focus their efforts on building faster, easier to manage and more reliable networks. Smart networks are good for vendors, not customers.

Wiser words have not been spoken...except by me agreeing with them, of course ;)  Not too shabby for an SSL VPN vendor way back in 2005.

Evan, I do hope you won't disappear and will continue to be an outspoken advocate of flushing the plumbing...best of luck to you and your team as you integrate into SonicWall.

/Hoff

Redux: Liability of Security Vulnerability Research...The End is Nigh!

I posited the potential risks of vulnerability research in this blog entry here.   Specifically I asked about reverse engineering and implications related to IP law/trademark/copyright, but the focus was ultimately on the liabilities of the researchers engaging in such activities.

Admittedly I'm not a lawyer and my understanding of some of the legal and ethical dynamics are amateur at best, but what was very interesting to me was the breadth of the replies from both the on and off-line responses to my request for opinion on the matter. 

I was contacted by white, gray and blackhats regarding this meme and the results were divergent across legal, political and ideological lines.

KJH (Kelly Jackson Higgins -- hey, Kel!) from Dark Reading recently posted an interesting collateral piece titled "Laws Threaten Security Researchers" in which she outlines the results of a CSI working group chartered to investigate and explore the implications that existing and pending legislation would have on vulnerability research and those who conduct it.  Folks like Jeremiah Grossman (who comments on this very story, here) and Billy Hoffman participate on this panel.

What is interesting is the contrast in commentary between how folks responded to my post versus these comments based upon the CSI working group's findings:

In the report, some Web researchers say that even if they find a bug accidentally on a site, they are hesitant to disclose it to the Website's owner for fear of prosecution. "This opinion grew stronger the more they learned during dialogue with working group members from the Department of Justice," the report says.

I believe we've all seen the results of some overly-litigious responses on behalf of companies against whom disclosures related to their products or services have been released -- for good or bad.

Ask someone like Dave Maynor if the pain is ultimately worth it.  Depending upon your disposition, your mileage may vary. 

That revelation is unnerving to Jeremiah Grossman, CTO and founder of WhiteHat Security and a member of the working group. "That means only people that are on the side of the consumer are being silenced for fear of prosecution," and not the bad guys.

...

"[Web] researchers are terrified about what they can and can't do, and whether they'll face jail or fines," says Sara Peters, CSI editor and author of the report. "Having the perspective of legal people and law enforcement has been incredibly valuable. [And] this is more complicated than we thought."

This sort of response didn't come across that way at all from folks who both privately or publicly responded to my blog; most responses were just the opposite, stated with somewhat of a sense of entitlement and immunity.   I expect to query those same folks again on the topic. 

Check this out:

The report discusses several methods of Web research, such as gathering information off-site about a Website or via social engineering; testing for cross-site scripting by sending HTML mail from the site to the researcher's own Webmail account; purposely causing errors on the site; and conducting port scans and vulnerability scans.

Interestingly, DOJ representatives say that using just one of these methods might not be enough for a solid case against a [good or bad] hacker. It would take several of these activities, as well as evidence that the researcher tried to "cover his tracks," they say. And other factors -- such as whether the researcher discloses a vulnerability, writes an exploit, or tries to sell the bug -- may factor in as well, according to the report.

Full disclosure and to whom you disclose it and when could mean the difference between time in the spotlight or time in the pokey!

/Hoff

For Data to Survive, It Must ADAPT...

Now that I've annoyed you by suggesting that network security will over time become irrelevant given lost visibility due to advances in OS protocol transport and operation, allow me to give you another nudge towards the edge and further reinforce my theories with some additionally practical data-centric security perspectives. 

If any form of network-centric security solution is to succeed in adding value over time, the mechanics of applying policy and effecting disposition on flows as they traverse the network must be made on content in context.  That means we must get to a point where we can make "security" decisions based upon information and its "value" and classification as it moves about.

It's not good enough to only make decisions on how flows/data should be characterized and acted on with the criteria being focused on the 5-tupule (header,) signature-driven profiling or even behavioral analysis that doesn't characterize the content in context of where it's coming from, where it's going and who (machine, virtual machine and "user") or what (application, service) intends to access and consume it. 

In the best of worlds, we like to be able to classify data before it makes its way though the IP stack and enters the network and use this metadata as an attached descriptor of the 'type' of content that this data represents.  We could do this as the data is created by applications (thick or thin, rich or basic) either using the application itself or by using an agent (client-side) that profiles the data prior to storage or transmission.

Since I'm on my Jericho Forum kick lately, here's how they describe how data ought to be controlled:

Access to data should be controlled by security attributes of the data itself.

• Attributes can be held within the data (DRM/Metadata) or could be a separate system.
• Access / security could be implemented by encryption.
• Some data may have “public, non-confidential” attributes.
• Access and access rights have a temporal component.

You would probably need client-side software to provide this functionality.  As an example, we do this today with email compliance solutions that have primitive versions of this sort of capability that force users to declare the classification of an email before you can hit the send button or even the document info that can be created when one authors a Word document. 

There are a bunch of ERM/DRM solutions in play today that are bandied about being sold as "compliance" solutions, but there value goes much deeper than that.  IP Leakage/Extrusion prevention systems (with or without client-side tie-ins) try to do similar things also.

Ideally, this metadata would be used as a fixed descriptor of the content that permanently attaches itself and follows that content around so it can be used to decide what content should be "routed" based upon policy.

If we're not able to use this file-oriented static metadata, we'd like then for the "network" (or something in/on it) to be able to dynamically profile content at wirespeed and characterize the data as it moves around the network from origin to destination in the same way.

So, this is where Applied Data & Application Policy Tagging (ADAPT) comes in.  ADAPT is an approach that uses some new technology to profile and characterize content (by using signatures, regular expressions and behavioral analysis in hardware) to then apply policy-driven traffic "routing" functionality as flows traverse the network by applying an ADAPT tag-header as a descriptor to each flow as it moves around the network.

The ADAPT tag could be fed by interpreting metadata attached to the data itself (if in file form) or dynamically by on-the-fly profiling.

Think of it like a VLAN tag the describes the data within the packet/flow.

This ADAPT tag is user defined and can use any taxonomy that best suits the types of content that is interesting; one might use asset classification such as "confidential" or uses taxonomies such as "HIPAA" or "PCI" to describe what is contained in the flows.  One could combine and/or stack the tags, too.

Then, as data moves across the network and across what we call boundaries (zones) of trust, the policy tags are parsed and disposition effected based upon the language governing the rules.

Just like an ACL for IP addresses of VLAN policies, ADAPT does the same thing for content routing.

To enable this sort of functionality, either every switch/router in the network would need to be ADAPT enabled (which would be difficult since you'd need every network vendor to support the protocols) OR you could use an overlay UTM security services switch sitting on top of the network plumbing through which all traffic moving from one zone to another would be subject to the ADAPT policy.

Since the only device that needs to be ADAPT aware is this UTM security service switch, you can let the network do what it does best and utilize this solution to enforce the policy for you across these boundary transitions.  Said UTM security service switch needs to have an extremely high-speed content security engine that is able to characterize the data at wirespeed and add a tag to the frame as it moves through the switching fabric and processed prior to popping out onto the network.

I'm going to be self-serving here and demonstrate this "theoretical" solution using a Crossbeam X80 UTM security services switch plumbed into a very fast, reliable, and resilient L2/L3 Cisco infrastructure.  It just so happens to have a wire-speed content security engine installed in it.  The reason the X-Series can do this is because once the flow enters its switching fabric, I own the ultimate packet/frame/cell format and can prepend any header functionality I like onto the structure to determine how it gets "routed."

Take the example below where the X80 is connected to the layer-3 switches using 802.1q VLAN trunked interfaces.  I've made this an intentionally simple network using VLANs and L3 routing; you could envision a much more complex segmentation and routing environment, obviously.

This network is chopped up into 4 VLAN segments:

1. General Clients (VLAN A)
2. Finance & Accounting Clients (VLAN B)
3. Financial Servers (VLAN C)
4. HR Servers (VLAN D)

Each of the clients/servers in the respective VLANs default routes out to an IP address which belongs to the firewall cluster IP addresses which is proffered by the firewall application modules providing service in the X80. 

Thus, to get from one VLAN to another VLAN, one must pass through the X80 and profiled by this content security engine and whatever additional UTM services are installed in the chassis (such as firewall, IDP, AV, etc.)

Let's say then that a user in VLAN A (General Clients) attempts to access one or more resources in the VLAN D (HR Servers.) 

Using solely IP addresses and/or L2 VLANs, let's say the firewall and IPS policies allow this behavior as the clients in that VLAN have a legitimate need to access the HR Intranet server.  However, let's say that this user tries to access data that exists on the HR Intranet server but contains personally identifiable information that falls under the governance/compliance mandates of HIPAA.

Let us further suggest that the ADAPT policy states the following:

Rule  Source                Destination            ADAPT Descriptor           Action
==============================================================

1        VLAN A             VLAN D                    HIPAA, Confidential        Deny
          IP.1.1               IP.3.1

2        VLAN B             VLAN C                    PCI                                 Allow
          IP.2.1             IP.4.1

Using rule 1 above, as the client makes the request, he transits from VLAN A to VLAN D.  The reply containing the requested information is profiled by the content security engine which is able to  characterize the data as containing information that matches our definition of either "HIPAA or Confidential" (purely arbitrary for the sake of this example.) 

This could be done by reading the metadata if it exists as an attachment to the content's file structure, in cooperation with an extrusion prevention application running in the chassis, or in the case of ad-hoc web-based applications/services, done dynamically.

According to the ADAPT policy above, this data would then be either silently dropped, depending upon what "deny" means, or perhaps the user would be redirected to a webpage that informs them of a policy violation.

Rule 2 above would allow authorized IP's in VLANs to access PCI-classified data.

You can imagine how one could integrate IAM and extend the policies to include pseudonymity/identity as a function of access, also.  Or, one could profile the requesting application (browser, for example) to define whether or not this is an authorized application.  You could extend the actions to lots of stuff, too.

In fact, I alluded to it in the first paragraph, but if we back up a step and look at where consolidation of functions/services are being driven with virtualization, one could also use the principles of ADAPT to extend the ACL functionality that exists in switching environments to control/segment/zone access to/from virtual machines (VMs) of different asset/data/classification/security zones.

What this translates to is a workflow/policy instantiation that would use the same logic to prevent VM1 from communicating with VM2 if there was a "zone" mis-match; as we add data classification in context, you could have various levels of granularity that defines access based not only on VM but VM and data trafficked by them.

Furthermore, assuming this service was deployed internally and you could establish a trusted CA with certs that would support transparent MITM SSL decrypts, you could do this (with appropriate scale) with encrypted traffic also.

This is data-centric security that uses the network when needed, the host when it can and the notion of both static and dynamic network-borne data classification to enforce policy in real-time.

/Hoff

[Comments/Blogs on this entry you might be interested in but have no trackbacks set:

MCWResearch Blog

Rob Newby's Blog

Alex Hutton's Blog

Security Retentive Blog

Network Intelligence is an Oxymoron & The Myth of Security Packet Cracking

[Live from Interop's Data Center Summit]

Jon Oltsik crafted an interesting post today regarding the bifurcation of opinion on where the “intelligence” ought to sit in a networked world: baked into the routers and switches or overlaid using general-purpose compute engines that ride Moore’s curve.

I think that I’ve made it pretty clear where I stand.   I submit that you should keep the network dumb, fast, reliable and resilient and add intelligence (such as security) via flexible and extensible service layers that scale both in terms of speed but also choice.

You should get to define and pick what best of breed means to you and add/remove services at the speed of your business, not the speed of an ASIC spin or an acquisition of technology that is neither in line with the pace and evolution of classes of threats and vulnerabilities or the speed of an agile business. 

The focal point of his post, however, was to suggest that the real issue is the fact that all of this intelligence requires exposure to the data streams which means that each component that comprises it needs to crack the packet before processing.   Jon suggests that you ought to crack the packet once and then do interesting things to the flows.  He calls this COPM (crack once, process many) and suggests that it yields efficiencies -- of what, he did not say, but I will assume he means latency and efficacy.

So, here’s my contentious point that I explain below:

Cracking the packet really doesn’t contribute much to the overall latency equation anymore thanks to high-speed hardware, but the processing sure as heck does!  So whether you crack once or many times, it doesn’t really matter, what you do with the packet does.

Now, on to the explanation…

I think that it’s fair to say that many of the underlying mechanics of security are commoditizing so things like anti-virus, IDS, firewalling, etc. can be done without a lot of specialization – leveraging prior art is quick and easy and thus companies can broaden their product portfolios by just adding a feature to an existing product.

Companies can do this because of the agility that software provides, not hardware.  Hardware can give you scales of economy as it relates to overall speed (for certain things) but generally not flexibility. 

However, software has it’s own Moore’s curve or sorts and I maintain that unfortunately its lifecycle, much like what we’re hearing @ Interop regarding CPU’s, does actually have a shelf life and point of diminishing return for reasons that you're probably not thinking about...more on this from Interop later.

John describes the stew of security componenty and what he expects to see @ Interop this week:

I expect network intelligence to be the dominant theme at this week's Interop show in Las Vegas. It may be subtle but its definitely there. Security companies will talk about cracking packets to identify threats, encrypt bits, or block data leakage. The WAN optimization crowd will discuss manipulating protocols and caching files, Application layer guys crow about XML parsing, XSLT transformation, and business logic. It's all about stuffing networking gear with fat microprocessors to perform one task or another.

That’s a lot of stuff tied to a lot of competing religious beliefs about how to do it all as Jon rightly demonstrates and ultimately highlights a nasty issue:

The problem now is that we are cracking packets all over the place. You can't send an e-mail, IM, or ping a router without some type of intelligent manipulation along the way.

<nod>  Whether it’s in the network, bolted on via an appliance or done on the hosts, this is and will always be true.  Here’s the really interesting next step:

I predict that the next bit wave in this evolution will be known as COPM for "Crack once, process many." In this model, IP packets are stopped and inspected and then all kinds of security, acceleration, and application logic actions occur. Seems like a more efficient model to me.

To do this, it basically means that this sort of solution requires Proxy (transparent or terminating) functionality.  Now, the challenge is that whilst “cracking the packets” is relatively easy and cheap even at 10G line rates due to hardware, the processing is really, really hard to do well across the spectrum of processing requirements if you care about things such as quality, efficacy, and latency and is “expensive” in all of those categories.

The intelligence of deciding what to process and how once you’ve cracked the packets is critical. 

This is where embedding this stuff into the network is a lousy idea. 

How can a single vendor possibly provide anything more than “good enough” security in a platform never designed to solve this sort of problem whilst simultaneously trying to balance delivery and security at line rate? 

This will require a paradigm shift for the networking folks that will either mean starting from scratch and integrating high-speed networking with general-purpose compute blades, re-purposing a chassis (like, say, a Cat65K) and stuffing it with nothing but security cards and grafting it onto the switches or stack appliances (big or small – single form factor or in blades) and graft them onto the switches once again.   And by the way, simply adding networking cards to a blade server isn't an effective solution, either.  "Regular" applications (and esp. SOA/Web 2.0 apps) aren't particularly topology sensitive.  Security "applications" on the other hand, are wholly dependent and integrated with the topologies into which they are plumbed.

It’s the hamster wheel of pain.

Or, you can get one of these which offers all the competency, agility, performance, resilience and availability of a specialized networking component combined with an open, agile and flexible operating and virtualized compute architecture that scales with parity based on Intel chipsets and Moore’s law.

What this gives you is an ecosystem of loosely-coupled BoB security services that can be intelligently combined in any order once cracked and ruthlessly manipulated as it passes through them governed by policy – and ultimately dependent upon making decisions on how and what to do to a packet/flow based upon content in context.

The consolidation of best of breed security functionality delivered in a converged architecture yields efficiencies that is spread across the domains of scale, performance, availability and security but also on the traditional economic scopes of CapEx and OpEx.

Cracking packets, bah!  That’s so last Tuesday.

/Hoff

Security: "Built-in, Overlay or Something More Radical?"

I was reading Joseph Tardo's (Nevis Networks) new Illuminations blog and found the topic of his latest post ""Built-in, Overlay or Something More Radical?" regarding the possible future of network security quite interesting.

Joseph (may I call you Joseph?) recaps the topic of a research draft from Stanford funded by the "Stanford Clean Slate Design for the Internet" project that discusses an approach to network security called SANE.   The notion of SANE (AKA Ethane) is a policy-driven security services layer that utilizes intelligent centrally-located services to replace many of the underlying functions provided by routers, switches and security products today:

Ethane is a new architecture for enterprise networks which provides a powerful yet simple management model and strong security guarantees.  Ethane allows network managers to define a single, network-wide, fine-grain policy, and then enforces it at every switch.  Ethane policy is defined over human-friendly names (such as "bob, "payroll-server", or "http-proxy) and  dictates who can talk to who and in which manner.  For example, a policy rule may specify that all guest users who have not authenticated can only use HTTP and that all of their traffic must traverse a local web proxy.

Ethane has a number of salient properties difficult to achieve with network technologies today.  First, the global security policy is enforced at each switch in a manner that is resistant to poofing.  Second, all packets on an Ethane network can be attributed back to the sending host and the physical location in which the packet entered the network.  In fact, packets collected in the past can also be attributed to the sending host at the time the packets were sent -- a feature that can be used to aid in auditing and forensics.  Finally, all the functionality within Ethane is provided by very simple hardware switches.       

The trick behind the Ethane design is that all complex functionality, including routing, naming, policy declaration and security checks are performed by a central controller (rather than in the switches as is done today).  Each flow on the network must first get permission from the controller which verifies that the communicate is permissible by the network policy.  If the controller allows a flow, it computes a route for the flow to take, and adds an entry for that flow in each of the switches along the path.       

With all complex function subsumed by the controller, switches in Ethane are reduced to managed flow tables whose entries can only be populated by the controller (which it does after each succesful permission check).  This allows a very simple design for Ethane       switches using only SRAM (no power-hungry TCAMS) and a little bit of logic.    

I like many of the concepts here, but I'm really wrestling with the scaling concerns that arise when I forecast the literal bottlenecking of admission/access control proposed therein.

Furthermore, and more importantly, while SANE speaks to being able to define who "Bob"  is and what infrastructure makes up the "payroll server,"  this solution seems to provide no way of enforcing policy based on content in context of the data flowing across it.  Integrating access control with the pseudonymity offered by integrating identity management into policy enforcement is only half the battle.

The security solutions of the future must evolve to divine and control not only vectors of transport but also the content and relative access that the content itself defines dynamically.

I'm going to suggest that by bastardizing one of the Jericho Forum's commandments for my own selfish use, the network/security layer of the future must ultimately respect and effect disposition of content based upon the following rule (independent of the network/host):

Access to data should be controlled by security attributes of the data itself.

• Attributes can be held within the data (DRM/Metadata) or could be a separate system.
• Access / security could be implemented by encryption.
• Some data may have “public, non-confidential” attributes.
• Access and access rights have a temporal component. 

 

Deviating somewhat from Jericho's actual meaning, I am intimating that somehow, somewhere, data must be classified and self-describe the policies that govern how it is published and consumed and ultimately this security metadata can then be used by the central policy enforcement mechanisms to describe who is allowed to access the data, from where, and where it is allowed to go.

...Back to he topic at hand, SANE:

As Joseph alluded, SANE would require replacing (or not using much of the functionality of) currently-deployed routers, switches and security kit.  I'll let your imagination address the obvious challenges with this design.

Without delving deeply, I'll use Joseph's categorization of “interesting-but-impractical”

/Hoff

NAC is a Feature not a Market...

I'm picking on NAC in the title of this entry because it will drive Alan Shimel ape-shit and NAC has become the most over-hyped hooplah next to Britney's hair shaving/rehab incident...besides, the pundits come a-flockin' when the NAC blood is in the water...

Speaking of chumming for big fish, love 'em or hate 'em, Gartner's Hype Cycles do a good job of allowing one to visualize where and when a specific technology appears, lives and dies as a function of time, adoption rate and utility.

We've recently seen a lot of activity in the security space that I would personally describe as natural evolution along the continuum, but is often instead described by others as market "consolidation" due to saturation. 

I'm not sure they are the same thing, but really, I don't care to argue that point.  It's boring.  It think that anyone arguing either side is probably right.  That means that Lindstrom would disagree with both. 

What I do want to do is summarize a couple of points regarding some of this "evolution" because I use my blog as a virtual jot pad against which I can measure my own consistency of thought and opinion.  That and the chicks dig it.

Without my usual PhD Doctoral thesis brevity, here are just a few network security technologies I reckon are already doomed to succeed as features and not markets -- those technologies that will, within the next 24 months, be absorbed into other delivery mechanisms that incorporate multiple technologies into a platform for virtualized security service layers:

1. Network Admission Control
2. Network Access Control
3. XML Security Gateways
4. Web Application Firewalls
5. NBAD for the purpose of DoS/DDoS
6. Content Security Accelerators
7. Network-based Vulnerability Assessment Toolsets
8. Database Security Gateways
9. Patch Management (Virtual or otherwise)
10. Hypervisor-based virtual NIDS/NIPS tools
11. Single Sign-on
12. Intellectual Property Leakage/Extrusion Prevention
    

...there are lots more.  Components like gateway AV, FW, VPN, SSL accelerators, IDS/IPS, etc. are already settling to the bottom of UTM suites as table stakes.  Many other functions are moving to SaaS models.  These are just the ones that occurred to me without much thought.

Now, I'm not suggesting that Uncle Art is right and there will be no stand-alone security vendors in three years, but I do think some of this stuff is being absorbed into the bedrock that will form the next 5 years of evolutionary activity.

Of course, some folks will argue that all of the above will just all be absorbed into the "network" (which means routers and switches.)  Switch or multi-function device...doesn't matter.  The "smoosh" is what I'm after, not what color it is when it happens.

What'd I miss?

/Hoff

(Written from SFO Airport sitting @ Peet's Coffee.  Drinking a two-shot extra large iced coffee)