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
• Applied Cryptography, Schneier, 1995(2nd ed)/2015(anniversary edition)
• Information Security Handbook, Death, 2017
• The Security Development Lifecycle, Howard/Lipner, Microsoft Press, 2006

Maybe

• Computer Security Fundamentals, Third Edition, Easton 2016

Don’t Bother

• Introduction to Computer Security, Bishop 2005
• Getting an Information Security Job for Dummies, Gregory 2015
• 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

• 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.

Applied Cryptography, 20th Anniversary Edition

• Author: Schneier
• Publisher: Wiley
• Published: 1995, 2015

This “Anniversary Edition” is a re-print of the second edition of this book from 1995, with a new introduction and a new foreword from the author but otherwise unchanged.

Despite the age of the content, the book does an excellent job of covering all the significant concepts in encryption, digital signatures, authentication, hashing, and other related topics. It thoroughly deserves the label “a classic” - and for its content as well as the political impact it made at its first publication. This book played an important part in moving cryptography from a secret-services topic to an academic one, for which I think we all should be grateful.

The author’s own foreword recommends “Cryptography Engineering, Schneier/Ferguson/Kohno, 2010” as a more up-to-date source of information; this book is sadly not currently available on safaribooksonline. However the original still holds up well. The only single topic I could see that was missing is blockchain; otherwise symmetric and asymmetric encryption, public key cryptography, PGP, etc are all covered.

The writing style is wonderfully readable, with complex concepts explained in plain language (as far as possible). Some of the content (particularly in chapters 10-20) is too detailed for the needs of most readers, but it is still worthwhile to skim the text and pick out the higher-level concepts.

I think every reader of this book will end up improving their knowledge of cryptology, whether almost-beginner or expert.

The book references this article which is an excellent summary of the real-world causes of it security problems. Sadly, the partially optimistic ending to the article has not come true - the article is from around 1993, but in my experience the same problems are still occurring in the current decade. It appears that applying good security practices are just not part of human nature or commercial interests.

There are also some classic quotes:

Key escrow has considerable disadvantages. The user has to trust the escrow agents’ security procedures, as well as the integrity of the people involved. He has to trust the escrow agents not to change their policies, the government not to change its laws, and those with lawful authority to get his keys to do so lawfully and responsibly. Imagine a major terrorist attack in New York; what sorts of limits on the police would be thrown aside in the aftermath? (from 1995; sadly prescient)

Computerized voting will never be used for general elections unless there is a protocol that both maintains individual privacy and prevents cheating. (from 1995; sadly too optimistic)

If companies do not feel that their interests are served by making their algorithms public, it is best to assume they’re right and avoid the algorithm.

Alice is the chief financial officer at Secrets, Ltd.—“We don’t tell you our motto.”

I have some additional notes in this extended review which might (or might not) be useful.

Information Security Handbook

• Author: Death, Darren
• Publisher: Packt
• Published: 2017

I found this to be 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 have some additional notes in this extended review which might (or might not) be useful.

The Security Development Lifecycle

• Authors: Howard/Lipton
• Publisher: Microsoft Press
• Published: 2006

This book is available as a free download from Microsoft.

Despite the age of this book, it has a lot of very good and still-relevant content. It contains a mix of management details and more technical aspects - ie relevant from board and CISO down to solution and system architect level. The book is most relevant to companies developing software packages for sale to customers, but content should also be relevant to open-source projects and company-internal projects.

The authors emphasis threat modelling using basically the same methodology recommended by Shostock (see review above) - no surpise as Shostock is basically documenting best practices within Microsoft.

Other points that I found particularly interesting are noted below..

One significant part of the SDL is setting up regular education courses for developers. Topics include:

• Basics of secure design
  • attack surface reduction
  • defense in depth
  • least privilege
  • secure defaults
• Threat Modeling
  • Designing to Threat Model
  • Coding to Threat Model
  • Testing to a Threat Model
• Intro to Fuzz Testing
• Secure Coding Best Practices
  • Buffer Overruns
  • Cross-Site scripting
  • SQL Injection
  • Weak Cryptography
  • Directory Traversal
  • Race Condition
  • Weak Authentication
  • Weak Authorization
  • Ineffective Secret Hiding
  • Resource Consumption (DoS)
• Security Tools Overview
• Performing Security Code Reviews
• Data Privacy

One aspect the book recommends for improving security is reducing the amount of code/features that an attacker has access to. The attack-service-reduction flow (page 80) recommends asking the following questions for each feature in the product:

• is this feature required by most users? No => disable (or don’t install) the feature by default
• can feature be split into sub-features? Are all of those features used by most users? No => disable infrequently-used subfeatures by default
• does feature need to be remotely accessible? No => restrict to local subnet or local machine
• does feature need to be accessible to anonymous users? No => restrict to users with appropriate role
• does feature need to run with privileges of calling code? No => run with reduced privileges

Chapter 9 parts 7 and 8 on threat modelling suggests first identifying all threats and making a list, and then later evaluating each threat. I’m not convinced here - that seems to be an unnecessary amount of paperwork. Whether there is a vulnerability or not is very context-sensitive, but that context info cannot be included in that list. That means the team must examine the context, then move on to something else, then come back again and remember what they were previously thinking about. Why not evaluate each threat as it is identified?

Chapter 18 makes some nice points about security in an Agile development process. Chapter 22 provides good information on threat modeling - examples of threats of various types.

Computer Security Fundamentals

• Author: Easttom
• Publisher: Pearson Education
• Published: 2016

The word “Fundamentals” in the title is correct - this discussion of security does not assume much previous IT knowledge. The audience appears to be people working in the IT industry, and who are willing to read some moderately complex explanations. This book is probably most useful for a junior MS-windows network or system administrator. Maybe help-desk staff, or IT managers without tech background. High-school or first-year-uni IT students perhaps. Junior software developers if they have not had good previous IT training.

General computer users (management, general office workers) will probably not be interested in the technical background presented, and senior IT Professionals should be expected to know everything in this book already.

The content is ms-windows-centric, US-centric and mostly covers desktop and networking topics along with some IT policy recommendations. How to do secure software development is not addressed.

Some of the “general background on cyber crimes” is overly long and overly dramatic; otherwise the writing style is unfortunately dull and boring. And despite the “third edition, 2016” some of the content feels out-dated. Hubs. Yahoo. Hmm… Nevertheless, it does a reasonable job of covering fundamental concepts for the target audience listed above.

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.

Getting an Information Security Job for Dummies

Details:

• Authors: Gregory
• Publisher: For Dummies
• Published: 2015

An odd book - not quite sure who the target audience for it is. Primarily, this is a book-of-lists: lists of different roles in “itsec”, lists of qualifications that you might need, lists of different types of security problems, lists of different sources of further information. As made clear in the content, a job in information security is not for beginners - you need significant technical knowledge before even considering being responsible for security decisions. Which makes the inclusion of basic content such as “what is a virus” and “how to write a CV” somewhat puzzling.

As a brief overview of the whole “itsec” industry, it is acceptable - nicely written prose, and concise. But rather shallow.

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.