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 (at) littlecatZ (dot) com [email concealed]>
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.

[ reply ]

Mark Curphey wrote:<br/>
<br/>
>To quote ...."The tools used for Risk Management in certification &<br/>
>accreditation (NIACAP/DITSCAP) are very effective for threat modeling."<br/>
><br/>
>Maybe I am missing the point here so please help me out.<br/>
><br/>
>How would these generic tools help me methodically expose the fact that an<br/>
>application developer chose to send a password in clear in an unprotected<br/>
>SOAP message across an untrusted network?<br/>
><br/>
>How would these generic tools help me expose an application that used DNS to<br/>
>authenticate a components location?<br/>
><br/>
>How is a generic tool going to help me expose an application that is not<br/>
>validating input from a 3rd party web services data feed ?<br/>
> <br/>
><br/>
I know your question is directed at a different set of tools, but I'd <br/>
like to try to answer it from the perspective of ours. I'm not sure <br/>
whether your issue is with 'generic' tools or with automated tools in <br/>
general, however the examples you've picked are good ones to illustrate <br/>
the point.<br/>
<br/>
The first question to ask yourself is are the issues you have identified <br/>
above 'generic' or not - generic doesn't necessarily mean <br/>
'non-technical'. The particular examples above seem pretty generic to me <br/>
- there is a whole class of applications that use SOAP, a whole class of <br/>
applications that use passwords, DNS, third party feeds, etc. These are <br/>
all *generic* technologies with *generic* requirements therefore it's <br/>
quite reasonable to look for a *generic* solution or method that <br/>
addresses such classes of system. In other words, whether your response <br/>
to these issues is a policy statement, a process, deployment of some pen <br/>
testing tool, code review, hire a consultant, deploy infrastructure, a <br/>
combination of all of these, or whatever - that response is your answer <br/>
for any application in this class. And that remains true whether you use <br/>
a tool to automate the process or not.<br/>
<br/>
Not only that but these requirements all flow from much higher level <br/>
business imperatives, which cannot all be addressed solely by technical <br/>
means. Therefore any system that is ONLY looking at technical issues is <br/>
going to miss the mark. The requirement not to send a password in clear <br/>
is a good case in point. This may flow from a requirement that only <br/>
employees can access the business's systems, for example. To achieve <br/>
that requires that you don't issue a password to a non-employee in the <br/>
first place - this is something that involves people issues, and almost <br/>
certainly requires looking at a business process and not just a <br/>
technical solution. Plus maybe because of this your application can be <br/>
subverted by attacking the HR system. And so on.<br/>
<br/>
Another reasonable question to ask is how would anyone expose these <br/>
types of errors? Then, can some or all of this method be automated? <br/>
Again the answer seems to be yes. For a start, it's pretty obvious that <br/>
if SOAP isn't being used then no SOAP issue applies. Similarly if you're <br/>
not using passwords then no password issue applies. Conversely if you <br/>
are using passwords then you need to look at how they are <br/>
managed/transmitted by each component that deals with them, not just <br/>
SOAP. If your environment doesn't include "untrusted" networks, then <br/>
another set of issues goes away. If you're using some infrastructural <br/>
elements such as standard OS builds or a common authentication system <br/>
that you've already evaluated, then you've already covered a whole raft <br/>
of standard technical issues. And so on. That's 100s of individual <br/>
detailed technical issues that can be quickly and automatically <br/>
eliminated from consideration, and that's just from a quick look at the <br/>
obvious stuff.<br/>
<br/>
Yet another reasonable question to ask is "compared to what?". In other <br/>
words, what do you propose instead of a generic tool? Are we going to <br/>
build a specific tool for every application? Why should that be any <br/>
easier? Or are we going look at every system manually? Also, is this <br/>
approach mutually exclusive with the use of a tool to sift through the <br/>
routine glaring stuff or can they be used together?<br/>
<br/>
>I think there maybe confusion between what I think of threat modeling and<br/>
>risk assessment. Threat modeling to me is about helping design a better<br/>
>technological solution.<br/>
><br/>
I know what you're getting at here, but risk assessment isn't just <br/>
non-technical, and threat modelling isn't just technical. You have to <br/>
look at the whole system, including the processes and the people. Think <br/>
of social engineering of a password. Think of someone misaddressing an <br/>
email and sending a spreadsheet containing a bank's entire trading <br/>
position to the competition. Think of a password that's sent encrypted <br/>
but that is issued in the first place to anyone who phones up and sounds <br/>
friendly. Those are all people problems that don't apply unless you use <br/>
a particular technology to do certain things, and both can be mitigated <br/>
in technical and non-technical ways. There are any amount of examples <br/>
like this.<br/>
<br/>
Cheers,<br/>
Frank<br/>
<br/>
[...]<br/>
<br/>
-- <br/>
Frank O'Dwyer <fod (at) littlecatZ (dot) com [email concealed]><br/>
Little cat Z http://www.littlecatZ.com/<br/>
<br/>
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.

