Comment Re:He knows cryptography but doesn't know programm (Score 1) 77
Argh.... Please forgive the above premature post. This is my first post to Slashdot; I meant to hit Preview, but missed.
sequence_man, you appear (to my eyes) to be as foolishly idealistic as Schneier now says he was when he wrote Applied Cryptography. Where Schneier was moved by his faith in the theoretical perfection of the mathematics, you seem to be standing on the rock of software engineering. This is indeed a dubious foundation.
I think you have missed the vast bulk of what Schneier was trying to say with Secrets and Lies. You've focused entirely on the idea that 1) because code is very complex and constantly growing morseso, therefore 2) there will always be bugs, and therefore 3) we can't have security. I think Schneier did make a point somewhat like that, but that's really one of his minor points: a bit of shrubbery in the forest you have overlooked.
If I had to summarize the book's main points in one sentence, it would be this: Security in the real world is hard, because it deals with many things, most of them complex, few of them subject to the kinds of precision or rules that you would hope for or expect from things like mathematics or programming languages.
Schneier spends several pages (a good part of one chapter, actually) talking about programming, the size and complexity of programs, bugs, and the resulting security loopholes. But this is hardly his main thrust; he simply uses it to underscore what he repeats and emphasizes all along: security is hard, harder than most people think, and must deal with many things, more than most people have thought about.
Good software engineering can in fact result in more secure software. Principles such as you alluded to (modular design, isolation of security-related functions, etc) are great, and we need more software designers and writers following such principles. Software should be designed with security in mind and written following good security practices. The shameful fact is that very often it is not.
However, even if the world were to wake up tomorrow and begin writing software that properly integrates with system security facilities, checks results for boundary conditions and general sanity, eliminates buffer overruns and race conditions, and the hundred other things you can find in various guides to writing secure code (see David Wheeler's Secure Programming for Linux and Unix HOWTO at http://www.ibiblio.org/pub/Linux/docs/HOWTO/other- formats/html_single/Secure-P rograms-HOWTO.html , the best reference on the subject I've found online so far, in part because of his well-commented list of other sources), that still doesn't buy us any real security. Not by itself, at least.
You see, security isn't about secure software any more than it's about secure cryptographic protocols. It's about those, and more. Security in the real world has to consider the following: physical security of computers; strength of passwords; correct installation of secure software; correct use of secure software and secure systems; correct administration of secure software and secure systems; proper permissions on files; power outages; backups; secure backup storage; bugged phones; bugged offices; bribed secretaries; bribed system administrators; bribed CEOs; people with guns; people with bombs; people with rubber hoses and brass knuckles; people with the key to your server room; users that don't understand security; managers and financial backers that don't understand security; system administrators that don't understand security; and finally (although there are many more things I could include in this list) programmers that don't understand security.
If you think that any of the above aren't really important, and that all we need is good, solid code that comes from good, solid coding practices, then you are thinking of security in a very limited context. This context may apply to your circumstances, but it is much smaller than the real security needs of a great many people.
Granted, most people don't need to worry about everything I mentioned... probably we can knock "men with guns/bombs/rubber hoses" off the list for the majority, right off the bat. But every secure computer system needs to be administered properly or it may well have no security whatsoever. Note that I'm not necessarily saying it needs to be actively administered, in the sense of being constantly monitored by Schneier's new company or some such; simply that a computer system needs to be, at a bare minimum, installed and configured securely at the outset. You may be thinking: "Well, duh, that's such an obvious notion that I didn't mention it." But this is precisely the kind of administration that is so lacking in so many computer systems today. If it's not explicitly considered, it will be overlooked, and if it's overlooked, there will be no security. And it gets overlooked all the time, time and time again, often even when someone does take the time to explicitly consider it.
Proper system administration (or even simply proper system setup) is only one more thing to consider when evaluating or constructing some kind of secure system. And it is only one of the other things that Schneier discusses in the rest of his book.
Schneier discusses and explains much more than poorly written code. He covers pretty much every facet of information security that I've yet encountered, including fundamental concepts like security in depth, risk analysis, threat modeling, and other phrases that Highly Paid Security Consultants like to toss around (but please note that just because the phrases are overused and under-understood by people with too-large hourly rates and too-small reading lists doesn't make the concepts themselves useless). He provides practical insight into things like passwords (what they are good for, what they are not good for, how they can be chosen and stored and used and the limitations of different ways of doing so), cryptographic algorithms (ditto), smart cards (ditto), and various kinds of security software (firewalls, scanners, IDS, and so forth (ditto)). He talks about end-users and how their behavior can compromise security. He talks about similar issues with system administrators, bureaucrats, police, and criminals.
Anyone contemplating buying or reading Secrets and Lies should be aware of a few things. First, it is not a hard-core technical book. There's no code, no algorithms, no configuration step-by-steps... there's not even any math! It's not written for a technical audience. Actually, that's not quite right: it's written to be accessible to a non-technical audience; there's a difference. Speaking as a techie, I eagerly devoured the book and was left quite satisfied. It covers my favorite subject (computer security) broadly and thoroughly even while omitting details that are only of interest to someone doing implementation (writing code, configuring systems, etc). It's a book that you could give to management if they wanted to know more about this "security stuff" you keep going on about. If they weren't inclined to read it, reading it yourself would make a good preparation for giving a presentation to management. While non-technical, it is not dumbed down in any respect.
Second, if (like me) you've read almost everything Schneier has written on his website, or have been working in or studying computer security for a couple of years, you won't really learn anything from reading the book. There's nothing ground-breaking, nothing revolutionary. But it is an excellent compliation and presentation of the things we all know, or should know. It may help you gain some focus on your current security problems, or put a large security project in perspective, or inspire you to do something specific you weren't considering before. If nothing else, Schneier's writing style is enough to make the book an entertaining read.
Third, you might get the impression that Schneier is writing this book simply to get customers for his new security monitoring business. I'm going to suggest that both his book and his business spring from the same source: his interest, research, and work in the field of both cryptography and, more and more as time has passed, security in general. Schneier is certainly qualified to write a book like this, and the book stands on its own as both informative and (for us computer security wonks) entertaining. If you are concerned that the book is nothing more than a protracted pitch for his new company, simply tear out the last few pages of the last chapter of the book, as that is the only place he mentions it.
You might legitimately be worried that with his new business, Schneier has an interest in overstating the security risks of computer systems. That may be so. But I don't believe that any of the risks he discusses are overstated in the least. In fact, several times he talks about the importance of not overstating security risks. Proper security stances, he argues (and I agree), result from understanding what threats you are actually facing, the importance of what you are protecting, the expense (in time, effort, and money) you are willing to incurr in protecting it, and the loss you are willing to take in failing to protect it. Schneier is firmly on the side of reason, not hysteria, and makes that clear many times throughout the book.
If you are interested in learning more about computer security, I would wholeheartedly recommend Secrets and Lies for foundation and philosophy, along with Practical Unix and Internet Security by Garfinkle and Spafford for practical advice and instructions. But I would urge you to read more than just the chapter about programs and bugs in code, lest you end up thinking, like sequence_man, that "security is a solvable software engineering problem". If you truly believe that, you will end up writing code in isolation with no consideration of other aspects of security. You will write code that has no practical use and makes no meaningful contribution to security in the real world.
Eddie Maise
sequence_man, you appear (to my eyes) to be as foolishly idealistic as Schneier now says he was when he wrote Applied Cryptography. Where Schneier was moved by his faith in the theoretical perfection of the mathematics, you seem to be standing on the rock of software engineering. This is indeed a dubious foundation.
I think you have missed the vast bulk of what Schneier was trying to say with Secrets and Lies. You've focused entirely on the idea that 1) because code is very complex and constantly growing morseso, therefore 2) there will always be bugs, and therefore 3) we can't have security. I think Schneier did make a point somewhat like that, but that's really one of his minor points: a bit of shrubbery in the forest you have overlooked.
If I had to summarize the book's main points in one sentence, it would be this: Security in the real world is hard, because it deals with many things, most of them complex, few of them subject to the kinds of precision or rules that you would hope for or expect from things like mathematics or programming languages.
Schneier spends several pages (a good part of one chapter, actually) talking about programming, the size and complexity of programs, bugs, and the resulting security loopholes. But this is hardly his main thrust; he simply uses it to underscore what he repeats and emphasizes all along: security is hard, harder than most people think, and must deal with many things, more than most people have thought about.
Good software engineering can in fact result in more secure software. Principles such as you alluded to (modular design, isolation of security-related functions, etc) are great, and we need more software designers and writers following such principles. Software should be designed with security in mind and written following good security practices. The shameful fact is that very often it is not.
However, even if the world were to wake up tomorrow and begin writing software that properly integrates with system security facilities, checks results for boundary conditions and general sanity, eliminates buffer overruns and race conditions, and the hundred other things you can find in various guides to writing secure code (see David Wheeler's Secure Programming for Linux and Unix HOWTO at http://www.ibiblio.org/pub/Linux/docs/HOWTO/other
You see, security isn't about secure software any more than it's about secure cryptographic protocols. It's about those, and more. Security in the real world has to consider the following: physical security of computers; strength of passwords; correct installation of secure software; correct use of secure software and secure systems; correct administration of secure software and secure systems; proper permissions on files; power outages; backups; secure backup storage; bugged phones; bugged offices; bribed secretaries; bribed system administrators; bribed CEOs; people with guns; people with bombs; people with rubber hoses and brass knuckles; people with the key to your server room; users that don't understand security; managers and financial backers that don't understand security; system administrators that don't understand security; and finally (although there are many more things I could include in this list) programmers that don't understand security.
If you think that any of the above aren't really important, and that all we need is good, solid code that comes from good, solid coding practices, then you are thinking of security in a very limited context. This context may apply to your circumstances, but it is much smaller than the real security needs of a great many people.
Granted, most people don't need to worry about everything I mentioned... probably we can knock "men with guns/bombs/rubber hoses" off the list for the majority, right off the bat. But every secure computer system needs to be administered properly or it may well have no security whatsoever. Note that I'm not necessarily saying it needs to be actively administered, in the sense of being constantly monitored by Schneier's new company or some such; simply that a computer system needs to be, at a bare minimum, installed and configured securely at the outset. You may be thinking: "Well, duh, that's such an obvious notion that I didn't mention it." But this is precisely the kind of administration that is so lacking in so many computer systems today. If it's not explicitly considered, it will be overlooked, and if it's overlooked, there will be no security. And it gets overlooked all the time, time and time again, often even when someone does take the time to explicitly consider it.
Proper system administration (or even simply proper system setup) is only one more thing to consider when evaluating or constructing some kind of secure system. And it is only one of the other things that Schneier discusses in the rest of his book.
Schneier discusses and explains much more than poorly written code. He covers pretty much every facet of information security that I've yet encountered, including fundamental concepts like security in depth, risk analysis, threat modeling, and other phrases that Highly Paid Security Consultants like to toss around (but please note that just because the phrases are overused and under-understood by people with too-large hourly rates and too-small reading lists doesn't make the concepts themselves useless). He provides practical insight into things like passwords (what they are good for, what they are not good for, how they can be chosen and stored and used and the limitations of different ways of doing so), cryptographic algorithms (ditto), smart cards (ditto), and various kinds of security software (firewalls, scanners, IDS, and so forth (ditto)). He talks about end-users and how their behavior can compromise security. He talks about similar issues with system administrators, bureaucrats, police, and criminals.
Anyone contemplating buying or reading Secrets and Lies should be aware of a few things. First, it is not a hard-core technical book. There's no code, no algorithms, no configuration step-by-steps... there's not even any math! It's not written for a technical audience. Actually, that's not quite right: it's written to be accessible to a non-technical audience; there's a difference. Speaking as a techie, I eagerly devoured the book and was left quite satisfied. It covers my favorite subject (computer security) broadly and thoroughly even while omitting details that are only of interest to someone doing implementation (writing code, configuring systems, etc). It's a book that you could give to management if they wanted to know more about this "security stuff" you keep going on about. If they weren't inclined to read it, reading it yourself would make a good preparation for giving a presentation to management. While non-technical, it is not dumbed down in any respect.
Second, if (like me) you've read almost everything Schneier has written on his website, or have been working in or studying computer security for a couple of years, you won't really learn anything from reading the book. There's nothing ground-breaking, nothing revolutionary. But it is an excellent compliation and presentation of the things we all know, or should know. It may help you gain some focus on your current security problems, or put a large security project in perspective, or inspire you to do something specific you weren't considering before. If nothing else, Schneier's writing style is enough to make the book an entertaining read.
Third, you might get the impression that Schneier is writing this book simply to get customers for his new security monitoring business. I'm going to suggest that both his book and his business spring from the same source: his interest, research, and work in the field of both cryptography and, more and more as time has passed, security in general. Schneier is certainly qualified to write a book like this, and the book stands on its own as both informative and (for us computer security wonks) entertaining. If you are concerned that the book is nothing more than a protracted pitch for his new company, simply tear out the last few pages of the last chapter of the book, as that is the only place he mentions it.
You might legitimately be worried that with his new business, Schneier has an interest in overstating the security risks of computer systems. That may be so. But I don't believe that any of the risks he discusses are overstated in the least. In fact, several times he talks about the importance of not overstating security risks. Proper security stances, he argues (and I agree), result from understanding what threats you are actually facing, the importance of what you are protecting, the expense (in time, effort, and money) you are willing to incurr in protecting it, and the loss you are willing to take in failing to protect it. Schneier is firmly on the side of reason, not hysteria, and makes that clear many times throughout the book.
If you are interested in learning more about computer security, I would wholeheartedly recommend Secrets and Lies for foundation and philosophy, along with Practical Unix and Internet Security by Garfinkle and Spafford for practical advice and instructions. But I would urge you to read more than just the chapter about programs and bugs in code, lest you end up thinking, like sequence_man, that "security is a solvable software engineering problem". If you truly believe that, you will end up writing code in isolation with no consideration of other aspects of security. You will write code that has no practical use and makes no meaningful contribution to security in the real world.
Eddie Maise
