This is great, and something I have incorporated into our own cycle previously, as carving out a spot on our team as the "security engineer" didn't seem to work. But by creating a process for including security testing, abuse cases, etc. I was able to incorporate security without a big hit to the team. This sold management on the fact that it can be a simple and seamless process and soon became adopted. The other half of it is that you have to be the person on the team who always is thinking in terms of the corner cases, the worst case scenarios, the one who aggravates the development team the most.
I still find that at times you have to raise concerns and show vulnerabilities by actually writing the POC exploits. An example of this would be a portable encrypted filesystem that was used to protect data the application used. No one understood that no matter how long the password was, nor the 256 "bank level" encryption, the filesystem was still insecure in it's _implementation_! By writing an exploit using DLL injection, some exported function hooking and by outputting the password into a plaintext file, the eyes of many were opened. Little did anyone know that part of developing a secure application you have to do it not only in the code, but it it's build process, deployment, etc. But once again the next time a major flaw comes into light, you find yourself in the wee hours of the morning writing a POC to prove just how bad it is. The question to the list is: Can we ever get away from costly exploit development? Has anyone developed techniques in reporting and disclosure that allowed them to avoid a massive caffeine addiction? JS -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, January 07, 2007 11:49 AM To: sc-l@securecoding.org Subject: [SC-L] QASEC Announcement: Writing Software Security Test Cases I've Just released an article about how the Quality Assurance phase of the development cycle can incorporate security testing into a standard test plan, and make it part of the regular testing cycle. Writing Software Security Test Cases: Putting security test cases into your test plan http://www.qasec.com/cycle/securitytestcases.shtml - Robert [EMAIL PROTECTED] http://www.cgisecurity.com/ http://www.qasec.com/ http://www.webappsec.org/ _______________________________________________ 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. _______________________________________________ _______________________________________________ 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. _______________________________________________