I was planning on writing something else today, but Raymond’s post about a buffer overflow in the LHA libraries convinced me to write this up.
Yesterday afternoon, I spent a really quite enjoyable 4 hours sitting in listening to Michael Howard give a refresher course in security to about a thousand product group developers.
Most, if not all of the people attending had been through the security training before, during the first windows security push, this was the first of the annual security refresher courses we’re required to take. Yes, that’s right, required. Microsoft’s REALLY serious about security these days, and as a part of that, every developer, tester and program manager at Microsoft (regardless of division) is going to be required to attend this training yearly. Security training is even a part of new employee orientation.
Fortunately, Michael’s a truly entertaining speaker – he has a knack for telling war stories, and his comments about code are remarkably insightful. If you haven’t bought (and read) his book (here, here, or here), you should do so immediately. I cannot stress how important it is.
Anyway, this new security training session brought up some things I had previously considered (see the discussion here about the zlib library) but hadn’t formalized. Fortunately, Michael framed it brilliantly: Remember the “Giblets”. “Giblets” are the pieces of software that you include in your product that you don’t always remember. Like zlib, or LHA, or MSXML, or the C runtime library.
Whenever you ship code, you need to consider what your response strategy is when a security hole occurs in your giblets. Do you even have a strategy? Are you monitoring all the security mailing lists (bugtraq, ntbugtraq) daily? Are you signed up for security announcements from the creator of your giblets? Are you prepared to offer a security update for your product when a problem is found in one of your giblets? How do your customers know what giblets your application includes?
Have you checked YOUR Giblets lately?
I don't write about the SDL very much, because I figure that the SDL team does a good enough job of it