Ask HN: Best security practices for startups

13 pointsby sithuabout 10 years ago

Hi,My partner and I plan to launch a healthcare-related web app in the coming months. We'll be hosting on AWS, with the database on an encrypted EBS volume, all conncetions over HTTPS and we should have two-factor authentication by SMS. We're mostly using the MEAN stack.I'm not technical, so I'd appreciate some guidance on best security practices that are relevant and feasible for a startup. I doubt we'll have anything financially useful to steal, but my main concern is avoiding leaks of private patient data, of which we might store a limited amount.1. Is there a checklist/best practices guide somewhere? I'd like to avoid making obvious mistakes that would be embarassing in retrospect, though I know it's hard to defend against someone skilled and determined.2. Any experience with hiring a firm (like Matasano) for penetrating testing? Rough estimate of cost? When is the right time to consider this?3. How and when to start a bug bounty program? Is there a standard way to determine severity and payouts?Thank you!

6 comments

andrewjshultsabout 10 years ago

FWIW - even inside a VPC on AWS traffic isn't encrypted by default so if you're dealing with PHI traffic between servers also needs to be encrypted. Many databases support this out of the box, but if you're using something like redis you either need to use ipsec or stunnel. Google's Compute Engine platform does support encrypted network traffic so that' s nice plus (we're multi-cloud so we're currently using stunnel and moving to ipsec).Lock out the root AWS keys as much as you can (ours requires a MFA token that's stored in a safe) and only use IAM users with restricted permissions for day to day operations.Everything should have an audit trail, preferable with all the logs shipped off the servers to a centralized store (that way if a server is compromised the attacker can't also edit/delete the logs)Script all your boxes through config management so that you can handle updates/security patches in a uniform manner and quickly.Restrict who has access to root/DB in production. When you grant access keep an audit trail of why they have access and revoke it if it's no longer necessary. Have a good development environment setup so people don't develop the habit of developing against production.Pentest + bug bounties are good. Once you get to a certain point you'll probably also need to have a general security/HIPAA audit as well.

评论 #9281934 未加载

wilburloabout 10 years ago

It's hard maintaining great security because, security and speed are usually in direct opposition.In terms of hardware/OS: Turn off everything incoming except for HTTPS, SSH, and ping (optional). Make sure everyone uses SSH keys (no passwords)In terms of programming, focus on security roles is tricky at first. So you want to be careful in describing how user roles or user permissions work in your site.Create a staging server with test data that mimics your production site (nearly exactly). Any penetration company company will ask you to sign a "This won't hurt anything", when smashing up your server.Another place to focus is how backups are copied, who can access the data, etc..This is a really big topic. Your insurance company when you apply will have an excellent check list.

评论 #9280136 未加载

评论 #9279769 未加载

jerematasnoabout 10 years ago

Sithu,Here are a couple of resources that I tend to hand out to startups that we do work for at Matasano. No charge :-)Not trying to be a salesperson, but I feel like most startups get more value out of sitting down with a security consultant for a couple days and talking about architecture and dev processes then they do getting a full penetration test. Like the presentations say, the big risk in the early days is lack of interest, not security. I feel like a startup's big security concern it doing something that's going to make them have to rewrite everything later on.<a href="http://chris.improbable.org/2009/9/24/indie-software-security-a-~12-step-program/" rel="nofollow">http://chris.improbable.org/2009/9/24/indie-software-securit...</a> (old presentation from tqbf. We might one day put it back on our blog. Don't hold your breath. Anyway, the slides and presentation aren's great IMO, but the blog post is!)<a href="http://firstround.com/review/Evernotes-CTO-on-Your-Biggest-Security-Worries-From-Three-Employees-to-300/" rel="nofollow">http://firstround.com/review/Evernotes-CTO-on-Your-Biggest-S...</a>

panoramaabout 10 years ago

I'm not too familiar with the field, but I'd also assess whether or not the data you're acquiring needs to be encrypted/handled in a certain way due to HIPAA-related compliance. That's potentially the most relevant worry you should have if your developer(s) are decent enough.

评论 #9279720 未加载

jtfairbankabout 10 years ago

Checkout aptible [<a href="https://www.aptible.com/]-" rel="nofollow">https://www.aptible.com/]-</a> they do hippa compliance as a service.

dsaccoabout 10 years ago

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: <a href="http://breakingbits.net/2015/02/28/security-for-startups/" rel="nofollow">http://breakingbits.net/2015/02/28/security-for-startups/</a>. 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: <a href="https://medium.com/@magoo/security-breach-101-b0f7897c027c" rel="nofollow">https://medium.com/@magoo/security-breach-101-b0f7897c027c</a>. 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.

评论 #9281918 未加载

评论 #9281160 未加载