We had a little chat a few weeks ago at the apparent shock suffered by many a security professional in discovering that the three-legged stool of security was constructed of unequally leveraged legs of C, I and A.
Some reckon that by all practical accounts C, I and A should not be evaluated or assessed in a vacuum, but depending upon your line of business, your line of work and how you view the world, often this is how things get done -- we have very siloed organizations, so it leads to siloed decision matrices.
Specifically, availability (or service delivery) in reality -- despite what theory and purists espouse -- often trumps "security" (the C and I functions.) As distasteful as that sounds, this is endemic. From operating systems focused on "usability" rather than security to routing protocols focused on rapid convergence and assumed trust as opposed to secure and authenticated mechanisms.
To wit (from the Renesys Blog):
Pakistan hijacks YouTube
Late in the (UTC) day on 24 February 2008, Pakistan Telecom (AS 17557) began advertising a small part of YouTube's (AS 36561) assigned network. This story is almost as old as BGP. Old hands will recognize this as, fundamentally, the same problem as the infamous AS 7007 from 1997, a more recent ConEd mistake of early 2006 and even TTNet's Christmas Eve gift 2004.
Just before 18:48 UTC, Pakistan Telecom, in response to government order to block access to YouTube (see news item) started advertising a route for 208.65.153.0/24 to its provider, PCCW (AS 3491). For those unfamiliar with BGP, this is a more specific route than the ones used by YouTube (208.65.152.0/22), and therefore most routers would choose to send traffic to Pakistan Telecom for this slice of YouTube's network.
Yes, this is really a demonstration of unavailability, but what I'm getting at here is that fundamentally, the core routing protocol we depend upon for the backbone Internet transport is roughly governed by the same rules that we depend upon whilst driving down a road separated by nothing more than painted lines...you simply hope/trust that nobody crosses the line and crashes into you head-on.
So, here we have a case where again we depend upon a protocol that was designed to provide (A)vailability, yet C and I are left floundering in the wings. We'll no doubt see another round of folks who will try and evangelize the need for secure BGP -- just like secure DNS, secure SMTP, secure...
This will hit deaf ears until we see the same thing happen again...
/Hoff
v