North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Networking Pearl Harbor in the Making
- From: Chris Woodfield
- Date: Mon Nov 07 13:26:56 2005
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.
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
> >margins drop thanks to folks choosing $vendor2 because $vendor has
> >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