Re: [SC-L] Tools: Evaluation Criteria
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Wall, Kevin > Sent: 24 May 2007 12:45 > To: McGovern, James F (HTSC, IT) > Cc: SC-L@securecoding.org > Subject: Re: [SC-L] Tools: Evaluation Criteria > > James McGovern wrote... > > > Maybe folks are still building square windows because we haven't > > realized how software fails and can describe it in terms of > a pattern. > > The only pattern-oriented book I have ran across in my > travels is the > > Core Security Patterns put out by the folks at Sun. Do you think we > > should stop talking solely about code and start talking about how > > vulnerabilities are repeatedly introduced and describe > using patterns > > notation? > [snip I am very happy to accept that we may not understand /all/ or even /most/ of the ways software fails but we do know an awful lot. Buffer overflows, numeric overflows and division by zero have been wee understood for years. The first was limited by various versions of Pascal ages ago. Yet we are still clinging to techniques that hope we can spot a buffer overflow "pattern" after construction (and hopefully before an exploiter!). There is a nice symmetry about my aeronautical analogy. The Comet disasters occurred just over 50 years after the Wright brothers first flew; and we are still fiddling around with buffer overflows just over 50 years after Colossus (at the Bletchley Park crypto centre of Enigma fame) signalled the start of the computer age. That's all, back to the asylum! Peter This email is confidential and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient, be advised that you have received this email in error and that any use, disclosure, copying or distribution or any action taken or omitted to be taken in reliance on it is strictly prohibited. If you have received this email in error please contact the sender. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Praxis. Although this email and any attachments are believed to be free of any virus or other defect, no responsibility is accepted by Praxis or any of its associated companies for any loss or damage arising in any way from the receipt or use thereof. The IT Department at Praxis can be contacted at [EMAIL PROTECTED] Praxis High Integrity Systems Ltd: Company Number: 3302507, registered in England and Wales Registered Address: 20 Manvers Street, Bath. BA1 1PX VAT Registered in Great Britain: 682635707 ___ 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 SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Tools: Evaluation Criteria
I recommend "Security Design Patterns" by Bob Blakley and Craig Heath http://www.opengroup.org/publications/catalog/g031.htm Like any good patterns work, it makes a number of implicit actions, explicit and gives you a way to see how they fit together and when you may choose certain paths. For example section 8.8 on secure proxy patterns, is the best treatment on the subject I have seen. It discusses seven distinct approaches to secure proxies (delegation, impersonation, and so on), it was written in the days before federation and user centric identity, so it would be nice to update it with that. -gp On 5/24/07 6:45 AM, "Wall, Kevin" <[EMAIL PROTECTED]> wrote: > James McGovern wrote... > >> Maybe folks are still building square windows because we haven't >> realized how software fails and can describe it in terms of a pattern. >> The only pattern-oriented book I have ran across in my travels is the >> Core Security Patterns put out by the folks at Sun. Do you think we >> should stop talking solely about code and start talking about how >> vulnerabilities are repeatedly introduced and describe using patterns >> notation? > > You might want to check out securitypatterns.org, and more specifically, > http://www.securitypatterns.org/patterns.html > which mentions a few other books. > > I think there are a few other books by Markus Schumacher, one of which > was based on his doctoral dissertation that is not shown there. > > As to your question, should we stop talking _SOLEY_ about code? Probably, > yes. But I think the reason we don't is two-fold -- the first is that most > of us view that as the easy-part, the low-hanging fruit so-to-speak. The > second is that the development community for the most part, still doesn't > seem to be applying the securing CODING principles, so many of us think > it would be premature to move on to try to teach them secure design > principles, developing security reqts with abuse cases, etc., threat modeling, > etc. From a personal POV, I think that's something that a small team of > security specialists can handle. (At least it mostly works here. Security > evaluations are mandatory shortly after the design is complete.) But we > can't possibly do manual code inspections with a small security team, > so we try to instruct (alas, w/out too much success) developers secure > coding practices to avoid the problems at that level in the first place. > > -kevin > --- > Kevin W. Wall Qwest Information Technology, Inc. > [EMAIL PROTECTED] Phone: 614.215.4788 > "The reason you have people breaking into your software all > over the place is because your software sucks..." > -- Former whitehouse cybersecurity advisor, Richard Clarke, > at eWeek Security Summit > > > This communication is the property of Qwest and may contain confidential or > privileged information. Unauthorized use of this communication is strictly > prohibited and may be unlawful. If you have received this communication > in error, please immediately notify the sender by reply e-mail and destroy > all copies of the communication and any attachments. > > ___ > 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 > SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) > as a free, non-commercial service to the software security community. > ___ > -- Gunnar Peterson, Managing Principal, Arctec Group http://www.arctecgroup.net SOA, Web Services and XML Security & Web Application Security Training Schedule of Public Classes May 15 Milan (OWASP App Sec Conference) June 4-5 Helsinki, Finland (FISA and OWASP) July 17-19 Washington/Baltimore Blog: http://1raindrop.typepad.com ___ 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 SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
Re: [SC-L] Tools: Evaluation Criteria
James McGovern wrote... > Maybe folks are still building square windows because we haven't > realized how software fails and can describe it in terms of a pattern. > The only pattern-oriented book I have ran across in my travels is the > Core Security Patterns put out by the folks at Sun. Do you think we > should stop talking solely about code and start talking about how > vulnerabilities are repeatedly introduced and describe using patterns > notation? You might want to check out securitypatterns.org, and more specifically, http://www.securitypatterns.org/patterns.html which mentions a few other books. I think there are a few other books by Markus Schumacher, one of which was based on his doctoral dissertation that is not shown there. As to your question, should we stop talking _SOLEY_ about code? Probably, yes. But I think the reason we don't is two-fold -- the first is that most of us view that as the easy-part, the low-hanging fruit so-to-speak. The second is that the development community for the most part, still doesn't seem to be applying the securing CODING principles, so many of us think it would be premature to move on to try to teach them secure design principles, developing security reqts with abuse cases, etc., threat modeling, etc. From a personal POV, I think that's something that a small team of security specialists can handle. (At least it mostly works here. Security evaluations are mandatory shortly after the design is complete.) But we can't possibly do manual code inspections with a small security team, so we try to instruct (alas, w/out too much success) developers secure coding practices to avoid the problems at that level in the first place. -kevin --- Kevin W. Wall Qwest Information Technology, Inc. [EMAIL PROTECTED] Phone: 614.215.4788 "The reason you have people breaking into your software all over the place is because your software sucks..." -- Former whitehouse cybersecurity advisor, Richard Clarke, at eWeek Security Summit This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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 SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. ___
