Rational Survivability

"Common sense has nothing to do with it. When I say he’s wrong, he’s wrong." — Ethel Mertz, I Love Lucy.

What a surprise, I disagree totally with Richard Stiennon on his assessment of the value proposition regarding the acquisition of Ellacoya by Arbor Networks. 

Specifically, I find it hysterical that Richard claims that Arbor is "abandoning the security space."  Just the opposite, I believe Arbor — given what they do — is pursuing a course of action that will allow them to not only continue to cement their value proposition in the security space, but extend it further, both in the carrier and enterprise space.

I think that it comes down to what Richard defines as "security" — a term I obviously despise for reasons just like this.

Here’s we we diverge:

I was actually in Ann Arbor last week when news broke that Arbor
Networks had acquired Ellacoya a so called “deep packet inspection”
technology vendor. I was perplexed. That’s not security.

"That’s not security." Funny.  See below.

First let me clear up some terminology.   “Deep Packet Inspection” was the term some Gartner analyst
popularized to describe what content filtering gateways do. They
inspect content for worms, attacks, and viruses. Somewhere along the
line the traffic shaping industry(Ellacoya, Allot, Sandvine) co-opted
the term to describe what their devices do: look at the packet header
to determine what protocol is being transported and throttle the
throughput based on protocol. In other words Quality of Service for
network traffic. These devices do not look at payloads at all except in
some rare instances when you have to determine if Skype-like programs
are spoofing different protocols.

Firstly, Richard conveniently trivialized DPI.  DPI is certainly about inspecting the packet (beyond the header, by the way) and determining what protocol and application that is being used with precision and fidelity.   In a carrier network, that’s used for provisioning, network allocation, bandwidth management and service level management.

These are terms every enterprise of worth is used to hearing and managing to!

Certainly a disposition once the packets are profiled could be to apply QoS which is often what one might do in DoS/DDoS situations, but there are multiple benefits of being able to apply policies and enact dispositions which are dependent on the use or misuse of a specific application or protocol.

In fact, if you don’t think that this is "security" why do we see QoS/Rate limiting in almost every firewall platform today — it may not show up in the GUI, but this is a fundamental way of dealing with attack.

Oh, by the way Richard, perhaps you ought to read your own product manuals as Fortinet provides QoS as a "security" function…perhaps not as robustly as Ellacoya…and soon Arbor:

FortiGate Traffic Shaping Technical Note

The FortiGate Traffic Shaping Technical Note, available on the Technical Documentation Web Site,
discusses Quality of Service (QoS) and traffic shaping, describes
FortiGate traffic shaping using the token bucket filter mechanism, and
provides general procedures and tips on how to configure traffic
shaping on FortiGate firewalls.

FortiOS v3.0 MR1introduced inbound traffic shaping per
interface. For any FortiGate interface you can use the following
command to configure inbound traffic shaping for that interface.
Inbound traffic shaping limits the bandwidth accepted by the interface.

config system interface
   edit port2
      set inbandwidth 50
   end
end

This command limits the inbound traffic that the port2 interface
accepts to 50 Kb/sec. You can set inbound traffic shaping for any
FortiGate interface and for more than one FortiGate interface. Setting inbandwidth to 0 (the default) means unlimited bandwidth or no traffic shaping.

Inbound traffic shaping limits the amount of traffic accepted by the
interface. This limiting occurs before the traffic is processed by the
FortiGate unit. Limiting inbound traffic takes precedence over traffic
shaping applied using firewall policies. This means that traffic
shaping applied by firewall policies is applied to traffic already
limited by inbound traffic shaping.

Lot of uses of the word "firewall" in the context of "traffic shaping" in that description…Here’s a link to your knowledge base, just in case you don’t have it 😉

Secondly, since availability is often a function of security, as an administrator I’d want to be able to craft a "security policy" that allows me to make sure that the stuff that matters to me most gets through and is prioritized as such and the rest fight for scraps.  Doing this with precision and fidelity is incredibly important whether you’re a carrier or an enterprise.  Oh, wait, here’s some more Fortinet documentation that seems to contradict the "that’s not security" sentiment:

Traffic shaping which is applied to a Firewall Policy, is enforced for
traffic which may flow in either direction. Therefore a session which
may be setup by an internal host to an external one, via a
Internal->External policy, will have Traffic shaping applied even if
the data stream is then coming from external to internal. For example,
an FTP ‘get’ or a SMTP server connecting to an external one, in order
to retrieve email.

Remember CHKP’s FloodGate?  Never particularly worked out from an integration perspective, but a good idea, nonetheless.  Cisco’s got it.  Juniper’s got it…

Further, there’s a new company — you may have heard about it — that takes application specificity and applies granular policies on traffic that does just this sort of thing: Palo Alto Networks.  They call it their "next generation firewall."  Love or hate the title (I don’t particularly care for it) I call it common sense.  Are you going to tell me this isn’t security, either? 

The next, next-generation of security devices will extend this decision-making criteria from ports/protocols through application "conduits" and start making decisions on content in context.  This is the natural extension of DPI.

I won’t argue with the rest of Richard’s points about M&A risk and market expansion because he’s right in many of his examples, but that wasn’t the title of his post or the real sentiment.

I think that this deal enhances both the capabilities and applicability of Arbor’s solutions which have been largely stovepiped and pigeonholed in the DDoS category based upon what they do today.  I hope they can execute on the integration play.

As to the notion of ignoring the enterprise and "doubling down on the carrier market," Arbor has a great DDoS product for both markets; this allows them now to take advantage of the cresting consolidation activity in both and start diversifying their SECURITY offerings in a way that is intelligently roadmapped.

Who knows.  Perhaps they’ll re-market the combined products as a "multiservices security gateway" just like Fortinet does with their carrier products (here.)

I think your marketing slip is showing, Rich.

/Hoff