My talk at Secure 360 was on Process Not Outcomes, we've limited control over otucomes, but we can all improve our processes. One way to do this is with checklists. Checklists help us navigate complex domains and avoid mistakes around things that we know but don't apply.
One of the things that makes infosec an interesting field is the situation that I characterize as 50% gnarly, deep technical problems (think Kerberos) and 50% brain dead mistakes (think private keys in source code repository). You can fail by messing up either one, checklists are about avoiding the second class of mistakes.
The way that checklists are most effective is when you make them your checklists instead of blind adoption of industry top ten lists. Making it your checklist means mapping it to your development process, what must be done before promoting from dev, from test to prod and into operations.
Project Checklist has a great set of rules for writing effective checklists. Following the disciplines that they recommend forces hard choices on the infosec team to gather and prioritize items for the checklists that are actionable with clear, concise guidance. Importantly, it gets Infosec out of playing Dr. No and coming only with hugely time consuming and expensive solutions. Instead look to integrate the checklist into the development process, and make it simple enough for a developer to fill out in a short amount of time.
What else can checklists do? http://www.newyorker.com/reporting/2007/12/10/071210fa_fact_gawande
Posted by: Steve Bern | May 17, 2012 at 09:32 AM
The challenge with checklists is that unlike doctors who know what they are doing, the same thing cant be said of programmers. A checklist in the hands of someone who doesn't know what the checkbox means is still an infosec challenge.
Posted by: James McGovern | May 20, 2012 at 04:07 PM