Security Engineering

SilverStr writes: "With all the recent discussion on organizations rethinking their security strategies, I thought I would do a review on one of my favorite books. I have stayed pretty quiet on /. over the years, but security is something I don't think developers anywhere should be taking lightly. Hopefully some of them will get something out of my review and pick this book up." Read on for the rest of his review of Ross Anderson's Security Engineering. Security Engineering: A Guide to Building Dependable Distributed Systems author Ross Anderson pages 612 publisher Wiley Computer Publishing rating 9.5 reviewer SilverStr ISBN 0-471-38922-6 summary An exceptional book on the dynamics of security engineering. A must have on all developers shelves who care about digital security and its impact on system design.

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 Book

If 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 Up

If 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 Contents

Part One

1. What Is Security Engineering
2. Protocols
3. Passwords
4. Access Control
5. Cryptography
6. Distributed Systems

Part Two

1. Multilevel Security
2. Multilateral Security
3. Banking and Bookkeeping
4. Monitoring Systems
5. Nuclear Command and Control
6. Security Printing and Seals
7. Biometrics
8. Physical Tamper Resistance
9. Emission Security
10. Electronic and Information Warfare
11. Telecom System Security
12. Network Attack and Defense
13. Protecting E-Commerce Systems
14. Copyright and Privacy Protection

Part Three

1. E-Policy
2. Management Issues
3. System Evaluation and Assurance
4. 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.

Comments

Speaking of security...

[ksw2]

This reminds me, looks like the speeches from Defcon 9 will be going up online soon.

Sugaring the pill

[GSV NegotiableEthics]

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.

Secrets and Lies

[ksw2]

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.

Secret Lies by Bruce Schneier

[Anonymous Coward]

Another book which is even more accessible to non-techies (perfect for clueless CEOs and management in general) is Secret Lies by Bruce Schneier. An excellent high-level view of why security often is sub-standard in most organization and many useful discussions on what to do and not to do with regards to security in general. Every man and woman should read this excellent book!

We need more disciplines like this

[Dr. Bent]

Software development, on the whole, is not practiced as an engineering discipline. It needs to be. Software engineers should be certified just like civil engineers or electrical engineers, and when something breaks, the company shouldn't be able to hide behind the EULA...they should be fully accountable.

This would make software much more reliable and siginificantly reduce the maintence cost for users.

Re:We need more disciplines like this

[GSloop]

I don't know about the certification bit...perhaps it would be a kudo, but not a requirement...hmmm...

