Book Review - Information Security Handbook

Categories: Security


This article contains some notes I made while reading the book Information Security Handbook by Darren Death, and which did not fit into the security book review article.

Disclaimer: I am no world expert in this area, and no literary reviewer - no guarantee that the following info is worth your time to read.

  • Title: Information Security Handbook
  • Author: Death, Darren
  • Publisher: Packt
  • Published: 2017


A very informative book on security from an “infosec management” viewpoint. It isn’t technical, addressing things like security policies and risk management rather than system-level or code-level solutions for security. However it is practical and pragmatic where many management-level books tend to use buzzwords and hand-waving.

The content is really targeted at a CISO candidate. However anyone who interacts with a CISO will also benefit (whether board member, HR, business-unit management, or technical staff)

The book editing is sadly not particularly good, but the content is worth ignoring the odd formatting, overuse of bullet-points, and occasional spelling error.

Writing is somewhat dry and “imperative” in form. Some real-life examples might have helped to make processes and procedures more understandable - although the book is quite long enough already!

Some of the discussion around SDLC/SELC software-development-related processes is a bit old-fashioned; very much waterfall-based thinking. Some adapting of the principles described here may be needed in more modern companies.


I found the following quotes interesting.

Do not start from scratch when you begin to establish your information security program. There are many excellent frameworks that exist that you can use to establish your information security program. Look to standards such as the ISO 27000 series, NIST Cybersecurity Framework, or COBIT 5.


I like this table on security policies specifying three types of policy (where control = measure or step or feature):

  • technical (implemented in hardware or software)
    • access-control
    • audit and accountability
    • identification and authentication
    • system and communications protection
    • examples
      • account management
      • end user device security
      • server security controls
      • network security controls
      • web-based application controls
  • management (responsibility of senior management)
    • planning
    • risk assessment
    • security assessment
    • system and services acquisition
    • eg
      • information security program
      • establishment of official roles
      • information security metrics
      • conducting risk assessments
      • organising vulnerability scanning
      • organising penetration testing
      • account rights reviews
  • operational (responsibility of operational staff)
    • awareness and training
    • configuration management
    • contingency planning
    • incident response
    • maintenance
    • media protection
    • personnel security
    • physical and environmental protection
    • system and information integrity
    • eg
      • training topics
      • expected and prohibited behaviour
      • employee screening
      • account termination
      • business continuity planning
      • disaster recovery
      • incidence response planning
      • workplace security
      • removable device security
      • sensitive data security

I also liked this list of policy documents that should exist:

  • Planning policy - mgmt roles, and rules over development and maintenance of other policies
  • Access control policy - rules on who can do what (at a high level) - not limited to electronic documents
  • Awareness and training policy - how to educate staff about security
  • Auditing and accountability policy - rules ensuring you can know who did what when, and what to do when somebody ignores the rules (not limited to electronic systems)
  • Configuration management policy - rules on how to deployment software, reconfig networks, etc. - including approval and audit trails
  • Contingency planning policy - a plan for what to do when things go wrong (other than security vulnerability)
  • Identification and authentication policy - how to know who a person is (physically or on network) and how to technically enforce access control policy
  • Incident response policy - a plan for handling a security vulnerability
  • Maintenance policy - rules on safely managing device repair (including desktops), rules about external party access to do software maintenance
  • Media protection policy - rules on handling tapes, disks, usb-sticks, etc. And paper documents too..
  • Personnel security policy - how to verify staff are trustworthy, how to deal with staff arriving and departing, processes for external users
  • Physical and environmental protection policy - protecting systems against break-ins, fire, flood, etc.
  • Risk assessment policy - define how to perform risk evaulations (how to determine the amount of funding/effort to dedicate to a newly-discovered threat)
  • Security assessment policy - how to determine whether a system is compliant with the security policies (how to test/audit compliance)
  • System and communications protection policy - rules on networking and encryption, rules regarding emails and written documents
  • System and information integrity policy - rules on system monitoring, patching, scanning
  • Systems and services acquisitions policy - rules on obtaining new software components and integrating external service suppliers

I hope I haven’t offended against copyright by reproducing these tables; maybe the fact that this is a positive review of the book will help!

Configuration management means:

  • maintaining an inventory of hardware and software
  • ensuring that changes to that inventory are approved beforehand, and tracked.
  • approval includes security-validation, licence-validation, etc.

My Personal Comments

I found the emphasis on creating an “asset catalog” overdone. In my opinion, making an asset catalog may be useful for communicating with management to get support and funding for security tasks. It is difficult to communicate the need to “secure rest endpoints”, but is easier to discuss the costs of “unauthorized access to financial reporting data”, even though one leads to the other and in fact working backwards from the “financial reporting data” to find the points at which security needs to be applied is harder than working forward from a DFD. A suitable asset-catalog may be created as an output of threat modelling..

The author includes any “IT function” as an “asset”, ie any system providing a particular piece of end-user-visible functionality.

I found the description of “threat analysis” a bit weak; it appears to be a standard step in all security standards although in my opinion this smells of “cargo culting” - ie I suspect it is recommended just because others have always recommended it. When looking at threats at a high level, they almost always apply. When looking at threats at a low level, the effort required to determine whether they apply is high, and very related to the details of system configuration and implementation - ie something that needs to be analysed at the per-project level (for every project in the company), rather than by any cross-project team. It therefore seems to me that the best a “security manager” can do is to make all project teams in the company aware of possible threats at a high level, and let them address the issue. Or perhaps this is what the process is trying to say? With the unstated assumption that the project teams are not security-competent and need to be educated and prompted by the cross-project security team?

Further Reading

The following sites were referenced from the book, and are interesting:

Random Notes

  • Information Assurance is the process of defining the requirements for confidentiality, integrity, and reliability for an asset. It is then IT-security’s problem to meet those requirements..