Re: http://web-ext2.darpa.mil/iso/ia&s/IA_PIP_990714.html
OK, so I took my highlighter to it, and my first reaction was "This
is a fine BAA, but not for us." One of the most frustrating things
reading it was imagining the kind of information systems they were
interested in protecting -- ATC? target tasking? sensor-fusion?
business processes? Not to mention the usual frustrating prospect of
protecting inherently unstable software systems -- you could get
burnt several layers down the OS, say. But of course, formalizing
that kind of insight is precisely the point of IASET.
This leads to the troubling absence of the word "platform" anywhere
in the document. With due respect to the history of secure OS
development, I think we haven't explored the space of computing
platforms with inherent autonomic assurance properties. We just may
not get anywhere securing Windows or UNIX; and we may not even be
able to effectively secure general-purpose Turing machines. Perhaps
the trick is in defining a "dumber" network that can't go off
computing arbitrary 'active net' code, but only provide a single,
trusted service: say, delivery of Web-like messages across a mesh of
'paranoid' devices (the '*TP' abstraction of the Internet). Going in
the opposite direction, to AI-like aware systems requires massive
engineering, right down to assuring that the video card and drivers
actually print out the warnings you think you're sending...
[Frankly, I read a lot of science-fiction wistfulness into this BAA.
I think they're setting their sights too high on securing
'cyberspace', from group-VR on down: reality will be much more
limited secure systems.]
Another note: the BAA assumes some concepts will remain entrenched,
like "firewall". I think the opposite: to build truly secure systems,
you have to be paranoid enough that everyone's their own firewall,
that you're going to build more robust systems if you don't fob some
security off on your firewalls. Don't forget the central fallacy: a
firewall represents the only ingress to an 'enclave' ... one stray
laptop with an 802.11 wireless ethernet connection, and...
On the other hand, the DC officer could be considered 'entrenched' in
the current IP frame:
>Dr. Maughan came to DARPA from the National Security Agency, where
>he was employed as a Senior Computer Scientist. Concurrently, Dr.
>Maughan co-authored the Internet Security Assoc. and Key Management
>Protocol (ISAKMP) Internet Draft. Before his employment with the
>National Security Agency, he was appointed U.S. technical
>representative to the NATO Tri-Service Group on Communications and
>Electronics (TSGCE) Working Group on Security.
That is to say, our approach to DC -- that it's got a low-level part
(between very small embedded devices in pico-nets) and a very
high-level part (secure workflow corrdination and event
notification/revocation) -- may simply fly around the target area,
which is really a request for high-speed secure IP protocols for
multicast and anycast. and group management.
So pitching munchkins -- paranoid, ad-hoc, economically-grounded,
REST-programmable, message-relaying networks -- don't advance their
goals on the face of it. I think that it will be an interesting
secure system, and aim to provide a highly-assured plaftform for
ad-hoc 'coalitions', but I can't see firm enough promises to make it
all hang together.
I'll keep thinking about this, in other moods, and see if more ideas emerge.
========================
Here are my notes from the BAA and the workshop notes from
http://schafercorp-ballston.com/may99wkshp/
DC: topic 1 is all about policy management, the dual of "trust
management", a nascent approach to secure systems. This subproblem
can be seen as pitched directly to that crowd (KeyNote, &c) only.
Noteworthy goals: automated policy negotiation (see the difficulties
with the original Privacy work at W3C (P3P)); and that "underlying
network technology should not have an impact on the representation of
the security policy" (sounds like "no IP#s and other hardwired
assumptions in the config files").
My first hope was to propose economic metrics for such policies:
decentralizing aspects of the problem through currency, but I see
from the presentation at
http://schafercorp-ballston.com/ia&s_industry_day/IAS_DC.ppt that
'market-based allocation' is considered part of 'Fault Tolerant
Networks' and not part of this BAA.
topic 2 has more potential for us., but still limited. He seems to be
looking for a 'multicast IPsec', zooming in on key-management
problems and join/leave rate control, &c.In fact, some of the
concepts I've mooted privately for ad-hoc device nets are ruled out,
e.g. simply throwing CPU at the problem of digitally signing
messages, and restricting attention to large-grain, less real-time
messages.
The third topic, infrastructure, we might have hoped scaled up to
application-layer issues like presence & event notification, or at
least virtual-enterprise coordination, but no, again, it's a focus on
low-level key management issues. and access control - distribution.
On to IASET: I'm also pessimistic that C2 offers unique traction on
modeling information assurance. True, we could *apply* such thinking
to build a secure-C2 model (policy-enforcing connectors, for
example), but even then, it's a tough sell to this grant. (IASET
topic 4 mentions trust analysis of composite systems, but only
barely).
Personally, I think economic models may prove a usefiul form of
'cyberscience', for measuring 'exposure' and 'leakage' and so on, but
while it is speculative, it's not clear that we have the theoretical
depth to do much with it; and building prototype platforms based on
this insight doesn't appear in the funding goals for IASET topic 1 or
3. There's even a hint under the AIA problem for QoS enforcement:
the 'value' of a process, link prioritization, &c.
Otherwise, AIA seems completel y out of our expertise here.
There's a presentation on 'cyber C2' that begins to illuminate the
military mind:
>Fundamental Concepts
>What is "terrain"?
>Network topology?
>Link capacities?
>Protocols supported?
>OSs, DBMSs?
>Firewalls?
>What are "forces"?
>Humans?
>Agents?
>Mission functions?
>What are "weapons"?
>Attacks/exploits?
>Correlation of forces?
>Observables?
>Doctrine?
i.e. a pretty literal view. The PPT is huge and slow, but worth
flipping through:
http://schafercorp-ballston.com/ia&s_industry_day/CC2_brief_Industry_D
ay.ppt
Postscript: Isaw the following old CBD announcement out of the
Special Projects Office:
http://www.darpa.mil/baa/acn.htm
AIRBORNE COMMUNICATIONS NODE (ACN) PROGRAM... The services that ACN
will provide include: PCS-like circuit oriented voice and data;
militarized tactical paging; internet-like data networking; tactical
battlefield multicast; high speed and high throughput infrastructure
access potentially including TCDL line-of-sight, Ku SATCOM and
air-to-air crosslinks to form a self-organizing backbone; surrogate
satellite support for UHF TACSAT and GBS receive/relay; dissimilar
radio interoperability; and range extension for over-the-horizon
connectivity of dispersed and rapidly moving forces. ACN will provide
the ability to exchange multimedia data through an internet-like data
network that supports user and platform mobility, wireless links and
military quality of service (QoS). The ACNwill enhance rapid force
projection, synchronization and synergy of Joint early entry forces
to achieve improved battle command coherency. The various
communications services will be implemented or emulated utilizing a
modular, software reprogrammable open systems architecture.