[ reply ]

Mark Curphey wrote:<br/><br/>
<br/><br/>
>To quote ...."The tools used for Risk Management in certification &<br/><br/>
>accreditation (NIACAP/DITSCAP) are very effective for threat modeling."<br/><br/>
><br/><br/>
>Maybe I am missing the point here so please help me out.<br/><br/>
><br/><br/>
>How would these generic tools help me methodically expose the fact that an<br/><br/>
>application developer chose to send a password in clear in an unprotected<br/><br/>
>SOAP message across an untrusted network?<br/><br/>
><br/><br/>
>How would these generic tools help me expose an application that used DNS to<br/><br/>
>authenticate a components location?<br/><br/>
><br/><br/>
>How is a generic tool going to help me expose an application that is not<br/><br/>
>validating input from a 3rd party web services data feed ?<br/><br/>
> <br/><br/>
><br/><br/>
I know your question is directed at a different set of tools, but I'd <br/><br/>
like to try to answer it from the perspective of ours. I'm not sure <br/><br/>
whether your issue is with 'generic' tools or with automated tools in <br/><br/>
general, however the examples you've picked are good ones to illustrate <br/><br/>
the point.<br/><br/>
<br/><br/>
The first question to ask yourself is are the issues you have identified <br/><br/>
above 'generic' or not - generic doesn't necessarily mean <br/><br/>
'non-technical'. The particular examples above seem pretty generic to me <br/><br/>
- there is a whole class of applications that use SOAP, a whole class of <br/><br/>
applications that use passwords, DNS, third party feeds, etc. These are <br/><br/>
all *generic* technologies with *generic* requirements therefore it's <br/><br/>
quite reasonable to look for a *generic* solution or method that <br/><br/>
addresses such classes of system. In other words, whether your response <br/><br/>
to these issues is a policy statement, a process, deployment of some pen <br/><br/>
testing tool, code review, hire a consultant, deploy infrastructure, a <br/><br/>
combination of all of these, or whatever - that response is your answer <br/><br/>
for any application in this class. And that remains true whether you use <br/><br/>
a tool to automate the process or not.<br/><br/>
<br/><br/>
Not only that but these requirements all flow from much higher level <br/><br/>
business imperatives, which cannot all be addressed solely by technical <br/><br/>
means. Therefore any system that is ONLY looking at technical issues is <br/><br/>
going to miss the mark. The requirement not to send a password in clear <br/><br/>
is a good case in point. This may flow from a requirement that only <br/><br/>
employees can access the business's systems, for example. To achieve <br/><br/>
that requires that you don't issue a password to a non-employee in the <br/><br/>
first place - this is something that involves people issues, and almost <br/><br/>
certainly requires looking at a business process and not just a <br/><br/>
technical solution. Plus maybe because of this your application can be <br/><br/>
subverted by attacking the HR system. And so on.<br/><br/>
<br/><br/>
Another reasonable question to ask is how would anyone expose these <br/><br/>
types of errors? Then, can some or all of this method be automated? <br/><br/>
Again the answer seems to be yes. For a start, it's pretty obvious that <br/><br/>
if SOAP isn't being used then no SOAP issue applies. Similarly if you're <br/><br/>
not using passwords then no password issue applies. Conversely if you <br/><br/>
are using passwords then you need to look at how they are <br/><br/>
managed/transmitted by each component that deals with them, not just <br/><br/>
SOAP. If your environment doesn't include "untrusted" networks, then <br/><br/>
another set of issues goes away. If you're using some infrastructural <br/><br/>
elements such as standard OS builds or a common authentication system <br/><br/>
that you've already evaluated, then you've already covered a whole raft <br/><br/>
of standard technical issues. And so on. That's 100s of individual <br/><br/>
detailed technical issues that can be quickly and automatically <br/><br/>
eliminated from consideration, and that's just from a quick look at the <br/><br/>
obvious stuff.<br/><br/>
<br/><br/>
Yet another reasonable question to ask is "compared to what?". In other <br/><br/>
words, what do you propose instead of a generic tool? Are we going to <br/><br/>
build a specific tool for every application? Why should that be any <br/><br/>
easier? Or are we going look at every system manually? Also, is this <br/><br/>
approach mutually exclusive with the use of a tool to sift through the <br/><br/>
routine glaring stuff or can they be used together?<br/><br/>
<br/><br/>
>I think there maybe confusion between what I think of threat modeling and<br/><br/>
>risk assessment. Threat modeling to me is about helping design a better<br/><br/>
>technological solution.<br/><br/>
><br/><br/>
I know what you're getting at here, but risk assessment isn't just <br/><br/>
non-technical, and threat modelling isn't just technical. You have to <br/><br/>
look at the whole system, including the processes and the people. Think <br/><br/>
of social engineering of a password. Think of someone misaddressing an <br/><br/>
email and sending a spreadsheet containing a bank's entire trading <br/><br/>
position to the competition. Think of a password that's sent encrypted <br/><br/>
but that is issued in the first place to anyone who phones up and sounds <br/><br/>
friendly. Those are all people problems that don't apply unless you use <br/><br/>
a particular technology to do certain things, and both can be mitigated <br/><br/>
in technical and non-technical ways. There are any amount of examples <br/><br/>
like this.<br/><br/>
<br/><br/>
Cheers,<br/><br/>
Frank<br/><br/>
<br/><br/>
[...]<br/><br/>
<br/><br/>
-- <br/><br/>
Frank O'Dwyer <fod (at) littlecatZ (dot) com [email concealed]><br/><br/>
Little cat Z http://www.littlecatZ.com/<br/><br/>
<br/><br/>
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.

