On 7/21/06, Dana Epp <[EMAIL PROTECTED]> wrote: > > yeah. > > but none of this changes the fact that it IS possible to write > completely secure code. > > -- mic > > And it IS possible that a man will walk on Mars someday. But its not > practical or realistic in the society we live in today. I'm sorry mic, > but I have to disagree with you here. > > It is EXTREMELY difficult to have code be 100% correct if an application > has any level of real use or complexity. There will be security defects.
Why? Why accept this as a fact? It is not a fact. If you put procedures in place and appropriately review and test you can be confident. > The weakest link here is the human factor, and people make mistakes. Yes they do. So help them to stop it by teaching and testing and reviewing. > More importantly, threats are constantly evolving and what you may > consider completely secure today may not be tomorrow when a new attack > vector is recognized that may attack your software. This isn't as true and as wide spread as you make it sound. Consider, for example, "SQL Injection". Assuming I do not upgrade my database, and do not change my code and server (i.e. do not change my environment at all), then if I have prevented this attack initially nothing new will come up to suddenly make it work. If the environment IS changed, however, then of course it's expected that the program should be reviewed and checked again. > And unless you wrote > every single line of code yourself without calling out to ANY libraries, > you cannot rely on the security of other libraries or components that > may NOT have the same engineering discipline that you may have on your > own code base. Not true; you can call other libraries happily and with confidence if you handle the case of them going all kinds of wrong. > Ross Anderson once said that secure software engineering is about > building systems to remain dependable in the face of malice, error, or > mischance. I think he has something there. If we build systems to > maintain confidentiality, integrity and availability, we have the > ability to fail gracefully in a manner to recover from unknown or > changing problems in our software without being detrimental to the user, > or their data. > > I don't think we should ever stop striving to reach secure coding > nirvana. But I also understand that in the real world we are still in > our infancy when it comes to secure software as a discipline, and we > still have much to learn before we will reach it. Yes, Much to learn. Like the fact that it _is_ reachable if you believe you can reach it. And, you know, study yoga and live in a cliff for a few years. > Regards, > Dana Epp > [Microsoft Security MVP] > http://silverstr.ufies.org/blog/ -- mic _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
