BKSSEGPM.RVW   20081006

"Software Security Engineering", Julia H. Allen et al, 2008,
978-0-321-50917-8, U$49.99/C$54.99
%A   Julia H. Allen
%A   Sean Barnum
%A   Robert J. Ellison
%A   Gary McGraw
%A   Nancy R. Mead
%C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario  M3C 2T8
%D   2008
%G   978-0-321-50917-8 0-321-50917-X
%I   Addison-Wesley Publishing Co.
%O   U$49.99/C$54.99 416-447-5101 800-822-6339 bkexpress@aw.com
%O  http://www.amazon.com/exec/obidos/ASIN/032150917X/robsladesinterne
  http://www.amazon.co.uk/exec/obidos/ASIN/032150917X/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/032150917X/robsladesin03-20
%O   Audience i Tech 2 Writing 1 (see revfaq.htm for explanation)
%P   334 p.
%T   "Software Security Engineering: A Guide for Project Managers"

The foreword maintains that the book addresses all levels of readers
from technical leaders to managers to senior executives.  The preface
defines secure software as applications that will withstand attack. 
Reliability (and other similar characteristics) is implicitly
dismissed.

Most of the material in chapter one, on the importance of software
security, has been published before, and therefore it is primarily a
generic recap and overview.  However, it is content that managers need
to hear.  Unfortunately, the many figures that pad out the space are
not effective illustrations of the concepts and points under
discussion, and can be misleading at times.  For example, unless
examined very carefully, one of them seems to insinuate that detecting
software defects early in the process actually increases the cost of
development.  Chapter two, supposedly about what makes software
secure, is primarily about why approaches to creating secure software
other than the one proposed in the book, are insufficient.  Some
suggestions on how to formalize a rigorous mechanism for determining
requirements for software are given in chapter three, but most of it
is about the SQUARE (Security Quality Requirements Engineering)
process.  Chapter four is the most userful material, presenting a
decent outline of the security analysis necessary for design.  A few
tools that can assist with the development phase are listed in chapter
five.  Chapter six raises the issue of complexity, and the negative
implications for system security.  The material is reasonable
(although it seems to spend more time with why systems fail than how
to make them more resilient), but it seems out of place: in terms of
logical flow the topic should be addressed earlier in the process, in
regard to requirements and design.  Miscellaneous thoughts on the
management of development and projects make up chapter seven.  Chapter
eight is a recap, in tabular form, of the points raised throughout the
book, and provides a useful quick list.

This work is intended for managers rather than developers, and, as
such, it provides a reasonable overview of the problem.  However, it
does not compare with other works on software security, since many of
those are directed at programmers rather than managers.  Experienced
managers (possibly not from a technical background) may find some of
the material on management somewhat condescending, but should pay
attention to the advice on the structure of a programming project.

copyright Robert M. Slade, 2008   BKSSEGPM.RVW   20081006