Rational Survivability

No DNS Disclosure Debacle Here: Stiennon Pens the Funniest Thing I've Read in 2008...

Hat tip to Rothman for this.

I don't know if Stiennon is off his meds or simply needed to re-post something from 2001 to meet an editorial quota, but his Network World article titled "The Most Important Networking Trend of 2008" ties thus far with the "Evolution of Dance" as my vote for most entertaining Internet content.

Richard's epiphany goes something like this:

• Multifunction network devices that have the ability to "route" traffic and combine security capabilities are the 'next big thing'
  
  
• If a company offers a multifunction network device that has the ability to "route" traffic and combine security capabilities but have the misfortune of using Linux as the operating system, they will "...forever be pigeon-holed as SMB solutions, not ready for enterprise prime time."
  
  
• The Wall Street Journal issued "... the year's most important article on networking" in an article titled "New Routers Catch the Eyes of IT Departments" which validates the heretofore undiscovered trend of convergence and commoditization!
   
  
• "Real" network security players such as Cisco, Juniper and Redback are building solutions to this incredible new trend and because of the badge on the box, will be considered ready for "...enterprise prime time."
   
  
• The WSJ article talks about the Cisco ASR1000 router as the penultimate representation of this new breed of converged "network security" device.
   
  
• Strangely, Stiennon seems to have missed the fact that the operating system (IOS-XE) that the ASR1000 is based on is, um, Linux.  You know, that operating system that dictates that this poor product will "...forever be pigeon-holed as SMB solutions, not ready for enterprise prime time."
  

Oh, crap!  Somebody better tell Cisco!

So despite the fact that Cisco ASR1000 is positioned as an edge device as are these crazy solutions called UTM devices, it seems we're all missing something because somehow a converged edge device now counts as being able to provide a "secure network fabric?"

In closing, allow me to highlight the cherry on top of Stiennon's security sundae:   

Have you ever noticed how industry "experts" tend to get stuck in a rut and continue to see everything through the same lens despite major shifts in markets and technology?

Yes, Richard, I do believe I have noticed this...

Funny stuff!

/Hoff

New Fortinet Patents May Spell Nasty Trouble For UTM Vendors, Virtualization Vendors, App. Delivery Vendors, Routing/Switching Vendors...

Check out the update below...

Were I in the UTM business, I'd be engaging the reality distortion field and speed-dialing my patent attorneys at this point.

Fortinet has recently had some very interesting patent applications granted by the PTO.

Integrated network and application security, together with virtualization technologies, offer a powerful and synergistic approach for defending against an increasingly dangerous cyber-criminal environment. In combination with its extensive patent-pending applications and patents already granted, Fortinet's newest patents address critical technologies that enable comprehensive network protection:

• U.S. Patent #7,333,430 - Systems and Methods for Passing Network Traffic Data - directed to efficiently processing network traffic data to facilitate policy enforcement, including content scanning, source/destination verification, virus scanning, content detection and intrusion detection;
  
  
• U.S. Patent #7,340,535 - System and Method for Controlling Routing in a Virtual Router System - directed to controlling the routing of network data, and providing efficient configuration of routing functionality and optimized use of available resources by applying functions to data packets in a virtual environment;
  
  
• U.S. Patent #7,376,125 - Service Processing Switch - directed to providing IP services and IP packet processing in a virtual router-based system using IP flow caches, virtual routing engines, virtual services engines and advanced security engines;
  
  
• U.S. Patent # 7,389,358 - Distributed Virtual System to Support Managed, Network-based Services - directed to a virtual routing system, which includes processing elements to manage and optimize IP traffic, useful for service provider switching functions at Internet point-of-presence (POP) locations.

These patents could have some potentially profound impact on vendors who offer "integrated security" by allowing for virtualized application of network security policy.  These patents could easily be enforced outside of the typically-defined UTM offerings, also.

I'm quite certain Cisco and Juniper are taking note as should be anyone in the business of offering virtualized routing/switching combined with security -- that's certainly a broad swath, eh?

On a wider note, I've actually been quite impressed with the IP portfolio that Fortinet has been assembling over the last couple of years.  If you've been paying attention, you will notice (for example) that that they have scooped up much of the remaining CoSine IP as well as recently acquired IPlocks' database security portfolio.

If I were they, the next thing I'd look for (and would have a while ago) is to scoop up a Web Application Firewall/Proxy vendor...

I trust you can figure out why...why not hazard a guess in the comments?

/Hoff

Updated:  It occured to me that this may be much more far-reaching than just UTM vendors, that basically this could affect folks like Crossbeam, Check Point, StillSecure, Cisco, Juniper, Secure Computing, f5...basically anyone who sells a product that mixes the application of security policy with virtualized routing/switching capabilities...

How about those ASA's or FWSMs?  How about those load balancers with VIPs?

Come to mention it, what of VMware?  How about the fact that in combining virtual networking with VMsafe, you've basically got what amounts to coverage by the first two patents:

U.S. Patent #7,333,430 - Systems and Methods for Passing Network Traffic Data - directed to efficiently processing network traffic data to facilitate policy enforcement, including content scanning, source/destination verification, virus scanning, content detection and intrusion detection;

U.S. Patent #7,340,535 - System and Method for Controlling Routing in a Virtual Router System - directed to controlling the routing of network data, and providing efficient configuration of routing functionality and optimized use of available resources by applying functions to data packets in a virtual environment;

Whoopsie.

Now, I'm not a lawyer, I just play one on teh Interwebs.

Complexity: The Enemy of Security? Or, If It Ain't Fixed, Don't Break It...

When all you have is a hammer, everything looks like a nail...

A couple of days ago, I was concerned (here) that I had missed Don Weber's point (here) regarding how he thinks solutions like UTM that consolidate multiple security functions into a single solution increased complexity and increased risk.

I was interested in more detail regarding Don's premise for his argument, so I asked him for some substantiating background information before I responded:

The question I have for Don is simple: how is it that you've arrived at the conclusion that the consolidation and convergence of security functionality from multiple discrete products into a single-sourced solution adds "complexity" and leads to "increased risk?"

Can you empirically demonstrate this by giving us an example of where a single function security device that became a multiple function security product caused this complete set combination of events to occur:

1. Product complexity increased
2. Lead to a vulnerability that was exploitable and
3. Increased "risk" based upon business impact and exposure

Don was kind enough to respond to my request with a rather lengthy post titled "The Perimeter Is Dead --  Let's Make It More Complex."  I knew that I wouldn't get the example I wanted, but I did get what I expected.  I started to write a very detailed response but stopped when I realized a couple of important things in reading his post as well as many of the comments:

