How to Write an Application Code Review Finding

Revision as of 11:52, 3 April 2006 by Jeff Williams (talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

> Personally, I find all of these lists (the SANS Top 20, the old Top > 10, the old Guide, etc) very negative - which is the way they were > designed. Even the chapter headings in the new book from Howard and > LeBlanc are negative. > > A few years ago, that's how I thought, too. However, I've moved on. > Sure we need to tell people, don't do X when it is necessary, but I > think human nature works better when ideas are framed in a positive > way. Certainly with business types who don't (yet) understand risk > properly. Read this: > > > > I write many reports which occasionally detail pretty bad news for > the recipients. Typically, they are not technical people (nor > necessarily should they be - well-written reports should be > understandable by lay people). Tog's essay was an eye opener for me > and I wish I'd read it sooner. With my more positive approach, I'm > getting greater traction and things are getting fixed. Before, they'd > often go "it's all too hard, we accept this risk, next!" > > I strongly believe we are here to enable secure business, not get in > the way. Too many security folks* forget that we exist to make sure > that ordinary folks don't lose money, don't see their details lost to > identity thieves, and don't lose privacy. "Thou Shalt Not ..." lists > don't really work in this "enable secure business" ideology. > > That's why the Guide has moved from negative titles to positive or > neutral titles. I've tried as hard as I can do phrase the issue in > terms of "This is the business reason why we check for this issue. > Check X. Do Y", rather than say "Faulty authorization. Don't do X. > It's bad. M'kay?". > > Only a few times I resorted to "don't do X" when it was truly > unavoidable and that's a few times too many. Hopefully, by Guide 2.1 > I can make it even more positive. >