IT Security Book Reviews

Categories: Security

Introduction

Here are some brief notes on various IT-security-related books.

The reviews are roughly ordered best-to-worst, ie the earliest books on the list are the most worth reading in my opinion. Of course this depends significantly on why you are reading security books and what background you have. I am a software architect and experienced developer, looking for good sources of information on how to choose architectures, libraries, and development practices to secure moderately complex applications and suites of interacting applications in an enterprise environment.

I have a subscription to safari books online, and most of the books below are available there.

Interestingly, many of the books are quite old - perhaps there was a rush of books around 2005 and then the market got saturated.. or maybe safari online just doesn’t have the most recent books.

Worth Reading

  • Threat Modeling: Designing for Security, Shostack 2014

Don’t Bother

  • Introduction to Computer Security, Bishop 2005
  • The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities, Dowd/McDonald/Schuh 2007
  • Risk Centric Threat Modelling: Process for Attack Simulation and Threat Analysis, UcedaVelez/Morana, 2015

Threat Modeling: Designing for Security

Details:

  • Author: Shostack
  • Publisher: Wiley
  • Published: 2014
  • Methodology: STRIDE

An opinionated guide to threat modelling (finding security holes in an IT architecture).

An uneven book, but nevertheless well worth reading.

There is some truly excellent advice in the early chapters on how to analyse an architectural design for potential problems which may be fixed at the architectural, implementation, operating, or business-process level. It addresses how to build a team to analyse a product, how to organise the analysis, and how to ensure problems lead to appropriate fixes (mitigations). The proposed approach uses STRIDE hints to stimulate discussion and discovery of vulnerabilities. The recommendations are pragmatic, avoiding unnecessary bureaucracy and paperwork, and focusing on improving the product rather than generating reports.

Later chapters drifts somewhat into academic and “what if” scenarios.

The content is still mostly relevant, despite the book’s age (2014).

I have written an article on this site about threat modelling which is strongly influenced by this book.

Introduction to Computer Security

Details:

  • Author: Bishop
  • Publisher: Addison-Wesley Professional
  • Published: 2005

Although this book is described as “a simpler version of a more academic book” (Computer Security: Art and Science), the content is still extremely academic and abstract. Most of the content up to chapter 20 is theoretic, with no obvious way to apply the information to the real world. Content from ch 20 onwards is somewhat more real-world (though still “general background info”), but is affected by the age of this book (2005).

This may be somewhat useful if you are inventing a new “certified secure operating system”, an alternative to the TLS protocol, or an alternative to SELinux. For all others, there are far more useful security intros.

The prose is sometimes a little overcomplicated - not a great surprise for an academic.

Content in the first 4 chapters is extremely theoretical, and frankly boring. I also find it somewhat arrogant that statements such as “The average user is not mathematically sophisticated enough to read and interpret the mathematics” (of a formal security definition) when the author also admits at several places that the academic approach doesn’t actually scale to real-world problems or requires unrealististic assumptions about its environment.

The content may be relevant if you are inventing a new “certified secure operating system”, an alternative to the TLS protocol, or an alternative to SELinux. If you need to be “US TCSEC Orange Book compliant” then some of the explanations might be useful.

The content related to cryptography (ch8-10) is better covered in other books (eg Schneier). The content on passwords is trivial and well-known.

Chapter 13 (identity) is moderately useful as a basic introduction. Parts of chapter 14 are moderately useful. Ch18 discusses the various certification processes for operating-systems and encryption-algorithms, if you are interested in such things.

Chapter 20 onwards is a little more relevant to the real world, but also more affected by the age of this book (2005).

Possibly the most useful content I found in the book was a list of principles:

  • Principle of least privilege
  • Principle of fail-safe defaults
  • Principle of complete mediation - be careful when cacheing access rights
  • Principle of open design (ie no security by obscurity)
  • Principle of Psychological Acceptability - dont piss off your users, or they will try to bypass security

And the following quote related to the principle of open design:

If the strength of the program’s security depends on the ignorance of the user, a knowledgeable user can defeat that security mechanism.

The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities

Details:

  • Authors: Dowd, McDonald, Schuh
  • Publisher: Addison-Wesley Professional
  • Published: 2007

This book is specifically aimed at experienced developers who are spending weeks reading the source-code of an existing application to find security issues at the code level. Most of the book is focused on applications in the C programming language (which is fortunately less and less common now).

The prose is nicely readable, and the authors clearly have a good grasp of their topic. However the book falls between audiences.

For those (like me) looking for material about threat modelling of enterprise software, ie suites of interacting applications and servers, this is mostly too detailed. There is some reasonably well-written methodology-type material in the first few chapters, but nothing that cannot be found better in other books. There is also little cover of mitigations, ie how an architect or dev team can design their app to avoid problems; the focus is only on vulnerability discovery.

