Schneier on Security
A blog covering security and security technology.
« Oxford University Blocks Google Docs |
| Friday Squid Blogging: Squid/Whale Yin-Yang »
March 8, 2013
Ross Anderson's Security Engineering Online
The second edition of Ross Anderson's fantastic book, Security Engineering, is now free online. Required reading for any security engineer.
Posted on March 8, 2013 at 12:08 PM
• 15 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
brilliant book. been reading it for about s week. quite a number of discussions and contentious issues covered in this blog are discussed. i particularly noted an example of screen capture malware. it is already happening.
Wow...after I bought the hardcopy.
Awesome! There are few good resources on security engineering. I'm glad he makes this series free after a while. The first one was helpful long after it was free. I'm sure the second one will be the same.
@ Bruce Schneier
From Ross Anderson's Chapter 26:
"even years and 25,000 copies later, readers had reported 99 errors (and
I’d found a handful more myself while writing the second edition). Most were
typos: the sixteen errors of substance discovered so far include... two cryptographers’
names wrong (Bruce Schneier, who wrote the foreword, miraculously became
A nice little laugh for me. Maybe he slipped and said what he really thought of you. ;)
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.
"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."
I mostly agree with that. When I read the first edition, I thought it was many different fragments thrown together from a number of subsections of security engineering. However, the content gave plenty of useful advice that I didn't see in many other often referenced books.
Another thing missing from many detailed, how-to type books is good examples. I mean, they'll usually have a few anecdotes but this book has more in number and quality of analysis. It also covers issues such as emanation security that many books neglect. (I still regularly meet people in security that have never heard of TEMPEST or power analysis.)
It's certainly not the book to end all others. It still has value and being free makes the value equation even better.
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".
Just because it doesn't fit your expectations doesn't mean it is terrible. I thought it was an excellent book. Inspired me to crack my college's laundry system and get free washing for a year! (Somewhat going against the "Should this book exist?" section!)
I find this an excellent book. I don't see it as a guide or text book, but more as a treatise on Seceng issues, esp how they brake. It is up to you to dig deeper to learn the complete working of security and related protocols. I do not think the intention of the text was to create security engineers, but to engage them.
I have only read a limited amount of this book so do not feel qualified to comment yet other than to say what I have read was interesting and thought provoking.
@Gweihir I find your criticism interesting and I am wondering which books you would recommend, perhaps not in SecEng but in other fields, that do meet your requirements for an engineering text.
@ David Scott,
Wow...after I bought the hardcopy
But think a little, the hard copy is worth it's weight in...
applying to the heads and other parts of the anatomy of supposed "engineers" untill they finally start to walk the path of wisdom ;)
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
A little harsh.
I remember when the first book came out, I read it and thought there was a lot missing but not in the way you have.
The problem I saw then was each of the chapters would need a book or two in their own right to cover in a reasonable depth. It was a problem I came up against almost immediately when other engineers without the appropriate background started asking me to explain what was involved.
For instance take a look at all the books on EMC engineering, this is but one fraction of what you need to know at a very indepth level when it comes to EmSec which is in turn but a small fraction of SecEng.
Then what about encapsulation, this again is a very indepth subject but it is very very diverse in nature and there is little about what is involved in a collected engineering format. For instance can you tell me which encapsulants I should and should not use with FR4 and why? Or how about loading them with quartz or carbide etc and what effect that has.
How about security seals and the different printing techniques behind them? there is actually very little written about this, most like "lockpicking secrets" is kept in the heads of practitioners and clasified government documents.
I have well over 130 books within my "dead tree cave" extensive collection of engineering books that cover only parts of what you would need to know from the physical and electronic side. Some of these books (such as "Soft Ferrites" or "Radio Frequency Transistors: Principles and Practical Applications") are long out of print and now rarer than "hens teeth" and you'ld be lucky to find them in any but a handfull of Universities. Other information is tucked away in Application Notes of semiconductor devices that came from companies that nolonger exist.
As a work the book stands by it's self and is a very worthy one when it comes to the usable information content to number of pages .
In effect it is a leader book, in that it is the first of it's kind and will almost certainly be refrenced by the majority of books that follow it.
 Most engineering books are 1/10th real information the other 9/10ths being effectivly explanitory padding. This is generaly a requirment of the publishers not the authors, because the publisher wants to cover a sufficiently wide audiance to cover costs and make a profit.
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.
The late Isiah Berlin talked about the fox and the hedgehog: the fox knows many little things, while the hedgehog knows one big thing.
Many people have tried to make security a "hedgehog" subject: if only we could have perfect crypto / multilevel security / certification / whatever, then all would be well.
Gweihir, I understand your viewpoint all too well; as a young man with a maths degree working for a bank, I was there. You want to reduce everything to a few rules you can explain to your boss, plus stuff you can prove is consistent with that. But experience teaches that the world is complex. Security engineering isn't electrical engineering; you can't reduce it to Maxwell's equations. You need many more mathematical tools: the crypto, the protocols, the information flow models, the game theory and maybe the emsec too. And then there's the human factors. Security is a fox subject, and getting more so
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.
Schneier.com is a personal website. Opinions expressed are not necessarily those of BT.