Schneier on Security

Gweihir • March 8, 2013 9:15 PM

Sorry, but I have to disagree. This is a terrible, terrible book. It is a weakly structured jumble of things with no strong underlying approach. It is very weak on conceptual level and does not succeed to put things into a larger perspective. While Bruce’s books are shorter and have less material, they always try to refer the larger context, the methods and what is important with regard to each subject or example and why. And that are the really important things.

Sure, it is entertaining to read, but if you really want to learn approaches, techniques and what is important and what not, it wastes your time. Worse, it can make you think that just knowing a large number of disconnected facts makes you a security expert. If you are already a security expert, I would classify it as “harmless fun”. If not, stay away!

Yes, I own it and was hugely disappointed. A good friend that is also a security expert completely shares my opinion. Entertaining on detail level, worse than worthless on the meta level.

That is not to say Anderson’s work is bad in general. I find his scientific papers usually quite interesting. But this Book is a failure.

Gweihir • March 9, 2013 12:33 PM

@Nick P:

Thank you. I had my misgivings about posting my statement here.

I think I should clarify a bit more why I arrive at the “terrible”: This simply is not an engineering book. An engineering book always needs to teach engineering (i.e. constructive and pragmatic) approaches at constructing something in the field it deals with.

This requires several things:

1. A classification and structuring of the phenomena and problems encountered and how to identify the classes of new ones.
2. A classification and structuring of the solutions.
3. Teaching the relevant engineering methods and approaches.
4. Teaching the guiding principles for the field.

5. Teaching engineering and its principles in general.

All need to be present and done well. They can be taught explicitly (by structuring the work alongside them) or implicitly (by structuring the work around application areas and examples), but they must be taught. Item 5 is there because engineering cannot really be taught in the abstract. So any book about engineering needs to give at least a quick introduction to engineering approaches and principles.

That said, as an unstructured collection of relevant things in security, the book does succeed. It is just a total failure a teaching engineering in the field and the risk I see is that people wanting to learn security engineering get misled. In the best case, the book is a disappointment to them (with regard to teaching engineering). In worst case, they believe this actually is security engineering, and that systematic engineering approaches to the problem do not yet exist (which is really untrue, see for example Bruce’s works) and all things have to be approached experimentally, i.e. try to define your own engineering approach.

I have seem people do the latter in practice in many, many cases and even for projects were security was critical for the organizational survival. This typically fails badly. One example of a failure mode is that is results in overly complex solutions. What they miss is one of the core principles of all engineering, namely KISS. Any reasonable security engineering books will at some hard to miss point(s) say “a general engineering principle is KISS and it applies strongly to security engineering”.

Gweihir • March 11, 2013 8:58 AM

@Tim, Bobby:

If a book is called “Security Engineering”, my minimal expectation is that it is an engineering book (which this one is decidedly not) and about security (which it is, although not in a systematic way). So I do not think that my expectations are unreasonable at all and calling it “terrible” with regard to what the title promises is entirely adequate.

Gweihir • March 11, 2013 11:53 PM

@Ross:

Thanks for the comment. I completely agree about the nature of security, and I like the fox & hedgehog analogy. But there are parts of security that can be done in an engineering fashion, with rules, standard approaches, etc. Not like EE, but often more “fuzzy”, more like Software Engineering (which still has a long way to go and may never become a real engineering discipline). The important thing is hence to know the engineering approaches, know and understand their limits and have at least a good overview over the “fox” parts of the problem. For the latter, your book is pretty good. But if somebody sees it only as fox or only as hedgehog, they are severely limiting themselves.

I guess what it comes down to is this: I do not object to the book or its contents. I think the structure could be better, but I understand that with such a wealth of diverse material a strong structure could also lead to problems. What I really do object to is the title. If a book is called “Security Engineering”, I expect that it contains at least a strong focus on the engineering aspects that are known. If it does not, there is a strong risk of people thinking that there are no systematic engineering aspects in security, especially with such a reputed figure as yourself as the author.

While I do not work for a bank, I do security consulting for some. What I run in time and again, is people thinking security is all fox (and if these read your book and think all engineering aspects of security are covered in it, their conviction gets worse) and people thinking security is all hedgehog. The latter usually think compliance is everything and are irritated when we start to also evaluate the compliance criteria and telling them that they are flawed with regard to the project at hand. This sometimes goes so far that these people insist our approach is illegitimate, as the compliance rules of course ensure security in their limited world-view. I am sure you have ample experience with that mind-set.

I admit that I used hyperbole to make sure my comment did not get overlooked in all the glowing reviews. My apologies for that. I also know that when a book is the first or one of the first to attempt something, it is necessarily not optimal. That does not reduce the accomplishment.