Rational Survivability

NWC's Wittmann: Security in Virtualized Environments Overstated: Just Do It!

In the April, 2007 edition of Network Computing magazine, Art Wittmann talks about server virtualization, its impact on data center consolidation and the overall drivers and benefits virtualization offers. 

What's really interesting is that while he rambles on about the benefits of power, cooling and compute cycle-reclamation, he completely befuddled me with the following statement in which he suggests that:

    "While the security threat inherent in virtualization is
     real, it's also overstated."

I'll get to the meaty bits in a minute as to why I think this is an asinine comment, but first a little more background on the article.

In addition to illustrating everything wrong with the way in which IT has traditionally implemented security -- bolting it on after the fact rather than baking it in -- it shows the recklessness with which evangelizing the adoption of technology without an appropriate level of security is cavalierly espoused without an overall understanding of the impact of risk such a move creates.

Whittmann manages to do this with an attitude that seeks to suggest that the speed-bump security folks and evil vendors (or in his words: nattering nabobs of negativity) are just intent on making a mountain out of a molehill.

It seems that NWC approaches the evaluation of technology and products in terms of five areas: performance, manageability, scalability, reliability and security.  He lists how virtualization has proven itself in the first four categories, but oddly sums up the fifth category (security) by ranting not about the security things that should or have been done, but rather how it's all overblown and a conspiracy by security folks to sell more kit and peddle more FUD:

"That leaves security as the final question.  You can bet that everyone who can make a dime on questioning the security of virtualization will be doing so; the drumbeat has started and is increasing in volume. 

...I think it's funny that he's intimating that we're making this stuff up.  Perhaps he's only read the theoretical security issues and not the practical.  While things like Blue Pill are sexy and certainly add sizzle to an argument, there are some nasty security issues that are unique to the virtualized world.  The drumbeat is increasing because these threats and vulnerabilities are real and so is the risk that companies that "just do it" are going to discover.

But while the security threat is real --and you should be concerned about it -- it's also overstated.  If you can eliminate 10 or 20 servers running outdated versions of NT in favor of a single consolidated pair of servers, the task of securing the environment should be simpler or at least no more complex.  If you're considering a server consolidation project, do it.  Be mindful of security, but don't be dissuaded by the nattering nabobs of negativity."

As far as I am concerned, this is irresponsible and reckless journalism and displays an ignorance of the impact that technology can have when implemented without appropriate security baked in. 

Look, if we don't have security that works in non-virtualized environments, replicating the same mistakes in a virtualized world isn't just as bad, it's horrific.   While it should be simpler or at least no more complex, the reality is that it is not.  The risk model changes.  Threat vectors multiply.  New vulnerabilities surface.  Controls multiply.  Operational risk increases.

We end up right back where we started; with a mess that the lure of cost and time savings causes us to rush into without doing security right from the start.

Don't just do it. Understand the risk associated with what a lack of technology, controls, process, and policies will have on your business before your held accountable for what Whittmann suggests you do today with reckless abandon.  Your auditors certainly will. 

/Hoff

Rothman's Right: SIM/SEM/Log Consolidation Needs Flushing...

Mike Rothman reiterated his position on SIM/SEM tools the other day.  You may agree, you may not.

I took this picture a while ago at a location I won't disclose as I walked into the facilities as a visitor.

Please don't hold me accountable for either the state of the log consolidator (below) or its efficacy.  It would appear that this particular appliance is suffering from some sort of buffer overflow as the container is suffering from a lack of flush.

I find it apropos (if not somewhat disturbing):

I'm not sure Anton Chuvakin's going to like this ;)

/Hoff

Off to the UK Next Week @ InfoSec UK Show

I'll be in the UK all of next week (April 23rd-April 27th) for the InfoSec UK show.  I suppose this means that we've run out of anyone interesting, good looking or knowledgeable to send?

Crossbeam will be at Stand # G153

If anyone wants to get together for a chat, a pint or a good old-fashioned dust-up, let me know.  My mobile works in the UK, so ring me if you have the number...if not, find someone who does ;)

Ping me via email (hoff [@] crossbeamsys.com) and we'll get together for any of the above.  I'm dying for some good Curry.

/Hoff

Off Topic: My Mt. Kilimanjaro Climb and Global Warming?

Off-topic, non-security post.

