Re: [fw-wiz] Application-level Attacks
From: Stephen P. Berry (spb_at_meshuggeneh.net)
To: "Marcus J. Ranum" <email@example.com> Date: Sun, 30 Jan 2005 17:42:10 -0800
-----BEGIN PGP SIGNED MESSAGE-----
Marcus J. Ranum writes:
>>Anything which does I/O can be though of as using a protocol.
>True! So then anything that is written in software is an application!
>And, in fact, since hardware is written in software nowadays, it's
>an application, too! So - EVERYTHING is an application. All attacks
>are application layer attacks!
What we discover here is that taxonomies---and in particular
descriptive taxonomies---aren't particularly useful guides to
the functional relationships between its categories.
Lemme give you a ferinstance. Right behind my computer desk is
a hundred gallon reef aquarium. One of the cool things about
reef aquaria is that you constantly discover unexpected things
in them (i.e., critters you didn't realise you had). When you're
trying to figure out what one of these this is, you tend to come up
with a description of it (segmented, hard shell, number of legs,
type of symmetry, and so on). You then take that description and
look it up in a marine biology text to figure out what it is.
This works because most biological taxa are based on simple descriptions
of morphology---what kind of parts something has, how many of them, and
how they're put together. This is hugely useful if you've got some
unknown animal and you want to be able to classify it: you can
map the characteristics to a name, and then use the name to look up
the available information on the animal. Think of this as a sort
of hash function, with morphological characteristics as the key.
Turns out that this is a lousy way of doing things if you're interested
in figuring out if two critters are related---all things that have
certain physicial traits are not necessarily related. Calling something
an `arthropod' is a description of its morphology, not its phylogeny.
By now you can probably see the analogy I'm making. When we're looking
at the latest exploit _du jour_, what we're generally interested
in are things which are best stated as parts of a risk analysis:
what is actually affected by the exploit; what the consequences of
the exploit are; what will need to be patched or reconfigured to
prevent the exploit; u.s.w. Turns out that the OSI seven layer
model maps onto those characteristics only incidentally; the OSI
seven layer model is a lousy model for risk analysis.
Having spent a fair amount of time recently trying to formulate
formal grammars for risk analysis (and, as a consequence, for
clearly enunciating intrusion detection, firewalling, and related
functions), it strikes me that the most interesting things about
attacks (from an analyst's standpoint) tend to have less to do
with the technical details of -how- an exploit works or the
literal details of what it affects (i.e., web server foo, version 1.x
or whatever), and much more to do with what the impact on the
target organisation is.
Since this will vary from organisation to organisation (depending
on what's exposed, what the auditing capabilities are, what containment
around the exposure looks like, and so forth), this leads me to
suspect that statements like `the latest attack on foo is a foozle-layer
attack' are inherently semantic nulls for everything but the most
If you want a one-liner to take away from all this, I suppose my
observation in a nutshell is that we talk too much about mechanisms
and too little about consequences. This makes sense in that the latter
is very much a context-dependent thing (and therefore isnt' terribly
suitable for whitepapers and marketing blurbs), but that's where
most of the actual interesting stuff is.
0 What exactly, if anything, it is -not- a lousy model of is
another question altogther.
1 If a particular bug is a buffer overflow, for example, we
can certainly make some general statements about buffer
overflows---but being a buffer overflow isn't necessarily
interesting information from the risk analysis standpoint.
2 Mod the case where part of your defence-in-depth strategy
involves nonexecutable stacks, StackGuard or an isomorphism
thereof, Multics, or whatever.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (OpenBSD)
-----END PGP SIGNATURE-----
firewall-wizards mailing list