Home page logo
/

webappsec logo WebApp Sec 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:

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.


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault