REVIEW: "Secure Coding", Mark G. Graff/Kenneth R. van Wyk

[InfoSec News <isn () c4i org>]

Forwarded from: "Rob, grandpa of Ryan, Trevor, Devon & Hannah" <rslade () sprint ca>

BKSECCOD.RVW   20030902

"Secure Coding", Mark G. Graff/Kenneth R. van Wyk, 2003,
0-596-00242-4, U$29.95/C$46.95
%A   Mark G. Graff
%A   Kenneth R. van Wyk
%C   103 Morris Street, Suite A, Sebastopol, CA   95472
%D   2003
%G   0-596-00242-4
%I   O'Reilly & Associates, Inc.
%O   U$29.95/C$46.95 800-998-9938 fax: 707-829-0104 nuts () ora com
%O  http://www.amazon.com/exec/obidos/ASIN/0596002424/robsladesinterne
  http://www.amazon.co.uk/exec/obidos/ASIN/0596002424/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0596002424/robsladesin03-20
%P   224 p.
%T   "Secure Coding: Principles and Practices"

Recent events have demonstrated that we are badly in need of guidance
in the matter of the construction of secure software (or the safe
fabrication of code).  This book covers a topic that is very
necessary.  Unfortunately, the work is insufficient to the task.

Chapter one provides us with the all-too-common information that
attacks happen, and that there are bugs in software, but at least the
writing style is thought-provoking.  At times the material is also
bemusing, as in the beginning of chapter two, which proposes that code
be "just secure enough"--even though the end of the previous chapter
pointed out that premise as one of the problems of software quality. 
We are given thirty principles of secure architecture (the first one
of which has at least seventeen sub-points), and while all of them are
good, they are both too many to serve as a convenient guide, and still
not exhaustive of the possible problems.  (Number thirty tacitly
admits this, asking "what did I forget?")  There are some examples
that provide a limited amount of practical advice on design, in
chapter three, but much of the content is abstract and vague.  It is
hard to find a structure or thread through the material, which seems
to be a miscellaneous collection of security topics such as risk
management.  Chapter four dispenses good suggestions about
implementation, but the text hardly constitutes any kind of failsafe
process for building software.  Operations, in chapter five, seems to
be basically a review of all aspects of security.  Chapter six starts
out by bemoaning the fact that so much of testing is done on an ad hoc
basis, without structure and process.  This is quite ironic, in view
of the fact that the book can fairly be described as ad hoc, too.

While the advice given in the text is useful and good, it is also
generally well-known, and often unsupported by material in regard to
how the recommended outcomes might be accomplished.  This is certainly
a rallying cry for what we need to do, but doesn't necessarily move us
closer to actually doing it.

copyright Robert M. Slade, 2003   BKSECCOD.RVW   20030902


======================  (quote inserted randomly by Pegasus Mailer)
rslade () vcn bc ca      slade () victoria tc ca      rslade () sun soci niu edu
      Metabolically challenged - politically correct term for dead
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade



-
ISN is currently hosted by Attrition.org

To unsubscribe email majordomo () attrition org with 'unsubscribe isn'
in the BODY of the mail.