Sorry for delay - I left town for thanksgiving and hardly touched my laptop - I bought a shiny new Nikon D-100 and used that instead :-)) I'm more than willing to share what we did - but I'd need to know what sort of info is needed. The process was pretty easy (albeit, hectic!) - education for all (three tracks, dev, test and designers) - lotsa examples, with specifics (such as threat modeling, tracing input and data mutation testing) - the essence of the training is now available as a Microsoft Official Curriculum course, 2805a "Security Seminar for Developers" (I doubt it's deep enough for anyone here!) - each component has to come up with a prioritized list of tasks to complete the push, we reviewed these plans and gave feedback. - devs reviewed code for issues based on the education provided. The good news is people at Msft tend to think WAY beyond just being told what to do - so every group looked critically at their components from a 'blackhat' perspective - that's why education is critical. - testers built new tests that focused on fault injection, data mutation and running more non-admin tests. - designers worked on threat models (average time for threat model: 3 weeks) as well as deteriming what it takes to reduce the attack surface of the product. This inlcudes turning stuff off that's not needed by most users, running with lower priv, extra defensive layers and so on. There's tons more stuff we did... But I need to know what people want... Cheers, Michael Secure Windows Initiative Writing Secure Code http://www.microsoft.com/mspress/books/5612.asp -----Original Message----- From: Dana Epp [mailto:danaat_private] Sent: Tuesday, November 26, 2002 4:41 PM To: Michael Howard; secprogat_private With all the talk of development libraries one common thread has continued to pop up with which there has been little debate. And that is that the weakest link is the human factor, and that better education is required. In many cases, the question not answered is how do we do this in the corporate environment, educating existing developers. I don't want to single out any one person as we have all had/have to deal with this in our own teams. But with Microsoft's latest push on better code quality with a "security-oriented developer's boot camp" I am wondering if anyone from the Secure Windows Initiative or the Trustworthy Computing arena at the campus would like to share with us the approach that was taking for the Microsoft boot camp. I need to apologize immediately to Michael as I have cc'd him on this as he is one of the few people at the Microsoft campus that can speak authoritatively on such endeavours, but unsure what the corporate policy would be on divulging this sort of information. ( Michael, I'll buy you a beer next time I am in Seattle and you can chastise me then :-P ) So how about it? Instead of continuing to beat a dead horse about the length of pointers and the power of the sizeof op (*sigh* will guys ever get over that... this discussion has been going on since the 80's ;-) ) perhaps we could have a constructive thread on approaches used in existing teams to "re-educate" them. Now, we could of course spew forth material from books like "Writing Secure Code", "Security Engineering" and the likes but I would be more interested in the real world application to educate existing developers. It would be interesting to see what sort of materials the "MS Boot camp" used, but can fully understand if they would not wish to disclose such information. More to the point, I bet a lot of us would be interested in how other work places have gone about doing this. Not just Microsoft. On top of that, this may help Michael with the Security Education thread he had about real world examples. Outside of understanding the real world application of knowing how to use the sizeof of (oh hell.. now I am hanging on about it.. shame on me) perhaps techniques taught in the work place could be applied to examples that could be placed in good books like WSC. Feel free to fire the flames to /dev/null. All other constructive criticisms on why this would or would not be a good idea are welcomed. If we get enough good feedback I would love to publish this information on the web for others to read in the future. Including some of the good examples we may be able to cultivate from this. --- Regards, Dana M. Epp
This archive was generated by hypermail 2b30 : Mon Dec 02 2002 - 15:10:48 PST