My recent adventure involved climbing Mt. Meru and Mt. Kilimanjaro in Tanzania.  It was awesome.  I'm long overdue in blogging the event.

The reason that I and my 4 compadres decided to climb Kili was because of the "fact" that ultimately the glacial packs atop Kilimanjaro would shortly disappear.  Recent forecasts suggested that within 10 years they would be completely gone.

So, imagine my surprise when we summited in -25 degrees (F) to come face to face with this 100 foot tall monster @ nearly 20,000 feet.  It was truly an awesome  spectacle.

I was expecting a small bit of snow and some compacted ice forms.  I didn't expect 80-100 foot glacial ice fields! 

Pair that with a current BBC article that suggests that ultimately the glaciers will be around for at least 30-40 years and while I'm not discounting the global warming effect, I am happy to note that these magnificent walls of ice will be here for at least a while longer.

This is great news.  I'm glad that it's not as bad as was originally forecasted because it's an awesome sight after 8 hours of the summit deathmarch slog; hopefully my kids will be able to join me if I do it again and we can see it together.

/Hoff

I want to have Gunnar Peterson's Baby (His SOA posts are the schizzle!)

I really look forward to reading Gunnar Peterson's blog.  He's got a fantastic writing style and communicates in an extremely effective form about one of my favorite topics SOA and security. His insightful posts really get to the point in a witty and meaningful way.  I'm going to try to make one of the OWASP meetings he is presenting at soon.

Gunnar made a fantastic post commenting on Arnon Rotem-Gal-Oz's writings on Service Firewall Patterns, but within the context of this discussion, his comments regarding the misalignment of developers, network folks, security practitioners and enterprise architects is well said:

One of my issues with common practice of enterprise architecture is that they frequently do not deep dive into security issues, instead focusing scalability, detailed software design, and so on. But here is the thing - the security people don't know enough about software design, and the software people don't know enough about security to really help out.

Sadly, this is very true.  It goes back to the same line of commentary I've also made in this regard.  The complexity of security is rising unchecked and all the policy in the world isn't going to help when the infrastructure is not capable of solving the problem and neither are the people who administer it.

Add to this the reality that many security mechanisms cannot make a business case as a one off project, but need to be part of core infrastructure to be economic, and wel[l], you get the situation we have today.

Exactly.  While this may not have been Gunnar's intention, this description of why embedding security functionality into the "network" and expecting packet jockeys to apply a level of expertise they don't have to solving security problems "in the network" as a result of economic cram-down is going to fail.

The architects define the "what", and unless security is one of those whats, it is not feasible to make the case for many specialized security services at a project by project level. This is why, enterprise architects that enable increased integration within and across enterprises, must also invest time and resources in revamping security services that enable this to be done in a reliable fashion.

...but sadly to Gunnar's point above, just as security people don't know enough about software design and software people don't know enough about security, enterprise architects often don't know what they don't know about networking or security.  The problem is systemic and even with the best intentions in mind, an architect rarely gets the opportunity to ensure that after the blueprints are handed down, that the "goals" for security are realized in an operational model consistent with the desired outcome.

I'm going to post separately on Rotem-Gal-Oz's Service Firewall Pattern shortly as there are tremendous synergies between what he suggests we should do and, strangely, the exact model we use to provide a security service layer (in virtualized gateway form) to provide this very thing.

/Hoff

No excuse for not shredding those credit card offers...Hamster Powered Shredder!

Saw this on Boing-Boing. Click on the picture.

There's now no excuse for not shredding those unsolicited
credit card offers that show up in the mail.  This works on
report cards, too, kids!

It's eco-friendly, makes its own bedding/toilet, entertains
your kids, able to turn vege-left overs into leveraged mechanical advantage, and gosh-darn it, it's so damned cute!

That's right, folks.  The coolest hack, evah!  Hamster-powered shredder!

That's Web2.0, baby...

Did I hurt your feelings? I'm OK, You're OK...

In the NY times this morning, I read an article titled "A Call for Manners in the World of Nasty Blogs" wherein the author posits whether it's "...too late to bring civility to the Web?"  I found it online here.

Pairing this article with various allusions and outright claims that I've been less than "civil" lately in the manner in which I publicly interact with other security "professionals," especially when they let their butt hang out, I paused for a moment to contemplate the article and the underlying message it sought to communicate.

