RE: Secure software development documents

["Dinis Cruz" <dinis () ddplus co uk>]

I still think (as I defended on my OWASP AppSec NYC 2004 conference presentation) that trying to write secure code is a 
journey, not a destination.

What is measurable and can be quantified is ‘Secure Application Hosting Environments’ i.e. ‘Application SandBoxes’.

Most vulnerabilities and exploits that exist today (SQL Injection, Buffer OverRuns, etc…) are only dangerous (i.e. have 
a relatively high Risk) because there is almost no layers of protection between the code that is exposed to malicious 
users and code that is able to do highly privileged actions.

If we had Applications that where designed with multiple layers of security, privileges and resources, then these 
vulnerabilities could not be exploited in the way they are today.

The best thing of this approach (focusing resources in creating ‘Secure Application Hosting Environments’ instead of 
focusing resources in trying to make ‘developers write secure code’ or spending resources in ‘tools that will identify 
all vulnerabilities within an application’) is that is a much more realistic, practical and effective method, AND it 
can be quantified and measured (whilst it is almost impossible to quantify the security of a piece of code!).

Of course that this is not easy and will make most current security software redundant, which is one of the reasons why 
(in my view) this idea is not wide spread in the industry.

Best regards

Dinis Cruz
.Net Security Consultant
DDPlus


---------- Original Message ----------------------------------
From: "Mark Curphey" <mark () curphey com>
Date:  Mon, 26 Jul 2004 20:17:40 -0400

> With regards to testing specifically this is a draft of OWASP Testing Part
> 1. It is essentially a high level view of what to think about when building
> a testing function.
>
> It is draft but as we have been threatening to release it for ions I thought
> I would at least put this version on Sourceforge to download and get a
> flavor of what we (OWASP) are saying. It is not finished (we have a face to
> face this Weds to finally conclude this part and the re-write) so please
> just read the Chapters 7 and 8 in this context. Chapters 4, 5 and 6 are
> getting a re-write (significant prune) this week but this may help.
>
> It won't please everyone, especially the silver bullet brigade, but it is a
> good attempt and consensus that most people who have been responsible for
> building and running security testing of web app software in large dev shops
> have agreed on. You have to think strategically and testing after
> development is too little too late (despite some marketing claims to the
> contrary).
>
> http://prdownloads.sourceforge.net/owasp/TheOWASPTestingProjectPart1Draft.pd
> f?download
>
> This is an interesting point in the software security industry I think. I
> have seen two distinct camps forming, those trying to solve the problem by
> promoting building better software and tackle the root causes (people,
> process and technology) and those selling shinier and shinier silver bullets
> (software or services) ;-(
>
> Basically we are saying you need to test your SDLC process itself and then
> discrete parts of it such as requirements, design, implementation and
> deployment. Today people seem to have a fixation on testing deployment only
> which is too little too late and too in-efficient.
>
> Note: As I was typing this I saw a mail from Skip Carter that re-enforces
> this.
>
> -----Original Message-----
> From: Scovetta, Michael V [mailto:Michael.Scovetta () ca com]
> Sent: Monday, July 26, 2004 10:23 AM
> To: udayan pathak; webappsec () securityfocus com; secprog () securityfocus com
> Subject: RE: Secure software development documents
>
> Udayan,
>
> I would recommend first looking at OWASP (http://www.owasp.org/). Their
> guide is relatively complete and of good quality. If you have $$$ to spend,
> I would recommend the 2-day Blackhat course "Network Application Design &
> Secure Implementation"
> (http://www.blackhat.com/html/bh-usa-04/train-bh-usa-04-dm.html)
> I found the course to be incredibly helpful, and it comes with a custom
> manual that is very detailed. Together, these two would probably get you 85%
> of the way there. The rest is (a) experience, (b) staying current (bugtraq,
> webappsec, etc), and (c) just being an intelligent individual.
>
> Mike Scovetta
>
>
> -----Original Message-----
> From: udayan pathak [mailto:udayan_pathak () yahoo com]
> Sent: Monday, July 26, 2004 7:19 AM
> To: webappsec () securityfocus com; secprog () securityfocus com
> Subject: Secure software development documents
>
> Hi everyone
>
> I have a query!
>
>
> What are the documentation standards being followed as far as secure
> software development is concerned? I find that in the current software
> development process the document generated do not/ barely cover the security
> of the application being developed.
>
> All the normal documents for requirement specification, requirement
> tracking, high level and low level design documents etc have nothing more
> than a small section in their template format for security, which looks more
> like a formality and hardly serves the purpose.
>
> Especially as far a software testing is concerned one gets the feeling that
> the provision for security testing in test cases gets diluted in the sea of
> functionality testing.
>
> Has anyone got any insights into this? or any other standard being followed
> ?
>
> Please let me know
>
>
>
> Udayan Pathak
>
>
>
>
> __________________________________
> Do you Yahoo!?
> New and Improved Yahoo! Mail - 100MB free storage!
> http://promotions.yahoo.com/new_mail