Re: [SC-L] Re: Application Insecurity --- Who is at Fault?

2005-04-11 Thread Michael Silk
Joel On Apr 12, 2005 12:45 AM, Joel Kamentz <[EMAIL PROTECTED]> wrote: > Re: bridges and stuff. > > Let's use an example someone else already brought up -- cross site scripting. > How many people > feel that, before it was ever known or had ever occurred the first time, good > programming > pra

Re: [SC-L] Re: Application Insecurity --- Who is at Fault?

2005-04-11 Thread Dave Paris
Joel Kamentz wrote: Re: bridges and stuff. I'm tempted to argue (though not with certainty) that it seems that the bridge analogy is flawed in another way -- that of the environment. While many programming languages have similarities and many things apply to all programming, there are many thing

Re: [SC-L] Re: Application Insecurity --- Who is at Fault?

2005-04-11 Thread Dave Aronson
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <[EMAIL PROTECTED]> Sender: [EMAIL PROTECTED] Precedence: bulk Mailing-List: contact <[

Re: [SC-L] Re: Application Insecurity --- Who is at Fault?

2005-04-11 Thread Carl G. Alphonce
on Monday April 11, 2005, Damir Rajnovic wrote: > On Mon, Apr 11, 2005 at 12:21:30PM +1000, Michael Silk wrote: > > Back to the bridge or house example, would you allow the builder to > > leave off 'security' of the structure? Allow them to introduce some > > design flaws to get it done earlie

Re: [SC-L] Theoretical question about vulnerabilities

2005-04-11 Thread Nash
Pascal Meunier wrote: > Do you think it is possible to enumerate all the ways > all vulnerabilities can be created? Is the set of all > possible exploitable programming mistakes bounded? By "bounded" I take you to mean "finite." In particular with reference to your taxonomy below. By "enumerate" I

RE: [SC-L] Re: Application Insecurity --- Who is at Fault?

2005-04-11 Thread ljknews
At 10:45 AM -0400 4/11/05, Joel Kamentz wrote: >I don't have experience with the formal methods, but I can see that, supposing >this were NASA, >etc., formal approaches >might lead to perfect protection. Not perfect, but better than average: http://www.fastcompany.com/online/06/writestuff.html

Re: [SC-L] Re: Application Insecurity --- Who is at Fault?

2005-04-11 Thread Michael Silk
Dave, On Apr 11, 2005 9:58 PM, Dave Paris <[EMAIL PROTECTED]> wrote: > The programmer is neither the application architect nor the system > engineer. In some cases he is. Either way, it doesn't matter. I'm not asking the programmer to re-design the application, I'm asking them to just program the

RE: [SC-L] Theoretical question about vulnerabilities

2005-04-11 Thread David Crocker
Pascal Meunier wrote: >> Do you think it is possible to enumerate all the ways all vulnerabilities can be created? Is the set of all possible exploitable programming mistakes bounded? << No. It's not so much a programming problem, more a specification problem. Tools now exist that make it possi

RE: [SC-L] Re: Application Insecurity --- Who is at Fault?

2005-04-11 Thread Joel Kamentz
Re: bridges and stuff. I'm tempted to argue (though not with certainty) that it seems that the bridge analogy is flawed in another way -- that of the environment. While many programming languages have similarities and many things apply to all programming, there are many things which do not tran

Re: [SC-L] Re: Application Insecurity --- Who is at Fault?

2005-04-11 Thread Damir Rajnovic
On Mon, Apr 11, 2005 at 12:21:30PM +1000, Michael Silk wrote: > Back to the bridge or house example, would you allow the builder to > leave off 'security' of the structure? Allow them to introduce some > design flaws to get it done earlier? Hopefully not ... so why is it > allowed for programming?

RE: [SC-L] Re: Application Insecurity --- Who is at Fault?

2005-04-11 Thread Chris Matthews
Dave Paris wrote: >It's also much more likely that the "foreman" (aka >programming manager) told the builder (programmer) to take shortcuts to >meet time and budget - rather than the programmer taking it upon >themselves to be sloppy and not follow the specifications. I'd note that there is the

Re: [SC-L] Re: Application Insecurity --- Who is at Fault?

2005-04-11 Thread Dave Paris
Michael Silk wrote: Ed, [...] Back to the bridge or house example, would you allow the builder to leave off 'security' of the structure? Allow them to introduce some design flaws to get it done earlier? Hopefully not ... so why is it allowed for programming? Why can people cut out 'security' ? It'

Re: [SC-L] Re: Application Insecurity --- Who is at Fault?

2005-04-11 Thread Kenneth R. van Wyk
Crispin Cowan wrote: Only after such standards are established and *proven effective* is there any utility in enforcing the standards upon the practitioners. Software is *not* yet at that stage. As much as I like the bridge metaphor -- which is why I used it on the cover of my Secure Coding book

RE: [SC-L] Re: Application Insecurity --- Who is at Fault?

2005-04-11 Thread Yousef Syed
Further to the Bridge Example (and any other construction); there is a great deal of external oversight involved here. The plans will be submitted to the planning departments, and building control of the local council (at least in the UK). They will be scrutinized by these external systems long be

Re: [SC-L] Re: Application Insecurity --- Who is at Fault?

2005-04-11 Thread Michael Silk
Ed, But even your signature suggests we already have an environment like that. Clearly you have become certfied, and most job ads I view require some form of certification. Certification isn't missing from the Programming profession - there is heaps of it. So what _is_ missing? We can assume

Re: [SC-L] Re: Application Insecurity --- Who is at Fault?

2005-04-11 Thread Crispin Cowan
I strongly disagree with this. Rigorous professional standards for mechanical and structural engineering came about only *after* a well-defined "cookbook" of how to properly engineer things was agreed upon. Only after such standards are established and *proven effective* is there any utility in