Live data from Hacker News

Ask HN: Best security practices for startups

news.ycombinator.com

1–10 of 16 posts

Ask HN: Best security practices for startups

#1
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!

Re: Ask HN: Best security practices for startups

#2
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.

Re: Ask HN: Best security practices for startups

#3
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.

Re: Ask HN: Best security practices for startups

#4
post #3

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.

HIPAA is surprisingly vague about the minimum standards for compliance, calling encryption "addressable" instead of "required"[1]. I believe this goes for both data in transit(HTTPS), and data at rest. I've seen some say that HTTPS is required but I can't find this on the gov site. My understanding is that if you choose not to encrypt, the burden of proof is on you should anything bad happen, to prove that implementing it was not "reasonable and appropriate". Since I can't think of any circumstances where sending plain text patient info over the internet is reasonable, i'll choose to encrypt. The other things for HIPAA compliance are complete audit logging so you can see who has accessed anything, and training of staff who have access to protected health info.

Most HIPAA recommendations seem to be a good idea to do anyway.

[1] http://www.hhs.gov/ocr/privacy/hipaa/faq/securityrule/2001.h...

Re: Ask HN: Best security practices for startups

#6
post #2

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 sta…

Interesting, any recommendations for companies selling insurance for this? Affordable insurance for small companies?

Re: Ask HN: Best security practices for startups

#7
post #4
post #3

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.

HIPAA is surprisingly vague about the minimum standards for compliance, calling encryption "addressable" instead of "required"[1]. I believe this goes for both data in transit(HTTPS), and data at rest. I've seen some say that HTTPS is required but I can't find this on the gov site. My understanding is that if you choose not to encrypt, the burden of proof is on you should anything bad happen, to prove that implementi…

Hire someone who has done HIPAA before.

Re: Ask HN: Best security practices for startups

#9
post #2

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 sta…

> Turn off everything incoming except for HTTPS, SSH, and ping (optional).

OP mentioned using AWS, in which case Amazon's built-in "Security Groups" feature can be used for restricting access to the instance by port or possibly by protocol. Naturally, however, one would not want any dangerous outbound traffic, such as unencrypted/unauthenticated automatic updates, so there also is merit in controlling which services and programs are running.

Re: Ask HN: Best security practices for startups

#10
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.

Post reply on HN