Slashdot Mirror

I don't mean to discourage you, so if you are serious about implementing a secure portal, or just learning more about secure systems development, here are some of my favorites:

By Schneier:

Secrets and Lies -- on why crypto and technology arent enough.

Applied Cryptography -- Howto make good crypto

By Viega and McGraw: Building Secure Software -- The whole process of secure system development.

Good luck and good reading!

In Building Secure Software, Viega and McGraw assert the same thing. See chapter 4, On Open Source and Closed Source.

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.

Crispin
----
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
Available for purchase

..remove the words "Well, it's okay because that box is sitting behind our firewall" from everybodys lexicon.

The point was raised above about how out of date this book would be by the time it was released. I honestly don't believe that's as big of an issue as people seem to think, 99% of the battle with keeping our networks secure is just getting people to consider the issue in the first place. Any book I can throw at our apps developers that gets them even thinking about the broad issues is a good thing, because once the seed is planted, then they come over and ask us what we would reccomend as they're working on their apps. Over the past six months we've seen the 'Ooops, you mean that travel site with the form for people to put their CC number in should be SSL'd?' to almost daily informal meetings about what they're doing and how we can support them.

Our biggest nightmare has been the sysadmins. The NT sysadmin refuses to apply any patches, 'because then things break', and won't close a single port, 'if you want features, you have to leave things open'. Lots of guerilla midnight work going on behind that boy. ;-)

Our solaris sysadmin is no better, if you could take the words 'Well, back at Siemans..' out of his vocabulary, he wouldn't have anything to say. Yet, he's very good at the above mentioned meetings for arguing that we're too paranoid, 'Only a very skilled attacker could sniff passwords of our switched network,' and this after multiple times of showing him dsniff and ettercap in action, complete with grabbing his passwords several times. Once again, lots of midnight cowboy fixes behind the back.

There's a really good book out, Building Secure Software where he brings out some very good points. The best one being that security is put on networkings shoulders, when the real problem is that the developers don't build their applications with security in mind. Therefore, the strategy is to deny attackers access to the errors in the code, when the best practice would be to remove those errors in the first place. That and the quote about ecrypting information in transit is like a guy living on the sidewalk using an armored car to send his credit card information to a man living on the beach in a cardboard box is simply priceless.

The second half of Building Secure Software has detailed chapters on: buffer overflows, access control, race conditions, random numbers, applying crypto, input validation, password systems, tamperproofing, and getting through firewalls. There's (too much) C, some Java, and a bit of python to make things real.

Security weenies tend not to understand that software lies at the heart of the security problem, choosing instead to throw firewalls and crypto at the problem and call it solved. You guys know better.

Software, the proactive security solution.

gem

Gary McGraw
http://www.cigital.com/~gem