• It's clear that many folks simply don't understand the underlying internal operating principles and architectures of security products on the market, and frankly for the most part they really shouldn't have to.  However, if you're going to start debating security architecture and engineering implementation of security software and hardware, it's somewhat unreasonable to start generalizing and creating bad analogs about things you clearly don't have experience with. 
   
• Believe it or not, most security companies that create bespoke security solutions do actually hire competent product management and engineering staff with the discipline, processes and practices that result in just a *little* bit more than copy/paste integration of software.  There are always exceptions, but if this were SOP, how many of them would still be in business?
   
• The FUD that vendors are accused of spreading to supposedly motivate consumers to purchase their products is sometimes outdone by the sheer lack of knowledge illustrated by the regurgitated drivel that is offered by people suggesting why these same products are not worthy of purchase. 
  
  In markets that have TAMs of $4+ Billion, either we're all incompetent lemmings (to be argued elsewhere) or there are some compelling reasons for these products.  Sometimes it's not solely security, for sure, but people don't purchase security products with the expectations of being less secure with products that are more complex and put them more at risk.  Silliness.
   
• I find it odd that the people who maintain that they must have diversity in their security solution providers gag when I ask them for proof that they have invested in multiple switch and router vendors across their entire enterprise, that they deliberately deploy critical computing assets on disparate operating systems and that they have redundancy for all critical assets in their enterprise...including themselves. 
   
• It doesn't make a lot of sense arguing about the utility, efficacy, usability and viability of a product with someone who has never actually implemented the solution they are arguing about and instead compares proprietary security products with a breadboard approach to creating a FrankenWall of non-integrated open source software on a common un-hardened Linux distro.
   
• Using words like complexity and risk within a theoretical context that has no empirical data offered to back it up short of a "gut reaction" and some vulnerability advisories in generally-available open source software lacks relevancy and is a waste of electrons.

I have proof points, ROI studies, security assessment results to the code level, and former customer case studies that demonstrate that some of the most paranoid companies on the planet see fit to purchase millions of dollars worth of supposedly "complex risk-increasing" solutions like these...I can tell you that they're not all lemmings.

Again, not all of those bullets are directed at Don specifically, but I sense we're really just going to talk past one another on this point and the emails I'm getting trying to privately debate this point are agitating to say the least.

Your beer's waiting, but expect an arm wrestle before you get to take the first sip.

/Hoff

Consolidating Controls Causes Chaos and Certain Complexity?

Don Weber wrote a post last week describing his thoughts on the consolidation of [security] controls and followed it up with another today titled "Quit Complicating our Controls - UTM Remix" in which he suggests that the consolidation of controls delivers an end-state of additional "complexity" and "higher risk":

Of course I can see why people desire to integrate the technologies. 

• It is more cost effective to have two or more technologies on one piece of hardware.
• You only have to manage one box.
• The controls can augment each other more effectively and efficiently (according to the advertising on the box).
• Firewalls usually represent a choke point to external and potentially hostile environments.
• Vendors can market it as the Silver Bullet (no relation to Gary McGraw’s podcast) of controls.
• “The next-generation firewall will have greater blocking and visibility into types of protocols,” says Greg Young, research vice president for Gartner.
• etc

Well, I have a problem with all of this. Why are we making our controls more complex? Complexity leads to vulnerabilities. Vulnerabilities lead to exploits. Exploits lead to compromises. Compromises lead to loss.

...and:

Don’t get me wrong. I am all for developing new technologies that will allow organizations to analyze their traffic so that they get a better picture of what is traversing and exiting their networks. I just think they will be more effective if they are deployed so that they augment each other’s control measures instead of threatening them by increasing the risk through complexity. Controls should reduce risk, not increase it.

Don's posts have touched on a myriad of topics I have very strong opinions on: complex simplicity, ("magical") risk, UTM and application firewalls.  I don't agree with Don's statements regarding any of them. That's probably why he called me out.

The question I have for Don is simple: how is it that you've arrived at the conclusion that the consolidation and convergence of security functionality from multiple discrete products into a single-sourced solution adds "complexity" and leads to "increased risk?"

Can you empirically demonstrate this by giving us an example of where a single function security device that became a multiple function security product caused this complete set combination of events to occur:

1. Product complexity increased
2. Lead to a vulnerability that was exploitable and
3. Increased "risk" based upon business impact and exposure

I'm being open-minded here and rather than try and address every corner-case I am eager to understand more of the background of Don's position so I might respond accordingly.

/Hoff

The 4th Generation of Security Devices = UTM + Routing & Switching or New Labels = Perfuming a Pig?

That's it.  I've had it.  Again.  There's no way I'd ever make it as a Marketeer.  <sigh>

I almost wasn't going to write anything about this particular topic because my response can (and probably should) easily be perceived as and retorted against as a pissy little marketing match between competitors.  Chu don't like it, Chu don't gotta read it, capice?

Sue me for telling the truth. {strike that, as someone probably will}

However, this sort of blatant exhalation of so-called revolutionary security product and architectural advances disguised as prophecy is just so, well, recockulous, that I can't stand it.

I found it funny that the Anti-Hoff (Stiennon) managed to slip another patented advertising editorial Captain Obvious press piece in SC Magazine regarding what can only be described as the natural evolution of network security products that plug into -- but are not natively -- routing or switching architectures.

I don't really mind that, but to suggest that somehow this is an original concept is just disingenuous.

Besides trying to wean Fortinet away from the classification as UTM devices (which Richard clearly hates
to be associated with) by suggesting that UTM should be renamed as "Flexible Security Platform," he does a fine job of asserting that a "geologic shift" (I can only assume he means tectonic) is coming soon in the so-called fourth generation of security products.

Of course, he's completely ignoring the fact that the solution he describes is and has already been deployed for years...but since tectonic shifts usually take millions of years to culminate in something noticeably remarkable, I can understand his confusion.

As you'll see below, calling these products "Flexible Security Platforms" or "Unified Network Platforms" is merely an arbitrary and ill-conceived hand-waving exercise in an attempt to differentiate in a crowded market.  Open source or COTS, ASIC/FPGA or multi-core Intel...that's just the packaging and delivery mechanism.  You can tart it up all you want with fancy marketing...