But I do agree with the engineering approach. (By the way, I'm not an engineer, but the much maligned Business School - Information Systems graduate)

Software design, and the structure over the programming/QA/design teams seems really weak to me. To get a good program (virtually bug-free and good security...realize that these are one and the same) the structure must be quite rigid. We can't all go off coding as we wish, and just throwing the design and QA portions together on the fly.

I know I mentioned it before, but Mark Minasi's "The Software Conspiracy" is a great book that lays out these principals in overall detail. Look at the references to find more concrete/detailed examples of structured coding and design.

If we ever expect to get decent software, and secure software, we must then take a more rigorous and structured approach to software creation and design. Until this gets done, we'll all be running around in FRONT of the 8 ball trying to patch things after the fact. I can attest that this approach is a loosing one - in any disipline. Security has to be built in up front. Writing good code, and having a very structured devlopment environment need to be carefully engineered.

If we built bridges the way we build software, about 30% of all bridges would catastrophically fail. Now, you'll say, "oh software isn't as important, or at least not most software." Well, sure, that's true. But I don't think the reason we build good bridges the first time is because it could kill someone - although it's probably one of the reasons. The most likely, is that REBUILDING bridges when they fail is very expensive. When that happens, we know who to blame, and the following costs are very apparent.

What happens in software, is the costs are not tracked and traced to their source. If they were, we'd all of a sudden realize that the cost of crappy software is HUGE! I don't recall the source, but I think the estimated cost of the NIMDA virus was like 2 Billion. Lets assume that the cost was over estimated by 100%, so the real cost was only 1 billion. We're talking about some real cash here. I don't know what Windows developemt costs were, but I'd bet for an extra billion, and some real care to fix the problem, we could have had a whole lot better software.

Now finally for the market based solution. Make vendors liable for the bugs and insecurity of their software The government doesn't have to mandate a standard. A jury decides if the software vendor used due dilligence in writing good code. All I'm asking is that the atrificial protections for software be lifted. Treat it like any other good. We wouldn't expect the same functionality or lack thereof for our lawn-mowers, toasters, cars, microwaves or even our Tivo's.

When vendors find that the real costs get shifted back to them, in the form of civil negligence suits, they'll get serious about fixing the problem. Until then, they'll laugh their way to the bank, and we (the techs) get to fix the problems over and over and over again. Not only that, but WE look bad, rather than the vendor.

Ok, do your damage.

Cheers!

Re:We need more disciplines like this

[CrosseyedPainless]

At the current state of the art, software engineering is about as codified and scientifically verifiable as medicine was in the 12th century.

Re:We need more disciplines like this

[einhverfr]

The only problem is:

Engineered security is and should be intuitive. It is not a matter of difficulty in the actual engineering process but rather a lack of effort that the software engineers devote to the process. This is pretty simple for most pieces of software with the main exception being cryptography (which should be far more rigorous than many engineering disciplines).

When I have designed secure distributed applications, I have generally carefully considered what level of trust to give each component and then layered the security accordingly. I can then delegate out the security-related tasks to the operating system, database manager, main application, etc. as appropriate so that a security failure in one module in no way is a complete system compromise (can you tell I don't like IIS or Sendmail?). In short, I design my applications with the idea that they will fail, but that such failure will not be complete, and then do what I can to prevent the failure in the first place.

To me this is pretty simple and straight-forward and does not require an engineering degree. What it does require is a little forethought, and the humility to realize that as a programmer, no one is perfect.

Re:We need more disciplines like this

[SirSlud]

I agree to a point. The software world is dangerously sales-driven (My uncle coined the term "Real Time Sales Driven Development", or RTSDD for short. It makes extreme programming look like a gentle stroll through the park.), and defiantely could do with some professional ceritifcation regulations that slow down the clamour to develop the latest buzzword. To some degree, I'm sure the situation is much better at insitutions that have used software systems for many years (ie, banks, etc) than consumer-facing industries ('net access providers, ASP providers, OS *cough* vendor). The CS degree seems to be how companies evaluate the 'professionalism' of a programmer, but I think its a misplaced faith. More important than that would be audits and guidelines that must be adhered to by a regulatory body.

Of course, those addicted to the worderful world of 'slave-to-the-market innovation at the speed of e-business and shit' probably shudder to the thought, but can you imagine if designing buildings were subjected to the kind of rush-out-the-door development tempo that many dev houses have? Sure buildings have people, but softweare systems hold processes and business logic, which surplanted people long ago in terms of marketplace value.

It'd probably result in greater long range vision for the software industry as a whole as well.

Re:We need more disciplines like this

[GSloop]

Read above you...

What I think you and others like you misunderstand, is that the current system of not having good code is really expensive too.

The only reason we don't realize this, is that it's not tracked and properly accounted for. If it were, and the costs associated with "bad" code were added to the acquisition costs of "bad" software, we'd all of a sudden see that "bad" code is lots more expensive.

Where's it easier to fix a problem...Design, and do it once, or after you have 5-10 or even 100 million copies running around? Sure, it takes a while, and it's not cheap to do at design time, but it makes a whole lot more sense! Not to mention that if the source is closed, only the vendor can fix it. So, either you get NO fix, or the vendor who should have fixed it in the first place, does so, and forces you to spend the resources to fix all your copies.

As I said above, civil liability would help. A jury decides if the vendor used due dilligence to produce the code. If not, the resources should be recoverable from the vendor.

Cheers!

Re:We need more disciplines like this

[GSloop]

How about a market based approach. Eliminate the protections software gets from civil liability.

The market would then respond to additional costs from suits that prevail and cost the vendor lots of money. Investors would be wary of investing in companies that didn't have rigorous design, testing, and production methods. Etc. etc. etc.

The jury would decide the merits of the case. Primarily, did the vendor use due dilligence in producing the software.

Now, for all the libertarians. You'll all yell that government shouldn't be involved...Well, fine, software copyright just went out the window too. Software vendors want it both ways. They want full government protection of IP and copyright. But they don't want the legal system to be involved when they make crappy software.

Take one, expect to take the other. This situation, it seems to me, to be the great fraud of the twenty-first century.

Cheers!

Re:We need more disciplines like this

[FrostedChaos]

To get a good program (virtually bug-free and good security...realize that these are one and the same) the structure must be quite rigid. We can't all go off coding as we wish, and just throwing the design and QA portions together on the fly.

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 .exe attachments would be a bad idea? Apparently the folks at microsoft-- or at least the ones making decisions-- can't.

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.

Re:We need more disciplines like this

[GSloop]

It is possibly for a program to be buggy, but secure.

Only by luck. Bugs will eventually lead to security holes. That's like saying "You can have accidents in your car without injuring anyone..." and then using this logic to claim that accidents aren't that big of a deal for injuring people.

I'm sorry, but that's a stupid approach. I'm not a manager. I DO know how to program - in fact, my first programming language was C. I'm not too bad, though I know what I excell at and what I don't. I'm mostly a security and networking guru.

You can take pot-shots all you like. The fact is that a wild-west approach to design, programming and QA won't get the job done right. Heavy handed, totally inflexible management PHB's won't either. There's a middle approach that will work. But I dare say that most projects I've been on and worked with took the wild-west approach much more often than the heavy management approach.

So, if I were asked to put effort into fixing the problem in general, I would focus on fixing the wild-west approach before anything else.

Cheers!

Re:We need more disciplines like this

[GSloop]

Did I miss something here? I didn't ever say ANYTHING about government regulation!

The only portion of my post that mentioned government was that software vendors want government to protect their copyright, but not subject themselves to a civil court for negligence in creating that same software.

They want part of government, but not the other. If you want copyright protection, then expect to also stand trial in civil court and defend yourself for shoddy software.

Seems fair to me.

Cheers!

Re:We need more disciplines like this

[GSloop]

Ok, I'll bite.

How many bugs do you know about that were caused by us not using ASCII or TCP? NONE!

If the OS is designed right, the ability of other programs to interact with your program is very limited. DLL hell? In my opinion, that's an instabiltiy that comes from a poor OS design. Now, when an application falls into DLL hell, it probably wouldn't be fair to hold the application vendor responsible, but it sure as hell would be fair to at least see if MS could find adequate reasons for their approach.

A good design approach helps keep the landscape stable. Most programs are around for such short periods anyway, that the arguments you present are hardly issues at all.

If you think they are, how about using some realistic examples, rather than ASCII or TCP.

Cheers!

Re:We need more disciplines like this

[GSloop]

That helps, but I personally don't think it's enough. It depends on the scope of the project and many other factors, but certainly on mid-size to larger projects, I think a more structured approach would yield better results.

Cheers!

Re:We need more disciplines like this

[imadork]

How about a market based approach. Eliminate the protections software gets from civil liability.
Software vendors want it both ways. They want full government protection of IP and copyright. But they don't want the legal system to be involved when they make crappy software.

There's are basic problems with the Market Based approach which make it unusable -- Since there are so many distinct parts of software (OS Kernel, OS Services, Applications, Libraries, Device Drivers) that may be made by different vendors, how can you pin the blame for a software problem on a particular vendor if you're not 100% sure where the problem is? Or what if the code from two vendors is technically correct in isolation, but creates a security problem when used together? Who gets sued then?

I'm not sure of there's a practical way to enforce civil liability for software products unless the acual code is examined in the trial. Which eliminates the whole concept of Proprietary software. Most /.ers would welcome that, but I guarantee their employers won't.

And given that these trials are decided by twelve people who couldn't get out of Jury Duty, how will they possibly be able to understand the technical merits of such a case? They'll probably be swayed by the lawyers in the better suits, which will belong to the big software companies. Or the class-action law firm that sues the small companies under this statute.

In short, eliminating civil liability protection for software will insure that only big companies that can afford to go to trial with the class-action lawyers will be able to write software. Forget about small companies. And forget about cooperative Open-Source development -- that just gives Class-action lawyers more people to sue.

Re:We need more disciplines like this

[GSloop]

All I can say, is

CAN I HAVE SOME OF WHAT YOU'VE BEEN SMOKING?

You're so out of touch with reality, it scares me.

That, or your reading comprehention SUCKS!

[Flame mode off]

Cheers!

Sample Chapters

[Akatosh]

Here you can find a pdf off chapter 10, chapter 18, and chapter 1.

Monitoring

[yintercept]

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.

Here are some extracts...

[Cyberdyne]

One point the reviewer missed is that Ross put a few chapters of the book on his home page here. There's a page about the book itself here with links to a couple of chapters.

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 ;-)

