[SC-L] Darkreading: on developer optimism
Hi all, My latest darkreading column (up just 5 minutes ago) is entitled "If You Build It, They'll Crash It." http://www.darkreading.com/document.asp?doc_id=98702&WT.svl=column1_1 It's about what we all need to do to get developers and builder types to think about bad people. I'm trying to address the "nobody would ever do that" problem. Pass it on... gem company www.cigital.com podcast www.cigital.com/silverbullet book www.swsec.com This electronic message transmission contains information that may be confidential or privileged. The information contained herein is intended solely for the recipient and use by any other party is not authorized. If you are not the intended recipient (or otherwise authorized to receive this message by the intended recipient), any disclosure, copying, distribution or use of the contents of the information is prohibited. If you have received this electronic message transmission in error, please contact the sender by reply email and delete all copies of this message. Cigital, Inc. accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or its contents. Thank You. ___ 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
RE: [SC-L] Dr. Dobb's | Quick-Kill Project Management | June 30, 2006
Kenneth Van Wyk writes... > http://www.ddj.com/dept/architect/189401902 > ... > Put another way, how does a team hold onto its good practices (not > just security reviews) when they're in crisis mode? I'm sure that > the answer varies a lot by team, priorities, etc., but I'd welcome > any comments, opinions, etc. from any of you who have been in > similar situations. I've been in this situation several times in my 25+ years in software development (especially with post-divestiture Bell Labs). During the times that it has been successfully addressed, I've noticed one major common theme and that is that the development team (and particularly the team lead) has got to have the "balls" to stand up to management and tell them that the dev team is unwilling to compromise on quality / security / (fill-in-the-blank-with-whatever-is-important-to-you) and that the ONLY way that it can be done is to drop certain FUNCTIONALITY (which usually management is reluctant to do). How successful this approach is depends on the several things (not a comprehensive list): 1) Whether the team has any credibility with management or not. (Hint: If you've already slipped your original schedule several times, you probably don't have any. :-) 2) How well the dev team presents its arguments, especially in terms of risks of NOT doing testing / security reviews / insert-your-favorite-here. (Since security is in a large part about _managing_ risks, this fits in nicely.) You need to remember though that ultimately, it is management's discretion whether or not to accept the risk(s), not the development team's. 3) How tactfully you present your case. (I.e., don't be arrogant; be willing to show some flexibility, e.g., working some additional hrs of unpaid OT; etc.) 4) Know your Brooks' _Mythical Man-Month. Management almost certainly will offer to give you more developers/testers/etc. This is almost always a bad ROI since you will spend more time bringing those individuals up-to-speed on your project than you will get back in productivity. Also, know your Capers Jones'; he has produced some excellent documentation that shows that dropping things like software code inspections actually increases software costs and time-to-delivery. It also greatly helps to have a team with enough spine that they all are willing to walk and find another job if they feel that they are being held hostage and being forced to make unnecessary compromises. I have been fortunate to have worked with many such teams in the past who consider their craftsmanship and pride in their work more important than prevalent "finish this yesterday" mentality, including a few teams that HAVE been willing to walk out in such situations. (Of course, that was during the dotcom boom, when all you had to do to find an development job was to know how to spell "www". I'm not sure how committed those people would have been during the leaner times.) BTW, I am proud to say that the application security team that I have worked with for the past six years or so have had the courage to insist that best practices such as formal use cases, design reviews, code inspections, etc. be followed even though the _formal_ IT process had thrown such practices out the window in favor of so-called XP development practices. (When it comes to security, I tell management that XP stands for "eXpect Problems" rather than "eXtreme Programming".) Of course, it is best to avoid situation like those described in the _Dr. Dobb's_ article in the first place. That's where it's useful to have a skill in estimating development effort, and one unfortunately where I think we as an industry have a rather poor track record. But that's another topic entirely. -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 > I saw an article on Dr. Dobb's (via Slashdot) this morning that made > me pause a bit. The article is on "Quick-Kill Project > Management" -- > full link is here: > > http://www.ddj.com/dept/architect/189401902 > > The article describes a small project team (say 5 developers) who > have suddenly had their dev schedule drastically accelerated on them > by powers outside of their control. It describes some techniques > that the dev leader can use to concentrate the team's focus on > killing (hence the name) the most pressing of issues. Not > surprisingly, there's no mention of security in the article, > although > they do talk about conducting code reviews, but only for functional > defects in the code. > > What caught my attention here is that I'll bet that a *lot* of small > dev t
[SC-L] Dr. Dobb's | Quick-Kill Project Management | June 30, 2006
Greetings SC-L, (Sorry for the previous message; I see that my (new) MacGPG is causing grief for Mailman, so I'm re-sending this message unsigned.) I saw an article on Dr. Dobb's (via Slashdot) this morning that made me pause a bit. The article is on "Quick-Kill Project Management" -- full link is here: http://www.ddj.com/dept/architect/189401902 The article describes a small project team (say 5 developers) who have suddenly had their dev schedule drastically accelerated on them by powers outside of their control. It describes some techniques that the dev leader can use to concentrate the team's focus on killing (hence the name) the most pressing of issues. Not surprisingly, there's no mention of security in the article, although they do talk about conducting code reviews, but only for functional defects in the code. What caught my attention here is that I'll bet that a *lot* of small dev teams end up in situations very similar to the one described in the article's opening statements. In that sort of situation (where the company VP says "finish this yesterday"), I'd expect that doing just about any sort of security review is the first thing to be dropped from the dev schedule. I wonder, though, if teams that have already integrated (say) static analysis tools into their build cycle might have a fighting chance at *not* dropping those checks during this kind of "death march". Put another way, how does a team hold onto its good practices (not just security reviews) when they're in crisis mode? I'm sure that the answer varies a lot by team, priorities, etc., but I'd welcome any comments, opinions, etc. from any of you who have been in similar situations. Cheers, Ken Kenneth Van Wyk KRvW Associates, LLC http://www.KRvW.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] Dr. Dobb's | Quick-Kill Project Management | June 30, 2006
Greetings SC-L,I saw an article on Dr. Dobb's (via Slashdot) this morning that made me pause a bit. The article is on "Quick-Kill Project Management" -- full link is here:http://www.ddj.com/dept/architect/189401902The article describes a small project team (say 5 developers) who have suddenly had their dev schedule drastically accelerated on them by powers outside of their control. It describes some techniques that the dev leader can use to concentrate the team's focus on killing (hence the name) the most pressing of issues. Not surprisingly, there's no mention of security in the article, although they do talk about conducting code reviews, but only for functional defects in the code.What caught my attention here is that I'll bet that a *lot* of small dev teams end up in situations very similar to the one described in the article's opening statements. In that sort of situation (where the company VP says "finish this yesterday"), I'd expect that doing just about any sort of security review is the first thing to be dropped from the dev schedule. I wonder, though, if teams that have already integrated (say) static analysis tools into their build cycle might have a fighting chance at *not* dropping those checks during this kind of "death march". Put another way, how does a team hold onto its good practices (not just security reviews) when they're in crisis mode? I'm sure that the answer varies a lot by team, priorities, etc., but I'd welcome any comments, opinions, etc. from any of you who have been in similar situations.Cheers,Ken Kenneth Van WykKRvW Associates, LLChttp://www.KRvW.com PGP.sig Description: This is a digitally signed message part ___ 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] "Baking Security In" - Microsoft dev security training
http://softwaredev.itbusinessnet.com/articles/viewarticle.jsp?id=47176 Gadi. ___ 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
