BKPGTMIS.RVW 20040514
"A Practical Guide to Managing Information Security", Steve Purser,
2004, 1-58053-702-2, C$120.50
%A Steve Purser
%C 685 Canton St., Norwood, MA 02062
%D 2004
%G 1-58053-702-2
%I Artech House/Horizon
%O C$120.50 800-225-9977 fax: 617-769-6334 artech@artech-house.com
%O http://www.amazon.com/exec/obidos/AS...bsladesinterne
http://www.amazon.co.uk/exec/obidos/...bsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASI...bsladesin03-20
%P 259 p.
%T "A Practical Guide to Managing Information Security"
After years of reviewing security books there were a number of red
warning flags in the preface: the perception that a book was needed to
address the "entire" subject of security, an insistence on a
"pragmatic" and management oriented approach, and the use of a
"fictitious but realistic case study" to support the arguments in the
work. The final omen came in the author's bio on the back cover: he's
a banker.
Chapter one is a vague statement that the information technology world
is getting riskier, but states outright the irresponsible notion that
it is better to provide a less secure product to customers as long as
that reduces your "time to market." This is backed up by a great deal
of waffling managementspeak that boils down to the idea that we have
to learn to work faster *and* cheaper *and* better *and* smarter. The
footnotes and references intended to demonstrate that this is a
scholarly and researched effort are, instead, a grab bag of varying
origin and quality, indicating that the author isn't really familiar
with security literature, and used whatever he happened to read. A
few security information sources and generic advice on planning is in
chapter two. The taxonomy of technical tools, in chapter three,
contains no entries for accounting, application development,
operations, physical security, assurance, or business continuity, thus
indicating the enormous gaps in this work. The artificial structure
imposed on the list works against an integrated view of the tools:
Purser obviously doesn't understand intrusion detection divisions, or
that host-based and net-based systems both provide details--but of
differing views.
In chapter four, Purser obviously thinks that he is giving us new
insight into security assessment, when all that is really being
delivered is a generic project planning cycle. Similarly, chapter
five deals with business and threat analysis. A vague review of
policy documents is in chapter six. Chapter seven takes on that
wonderful buzzphrase, "process re-engineering," having almost nothing
to do with security at all. A planning cycle comes up again when
chapter eight supposedly looks at security architecture. Chapter nine
covers security training, in an overly formal way.
This book adds almost nothing to the existing security literature,
except for a lot of management directed verbiage.
copyright Robert M. Slade, 2004 BKPGTMIS.RVW 20040514
--
======================
rslade@vcn.bc.ca slade@victoria.tc.ca rslade@sun.soci.niu.edu
============= for back issues:
[Base URL] site http://victoria.tc.ca/techrev/
or mirror http://sun.soci.niu.edu/~rslade/
CISSP refs: [Base URL]mnbksccd.htm
Security Dict.: [Base URL]secgloss.htm
Book reviews: [Base URL]mnbk.htm
Review mailing list: send mail to techbooks-subscribe@egroups.com
or techbooks-subscribe@topica.com
Here is my response to the review of my book written by Robert Slade.
Hopefully, it will clear up any confusion that this review has
created. Unlike the reviewer, I will avoid emotionally charged
language and stick to the facts.
The first paragraph aims to establish the credibility of the reviewer
and does not really require a response from my side, except to point
out the fact that I am not a banker - I just happen to work for a
financial institution. Needless to say, I wouldn't consider it any
kind of omen if I were a banker and sweeping statements about
professionals in particular sectors are unlikely to add value to any
serious review.
The opening statement of paragraph 2 is a classic example of quoting
out of context. The text in the book actually refers to the balance
between the benefits to the organisation of getting to market quickly
versus the risk to the organisation of reducing security
functionality. Most organisations have to take similar decisions all
the while and there is nothing irresponsible about achieving a
sensible compromise.
Most of the remaining text is subjective, rather than objective
criticism and the reviewer simply conveys the feeling that he didn't
like what he read. Again, I won't comment on this, as this is no facts
are stated. The description of the content as being "generic" and
"vague" is entirely unjustified in my opinion. The comment regarding
the taxonomy of tools is correct however – I took the decision to
limit the content of this section and I still stand by this decision.
This is a book about managing information security and the emphasis is
on management, not technology. This being the case, it is perhaps not
too surprising to discover the fact that it contains a lot of
"management directed verbiage".
Without wishing to fall into the same trap as the reviewer, it seems
likely to me that Robert Slade made his mind up about this book on the
basis of the "red warning flags" he refers to in his first paragraph
and not on the basis of the content.
Steve Purser.
