Ask HN: What was the biggest challenge in securing your SaaS/service? By securing I mean building technical security to protect customer / commercially sensitive data, not securing the funding. It would be brilliant to hear both those who did, and those who chose not to care or give up in process. |
Audit log everything. If you think you have enough logging you're likely wrong. I have never seen a platform where I thought "this is nice, but I wish it has less logs"
Strong role based access controls, especially if you provide rights that can be built into custom roles. It's very hard to add these later and I can usually tell when a platform hasn't be designed to handle roles from very early on
Federated logins like SAML or Open ID Connect. Getting authentication right is very hard and it's usually better to use a well tested service rather than try to do it yourself. Codegeek mentioned not storing things you don't need. If you don't need to store passwords you've done yourself a huge favour.
Architecture reviews and penetration tests. Big organizations are going to ask for the results of these processes, so you might as well plan for it. Pen tests are nice, but bringing in outside help to do architecture reviews of your security is really cost effective. You'll catch issues at the design stage where it's still much easier to fix them. Once code is in production security design changes are much, much harder. This is an area you want someone to look over your shoulder to make sure you are considering the right threat models and building things out the right way.
* Identifying threat model (assets we are protecting, what we are protecting them against), that connects to practical business values and risks, not abstract "security ideals". In our case it was understanding what kind of data we're afraid to lose / get tampered with to what extent - for some things we might've lost a license, for other things our CEO might've had a criminal case, so different measures applied.
* Orchestrating practical security with compliance (was relevant for that product, banking -> ISO, PCIDSS and local personal data protection regulation).
* Making hard decisions on whether doing it internally (we've had these competences) or outsourcing some of the implementation work to specialized outfit. Did it internally, was great experience, but would think twice to repeat.
* Making stakeholders understand how much the showstoppers, which emerge along the way, are important to be taken care of.
I had to build this into Cachoid from day one. No funding and no extra help. I think it boils down to putting oneself in another's shoes and ask: would I use this service myself if it was best-effort work?
- Don't store any sensitive data on your servers unless you absolutely need to. For example, do you really need to store the client's address ? May be not. Think about that. The less the data, the less the risk of exposure.
- Never trust user input. Always sanitize.
- Passwords. Please use a one way hash like bcrypt and be done with it. Don't implement your own and never ever do plain text.
- Offsite backups. Don't store backups on the same server.
- Learn how to harden your server like adding firewalls, basic security checks using things like iptables/fail2ban etc. Basically, try to keep the bad guys out as much as possible.
- Check what ports are open on the server. Again, this related to the previous point but don't expose any port that you don't need to. Remember the recent mongodb debacle. Check that things are only running on localhost and not exposed to outside world.
- Encourage your users to use secure passwords. Don't make up stupid rules like "must have a number". Instead, check if the password is secure enough and then let them save it.
- For ssh access to server, turn root access off. Create a specific user to handle things. Make ssh key based authentication only and not password based.
- Subscribe to tech forums where you can keep an eye on latest security vulnerabilities and act on them as needed. HN saves so much time for me to keep an eye on what is blowing up around the tech. world.
- Of course, use SSL everywhere. Letsencrypt makes it easy. Don't be too lazy. Just install the damn SSL.
- Be careful of "social engineering". Your system may be very secure but it just takes one badly trained customer service rep or email to hack into your system. If someone requests any client access, check their credentials of who they really are. Don't just respond to an email just because it seems to come from your client.
- Finally, take a chill pill and don't lose too much sleep. Every system is prone to security issues so as long as you are doing the important things, you should generally be ok unless you are specifically the target which usually is not the case.
I disagree, I think a LOT of developers are quite arrogant when it comes to security "how hard can it be?".
Have a look at some of the answers to this reddit question.
https://www.reddit.com/r/ruby/comments/5wp0rh/how_to_approac...
1. Infrastructure security is because you don't want intruders on your servers. If you don't control access to the actual servers and your own SaaS accounts, and have systems to detect and alert when something abnormal happens, then all bets are off.
2. Data security is because my data is important to me, and I want you to keep it confidential. Store it encrypted. Encrypt in transit, even inside your network. Don't send confidential stuff over Slack. The data a customer puts into your SaaS product should be safe and secure from anyone else who wants to see it.
3. Product security options are required when selling any SaaS offering today. Build and enable 2fa. Build a feature to allow for role based access controls. Don't build any system that would enable you to send me my password in an email. This is a huge list to make.
We recently launched an open source guide for product managers of SaaS applications to use when trying to build for the enterprise. It's at https://www.enterpriseready.io. There are a few relevant sections for this conversation: Product Security, Audit Logs, Role Based Access Control. I'd encourage you to read those sections, and send any feedback. Our team has been working on problems in this space for a while now, and put a lot of time into building those guides.
I am working to get the idea validated, so if anyone would like to get in touch, I'd love to chat (be it with fellow SaaSs, or startups etc).
My email is in my profile.