Re:The Language of God

[atcroft]

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.

Book is a LOT (40%) cheaper at Amazon!

[SuperKendall]

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.

Re:Any books w/sample code?

[Snake]

If one was looking for a book with samples of writing secure code, does anyone have any recommendations?

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.

Read it before the UK government makes it illegal

[armb]

Yes, you thought dumb crypto laws were a thing of the past, but no, here comes the UK trying to copy what the USA already gave up, only without that tedious constitutional protection of free speech stuff.

http://www.cl.cam.ac.uk/~rja14/exportbill.html
(yes, rja14 is the Ross Anderson who wrote this book).

Also

[wiredog]

"Database Nation" from O'Reilly

On Software Development as Engineering

[essiescreet]

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.

do NOT use the link provided to buy this book.

[einer]

60.00 from fatbrain?!Go to bestbookbuys.com (a comparison shopping site much like pricegrabber) and pick it up for under $40.00

How?

[JMZero]

How do you detect intrusion? Of course you can do things like the following (in a login based web app):

1. Watching for too many password tries
2. Watching for too many page views/write attempts by a particular user - logging things
3. Blocking and logging long queries/odd characters/queries with errors

What else can I do? I try to write clean, secure code - but I don't know what the big threats are around the corner.

Should I be working harder to avoid cross-site scripting issues on pages past the login page? What's the odds of it being exploited? I use a session key, should I be changing it on every page view? Should I tie session keys to request IP (I do now), or is that pointless? Should I be extending my SSL key length?

