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.
I can offer some advice from the other side of the fence as someone who evaluates potential SaaS platforms for use in an enterprise.<p>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"<p>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<p>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.<p>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.
Having worked on SaaS products with high demands to security before, and having spent a serious chunk of people's hours on building security infrastructure around it, I'd say the biggest challenges were:<p>* 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.<p>* Orchestrating practical security with compliance (was relevant for that product, banking -> ISO, PCIDSS and local personal data protection regulation).<p>* 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.<p>* Making stakeholders understand how much the showstoppers, which emerge along the way, are important to be taken care of.
Google 2FA, AWS S3 encryption at rest and its integration with the micro services, ModSecurity integration for Varnish, E2EE for SSL/TLS, infrastructure and micro service security, etc.<p>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?
Security is hard. We all know that. But there are many low hanging fruits that you can do with a little bit of effort. A lot of people ignore even the low hanging ones. I am not an expert but I have a list that I try to follow at the very least:<p>- 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.<p>- Never trust user input. Always sanitize.<p>- 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.<p>- Offsite backups. Don't store backups on the same server.<p>- 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.<p>- 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.<p>- 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.<p>- 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.<p>- 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.<p>- Of course, use SSL everywhere. Letsencrypt makes it easy. Don't be too lazy. Just install the damn SSL.<p>- 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.<p>- 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.
You really need to think about security as a few distinct, but related parts. There's (at least) infrastructure, data and product security to consider.<p>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.<p>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.<p>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.<p>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 <a href="https://www.enterpriseready.io" rel="nofollow">https://www.enterpriseready.io</a>. 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'm working on a SaaS in this very space - helping businesses to secure their customer details and identify data breaches early, so that you can be proactive in your mitigation and cleanup.<p>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).<p>My email is in my profile.