Re: Networking Pearl Harbor in the Making

[Chris Woodfield <rekoil () semihuman com>]

The problem is that generally, things have to get *really* bad before 
people will switch to a more secure infrastructure...it's all about 
costs, and the cost of staying with a less secure platform must 
substantially exceed the cost of switching before it's considered a 
reasonable response. It takes big numbers to overcome intertia.

A decent parallel is gas prices - people didn't stop buying SUVs in 
significant numbers until the price of gas broke $2 a gallon. And it 
wasn't until we hit $3 before people started trading in their Hummers. 
Again, the cost of maintaining the status quo had to get *really* painful 
to overcome the inertia of staying there.

This is already happening on the server side (see the growth rates for 
Linux vs. Windows server software), but it hasn't happened yet there on 
the network infrastructure side, primarily because the 'net has 
yet to see a real large-scale security incident involving network 
hardware. Yeah, Slammer maxed out the flow tables on a bunch of boxes, but 
the routers themselves weren't targets. And swapping out network infrastructure 
in many cases far more costly than migrating server OSes, particularly for 
us folks for whom the network IS our product.

Thus, I feel that it's going to take a wide-scale exploit *of the 
routers themselves* causing large-scale outages before enough people 
switch to make the vendor feel any real pain directly related the failure 
to secure the infrastructure. Only then will we begin to see our 
networks become truly more secure.

-C

On Mon, Nov 07, 2005 at 12:39:31PM -0500, Christian Kuhtz wrote:
> On Nov 7, 2005, at 12:16 PM, Todd Vierling wrote:
>
> > On Mon, 7 Nov 2005, Christian Kuhtz wrote:
> >
> > > > How so? Haven't we recently seen an across the board bug in
> > > > multiple version of $vendor code?
> > >
> > > And that's evidence of what other than nobody is willing to pay  
> > > for what it
> > > takes to get better code out of $vendor?
> > >
> > > Code can be built better.  It just isn't always economical to do so.
> >
> > In some business models.
> >
> > Financial reports regularly hint that $vendor has margins far  
> > exceeding the
> > costs necessity to clean up security-critical code.  When the  
> > aggregate
> > margins drop thanks to folks choosing $vendor2 because $vendor has  
> > decided
> > to let security flaws stew, it's time for $vendor to reevaluate that
> > business model -- at least a little.
>
> Apparently they're still in business, and they're making money, and  
> that means people are still buying their stuff.  And as long as  
> that's true, nothing will change.  Correlating a margins over a very  
> large product range with bugs specifically in service provider gear  
> is problematic in my opinion.  Apples v Oranges.  Whatever, it really  
> doesn't matter.
>
> Reliability should be engineered by the SP, not exclusively expected  
> from any one vendor.  And you can improve reliability by using same  
> devices in a particular fashion, not just by using different devices,  
> which was my whole point about calculating reliability in the first  
> place.
>
> Thanks,
> Christian