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