Archive

Archive for the ‘Networking’ Category

Quick Post of a Virtualization Security Presentation: “Virtualization and the End of Network Security As We Know It…”

August 20th, 2007 7 comments

Virtualizationagenda
"Virtualization and the End of Network Security As We Know It…
The feel good hit of the summer!"

Ye olde blog gets pinged quite a lot with searches and search engine redirects for folks looking for basic virtualization and virtualized security information. 

I had to drum up a basic high-level virtualization security presentation for the ISSA Charlotte Metro gathering back in April and I thought I may as well post it.

It’s in .PDF format.  If you want it in .PPT or Keynote, let me know, I’ll be glad to send it to you.  If it’s useful or you need some explanation regarding the visual slides, please get back to me and I’ll be more than glad to address anything you want.  I had 45 minutes to highlight how folks were and might deal with "securing virtualization by virtualizing security."

Yes, some of it is an ad for the company I used to work for who specializes in virtualized security service layers (Crossbeam) but I’m sure you can see how it is relevant in the preso.  You’ll laugh, you’ll cry, you’ll copy/paste the text and declare your own brilliance.  Here’s the summary slide so those of you who haven’t downloaded this yet will know the sheer genius you will be missing if you don’t:

Issavirtualization034

At any rate, it’s not earth shattering but does a decent job at the high level of indicating some of the elements regarding virtualized security. I apologize for the individual animation slide page build-ups.  I’ll re-upload without them when I can get around to it. (Ed: Done.  I also uploaded the correct version 😉

Here’s the PDF.

/Hoff

(As of 11pm EST — 5.5 hours later 1:45pm EST the next day, you lot have downloaded this over 150 380 times.  Since there are no comments, it’s either the biggest piece of crap I’ve ever produced or you are all just so awe stricken you are unable to type.  Newby, you are not allowed to respond to this rhetorical question…)

Cisco Responds to My Data Center Virtualization Post…

July 24th, 2007 2 comments

Cisco
"…I will squash him like a liiiiittle bug, that Hoff!"

OK, well they weren’t responding directly to my post from last night, but as they say in the big show, "timing is everything."

My last blog entry detailed some navel gazing regarding some interesting long term strategic moves by Cisco to further embrace the virtualized data center and the impact this would have on the current and future product roadmaps.  I found it very telling that Chambers will be keynoting at this year’s VMWorld and what this means for the future.

Not 8 hours after my posting (completely coincidental I’m sure 😉 the PR machine spit out the following set of announcements from Networkers Cisco Live titled "Cisco Unveils Plans to Transform the Data Center."    You can find more detailed information from Cisco’s web here.

This announcement focused on outlining some of the near-term (2 year) proofpoints and touts the introduction of "…New Data Center Products, Services and Programs to Support a Holistic View of the Data Center." 

There’s an enormous amount of data to digest in this announcement, but the interesting bits for me to focus on are the two elements pertaining to security virtualization as well as service composition, provisioning and intelligent virtualized service delivery.   This sort of language is near and dear to my heart.

I’m only highlighting a small subsection of the release as there is a ton of storage, data mobility, multiservice fabric and WAAS stuff in there too.  This is all very important stuff, but I wanted to pay attention to the VFrame Data Center orchestration platform and the ACE XML security gateway functions since they pertain to what I have been writing about recently:

If you can choke back the bile from the  "Data Center v3.0" moniker:

…Cisco announced at a press conference today its
vision for
next-generation data centers, called Data Center 3.0. The
Cisco vision for
Data Center 3.0 entails the real-time, dynamic orchestration
of
infrastructure services from shared pools of virtualized
server, storage
and network resources, while optimizing application performance,
service
levels, efficiency and collaboration.

Over the next 24 months, Cisco will deliver innovative new
products,
programs, and capabilities to help customers realize the
Cisco Data Center
3.0 vision. New products and programs announced today support
that vision,
representing the first steps in helping customers to create
next-generation
data centers.

Cisco VFrame Data Center

VFrame Data Center (VFrame DC) is an orchestration platform
that leverages
network intelligence to provision resources together as
virtualized
services. This industry-first approach greatly reduces application
deployment times, improves overall resource utilization,
and offers greater
business agility. Further, VFrame DC includes an open API,
and easily
integrates with third party management applications, as
well as
best-of-breed server and storage virtualization offerings.

With VFrame DC, customers can now link their compute, networking
and
storage infrastructures together as a set of virtualized
services. This
services approach provides a simple yet powerful way to
quickly view all
the services configured at the application level to improve
troubleshooting
and change management. VFrame DC offers a policy engine
for automating
resource changes in response to infrastructure outages and
performance
changes. Additionally, these changes can be controlled by
external
monitoring systems via integration with the VFrame DC web
services
application programming interface (API).

I think that from my view of the world, these two elements represent a step in the right direction for Cisco.  Gasp!  Yes, I said it.  While Chambers prides himself on hyping Cisco’s sensitivity to "market transitions" it’s clear that Cisco gets that virtualization across both the network, host and storage is actually a real market.  They’re still working the security piecem however they, like Microsoft, mean business when they enter a space and it’s no doubt they’re swinging to fences with VFrame. 

I think the VFrame API is critical and how robust it is will determine the success of VFrame.  It’s interesting that VFrame is productized as an appliance, but I think I get what Chambers is going to be talking about at VMWorld — how VFrame will interoperate/interact with VMWare provisioning and management toolsets. 

Interestingly, the UI and template functionality looks a hell of a lot like some others I’ve blogged about and is meant to provide an umbrella management "layer" that allows for discovery, design, provisioning, deployment and automation of services and virtualized components across resource pools of servers, network components, security and storage:

Cisco VFrame Data Center components include:

  • Cisco VFrame Data Center Appliance: Central controller that connects to Ethernet and Fibre Channel networks
  • Cisco VFrame Data Center GUI: Java-based client that accesses application running on VFrame Data Center Appliance
  • Cisco VFrame Web Services Interface and Software Development Kit:
    Programmable interface that allows scripting of actions for Cisco
    VFrame Data Center
  • Cisco VFrame Host Agent: Host agent that provides server heartbeat,
    capacity utilization metrics, shutdown, and other capabilities
  • Cisco VFrame Data Center Macros: Open interface that allows administrators to create custom provisioning actions

That’s ambitious to say the least.

It’s still a raucous debate with me regarding where a lot of this stuff belongs (in the network or as a service layer) and I maintain the latter.  Innovation driven by companies such as 3Tera demonstrate that the best ideas are always copied by the 800 pound gorillas once they become mainstream.

Enhanced Cisco ACE XML Gateway Software

The new Cisco Application Control Engine (ACE) Extensible
Markup Language
(XML) Gateway software delivers enhanced capabilities for
enabling secure
Web services, providing customers with better management,
visibility, and
performance of their XML applications and Web 2.0 services.
The new
software includes a wide variety of new capabilities and
features plus
enhanced performance monitoring and reporting, providing
improved
operations and capacity planning for Web services secured
by the Cisco ACE
XML Gateway.

I’d say this is a long overdue component for Cisco; since Chambers has been doing nothing but squawking about Web2.0, collaboration, etc., the need to integrate XML security into the security portfolio is a must, especially as we see XML as the Internet-based messaging bus for just about everything these days.

All in all I’d say Cisco is doing a good job of continuing to push the message along and while one shouldn’t see this faint praise as me softening my stance on Cisco’s execution potential, it’s yet to be seen if trying to be everything to everyone will deliver levels of service commensurate with what customers need.

Only time will tell.

/Hoff

 

Categories: Cisco, Networking, Virtualization Tags:

Network Security is Dead…It’s All About the Host.

May 28th, 2007 6 comments

Securitycomputer2No, not entirely as it’s really about the data, but
I had an epiphany last week. 

I didn’t get any on me, but I was really excited about the — brace yourself — future of security in a meeting I had with Microsoft.  It reaffirmed my belief that while some low-hanging security fruit will be picked off by the network, the majority of the security value won’t be delivered by it.

I didn’t think I’d recognize just how much of it — in such a short time — will ultimately make its way back into the host (OS,) and perhaps you didn’t either.

We started with centralized host-based computing, moved to client-server.  We’ve had Web1.0, are in the  beginnings of WebX.0 and I ultimately believe that we’re headed back to a centralized host-based paradigm now that the network transport is fast, reliable and cheap.

That means that a bunch of the stuff we use today to secure the "network" will gravitate back towards the host. I’ve used Scott McNealy’s mantra as he intended it to in order to provide some color to conversations before, but I’m going to butcher it here. 

While I agree that in abstract the "Network is the Computer," in order to secure it, you’re going to have to treat the "network" like an OS…hard to do.   That’s why I think more and more security will make its way back to the actual
"computer" instead.

So much of the strategy linked to large security vendors sees an increase in footprint back on the host.  It’s showing back up there today in the guise of AV, HIPS, configuration management, NAC and Extrusion Prevention, but it’s going to play a much, much loftier role as time goes on as the level of interaction and interoperability must increase.  Rather than put 10+ agents on a box, imagine if that stuff was already built in?

Heresy, I suppose.

I wager that the "you can’t trust the endpoint" and "all security will make its way into the switch" crowds will start yapping on this point, but before that happens, let me explain…

The Microsoft Factor

Vista_box_2
I was fortunate enough to sit down with some of the key players in Microsoft’s security team last week and engage in a lively bit of banter regarding some both practical and esoteric elements of where security has been, is now and will be in the near future. 

On the tail of Mr. Chambers’ Interop keynote, the discussion was all abuzz regarding collaboration and WebX.0 and the wonders that will come of the technology levers in the near future as well as the, ahem, security challenges that this new world order will bring.  I’ll cover that little gem in another blog entry.

Some of us wanted to curl up into a fetal position.  Others saw a chance to correct material defects in the way in which the intersection of networking and security has been approached.  I think the combination of the two is natural and healthy and ultimately quite predictable in these conversations.

I did a bit of both, honestly.

As you can guess, given who I was talking to, much of what was discussed found its way back to a host-centric view of security with a heavy anchoring in the continued evolution of producing more secure operating systems, more secure code, more secure protocols and strong authentication paired with encryption.

I expected to roll my eyes a lot and figured that our conversation would gravitate towards UAC and that a bulk-helping of vapor functionality would be dispensed with the normal disclaimers urging "…when it’s available one day" as a helping would be ladled generously into the dog-food bowls the Microsofties were eating from.

I am really glad I was wrong, and it just goes to show you that it’s important to consider a balanced scorecard in all this; listen with two holes, talk with one…preferably the correct one 😉

I may be shot for saying this in the court of popular opinion, but I think Microsoft is really doing a fantastic job in their renewed efforts toward improving security.  It’s not perfect, but the security industry is such a fickle and bipolar mistress — if you’re not 100% you’re a zero.

After spending all this time urging people that the future of security will not be delivered in the network proper, I have not focused enough attention on the advancements that are indeed creeping their way into the OS’s toward a more secure future as  this inertia orthogonally reinforces my point.

Yes, I work for a company that provides network-centric security offerings.  Does this contradict the statement I just made?  I don’t think so, and neither did the folks from Microsoft.  There will always be a need to consolidate certain security functionality that does not fit within the context of the host — at least within an acceptable timeframe as the nature of security continues to evolve.  Read on.

The network will become transparent.  Why?

In this brave new world, mutually-authenticated and encrypted network communications won’t be visible to the majority of the plumbing that’s transporting it, so short of the specific shunts to the residual overlay solutions that will still be present to the network in forms of controls that will not make their way to the host, the network isn’t going to add much security value at all.

The Jericho EffectJerichoeps_2

What I found interesting is that I’ve enjoyed similar discussions with the distinguished fellows of the Jericho Forum wherein after we’ve debated the merits of WHAT you might call it, the notion of HOW "deperimeterization," "reperimeterization," (or my favorite) "radical externalization,"  weighs heavily on the evolution of security as we know it.

I have to admit that I’ve been a bit harsh on the Jericho boys before, but Paul Simmonds and I (or at least I did) came to the realization that my allergic reaction wasn’t to the concepts at hand, but rather the abrasive marketing of the message.  Live and learn.

Both sets of conversations basically see the pendulum effect of security in action in this oversimplification of what Jericho posits is the future of security and what Microsoft can deliver — today:

Take a host with a secured OS, connect it into any network using whatever means you find
appropriate, without regard for having to think about whether you’re on the "inside" or "outside." Communicate securely, access and exchange data in policy-defined "zones of trust" using open, secure, authenticated and encrypted protocols.

If you’re interested in the non-butchered more specific elements of the Jericho Forum’s "10 Commandments," see here.

What I wasn’t expecting in marrying these two classes of conversation is that this future of security is much closer and notably much more possible than I readily expected…with a Microsoft OS, no less.   In fact, I got a demonstration of it.  It may seem like no big deal to some of you, but the underlying architectural enhancements to Microsoft’s Vista and Longhorn OS’s are a fantastic improvement on what we have had to put up thus far.

One of the Microsoft guys fired up his laptop with a standard-issue off-the-shelf edition of Vista,  authenticated with his smartcard, transparently attached to the hotel’s open wireless network and then took me on a tour of some non-privileged internal Microsoft network resources.

Then he showed me some of the ad-hoc collaborative "People Near Me" peer2peer tools built into Vista — same sorts of functionality…transparent, collaborative and apparently quite secure (gasp!) all at the same time.

It was all mutually authenticated and encrypted and done so transparently to him.

He didn’t "do" anything; no VPN clients, no split-brain tunneling, no additional Active-X agents, no SSL or IPSec shims…it’s the integrated functionality provided by both IPv6 and IPSec in the NextGen IP stack present in Vista.

And in his words "it just works."   Yes it does.

He basically established connectivity and his machine reached out to an reachable read-only DC (after auth. and with encryption) which allowed him to transparently resolve "internal" vs. "external" resources.  Yes, the requirements of today expect that the OS must still evolve to prevent exploit of the OS, but this too shall become better over time.

No, it obviously doesn’t address what happens if you’re using a Mac or Linux, but the pressure will be on to provide the same sort of transparent, collaborative and secure functionality across those OS’s, too.

Allow me my generalizations — I know that security isn’t fixed and that we still have problems, but think of this as a half-glass full, willya!?

One of the other benefits I got form this conversation is the reminder that as Vista and Longhorn default to IPv6 natively (they can do both v4&v6 dynamically,) as enterprises upgrade, the network hardware and software (and hence the existing security architecture) must also be able to support IPv6 natively.  It’s not just the government pushing v6, large enterprises are now standardizing on it, too.

Here are some excellent links describing the Nextgen IP stack in Vista, the native support for IPSec (goodbye VPN market,) and IPv6 support.

Funny how people keep talking about Google being a threat to Microsoft.  I think that the network giants like Cisco might have their hands full with Microsoft…look at how each of them are maneuvering.

/Hoff
{ Typing this on my Mac…staring @ a Vista Box I’m waiting to open to install within Parallels 😉 }

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

April 30th, 2007 2 comments

Virtualprotection_dog
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

UNP = Unecessary New Paradigm?

February 21st, 2007 6 comments

Unp [I have a backlog of blog posts due to my 2 weeks on the road.  Excuse my trip into last week.]

During our UTM Smackdown panel @ RSA, Alan Shimel from StillSecure
kept hinting (okay, yelling) about StillSecure’s upcoming product
announcement regarding their bringing a UTM solution to market.

Firstly, I think that’s great, because as I agreed, the natural
evolution of (Enterprise) UTM includes the integration of functionality such as NAC, VA/VM, etc., and StillSecure’s
products are top-notch, so I expect another excellent product from the
boys from Colorado. 

I also know that Alan and Mitchell really know
their market well and do a fantastic job with product management and
marketing within this space.  But Alan/Mitchell’s announcement has me puzzled because there’s some serious amount
of verbiage being tossed about here that’s ignoring a whole lot of reality that even the best marketing distortion field can’t obfuscate.

I found it interesting on Alan’s blog
that actually what he meant to say is that StillSecure intends to bring
a “new” type of product to market that isn’t described as UTM at all –
in fact, Mitchell Ashley (StillSecure’s CTO – and hopefully he won’t
get mad when I call him a friend) is attempting to define both a new paradigm and market segment that they call Unified Network
Platform, or UNP.  See here for Mitchell’s whitepaper and description of UNP.

UNP should not, however, be confused with UPN, the television network that brought you such hits as “Moesha.

UNP is defined as "…a new paradigm for addressing the needs of network and security functions.  Breaking the mold of the proprietary vendor hardware appliance solution, UNP provides an open platform architecture consisting of open software and general purpose hardware, enabling the convergenceof network applications."

The Model is illustrated graphically by this diagram which looks surprisingly similar to the Carrier Grade Linux group’s model and almost identical to the Crossbeam X-Series architecture:

Tcnmodel_3Clever marketing, for sure, but as I pointed out to Alan at the
Smackdown, short of the new title, neither the model nor the approach
is new at all.  In many aspects of how Alan described his new product line, it’s exactly what we do @ Crossbeam.  I was intrigued, for sure.

Apart from some semantic issues surrounding the use of open source
to the exclusion of COTS and swearing off any potential benefits of optimized hardware, Mitchell’s definition of UNP attempts to
re-brand concepts and a technology approach that’s quite familiar to me.

The model as defined by Mitchell seems to lay claim to an operational and technology integration
model that has been defined already as the foundation for Next
Generation Networks (NGN) that is at the core of the designs
IMS/converged network working groups (and VMWare’s virtual appliance
model for that matter) and call it UNP.

I really don’t get the novelty here.

Virtualization? Check.  Software is the key?  Check.  "Proprietary" hardware versus OTS hardware?

Who gives a crap!?  If the cost of a product and its positioning within the network is justified by the performance, scale, availability of software choice as defined by the user and the appropriate reduction of risk, then it seems to me that the only people who need to make the argument complaining about "proprietary" hardware are those that don’t have any…

I agree that the advance of OTS hardware and multi-core technology is yielding amazing value for the dollar spent and much of the hardware solutions today are commoditized at birth, but I maintain that there is a point of diminishing returns at which even today’s multi-core processors experience limits of memory and I/O (not to mention the ability of the software itself to take advantage of) that is specific to the market into which solutions are designed to operate.

You’ll get no argument from me that software is the secret sauce in the
security space and even in Crossbeam’s case, the hardware is a means to
an end, so if integrating FPGA’s and optimized network processing
hardware provides for hyper-performance of standard Intel reference
designs, ‘splain to me how that’s a bad thing?

I suggest that UNP is an interesting perspective and sheds light
on the “convergence” of security functionality and virtual appliances
for the SME/SMB market, but new it ain’t, and this sort of solution does not fly in the large enterprise, service provider or mobile operator.  It’s also a little odd and
naive to suggest that this is a “network” platform approach that will
rival dedicated networking functions at anything but the SME/SMB level.

Now, I’m not trying to assail Mitchell’s efforts or creativity here,
nor am I suggesting that this is not an interesting way to try and
distance StillSecure from the other 1000 me-too FW, nee IPS nee
small-office UTM fray, but there’s also a danger in trying to create
distinction in an already acronym-burdened industry and come off
looking like your doing something completely new.

I had a point-by-point response to Mitchell’s summary points of his whitepaper, but as I reviewed it I realized that this would come across as one of those enormous Hoff posts — not to mention it read as a Crossbeam versus StillSecure manifesto…and given that Alan’s into his kinder, gentler stage, I reckoned I’d give it a go, too.

…we’ll see how long that lasts.

/Hoff

Upchuck, Shrubbery, Bumps-in-the-wire & Alan does the “Shimmy”

January 13th, 2007 6 comments

Overlaidvembedded
Alan and I normally are close enough on our positions that I don’t feel it necessary to argue with him.

I certainly don’t feel compelled to come to the defense of a competitor that Alan’s unloading on, but I’m really confused about his interpretation of what TippingPoint’s Chief Architect, Brian Smith, is communicating and where Alan suggests that he and StillSecure’s position lays.

To re-cap, Brian Smith was quoted in an SC Magazine Article as describing his views on how security ought to be positioned in the network thusly:

"Brian Smith, the chief architect of 3Com and a
founder of TippingPoint, says his first-ever RSA keynote will focus on
integrating solutions such as network access control, intrusion
prevention and behavioral anomaly detection to create an intelligent
network.

"I can do all of these sorts of synergies and when you trace it
out, what ends up happening is you’re able to debug network problems
that you were never able to do before, get an unprecedented level of
security, and also lower the total cost of ownership," Smith says.
"They have to talk to each other. If we can pull all of these solutions
together, I think that’s going to be the trend over the next five to 10
years. It’s a natural evolution in the technology cycle."

Smith says he also plans to emphasize the benefits of the
bump-in-the-wire network approach to deploying security solutions.
Rather than embedding solutions into switchers and routers, Smith plans
to suggest overlaying solutions to allow for a more converged, cheaper
way to add intelligence to the network."

Amen to that.  But lest you think I am intimating that we should all just toss appliances willy-nilly across the network (in fact, that’s the opposite of what I think,) please read on…

Apparently it was the third (boldfaced) paragraph that got Alan’s goat and provoked him into a state of up-chuckedness.  Specifically, it seems that it is repugnant to Alan that someone who works for a "switch" company could suggest that overlaying security can be facilitated as a "bump-in-the wire."  I guess that depends upon your interpretation of "bump-in-the-wire." 

I’m guessing that Alan thinks that means individual appliances being inserted between network segments with one "goesinta" and one "goesouta" cable and yet I can’t figure out why  "…virtualizing some of this stuff and putting it on blades and so forth" has to be within the router or switch and not on an extensible services platform?

I have a feeling I’m going to hear the typical "not everyone can afford big iron" as a response…but if you can generalize to prove a point, I can become surgical and suggest that it’s not fair to treat the Global 2000, Carriers, Service Providers and Mobile Operators as an exception rather than the rule when it comes to describing security trends and markets, either.

Summarily, it appears that the "convergence" of networking and security in Alan’s eyes means that security functionality MUST be integrated into routers and switches in order to be successful and that adding security functionality on top of or in conjunction with the network is a lousy idea.

Strange comments from a guy whose company takes generic PC appliances  with security software on them and deploys them as bumps in the wire by sprinkling them across the network — usually at the cursed perimeter and not at the core.  Confused?  So am I.

Alan goes on:

Most of the guys who do the bump in the wire are trying like hell to
move up the stack and the network to get away from the edge to the
core.  You may be able to do IPS as a bump in the wire at the core if
you have the horsepower, but you are going to be forced to the edge for
other security stuff if you insist on bump in the wire.  Single point
of failure, scalability and cost are just working against you.
Eventually you have to turn to the switch. I just don’t get where he is
coming from here.

So you’re saying that your business model is already dead, Alan?

The final piece of irony is this:

Has selling big-ass, honking ASIC boxes to do IPS for so long totally
blinded them to virtualizing some of this stuff and putting it on
blades and so forth inside the switch and network.

Um, no. Again, not like I feel any inclination to defend Tippingpoint, but it’s apparent that Alan is not aware of TippingPoint’s M60 which is a huge multi-gigabit LAN switching platform (10-14 slots) with integrated IPS (and other functionality) that can either replace a typical switch or connect to existing switch fabrics to form an overlay security service.  It’s about a year overdue from the last announcement, but the M60 is an impressive piece of iron:M60

Each blade in the M60 acts as a stand-alone IPS device, similar to
TippingPoint’s T-series appliances, in which network connectivity and
IPS packet processing are done on the hardware. (The exception is with
10G interfaces; the M60 uses 3Com’s 8800 dual-port 10G blades, which
connect to TippingPoint IPS blades through the switch’s backplane.)

The blades run 3Com’s TippingPoint IPS device operating system and use the vendor’s Digital Vaccine updating service, letting  the device identify the latest threat signatures and vulnerabilities.

This was one of the results of the Huawei joint venture with 3Com.  I believe that THIS is really what Brian Smith is talking about, not device sprinkling appliances.  It’s  a switch.  It’s an IPS.  That’s bad, how?

What has me confused is that if Alan is so against hanging security services/functions OFF a switch, why did StillSecure do the deal with Extreme Networks in which the concept is to hang an appliance (the Sentriant AG) off the switch as an appliance instead of "inside" it like he suggests is the only way to effectively demonstrate the convergence of networking and security?

So, I totally get Brian Smith’s comments (despite the fact that he’s a competitor AND works for a switch vendor — who, by the way, also OEM’d Crossbeam’s X-Series Security Services Switches prior to their Tippingpoint acquisition!)

The model is valid.  Overlaying security as an intelligent service layer on top of the network is a great approach.  Ask me how I know. 😉

Chris

People Are Tools…Not Appliances

December 13th, 2006 2 comments

AppliancesAlan Shimel is commenting here on his blog in this post titled "People are not appliances they’re flexible."  In this entry he muses on about vocational "flexibility" and what appears to be the "cosmic humanity" of folks in the IT/Security space.

He also keeps talking about the need to keep buying COTS hardware appliances…he’ll never learn!

Specifically, Alan’s argument (which is orthogonal to the actual topic) is that as specialized appliances proliferate, he disagrees with the fact that the operators and administrators of said appliances must also specialize.  In fact, he waxes on about the apparent good-natured ebb and flow of utilitarian socialism and how ultimately we’re all re-trainable and can fluidly move from one discipline to another irrespective of the realities and vagaries of culture and capability.

Using that as an example it seems that a help-desk admin who deploys patches from one appliance can just pick up and start doing IDS analysis on another?  How about that same  "appliance" technician reading PCI for dummies and starting to manage firewall appliances doing policy manipulation?  Sure, they’re re-trainable, but at what incidental cost?  Seems a little naive of a statement for my tastes.

Mike Murray from nCircle on the other hand suggests that Enterprises inherently gravitate toward silos.  I totally agree — emphatically as we speak about larger Enterprises.  Operationalizing anything within a big machine means that you have political, operational and economic silos occuring naturally.  It’s even a byproduct of compliance, separation of duties and basic audit-output mitigation strategies.  Specializing may be "bad" but it’s what happens. 

Appliances don’t cause this, the quest for money or the love of what you do, does.

Even if Alan ignores the fact that you don’t have to keep buying individual appliances (you can consolidate them) the fact is that different elements within the organization manage the functions on them.   Even on our boxes…when you have firewall, IDP and AV in an X80 chassis, three different groups (perhaps more) manage and operate these solutions.  Silos, each and every one of them.

Nature of the beast.

That being said, this doesn’t mean I don’t disagree that I’d *like* to see more cross-functional representation across solution sets, but it’s just not reality:

Evolution teaches us that too specialized a species is a recipe for
extinction. That is what we need from our appliance models, flexibility
and adaptability, not more silos!  We need to break down the silos and
have interaction among them to improve productivity.

One could take that argument and extrapolate it to explain why people are so polarized on certain issues such as (for example) security and its ultimate place in the Enterprise: in the network or in specialized appliances.   

Innovation, specialization and (dare I say) evolution suggests that survival of the "fittest" can also be traced back to the ability to not just "survive" but thrive based upon the ability to adapt in specificity to what would otherwise be an extinguishing event.  Specialization does not necessarily infer it’s a single temporal event.  The cumulative or incremental effect of successive specialization can also provide an explanation for how things survive.  Take the platypus as an example.  It ended up with a beaver’s tail and a duck’s bill.  Go figure. 😉

What’s important here is the timing of this adaptation and how the movie plays forward.

Hoff

Crossbeam To Exit Security Market — Will Re-focus On Selling Pet Supplies On-line

November 5th, 2006 1 comment

Ptacek
Firstly, I really like debating elements with Ptacek.  He’s a really, really smart guy.  Somewhat misguided, but a really, really smart guy.  I’m honored that he picks on me.  Really. 

He picked on Bejtlich the other day.  Given this association, I believe I have solved the Poincaré conjecture which has something to do with math, intractability and doughnuts.  Mmmmm.  Doughnuts.

Here, he mentions in response to my post regarding my Chicago presentation, that Cisco will crush Crossbeam.  Privately he gave me a date and time, but I told him that I wouldn’t repeat when because it might affect his Cisco stock value.

Secondly, I can only giggle about Thomas’ choice for his blog entry title ("Cisco can kill Crossbeam any time it wants…") relating how Cisco will assimilate us all…I remember that same Borg-like prediction about how Microsoft would crush the Linux movement and how no other OS would stand a chance.

I believe Thomas is still using a Mac today…

At any rate, I started with Crossbeam almost exactly a year ago.  The funny thing about crossing over from a security practitioner to working for a security vendor is that all your credibility goes out the window instantly.

I get this, it’s part of the game, but I refuse to bow to the notion that the last 15 years of my life and the credibility it has earned is erased by this singular event, so I go on assuming that my opinions count as they always have – like the paper they’re written on.

Almost always, I end up arguing with people who have either only been a vendor or an analyst and short of securing their home networks have never actually been a CISO of a company whose assets have monetary value with the word “billions” preceeding it.  I have.  I argue from that point and the beliefs that come from that perspective.  Yes, I am biased.  I was before I came to Crossbeam, too.

The one thing that makes it difficult to sort out addressing someone who is as long-winded as I am is figuring out which parts of the debate are religious, marketing, technical or dogma.

Thomas is obviously reacting to my post playing the role of Cisco’s VP of Marketing, despite his disclaimers to the opposite.  I will answer disguised as a cabaret dancer from Ohio.  I hope that’s not confusing.  If nothing I say makes sense, I’ll just ask you to rent the movie “Showgirls” and you’ll forget all about this security nonsense.

So I’ve read his retort to my post/presentation, and I’m going to respond to the things I think are worth responding to because a good chunk of his posting doesn’t really address my points – they defend Cisco’s misses.  Yet I digress…

Ptacek starts out all right, doing a good job of summarizing the sentiment of both my post and my presentation:

Chris’ argument has three salients:

  • Cisco’s Self-Defending Network Architecture (the successor to SAFE) is just marketecture.
  • Cisco hasn’t put its money where its mouth is on integration of security into its mainline platforms (the Cat and routers).
  • Security belongs at a “service layer”, virtualized over the entire network, not as point-deployed boxes (IPS) or embedded into the infrastructure (IPS blade).

I really could just stop here because I’ve yet to find anyone (besides Thomas) who would actually disagree with any of those points, so why continue? 😉

But, he did, so I will…

1.    Is SDNA “marketecture”? Of course it is. SDNA is code for “sole-source network security from Cisco”. Sniping at SDNA’s credibility is as silly as sniping at the Cisco SAFE architecture in 2001: absolutely nobody designs networks according to these “schemes”. SDNA is a “why we did it” story that is retrofit onto Cisco’s evolving product lines to make it seem like they have strong management and a real vision.

Roger that.  SDNA = marketing.  Being opportunistic marketing-wise = vision.  Check.

But Chris’ argument isn’t about SDNA. It’s about whether enterprises should sole-source from Cisco, with around $1b in security sales, or consider vendors like Crossbeam that post sales less than 8% of that.

That’s right, my argument is that you shouldn’t sole-source your security solutions from a single vendor who claims competency in 15+ categories of security without demonstrating it, ever, except with a checkbook.

Also, just to double-check, Thomas, in Cisco math, a $200,000 Cat6500 switch with two FWSM blades is still $200,000 of “security sales,” right?   Uh-huh.  How about those “negative margin” deals…

That’s a fine argument to make, but if you’re going to build it on Cisco’s inability to run a real playbook, you can’t cherry pick Cisco’s weakest messages. SDNA may be meaningless. NAC isn’t. Even if it doesn’t work yet, it’s actionable and it’s changed the way people think about securing their network, and when Cisco buys the company that can really deliver on it for large enterprises, NAC is going to cause Crossbeam huge headaches.

Cherry-pick their weakest message?  SDNA is their message, Thomas!   DVVM and Quad-play is dependent upon this underlying message that “security is the network.”  I didn’t make this up, Cisco did.

You just contradicted yourself hugely.  In the first paragraph you said that “…absolutely nobody designs networks according to these “schemes”” but somehow that’s affected the way in which folks secure their networks!?  You’re right…they take a look at the Cisco method and realize it doesn’t work and look for other solutions.

Also, I just love the “…you just wait until Cisco buys something that actually works” sentiment!

By the way, Crossbeam doesn’t have to fear when Cisco gets NAC working (which is the most hysterical comment you’ve made,) because we can simply get a best-of-breed partners’ NAC application running on our platforms…no cash, no development, no fuss.  In fact, we are already in the process of doing that.

Furthermore, when you say NAC, you mean CNAC.  But which CNAC are you referring to?  The one that didn’t completely pan-out (CSA) or the new-and-improved Clean Access?  You know, the same Clean Access that requires ANOTHER appliance to be added to the network to function and is purdy much a Cisco-only solution…

2.    If you’re an indie network security vendor with a pulse, the idea of Cisco embedding IPS and firewalls into every Cat switch and access router puts you in a cold sweat. Is Cisco full of shit about this plan? Reasonable people will disagree, but the answer will be “no”.

See, I don’t think they’re full of shit.  I just think they’re not a security company and aren’t executing on their vision in a manner consistent with the customers they serve outside of the SMB.  The Enterprise strategy is showing cracks and they are very distracted across an immense portfolio.  They’re trying to re-group on the convergence front, but there’s pressure there, too.  All the while, security plods on.

First, the existence proof: the ISR. Large enterprises buy them by the hundreds. It’s one of Cisco’s most successful products ever. And it’s a direct threat to the branch/satellite-office market that is the primary revenue multiplier for indie perimeter security vendors —- Crossbeam’s bread and butter.

The ISR is fantastic…and if you’re a branch/satellite-office company I’d suggest it’s a very good product – still only provides limited security functionality and that’s why Cisco sells ASA’s with them.

Also, if you’re suggesting that the SMB/Branch perimeter is Crossbeam’s “bread and butter” you are completely and absolutely incorrect.  90% of our revenue comes from Large enterprise data center consolidation and service provider/MSSP/mobile operator customers.  Your definition of the “perimeter” needs work as does your understanding of what we do…again.

Cisco does more than $10b a year in Cat switching alone; by revenue, their grip on that market is comparable to Microsoft’s lock on operating systems. All it takes for Cisco to launch completely integrated network security is a credible ASA blade for the Cat6k. How far out can that be? Enterprises already buy the Firewall Switch Module.

Actually, the ASA isn’t their answer to the aging FWSM, the ACE and VSA are…and it’s got a long way to go.   By the way, who said that I’m suggesting we’re out to crush Cisco?  Beating them where they do a lousy job is a very nice living by your own math above.  How far out?  You’ll have to ask them.

The 6500 series is old in the tooth and if you read Gartner’s recent 2006 MQ for Campus LAN, their darling Cisco takes some serious knocks.  That includes the security piece.  Gasp!

And finally there’s the obvious point to be made about NAC and Cisco Security Agent, the alien larvae Cisco is trying implant into host security. NAC is a lot of bad things, but “un-integrated” is not one of them.

You’re right, but you forget that "un-integrated (?)" does not equal “functional.”  You’re also a couple of months late on this argument already…please see above.  I think your a little out-of-date on where Cisco is with CNAC…please see the report above for a very interesting look at the Gartner report.

Basically, every indie vendor has a talking point about how Cisco should just stick to the connectivity that they’re good at. This stuff all sounds good at first, but c’mon. Cisco doesn’t own connectivity because they make the best routers and switches. To claim that their routing (perimeter) and switching (internal) real estate doesn’t give them a dominant position in security is to claim that the perimeter and internal networks aren’t implicated in security. Delusional.

A dominant position or an advantage in hocking their wares because there’s some box that might be a platform to deploy it someday or today in pieces?  I’d say the latter.  Where is my bottle of Zoloft, anyway?

I agree, they haven’t done it yet, but I’ll make a statement that’s sure to get me yelled at: as soon as Cisco decides it’s ready, it can end companies like Crossbeam, Checkpoint, and SourceFire within 18 months. Isn’t not doing that, and running security as a totally seperate business unit, one of the big mistakes they made in the 90s?

Oh, OK.  They haven’t because instead of feeding the hungry, bestowing Linksys DSL routers to everyone in Kentucky or donating to stop the killing in Darfur, they’ve instead decided to give  kindly by not destroying their competitors. 

Jesus, I had no idea!  Thanks for clearing that up.   

Security is now under Jayshree’s organization which is routing/switching, and I don’t believe it has ever been a separate unit.  It should be.  That way if it doesn’t pan out they can just scrap-heap it and say that it’s a feature, not a market.

3.  Does it make sense to deploy security uniformly across the whole network, defending secretary desktops the same way you defend iSCSI servers or server-agent management consoles? No. Security should be focused on assets.

Hey, that’s a great point.  I think I made it! Please tell me how they do that?

But exactly what does this have to do with network architecture? Read Chris’ slides and it seems to mean “the way to architect your network is to hang Cisco boxes off of a couple Crossbeams in your core”.

Not quite, but your extreme-isms are starting to have me think you should write for Al-Jazeera.   How about quoting what I actually talked about…you know, like build a fast, reliable, resilient and responsive network infrastructure and overlay security as a combination of security services which provides the absolute best-of-breed security in combination where you need it, when you need it and at a price tag where the risk justifies the cost.

But that’s what you meant, right? 😉

The points Thomas pins his venom on below are from a single slide in the preso which is basically a Letterman’s top-10 spoof.  Some of them are purposely meant to incite, others are humorous, some are leverage points for the rest of the discussion that the audience and I had.

I’ll respond to some of them because many of Thomas’ objections are out of context and some are just to silly to respond to.  If you really, really want a line-by-line, I’ll do it.  Y’all just let me know 😉

2.  When’s the last time a network guy could perform a byte-level forensic trace of a Botnet C&C channel or a security guy troubleshoot a nasty BGP route-reflector distribution problem?

I don’t know. You might try asking Dug Song at Arbor, Kirby Kuehl at Cisco, or any of the Team Cymru guys. When’s the last time a security guy bought a Cisco product? Hint: it happened 5 times while you read this sentence.

Ummmm…I was referring to the average security and network practitioner in a stove-piped Enterprise or service provider, not the rest of the crew from your Saturday afternoon flag-football squad 😉

These guys, like you, are not representative of the typical folks who have to actually use the stuff we’re talking about.

You know, customers.

  3.  Managing threats and vulnerabilities is not the same as managing risk; networks don’t understand the value of the data traversing it..how can they protect it accordingly?

Cisco is not an ethernet cable. “The network” is whatever your vendor says it is. In Crossbeam’s case, “the network” is Cisco and “security” is everything else, including Checkpoint and SourceFire, both of whom sell products that Cisco has pin-compatible substitutes for.

Do any of these companies “understand the data”? No, I agree, they don’t. Is “understanding the data” important? Then let’s suspend the conversation until Cisco buys Vontu and Crossbeam partners with Vericept.

Pin-compatible?   Label-compatible, perhaps.  I think this is exactly the divergence that’s at the crux of the debate here, as the “quality” of the individual security solutions on their own (appliance or embedded) versus how they work as part of an architecture is the issue.  That’s my point, but it’s not a bullet-in-a-list sort of answer.

Also, I don’t care about Cisco buying Vontu, but what makes you think that we’re not already talking (and haven’t been for some time) to an extrusion prevention/IP Leakage vendor like Vericept?   

Crossbeam doesn’t suffer from having to wait to acquire technology and then spend 18 months butchering it to get it to work within the existing platforms (or build yet another point-solution appliance.)  We do our research in advance and when the time is right – and the customers desire it – we bring a partner’s application(s) onto the platform.

   4.  Just because two things are branded with the same name doesn’t mean they can communicate or interoperate well; just ask my wife

How’s that SourceFire/Checkpoint CPMI integration coming then? You got ISS using Snort signatures yet, or vice versa? Does anyone do app-level integration well?

Nope, and we’re not going to.  Neither will Cisco because they have no reason to if the entire network — and all the security components within — is theirs.  In fact, it’s within their interests to not have this happen.  If it did, it would just make your arguments weaker.

I’m just dinging the message and the messenger.  Our “app-level integration” is approached from a different perspective that starts first with consolidation of functions, virtualization of transport, application and policy then with the capability to flexibly pass flows through combinations of these virtual security stacks managed by the discrete parties charged with their care.  Best of breed functions that can be added to in an open platform without the need for a bunch of point solutions.

In large networks, the people responsible for FW are different than those responsible for IDS, are different than those responsible for XML, etc.   They’re still very, very vertically-stovepiped.

We don’t need to boil the ocean and we don’t.  We still have work to do on providing the overall global view of how traffic moves and is affected through these stacks, but we’re not the one blowing smoke about how this supposedly all works today.

That would be your job 😉

6.  The dirty little secret of embedding security in the “network” is that it’s the same as doing it with point-appliances…a single vendor’s set of appliances

Yes, it’s true: if Cisco succeeds in embedding security into its mainline products, you are going to be using Cisco security products. Diversity and consumer choice are valid arguments against Cisco.

But there’s one way in which using embedded security demonstrably isn’t the same as using point products: you don’t have to deploy point products to do it.

I call bullshit.  If you look at the slides in my preso, I can count over 13 different “point solutions” that aren’t routers and switches which are today relied upon to deploy this supposed “embedded” security.  The only difference between Cisco’s approach to embedded security and the appliance model is that the “appliances” are all Cisco’s.

Just because they have a Cisco label on it doesn’t make it “embedded.”

  7.  Modeling the security of the self-defending network after the human immune system and suggesting that it’s the ultimate analog is a crappy idea; people die

      Yes. What I hate about Cisco’s solutions is that you have to let a few machines on your network get infected for them to generate antigens; also, when Cisco’s security features coagulate around injuries, YouTube gets really slow.

Puff, puff, pass.  Puff, puff, pass.  You’re f-in up the rotation…man!

Please point me to a single customer in the world who has a self-defending network that functions like this.  Oh, that’s right, it’s the marketecture that you referred to in your first point and forgot that it doesn’t, actually, exist.  If YouTube being slow was the biggest problem businesses had today, you wouldn’t be employed either, T.

   8.  Security solely by acquisition does not make you a security company… just like acquiring lots of security “stuff” does not make you secure

You sure this is a good argument to make for a company that delivers 99% of its security value prop through partnerships with other companies?

Let’s ask the mean question: using product space names and market position (ie, “the #5 IPS vendor”), name some of the companies Crossbeam has turned down as partners? Cisco’s kind of picky about what it buys, you know.

It’s absolutely the right argument to make.  I guarantee you that the model of being customer-driven to take the best-in-breed security solutions from true security vendors and integrate it into a delivery architecture that is designed to do this rather than being force-fed into a retro-fit, works.  Today.

Mrt

Oh, and #5 is a long way from #1, Mr. T.

"I pity the fool who mess wit Cisco.   Unnhnhnhnhh!  I want Balboa.  Sucka!"

Oh, I’d be more than glad to email you the list of 15-20 vendors over the last 6 months that we’ve said “no” to. 

You’re about to hit my threshold trip-limit on how much of our business model you claim inside knowledge to…especially since you’re batting zero at this point.

9.  Security in breadth is not the same thing as security in depth; “good enough” security is not good enough in the data center

What aspect of Cisco’s IPS is not “good enough” for the data center?

…the same one that loses to ISS, Sourcefire, and Enterasys every day.  Want to ask the same about DDoS?  I believe the answer there would be your own beloved Arbor.

People deploy Cisco’s solution usually in conjunction with other products or the same function.  I think I’ve said enough.

Did you run your original post through the Babelfish English → Cisco parser before you copy/pasted it here, or what?

10.  Securing everything, everywhere is not only unnecessary, it’s unachievable

It is if Cisco sells it at 10 points below cost in order to turn the entire network security market into a line-item feature for the Catalyst 6000.

So you admit that this is not about the efficacy of a solution but rather how much shit you have to give away for free to be called a market leader?

Actually, with the example above, Cisco now suggests you buy a completely separate 6509 into which you put all the security functions and turn it into a “security services switch” that is plugged into the “real” switching/routing fabric. 

Sound familiar?  It does to me.

I know it doesn’t sound that way, but I’m neither a fan of Cisco nor a skeptic about Chris. But his arguments don’t take Cisco seriously, and if we’re going to armchair quarterback the security industry, why be nice about that?

You’re right, it doesn’t.  I still love you, though. 

By the way, Lindstrom and I both looked at each other and laughed when we had lunch together at the show realizing that should you ever figure out we were in Chi-town and didn’t call you that you’d be grumpy.  (I had no idea you lived in Chicago so it was all Pete’s fault.)

/Hoff

Getting “defensive” about security strategy?

November 3rd, 2006 No comments

81152612s
Uncle Mikey thinks I’m backward and defensive.  He’s referring to my post last night about the yawns I continue to experience regarding Cisco’s approach to the "self-defending network."  I’ll make no bones that more and more security will make its way into the network…that wasn’t the point.  Just because it’s there, doesn’t mean it’s worth using or actually works.  That *is* my point.

Here’s his post:

Every time Chris Hoff writes something, I wonder if he’s back. It’s
been months since he’s consistently been involved in the conversation,
and I’ve missed his participation. This piece though strikes me as a
bit defensive and backwards looking. I guess Chris just had the
epiphany that Cisco’s "Self-Defending Network" is a marketecture. Of
course it is. And yes, it’s in Cisco’s best interest to have security
everywhere, OVER TIME. I understand that your business is to sell a
"virtualized best of breed security as a service layer" stuff, but to
think that the trend is not towards having security capabilities
embedded within the fabric of the network suffers from a bit of tunnel
vision. Maybe you don’t like Cisco’s plan to get customers there, but
they will get there. To be clear, I’m not talking about right now, this
is a path that we’ll follow for the next 5-7 years. But at that time,
it’ll be about how to most effectively MANAGE the embedded
capabilities. So your "virtualized service layer" morphs into a
management layer. But I suspect you already know that, but it’s more
fun to bang up Cisco and talk about arm bars.

So he’s right.  I am backward — more specifically contrarian. I am also "defensive" because I could give a shit if big is the new small, purple is the new black or men wearing lipstick is socially acceptable.  What *I* care about is solving security and survivability problems TODAY…that same marketecture that you call out is taking place over 5-7 years supposedly started 5-7 years ago according to John Chambers!

How many decades are you willing to wait just to say "I told you so" in regards to your prophetic exclamation that security will become more integrated into the network?    Convenience and cost aren’t all they’re cracked up to be.  Sometimes the stuff actually has to work!

It’s not like you have to be Ms. Cleo to see what Cisco’s doing, but you don’t have to pretend to be blind and accept that it’s the cure for world hunger, also.

This piece though strikes me as a
bit defensive and backwards looking. I guess Chris just had the
epiphany that Cisco’s "Self-Defending Network" is a marketecture. Of
course it is. And yes, it’s in Cisco’s best interest to have security
everywhere, OVER TIME. I understand that your business is to sell a
"virtualized best of breed security as a service layer" stuff, but to
think that the trend is not towards having security capabilities
embedded within the fabric of the network suffers from a bit of tunnel
vision.

No, I didn’t *just* have this epiphany, it’s been the bane of my (and almost everyone else I talk to) existence for years.  I didn’t say  that security isn’t trending into the network, Mike.  What I said is that it’s a flawed approach with an even more flawed  genesis.  Here’s a turets-inspired outburst for you:

You don’t need security everywhere, all the time.  The network will never have the intelligence to make decisions on content in context.  The balance of delivery versus security will ALWAYS swing to the former in Cisco’s world.  CISCO IS NOT A SECURITY COMPANY.

The entire corner piece for Cisco’s SDN strategy for the last few years has been on CSA — software running on damned host!  Like Stiennon says, relying on the health of the very end-point you’re trying to protect to ensure the basis of your network’s viability and survivability is freaking ludicrous.  NAC is important, but up until last year, that was it in terms of the self-defending network — leave it to the host.  Now you can send telemetry to build dynamic ACL’s.   There’s a giant step forward.

Oh, but network vendors are from venus and security folks will use MARS — is that it?

Slapping together a bunch of stuff from acquisition is security in breadth not security in depth.

Maybe you don’t like Cisco’s plan to get customers there, but
they will get there. To be clear, I’m not talking about right now, this
is a path that we’ll follow for the next 5-7 years. But at that time,
it’ll be about how to most effectively MANAGE the embedded
capabilities. So your "virtualized service layer" morphs into a
management layer. But I suspect you already know that, but it’s more
fun to bang up Cisco and talk about arm bars.

You know what, Mike?  Kindly define "there" for me.  Because if you define "there" as a cobbled together bunch of appliances, routers and switches trying to effect security dispositions across an infrastructure and security monoculture without being able to make decisions on content and context, then I totally agree with you.

Screw waiting for this stuff, Mike.  They are the biggest networking company on the planet and it’s already been 5 years.  They keep announcing strategies like they’re a special on aisle 7 and then putting them on the discount shelf when they don’t pan out.

Take AON for example.  I always used to joke it would take an EON for AON.  I’m right.  That whole thing was a crock of…and now it’s, um, moved sideways to be integrated into yet another "strategy" because architects are smart enough to detect a polished turd when they see one.

Cisco is not the answer to life, the universe and everything else.  People are NOT willing to bet their business, reputation and company’s health on another marketecture.  People also are fed up with a single vendor’s version of the truth.  That’s why there are 600+ vendors in the network security space.

Does Cisco have huge marketshare?  In networking, yes.  But over 70% of security dollars spent DO NOT GO TO CISCO.

Will Cisco "get there."  Sure.  I wonder, however, if "there" is where people really care about being.

I don’t.  My customers have problems they need solved today that overlay and work synergistically with very reliable, fast, available and robust network plumbing.  In the data center, protecting the things that matter most, good enough is NOT good enough.

At the SMB perimeter, it is.

I think, quite honestly, that you’re the one with the myopic lens — all you see is a freight train heading towards you not realizing all you have to do is jump tracks. 

All aboard!

NAC Attack: Why NAC doesn’t work and SN(i)F doesn’t, either…alone

August 7th, 2006 12 comments

Hearnospeakno
I have to admit that when I read Alan Shimel’s blog entry whereby he calls out Richard Stiennon on his blog entries titled "Don’t Bother with NAC" and "Network Admission Control is a Blind Alley," I started licking my chops as I couldn’t wait to jump in and take some time to throw fuel on the fire.  Of course, Mike Rothman already did that, but my goal in life is to be more inflammatory than he is, so let the dousing begin!

I’ve actually been meaning to ask for clarification on some points from both of these fellas, so no better time than the present. 

Now, given the fact that I know all of the usual suspects in this
debate, it’s odd that I’m actually not siding with any of them.  In
fact, I sit squarely in the middle because I think that in the same
breath both Richard and Alan are as wrong as they are right.  Mike is always right (in his own mind) but rather than suggest there was a KO here, let’s review the tape and analyze the count before we go to the scorecards for a decision.

This bout is under the jurisdiction of and sanctioned by the Nevada
Gaming Commission and brought to you by FUD — the offical supplier of
facts on the Internet. 😉

Tale of the tape:

Richard Stiennon:

  1. Richard Stiennon highlighted some of Ofir Arkin’s NAC "weaknesses" presented at Black Hat and suggests that NAC is a waste of time based upon not only these technical deficiencies but also that the problems that NAC seeks to solve are already ameliorated by proper patching as machines "…that are patched do not get infected."
  2. Somewhat confusingly he follows on with the statement based upon the previous statement that "The fear of the zero-day worm or virus has
    proved ungrounded. And besides, if it is zero-day, then having the
    latest DAT file from Symantec does you no good."
  3. Richard suggests that integrating host-based and network-based security
    is a bad idea and that the right thing to do is based upon  "de-coupling network and host-based security. Rather than require them to work together let them work alone."
  4. Ultimately he expects that the rest of the problems will be fixed with a paradigm which he has called Secure Network Fabric. 
  5. Richard says the right solution is the concept he calls "Secure Network Fabric (SNF)" wherein "…network security
    solutions will not require switches, routers, laptops, servers,
    and vendors to work in concert with each other" but rather "…relies most heavily
    on a switched network architecture [which] usually involve[s] core switches
    as well as access switches."
  6. SNF relies on the VLANs that "…would be used to provide granularity
    down to the device-level where needed. The switch enforces policy based
    on layer 2 and 3 information. It is directed by the NetFlow based
    behavior monitoring system.
  7. Richard has talked about the need for integrating intelligent IDP (Intrusion Detection and Prevention) systems coupled with NBA/NBAD (Network Behavioral Analysis/Network Behavioral Anomaly Detection) and switching fabric for quite some time and this integration is key in SNF functionality.
  8. Furthermore, Richard maintains that relying on the endpoint to report its health back to the network and the mechanisms designed to allow admission is a bad idea and unnecessary.
  9. Richard maintains that there is a difference between "Admission Control" and "Access Control" and sums it up thusly: "To keep it simple just remember: Access Control, good. Admission Control, bad."

Alan Shimel:

  1. Alan freely admits that there are some technical "issues" with NAC such as implementation concerns with DHCP, static IP addresses, spoofed MAC addresses, NAT, etc.
  2. Alan points out that Richard did not mention that Ofir Arkin also suggests that utilizing a NAC solution based upon 802.1x is actually a robust solution.
  3. Alan alludes to the fact that people deploy NAC for various reasons and (quoting from a prior article) "…an important point is that NAC is not really geared towards stopping the determined hacker, but rather the inadvertant polluter."  Hence I believe he’s saying that 802.1x is the right NAC solution to use if you can as it solves both problems, but that if latter is not your reason for deploying NAC, then the other issues are not as important.
  4. Alan points to the fact that many of Richard’s references are quite dated (such as the comments describing the 2003 acquisition of TippingPoint by 3Com as "recent" and that ultimately SNF is a soapbox upon which Richard can preach his dislike of NAC based upon "…trusting the endpoint to report its health."
  5. De-coupling network and host-based endpoint security is a bad idea, according to Alan, because you miss context and introduce/reinforce the information silos that exist today rather than allow for coordinated, consolidated and correlated security decisions to be made.
  6. Alan wishes to purchase Pot (unless it’s something better) from Richard and go for a long walk on the shore because Mr. Stiennon has "the good stuff" in his opinion since Richard intimates that patching and configuration management have worked well and that zero-day attacks are a non-entity.
  7. Alan suggests that the technology "…we used to call behvior based IPS’s" which will pass "…to the switch to enfore policy" is ultimately "another failed technology" and that the vendors Richard cites in his BAIPS example (Arbor, Mazu, etc.) are all "…struggling in search of a solution for the technology they have developed."
  8. Alan maintains that the SNF "dream" lacks the ability to deliver any time soon because by de-coupling host and network security, you are hamstrung by the lack of "…context, analytics and network performance."
  9. Finally, Alan is unclear on the difference between Network Access Control (good) and Network Admission Control (bad.)

So again, I maintain that they are both right and both wrong.  I am the Switzerland of NAC/SNF! 

I’ll tell you why — not in any particular order or with a particular slant…

(the bout has now turned from a boxing context to a three man Mixed-Martial-Arts Octagon cage-match!  I predict a first round submission via tap-out):

  1. Firstly, endpoint and network security MUST be deployed together and ultimately communicate with one another to ultimately effect the most visible, transparent, collaborative and robust defense-in-depth security strategy available.  Nobody said it’s a 50/50 percentage, but having one without the other is silly.  There are things on endpoints that you can’t discover over a network.  Not having some intelligence about the endpoint means the network cannot possibly determine as accurately the "intent" of the packets spewing from it.
  2. Network Admission Control solutions don’t necessarily blindly trust the endpoint — whether agent or agentless, the NAC controller takes not only what the host "reports" but also how it "responds" to active probes of its state.  While virtualization and covert rootkits have the capability to potentially hide from these probes, suggesting that an endpoint passes these tests does not mean that the endpoint is no longer subject to any other control on the network…
  3. Once Network Admission Control is accomplished, Network Access Control can be applied (continuously) based upon policy and behavioral analysis/behavioral anomaly detection.
  4. Patching doesn’t work — not because the verb is dysfunctional — but because the people who are responsible for implementing it are.  So long as these systems are not completely automated, we’re at risk.
  5. Zero day exploits are not overblown — they’re getting more surgically targeted and the remediation cycles are too long.  Network-based solutions alone cannot protect against anomalies that are not protocol or exploit/vulnerability signature driven…if the traffic patterns are not abnormal, the flags are OK and the content seemingly benign going to something "normal," it *will* hit the target.
  6. You’ll be suprised just how immature many of the largest networks on this planet are in terms of segmentation via VLANs and internal security…FLAT, FLAT, FLAT.  Scary stuff.  If you think the network "understands" the data that is transported over it or can magically determine what is more important by asset/risk relevance, I too would like some of that stuff you’re smoking.
  7. Relying on the SNF concept wherein the "switch enforces policy based
    on layer 2 and 3 information," and "is directed by the NetFlow based
    behavior monitoring system" is wholly shortsighted.  Firstly layer 2/3 information is incredibly limited since most of the attacks today are application-level attacks and NOT L2/L3 and Netflow data (even v9) is grossly coarse and doesn’t provide the context needed to effectively determine these sorts of incursions.  That’s why NetFlow today is mostly used in DDoS activities — because you see egregiously spiked usage and/or traffic patterns.  It’s a colander not a sieve.
  8. Most vendors today are indeed combining IDP functionality with NBA/D to give a much deeper and contextual awareness across the network.  More importantly, big players such as ISS and Cisco include endpoint security and NAC (both "versions") to more granularly define, isolate and ameliorate attacks.  It’s not perfect, but it’s getting better.
  9. Advances in BA/NBA/NBAD are coming (they’re here, actually) and it will produce profound new ways of managing context and actionable intelligence when combined with optimized compute and forwarding engines which are emerging at the same time.   They will begin, when paired with network-wide correlation tools, to solve the holy trinity of issues: context, analytics and performance.
  10. Furthermore, companies such as ISS and StillSecure (Alan’s company) have partnered with switch vendors to actually do just what Richard suggests in concept.  Interestingly enough,
    despite the new moniker, the SNF concept is not new — Cisco’s SDN (albeit
    without NAC) heavily leverages the concepts described above from an
    embedded security perspective and overlay security vendors such as ISS
    and Crossbeam also have solutions (in POC or available) in this area.
  11. Let’s be honest, just like the BA vendors Alan described, NAC is in just the same position — "struggling in search of a solution for the technology they have developed."  There are many reasons for deploying NAC: Pre and Post-inspection/Quarantine/Remediation and there are numerous ways of doing it: agent-based/agentless/in-line/out-of-band… The scary thing is with so many vendors jumping in here and the 800 pound Gorilla (Cisco) even having trouble figuring it out, how long before NAC becomes a feature and not a market?  Spending a bunch of money on a solution (even without potential forklifts) to not "… stop the determined hacker, but rather the inadvertant polluter" seems a little odd to me.  Sure it’s part of a well defined network strategy, but it ain’t all that yet, either.
  12. With Cisco’s CSO saying things like "The concept of having devices join a network in which they are posture-assessed and given access to the network in a granular way is still in its infancy" and even StillSecure’s CTO (Mitchell Ashley) saying "…but I think those interested in NAC today are really trying to avoid infection spread by an unsuspecting network user rather than a knowledgeable intruder" it’s difficult to see how NAC can be considered a core element of a network security strategy WITHOUT something like SNF.

So, they’re both right and both wrong.  Oh, and by the way, Enterprise and Provider-class UTM solutions are combining ALL of this in a unified security service layer… FW, IDP, Anti-X, NBA(D) and SNF-like foundations.

[Tap before it breaks, boys!]

We need NAC and we need SNF and I’ve got the answer:

  1. Take some of Richard’s "good stuff"
  2. Puff, puff, pass
  3. Combine some of Alan’s NAC with Richard’s SNF
  4. Stir
  5. Bake for 30 minutes and you have one F’N (good) SNAC
    (it’s an anagram, get it!)

There you have it.

Chris