Agile IT Security Implementation Methodology

Jeff Laskowski (2011)
Review date: January, 2012

Publisher's site (PACKT publishing)
Opinion

This book takes a novel approach towards IT security. After reading it, I got the impression that the author has spent a lot of time in big organizations, like the ones described in the book's eighth chapter, according to which, security is handled by vulnerability assessment teams, system administration teams, network administration teams, intrusion analysis teams, intrusion response teams, and so on.

In such organizations, addressing a seemingly simple problem may be daunting task due to the administrative overhead and communication paths, so the author came up with the idea that the process could be simplified by applying agile methods. A very good idea!

Unfortunately, the book doesn't deliver on this idea. Maybe I read it having too high expectations, but my overall feeling is that there are too many gaps, too many incomplete or simplified lines of reasoning, and that the book requires a reader that's very familiar with agile methods and knows a thing or two about IT security. Readers familiar with both topics will find some gems, and new ideas, such as the bullpen, but must also overlook some simplifications, far-stretched reasoning, and lack of depth. For example, chapter eleven, titled "Barriers to Agile", is two pages. While nothing in the chapter is incorrect, I'd really like the topic to be expanded a little. There have to be barriers and problems specific to IT security and agile, and they sure deserve more in-depth treatment than two pages.

Readers approaching this book to learn how agile thinking can be applied to IT security will find chapter four the most interesting. Here a bunch of principles and techniques from Extreme Programming, Scrum, and Lean have been fitted to apply to security. For example, it makes sense that security-related work be done in pairs (as in pair programming). It would be nice if security solutions were refactored, although I suspect they seldom are. Small deliverables apply to pretty much everything, and so does decomposition. Now collective membership, it'd really like to learn how that worked out in the author's siloed organization. Spikes and simple design should apply equally well to security solutions. Good so far.

Chapter four also contains some things that were not very familiar to me. For example: "project divergence rate". It's a measure of how many "changes" that occur in the project during a given time interval. When requirements stabilize, the project divergence rate goes down. This type of micro-measurement doesn't ring very agile to me, but if it works for somebody then it works. "Project velocity rate" is discussed next, and is defined as total number of hours needed to complete something divided by the estimate.

Personally, I'd measure the velocity in story points and use the focus factor get the kind of information that the project velocity rate provides. However, there are many ways of estimating and following up work.

Then there is "agile processes need Scrum Masters to help keep projects moving". No. Scrum needs Scrum Masters, and the chapter is about Scrum, XP, and Lean under the collective name of "Agile". A similar argument could be applied the way standup meetings and planning poker are described.

The problem with this chapter is that it mixes some small techniques, like planning poker, with bigger concepts like minimizing waste, in a seemingly unstructured manner. I think it would be better if the author first gave a brief description of the underlying methodologies, then described the principle/technique as applied in the methodology, then its adaption to security, and finally some examples, success stories or personal reflections. Without the latter, the reader doesn't really know how the adaption works in practice. Has the author used the technique once, a hundred times, or does he just think that it seems to be a good idea?

Chapter seven seems to be more ambitious about talking about a methodology - Lean, but again, war stories, lessons learned and details specific to applying Lean to security are missing.

Chapter five, I believe, is one of the better chapters. Here we learn about a visualization technique called the "bullpen". It's a way of modeling data sources, infrastructure and risk sources in a simple and visual manner. The concept is expanded upon in the following chapter. Then there's a short intro to DREAD modeling.

The book also contains material that's strictly about security. Chapters one, two, and nine comprise an introduction, talk about threats in general, and about security awareness. I think that some of the material therein isn't quite up to date, and I reacted to some phrases like: "Social engineering is the latest trend in hacking". What bothered me the most, though, was that there was no Chekov's gun. If a chapter is spent describing new security threats, then it would be really cool to see how agile security is used to address those threats towards the end of the book.

In conclusion, I think the book is on to something. The underlying ideas are good, and intellectual effort has been put into finding agile techniques that should be transfer nicely to security. What I expect as a reader is more structure, more background, and a natural blending of the chapters on security and agile. And above all, the author's experience of applying these techniques!

Who should read this book

Readers seeking agile inspiration in their daily IT security work may find some ideas in this book.




News

  • 2015-09-29

    It's been almost one and a half year since I reviwed a book! I've been too absorbed by Writing my own. Anyway, I'm back with Jeff Patton's relatively...
  • 2014-01-04

    New category! Performance! Reviewed The Every Computer Performance Book. Check it out!
  • 2013-09-10

    Reviewed a book that' slightly less technical, but much more fun to read. It's I.T. Confidential.
  • 2013-08-13

    Reviewed yet another book on Visual Studio 2012 and TFS. I also created a "Microsoft" category and moved the other TFS book there from the "Tools"...
  • 2013-08-05

    Updated the FAQ. Included information about getting a book reviewed.