I further contemplated messages from fellow bloggers who want to encourage meaningful, supportive and positive dialogue within our community instead of provoking or otherwise poking those with whom we disagree.  I took this to heart and thought long and hard about this.

No, really.  I did.

I realized several things, denied about 6 others, and thought diligently about seeking therapy regarding my unhealthy obsession with gym socks and pickled herring.

I concluded a couple of things:

1. The Internet is indeed a "...prickly and unpleasant place."  There's www.kittenwar.com where the vile mediator of all things cuddly and feline suggests "May the Cutest Kitten Win!" but I'm not sure that really counts.

 

2. There are two types of people in the world.  Those that blog and read blogs and those that visit www.kittenwar.com.

 

3. "Recent outbreaks of antagonism..." describes my encounters daily with my local Starbucks Barista.  Posting my opinion wherein someone lets their butt hang out is reasonable, warranted, sometimes juvenile and above all, fun.

 

4. The community that is the Internet is self-policing.  We kick ass when we need to and let the whole unregulated bunch ramble on as due course.  Sometimes people throw their toys out of the pram, but that happens in grade school -- the Internet's no different.

 

5. Mr. O'Reilly and Mr. Wales should stick to allowing and ensuring the freedom of speech, not refereeing it.   I didn't vote for them.  Did you?

 

6. If, as Siskel and Eibert above get their way, I'll have to rate my blog indicating "the principles...and what kind of behavior and dialogue [my blog will] will engage in.  I liken that to the L.A. County Dept. of Health certifications on restaurants...while you certainly have a CHOICE not to eat at a restaurant with a 'D' rating, you'd miss every fantastic Vietnamese Pho restaurant this side of Delaware just because of a little E-Coli.  Likewise, with this rating system, you'd miss all the best blogs out there!

 

7. Turn off anonymous blogging or weed through the posts.  Nobody said blogs were themselves administered as a democracy.  You don't like it, delete it.  That's an instantiation of free speech, too...mine.

 

8. Last time I looked, nobody tapes peoples eye's open and makes them read my blog.  There is that group of folks in Gitmo, but they swear it's just mild hazing.

 

9. It occurs to me that what seems to be at issue here is actually ANONYMOUS blogging.  Fine.  Turn the feature off.  Require registration and then  folks can face those that annoy them.
   

    

10. Civility is not the same thing as criminality or vulgarity, just to clear that up.

Just to be clear, the reaction by Mr's. Wales and O'Reilly that were flamed by recent events are understandable, and the utter lunacy and despicable nature of the threats and taunts that Kathy Sierra endured are unconscionable.  Nobody deserves that sort of harassment when lines are crossed and physical violence is threatened.

Look, O'Reilly's "Blogger Code of Conduct" isn't all that bad, and quite honestly I abide by most of the "code" as a function of being a reasonable human being and a rational contributor.  Those items highlighted I find relevant, the rest, not so much:

• We take responsibility for our own words and for the comments we allow on our blog.
• We won't say anything online that we wouldn't say in person.
• We connect privately before we respond publicly.
• When we believe someone is unfairly attacking another, we take action.
• We do not allow anonymous comments.
• We ignore the trolls.

That said, whether "free speech is enhanced by civility" or not is irrelevant.  Free means unencumbered to me. In fact, here's the Wikipedia definition of "Free Speech":

Freedom of speech is the concept of the inherent human right to voice one's opinion publicly without fear of censorship or punishment. The right is enshrined in the United Nations Universal Declaration of Human Rights and is granted formal recognition by the laws of most nations. Nonetheless the degree to which the right is upheld in practice varies greatly from one nation to another.

In many nations, particularly those with relatively authoritarian forms of government, overt government censorship is enforced. Censorship has also been claimed to occur in other forms (see propaganda model) and there are different approaches to issues such as hate speech, obscenity, and defamation laws even in countries seen as liberal democracies.

I'd like it very much if we can just leave the "community" to self-police itself and not infringe on my ability to write what I like, when I like it about whomsoever I like to write about. 

That's just my uncivil opinion.

