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

From: InfoSec News (isn@private)
Date: Fri Oct 17 2003 - 00:18:09 PDT

  • Next message: InfoSec News: "[ISN] Hospitals back off Cisco LEAP security for WLANs"

    Forwarded from: "Rob, grandpa of Ryan, Trevor, Devon & Hannah" <rslade@private>
    
    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@private
    %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@private      slade@private      rslade@private
          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@private with 'unsubscribe isn'
    in the BODY of the mail.
    -
    ISN is currently hosted by Attrition.org
    
    To unsubscribe email majordomo@private with 'unsubscribe isn'
    in the BODY of the mail.
    



    This archive was generated by hypermail 2b30 : Fri Oct 17 2003 - 11:15:22 PDT