
Ask HN: What was the biggest challenge in securing your SaaS/service? - giantahead
By securing I mean building technical security to protect customer &#x2F; 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.
======
theluketaylor
I can offer some advice from the other side of the fence as someone who
evaluates potential SaaS platforms for use in an enterprise.

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.

------
9gunpi
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:

* 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.

------
jjoe
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.

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?

------
codegeek
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:

\- 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.

~~~
dublinclontarf
> We all know that

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...](https://www.reddit.com/r/ruby/comments/5wp0rh/how_to_approach_replacing_a_custom_authentication/)

------
marcc
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.

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](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.

------
graystevens
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.

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.

------
vixentael
I wonder how you calculate money loss, if your service is hacked.

