RE: Threat Modelling [Virus checkedAU]

[Bruce.Morris () au ey com]

This email is to be read subject to the disclaimer below.

Threat and risk are commonly used as interchangeable terms, incorrectly.  I
too made the mistake initially of thinking Mark was refering to risk with
this openning question because I don't distinguish between the two in
trying to interact with those who don't understand risk assessment - I end
up confusing them when I do.  I agree you can't have one without the other.

Apples and oranges may not be the best analogy in this case.  They are
intrinsically linked more closely than that.
threat - n 1: something that is a source of danger
risk  - n. The possibility of suffering harm or loss; danger.

Whilst these may not even be the best definitions they do draw the
distinction I think which is being sought and which also drives to the
heart of Mark's concerns.

Threat needs to be considered the source of the risk - I think if we don't
understand the potential source (that is weakeness in the environment) of
the risk then we can't adequately describe the controls required to be
implemented to mitigate the risk.   However, as Frank rightly points out,
if we don't make the next jump of linking the source (threat) to the
exposure at a business level (what the real issue is) then we miss the
point - we implement controls for no reason or miss the all too important
non-technical bits.

The level of detail is the problem of all threat risk assessments.  If I
was doing a risk list with respect to a web application it would begin at
the top ten type levels - the top ten would link to higher level business
risks around the application which may concern unauthorised access,
unauthorised disclosure, etc (or possibily even a more specific business
level in between.  However, to make sense of the risk at the top ten level
I need to look at the probability of the source being realised.

This is where things start to get specific to a
solution/application/architecture/design.  Threat modelling in this context
will mean that certain technologies, architectures for web apps will have
particular (potential) weakeness with their configuration, design or
implementation, etc which can be "generically" stated as a baseline.
Incidentally, the threats are also the things that specifically get
monitored and reviewed towards assessing the ongoing risk profile of the
environment.

I would hope that this type of threat modelling would provide a picture of
the positives and negatives of various archtiectures and designs to the
start of a project.






                                                                                                                        
               
                       "Mark Curphey"                                                                                   
               
                       <mark@curphey.c         To:      "'Frank O'Dwyer'" <fod () littlecatZ com>                       
                  
                       om>                     cc:      <webappsec () securityfocus com>                                
                  
                                               Subject: RE: Threat Modelling  [Virus checkedAU]                         
               
                       23/05/2004                                                                                       
               
                       11:21 PM                                                                                         
               
                                                                                                                        
               
                                                                                                                        
               



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.







--------------------
NOTICE - This communication contains information which is confidential and
the copyright of Ernst & Young or a third party.

If you are not the intended recipient of this communication please delete
and destroy all copies and telephone Ernst & Young on 1800 655 717
immediately. If you are the intended recipient of this communication you
should not copy, disclose  or distribute this communication without the
authority of Ernst & Young.

Any views expressed in this Communication are those of the individual
sender, except where the sender specifically states them to be the views of
Ernst & Young.

Except as required at law, Ernst & Young does not represent, warrant and/or
guarantee that the integrity of this communication has been maintained nor
that the communication is free of errors, virus, interception or
interference.

Liability limited by the Accountants Scheme, approved under the
Professional Standards Act 1994 (NSW)
--------------------