For those looking for subtle security vulnerabilities in complex single applications or in operating-systems, the material is likely to be too shallow. It might be useful as introductory reading material for those learning white-hat (or black-hat) vulnerability assessment, as many explanations include both introductory and middle-complexity material.

The content is now somewhat outdated; a lot has changed since 2007.

One interesting point made is that accountability is a superset of nonrepudiation, and that access control consists of the tuple (authentication, authorization, accountability). Authorization controls who can do what, and accountability makes their actions later traceable. Both depend on reliable authentication. When all three are applied correctly (no action without authorization and accountability), the system is secure.

The book references the book Threat Modeling (Microsoft Press, 2004) by Frank Swiderski and Window Snyder and the works of Matt Blanc.

Regarding the section on threat-modelling and “gathering information” phase, I’m not convinced that much of the suggested information is actually useful. As Shostock points out, asset lists do not lead directly to vulnerabilities or mitigations - though I do believe a rough idea can be useful. Possibly “use scenarios” might be helpful in analyzing complex APIs offered by some components (particularly if the components do not document their APIs well). External entities and entrypoints are definitely useful - but should already be on the DFD.

I’m definitely not convinced that an “attack tree” offers much for security analysis. Yes, this is very much what an attacker would model. However it is a large amount of work to build a full attack tree. And to “expand” a node into its children, you need full knowledge of the entire system - which makes for workshops with lots of people (per/component allows more focused workshops). Picking the root nodes for attack trees can be difficult (a tree per identified asset is not very effective or complete); a simple DFD-driven per-component evaluation (STRIDE-per-component) has no such problem. The authors do make an interesting point that the tree can be evaluated together with the DFD, expanding nodes only with children that seem “applicable” to the system as defined by the DFD. I also like the AND/OR syntax in the attack tree. (or unless the parent/child lines are linked with a curve). A risk-register is basically a list of the leaf nodes of an attack tree.

The described DREAD approach to evaluating the “priority” of a risk has been generally dropped as too complex. Risk evaluation is still important, but should not be overcomplicated.

This book seems to assume that one person is “doing a review” - Shostock recommends instead that a team do it, and the team consist mostly of “project insiders”, with maybe one or two security experts added. This reduces the feeling that the team is “being personally evaluated”, ie makes it cooperative rather than combative. This also provides deep system knowledge, and (IMO) educates the team members at the same time.

The vast majority of chapter 14 is irrelevant for 99.99% of potential readers - very few people will audit a TCP network stack implementation. Some of the information is interesting for the structure/internals of TCP/IP networking - but not in a security context. Simlarly, chapter 15 is about firewalls - problems that can occur in the implementation rather than simply how to use them to protect another system. If you work for the NSA, CIA, Mossad, or similar organisations then you might be interested in this level of detail. If you are developing an operating system, you might also need this level of info. However the chances of finding anything in a modern networking stack are fairly low.

Ch 17-18 on web technologies are not bad, but a little generic. There are whole books dedicated to auditing servers-side web applications; I only skimmed this chapter but cannot imagine it adds much to the debate. Looks a lot at CGI and similar rather outdated technologies. Given it was published in 2007, that is no surprise.

Risk Centric Threat Modelling: Process for Attack Simulation and Threat Analysis

Details:

  • Authors: UcedaVelez, Morana
  • Publisher: Wiley
  • Published: 2015
  • Methodology: PASTA

Simply put: This book is rubbish.

Quick summary:

  • Lots of words, little useable content.
  • Chapters 1 through 5 are completely vague, a buzzword-filled word-cloud that do little except convey a sense that “security stuff is hard, and requires a process-heavy solution involving lots of consultants, lots of meetings, and lots of reports”.

The start of chapter 6 sums it up: PASTA is an approach whose results can be “socialized with senior executives”. This book seems to be aimed at people looking to set up a security team with broad responsibilities within a very large and bureaucratic organisation - exactly the target audience who do not need a book of this sort, as they should be properly qualified. Even then, a book so full of vague verbosity (and grammatic errors) is not helpful to any target audience.

The book frequently references military threat modelling, in which capabilities and motives of an adversary are analysed. However I am not convinced that there is much commonality between software and military threats. Schostock suggests this approach does not effectively lead to possible mitigations, which I find convincing. Software is a special case: it is stationary and passive (waits for attack), like a fortress. Software-based systems can generally also assume that the enemy has competence and reasonable computing power (both are cheap and plentiful for internet-based attackers); building an airforce can take time but a new software attack approach can come from nowhere. For specific vulnerabilities, a cost/benefit analysis can include an estimate of the motives/investment an attacker might apply after identifying the weakness (rather than considering it first).

The authors are obsessed with “thinking like an attacker”, including building collections of “attacker types” with made-up personal histories and motivations. Honestly, this sounds more like an introductory writing course for amateur crime novelists than a serious and financially-effective way to improve the security of an IT system. In the end, we don’t care what the motives or skillsets of attackers are - our goal is a system that is secure against all reasonable attacks.