RE: Networking Pearl Harbor in the Making
On Monday 07 Nov 2005 3:42 pm, Hannigan, Martin wrote:
It's an argument for vendor diversity.
No it is an argument for code base diversity (or better software engineering).
Vendor diversity doesn't necessarily give you this, and you can get this with one vendor.
How so? Haven't we recently seen an across the board bug in multiple version of $vendor code?
Vendor diversity might be a good idea, but for other reasons.
Sure. There are more reasons than one to do it. I was specifically pointing out that code diversity is a good one - and not forgetting associated cost and economic impacts as mentioned in a later followup. -M<
On Nov 7, 2005, at 11:11 AM, Hannigan, Martin wrote:
On Monday 07 Nov 2005 3:42 pm, Hannigan, Martin wrote:
It's an argument for vendor diversity.
No it is an argument for code base diversity (or better software engineering).
Vendor diversity doesn't necessarily give you this, and you can get this with one vendor.
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.
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. -- -- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>
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
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
participants (4)
-
Chris Woodfield -
Christian Kuhtz -
Hannigan, Martin -
Todd Vierling