mailing list archives
Re: Threat Modelling
From: "Frank O'Dwyer" <fod () littlecatZ com>
Date: Sun, 23 May 2004 10:08:11 +0100
Mark Curphey wrote:
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
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 ?
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
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 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
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
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.