How do start-ups deal with (black hat) hackers?
SwellJoe: The vast majority of security issues we see (and we see a lot of them--systems management has been how I make my living for about ten years, likewise for my co-founder) are not related to web apps at all.  They come from basic misunderstandings of the underlying system and the software that runs their services.So, here's the first three recommendations I make to pretty much everyone concerned about security (which should be everyone with a machine connected to the Internet):1. Use strong passwords.  A strong password is 8+ characters long, has numbers, letters and optionally symbols.  A strong password is changed every year or so.  A strong password does not contain dictionary words.2. Update your software.  If you use Linux, use one that has good package management and a long lifecycle so that packages are easy to install and will be available for the three+ years that the average server is in service.  CentOS/RHEL and Debian are the only ones I really trust on servers.  Ubuntu LTS releases will do, in a pinch.  If your system does not make it really easy to do this, then you need a better OS.  Imagine the worst possible time for a security problem to show up--you're at the beach with no WiFi for miles and all you can do is call someone to walk them through the process--and if that sounds scary, then you've got a problem.  It's pretty easy to say, "OK, login to the system using PuTTY (or better, Webmin, but I won't demand that everyone run our software) and type 'yum update httpd'", or 'apt-get install apache2', if it's a Debian system.  But imagine, "OK, go to Apache.org, and click on the download link...oh, wait, click on HTTP Server, and then click on download.  Now download the latest one.  No, not to your local machine...download it to the server.  Use wget.  Yeah.  Type wget and paste the link from the Apache website.  OK, now untar it.  No, type in 'tar zxvf blah-blah-blah'.  OK, look for the previous Apache version directory, because we need to copy the default configuration over.  I don't remember what it's called..."  etc.  Careful with stuff installed from sources other than native packages is what I'm saying here.  You'll have to do it for a few things, obviously, and your own app will probably be in SVN or git, but don't make it a habit to get everything from non-standard sources.  It's just a security disaster waiting to happen.3. Don't run unneeded services.  If you don't know what it is, google it.  If you don't need it, turn it off.  If it exposes a port to the Internet, keep a very close eye on updates for that service.  CentOS/RHEL and Debian usually roll out security fixes within hours of exploits being discovered...this is usually good enough.  If your database doesn't need a public port, run it on localhost.  If you do have a separate database server, see if your host can give you a private network for your web servers and backend database(s).  Some won't even charge extra for private connections between multiple boxes in the same data center (though most will charge a few bucks).  If they're not on the same physical segment, this generally won't be possible, though.This is the low-hanging fruit, and should be standard practice for pretty much everybody with servers to manage.