[Ed. I found Tristan Louis' dissection of O'Reilly's draft "Blogger's Code of Conduct" quite interesting.]

/Hoff

Intellectual Property/Data Leakage/Content Monitoring & Protection - Another Feature, NOT a Market.

Besides having the single largest collection of vendors that begin with the letter 'V" in one segment of the security space (Vontu, Vericept, Verdasys, Vormetric...what the hell!?) it's interesting to see how quickly content monitoring and protection functionality is approaching the inflection point of market versus feature definition.

The "evolution" of the security market marches on.

Known by many names, what I describe as content monitoring and protection (CMP) is also known as extrusion prevention, data leakage or intellectual property management toolsets.  I think for most, the anchor concept of digital rights management (DRM) within the Enterprise becomes glue that makes CMP attractive and compelling; knowing what and where your data is and how its distribution needs to be controlled is critical.

The difficulty with this technology is the just like any other feature, it needs a delivery mechanism.  Usually this means yet another appliance; one that's positioned either as close to the data as possible or right back at the perimeter in order to profile and control data based upon policy before it leaves the "inside" and goes "outside."

I made the point previously that I see this capability becoming a feature in a greater amalgam of functionality;  I see it becoming table stakes included in application delivery controllers, FW/IDP systems and the inevitable smoosh of WAF/XML/Database security gateways (which I think will also further combine with ADC's.)

I see CMP becoming part of UTM suites.  Soon.

That being said, the deeper we go to inspect content in order to make decisions in context, the more demanding the requirements for the applications and "appliances" that perform this functionality become.  Making line speed decisions on content, in context, is going to be difficult to solve. 

CMP vendors are making a push seeing this writing on the wall, but it's sort of like IPS or FW or URL Filtering...it's going to smoosh.

Websense acquired PortAuthority.  McAfee acquired Onigma.  Cisco will buy...?

/Hoff

More On the Risks of Virtualization

I've been doing a bit of writing and speaking on panels recently on the topic of virtualization and the impact that it has across the entire spectrum of risk; I think it's fairly clear to most that virtualization impacts all aspects of the computing landscape, from the client to the data center and ultimately how securing virtualization by virtualizing security is important.

Gartner just released an interesting article that says "Organizations That Rush to Adopt Virtualization Can Weaken Security."   Despite the sensationalism that some people react to in the title, I think that the security issues they bring up are quite valid. 

I'm glad to see that this study almost directly reflects the talking points that we've been puttering on about without any glaring omissions as it validates the problem space; it doesn't take a rocket scientist to state the obvious, but I hope we get solutions to these problems quickly. 

Granted these are fairly well-known issues but most folks have not looked deeply into how this affects their overall risk models:

Organizations must consider these security issues in virtualized environments:

• Virtualization software, such as hypervisors, represent a new layer of privileged software that will be attacked and must be protected.
• The loss of separation of duties for administrative tasks, which can lead to a breakdown of defense in-depth.
• Patching, signature updates, and protection from tampering for offline VM and VM "appliance" images.
• Patching and secure confirmation management of VM appliances where the underlying OS and configuration are not accessible.
• Limited visibility into the host OS and virtual network to find vulnerabilities and assess correct configuration.
• Restricted view into inter-VM traffic for inspection by intrusion prevention systems (IPSs).
• Mobile VMs will require security policy and settings to migrate with them.
• Immature and incomplete security and management tools.

I'm going to be presenting something very similar at the ISSA Metro event in Charlotte on April 10th.  I'll upload my presentation ahead of time for anyone who might find it useful or interesting.

/Hoff

It's a sNACdown! Cage Match between Captain Obvious and Me, El Rational.

CAUTION:  I use the words "Nostradramatic prescience" in this blog posting.  Anyone easily offended by such poetic buggery should stop reading now.  You have been forewarned.

That's it.  I've had it.  I've taken some semi-humorous jabs at Mr. Stiennon before, but my contempt for what is just self-serving PFD (Pure F'ing Dribble) has hit an all time high.  This is, an out-and-out, smackdown.  I make no bones about it.

Richard is at it again.  It seems that stating the obvious and taking credit for it has become an art form. 

Richard expects to be congratulated for his prophetic statements that are basically a told-you-so to any monkey dumb enough to rely only on Network Admission Control (see below) as his/her only security defense.  Furthermore, he has the gaul to suggest that by obfuscating the bulk of the arguments made to the contradiction of his point, he wins by default and he's owed some sort of ass-kissing:

And for my fellow bloggers who I rarely call out using my own blog: are you ready to retract your "founded on quicksand" statements and admit that you were wrong and Stiennon was right once again?  :-)

