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)"
They have been replaced by Japanese riot cops practicing Aikido, a fighting philosophy where there is neither victor nor vanquished.
Aikido isn't for fighting -- it's a defensive martial art whose purpose is to gently take down your opponent using a variety of joint locks, etc.
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!
Some people might not like reading the books on your monitor, but it doesn't bother me. I think the electronic search features (in a specific book, across all books, etc.) really makes the service much more useful.
Again, I'm not trying to plug, but after years of spending at least $50 a month on books I'm really satisfied with safari.
Computer security is almost an oxymoron in a networked environment. On the one hand we want to be connected to everyone and seamlessly share data, software, and functionality. And so we connect to large numbers of people, like the poeple we meet on /. and other forums.
On the other hand, we want to restrict access to all but a "trusted" few. Yet the tools for creating trust on the internet are poor or illusory.
Trust takes time to develop. Only after we have a breadth and depth of experience with the coutnerparty can we truely trust them. The existence of people willing to create a trusted persona over the months or years in order to gain black-hat access or run a scam is at odds with the natural speed of the internet were it only takes a few months to become a trusted veteran.
Trust also requires tokens of commitment -- the idea that each party has something to lose in the relationship. Unfortunately, most online venues lack this because it is too easy to abandon a troll/criminal persona and create a fresh persona.
I applaud the work of computer security professionals -- its an extremely hard job made harder by the conflicting demands on computer infrastructures and the mismatched timescales of trust and the internet.
Two wrongs don't make a right, but three lefts do.
...and remember to wear badger skin underwear to keep out the fleas. (thanks Hagakure )
You have no idea what you're talking about. Mathematicians and computer scientists prove negatives and non-existence all the time. For example, it is proven that there exist no non-zero rationals a, b, and c, and integer n > 2, such that a^n + b^n = c^n.
The reason it's not possible in practice to prove anything about computer security is that the languages and protocols we used were not designed with this ability in mind. You can't prove anything useful about unix, C, or HTTP. It's true that it would take a massive overhaul of our computer infrastructure, but it's possible to have systems that you can reason about.
Even then, it's true that you can only prove things in a model, and it's always possible that there will be a real-world attack that isn't reflected in the model. But the situation could be much, much better than it is today. If you use a safe language and design your library carefully, you can probably provably protect yourself from some vulnerabilities.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.