RE: [emergency] CAP and DDoS

[Art Botterell <acb@incident.com>]

Len, Rex, et al. -

What you're rightly describing is a broad, deep and enduring 
challenge in emergency management generally.  Obvious near-term 
efficiencies frequently come with hidden costs to resilience and 
adaptability that are only noticed once it's too late.

Whether we're talking about structural vulnerabilities in 
sophisticated works of engineering (e.g., WTC/Space Shuttle), 
economic and logistical brittleness caused by just-in-time inventory 
practices (West Coast Longshoremen strike), foreseeable hazards 
resulting from poor land-use choices (many if not most floods), 
operational vulnerabilities that accompany application and 
operating-system monoculture in IT (MyDoom, Slammer, et al.), or the 
perils of putting all our eggs in one telecommunications basket... 
and the list of examples can go on and on... the pattern is that 
apparent convenience and economy can easily distract our attention 
from the strategic implications of our choices.

Emergency management professionals are only too aware of this 
fundamental trade-off, but they also know that the policy-makers they 
work for are under relentless pressure from the obvious and the 
immediate.  For example, TCP/IP networks can be made highly reliable, 
but they're usually engineered for profitability more than 
reliability.  And any single technology is a potential 
single-point-of-failure, but the costs of diversity are seen daily 
while the rewards appear only occasionally.  It's a constant struggle 
to stretch the horizons of corporate or governmental decision-making 
beyond the immediate and the familiar.

(Frequently... tragically... the only time we see decision-makers 
achieve a clear focus on issues of preparedness, hazard mitigation 
and systemic resilience is right after the community suffers some 
serious loss.  It's a hell of a way to make progress,  but sometimes 
it's the only way it happens.  Thus public safety and security has 
advanced in fits and starts over the years, too often punctuated by 
horror.)

So yes, this is an issue I hope we'll all strive to communicate, 
clearly and consistently.  It certainly features prominently in the 
briefing PPW will be providing at NEMA next week... although again 
that's mostly preaching to the choir.  The EIC will have an even more 
important audience during the March session on the Hill.

- Art


At 12:42 PM -0600 2/6/04, Bullard, Claude L (Len) wrote:
>And that message should be communicated.  Otherwise,
>good intentions over flaky protocols will filter
>into the infrastructure.  A problem of the current
>environment is that too many in the Beltway and
>elsewhere are drinking the HTTP/REST/IP kool-aid and
>not taking into account the unreliability and
>vulnerabilities of the base TCP/IP infrastructure.
>So Federal dollars will be attached to agency
>procurements based on those technologies. 
>
>Some will understand and refuse to build it
>for mission critical applications; some won't. 
>
>Be sure the message is clear and the risks
>are well-explained.  An XML document doesn't buy
>them security or protection.  Being agnostic
>and failing to explain the need to completely
>assess the risk of the transport are different.
>
>Thanks!
>
>len
>
>
>From: Art Botterell [mailto:acb@incident.com]
>
>At 5:09 PM -0600 2/5/04, Bullard, Claude L (Len) wrote:
>>Perhaps out of scope, but of interest:  how  would Distributed
>>Denial of Service (DDoS) attacks affect the capabilities of systems
>>using CAP?  Pretty much as it would affect  any IP server, yes?
>
>Right.  In fact, any transport mechanism is vulnerable to some sort
>of denial-of-service attack, be it Internet-based DDOS,
>radio-frequency jamming or even plain old-fashioned "backhoe fade."
>
>This is one of the reasons we've all worked so hard to keep CAP
>transport-independent.  Technical diversity, through the integrated
>use of a combination of distinct transport technologies, is one of
>the best ways to mitigate the risk of DoS attacks and accidents.
>It's a lot harder to jam every technology at once than it is to jam
>any one at a time.