Re: Threat Modelling

["Frank O'Dwyer" <fod () littlecatZ com>]

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.