HN Books @HNBooksMonth

How about Practical Unix & Internet Security by Simson Garfinkel and Gene Spafford. Too old?

http://www.amazon.com/Practical-Unix-Internet-Security-Editi...

⬐ mvlad

I think the target audience is different.

For people really interested in crypto there's obiously HAC [1].

For people interested in something that is updated each year: LNCS from DIMVA and RAID are quite good for understanding the problems or future problems and their solutions.

And of course phrack?

[1] http://cacr.uwaterloo.ca/hac/

"gaaa!" is an entirely legitimate response to this and the same one I had when I looked at it in the middle of last year (and I've been playing the game since 1980 (sic), but not since 2000 ... the threat environment has exponentially increased since then).

I'm afraid my only recommendation is not immediately useful, which is to start reading/skimming a 1,000 page book, Practical Unix & Internet Security, 3rd Edition by Simson Garfinkel et. al. (http://www.amazon.com/Practical-Unix-Internet-Security-3rd/d...).

But's that reference is only "a mile wide and an inch deep* (from the Amazon.com reviews).

How much time do you have? How much flexibility in choosing your OS (e.g. is OpenBSD or a Linux that really implements SELinux an option)?

And there are so many details today, like how do you get adequate entropy for your RNG on a VPS?

Gaaa!

⬐ nfnaaron

"But's that reference is only 'a mile wide and an inch deep'"

So maybe that's an overview/jumping off point?

I've run FreeBSD at home years ago. I'm on slicehost for now, the and linode offer mainstream-ish linux.

My concern with *BSD, or a less mainstream Linux, is the difficulty it may introduce in developing and running apps based on the many ready-made tools and frameworks available. Good security vs easy development. "Gaaa!"

⬐ hga

If I was starting fresh, that would be my jumping off point. It will orient you, it develops a good philosophy and it will allow you to build your own priority ordered lists (which you probably won't be able to find as such, since things are so unstandardized (and therefore exciting!) right now), and then you'll know what to drill down to with Google et. al.

And, yep, you've outlined one fundamental tradeoff, but in server space this should be less of a problem. But I wouldn't be personally adverse to starting out with a distribution with a serious SELinux implementation (e.g. Fedora, but that has an upgrade problem). Of course SELinux just by itself is somewhat complicated, but it's the only defense in depth solution I know of. And I want one of those in addition to making the "crusts" as hardened as possible.

One thing I'd think strongly about is getting one foundation in place ASAP: disaster and intrusion recovery.

Just like the second thing I do after "Hello, world!" in a new programming project is to set up a good logging system, being able to recover from "man caused" and other disasters will help you a lot until you're a Uber Security Guru.

Ask me if you're responsible for keeping customer information secure ... that's its own can of worms and one that's I've worked on myself.

⬐ nfnaaron

"Ask me if you're responsible for keeping customer information secure ... that's its own can of worms and one that's I've worked on myself."

I'm one guy, building a web app up from nothing. So yeah, I'm responsible. :-/

My initial approach is to never have a CC number touch my server, and to absolutely limit the amount of information I need from users. Nevertheless, I do want my users' data to be as private as they make it, and I don't want to find myself hosting inappropriate stuff from breakins or "users of convenience."

⬐ hga

You've got the right ideas. (And I've been there WRT to the "users of convenience", not fun but one of the less harmful attacks ... unless they use you to spam.)

There's the usual set of things to do with your less sensitive user information: salt and hash passwords appropriately, make your password reset system sane (non-obvious security questions if you go that route), and then as a first step I'd just harden the data on-line. Perhaps encrypt the disk copies so that simply grabbing files won't be sufficient, raise the bar sorts of things.

Simson's book very quickly goes into policies: risk assessments, trade-offs, all that. Get minimally organized there and you can then do something like this:

  What's the threat level?

  What's the cost of compromise?

  How much effort should I put into this?

Then what you should do will be more obvious.

Oh yeah, one thing I forgot to add, in relation to Travis and my suggestions about recovery: have some minimal automated intrusion/modification checks, so you'll have a chance of knowing your system has been compromised.

⬐ nfnaaron

Thanks lots. Encouraging to know, based on responses, that I'm thinking in some of the right directions.

ocean large, boat small

⬐ hga

You're very welcome.

A lot of this is just common sense and thinking things through ... you've already made the only step that really matters, which is taking the issue seriously and proactively.

Good luck, and if you have any specific questions in the future I'm always game; my email is in my HN profile.