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.
This reminds me, looks like the speeches from Defcon 9 will be going up online soon.
He mentioned Applied Cryptography... I wanted to point out Schneier's latest book Secrets and Lies, kind of a real-world threat analysis in contrast to the mathematical analysis of Applied Cryptography. Good read.
Here you can find a pdf off chapter 10, chapter 18, and chapter 1.
From what I've seen of it so far, it's a good book (Disclaimer: yes, he was my project supervisor last year!). A few funny typos etc in the errata, which is well worth a look, too, especially anyone wondering who the hell this "Prince Schneier" guy on p 113 is ;-)
I know it's all the rage to hate Amazon. As for myself, I think the annoyance of things like one-click patent support do not quite outway the good Amazon has done or the fact they have a well-built site that I enjoy more than almost any other.
I do buy books from FatBrain from time to time, and even wear a FatBrain baseball hat they were kind enough to send me some time ago. But when a book is $60 at FatBrain, and $36 at Amazon... well, I like donating money to the EFF but I'm not sure I am quite THAT supportive of FatBrain. So if you're on a limited budget, you might want to order the book here instead (and no, I don't get anything from the link - go to Amazon yourself if you are paranoid).
Just for completeness, it's $51.95 at Bookpool.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I heartily recommend the book Building Secure Software (How to Avoid Security Problems the Right Way) .
It also shows that security is mostly a human problem.
On the other hand, I would like to know how crackers find security holes. For example: how was the buffer overflow in PnP XP found? Did the guy sort of fuzzed it?
What I mean is: Before trying to secure software, it would be nice to know how the bad guys (or the security researchers) find the weaknesses.
60.00 from fatbrain?!Go to bestbookbuys.com (a comparison shopping site much like pricegrabber) and pick it up for under $40.00
Oh, wow. It's another "structured programming guru." And like all the others, he knows nothing about programming.
Good programming is not accomplished by managers or business structures, useful as those are. Good programming is done by good programmers, using a language that allows them to express themselves elegantly.
In case you were wondering, programmers generally use the term "bugs" to refer to flaws in the implementation of a program, not flaws in the design of a program. For example, the fact that Mac OS 7 had no multi-user mode was not a security "bug"-- it was never designed with multi-user mode in mind. The fact that Windows 95 had memory leaks WAS a bug, because it represented an incorrect implementation of the design specification.
It is possibly for a program to be buggy, but secure. For example, an FTP server can be immune to exploits, but still have memory leaks and random crashes. It is also possible for a program to be free of bugs, but insecure. If your FTP server is rock-solid stable, but never asks anyone for a password, you are in this situation. If you think, "but nobody could be stupid enough to ignore security in their product design!"... well, like I said, you haven't been in this business long.
There are a lot of things programmers can do to improve security:
1) Don't use C for networking software. All at once, buffer overflows (as well as faulty pointer arithmatic) become a thing of the past. Unfortunately, there are very few languages that can replace C for systems-level and speed-critical software. But even if you do end up using C, DON'T use the C string functions.
2) Think about your design BEFORE you implement it. It doesn't matter who the CEO of the company is, or how many managers are on the Managerial Board, if the programmers can't think for themselves. For example, can you think of situations where having your email program automatically download and run
In my opinion, the best programming teams are small, focused teams of individuals, who can work with little interference from management. Trying to squeeze software development into "top-heavy" business models has never worked very well (*cough*, IBM, *cough*, OS/2). And finally, before you convince yourself that you know how to manage programmers-- try programming.
"Any connection between your reality and mine is purely coincidental." -Slashdot
I'd like to recommend some complementary books; each of these approach security from a different angle
Michael