It's not new, it's not revolutionary (because it's already been done) and it sure as hell ain't the second coming.  I'll say it again, it's been here for years.  I personally bought it and deployed it as a customer almost 4 years ago...if you haven't figured out what I'm talking about yet, read on.

Here's how C.O. describes what the company I work for has been doing for 6 years and that he intimates Fortinet will provide that nobody else can:

We are rapidly approaching the advent of the fourth generation security platform. This is a device that can do all of the security functions that are lumped in to UTM but are also excellent network devices at layers two and three. They act as a switch and a router. They supplant traditional network devices while providing security at all levels. Their inherent architectural flexibility makes them easy to fit into existing environments and even make some things possible that were never possible before. For instance a large enterprise with several business units could deploy these advanced networking/security devices at the core and assign virtual security domains to each business unit while performing content filtering and firewalling between each virtual domain, thus segmenting the business units and maximizing the investment in core security devices.

One geologic shift that will occur thanks to the advent of these fourth generation security platforms is that networking vendors will be playing catch up, trying to patch more and more security functions into their under-powered devices or complicating their go to market message with a plethora of boxes while the security platform vendors will quickly and easily add networking functionality to their devices.

Fourth generation network security platforms will evolve beyond stand alone security appliances to encompass routing and switching as well. This new generation of devices will impact the networking industry it scrambles to acquire the expertise in security and shift their business model from commodity switching and routing to value add networking and protection capabilities.

Let's see...combine high-speed network processing whose routing/switching architecture was designed by the same engineers that designed Bay/Welfleet's core routers, add in a multi-core Intel processing/compute layer which utilizes virtualized, load-balanced security applications as a  service layer that can be overlaid across a fast, reliable, resilient and highly-available network transport and what do you get?

This:

Up to 32 GigE or 64 10/100 switching ports and 40 Intel cores in a single chassis today...and in Q3'07 you'll also have the combination of our NextGen network processors which will provide up to 8x10GigE and 40xGigE with 64 MIPS Network Security cores combined with the same 40 Intel cores in the same chassis.

By the way, I consider that routing and switching are just table stakes, not market differentiators; in products like the one to the left, this is just basic expected functionality.

Furthermore, in this so-called next generation of "security switches," the customer should be able to run both open source as well as best-in-breed COTS security applications on the platform and not constrain the user to a single vendor's version of the truth running proprietary software.

-----

But wait, it only gets better...what I found equally as hysterical is the notion that Captain Obvious now has a sidekick!  It seems Alan Shimel has signed on as Richard's Boy Wonder.  Alan's suggesting that again, the magic bullet is Cobia and that because he can run a routing daemon and his appliance has more than a couple of ports, it's a router and a switch as well as a multi-function UTM UNP swiss army knife of security & networking goodness -- and he was the first to do it!  Holy marketing-schizzle Batman! 

I don't need to re-hash this.  I blogged about it here before.

You can dress Newt Gingrich up as a chick but it doesn't mean I want to make out with him...

This is cheap, cheap, cheap marketing on both your parts and don't believe for a minute that customers don't see right through it; perfuming pigs is not revolutionary, it's called product marketing.

/Hoff

Profiling Data At the Network-Layer and Controlling It's Movement Is a Bad Thing?

I've been watching what appears like a car crash in slow-motion and for some strange reason I share some affinity and/or responsibility for what is unfolding in the debate between Rory and Rob.

What motivated me to comment on this on-going exploration of data-centric security was Rory's last post in which he appears to refer to some points I raised in my original post but still bent on the idea that the crux of my concept was tied to DRM:

So .. am I anti-security? Nope I'm extremely pro-security. My feeling is however that the best way to implement security is in ways which it's invisable to users. Every time you make ordinary business people think about security (eg, usernames/passwords) they try their darndest to bypass those requirements.

That's fine and I agree.  The concept of ADAPT is completely transparent to "users."  This doesn't obviate the fact that someone will have to be responsible for characterizing what is important and relevant to the business in terms of "assets/data," attaching weight/value to them, and setting some policies regarding how to mitigate impact and ultimately risk.

Personally I'm a great fan of network segregation and defence in depth at the network layer. I think that devices like the ones crossbeam produce are very useful in coming up with risk profiles, on a network by network basis rather than a data basis and managing traffic in that way. The reason for this is that then the segregation and protections can be applied without the intervention of end-users and without them (hopefully) having to know about what security is in place.

So I think you're still missing my point.  The example I gave of the X-Series using ADAPT takes a combination of best-of-breed security software components such as FW, IDP, WAF, XML, AV, etc. and provides you with segregation as you describe.  HOWEVER, the (r)evolutionary delta here is that the ADAPT profiling of content set by policies which are invisible to the user at the network layer allows one to make security decisions on content in context and control how data moves.

So to use the phrase that I've seen in other blogs on this subject, I think that the "zones of trust" are a great idea, but the zone's shouldn't be based on the data that flows over them, but the user/machine that are used. It's the idea of tagging all that data with the right tags and controlling it's flow that bugs me.

...and thus it's obvious that I completely and utterly disagree with this statement.  Without tying some sort of identity (pseudonymity) to the user/machine AND combining it with identifying the channels (applications) and the content (payload) you simply cannot make an informed decision as to the legitimacy of the movement/delivery of this data.

I used the case of being able to utilize client-side tagging as an extension to ADAPT, NOT as a dependency.  Go back and re-read the post; it's a network-based transparent tagging process that attaches the tag to the traffic as it moves around the network.  I don't understand why that would bug you?

So that's where my points in the previous post came from, and I still reckon their correct. Data tagging and parsing relies on the existance of standards and their uptake in the first instance and then users *actually using them* and personally I think that's not going to happen in general companies and therefore is not the best place to be focusing security effort...

Please explain this to me?  What standards need to exist in order to tag data -- unless of course you're talking about the heterogeneous exchange and integration of tagging data at the client side across platforms?  Not so if you do it at the network layer WITHIN the context of the architecture I outlined; the clients, switches, routers, etc. don't need to know a thing about the process as it's done transparently.

I wasn't arguing that this is the end-all-be-all of data-centric security, but it's worth exploring without deadweighting it to the negative baggage of DRM and the existing DLP/Extrusion Prevention technologies and methodologies that currently exist.

ADAPT is doable and real; stay tuned.

/Hoff

For Data to Survive, It Must ADAPT...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This network is chopped up into 4 VLAN segments:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

/Hoff

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

MCWResearch Blog

Rob Newby's Blog

Alex Hutton's Blog

Security Retentive Blog

My IPS (and FW, WAF, XML, DBF, URL, AV, AS) *IS* Bigger Than Yours Is...

Interop has has been great thus far.  One of the most visible themes of this year's show is (not suprisingly) the hyped emergence of 10Gb/s Ethernet.  10G isn't new, but the market is now ripe with products supporting it: routers, switches, servers and, of course, security kit.

With this uptick in connectivity as well as the corresponding float in compute power thanks to Mr. Moore AND some nifty evolution of very fast, low latency, reasonably accurate deep packet inspection (including behavioral technology,) the marketing wars have begun on who has the biggest, baddest toys on the block.

Whenever this discussion arises, without question the notion of "carrier class" gets bandied about in order to essentially qualify a product as being able to withstand enormous amounts of traffic load without imposing latency. 

One of the most compelling reasons for these big pieces of iron (which are ultimately a means to an end to run software, afterall) is the service provider/carrier/mobile operator market which certainly has its fair share of challenges in terms of not only scale and performance but also security.

I blogged a couple of weeks ago regarding the resurgence of what can be described as "clean pipes" wherein a service provider applies some technology that gets rid of the big lumps upstream of the customer premises in order to deliver more sanitary network transport.

What's interesting about clean pipes is that much of what security providers talk about today is only actually a small amount of what is actually needed.  Security providers, most notably IPS vendors, anchor the entire strategy of clean pipes around "threat protection" that appears somewhat one dimensional.

This normally means getting rid of what is generically referred to today as "malware," arresting worm propagation and quashing DoS/DDoS attacks.  It doesn't speak at all to the need for things that aren't purely "security" in nature such as parental controls (URL filtering,) anti-spam, P2P, etc.  It appears that in the strictest definition, these aren't threats?

So, this week we've seen the following announcements:

• ISS announces their new appliance that offers 6Gb/s of IPS
• McAfee announces thei new appliance that offers 10Gb/s of IPS

The trumpets sounded and the heavens parted as these products were announced touting threat protection via IPS at levels supposedly never approached before.  More appliances.  Lots of interfaces.  Big numbers.  Yet to be seen in action.  Also, to be clear a 2U rackmount appliance that is not DC powered and non-NEBS certified isn't normally called "Carrier-Class."

I find these announcements interesting because even with our existing products (which run ISS and Sourcefire's IDS/IPS software, by the way) we can deliver 8Gb/s of firewall and IPS today and have been able to for some time.

Lisa Vaas over @ eWeek just covered the ISS and McAfee announcements and she was nice enough to talk about our products and positioning.  One super-critical difference is that along with high throughput and low latency you get to actually CHOOSE which IPS you want to run -- ISS, Sourcefire and shortly Check Point's IPS-1.

You can then combine that with firewall, AV, AS, URL filtering, web app. and database firewalls and XML security gateways in the same chassis to name a few other functions -- all best of breed from top-tier players -- and this is what we call Enterprise and Provider-Class UTM folks.

Holistically approaching threat management across the entire spectrum is really important along with the speeds and feeds and we've all seen what happens when more and more functionality is added to the feature stack -- you turn a feature on and you pay for it performance-wise somewhere else.  It's robbing Peter to pay Paul.  The processing requirements necessary at 10G line rates to do IPS is different when you add AV to the mix.

The next steps will be interesting and we'll have to see how the switch and overlay vendors rev up to make their move to have the biggest on the block.  Hey, what ever did happen to that 3Com M160?

Then there's that little company called Cisco...

{Ed: Oops.  I made a boo-boo and talked about some stuff I shouldn't have.  You didn't notice, did you?  Ah, the perils of the intersection of Corporate Blvd. and Personal Way!  Lesson learned. ;) }

 

Clean Pipes - Less Sewerage or More Potable Water?

Jeff Bardin over on the CSO blog pitched an interesting stake in the ground when he posited "Connectivity As A Utility: Where are My Clean Pipes?"

Specifically, Jeff expects that his (corporate?) Internet service functions in the same manner as his telephone service via something similar to a "do not call list."  Basically, he opts out by placing himself on the no-call list and telemarketers cease to call. Others might liken it to turning on a tap and getting clean, potable water; you pay for a utility and expect it to be usable.  All of it.

Many telecommunications providers want to charge you for having clean pipes, deploying a suite of DDoS services that you have to buy to enhance your security posture.   Protection of last mile bandwidth is very key to network availability as well as confidentiality and integrity. If I am subscribing for a full T1, shouldn’t I get the full T1 as part of the price and not just a segment of the T1? Why do I have to pay for the spam, probes, scans, and malicious activity that my telecommunications service provider should prevent at 3 miles out versus my having to subscribe to another service to attain clean pipes at my doorstep?

I think that most people would agree with the concept of clean pipes in principle.  I can't think of any other utility where the service levels delivered are taken with such a lackadaisical best effort approach and where the consumer can almost always expect that some amount (if not the majority) of the utility is unusable. 

Over the last year, I've met with many of the largest ISP's, MSSP's, TelCo's and Mobile Operators on the planet and all are in some phase of deploying some sort of clean pipes variant.  Gartner even predicts a large amount of security to move "into the cloud."

In terms of adoption, EMEA is leaps and bounds ahead of the US and APAC in these sorts of services and will continue to be.  The relative oligopolies associated with smaller nation states allows for much more agile and flexible service definition and roll-outs -- no less complex, mind you.  It's incredible to see just how disparate and divergent the gap is between what consumers (SME/SMB/Mobile as well as large enterprise) are offered in EMEA as opposed to the good-ol' U S of A.

However, the stark reality is that the implementation of clean pipes by your service provider(s) comes down to a balance of two issues: efficacy and economics, with each varying dramatically with the market being served; the large enterprise's expectations and requirements look very, very different from the SME/SMB.

Let's take a look at both of these elements.

ECONOMICS

If you ask most service providers about so-called clean pipes up to a year ago, you could expect to get an answer that was based upon a "selfish" initiative aimed at stopping wasteful bandwidth usage upstream in the service provider's network, not really protecting the consumer. 

The main focus here is really on DDoS and viri/worm propagation.  Today, the closest you'll come to "clean pipes" is usually some combination of the following services deployed both (still) at the customer premises as well as somewhere upstream:

• DoS/DDoS
• Anti-Virus
• Anti-Spam
• URL Filtering/Parental Controls
• Managed Firewall/IDS/IPS

What is interesting about these services is that they basically define the same functions you can now get in those small little UTM boxes that consolidate security functionality at the "perimeter."  The capital cost of these devices and the operational levies associated with their upkeep are pretty close in the SME/SMB and when you balance what you get in "good enough" services for this market as well as the overall availability of these "in the cloud" offerings, UTM makes more sense for many in the near term.

For the large enterprise, the story is different.  Outsourcing some level of security to an MSSP (or perhaps even the entire operation) or moving some amount upstream is a matter of core competence and leveraging the focus of having internal teams focus on the things that matter most while the low hanging fruit can be filtered out and monitored by someone else.  I describe that as filtering out the lumps.  Some enormous companies have outsourced not only their security functions but their entire IT operations and data center assets in this manner.  It's not pretty, but it works.

I'm not sure they are any more secure than they were before, however.  The risk simply was transferred whilst the tolerance/appetite for it didn't change at all.  Puzzling.

Is it really wrong to think that companies (you'll notice I said companies, not "people" in the general sense) should pay for clean pipes?  I don't think it is.  The reality is that for non-commercial subscribers such as home users, broadband or mobile users, some amount of bandwidth hygiene should be free -- the potable water approach.

I think, however, that should a company which expects elevated service levels and commensurate guarantees of such, want more secure connectivity, they can expect to ante up.  Why?  Because the investment required to deliver this sort of service costs a LOT of money -- both to spin up and to instantiate over time.  You're going to have to pay for that somewhere.

I very much like Jeff's statistics:

We stop on average for our organization nearly 600 million malicious emails per year at our doorstep averaging 2.8 gigabytes of garbage per day. You add it up and we are looking at nearly a terabyte of malicious email we have to stop. Now add in probes and scans against HTTP and HTTPS sites and the number continues to skyrocket.

Again, even though Jeff's organization isn't small by any means, the stuff he's complaining about here is really the low-hanging fruit.  It doesn't bear a dent against the targeted, malicious and financially-impacting security threats that really demands a level of service no service provider will be able to deliver without a huge cost premium.

I won't bore you with the details, but the level of high-availability, resilience, performance, manageability, and provisioning required to deliver even this sort of service is enormous.  Most vendors simply can't do it and most service providers are slow to invest in proprietary solutions that won't scale economically with the operational models in place.

Interestingly, vendors such as McAfee even as recently as 2005 announced with much fanfare that they were going to deliver technology, services and a united consortium of participating service providers with the following lofty clean pipe goals (besides selling more product, that is):

The initiative is one part of a major product and services push from McAfee, which is developing its next generation of carrier-grade security appliances and ramping up its enterprise security offerings with NAC and secure content management product releases planned for the first half of next year, said Vatsal Sonecha, vice president of market development and strategic alliances at McAfee, in Santa Clara, Calif.

Clean Pipes will be a major expansion of McAfee's managed services offerings. The company will sell managed intrusion prevention; secure content management; vulnerability management; malware protection, including anti-virus, anti-spam and anti-spyware services; and mobile device security, Sonecha said.

McAfee is working with Cable and Wireless PLC, British Telecommunications PLC (British Telecom), Telefónica SA and China Network Communications (China Netcom) to tailor its offerings through an invitation-only group it calls the Clean Pipes Consortium.

http://www.eweek.com/article2/0,1895,1855188,00.asp

Look at all those services!  What have they delivered as a service in the cloud or clean pipes?  Nada. 

The chassis-based products which were to deliver these services never materialized and neither did the services.  Why?  Because it's really damned hard to do correctly.  Just ask Inkra, Nexi, CoSine, etc.  Or you can ask me.  The difference is, we're still in business and they're not.  It's interesting to note that every one of those "consortium members" with the exception of Cable and Wireless are Crossbeam customers.  Go figure.

EFFICACY

Once the provider starts filtering at the ingress/egress, one must trust that the things being filtered won't have an impact on performance -- or confidentiality, integrity and availability.  Truth be told, as simple as it seems, it's not just about raw bandwidth.  Service levels must be maintained and the moment something that is expected doesn't make its way down the pipe, someone will be screaming bloody murder for "slightly clean" pipes.

Ask me how I know.  I've lived through inconsistent application of policies, non-logged protocol filtering, dropped traffic and asymmetric issues introduced by on-prem and in-the-cloud MSSP offerings.  Once the filtering moves past your prem. as a customer, your visibility does too.  Those fancy dashboards don't do a damned bit of good, either.  Ever consider the forensic impact?

Today, if you asked a service provider what constitutes their approach to clean pipes, most will refer you back to the same list I referenced above:

• DoS/DDoS
• Anti-Virus
• Anti-Spam
• URL Filtering/Parental Controls
• Managed Firewall/IDS/IPS

The problem is that most of these solutions are disparate point products run by different business units at different parts of the network.  Most are still aimed at the perimeter service -- it's just that the perimeter has moved outward a notch in the belt.

Look, for the SME/SMB (or mobile user,) "good enough" is, for the most part, good enough.  Having an upstream provider filter out a bunch of spam and viri is a good thing and most firewall rules in place in the SME/SMB block everything but a few inbound ports to DMZ hosts (if there are any) and allow everything from the inside to go out.  Not very complicated and it doesn't take a rocket scientist to see how, from the perspective of what is at risk, that this service doesn't pay off handsomely.

From the large enterprise I'd say that if you are going to expect that operational service levels will be met, think again.  What happens when you introduce web services, SOA and heavy XML onto externally-exposed network stubs.  What happens when Web2/3/4.x technologies demand more and more security layers deployed alongside the mechanics and messaging of the service?

You can expect issues and the lack of transparency will be an issue on all but the most simple of issues.

Think your third party due diligence requirements are heady now?  Wait until this little transference of risk gets analyzed when something bad happens -- and it will.  Oh how quickly the pendulum will swing back to managing this stuff in-house again.

This model doesn't scale and it doesn't address the underlying deficiencies in the most critical elements of the chain: applications, databases and end-point threats such as co-opted clients as unwilling botnet participants.

But to Jeff's point, if he didn't have to spend money on the small stuff above, he could probably spend it elsewhere where he needs it most.

I think services in the cloud/clean pipes makes a lot of sense.  I'd sure as hell like to invest less in commoditizing functions at the perimeter and on my desktop.  I'm just not sure we're going to get there anytime soon.

/Hoff

*Image Credit: CleanPipes

Unified Risk Management (URM) and the Secure Architecture Blueprint

Gunnar once again hits home with an excellent post defining what he calls the Security Architecture Blueprint (SAB):

The purpose of the security architecture blueprint is to bring focus to the key areas of concern for the enterprise, highlighting decision criteria and context for each domain. Since security is a system property it can be difficult for Enterprise Security groups to separate the disparate concerns that exist at different system layers and to understand their role in the system as a whole. This blueprint provides a framework for understanding disparate design and process considerations; to organize architecture and actions toward improving enterprise security.

I appreciated the graphical representation of the security architecture blueprint as it provides some striking parallels to the diagram that I created about a year ago to demonstrate a similar concept that I call the Unified Risk Management (URM) framework. 

(Ed.: URM focuses on business-driven information survivability architectures that describes as much risk tolerance as it does risk management.)

Here are both the textual and graphical representations of URM: 

Managing risk is fast becoming a lost art.  As the pace of technology’s evolution and adoption overtakes our ability to assess and manage its impact on the business, the overrun has created massive governance and operational gaps resulting in exposure and misalignment.  This has caused organizations to lose focus on the things that matter most: the survivability and ultimate growth of the business.

Overwhelmed with the escalation of increasingly complex threats, the alarming ubiquity of vulnerable systems and the constant onslaught of rapidly evolving exploits, security practitioners are ultimately forced to choose between the unending grind of tactical practices focused on deploying and managing security infrastructure versus the strategic art of managing and institutionalizing risk-driven architecture as a business process.

URM illustrates the gap between pure technology-focused information security infrastructure and business-driven, risk-focused information survivability architectures and show how this gap is bridged using sound risk management practices in conjunction with best of breed consolidated Unified Threat Management (UTM) solutions as the technology anchor tenant in a consolidated risk management model.

URM demonstrates how governance organizations, business stakeholders, network and security teams can harmonize their efforts to produce a true business protection and enablement strategy utilizing best of breed consolidated UTM solutions as a core component to effectively arrive at managing risk and delivering security as an on-demand service layer at the speed of business.  This is a process we call Unified Risk Management or URM.

(Updated on 5/8/07 with updates to URM Model)

The point of URM is to provide a holistic framework against which one may measure and effectively manage risk.  Each one of the blocks above has a set of sub-components that breaks out the specifics of each section.  Further, my thinking on URM became the foundation of my exploration of the Security Services Oriented Architecture (SSOA) model. 

You might also want to check out Skybox Security's Security Risk Management (SRM) Blueprint, also.

Thanks again to Gunnar as I see some gaps that I have to think about based upon what I read in his SAB document.

/Hoff

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)

John Thompson's (Symantec) Ironic warning of "Conflict of Interest"

Infoworld ran an interesting article on John Thompson's recent CeBIT keynote in which he took a shot at Microsoft by suggesting that there is an inherently "...huge conflict of interest for one company to provide both an operating platform and a security platform."

I suppose that opinion depends upon whether or not said company suggests that their security controls are all that are needed to secure said operating system or that defense in depth is not needed.

Here's why I find this statement interesting and I am going to twist it by agreeing with the statement within the context of the same argument pertaining to Cisco as an extension to the many, many articles I have already written on this topic.

Given just the last rash of vulnerabilities in Cisco's routing, switching and security products a few weeks ago, I believe it's also a mistake (you can read "conflict of interest" if you desire) for Cisco (le fox) to protect the network (le chicken.)  That's the same argument of the "operating system" and the "security platform."

I think it's simply not relevant or appropriate to simply shrug off issues like this just because of Cisco's size and the apparent manifest destiny associated with security "going into the switch" -- just because it does and more than likely will -- does not mean it should and does not mean that people will settle for "good enough" security when the network consistently fails to self-defend.

I don't disagree that more and more security *will* make it's way into the network switches, much like I don't disagree that the sun will rise in the east and set in the west, but much in the same way that folks don't just give up and go to sleep once the sun goes down, the lightbulb that goes on in my head suggests there is a better way.

/Hoff

The semantics of UTM messaging: Snake Oil and Pissing Matches

Those of you who know me realize that no matter where I go, who I work for or who's buying me drinks, I am going to passionately say what I believe at the expense of sometimes being perceived as a bit of a pot-stirrer. 

I'm far from being impartial on many topics -- I don't believe that anyone is truly impartial about anything --  but at the same time, I have an open mind and will gladly listen to points raised in response to anything I say.  I may not agree with it, but I'll also tell you why. 

What I have zero patience for, however, is when I get twisted semantic marketing spin responses.  It makes me grumpy.  That's probably why Rothman, Shimmy and I get along so well.

Some of you might remember grudge match #1 between me and Alex Niehaus, the former VP of Marketing for Astaro (coincidence?)  This might become grudge match #2.  People will undoubtedly roll their eyes and dismiss this as vendors sniping at one another.  So be it.  Please see paragraphs #1 and 2 above. 

My recent interchange with Richard Stiennon is an extension of arguments we've been having for a year or so from when Richard was still an independent analyst.  He is now employed as the Chief Marketing Officer at Fortinet. 

Our disagreements have intensified for what can only be described as obvious reasons, but I'm starting to get as purturbed as I did with Alex Neihaus when the marketing sewerage obfuscates the real issues with hand-waving and hyperbole. 

I called Richard out recently for what I believed to be complete doubletalk on his stance on UTM and he responded here in a comment.  Comments get buried so I want to bring this back up to the top of the stack for all to see.  Don't mistake this as a personal attack against Richard, but a dissection of what Richard says.  I think it's just gobbledygook.

To be honest, I think it took a lot of guts to respond, but his answer makes my head spin as much as Anna Nicole Smith in a cheesecake factory.  Yes, I know she's dead, but she loved cheesecake and I'm pressed for an analogy.

The beauty of blogging is that the instant you say something, it becomes a record of "fact."  That can be good or bad depending upon what you say. 

I will begin to respond to Richard's retort wherein he first summarily states:

Here is where I stand. I hate the huge bucket that UTM has become.  Absolutely every form of gateway security can be lumped in to this category that IDC invented. We discussed this at RSA on the panel that Mr. Rothman so graciously hosted.

I also assume that this means Richard hates the bit buckets that Firewall, IPS, NAC, VA/VM, and Patch Management (as examples) have become, too?   This trend is the natural by-product of marketers and strategists scrambling to find a place to hang their hat in a very crowded space.  So what.

UTM is about solving applied sets of business problems.  You can call it what you like, but the only reason marketeers either love or hate UTM usually depends upon where they sit in the rankings.  This intrigues me, Richard, because (as you mention further on) Fortinet pays to be a part of IDC's UTM Tracker, and they rank Fortinet as #1 in at least one of the product price ranges, so someone at Fortinet seems to think UTM is a decent market to hang a shingle on.

Hate it or not, Fortinet is a UTM vendor, just like Crossbeam.  Both companies hang their shingles on this market because it's established and tracked.

When trying to classify a market you look for common traits and, even better, common buying patterns, to help lump vendors or products in to a category. But for Crossbeam, Fortinet, and Astaro to be lumped together has always struck me as a sign that the UTM "market" was not going to work.

You're right.  Lumping Crossbeam with Fortinet and Astaro is the wrong thing to do.  ;)

Arguing the viability of a market which has tremendous coverage and validated presence seems a little odd.  Crafting a true strategy of differentiation as to how you're different in that market is a good thing, however.

I much prefer the Gartner view (as I would) of Security Platforms. These are devices that are able to apply security policies using a bunch of different methods and they can loosely be thrown on to a grid...

So what you're saying is that you like the nebulous and ill-defined blob that is Gartner's view, don't like IDC, but you'll gladly pay for their services to declare you #1 in a market you don't respect?

Now, yes, I did join a company that IDC considers to be a major UTM player- leading in volume shipments in those parts of 2006 that they are reporting. But, I was an independent analyst and I NEVER classified Fortinet as a UTM play.

You mean besides when you said:

"By all accounts the so called UTM market is doing very well with players like Fortinet, Barracuda, Sonicwall, Astaro, and Watchguard, evidently seeing considerable success" 

Just in case you're interested, you can find that quote here.   There are many, many other examples of you saying this, by the way.  Podcasts, blog entries, etc.

Also, are you suggesting that Fortinet does not consider itself a UTM player?  Someone better tell the Marketing department.  Look at one of your news pages on your website.  Say, this one, for example -- 10 articles have UTM in the title and your own Mr. Akomoto (VP of Fortinet, Japan) says "The UTM market was pioneered by us," says Mr. Okamoto, the vice-president of Fortinet Japan. Mr. Okamoto explains how Fortinet created the UTM category, the initial popularity of UTM solutions with SMBs..." 

Heck, in the 24 categories for the security market that I maintained I did not even track UTMs. As I tracked Fortinet over the years I considered them a security platform vendor and one that just happened to be executing on my vision for the network security space.

Yes, I understand how much you dislike IDC.  Can you kindly show reference to where you previously commented on how Fortinet was executing on your vision for Secure Network Fabric?  I can show you where you did for Crossbeam -- it was at our Sales Meeting two years ago where you presented.  I can even upload the slide presentation if you like.

As you know Chris I have always been a big fan of Crossbeam and in the interest of full disclosure, Crossbeam was a client while I was a Gartner analyst and my second client when I launched my own firm. Great people and a great product.

Richard, I'm not really looking for the renewal of your Crossbeam Fan Club membership...really.

Crossbeam is the security platform of choice for running legacy security apps.

Oh, now it's on!  I'm fixin' to get "Old Testament" on you!

Just so we're clear, ISV applications that run on Crossbeam such as XML gateways, web-application firewalls, database firewalls and next generation network converged security services such as session border controllers are all UTM "legacy applications!?" 

So besides an ASIC for AV, what "new" non-legacy apps does Fortinet bring to the table?  I mean now.  From the Fortinet homepage, please demonstrate which novel new applications that Firewall, IPS, VPN, Web filtering and Antispam represent?

It must suck to have to craft a story around boat-anchor ASICs that can't extend past AV offload.  That means you have to rely on software and innovation in that space.  Cobbling together a bunch of "legacy" applications with a nice GUI doesn't necessarily represent innovation and "next generation." 

Now let's address the concept of running multiple security defenses on one security platform. Let's take three such functions, Firewalling, VPN, and IPS. Thanks to Checkpoint, firewalls and VPN are frequently bundled together. It has become the norm, although in the early days these were separate boxes. Now, you can either take a Snort implementation and bolt it on to your firewall in such a way that a signature can trigger a temporary block command ala Checkpoint and a bunch of other so called IPS devices or you can create a deep packet inspection capable firewall that can apply policies like: No Worm Traffic. To do the latter you have to start from scratch. You need new technology and several vendors do this pretty well.

It's clear you have a very deluded interesting perspective on security applications. The "innovation" that you're suggesting differentiates what has classically been described as the natrual evolution of converging marketspaces.  That over-played Snort analogy is crap.  The old "signature" vs. "anomaly detection" argument paired with "deep packet inspection" is tired.  Fortinet doesn't really do anything that anyone else can't/doesn't already do.  Except for violating GPL, that is.

I suppose now that Check Point has acquired NFR, their technology is crap, too?  Marcus would be proud.

So, given a new way to firewall (payload inspection instead of stateful inspection) what enterprise would choose *not* to use IPS capability in their firewall and use a separate device behind the firewall? See the trouble? A legacy firewall is NO LONGER BEST OF BREED! The best of breed firewall can do IPS.

Oh come on, Richard.  First of all, the answer to your question is that many, many large enterprises and service providers utilize a layered defense and place an IPS before or after their firewall.  Some have requirements for firewall/IDS/IPS pairs from different vendors.  Others require defense in depth and do not trust that the competence in a solutions provider that claims to "do it all."

Best of breed is what the customer defines as best of breed.  Just to be clear, would you consider Fortinet to be best of breed?

If you use a Crossbeam, by the way, it's not a separate device and you're not limited to just using the firewall or IPS in "front of" or "behind" one another.  You can virtualize placement wherever you desire.  Also, in many large enterprises, using IPS's and firewalls from separate vendors is not only good practice but also required.

How does Fortinet accomplish that?

Your "payload inspection" is leveraging a bunch of OSS-based functionality paired with an ASIC that is used for AV -- you know, signatures -- with heuristics and a nice GUI.  Whilst the Cosine IP Fortinet acquired represents some very interesting technology for provisioning and such, it ain't in your boxes.

You're really trying to pick a fight with me about Check Point when you choose to also ignore the fact that we run up to 15 other applications such as SourceFire and ISS on the same platform?  We all know you dislike Check Point.  Get over it.

I have spent eight of the last 12 weeks on the road meeting our large enterprise clients in the Americas, Asia, and EMEA. None of them shop comparatively for UTM appliances. Every single customer was shopping for firewall upgrades, SSL VPN, spam or virus filtering inline, etc.

Really?  So since you don't have separate products to address these (Fortinet sells UTM, afterall) that means you had nothing to offer them?  Convergence is driving UTM adoption.  You can call it what you want, but you're whitewashing to prove a flawed theorem.

During the sales process they realize the benefit of combined functionality that comes with the ability to process payloads and invariably sign up for more than just a single security function. Does that mean UTM is gaining traction in the enterprise? To me the answer is no. It means that the enterprise is looking for advanced security platforms that can deliver better security at lower capex and opex.

...and what the heck is the difference between that and UTM, exactly?  People don't buy IPS, they buy network level protection to defend against attack.  IPS is just the product catagory, as is UTM. 

I would lay off the Bourbon Chris. Try a snifter of my 16 yr old Lagavulin that I picked up in London this Friday. It will help to mellow you out.

I don't like Scotch, Richard.  It leaves a bad taste in my mouth...sort of like your response ;)

When Blogging goes bad...

Hey, do you remember reading this little snippet as a quote from a certain industry personality we all know and love in regards to his lack of love for UTM?

"I have a problem with the idea of Universal Threat Management appliances.  Leaving aside the horrible terminology (Who wants to manage threats? Don’t you want to block them and forget about them?) the question that I always ask is: If best-of-breed is the standard for large enterprises why would it be good practice for a smaller entity to lump a lot of security functions such as firewall, email gateway, spam filter, anti-virus, anti-spyware, IDS, IPS, and vulnerability management all in one under-powered device?"

I'll give you a hint.  It was posted here by the original author and I responded to it, here.

That's right!  It was my buddy, Richard Stiennon -- lambasting Universal (sic) Threat Management appliances...like those of Fortinet, before they offered him a job.  Perhaps Fortinet doesn't count because they make Unified, not Universal, Threat Management devices?

Don't hate the player, baby, hate the game!  (i.e., be careful what you blog, it could come back to hire haunt you.)

Sorry, Rich.  3 Bourbons and a long week make Johnny a lit boy.  Couldn't help myself.  Fire Away!

/Hoff

UNP = Unecessary New Paradigm?

[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:

Clever 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

Freddy Got Fingered...

Freddy Got Fingered is probably one of the most disgustingly funny movies I've ever seen.  It's truly sick.  In the first 10 minutes, Chris Elliot Tom Green (thanks, Zach!) performs unnatural acts on a farm animal and plays a Brahms concerto on an electronic keyboard with pieces of meat strung from overhanging pulley systems that move up and down as he plays.

Weird.

What the hell does this have to do with what Martin McKeay wrote about my blog entry welcoming Richard Stiennon to the ranks of the UTM vendor pool?  Nothing, really.  Except for the fact that I got "fingered" (ew!) by Martin as he pegged my post for what I said it was -- an un-objective "Welcome to the Jungle" message to Richard who in our last exchanges didn't seem to believe in UTM. 

Now he does.  What a difference a day makes.

I started thinking about Richard's comment about how in his new position he's not going to become a "defender of the product" -- somehow rising above it all and not getting dirty debating the "merits" because he's the Chief Marketing Officer.  At first I dismissed his comments and blew him a kiss given how early in the game it is for him @ Fortinet, but I, like Martin, sure as hell hope that he's not going to hide under a title because he doesn't want to debate openly.

We've called each other out -- sort of. 

I respect Richard's opinions.  I don't happen to agree with all of them and unfortunately I seem to be violating some unwritten rule that suggests it's out of bounds to say so?  I guess that's why I don't consider myself in marketing.  Ptacek would call me on that one because everyone -- including my plumber -- he considers in marketing ;)

When Mr. S. was an analyst he thought fit to be able to debate and agree/disagree with anything I said.  Because he was "independent?"  Now that he's not, he can't?

Perhaps I missed the memo, but I think it's a cop-out to essentially "take the fifth" when doing a 180.  I just don't subscribe to the fact that there's some secret code that suggests that when roles change so do opinions and the exposure that comes with articulating them.

If I went to work for Cisco tomorrow, based upon my comments and opinions in the past, I'd sure as hell expect that people would question me on it and expect to debate the "merits" one way or the other.  I'd also feel compelled to 'splain.  But that's just me.

Also, I'll take any advice anyone has -- whether the topic is fly fishing, chainsaw juggling or branding.  I'm an equal opportunity opinionist that expects to receive as much as I give. ;)

Enough.  This is getting to sound like I'm trying to pick on Richard.  I'm not.  Well, OK.  I am.  But that's what all you people pay to see, right?

Rich -- whaddya say we rent those inflatable Sumo suits @ RSA and do a true UTM grudge match!?  I expect that you'll take Ken Xie's place on Rothman's UTM panel?

Hoff

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

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.

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?

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!

Defending the Self-Defending Network

I recently gave a session presentation at TechTarget's Information Security Decisions show in Chicago.  The topic of my presentation was "Defending the Self-Defending Network with Virtualized Enterprise UTM."  They're actually making a roaming seminar series out of it.

Must have been the shirts and iPods I gave away?

What's the presentation summary?  Simple.  "Embedded" network security as proposed by Cisco is a pipe dream.  In fact, it's nothing more than the aging appliance model with boxes NOT embedded into the routers and switches at all; they're just a single vendor's appliances disguised as "security enablers."

The "Self-Defending Network" is a marketecture.  It's not feasbile, unreasonable, fiscally mis-aligned to (and unaware of) the value of the assets it protects and the worst example of risk management modeling; protecting everything, everywhere, all the time is stupid.

You ought to protect the things that matter most with the best defense possible, where needed, when needed and at a cost where the risk justifies the cost.  Box sprinkling security is so last Wednesday.

You should build a stable, resilient, fast and reliable network.  Stir in some basic "embedded" or appliancized security functionality as acceptable and then overlay virtualized best-of-breed security as a service layer.  See the post regarding SSOA (Security Service Oriented Architectures) below for the full picture.

On a more theatric note...

The wonderful marketing mavens who dreamed up the theme for my session chose football.  I grew up in New Zealand.  I know Rugby.  Moreover, what I really wanted to do was to build a theme around the sport I love most, Mixed Maritial Arts -- a'la Ultimate Fighting Championship (UFC.) 

For some reason they thought that using terms such as "Kimora," "Arm bar," "tap-out by submission," and "rear naked choke" would have some sort of negative impact.  I think it's the perfect model for a network security presentation...so did about 30 of the guys who came back to the booth to discuss the recent UFC match between Rich Franklin and "Spider" Silva...Mui Thai clinches and about 5 knees to the head...awesome!

At any rate, you'll appreciate my lame attempts at football analogies then.

Here's a link to the presentation if you're interested.

Chris

Martin McKeay's Podcast...

I don't know how I forgot to mention this.  I'm an idiot.  I listen to Martin McKeay's podcasts religiously...and I've been lucky enough to participate as part of a Mobcast once before.  Martin's depth
of knowledge and the breadth of catagories/topics and guests he includes is phenomenal.

On August 29th, Martin was kind enough to have me on his podcast and interviewed me.  I did what I always do...talk too much.  We spoke about risk management, the security landscape, and UTM.

If you've got 40 minutes to kill, check out the podcast here.

Chris