Re: one use for taxonomies

[Brenda <asparagi () hhhh org>]

Andrew,

I completely agree that the point of threat modeling is to analyze
business risks, and I also agree that as currently formulated, a threat
model with lots of technical details is difficult to use for business
risk analysis.  However, the technical details have a major effect on
risk analysis for business issues, because they control many cases of
whether the business issues can occur.  I think issues affecting the
technical kingdom you outlined belong in the threat model as part of the
attack graph, and issues affecting the business and user kingdoms you
outlined are related to the risk model which is part of? related to? the
threat model (e.g. if this issue occurs, how bad is it for our
business/joe user?).

Using an experimental tool I really ought to hurry up and release, we
have already automated threat generation for data assets using two
extremely simple taxonomies (one for actions, one for threats).

The action taxonomy we are using is CRUD (create, read, update, and
delete), the old relational database standby.  The threat taxonomy we
are using is elevation of privilege and denial of service.

The way it works is, you describe the business requirements of the
system in the form of business rules regarding when actions on assets
can occur.  For example, one intended action of a Blog application might
be "User creates Blog Entry on User's own Blog".  When you have the
complete set of business rules for all intended actions, you know what
all of the potential business issues regarding the system (threats) are,
because they are all either more (elevation of privilege) or less
(denial of service) than the intended actions the system should support.
  There is an elevation of privilege threat for each potential action
(from the action taxonomy) on each asset, and a denial of service threat
for each intended action, plus 2 threats we've been calling the social
responsibility threats, which affect the assets of other systems.  For
example, with the business rule given above, the elevation of privilege
threat (and top of attack tree) we would usually use is something like this:

Someone creates Blog Entry despite rules
  OR
    Someone other than a User creates Blog Entry
    User creates a Blog Entry on someone else's Blog
    User creates a Blog Entry without a corresponding Blog

So far, experimental evidence indicates that this partial automation
assists experienced folks in missing fewer business-level issues than
manual methods.  Because the only way an attacker can affect the things
you listed in the business kingdom is to violate the business rules of
the system, all business risks to the system can be analyzed using the
threats generated in this way.  (I should mention that in practice,
doing that properly would require some mechanism for relating the
concepts from your business kingdom to the specific business rule
violations/threats; we haven't tackled that yet and I don't know that we
should, because it seems like an entirely business issue and different
expertise than ours would be needed.)  In our model, all threats are by
definition business issues because the set of threats is the complete
list of possible business rule violations.  Interestingly, this means
you can generate the threats for a system given its requirements
document, so if you are working closely with a development team, you and
the team can determine what the threats are before they start writing
the specification.  We haven't had an opportunity to try this out
properly yet (willing guinea pigs please contact me off-list).

What we have now can definitely be improved; flaws we've noticed (over
the past year or so that we've been testing this) include:

- all the complexity of the requirements lands in the business rules,
which are completely free-form/for which we have no taxonomy
- representing repudiation is arguably slightly clunky, in that you must
explicitly include logging as a business rule for actions you wish to log
- in real-world systems there are frequently several actions which
should be performed together, as a single atomic action, which for now
you must textually and clunkily describe in the rules for each relevant
action
- arguably there is a fifth action named invoke; we tried this for a
while and it seemed to just be adding noise, but for modeling an
operating system or virtual machine, it may be needed
- we have no action taxonomy for physical objects
- because these threats are business-level threats, there is a huge
amount of repetition in the attack trees under them (all of which falls
into your technical kingdom), further exacerbating the need for a
different factoring (e.g. one directed attack graph vs. trees) and
automation, which we don't have for attacks

So, although this partitioning of "all the threats" seems pretty good
and could potentially be correct, or grow into being correct with some
tweaks, we are working on a different partitioning/threat taxonomy which
is based on Ross Method.  Ross Method is a notation for describing
business rules which comes from the relational database world.  This
would eliminate the action taxonomy and change the asset selection
process we have now into a data modeling step before the rules
definition step.  Hopefully this will fix many of the above issues, but
it may raise new ones (e.g. is Ross Method complete for business rules
we care about, how do you break business rules, ...).

> User Kingdom view
> 1.0 An attacker may be able to steal my credit card when I use this
> service

This is very interesting -- when you present it like this I wonder
whether essentially the same model, with the same threats and attack
trees, could be useful for multiple different stakeholders in a system.
 All you might need to change are the exposure values which weight how
bad each threat would be if it occurred, to reflect the different values
of each party, and potentially what is considered in scope, to reflect
how much detail each party can control/wants to know about.

> I personally don't think this is tractable problem for automation
> except as a subset of a particular kingdom.

I don't understand what you mean in this sentence.  I think you might
mean we would need to automate things related to each kingdom
separately?  I might agree with that, at least for some pairs of kingdoms.

> What we need are better
> threat modeling tools to assist in the creation of threat models.

I'm working on that, but I have to warn you that the user interface is
rather different, it does a lot of automation, and initially I'm
planning to punt to the MS tool (by exporting) for stuff that we don't
know how to automate yet.  So, it might not be what you want.  I am
shooting for release within the next month.

I hope somebody will tell me if I'm straying too far off topic for this
list, and suggest a more appropriate venue.

Brenda