Firstly, there's a REASON you "rarely call out" other people on your blog, Richard. It has something to do with a lack of frequency of actually being right, or more importantly others being wrong.  

I mean the rest of us poor ig'nant blogger folk just cower in the shadows of your earth-shattering predictions for 2007: Cybercrime is on the rise, identify theft is a terrible problem, attacks against financial services companies will increase and folks will upload illegal videos to YouTube. 

I'm sure the throngs of those who rise up against Captain Obvious are already sending their apology Hallmarks.  I'll make sure to pre-send those congratulatory balloons now so I can save on shipping, eh?

Secondly, suggesting that others are wrong when you only present 1/10th of the debate is like watching two monkeys screw a football.  It's messy, usually ends up with one chimp having all the fun and nobody will end up wanting to play ball again with the "winner."  Congratulations, champ.

What the heck am I talking about?  Way back when, a bunch of us had a debate concerning the utility of NAC.  More specifically, we had a debate about the utility, efficacy and value of NAC as part of an overall security strategy.  The debate actually started between Richard and Alan Shimmel. 

I waded in because I found them both to be right and both to be wrong.  What I suggested is that NAC by ITSELF is not effective and must be deployed as part of a well-structured layered defense.  I went so far as to  suggest that Richard's ideas that the network 'fabric' could also do this by itself were also flawed.  Interestingly, we all agreed that trusting the end-point ALONE to report on its state and gain admission to the network was a flawed idea.

Basically, I suggested that securing one's assets came down to common sense, the appropriate use of layered defense in both the infrastructure and on top of it and utilizing NAC when and how appropriate.  You know, rational security.

The interesting thing to come out of that debate is that to Richard, it became clear that the acronym "NAC" appeared to only mean Network ADMISSION Control.  Even more specifically, it meant Cisco's version of Network ADMISSION Control.  Listen to the Podcast.  Read the blogs.  It's completely one dimensional and unrealistic to group every single NAC product and compare it to Cisco.  He did this intentionally so as to prove an equally one dimensional point.  Everyone already knows that pre-admission control is nothing you solely rely on for assured secure connectivity.

To the rest of us who participated in that debate, NAC meant not only Network ADMISSION Control, but also Network ACCESS Control...and not just Cisco's which we all concluded, pretty much sucked monkey butt.  The problem is that Richard's assessment of (C)NAC is so myopic that he renders any argument concerning NAC (both) down to a single basal point that nobody actually made.

It goes something like this and was recorded thusly by his lordship himself from up on high on a tablet somewhere.  Richard's "First Law of Network Security":

Thou shalt not trust an end point to report its own state

Well, no shit.  Really!?  Isn't it more important to not necessarily trust that the state reported is accurate but take the status with a grain of salt and use it as a component of assessing the fitness of a host to participate as a citizen of the network?   Trust but verify?

Are there any other famous new laws of yours I should know about?  Maybe like:

Thou shalt not use default passwords
Thou shalt not click on hyperlinks in emails
Thou shalt not use eBanking apps on shared computers in Chinese Internet Cafes
Thou shalt not deploy IDS' and not monitor them
Thou shalt not use "any any any allow" firewall/ACL rules
Thou shalt not allow SMTP relaying
Thou shalt not use the handle hornyhussy in the #FirewallAdminSingles IRC channel

