RE: Threat Modelling

["Mark Curphey" <mark () curphey com>]

I don't disagree with anything specifically you say but here are a few
observations. In general IMHO this conversation started discussing apples
(threat modeling to build better technical solutions) and is now trying to
compare oranges to apples (info sec management of systems).

It is easy to abstract security to a higher and higher level to become more
comfortable with your answers or to find a valid objection. Should I review
the political stability of the country where the code is being created in? I
am sure someone can come up with a good argument for it but in practical
terms you have to set a scope or decompose complex problems into smaller
more manageable ones to be successful. Big generic risk models are bulky,
costly and seem to have been ineffective if you look at the landscape today.
I have done work for various companies where they spend massive amounts of
money developing formal risk models for systems that all miss significant
issues. I don't disagree that policy is a fundamental place to start but as
Dr Phil says (so I am told!), you don't loose weight with a gym membership!

I actually think you probably hit the nail on the head when you talk about
"applications of this class". The detail you elude to I have never seen in
any RA tools. If it were it would be able to support the threat modeling
process of the type defined in writing secure code etc I think that would be
great. Hopefully the MS tool or others that I think are brewing will.

I think it boils down to the fact that you have to choose the right tool for
the right job. The thread was about modeling technical security using a
process that has been come to be called threat modeling. There are other
techniques such as risk assessment for higher level / bigger picture stuff
but IMHO they are not the right tool for the right job. There are clearly
overlaps but the devil is often in the details with software security. If I
want to race a car I am going to choose the right sort of car, not one that
meets a set of high level requirements such as having 4 wheels, an engine
and a steering wheel. 

You certainly don't need a specific tool for each application but do need a
tool that is specific to software development and the uniqueness that
software security brings. I would argue that traditional risk assessment
tools and techniques have been around for decades but are clearly not
working on software security today. Actually I am sure a set of criteria and
a methodology can be developed that would fit under various tools frameworks
today, after all what we are discussing is a subset of the bigger picture,
higher level risk assessment. 

But for modeling technical security of software designs, I have to say I
still don't believe high level risk assessment tools have a strong place to
play.

-----Original Message-----
From: Frank O'Dwyer [mailto:fod () littlecatZ com] 
Sent: Sunday, May 23, 2004 5:08 AM
To: Mark Curphey
Cc: webappsec () securityfocus com
Subject: Re: Threat Modelling

Mark Curphey wrote:

> To quote ...."The tools used for Risk Management in certification & 
> accreditation (NIACAP/DITSCAP) are very effective for threat modeling."
>
> Maybe I am missing the point here so please help me out.
>
> How would these generic tools help me methodically expose the fact that 
> an application developer chose to send a password in clear in an 
> unprotected SOAP message across an untrusted network?
>
> How would these generic tools help me expose an application that used 
> DNS to authenticate a components location?
>
> How is a generic tool going to help me expose an application that is 
> not validating input from a 3rd party web services data feed ?
>  
I know your question is directed at a different set of tools, but I'd like
to try to answer it from the perspective of ours. I'm not sure whether your
issue is with 'generic' tools or with automated tools in general, however
the examples you've picked are good ones to illustrate the point.

The first question to ask yourself is are the issues you have identified
above 'generic' or not - generic doesn't necessarily mean 'non-technical'.
The particular examples above seem pretty generic to me
- there is a whole class of applications that use SOAP, a whole class of
applications that use passwords, DNS, third party feeds, etc. These are all
*generic* technologies with *generic* requirements therefore it's quite
reasonable to look for a *generic* solution or method that addresses such
classes of system. In other words, whether your response to these issues is
a policy statement, a process, deployment of some pen testing tool, code
review, hire a consultant, deploy infrastructure, a combination of all of
these, or whatever - that response is your answer for any application in
this class. And that remains true whether you use a tool to automate the
process or not.

Not only that but these requirements all flow from much higher level
business imperatives, which cannot all be addressed solely by technical
means. Therefore any system that is ONLY looking at technical issues is
going to miss the mark. The requirement not to send a password in clear is a
good case in point. This may flow from a requirement that only employees can
access the business's systems, for example.  To achieve that requires that
you don't issue a password to a non-employee in the first place - this is
something that involves people issues, and almost certainly requires looking
at a business process and not just a technical solution. Plus maybe because
of this your application can be subverted by attacking the HR system. And so
on.

Another reasonable question to ask is how would anyone expose these types of
errors? Then, can some or all of this method be automated? 
Again the answer seems to be yes. For a start, it's pretty obvious that if
SOAP isn't being used then no SOAP issue applies. Similarly if you're not
using passwords then no password issue applies. Conversely if you are using
passwords then you need to look at how they are managed/transmitted by each
component that deals with them, not just SOAP. If your environment doesn't
include "untrusted" networks, then another set of issues goes away. If
you're using some infrastructural elements such as standard OS builds or a
common authentication system that you've already evaluated, then you've
already covered a whole raft of standard technical issues. And so on. That's
100s of individual detailed technical issues that can be quickly and
automatically eliminated from consideration, and that's just from a quick
look at the obvious stuff.

Yet another reasonable question to ask is "compared to what?". In other
words, what do you propose instead of a generic tool? Are we going to build
a specific tool for every application? Why should that be any easier? Or are
we going look at every system manually? Also, is this approach mutually
exclusive with the use of a tool to sift through the routine glaring stuff
or can they be used together?

> I think there maybe confusion between what I think of threat modeling 
> and risk assessment. Threat modeling to me is about helping design a 
> better technological solution.
I know what you're getting at here, but risk assessment isn't just
non-technical, and threat modelling isn't just technical. You have to look
at the whole system, including the processes and the people. Think of social
engineering of a password. Think of someone misaddressing an email and
sending a spreadsheet containing a bank's entire trading position to the
competition. Think of a password that's sent encrypted but that is issued in
the first place to anyone who phones up and sounds friendly. Those are all
people problems that don't apply unless you use a particular technology to
do certain things, and both can be mitigated in technical and non-technical
ways. There are any amount of examples like this.

Cheers,
Frank

[...]

-- 
Frank O'Dwyer      <fod () littlecatZ com>
Little cat Z       http://www.littlecatZ.com/

This message is intended only for the use of the addressee and may contain
information that is privileged, confidential and exempt from disclosure
under applicable law. If the reader of this message is not the intended
recipient, or the employee or agent responsible for delivering the message
to the intended recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited. If you
have received this e-mail in error, please notify us immediately by return
e-mail and delete this e-mail and all attachments from your system.