one use for taxonomies

[Brenda <asparagi () hhhh org>]

I'm one of the "folks in Seattle" Arian mentioned in a previous post.
I have read what seemed relevant in the list archives, but I just got
here; I apologize if I am restating points others said previously.

Some colleagues & I have been working on a more consistent,
reproducible, computable &c threat modeling methodology.  If you've
constructed a few threat models for systems of moderate complexity using
any methodology of which I am currently aware, you know that a lot of
threat modeling work is very repetitive.  But, because of the way
existing methodologies break the problem down, if you want a useful
model, an experienced security person must do most of the construction
(or at least extensive review, which takes nearly as long as
construction) of the model.  You can see this for yourself by asking a
group of developers with little or no security experience to construct a
threat model using existing methodologies.  I have never seen such a
model which did not miss many, many design-level holes which threat
modeling is supposed to catch.  In fact, our experience has been that
more than one experienced security person really ought to take a look at
a model before it is finished, because there are regularly a couple of
holes which slip past just one of us.

What this inconsistency, even in models produced by experienced people,
says to me is that threat modeling is currently an art, not an
engineering process.  The repetitive nature of the majority of the work
is a strong clue that the process would benefit from some automation.
Obviously it is difficult to automate an art.  We are trying to break
things down differently, so that the repetition and the thinking are
more separated, so that people can get more consistent, and hopefully
more useful, results.  I admit that we'd also like to minimize the
error-inducing boredom.

In practice, many groups of people who do a lot of threat modeling
construct libraries of known attacks, threats, vulnerabilities,
mitigations.  These libraries are essentially
categorizations/taxonomies, albeit in the
folders-for-organizing-your-mail way that Frank mentioned.  This
strategy has been used by multiple groups, apparently independently, to
try to produce more consistent threat models.   Interestingly, in every
library I've seen to date, instances of different types occur side by
side in lists that imply they are parallel.  For example, in one list of
"vulnerabilities" I saw items like these:

XSS (I would call this an attack)
output encoding (I would call this a mitigation)
permissive access controls (I would call this a weakness)

Whether [portions of] a process like threat modeling is automatable
depends on (among many other things) the way the concepts needed to do
it fit together.  A clearly-defined partition of the concept space
(think a data model or object oriented design for the concepts) is a
prerequisite to automation, and to the transition from art to
engineering.  There might be ways to automate portions of threat
modeling without a good categorization scheme for the important
concepts, but right now the line of thought which looks most promising
is to come up with those taxonomies.  At the moment, it is not clear to
me whether deciding which concepts are important and selecting
definitions for them which mesh appropriately is separable from choosing
the categorization/taxonomy itself.

I agree that this is an extremely sticky problem, for which there will
be multiple correct answers.  I have not encountered even one correct
answer, in the sense of a logical partition of the concept space
followed by a logical partition of the instances in each concept.  I
think it would be beneficial to have a published example of a correct
answer.  As its limitations become clear, future sets of definitions and
taxonomies can at least have something to measure themselves against
(Did I include everything these guys did?).  In the meantime, using a
named set of taxonomies can aid communication in the face of terms with
multiple, inconsistent definitions.

Brenda