Actually CJC, it's often even worse than that. In many cases, the customer or consumer has an implicit requirement for security that remains unstated. Only when the system fails and is successfully attacked does that requirement shift from implicit to explicit. "You mean it wasn't secure?? You've got to be kidding..."
In some sense that's what happened to Microsoft way back in the virus-bag days. History shows that it is best to anticipate implicit requirements and address them as possible. gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com On 8/21/09 8:40 AM, "Cassidy, Colin (GE Infra, Energy)" <colin.cass...@ge.com> wrote: Martin Gilje Jaatun wrote: > Karen, Matt & all, > > Goertzel, Karen [USA] wrote: > > I'm more devious. I think what needs to happen is that we > need to redefine what we mean by "functionally correct" or > "quality" code. If determination of functional correctness > were extended from "must operate as specified under expected > conditions" to "must operate as specified under all > conditions", functional correctness would necessarily require > security, safety, fault tolerance, and all those other good > things that make software dependable instead of just correct. > > > I couldn't agree more! > > However, I have had several discussions with a colleague who is fairly > well known in the"Software Process Improvement Mafia" on the topic of > how to ensure that security requirements are considered for > _all_ kinds > of code, not just "security software". Particularily in the context of > agile development techniques, security keeps getting the short end of > the stick, losing every time to "working features". His stance on this > is that "if security were important to the customer, the > customer would > provide and prioritize security requirements". To me, this is > a bit like > saying "If the customer doesn't explicitly state that the software > should be Y2k-proof, he/she is not really bothered about it". The problem (certainly as I see it) is that the customer is likely to say "Make it secure" without really understanding what that means. Secure against what exactly? Or you'll get a list of security features that the customer wants, but as we all know security features != secure product. Instead we've taken a combined approach of including customer requirements and adding specific requirements of our own focusing a good Secure development practices. > If we can "brainwash" the coming generations of programmers into > accepting Karen's definition of "quality code", we might finally be > getting somewhere. And that's the trick we've been attempting here. Secure software is nothing more than really good quality code. We already use coding guidelines and have a strong(ish) process of code reviews. So we have augmented our coding and review guidelines to include secure coding aspect such as input/output validation, good memory management etc. That said there is still a lot of scope for improvement in the rest of the software development process (testing and design in particular). CJC _______________________________________________ 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. _______________________________________________
