security silver bullet

i am still on the lookout for quality podcasts. one of the series i’ve been really enjoying lately is silver bullet security podcast by gary mcgraw.

i am a bit of a fanboy – i’ve got all three of his software security books, and i have been following him for a while – listening to the interviews and reading the articles.

i go through a lot of podcasts on regular basis, and “silver bullet” is one of the most impressive ones. first of all, the sound quality itself is pretty damn good. having suffered through some badly-recorded, non-normalized audio in the past, i am happily listening to articulate, passionate folks that actually sound good. perhaps the sound quality it is due to gary mcgraw’s music career.

secondly, he manages to pull together an impressive array of people that have proven themselves over the years in the field of security. in most cases they’ve been at it for decades, and it shows.

since security is a relatively new field, most of his guests come from different backgrounds, which makes interviews all the more interesting. gary mcgraw himself did his undergrad in philosophy, while his phd was in CS and cognitive science under douglas hofstadter (in fact, gary mcgraw contributed a chapter to Fluid Concepts and Creative Analogies).

having read his books, there is not much new in the podcast, but it really helps to clarify and reinforce the basics as well as acquire the vocabulary to be able to discuss these topics. this is why i am on my second round re-listening to the podcast.

one of the main insights i got from listening to the podcast came from its title. “silver bullet” is the famous essay by brooks where he argues that there are inherent complexities in software development that will not magically disappear by introducing better tools or practices.

security is complex. there are accidental complexities, that could be (and are) addressed – get rid of languages with memory overflow problems, introduce address space layout randomization, use static analysis tools, etc.

at the same time there are inherent, essential complexities to security that will always be in place due to new applications that create new attack vectors simply by the virtue of their functionality.

thus it is logical to see security overlapping with QA (QA being quality assurance as a process, which deals with ensuring that quality happens, as opposed to testing which is simply one aspect of it). given this approach, a lot of things about security fall into place: “security means risk management”, “security is a process, not a product”, “there is not absolute security”, “security faults are quality faults”, “it is harder to build a secure system than to break one”, “one cannot sprinkle some magic security dust at the end of the project”, usefulness of “badness-ometers” as gary calls them, etc (these one-liners have such a nice ring to them and stimulate thinking in the right direction; they are butchering the contents of the books though, so read them for the facts!).

since podcast series are not that technical at all (although most of the participants are quite hardcore hackers), i would wholeheartedly recommend them to the broadest audience.