Slashdot Mirror
Security Engineering
Introduction
The complexities of security engineering go beyond the ideals of understanding buffer overflows and considering that patching your systems is not an option. Many a Slashdot article (particularly the latest one on Louis Bertrand's OpenBSD presentation) has comments on the failings of code design. In Ross Anderson's book Security Engineering: A Guide to Building Dependable Distributed Systems, Ross goes into impeccable detail into the aspects of building systems resilient to malicious attack, abuse and programming error.
The book is well laid out, and in my opinion Ross properly segmented the topics in a way that makes the sections easy to read. The first section is focused on the many concepts of digital security such as protocols, access control and cryptography, and is written in a way so that you do not require a technical background to understand. It was refreshing to read how Ross explains cryptography in such a non-threatening manner that you can understand it without having to refer to Applied Cryptography from Bruce Schneier. Many authors have tried this in the past, and failed.
The second part of the book goes into considerable detail about practical and important applications such as banking and network attacks and defense. I have to be honest with you, I don't read a lot of books on software engineering that go into Radar Jamming and Nuclear Command and Control systems, and I found that sort of discussion exciting. (Although I have no interest in writing security code for the next cruise missile that will move the world to a level of DefCon quicker than that in movies like War Games, I still was quite interested in the approach.) Many of the examples and case studies that Ross explains bring the whole topic together to help strengthen the point about security engineering and its application to each system. Further to this, Ross' writing made me shutter to think about just how popular applications like bankcard systems have been written to be so weak and vulnerable. Before the book's main content, Ross includes an explanation the legalities of publishing some of this information. It wasn't until I started reflecting on some of the case studies that I realized how potent and valuable some of this information is, especially when I thought of potential risks that should have been mitigated and were not. Ross' examples should be considered textbook cases, though, and not information that can be drastically abused.
The third part looks into the organizational and policy issues faced with security engineering. From office politics to security and the law, this section goes into depth about managing security engineering and its affects on business and people. Compared to the rest of this book I found some of the topics in this section too short on detail, feeling like just a glancing blow, but still giving the reader enough information to seek more in depth content if they so choose. (Check out the bibliography for such information.) Discussing issues such as Carnivore, digital copyright, and system evaluation and assurance, this section rounds out the book quite well.
Why to Consider this BookIf you are a developer considering security (which should be all developers, anyways) this book provides a good balance on security engineering, and serves as an excellent reference work. It can work well as a textbook introducing developers to security engineering, and can be used as a good introduction to many dynamics of digital security. (Hint to COMP professors outside of Cambridge: get your students to read this book -- after you do of course).
Although you might not be able to use the section on radar jamming and its countermeasures directly, you may still be able to use principles in writing protected electronic systems while working on that new wireless system for Ma Bell. And finally, you should use this book as a brick in the foundation of learning on the concepts of writing secure code.
Something else you should consider in this book is the extensive bibliography in the back. If you want to follow up with more detailed information in any one section, Ross did an tremendous job in providing pointers to research papers and work done by others to read and research on. This in itself made the book well worth the money, as for me I have already read up and used some of the works I didn't have indexed to me before.
Wrap UpIf you are going to read this book and look for samples to write secure code, you are going to pick up the wrong book. This book is a cornerstone in building a strong foundation and understanding of security engineering. This book is goes beyond understanding the practical components of buffer overflows, stack smashing and code audits for review, and takes the reader into a new plain of understanding when it comes to security engineering. It is not a cookbook for lazy script kiddies to learn how to attack weak systems, but can be used to allow you to learn from others mistakes. You don't have to be a developer working on security systems to gain some knowledge from this text. Areas in the book such as that on E-Commerce can very much help bridge the chasm of bad web application design and can help you refrain from getting in the trap of fast application development full of vulnerabilities and exposing users to unnecessary online risk.
It is the responsibility of all developers to understand the risks they expose their software and their clients to. I am sure some developers will have some excuse where their web forms and applications do not require them to learn such silly things. That's fine. Hopefully I wouldn't need to use your systems. For the rest of us though, this is a must read.
Table of ContentsPart One
- What Is Security Engineering
- Protocols
- Passwords
- Access Control
- Cryptography
- Distributed Systems
Part Two
- Multilevel Security
- Multilateral Security
- Banking and Bookkeeping
- Monitoring Systems
- Nuclear Command and Control
- Security Printing and Seals
- Biometrics
- Physical Tamper Resistance
- Emission Security
- Electronic and Information Warfare
- Telecom System Security
- Network Attack and Defense
- Protecting E-Commerce Systems
- Copyright and Privacy Protection
Part Three
- E-Policy
- Management Issues
- System Evaluation and Assurance
- Conclusions
Bibliography
You can purchase Security Engineering from Fatbrain. Want to see your own review here? Just read the book review guidelines, then use Slashdot's handy submission form.
Let's face it, most developers would rather gnaw their own left leg off than read about something as dull as building secure systems--it's so often something left to a security audit or (even more often) a malicious cracker to discover the inevitable vulnerabilities. So it's nice to see a book that capitalizes on the glamor of nuclear defence systems to try and kickstart interest.
I threw this book in my to read list. BTW, I've found that people are probably a more important part of your security strategy than just code. Every program I write begins with a security mechanism that drops any anomolies into a database. Severe problems get emailed to an admin or activates their pager. The program does a great job detecting and reporting security breaches, but means squat if no one ever acts on the problems or turns off their pagers. It generally is an uphill battle to get a company to train resources in monitoring their systems, and to give adequate rewards to the admin who gets woken up at 3AM because some one is trying to hack a password in the system.
When someone starts off by saying
"I thought I would do a review on one of my favorite books."
I guess this is objective, since it is one of his favorites.
Sounds like a good book. As someone with a system dropped into his lap which was never designed to be distributed (but now is), the review interested me, and I'm likely to soon try to obtain the book (or at least look at it).
One problem I often faced by developers is not so much that they don't want to write good secure code, but they are under such deadlines that they can't take a break to learn how. For some, their early training may not have included the idea of the application being distributed, or prepared them for the issues inherent in such environments. The other issue I tend to see is users during testing clamoring that the security that may have been put is unnecessary, or slows down the process, or it is too much to remember, or... *bang head against nearest hard surface, repeat*
In response to your sig (and slightly off-topic to the article), an off-shoot of the Cygwin project (housed at http://sources.redhat.com/ ), includes an implementation (under "More projects") of XFree86 using the Cygwin API to run under Windows 9x/NT/2k/XP.
This is valid, to a point, here's where it falls apart: You want to build a bridge: 1. Draw Plans 2. Have plans approved by inspector 3. Dig and pour foundation 4. Have foundation approved by inspector 5. Put up pylons, supports, whatever 6. Have them approved by inspector 7. Put the horizontal top on the bridge 8. Have top approved by inspector 9. Pave road 10. Have pavement approved by inspector 11. Bridge gets reviewed every year by inspector to check for flaws, maintainence needs, etc. Now, not all these apply to software development, but I hope you can see some parallels. Also, There is not much innovation in this type of method. You know your load, materials (and their thresholds), traffic load, weather, and most other variables, and you can use a mathematical formula to solve them. Show me this for software development! Now, certifing developers is a good idea, as is holding people accountable for their mistakes, but treating software developers like you would civil/mech/areo engineers is a farce, and is only purported to work by people who heard it in school and are just spouting it back out.