mailing list archives
RE: Threat Modelling
From: "Brewis, Mark" <mark.brewis () eds com>
Date: Tue, 25 May 2004 10:22:45 +0100
From: Frank O'Dwyer [mailto:fod () littlecatZ com]
Sent: 25 May 2004 07:06
To: webappsec () securityfocus com
Agreed; the discussion has moved from the modelling
necessary for the secure coding of an app. or the pentesting
of that app. into assessing the wider holistic security environment.
No it hasn't. Taking wider non-technical issues and business
requirements into account is part of the "modelling
necessary" in order
to deliver "secure code", that's the point. This in turn is
part of what
you need to do to deliver secure technical systems that participate in
some business process - which is the real objective.
I'm not disagreeing with any of the things you are saying - they are all good security management practice, and
hopefully everyone here espouses them. I know that if you concentrate on the micro and ignore the macro you can end up
with a perfectly engineered jewel in the midst of chaos. However, the discussion was originally about modelling apps
at a technical level; fine screwdriver against big screwdriver.
That's great, if that is what I want to do. If a wanted to
define a test strategy, or identify generic class
vulnerabilities in an app. under development, that doesn't
meet my needs.
Sure it does. Or at least you've failed to provide any reason why it
wouldn't. Nothing about taking wider issues into account AS
that you wind up without a test strategy, or miss generic class
Agreed in principle, but I don't believe that the current tools provide us with that assurance (although I haven't had
a chance to look at your own yet). That is where the shortfall is at the moment. From a pentesting standpoint,
because that is my focus, I either get completely blind tests, or I get process documents, flow, case and sequence
diagrams and have to model attack trees etc. None of the RA tools I have access to help much, if at all, in doing this.
That's over and above the fact that any security model that
gives a lot
of weight to the needs of pentesting is pretty much doomed to being
wrong from the outset, because most security attributes are quality
attributes for which testing is a really poor fit.
I've a slightly different take on that, although I'm not disagreeing with you. Any auditor will tell you that you
audit against the quality system, however poor the system is. You can then make recommendations to improve the quality
system, but they still pass the audit. A pentest is an audit against a completely external set of criteria, a
different quality system, if you will.
To rely wholly on pentesting as your security model is fallacy - you still have to build strong.
I wanted a screwdriver, and you've passed me a monkey wrench.
Well no I haven't - you wanted a screwdriver and I've given you a
screwdriver. I've also given you a rawlplug and a drill, and
that unless you use all three together in the right order and in the
right way, the shelf you've been trying to put up will keep
I'm looking for a fine screwdriver and I've been given a large one - it will do the job, but it is likely to be a bit
RE: Threat Modelling Brewis, Mark (May 24)
RE: Threat Modelling Runion Mark A FGA DOIM WEBMASTER(ctr) (May 24)
RE: Threat Modelling Brewis, Mark (May 25)