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