{By the way, I think using the phrase '...shalt not' is actually a double-negative?} [Ed: No, it's not]

Today Richard blew his own horn to try and reinforce his Nostradramatic prescience when he commented on how presenters at Blackhat further demonstrated that you can spoof reporting compliance checks of an end-point to the interrogator using Cisco's NAC product using a toolkit created to do just that. 

Oh, the horror!  You mean Malware might actually fake an endpoint into thinking it's not compromised or spoof the compliance in the first place!?  What a novel idea.  Not.  Welcome to the world of amorphous polymorphic malware.  Been there, done that, bought the T-Shirt.  AV has been dealing with this for quite a while.  It ain't new.  Bound to happen again.

Does it make NAC useless.  Nope.  Does it mean that we need greater levels of integrity checking and further in-depth validation of state.  Yep.   'Nuff said. 

Let me give you Hoff's "First Law of Network Security" Blogging:

Thou shalt not post drivel bait, Troll.

It's not as sexy sounding as yours, but it's immutable, non-negotiable and 100% free of trans-fatty acids.

/Hoff

(Written from the lobby of the Westford Regency Hotel.  Drinking...nothing, unfortunately.)

The Philosophy of Network Security Design

Thomas and I were barking at each other regarding something last night and today he left a salient and thought-provoking comment that provided a very concise, pragmatic and objective summation of the embedded vs. overlay security quagmire:

     "I think the jury is still out on how much security policy we   
     should be pushing to middleboxes, and how smart those   
     middleboxes should be. What I know right now is we spend
     way, way too much time, effort, and money on 19" rack
     mountable chasses that suck in packets and spit them back
     out again without providing any measurable impact on the
     security of our networks.  Not a fan."

I couldn't agree more.  Most of the security components today, including those that run in our little security ecosystem, really don't intercommunicate.  There is no shared understanding of telemetry or instrumentation and there's certainly little or no correlation of threats, vulnerabilities, risk or disposition.

The problem is bad inasmuch as even best-of-breed solutions usually require box sprawl and stacking and don't necessarily provide for a more secure posture, especially within context of another of Thomas' interesting posts on defense in depth/mesh...

That's changing, however.  Our latest generation of NPMs (Network Processing Modules) allow discrete security ISV's (which run on intelligently load-balanced Application Processor Modules -- Intel blades in the same chassis) to interact with and control the network hardware through defined API's -- this provides the first step in that common telemetry such that while application A doesn't need to know about the specifics of application B, they can functionally interact based upon the common output of disposition and/or classification of flows between them.

Later, they'll be able to perhaps control each other through the same set of API's.

So, I don't think we're going to solve the interoperability issue completely anytime soon inasmuch as we'll go from 0 to 100%, but I think that the consolidation of these functions into smaller footprints that allow for intelligent traffic classification and disposition is a first good step.

I don't expect Thomas to agree or even resonate with my statements below, but I found his explanation of the problem space to be dead on.  Here's my explanation of an incremental step towards solving some of the bigger classes of problems in that space which I believe hinges on consolidation of security functionality first and foremost.

The three options for reducing this footprint are as follows:

1. Proprietary Embedded security in routers/switches (Cisco, Juniper)
   
   Pros: Supposedly less boxes, better communication between components and good coverage
   given the fact that the security stuff is in the infrastructure.  One vendor from which you get
   your infrastructure and your protection.  Correlation across the network "fabric" will ultimately
   allow for near-time zoning and quarantine.  Single management pane across the Enterprise
   for availability and security.  Did I mention the platform is already there?
   
   Cons: You rely on a single vendor's version of the truth and you get closer to a monoculture
   wherein the safeguards protecting the network put at risk the very assets they seek to protect
   because there is no separation of "church and state."  Also, the expertise and coverage as well
   as the agility for product development based upon evolving threats is hampered by the many
   moving parts in this machine.  Utility vs Security?  Utility wins.  Good enough vs. Best of breed?
   Probably somewhere in between.

 

2. Proprietary Overlay security in a Consolidated Platform (Fortinet 5000, Tipping Point, etc.)
   
   Pros:  Reduced footprint, consolidated functionality, single management pane across multiple
   security functions within the box.  Usually excels in one specific area like AV and can add "good enough" functionality as the needs arise.  Software moves up and down the scalability stack depending upon performance needed.
   
   Cons:  You again rely on a single vendor's version of the truth.  These boxes tend to want to replace switching infrastructure.  Many of these platforms utilize ASICs to accelerate certain functions with the bulk of functionality residing in pure software with limited application or network-level intelligence.  You pay the price in terms of performance and scale given the architectures of these boxes which do not easily allow for the addition of new classes of solutions to thwart new threats.  Not really routers/switches.

 

3. Open Overlay security in a Consolidated Platform (Crossbeam)
   
   Pros:  The customer defines best of breed and can rapidly add new security functionality
   at a speed that keeps pace with the threats the customer needs to mitigate.  Utilizing a scalable and high-performance switching architecture combined with all the benefits
   of an open blade-based security application/appliance delivery mechanism gives the best of all
   worlds: self-healing, highly resilient, high performance and highly-available while utilizing
   hardened Linux OS across load-balanced, virtualized security applications running on optimized
   hardware.
   
   Cons: Currently based upon proprietary (even though Intel reference design) hardware for
   the application processing while also utilizing proprietary networking switching fabric and
   load balancing.  Can only offer software as quickly as it can be adapted and tested on the
   platforms.  No ASICs means small packet performance @ 64byte zero loss isn't as high as
   ASIC based packet-forwarding engines.  No single pane of management.

I think that option #3 is a damned good start towards solving the consolidation issues whilst balancing the need to overlay syngergistically with the network infrastructure.  You're not locked into single vendor's version of the truth and although the hardware may be "proprietary," the operating system and choice in software is not.  You can choose from COTS, Open Source or write your own, all in an scaleable platform that is just as much a collapsed switching/routing platform as it is a consolidated blade server.

I think it has the best chance of evolving to solve more classes of problems than the other two at a rate and level of cost-effectiveness balanced with higher efficacy due to best of breed.

This, of course, depends upon how high the level of integration is between the apps -- or at least their dispositions.  We're working very, very hard on that.

At any rate, Thomas ended with:

"I am a believer in freezing development of the core protocols and building new functionality on top of them. I like NAT. I like Paul Francis. I think the IETF has been hijacked by the leftovers from the OSI standards committees. I don't know what you call that philosophy, besides "end2end originalist".

I like NAT.  I think this is Paul Francis.  The IETF has been hijacked by aliens, actually, and I'm getting a new tattoo:

I Think Cobia's a Great Idea...Despite Shimel's Rabid Frothing to the Contrary...

[Ed: I want to add something here...I think people should pay attention to Cobia for lots of reasons; some of them are apparent and others cause eyebrows and shoulders to shrug.  Just like when Astaro announced their "Virtual Security Appliance" that I barfed all over because of egregiously overarching claims to revolutionary impact in the security market, one must consider the audience and motivation for creating a "product" like this.

I think folks should pay attention to Cobia because it continues to provoke discussion and debate surrounding where, how and why security is positioned in the network not to mention stirring interesting discussions regarding the definition of Open Source...]

--

Look, I think Cobia is compelling, creative, valuable and very interesting and I think people should pay attention to it.  I think it's a great idea and I know that Mitchell, Alan and Martin (and the rest of the team) will make it successful.

Alan's statements to the contrary are just wrong and are overly controversial -- unfortunately at the expense of a reasonable debate on an issue central to security today.  I love him, but I suggest he needs Ritalin today!

The SME/SMB market is ripe for this sort of utility, but again, while the packaging and components are put together in new and interesting ways, the underlying framework is not.  That's not a bad thing, but again, forging yet another market classification in an already fractured industry is potentially difficult for everyone.

The WhistleJet from 1999 was a very similar model.  Sure, it wasn't open source and it didn't run on a VM, but it was a very similar model.

I really didn't want to bring up this point, because it seems contrived and snarky at this point, but it's interesting that much of what is being presented with Cobia is already done in our boxes.  I have no interest in starting a pissing match because there's no reason to as Cobia serves a different marketspace than we do and blending utility applications (even though we can) with dedicated security applications isn't in our interest or business model.

Mitchell even sees some value in running Cobia on Crossbeam. 

Again, I think Cobia is an interesting idea and well-timed for the SME/SMB.  I think it's very cool and if you're in the market for this solution you should definitely look at it.

I'm done arguing about something I wasn't arguing about in the first place.

/Hoff

On Flying Pigs, DNSSEC, and embedded versus overlaid security...

I found Thomas Ptacek's comments regarding DNSSEC deliciously ironic not for anything directly related to secure DNS, but rather a point he made in substantiating his position regarding DNSSEC while describing the intelligence (or lack thereof) of the network and application layers.

This may have just been oversight on his part, but it occurs to me that I've witnessed something on the order of a polar magnetic inversion of sorts.  Or not.  Maybe it's the coffee.  Ethiopian Yirgacheffe does that to me.

Specifically, Thomas and I have debated previously about this topic and my contention is that the network plumbing ought to be fast, reliable, resilient and dumb whilst elements such as security and applications should make up a service layer of intelligence running atop the pipes. 

Thomas' assertions focus on the manifest destiny that Cisco will rule the interconnected universe and that security, amongst other things, will -- and more importantly should -- become absorbed into and provided by the network switches and routers.

While Thomas' arguments below are admittedly regarding the "Internet" versus the "Intranet," I maintain that the issues are the same.  It seems that his statements below which appear to endorse the "...end-to-end argument in system design" regarding the "...fundamental design principle of the Intenet" are at odds with his previous aspersions regarding my belief.  Check out the bits in red.

Here's what Thomas said in "A Case Against DNSSSEC (A Matasano Miniseries):

...You know what? I don’t even agree in principle. DNSSEC is a bad thing, even if it does work.

How could that possibly be?

It violates a fundamental design principle of the Internet.

Nonsense. DNSSEC was designed and endorsed by several of the architects of the Internet. What principle would they be violating?

The end-to-end argument in system design. It says that you want to keep the Internet dumb and the applications smart. But DNSSEC does the opposite. It says, “Applications aren’t smart enough to provide security, and end-users pay the price. So we’re going to bake security into the infrastructure.”

I could have sworn that the bit in italics is exactly what Thomas used to say.  Beautiful.  If, Thomas truly agrees with this axiom and that indeed the Internet (the plumbing) is supposed to be dumb and applications (service layer) smart, then I suggest he should revisit his rants regarding how he believes the embedding security in the nework is a good idea since it invalidates the very "foundation" of the Internet.

I wonder what that'll do internal networks? 

That's all.  CSI is on.

/Hoff

(Written @ Home drinking Yirgacheffe watching UFC re-runs)

If it walks like a duck, and quacks like duck, it must be...?

Seriously, this really wasn't a thread about NAC.  It's a great soundbite to get people chatting (arguing) but there's a bit more to it than that.  I didn't really mean to offend those NAC-Addicts out there.

My last post was the exploration of security functions and their status (or even migration/transformation)  as either a market or feature included in a larger set of features.  Alan Shimel responded to my comments; specifically regarding my opinion that NAC is now rapidly becoming a feature and won't be a competitive market for much longer. 

Always the quick wit, Alan suggested that UTM was a "technology" that is going to become a feature much like my description of NAC's fate.  Besides the fact that UTM isn't a technology but rather a consolidation of lots of other technologies that won't stand alone, I found a completely orthogonal statement that Alan made to cause my head to spin as a security practitioner. 

My reaction stems from the repeated belief that there should be separation of delivery between the network plumbing, the security service layers and ultimately the application(s) that run across them.  Note well that I'm not suggesting that common instrumentation, telemetry and disposition shouldn't be collaboratively shared, but their delivery and execution ought to be discrete.  Best tool for the job.

Of course, this very contention is the source of much of the disagreement between me and many others who believe that security will just become absorbed into the "network."  It seems now that Alan is suggesting that the model of combining all three is going to be something in high demand (at least in the SME/SMB) -- much in the same way Cisco does:

The day is rapidly coming when people will ask why would they buy a box that all it does is a bunch of security stuff.  If it is going to live on the network, why would the network stuff not be on there too or the security stuff on the network box.

Firstly, multi-function devices that blend security and other features on the "network" aren't exactly new.

That's what the Cisco ISR platform is becoming now what with the whole Branch Office battle waging, and back in '99 (the first thing that pops into my mind) a bunch of my customers bought and deployed WhistleJet multi-function servers which had DHCP, print server, email server, web server, file server, and security functions such as a firewall/NAT baked in.

But that's neither here nor there, because the thing I'm really, really interested in Alan's decidedly non-security focused approach to prioritizing utility over security, given that he works for a security company, that is.

I'm all for bang for the buck, but I'm really surprised that he would make a statement like this within the context of a security discussion.

That is what Mitchell has been talking about in terms of what we are doing and we are going to go public Monday.  Check back then to see the first small step in the leap of UTM's becoming a feature of Unified Network Platforms.

Virtualization is a wonderful thing.  It's also got some major shortcomings.  The notion that just because you *can* run everything under the sun on a platform doesn't always mean that you *should* and often it means you very much get what you pay for.  This is what I meant when I quoted Lee Iacocca when he said "People want economy and they will pay any price to get it."

How many times have you tried to consolidate all those multi-function devices (PDA, phone, portable media player, camera, etc.) down into one device.  Never works out, does it?  Ultimately you get fed up with inconsistent quality levels, you buy the next megapixel camera that comes out with image stabilization.  Then you get the new video iPod, then...

Alan's basically agreed with me on my original point discussing features vs. markets and the UTM vs. UNP thing is merely a handwaving marketing exercise.  Move on folks, nothing to see here.

'nuff said.

/Hoff

(Written sitting in front of my TV watching Bill Maher drinking a Latte)