Slashdot Mirror
Security Warrior
The book comes lightly packaged in a metaphor about the training of samurai. A security warrior, it is said, must avoid a "superficial study of the subject" because that leads to a "deterioration of the samurai spirit." To avoid this, the authors plunge deeply into a wide variety of ways that attackers might break into your system. The book is meant to help you "know your enemy" and "see through an attacker's eyes."
This chestbeating fluff disappears pretty quickly because the authors dive into reading assembly code in the first chapter and start talking about the registers of the CPU by page 4. The rest of the first part of the book explores reverse engineering software by reading assembly dumps and using good tools to decipher it.
After poking around in binary code, they turn to the bits floating around the network. Chapters 6 through 10 explore how to sit on one end of the Internet and pry your way into another computer. Chapters 11 through 17 dive deeper into the specific defenses of platforms like UNIX, Windows, SOAP and SQL. The rest of the book, Chapters 18 through 22, explore how to figure out just what the attackers may be doing by setting up honeypots and log analysis tools.
Covering all of these topics in 531 pages is clearly not possible and the book reads more like a survey or a catalog of what can go wrong. If you use PHP, for instance, as a frontend to your database, you might want to be sure that some "script kiddie" won't slip in some extra SQL in the form fields. Each topic isn't built up from some bedrock foundation with perfect mathematical pedagogy, it's just defined as a list of bad things that you should avoid doing.
The authors seem to be aware of how this might be misinterpreted. There are many good tricks in the book and it wouldn't be hard to rename it Al K Da's 1337 Haxor Tips . So the authors stress how learning about the enemy is the only way to defeat the hordes.
I think the problem is deeper and more philosophical. There's no way to prove a negative. There are no good mathematical tools that make it easy to prove statements like P!=NP or big numbers can't be factored quickly. In a larger sense, it's not really possible to prove that someone can't break into a system. A more traditional, ground-up approach to the topic can offer some assurances, but books like this one are always necessary. Anyone doing battle against unknowable and unpredictable adversaries must look between the cracks.
If you look at it this way, the book is a good collection of tips and hints that will help someone keep their network a bit more secure. It doesn't provide a deep, elegant and rigorous explication of the topic, but I don't think that is possible. It's a great collection of tricks that should be part of a good warrior's training.
Peter Wayner is the author of Translucent Databases and Policing Online Games . You can purchase Security Warrior from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
However, physical security and network security are somewhat different issues. If you unplug from the net you are entirely secure from attacks over the net. Yeah, somebody can still drop a bomb on you, just as someone can drop a bomb on your house. Motivation to do so is often lacking though, since that denies them the ability to walk off with your TV set.
The issue with net security is that you're inviting people into your foyer, and perhaps even your living room and bathroom, but wish to keep them from snooping in your bedroom or medicine cabinet, or slipping into the heating ducts.
Maintaining limited security is a thougher nut than just throwing a wall around your place with big "Keep Out" signs.
In any case, just as with home security, the real goal isn't so much to become ultimately secure, as you point out that's impossible, but to make it easier to break into your neighbor's house than your own.
Suck's for your neighbor I suppose, but that's what it boils down to.
KFG
Computer security problems almost always fall into a few well-known (beaten to death is more accurate) patterns. One such pattern is the "buffer overflow attack". Why does anyone accept this? There is absolutely no reason for modern software to be subject to buffer overflows. We have languages like Java which run everything within a protected virtual machine and don't use buffers. We can design CPUs which allow sections of memory to be marked "execute only, don't write". We can use safe string libraries instead of creaky old standard lib. And yet I still hear people saying that buffer overflows are a given.
Same with root escalations. For years we have had ideas of how to have systems that are compartmented and don't have root. In the Unix world, we have the idiocy of "trusted ports" (ports I could go on and on. The only reason why computers are so insecure is because we have accepted that they are and decided to live with it. This is just wrong.
--------
Create your own WAP site, or become a Wireless-Enabled Hosting(tm) provider
However, physical security and network security are somewhat different issues. If you unplug from the net you are entirely secure from attacks over the net. Yeah, somebody can still drop a bomb on you, just as someone can drop a bomb on your house. Motivation to do so is often lacking though, since that denies them the ability to walk off with your TV set.
Unplugging from the 'net is a good idea for servers that offer no services to the 'net. (Software updates can be delivered to it by sneakernet when needed.) Unplugging a server that does offer a service while under attack, however, is a security failure that's contained. Yeah, you're protected from any further breaches, but now your service is down for security reasons, and not letting your service out is a Type II security failure.
Would you look at that... I could chop up something in seconds to run around patching shit. Didn't test variables, I did it to prove a point. Sure admins all get busy, but most admins also get lazy
MoFscker
If you really think you're not going to seal all the cracks, or that you create new ones as you rebuild your electronic foundation, you need to track what goes on inside the house at all times.
The best way to do this is to log all significant events in your infrastructure:
Without knowledge of your history you can't see new trends or look back and see how often in the past newly discovered exploits by external attackers and internal were used. The company I work for (Addamark) discusses the log-everything approach to security. It's a tough problem because of the scale of info required. Sorry for the shameless plug but this is the problem we address, and do so rather well at several real-world companies.
Heh, yes, Hagakure (In the Shadows of Leaves) has many insights on a lot of topics :). For the one at hand, a slightly more productive reflection from the book might be:
668.5