WebApp Sec mailing list archives
RE: Threat Modelling [Virus checkedAU]
From: Bruce.Morris () au ey com
Date: Mon, 24 May 2004 10:42:52 +1000
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) --------------------
Current thread:
- RE: Threat Modelling [Virus checkedAU] Bruce . Morris (May 23)