And while I think about this, I notice some user has their password on a little sticky note on their monitor.

There's so many security threats to worry about. Does anyone have a resource that might suggest which are the first ones I should point my time at? Or a list of security failures and how they happened?

.

Re:How?

[OblongPlatypus]

A question for you... how do you get by tying session keys to request IP? I'd love to do that for my web app, and I think it's far from pointless (IP spoofing is beyond the level of the sort of person who would try to hack my system), but I'm stumped by the fact that some ISPs (including AOL) will give its users different IPs from one request to the other. How do you handle that? Or doesn't your app have AOL-using users?

USA vs. other countries

[OblongPlatypus]

I have little to no knowledge about how the whole engineer certification thing works in the states, but I thought I'd share my situation anyway. If anyone would like to enlighten me about how it works in the states in a reply, I'd be most grateful.

I live in Norway, and I'm currently three quarters through the first year of a 5-year study to become a civil engineer in "computer technology". Although it may not sound like it, this study branches into eight different subjects, most of which are entirely software oriented. In four years, I'll graduate as a civil software engineer, every bit as much of an engineer as an engineer of electronics or other traditional engineering sciences. There are similar degrees in such diverse subjects as chemistry, industrial economics and technology management, mathematics, and communication technology.

Just read it

[the_rev_matt]

I just finished reading it, and it is mandatory reading if you are developing security these days. It covers a very broad range of situations and assumes a fair amount of familiarity with the math behind crypto, so this isn't "Teach Yourself Security in 24 Hours for Dummies".

Re:Any books w/sample code?

[joib]

I haven't read the book, but for something with a perhaps more practical approach, check out the Secure Programming for Linux and Unix HOWTO.

Some more recommendations

[Michael Schuerig]

I'm no security expert, I've only just recently started reading. And incidentally, a couple of days ago I've begun reading "Security Engineering". So far I share the reviewers very good impression.

I'd like to recommend some complementary books; each of these approach security from a different angle

• Secrets & Lies by Bruce Schneier. Deals with the "soft" issues. What are the threads to networked systems? Who are the attackers? One of the messages: Risks can't be avoided -- manage them.
• Building Secure Software by John Viega and Gary McGraw This one's closer to technological issues related to security. Risks of various base technologies (languages, middleware). Introductory details on buffer overflow attacks, random numbers, cryptography. Some organizational/dev process stuff.
• Secure Programming for Linux and Unix HOWTO
• by David A. Wheeler. Technical security down to the C-level. Programming techniques.

Michael

Re:Any books w/sample code?

[Suicyco]

There are many good articles on how to do this. Check @Stake and securityfocus. In essence, a typical buffer overflow is discovered by hammering away at software until you can reproduce a bug, by making the software crash. You then reproduce this crash using a debugger such as softice, trace the stack and figure out just what is going on memory. You then craft your input strings to hijaak the registers to point to a different location to begin executing code.

A good example is: http://www.atstake.com/research/reports/wprasbuf.h tml

Its a simple exploit of RASMAN.EXE and takes you through step by step how an exploit is discovered, researched and ultimately exploited. Its an interesting subject to say the least, but not for the faint of heart. Brush up on your assembly!