Slashdot Log In
Secrets & Lies: Digital Security In A Networked World
from the learn-the-defense-and-offense dept.
| Secrets & Lies: Digital Security in a Networked World | |
| author | Bruce Schneier |
| pages | 412 |
| publisher | Johy Wiley & Sons, 09/2000 |
| rating | 10 |
| reviewer | Jeff "hemos" Bates |
| ISBN | 0471253111 |
| summary | A well written, well researched exploration of digital security as a system. |
I've recently had the pleasure of reading Bruce Schneier's latest writing effort Secrets and Lies: Digital Security in a Networked World. A number of our readers may remember his prior book Applied Cryptography , which discussed the use of cryptography in our brave new digital world, and how the use of crytography would make things secure.
This time around, Schneier is much more cicumspect about the uses and application of cryptography. As he states in the introduction and throughout the book, when writing AC, he thought that the use of cryptography would make things more secure. He was correct - but the lesson he learned while working with companies and individuals, that we can't just add cryptography into a system and make it secure, but that systems must be designed from the bottom-up with security in mind. S&L draws upon a huge amount of experience working in the security field, making one central point: Any system, no matter how good the cryptography is, is only as strong as the weakest link. Yes, that's an old cliche, but it's one that bears repeating.
What makes it even more imperative to design system to be secure is the sheer amount of systems that aren't secure, and what the means for us. Some of the examples Schneier uses in S&L are simply frightening to consider were they to occur. And some of his ideas about what will come, and the tools we have will make you want to keep a good stash of gold kruggerands under your mattress.
Indeed, as he talks about in the introduction, part of the reason this book too so long to write was because he was depressed at the world of security around him. Looking at what companies were doing, at what people were doing, and the sheer amount of systems holes out there must be depressing - but it only drives home the point even moreso that we must design *systems* not just adding cryptography and thinking that's the magic pixie dust that can make everything better.
The book does an exceptional job of wending its way through various security measures, how they work, and how they fail. IMHO, one of the real strengths of this book is that it's something that a cryptography novice could read, as well as an expert. Certain sections of the book are dedicated to the nitty gritty behind systems, but there are also sections that are dedicated to simply laying out the process by which one should approach the systems. Indeed, the support blurb on the dust jacket is written by Jay S. Walk, the founder of priceline.com. This adds to the strength of the claim that the book can be for everyone.
Schneier is intimately involved with the security community - besides being the creater of the [Blowfish] and [Twofish] encryption algorithms and a frequent speaker at technical conferences, his company deals with this day in and day out. More to the point for a book, he can also write. It makes reading about Product Testing and Verification (Chapter 22) rather than a snooze, a treat. The book is one of those rare cross-overs - something to give your geek friends, and your [PHB], all of whom will appreciate it. The breadth of the book is revealed in the contents (Duh) and it's a good mixture of all the necessary elements. You'll learn about entropy in a system as well as Attack Trees, Threat Modeling and what all of this stuff means in day-to-day life.
I wholeheartedly recommend this book.
The Table of Contents and the preface are available on Counterpane's site; S&L's Chapter Three is on Amazon.
Purchase this book at ThinkGeek.
Re:However ... (Score:3)
Why do you assume most geeks know this kind of thing well? I know several geeks and all of them know little about cryptology. As long as it works they're happy and they continue on with what ever they're pet project is. It never hurts to review the material.
As for grok I wouldn't consider that just a geek word. My parents know it (sure they don't use it but they know it) and they do not read science fiction at all. Sometimes you would be suprised at what you think is a word or concept non-geeks don't get that they do understand.
Re:Product placement ad? (Score:3)
Cheaper at buy.com (Score:3)
~Sean
Face it. (Score:3)
The only sure-fire way to make a system secure is to remove every input (KBD, Mouse, Serial, Network, Parallel, USB, etc.) port from a system.
kwsNI
Re:Security isn't important (Score:4)
It's biggest success has been in that Russia and the US haven't nuked themselves to oblivion and back. Yet.
However, it's failed abysmally in just about every other sector of life. Tough jail sentances, guns, the death penalty, etc, have usually attracted more crime because they delude people into feeling safer than they are (thus reducing any REAL defence) and increasing potential rewards (due to rewards often being proportional to risk).
No. The best defence is NOT deterence. Even a pitbull can be distracted, fed, drugged, trapped, etc. The best defence is to stop making pointless assumptions.
In computing, true security comes when you can say (HONESTLY) that your server box is untrusted, your client box is untrusted, your network is untrusted and you can STILL store and move data securely.
Security isn't about stopping someone getting in. Someone can ALWAYS get in, if they try hard enough. Security is about knowing that once that somebody -DOES- get in, they can do nothing with or to your data that isn't possible by anyone outside the machine, anyway.
A locked door is no guard, and an alarm can always be bypassed. If you put your valuables in plain sight and easy reach, the best deterence in the world can only buy you time, not security.
"Security is only as strong as its weakest link" (Score:4)
Though I believe there is a lot of truth to that statement, I've also seen it applied to an extent that it hurts overall security. Generally speaking, this world is not nearly so simple. Where systems break, it generally involves a failure on multiple levels. For instance, look at the numerous social engineering scams. Rarely is it just ONE person that broke the entire security, but rather a bunch of different people within the target organization being too careless with information. All those careless bits, in turn, interplayed with one another and allowed the crackers to build up the key to access the desired information. The point is that if each person were just twice as aware as they were before, that could go a long long ways in preventing hackings. The same goes for the vast majority of the hacking incidents. Rarely are they some strike of genius on the part of the hacker, seeing things that no one has seen before. Instead they're previously documented things that could've been avoided with reasonable effort.
I sincerely believe that effective security is attainable, provided enough effort is put into it, even though one may never be 100% theoretically secure. That is to say that if all the key players involved simply payed more attention to security, actual instances of hacking secured sites would be rare. Let's say we have two major layers of security. Each layer had 50 trained professionals go over it for all known bugs, and for anything theoretical they can provide. Assuming the organization keeps up to date on emerging threats, and monitors its security system, and if the source and specific specs on the protocol are closed, the odds of a hacker DISCOVERING two bugs in both layers that none of the pros saw is quite slim [about as good as a gaurantee as you can get in life anyways].
Unfortunately, the only standard that most people have to compare it with is nothing even approaching that. For instance, almost every single operating systems (yes, there are one or two exceptions), including the linux distros, have shipped with well known exploitable bugs. They may not have known there is that specific bug in that specific package/module/whatever, but if they had really double checked for existing bugs, it'd never have shipped like that. Likewise for most of these hacking incidents. They're well documented techniques simply being reapplied. There is simply no excuse for it. One may not be able to gaurantee that no bugs exist, but they can certainly gaurantee that certain conditions don't exist.
/END RANT
Also recommend: Information Warfare and Security (Score:4)
Social Engineering (Score:5)
I just finished reading this... (Score:5)
An interesting thing about the book is the contrast between two concepts that may seem contradictory at first: Security is only as strong as it's weakest link, but layered security can result in stronger security than any one part.
It's like the difference between logical AND and logical OR. You want to build security systems where to break it, an attacker would have to break through a firewall AND steal a password AND get root access from user access AND evade the network monitoring system, etc. This is security in depth - stronger than any one link.
Unfortunately, most systems are designed as logical OR: To break the security, the attacker just needs to penetrate the firewall OR steal a password OR buffer-overflow a CGI script, etc. This is "weakest link" security.
Other things that stuck in my mind from the first reading: No matter how strong you build it, someone will eventually break it. So design it for easy recovery. The CSS system on DVD's is an excellent example for this - now that it's been broken, there is no good way for the DVD manufacturers to recover. They can't change the encryption system without breaking compatibility... (The CSS/deCSS system is actually used as an example several times throughout the book).
I highly recommend this book. I'll probably reread my copy several times.
Torrey Hoffman (Azog)
Always know your sources (Score:5)
Personally, I think Bruce is an upright guy, and that what's happening here is that at each point in time he both writes about and works to address the problem he actually believes in. But it always pays to pay attention to the potential biases of your sources.
Risk and the Blame Game (Score:5)
Of course, it takes more than a thick skin to deal with this environment. You're diametrically opposing developers - you want things secure, they want things to work (the inverse relationship of functionality vs. security). The trap here is becoming this big obstical that developers have to figure a way around to get "real work" done. We avoid that.
In our environment, information security advises on projects. When we note an insecurity, we bring it to the developer's attention and help figure out more secure alternatives. If the developer wishes to push an insecure solution, they need to get management to assume the risk presented.
This process does a few amazing things. The first thing is it makes security a part of everyone's interest - not just the information security department. The developer has to honestly look at the situation and create a strong enough business case to justify the risk to the manager assuming that risk. The management (in CYA mode) is going to look at this business case very closely before accepting it. If the risk is justified, it gets accepted. If not, the developer is forced to seek out a more secure method and security isn't the Bad Guy impeding progress.
The only caveat to this is the company's culture. Accountability and a reasonable understanding of a risk's scope is required. Some insecure, but acceptable, decissions will pass (read: risk management). Its crucial that information security's recommendations are well laid out, understood, and valued by management. Alas, that's not always the case.
The real warning (Score:5)
As Schneier points out at one point in the book, the real problem is commitment to security. The odd high-profile Web site defacement or DB-of-card-numbers theft gets security onto the agenda inside companies, and the edict comes from the business to "guarantee security, whatever the cost" as the usual ill-informed media tsunami breaks all over the Web.
But there is always the assumption that "cost" means a dollar (pound, mark, whatever) figure. It certainly costs money to do it right, but the real cost is in changing working practices, restricting timescales, guaranteeing proper code audits before deployment and so on. These are the costs that the business is rarely -- if ever -- willing to bear for more than a few fleeting moments. The day you walk into the Big New Project meeting and say "We can't deliver this on time because we need to do a security audit" is the day security gets ignored once more.
And the real motto? It's tough to be on the technical end, because even if your advice is ignored, you can bet your head is on the line for the mistakes.