Re: Let's get the ball rolling

["Joe Teff" <joe () joeteff com>]

> From my experience, training should be the top priority. Pen testing and 
code review are good measures, but will always find the problems too late 
in the process. Documentation fails if the people invloved cannot 
appreciate the "why". The vast majority of developers, architects, 
business analysts and software testers can understand the "why" once it 
it explained. Security is a process, not a checklist. We have to make 
tradeoffs every day. I find the vast majority of developers don't really 
understand how HTTP, web servers, app servers or databases really work. 
For the most part, the mistakes being made are not because of bad 
motives. Rather it is because they do not understand what is possible. 
Developers tend to get specs and write the code based on the specs. In 
other words, they color inside the lines. They also need to understand 
how thier applications/servers will respond when someone tries (either by 
accident or on purpose) to use thier application in ways that was not 
intended.

Joe Teff

-----Original Message-----
From: "Jeff Williams @ Aspect" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Date: Sat, 6 Dec 2003 23:55:47 -0500
Subject: Re: [SC-L] Let's get the ball rolling

> Despite the traffic of the last few days, I'm hoping that the list
> focuses
> on that "other stuff" as well. Most software development organizations
> have
> not integrated security into their SDLC effectively. I'd be interested
> in
> hearing how other organizations have dealt with this.  The SSE-CMM (I
> chaired the group that authored it) focuses on systems engineering, not
> software specifically. Software development organizations need specific
> practices for sofware engineering.
>
> I'm particularly interested in the most effective of these practices
> for
> large-scale software organizations, in the "bang for the buck" sense.
> Imagine you're a software development manager with a limited budget,
> and you
> just realized that you need to start producing more secure software. 
> Do you
> invest in training developers, better software security requirements,
> configuration management, better documentation, designing and
> implementing
> better security mechanisms, code review and penetration testing, or
> what?
>
> Obviously, one major factor is where you are right now in the
> development
> process, since you can't go back and train all the developers after the
> system is already developed. But what is the calculus for what to do
> when?
> And what measurements can you take to be sure that what you do makes
> good
> risk management sense?
>
> --Jeff
>
> Jeff Williams
> Aspect Security
> http://www.aspectsecurity.com