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

2005-04-19 Thread George Capehart
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Crispin Cowan wrote: > >> This is particularly interesting to me because I just had a doctoral >> student come to me with an idea for dissertation research that >> included an hypothesis that organizations at SEI 1 were better able to >> estimate so

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

2005-04-10 Thread Yousef Syed
corporations are made to feel the burden of their slack security, then they'll take it seriously... maybe... Ys -- Yousef Syed -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Silk Sent: 06 April 2005 23:45 To: Dave Paris Cc: Secure Coding Mailin

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

2005-04-08 Thread Crispin Cowan
Julie JCH Ryan, D.Sc. wrote: Other students chimed in on the argument positing that the programming challenge was an inaccurate measure of student programming capability because the contestant was not allowed to do research on the internet during the challenge. Another said the problem was that

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

2005-04-08 Thread Julie JCH Ryan, D.Sc.
This is a little off topic, but I'm wondering if anyone would like to comment. One of our students posited that US computer science students have lost their edge because they haven't done well in the ACM programming challenge recently. He wrote, among other things, that: "Interesting factoids

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

2005-04-07 Thread ljknews
At 7:44 AM -0400 4/7/05, Dave Paris wrote: > What you're proposing is that the ironworker should reengineer the > bridge in-situ (as if he even has the authority!) or the expertise. -- Larry Kilgallen

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

2005-04-07 Thread secureCoding2dave
Blue Boar <[EMAIL PROTECTED]> wrote: > [Security] is extra. It's extra time and effort. And extra > testing. And extra backtracking and schedule slipping when > you realize you blew something. All before it hits beta. ...if you're lucky. (Or if you're doing development right, but IME that

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

2005-04-07 Thread Michael Silk
Dave, > What you're proposing is that the ironworker should reengineer the > bridge in-situ (as if he even has the authority!), causing weeks of > delay, cost overruns, and possibly lead to his employer never getting a > bridge contract again. That's not at all what I'm suggesting... guess my poi

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

2005-04-07 Thread Dave Paris
Michael Silk wrote: [...] Consider the bridge example brought up earlier. If your bridge builder finished the job but said: "ohh, the bridge isn't secure though. If someone tries to push it at a certain angle, it will fall". You would be panic stricken. Fear would overcome you, and you might either

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

2005-04-07 Thread Margus Freudenthal
Michael Silk wrote: Consider the bridge example brought up earlier. If your bridge builder finished the job but said: "ohh, the bridge isn't secure though. If someone tries to push it at a certain angle, it will fall". All bridges have certain limits. There is difference between a footbridge and b

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

2005-04-07 Thread Blue Boar
Michael Silk wrote: > See, you are considering 'security' as something extra again. This is > not right. It is extra. It's extra time and effort. And extra testing. And extra backtracking and schedule slipping when you realize you blew something. All before it hits beta. Any solution that end

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

2005-04-07 Thread Michael Silk
On Apr 7, 2005 12:43 PM, Blue Boar <[EMAIL PROTECTED]> wrote: > Michael Silk wrote: > > See, you are considering 'security' as something extra again. This is > > not right. > > It is extra. It's extra time and effort. And extra testing. And extra > backtracking and schedule slipping when you re

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

2005-04-06 Thread Michael Silk
Inline On Apr 7, 2005 1:06 AM, Dave Paris <[EMAIL PROTECTED]> wrote: > And I couldn't disagree more with your perspective, except for your > inclusion of managers in parenthesis. > > Developers take direction and instruction from management, they are not > autonomous entities. If management does

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

2005-04-06 Thread Michael Silk
inal Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Michael Silk > > Sent: Wednesday, April 06, 2005 9:40 AM > > To: Kenneth R. van Wyk > > Cc: Secure Coding Mailing List > > Subject: Re: [SC-L] Application Insecurity --- Who is at Fault?

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

2005-04-06 Thread Michael Silk
/documentation/legal.html). Yes, I've read the before, and even discussed it with you! :) -- Michael > > --Jeff > > > > >> - Original Message - > >> From: "Michael Silk" <[EMAIL PROTECTED]> > >> To: "Kenneth

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

2005-04-06 Thread Michael Silk
is time :) -- Michael > - Original Message - > From: "Michael Silk" <[EMAIL PROTECTED]> > To: "Kenneth R. van Wyk" <[EMAIL PROTECTED]> > Cc: "Secure Coding Mailing List" > Sent: Wednesday, April 06, 2005 9:40 AM > Subject: Re: [SC

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

2005-04-06 Thread Greenarrow 1
Government is not the answer. Just how would one get the numerous governments to agree on a law that most likely be impossible to enforce? Soft ware made in the European Union is not enforceable in the United States and visa versa, ie. Mapping out a plan to the various companies' management wo

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

2005-04-06 Thread Jeff Williams
t;[EMAIL PROTECTED]> To: "Kenneth R. van Wyk" <[EMAIL PROTECTED]> Cc: "Secure Coding Mailing List" Sent: Wednesday, April 06, 2005 9:40 AM Subject: Re: [SC-L] Application Insecurity --- Who is at Fault? > Quoting from the article: > ''You can't

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

2005-04-06 Thread Jeff Williams
ht?! :-\ KRvW] - Original Message - From: "Michael Silk" <[EMAIL PROTECTED]> To: "Kenneth R. van Wyk" <[EMAIL PROTECTED]> Cc: "Secure Coding Mailing List" Sent: Wednesday, April 06, 2005 9:40 AM Subject: Re: [SC-L] Application Insecurity --- Who is

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

2005-04-06 Thread Michael S Hines
ginal Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Silk Sent: Wednesday, April 06, 2005 8:40 AM To: Kenneth R. van Wyk Cc: Secure Coding Mailing List Subject: Re: [SC-L] Application Insecurity --- Who is at Fault? Quoting from the article: ''You can

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

2005-04-06 Thread Dave Paris
And I couldn't disagree more with your perspective, except for your inclusion of managers in parenthesis. Developers take direction and instruction from management, they are not autonomous entities. If management doesn't make security a priority, then only so much secure/defensive code can be

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

2005-04-06 Thread Goertzel Karen
ith security in mind. -- Karen Goertzel, CISSP Booz Allen Hamilton 703-902-6981 [EMAIL PROTECTED] > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Michael Silk > Sent: Wednesday, April 06, 2005 9:40 AM > To: Kenneth R. van Wyk &g

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

2005-04-06 Thread Michael Silk
Quoting from the article: ''You can't really blame the developers,'' I couldn't disagree more with that ... It's completely the developers fault (and managers). 'Security' isn't something that should be thought of as an 'extra' or an 'added bonus' in an application. Typically it's just about prog