Ask HN: Best security practices for startups

Hey Sithu, my name is Dylan. I work at Accuvant, a security firm like Matasano. We work with a lot of the top tech companies and Fortune 500.

I sent you an email, and I'd be happy to answer any of your questions or help you out (no charge). Down the line, if you decide you'd like to explore a security audit, we can help with that too.

For now, I'll answer your questions:

1. I wrote a basic checklist for startups looking to improve their security. You can find it here: http://breakingbits.net/2015/02/28/security-for-startups/. It's not comprehensive, but I tried to cover the most common issues I saw with startups. Ryan McGeehan also wrote a wonderful checklist for incident response after something does happen. They're two sides of the same coin - preparation and damage control. Check that out here: https://medium.com/@magoo/security-breach-101-b0f7897c027c. Your specific company will have more to do for each of these based on the context of your team, product and size.

2. It's difficult to give a good estimate of cost, and I'm not trying to be a salesman here. It depends on length and scope of work. Are we doing code review or just blackbox testing? Five days or 10? The entire application attach surface or just a few critical pieces of functionality? Budget about $10,000 for a white label pen test lasting a week, but it could be more or less. I'm summoning 'tptacek here in the hopes he might have more nuance to contribute to this answer.

3. How and when to begin a bug bounty program is similarly variable. I have a lot of experience working with Series A companies, and bug bounties are a personal specialty of mine (I have research directly on the subject). In my opinion, you should not have bug bounties until you have at least one full time security engineer. You don't want to pay out a bounty for someone reporting that your cookies lack an HttpOnly flag. On the other hand, server-side request forgery usually warrants a payment. If you have developers who could tell you the difference in those two in terms of both definition and severity without looking it up, you're okay to have a bug bounty. If not, don't pay people for their reports just yet. (This is personal philosophy from my experience - many people will have different opinions).

On the other hand, always have a responsible disclosure program. It is perfectly okay to not reward people for reporting security vulnerabilities. I'll repeat this: it is perfectly reasonable to not give out payments for reports. Don't let financial rewards enter the program until you have reached a certain level of internal security maturity.

And no, there is no standard way to determine severity and payments. Google and Facebook pay a lot for bugs that some companies wouldn't even accept. It totally depends. That said, as a general guideline, if a reported bug 1. is valid, 2. compromises users, it's worth something.

Like I said, I sent you an email. Let me know if you have any questions, I'd be happy to help you with anything you need to know.

Thanks for your reply! Very helpful. Got your email, and will be reaching out to you.

EC2 S3 yes (this should be easy as S3 has ssl support out of the box). The bigger issue is stuff like redis (which purposefully doesn't support encryption) which means you either need to be careful not to put PHI in redis (e.g., use object IDs rather than the object themselves, don't cache things that might have PHI) or use something like stunnel (which doesn't play lovely with redis), ipsec, or use GCE.

I'd recommend encrypting from the boot volume up and not just your EBS volumes. Otherwise you have to worry about things like PHI in logs, core dumps, etc. being put onto unencrypted storage.