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.
Another good book in the same vein is Counter Hack by Ed Skoudis. It can be slightly dated, but still informative.
Here's amazon's page on it. It's ranked 5 out of 5 stars.
Casual Games/Downloads
A good security policy is paramount. This book does a good job pointing out some not-so-obvious places that are often over-looked in our haste to meet deadlines.
"Windows Reverse Engineering (PDF)"
Security has been the same for a while:
Don't open unused ports.
Don't make your system unnecessarily complex.
Don't use software if you haven't inspected it.
Don't give access to those who don't need it.
Handle every exception.
Assume your user is an a**hole/dumbass who will use your system every way except the way it was intended to be used.
Dot your i's and cross your t's.
Now... Who wants to give me a book deal?
Slashdot Syndrome: the sudden, extreme urge to correct someone in order to validate one's self.
There's no such thing as a physical lock that can't be broken. It's only a matter of how much force needs to be gathered to break down the door, or break a hole in the wall.
An entirely secure site can be breached by a bomb being dropped on top of it. Now, some people might say that's cheating, because demolishing the site, and therefore whatever valuable was being protected too, doesn't give control of the valuable to the atacker. However, it does deny the services of the valuable to its owner as well. That's a security failure, the job is to keep the services of that valuable always available.
Computer security should be thought of in those terms. There's no such thing as unbreachable security, you just want to set the threshholds of what it takes to breach the security high enough so that it becomes highly unlikely that anybody can come up with the force it takes to defeat them.
Clearly, if somebody comes up with a processor that can quickly factor large numbers, then a good chunk of today's security theory will go straight out the window. However, since to our knowledge nobody has done so and nobody's close to doing so, we can consider that a good security technique to use now.
One must always keep up with what tools the bad guys have available, because once they have something that can knock down a defensive tool with ease, that defensive tool had better have another line of defense behind it.
Its a good book if you are interested in gaining a foundation in analysing TECHNICAL security issues. I.e. its a good pen-testing research book, but it doesn't go into any great depth with regards to higher-management issues, such as a corporate policy, ITIL/BS7799 type work. It is however a good base for skimming the surface of everything nasty that can come your way. It is excellently referenced! which is handy!
I'm reviewing the book as well with the intent to publish the review, but with so much work lately I haven't had time for reading. Any way, my summary so far (up to the UNIX specific attacks) is that it feels somewhat fragmented, and the order is slightly jarring. The first section of the book jumps right into assembly. While that might be a foundation to computing (one step up from machine code), it's a real bucket of ice water in the face for anyone trying to get started with the book. Even though I've been trained in a couple of programming languages and I'm familiar with ASM, it was still difficult to follow along some times. The first section on networking felt very incomplete and shallow, but then after skipping around a bit they come back to more network security topics a bit later. It remains to be seen how well it will flesh out in the later chapters. I was rather hoping for some details, like W. Richard Stevens tcpdump approach to teaching TCP/IP, given all the detail they had earlier on ASM, but alas I haven't seen anything like that, so far. On the other hand, I found the section on reversing Linux binaries to be very enlightening. I never realized how broken/limited the tools are for reversing on a Linux platform. Certainly that could make it very difficult to examine Linux viruses and worms when they finally start circulating in large numbers. Any way, I'll reserve the rest of my judgement until I actually finish the book.
Someone is WRONG on the Internet!