[OWASP-TESTING] testing project part 1 - threat modeling

[Andrew van der Stock]

Mads,

The reason I mentioned UML is simple - most developers are now familiar with
it, and it is often all they can give me (if they have any doco at all). 

I take your point, though. Maybe there is no one "good" method except to say
that decomposing an application is essential. 

Abuse cases are interesting. They are like negative test artifacts. It
deserves an inclusion. 

Would you like to re-write the chapter? I think that is probably the best
way to get a workable consensus. 

Andrew

-----Original Message-----
From: owasp-testing-admin at lists.sourceforge.net
[mailto:owasp-testing-admin at lists.sourceforge.net] On Behalf Of Mads
Rasmussen
Sent: Tuesday, 6 July 2004 2:55 AM
To: Owasp-Testing
Subject: [OWASP-TESTING] testing project part 1 - threat modeling

Howard and Le Blanc's book on secure coding writes explicitly why UML 
isn't a good choice for deposing the application being analyzed.

Is there any reason as to why UML was "chosen"? Wouldn't it be better to 
talk about Data Flow Datagrams that seems to be the standard modeling 
tool when modeling flow of data.

I don't for example agree with Use Case models being the best way to 
decompose an application being analyzed. It is handy to model what you 
want the application to do in the analysis phase but more information is 
needed when doing threat analysis (that's my opinion at least)

When modeling something within a time frame you have the sequence 
diagram from UML fitting perfectly.

As a commercial for DFD, it says at msdn, "Data flow diagrams (DFDs) and 
sequence diagrams can help with the formal decomposition of a system. A 
DFD is a graphical representation of data flows, data stores, and 
relationships between data sources and destinations. A sequence diagram 
shows how a group of objects collaborate in terms of chronological events.

(http://msdn.microsoft.com/security/securecode/threatmodeling/default.aspx?p
ull=/library/en-us/dnnetsec/html/thcmch03.asp)

There is another approach called Misuse/Abuse Cases, using the use cases 
made in the analysis phase to try abusing the system on a design level. 
This is great but I still think you need more information to do a fully 
threat analysis than is available on the design level.

There is some literature available on this, like:

http://www.computer.org/security/v2n3/bsi.htm
http://www.martinfowler.com/distributedComputing/abuse.pdf
http://www.cs.york.ac.uk/ftpdir/reports/YCS-2004-375.pdf (paper)

Please send comments!

-- 
Mads Rasmussen, M.Sc.
Open Communications Security
www.opencs.com.br
+55 11 3345 2525



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
owasp-testing mailing list
owasp-testing at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owasp-testing