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.
This is old news and most people with an active interest in security are yawning by that point. Secrets & Lies isn't aimed at security professionals - it's aimed at everyone else using the Internet. Most people don't know that terms like "128-bit encryption", "SSL" or "firewall" mean absolutely nothing on their own. This book does a wonderful job of debunking a number of security myths.
I'm strongly opposed to the idea of requiring any sort license to use the internet. I still found myself thinking that one redeeming value of a licensed Internet would that people could be required to read this book. Most people are entirely too cavalier about security, largely because they don't know any better.
we literally cannot conceive of something which is entirely self-sustaining
hmmm... What about those blown glass spheres that contain a complete balanced biosphere? They've got like little shrimp and plants and water and air in them... no holes.
"Free your mind and your ass will follow"
You don't think this is already happening? See, e.g., Kevin Mitnick.
#include "disclaim.h"
"All the best people in life seem to like LINUX." - Steve Wozniak
#include "disclaim.h"
"All the best people in life seem to like LINUX." - Steve Wozniak
I wonder how much flak this and the previous article will get from people accusing Bruce Schneier of selling out and becoming a marketdroid. However, to me his "conversion" sounds sincere - a real crisis of conscience, leading to depression and then a breakthrough. (Believe me, I know from depression....) Besides, why shouldn't he literally his money where is mouth is, and try to run this "managed security" idea as a business? If he's wrong, then his clients will suffer, but at least his ideas will be tested in the real world, rather than just debated endlessly in academic circles.
#include "disclaim.h"
"All the best people in life seem to like LINUX." - Steve Wozniak
#include "disclaim.h"
"All the best people in life seem to like LINUX." - Steve Wozniak
So I suppose if I catch you touching the handle of my car door as you pass by it on the street, we should lock you up on felony charges?
I don't get Americans like you. First you run around screaming "theyerawtabealaw" every time you perceive a problem, and next thing you know, you're screaming about the gubermint on your back.
Real democracy is hard, and it means spending a lot of time working for solutions outside the system, not radically curtailing freedom. Go live in a police state if you don't like it, but don't ruin my country.
Boss of nothin. Big deal.
Son, go get daddy's hard plastic eyes.
Expanding a vast wasteland since 1996.
I resent that comment. I'm Canadian, not USian.
You make the very assumption that you say is a bad one -- you trust that the algorithms you are employing are secure, and more, that the implementations you are using them with are secure.
On top of that, if somebody can always get in, they can always hunt you down and apply rubber hose cryptanalysis. They can do that even without breaking into your machine, and there's not much you can do if an attacker is that determined.
At some point, it comes down to actually having to trust something. Do you trust that your client has not been compromised with a program that will pass any cleartext it sees on to your competitor (or the Mafia, or the government)? Do you trust that your network will deliver a reasonable fraction of the packets you send out? Do you trust that your encryption and authentication are difficult to defeat?
This isn't very surprising, either; you just usually don't think much about trust issues in the real world, because anonymity in the real world is much harder to attain. Do you trust the guy across the street not to pull out an Uzi and try to mow you down? Most people do, because there are generally compelling deterrences against that (based primarily on the ease of being identified and the difficulty of leaving the scene without leaving indentifiable traces). Some people don't, so they either stay inside or only go out in the company of bodyguards. It's a decision that must be made on a case-by-case basis, even if you don't often think about making that choice.
So one of the real tricks in the online world is finding the right balance between anonymity and identification -- some balance point that protects both the victims and the victimized. This is not the only tricky thing about online security; actual bug-free (or security bug-free) code is at least as important, and the code cannot have any more security than the protocol.
Most of the IP-based protocols used in the world today ignore all of these in favor of features and glitz, because they're driven by commercial decision processes, but there's always hope that newer protocols will be adopted and that they will supplant the insecure protocols that come out first. (For more on that, I refer the reader to the classic "Worse Is Better" paper.)
This is just one of the many revelations and insights Bruce has to offer in this very well written book. I learned about threat trees, the true nature of the security landscape, ... and so much more it's amazing.
Buy it, read it, twice. (I'm about to start again)
--Mike--
Bruce spoke on a couple of panels at Chicon. I hope he'll forgive me, but I am reconstructing this from somewhat sleep deprived memories. He was quite frank about the fact that when he wrote Applied Cryptography, he believed that the proper use of cryptography could provide security. He said that his actual observations since then have convinced him that it is not possible for humans to use a system and for it to remain completely secure. The limits on human memory for pass phrases and the need for access to the secured data are two of the biggest problems. Although I don't remember him saying it outright, another is the limits to individuals' ability to stay up-to-date is another.
The net will not be what we demand, but what we make it. Build it well.
Here is my rather long (and negative) review of Schneier's book. For those unwilling to wade through it, my key point is that being a good mathimatician doesn't necessarilly qualify one to be a good programmer. He truely doesn't understand programming and hence doesn't believe that a single secure piece of software could ever be written.
After writing a wonderful book on Applied Cryptography, Bruce Schneier lost his faith in mathematics. This loss of faith came from looking at truly applied cryptography, namely looking at actual source code. This code so scared him that he wrote a book saying that cryptography is not The Answer(tm). I beg to differ.
He thinks real code should scare you so much that you should hire his company on continuously monitor your computer. Not a onetime vetting -- you should pay him every day for the rest of eternity. Not a bad racket.
The key points he makes are as follows:
- There are about 5 - 15 bugs per 1000 lines of code.
- Software has been doubling in complexity and size every year or two.
- Windows NT has 35 - 60 million lines of code and hence about 100k
bugs.
- Therefore no modern product will every actually be secure.
Modern software will generate new bugs at a faster rate than even the "many-eyeballs" of open source can squash them.But code doesn't have to be written this way. You can put all of your risky code in a small enough package that it could be checked for errors. The word kernel comes to mind. :-)
But, he also says that Linux suffers the same problem that MS has.
Unfortunately, I don't know the kernel well enough to comment on how
much it has grown and he doesn't provide data on the growth of Unix
kernels. Somehow I think this absence of information might reflect
the fact that the current Linux kernel is not 1000 times bigger than say a
Solaris kernel of the early 80s.
But under Linux, is even counting the lines of code a good measure? Somehow I think the kernel is modular enough so that if I load a new PCMCIA module, it wouldn't automatically be given rights to read and write to arbitrary files on the system. Please correct me if I'm wrong, and I'll sleep much less well at night. So not all the code in the kernel should be counted as being the same.
I would be much happier with his analysis if he had looked at contrasts between sendmail (which is notoriously buggy) and qmail (which doesn't appear to be as buggy). The software point is that the dangerous code in qmail is all in one program--and that program doesn't trust any of the other pieces that make up qmail. So if that part is actually programmed bug-free, then there shouldn't be ANY possible bug in the rest of the code that can undermine security. This is good design. Almost any line of the sendmail program could undermine the security of the system. This is a truly a monolithically bad design.
To list another example, almost all of current open source pgp (namely gpg and its supporting material) uses gpg for the actual encryption and some other program for the viewing. So no matter how stupid the viewing program is, it is impossible for it to undermine security. (OK, it could send a copy of the plain text after it sends a copy of the encrypted message--but that would be a easy bug to catch.)
Even viruses like the ILOVEYOU worm in a hopelessly insecure operating system should be fairly easy to avoid. If you simply had Visual Basic always run in something equivalent to a change-rooted environment, it would have been impossible to write such a virus. Whether this could be done in windoz isn't the issue--instead the point is that people have known about this sort of problem for years and there has been a simple fix for years.
In his defense, he does seem to spend most of his time working in the MS world. That he worries about someone running a game server on their machine without having vetted all of the code would be a very rational worry in MS. But, there are ways this could be done under Linux that would maintain total security of the machine it ran on without looking at even one line of source code (run the program as a regular user in a chroot environment sounds safe to me).
So I see the picture something like this.
- Cryptography is not a solution to all problems:
- Digital cash probably won't catch on.
- Smart cards probably won't ever work.
- All the fancy algorithms for voting and sharing information
will never replace the voting booth.
- Playing poker will probably use a trusted intermediary instead
of a cryptographic protocol.
- Cryptography can solve some things: SSH, GPG and VPNs all work.
- But, the key reason a system will be cracked into is not new
mathematics but bad coding.
- There are ways of coding (see Lakos for many good ideas) that
will lead to secure programs.
- Users will always be a weak link, but a good system (say Linux)
should only compromise what that user had access to and not the whole
network.
ConclusionSchneier is incorrect when he says that security is a process. Instead, security is a solvable software engineering problem. In fact, I think a few small pieces of it have actually been solved. I think mail handling has been solved (qmail) and telnet has been solved (ssh2 with public/private keys). Certainly serving static web pages is solved (apache).
Keeping users from getting the root access should be a solvable problem, but I don't know if it is currently solved or not on Linux systems. Once that is solved, serving CGI scripts, running arbitrary servers, downloading arbitrary code off the net and running it on your local machine should all be safe things to do. (Now I don't think the automatic updates to GNOME is going to pass security muster anytime soon.)
So let me make a statement that most clearly separates Schneier's position from my own. Consider the following two systems:
-
A Linux system running ssh2 and qmail that is never patched. Total
passive management. (Of course the ssh2 would require public
key/private key pairs instead of passwords.)
- An NT system (or whatever is the latest and greatest MS
product) that has an active administrator who installs all MS patches
within 24 hours of their release and upgrades to the newest version
whenever it comes out.
Which do you think has a higher chance of being secure over the next few years? Schneier argues that active management is the only way of providing reasonable security, so my strawman version of him would pick the NT system. I think the Linux machine would probably be safe for 10 years. (I'd go longer, but don't trust the key length of ssh2 to protect against all new mathematics and hardware past about 10 years.)If you went with NT, read Schneier's book. He will give you good arguments to believe that active management is the only answer. If you went with a limited Linux system, then join the open software movement and see if we can add more features to the Linux box without compromising security.
Quite opposite of what you thought I meant, I think that the first step to improving digital security is to become more proactive than reactive to security.
The point my above post was trying to convey is that we're currently content to say I've secured my system against all know attacks. So what? Sometime down the road their will be a new hack out there and your system is going to be vulnerable. Too often, I've seen people like this. Security is an ongoing process that will never be complete.
I never said we shouldn't try to make better security. I just meant to imply that we will always find a way around security. Take DeCSS for example. The MPAA convinced all the movie studies that CSS was uncrackable, that's why they adapted it as the standard for DVD. Now look at it. The MPAA is spending billions in a losing battle to prevent people from decrypting it.
Never get sucked into believing that security makes your system secure. There will always be talented people out there putting in the effort to prove you wrong.
kwsNI
"one treats others with courtesy not because they are gentlemen or gentlewomen, but because you are" --G. Henrichs
That being said, there are some nits I have to pick. I disagree that the book is "well researched." The important stuff is all obviously drawn from his own experience (obviously extensive) as a security consultant, supplemented with various anecdotes from the web, journals, etc. A useful knowledge base, but not that impressive researchwise.
This is aggravated by Schneier's use of non-technical examples and analogies in many of his arguments. The arguments themselves are very strong, but when he cites this historical example or that financial practice, he often gets his facts wrong. I don't suppose this has a big effect on his credibility, but it must have some.
It's also a little disappointing that Schneier didn't bother to get into the general history of the Engima/Ultra business -- a prime example of his basic theme, that the smallest failure of the security process is vulnerable to machines with infinite patience.
Finally, I'm very, very disappointed that Scheier fails to challenge -- and sometimes even supports -- the social conservative attitude towards hacking and reverse engineering. He points out the futility of trying to encrypt DVDs -- but barely touches on the DMCA. He speaks of general software hacking as a basically benign activity -- but he supports criminal punishment even for the most non-invasive electronic "trespass". This is a point of view utterly at odds with his ideas of security considered in a complete social context.
Yes, it is impossible to secure a system completely - every security system has a human element, and every human element has a head that can have a gun held against it.
Its sort of amusing that Bruce took this long to come to this realization.
Don't mind the doomsayers - if you follow sound security policies and practices, you will likely be okay. If not, well, that's why you buy insurance.
I still recommend The Code Book for more general reading. (Normal Amazon link - none of that affiliation crap).
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
Gee whiz, Hemos. Did you actually have to break out the so we'd notice the ThinkGeek link?
Browser? I barely know her!
I just read this book last week.
;) Still can't get over the fact that he invented the satelitte.
I am not a security consultant, nor am I an uber cracker. I am a programmer who due to middle management mismanagement is often forced to worry about network security a lot more than I should, but I digress.
I found a lot of the major points were identical to many things I learnt at university and was dissappointed by the scare mongering that the author employed. I would assume that anyone who reads a book regarding advanced security policy implementations would be quite aware of all the shortcomings in a lot of organisations systems and thereby doesn't really need to be bombarded with anecdotal nightmare scenarios.
I am disappointed by some of the sensationalism which is being used by a lot of "security" books.
There is a new genre of books coming out, pop-tech. Books which are half based on sound technical information (albeit derived from academic channels) and popular culture semi-futurism/apocalyptic tea leave reading.
Whilst this book is on the softer end of that spectrum it still falls into the same band.
Having said that, a lot of good points are raised and it will jog your memory, but if you want a sounder perspective on security and encryption I suggest you go to your local university bookstore and get a book which was written by someone who doesn't run a company in the field and doesn't need to drum up business.
If you want the futuristic tea leave reading then perhaps asimov is more your thing
This book is somewhat of a hybrid (as mentioned before it is by no means the worst offender but it is definately in the same cell block) please don't try to develop security policies for you organsation solely on this book. As the tea leaves will end up telling the truth.
Schneier explains a lot of stuff, like what authentication is, what a private key is and so on, that most geeks will know backwards. I'm willing to bet that anyone that read his Counterpane newsletters will probably not learn a huge amount of new stuff.
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.
The book is way cheap at buy.com (under $15US) + 4 for shipping. Unless they were targeting discount cookies at me. That beats the hell out of Amazon and ThinkGeek.
~Sean
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
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
BEGIN RANT/
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
Evan - needs to hit preview before submitting
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.