Re: one use for taxonomies

["Paul B. Saitta" <pbs () dymaxion org>]

On Fri, Jul 15, 2005 at 11:33:55PM +0100, Frank O'Dwyer wrote:
> I'd like to suggest a different and possibly heretical view, which is
> that maybe you don't need an (explicit) threat model at all. My reason
> for saying that is for any of the formal analysis I've seen, it doesn't
> lead to a different outcome, compared to much simpler and less formal
> approaches (it depends on the approach, of course).
>
> If you step back and look at the ultimate goal, it is to implement a
> system [or a system dev lifecycle] with effective countermeasures
> (technical and non-technical). The question is, which countermeasures
> will those be? 

<snip>

> The thing is if the sort of question you will ultimately answer is
> something like "gee, I wonder which transport security protocol we will
> use THIS time. Will it be SSL/TLS, or, um...I'm sure there was another
> one" - well, why not just cut to the chase?

This misses the point by a bit, I think.  While you can often short circuit
the choices of which countermeasures to use, once you've figured out the
definition of the problem, until you understand the problem, you don't know
what properties you need out of the system.  I mean, if you want to encrypt
all data at rest, use SSL everywhere, always use two-factor authentication,
etc., that's great.  I think whoever's paying the bills may complain, though.

We all like to think that the definition of the problem is patently obvious.
It's not.  Determining where you need your system to have which properties and
when they need to be enforced can actually be rather difficult, especially in
non-trivial systems.

The key part of threat modeling is not deciding which mitigations to use to
deal with a given weakness and prevent an attack from succeeding, it's figuring
out what you need to protect in the first place, and where those mitigations
need to be used.

Honestly, a large part of threat modeling, when done correctly, has nothing to
do with mitigations, code, or any implementation details.  Instead, it worries
about the business rules and ways to attack them directly.  Why should I (as
an attacker) bother owning a machine when I can just exploit the rules of the
application and get what I need done anyway?  There are no stock mitigations
to this class of problems, because there can't be -- they all follow directly
from the requirements of the application in question.

The other reason to do formal analysis is to ensure completeness.  Any time
you're using an ad hoc method in a security setting, you've lost.  You may get
it right 99% of the time, but the attacker only needs you to screw up once.
Would you trust crypto without formal analysis of its strength?  No.  Why
trust a security architecture without the same guarantees, then?

I recognize that threat models can be a lot of paperwork, and they can be a
real pain to do, but you get what you pay for, especially when you look at
security processes over time.  The one-off app done by the rock star team is a
very different situation than the fiftieth outsourced billing application, and
even the one-offs tend to have big problems.

I've got a paper which should be up tomorrow describing the current (as of a
few months ago) state of the threat modeling work that Brenda and I have been
doing that may be interesting to people here who'd like to see a slightly
different perspective on threat modeling.  I'll send the URL here when it's
up, if that's ok with people.

/P.

-- 
Ideas are my favorite toys.

Attachment: _bin
Description: