(A)vailability > (C)onfidentiality + (I)ntegrity…Part Deux: Film/Video NOT At 11…
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.
There is very little preventing someone from re-routing traffic. This could result in either a denial of service (as the traffic would not reach its destination) or even something akin to an interception, "storage" and eventual forwarding for nefarious means.
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
I remember the AS7007 incident intimately, and I'll say no more than that on that issue.
Whilst there is a smattering of security related to this, what it really comes down to is policy on the acceptance and advertisement of prefixes from downstream clients to your upstream provider(s). PCCW had no (or limited) inbound and outbound filters on what was to be accepted and advertised. Neither did their upstream, or their their upstream.
This is not a case of security, it's just plain, flat out laziness and the responsibility sits fairly and squarely on the heads of the providers and, to a limited degree, on the head of the Pakistan provider for redistributing those routes into BGP in the first place.
We will see this again, without a doubt, given the laissez faire attitude of a lot of new (and a good proportion of older) service providers providing tier 1 and 2 Internet services.
Availability quite often trumps C & I, because it's the only part of the CIA triangle that VPs actually GET and care about in many organizations. However, they're not universally balanced, and there are many instances where it's far better to take an outage than to permit corrupt data — life systems with infusion products or a gamma knife machine would be a good example.
Interestingly enough, I was just compiling all the stacks and loads of regulatory/legal requirements for C, I & A. Big stack for C, Big stack for I, hardly any (if at all) regulatory requirements for availability. Interesting.
As usual Chris, you've offered another thought provoking post – thanks and keep 'em coming!
From my understanding, the CIA triad only considers availability as it pertains to authorized parties; what it fails to consider is unavailability to unauthorized parties. Since information security is essentially the control of access to information resources, both perspectives need consideration.
Additionally, the CIA triad seems to view each component as being autonomous, with the ability to synergistically enhance one another. However, it doesn't seem to identify the reliance upon each for the other to "succeed". To that, suggesting any one trumps the other appears to overlook this interdependent relationship between the three.
For instance, if the integrity of a BGP advertisement is compromised, the corrupted routing tables could result in the inaccessibility [unavailability] of a network for authorized parties. If the confidentiality of an email is compromised, the information could be accessible [available] to unauthorized parties.
Of course, this gets us into a chicken-egg scenario, where information has to be available to in order for it to be confidential or accurate, yet without being confidential or accurate, it may or may not be available. Scenarios like these have me leaning more towards the Parkerian Hexad because it expands the CIA triad by including subtle, yet important differentiations which also tend to identify some of these interdependencies.
As always, I'm interested in your thoughts on the matter.
Cheers!
Good. Great post dude!