Re: Application-level Attacks

["Stephen P. Berry" <spb () meshuggeneh net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


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[0].

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
trivial cases[1].


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.



- -spb

- -----
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].
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)

iD8DBQFB/YzfG3kIaxeRZl8RAgJ5AKDdfCTUE30gW99RvYae7bmG6SXHpgCfcagg
4yYWYH0tXjppHpyeCafCKQU=
=i8Dd
-----END PGP SIGNATURE-----
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards