BKITSCPM.RVW 20060808
"IT Security Project Management", Susan Snedaker, 2006, 1-59749-076-8,
U$59.95/C$77.95
%A Susan Snedaker info@virtualteam.com
%C 800 Hingham Street, Rockland, MA 02370
%D 2006
%E Russ Rogers
%G 1-59749-076-8
%I Syngress Media, Inc.
%O U$59.95/C$77.95 781-681-5151 fax: 781-681-3585 www.syngress.com
%O http://www.amazon.com/exec/obidos/ASIN/1597490768/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/1597490768/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/1597490768/robsladesin03-20
%O Audience i- Tech 1 Writing 1 (see revfaq.htm for explanation)
%P 612 p.
%T "IT Security Project Management"
Chapter one is an introduction, but also something of a preface to the
book. In terms of the intended audience, the author states that it is
assumed readers know the basics of project management and also network
security. The text, therefore, is proposed to be an operational
framework for designing an information technology security project
plan. However, as the material goes on to describe the components of
such a plan only network items are listed: physical security,
applications security, databases, business continuity, and a host of
other considerations are notable by their absence, and even the vital
element of policy is buried as a minor ingredient. There is a vague
and verbose outline of risk and cost/benefit analysis, and a list of
success factors that range from the glaringly obvious (management
support) to the counterproductive (standard off-the-shelf
infrastructure is recommended even though this practice is known to
increase the likelihood of attacks).
Chapter two defines security projects, but mostly in terms of the
sections of a proposal. Organizing the project, in chapter three,
lists various project management factors, probably the most
significant being the composition of the team that will define the
project. (Didn't we do the definition in chapter two?) Ensuring
quality, in chapter four, seems to consist of knowing requirements and
metrics. Chapter five sees the formation of the project team, which
is not the same as the team that defined the project in chapter three.
Standard project planning advice is provided in chapter six. Chapter
seven is supposed to be about managing the project, but there is
little or no mention of the mechanics of management, with the content
concentrating on initiation and changes of specifications. The
termination phase is reviewed in chapter eight.
Chapter nine, entitled "Corporate IT Security Project Plan," is
supposed to be the promised overarching framework. However, after
twenty-two pages of legal advice (and two warnings about giving or
taking unauthorized legal advice), we find a project outline (missing
some of the usual steps) and a haphazard aggregation of project
elements, many of which have been covered previously. (Contrary to
the recommendation in chapter six, the outline lists a number of items
of quite different importance all at the same level.) A random and
unstructured collection of security topics makes up the bulk of
chapter ten, which is nominally about general IT security planning.
The lack of pattern and hodgepodge of subjects seems to confuse even
Snedaker: figure 10-1 on page 265 ("Layered Approach to Network
Security") and figure 10-5 on page 327 ("Elements of IT Security
Requirements") are duplicates. Much the same description is true of
IT infrastructure, in chapter eleven, and it also repeats a good deal
of the content. Wireless security, in chapter twelve, does have more
substance that is specifically related to wireless technology and
risks, although it is strange, given the immediacy of other items in
the work (there is a reference to an event that happened on May 24,
2006), that the list of 802.11 protocols does not list 802.11i, which
is probably the most secure. Chapter thirteen, about operations
security, does have a bit more organization, but is fairly standard
advice about incident response, security awareness, and policy.
If it is expected that the reader is thoroughly familiar with project
management, the primacy and amount of space dedicated to the basic
project operations (chapters two to eight, 158 pages) is odd. It
turns out that the limiting of the technical content to network areas
is of no particular importance, since this volume is really only
generic project management advice anyway (and not overly complete, at
that). Page 445 notes that "[o]ur goal is not to push you to use
outside consultants," but Snedaker is a consultant, and owns a
consulting firm. The writing in this book is turgid, the content
banal, and the advice incomplete. Given that I am a slefprofessed
professional paranoid, I may perhaps be forgiven for imagining that
someone might write a bad book in the hopes that readers, attempting
to figure out how to do it themselves, would give up in disgust and
look around for someone to make sense of the process for them.
Just a thought.
copyright Robert M. Slade, 2006 BKITSCPM.RVW 20060808
====================== (quote inserted randomly by Pegasus Mailer)
rslade@vcn.bc.ca slade@victoria.tc.ca rslade@computercrime.org
When we write programs that learn, it turns out that we do and
they don't. - Alan J. Perlis
Dictionary of Information Security www.syngress.com/catalog/?pid=4150
http://victoria.tc.ca/techrev/rms.htm
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/CISSP-Discuss/
<*> To unsubscribe from this group, send an email to:
CISSP-Discuss-unsubscribe@yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
