My only negative comment would be that it got a little slow at the end, for me. Maybe I was just tired that night or something.
He cites a few excellent examples of places or instances where someone did something that they honestly felt would contribute to increased security, when the actual effect turned out to be the opposite. If I may draw a crude comparison: if you appreciated some of the observations, and perhaps even the writing style and presentation in Hammer and Champy's "Reengineering the Corporation", then you will like and appreciate this volume. The way Mr. Schneier presents information, and the way he introduces you to perceived vs. actual may strike you as being similar. (No offense meant to either author - I enjoyed both)
Happy trails.
1. What assets are you trying to protect? 2. What are the risks to these assets? 3. How well does the security system mitigate those risks? 4. What other risks does the security system cause? 5. What costs and trade-offs does the security solution impose?
In the process, Schneier provides many interesting examples. This is an excellent book on security for the layman. But it is definitely a book targeted at a popular audience. There are no footnotes or references, and Schneier occasionally tosses off remarks or asides that are questionable, if not false.
There are two significant flaws in the book:
1. It exaggerates the subjectivity of a security evaluation. On p. 17, chapter two is titled "Security Trade-offs are Subjective." But it's not the trade-off itself that is subjective. It's not the risk assessment that is subjective. It is people's non-instrumental desires (basic desires) orvalues that are subjective.
Schneier writes (p. 17) that "Different people have different senses of what constitutes a threat"--but some are right and some are wrong. His distinction between perceived and actual risk shows that the important one is actual risk, not perceived risk. Actual risk is objective, not subjective. Schneier continues "or what level of risk is acceptable." That can certainly have a subjective component, but even subjective components can conflict with each other and be internally inconsistent, indicating a problem in the evaluation.
The final sentence of the chapter contradicts the chapter title: "Because we do not understand the risks, we make bad security trade-offs." (p. 31) If the trade-offs were subjective, there would be no such thing as a bad trade-off, only a trade-off perceived to be bad by someone.
Later in the book Schneier contradicts the strong subjectivity claim (e.g., p. 249: "Massive surveillance systems are *never* worth it." (emphasis added)) I don't think he seriously meant to make the strong claim--I think it's just careless/imprecise writing. p. 259 seems to get it pretty much right, but he should really have found a philosopher to review this book--that a problem is intractable doesn't mean that the answer is subjective, nor does the fact that subjective interests enter into the picture mean that the answer, given those interests, is subjective.
2. The book argues for an exaggerated egalitarianism--that anybody, regardless of background, training, or intelligence, can do security analysis. At the same time, the book touches on some of the evidence that ordinary judgments are inaccurate, and that people are notoriously bad at estimating and comparing risks due to the natural use of heuristics like vividness, recency, etc. (the classic Kahnemann and Tversy book, _Judgment Under Uncertainty_, summarizes some of this evidence). It would be grossly mistaken to think that Joe Schmoe off the street is going to be capable of designing (or evaluating) the effectiveness of a complex security system, versus people with appropriate training and experience--just as mistaken as hiring people with no computer knowledge to build and maintain your IT infrastructure. Again, like in point 1, Schneier says things which contradict the strong hypothesis he seems to argue for, for example when he writes that wealthy people want doctors who treat others, not just standing by on 24/7 on-call for those wealthy people, because they want doctors who are experienced. And I think this is a good comparison--the position Schneier *should* be arguing for is that we should take responsibility for our own security in the same way that we should take responsibility for our own health. We still need to rely on experts, but we should take an active role in consulting with them and evaluating what they tell us, especially since (just as in health care and medicine) there are people who know what they are talking about and those who are snake oil salesmen.
In the information security field, "risk" and "vulnerability" have roughly the same meanings that you use. However, "threat" means something more like "a method of exploiting a vulnerability or combination of vulnerabilities to cause a loss", while what you call a "threat" is an abstraction called an opponent or adversary. When we talk about "threat analysis", we mean examining ways vulnerabilities can be combined and exploited and what kinds of losses they can cause; these analyses may then be used as inputs to a risk analysis model. In the lunch room example you cited, the threat is "casually saunter up to the fridge, glance around, take a lunch, scurry away", and would be characterised as "low cost, low skill, low risk of discovery". The threat is indeed the same whether or not there is an opponent to exploit it. Opponents, in turn, are fairly abstractly characterised, something like:C "local hobo who notices the smokers propping open the lunch room door"B "hungry intern on low wage"A "corporate saboteur spiking the CFO's salad at the AGM"
What your intel and law enforcement types call a "threat analysis" simply isn't terribly relevant in the IT security field; we are mostly civilian corporate employees, with neither the right nor capability to compile dossiers on *specific* "opponents". We do compile information about what kind of attacks have actually been occuring; we call that the "CERT Summary"!
It is true, as Schneier says, that "threat analysis" and "risk analysis" are often confused in IT security - due in large part to the non-IT security world merging both concepts into their risk analyses. But in our field it is much better to keep them separate. A threat analysis is a more abstract (and hence generally applicable) study, while a risk analysis depends on a particular business model. For example, if we store Almas caviar in the fridge instead of salami, the threat analysis is the same, but the risk analysis will be considerably different; all the wierdo threats that were low risk before (e.g. masked men with shotguns storming the fridge) become realistic. This separation is useful when identical reusable software components may be employed by thousands of very different businesses.
So, I while I found your comments very interesting, I think the semantic difference is just a difference, not an error.
