Jeff, On Apr 7, 2005 11:00 AM, Jeff Williams <[EMAIL PROTECTED]> wrote: > > I would think this might work, but I - if I ran a software development > > company - would be very scared about signing that contract... Even if > > I did everything right, who's to say I might not get blamed? Anyway, > > insurance would end up being the solution. > > What you *should* be scared of is a contract that's silent about security.
If you're silent you can claim ignorance :D But of course, I agree. "Security" should be mentioned under the part of applications "Working Right". What I meant I would be scared of, however, is that if the contract didn't fully specify what I would be taking responsibility for. I.e. I could be blamed if some misconfiguration on the server allowed a user to run my tool/component as admin and enter some information or do whatever. The contract would have to be specific (technical?) so-as to avoid problems like this. But I presume you have had far more experience with these issues than I have... can you share any w.r.t to problems like that? Because I can imagine [if I wasn't ethical] trying to blame a security problem in My Big Financial Website on a 3rd party tool if I could. > Courts will have to interpret (make stuff up) to figure out what the two > parties intended. I strongly suspect courts will read in terms like "the > software shall not have obvious security holes". They will probably rely on > documents like the OWASP Top Ten to establish a baseline for trade practice. > > Contracts protect both sides. Have the discussion. Check out the OWASP > Software Security Contract Annex for a > template.(http://www.owasp.org/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 R. van Wyk" <[EMAIL PROTECTED]> > >> Cc: "Secure Coding Mailing List" <SC-L@securecoding.org> > >> 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 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 programming _correctly_! > >> > > >> > The article says it's a 'communal' problem (i.e: consumers should > >> > _ask_ for secure software!). This isn't exactly true, and not really > >> > fair. Insecure software or secure software can exist without > >> > consumers. They don't matter. It's all about the programmers. The > >> > problem is they are allowed to get away with their crappy programming > >> > habits - and that is the fault of management, not consumers, for > >> > allowing 'security' to be thought of as something seperate from > >> > 'programming'. > >> > > >> > Consumers can't be punished and blamed, they are just trying to get > >> > something done - word processing, emailing, whatever. They don't need > >> > to - nor should. really. - care about lower-level security in the > >> > applications they buy. The programmers should just get it right, and > >> > managers need to get a clue about what is acceptable 'programming' and > >> > what isn't. > >> > > >> > Just my opinion, anyway. > >> > > >> > -- Michael > >> > > >> > > >> > On Apr 6, 2005 5:15 AM, Kenneth R. van Wyk <[EMAIL PROTECTED]> wrote: > >> >> Greetings++, > >> >> > >> >> Another interesting article this morning, this time from > >> >> eSecurityPlanet. > >> >> (Full disclosure: I'm one of their columnists.) The article, by > >> >> Melissa > >> >> Bleasdale and available at > >> >> http://www.esecurityplanet.com/trends/article.php/3495431, is on the > >> >> general > >> >> state of application security in today's market. Not a whole lot of > >> >> new > >> >> material there for SC-L readers, but it's still nice to see the > >> >> software > >> >> security message getting out to more and more people. > >> >> > >> >> Cheers, > >> >> > >> >> Ken van Wyk > >> >> -- > >> >> KRvW Associates, LLC > >> >> http://www.KRvW.com > >> >> > >> > > >> > > >> > >> > >