[ reply ]

Mark Curphey wrote:<br/><br/><br/>
<br/><br/><br/>
>To quote ...."The tools used for Risk Management in certification &<br/><br/><br/>
>accreditation (NIACAP/DITSCAP) are very effective for threat modeling."<br/><br/><br/>
><br/><br/><br/>
>Maybe I am missing the point here so please help me out.<br/><br/><br/>
><br/><br/><br/>
>How would these generic tools help me methodically expose the fact that an<br/><br/><br/>
>application developer chose to send a password in clear in an unprotected<br/><br/><br/>
>SOAP message across an untrusted network?<br/><br/><br/>
><br/><br/><br/>
>How would these generic tools help me expose an application that used DNS to<br/><br/><br/>
>authenticate a components location?<br/><br/><br/>
><br/><br/><br/>
>How is a generic tool going to help me expose an application that is not<br/><br/><br/>
>validating input from a 3rd party web services data feed ?<br/><br/><br/>
> <br/><br/><br/>
><br/><br/><br/>
I know your question is directed at a different set of tools, but I'd <br/><br/><br/>
like to try to answer it from the perspective of ours. I'm not sure <br/><br/><br/>
whether your issue is with 'generic' tools or with automated tools in <br/><br/><br/>
general, however the examples you've picked are good ones to illustrate <br/><br/><br/>
the point.<br/><br/><br/>
<br/><br/><br/>
The first question to ask yourself is are the issues you have identified <br/><br/><br/>
above 'generic' or not - generic doesn't necessarily mean <br/><br/><br/>
'non-technical'. The particular examples above seem pretty generic to me <br/><br/><br/>
- there is a whole class of applications that use SOAP, a whole class of <br/><br/><br/>
applications that use passwords, DNS, third party feeds, etc. These are <br/><br/><br/>
all *generic* technologies with *generic* requirements therefore it's <br/><br/><br/>
quite reasonable to look for a *generic* solution or method that <br/><br/><br/>
addresses such classes of system. In other words, whether your response <br/><br/><br/>
to these issues is a policy statement, a process, deployment of some pen <br/><br/><br/>
testing tool, code review, hire a consultant, deploy infrastructure, a <br/><br/><br/>
combination of all of these, or whatever - that response is your answer <br/><br/><br/>
for any application in this class. And that remains true whether you use <br/><br/><br/>
a tool to automate the process or not.<br/><br/><br/>
<br/><br/><br/>
Not only that but these requirements all flow from much higher level <br/><br/><br/>
business imperatives, which cannot all be addressed solely by technical <br/><br/><br/>
means. Therefore any system that is ONLY looking at technical issues is <br/><br/><br/>
going to miss the mark. The requirement not to send a password in clear <br/><br/><br/>
is a good case in point. This may flow from a requirement that only <br/><br/><br/>
employees can access the business's systems, for example. To achieve <br/><br/><br/>
that requires that you don't issue a password to a non-employee in the <br/><br/><br/>
first place - this is something that involves people issues, and almost <br/><br/><br/>
certainly requires looking at a business process and not just a <br/><br/><br/>
technical solution. Plus maybe because of this your application can be <br/><br/><br/>
subverted by attacking the HR system. And so on.<br/><br/><br/>
<br/><br/><br/>
Another reasonable question to ask is how would anyone expose these <br/><br/><br/>
types of errors? Then, can some or all of this method be automated? <br/><br/><br/>
Again the answer seems to be yes. For a start, it's pretty obvious that <br/><br/><br/>
if SOAP isn't being used then no SOAP issue applies. Similarly if you're <br/><br/><br/>
not using passwords then no password issue applies. Conversely if you <br/><br/><br/>
are using passwords then you need to look at how they are <br/><br/><br/>
managed/transmitted by each component that deals with them, not just <br/><br/><br/>
SOAP. If your environment doesn't include "untrusted" networks, then <br/><br/><br/>
another set of issues goes away. If you're using some infrastructural <br/><br/><br/>
elements such as standard OS builds or a common authentication system <br/><br/><br/>
that you've already evaluated, then you've already covered a whole raft <br/><br/><br/>
of standard technical issues. And so on. That's 100s of individual <br/><br/><br/>
detailed technical issues that can be quickly and automatically <br/><br/><br/>
eliminated from consideration, and that's just from a quick look at the <br/><br/><br/>
obvious stuff.<br/><br/><br/>
<br/><br/><br/>
Yet another reasonable question to ask is "compared to what?". In other <br/><br/><br/>
words, what do you propose instead of a generic tool? Are we going to <br/><br/><br/>
build a specific tool for every application? Why should that be any <br/><br/><br/>
easier? Or are we going look at every system manually? Also, is this <br/><br/><br/>
approach mutually exclusive with the use of a tool to sift through the <br/><br/><br/>
routine glaring stuff or can they be used together?<br/><br/><br/>
<br/><br/><br/>
>I think there maybe confusion between what I think of threat modeling and<br/><br/><br/>
>risk assessment. Threat modeling to me is about helping design a better<br/><br/><br/>
>technological solution.<br/><br/><br/>
><br/><br/><br/>
I know what you're getting at here, but risk assessment isn't just <br/><br/><br/>
non-technical, and threat modelling isn't just technical. You have to <br/><br/><br/>
look at the whole system, including the processes and the people. Think <br/><br/><br/>
of social engineering of a password. Think of someone misaddressing an <br/><br/><br/>
email and sending a spreadsheet containing a bank's entire trading <br/><br/><br/>
position to the competition. Think of a password that's sent encrypted <br/><br/><br/>
but that is issued in the first place to anyone who phones up and sounds <br/><br/><br/>
friendly. Those are all people problems that don't apply unless you use <br/><br/><br/>
a particular technology to do certain things, and both can be mitigated <br/><br/><br/>
in technical and non-technical ways. There are any amount of examples <br/><br/><br/>
like this.<br/><br/><br/>
<br/><br/><br/>
Cheers,<br/><br/><br/>
Frank<br/><br/><br/>
<br/><br/><br/>
[...]<br/><br/><br/>
<br/><br/><br/>
-- <br/><br/><br/>
Frank O'Dwyer <fod (at) littlecatZ (dot) com [email concealed]><br/><br/><br/>
Little cat Z http://www.littlecatZ.com/<br/><br/><br/>
<br/><br/><br/>
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.

[ reply ]