Slashdot Mirror
Secrets & Lies: Digital Security In A Networked World
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.
Sometime the best away to around security is the people who secure the system. I have gotten password with out any kind of verfication. You cannot your system without training your people first on how to secure your system.
I was very impressed. It's interesting reading, not extremely technical, and has lots of good tips on how to think about building secure systems. There's not much detail on any particular system - that's not the focus of the book. Since it focuses more on concepts and less on specifics, it will remain relevant for a long time, compared to "Securing Red Hat Linux 6.0" which is already out of date.
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)
Torrey Hoffman (Azog)
"HTML needs a rant tag" - Alan Cox
It's probably worth pointing out that when Schneier wrote Applied Cryptography, which pushed crypto as the solution to security problems, he was making his living as a crypto consultant. Now he publishes Secrets & Lies, which says there is no security and the only comfort is in eternal vigilance, he's making his living running a company that sells monitoring services.
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.
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.
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.