The news from the mobile markets continues to get worse, so I’ve been thinking about SaaS as a business (SaaSaaB?).
For those of you running such businesses, how do you handle having your software/customer data exposed to hackers 24/7? With a pure mobile app, about the worst things that can happen is that it is crash prone or it is pirated by people who wouldn’t pay for it in the first place.
This is why (perhaps to my detriment, though I’ll never know for sure) I didn’t do HelpSpot as SaaS. At this point though you can handle hosting pretty easily. The main thing really is that when you start out you’ll be so small with so few customers that basically you’re A) not worth hacking other that if you have some server setup that can be automatically exploited perhaps and B) even if you go down for a bit you won’t have so many customers so only a small number or likely to be affected by it. By the time those aren’t issues you’ll have enough money to have at least some part time help most likely.
Security is tough, but if you write/do as little as possible, it’s easier:
I made a decision to use a third party accounting platform as my biggest “sleep at night” decision. We offload all the transaction data to xero.com as soon as it comes back from the Payment Gateway using a background worker task. They are much better at all those legal and security responsibilities than we are!
You have the basic options:
In practice, the learning curve is long enough that you will want to start sooner and bite it off in small chunks.
Relying on mature frameworks is helpful, but sometime exposes you more, especially as you won’t necessarily know the best practices for configuration and deployment. There are entire workshops on securing a rails installation for example. Relying on obscurity won’t help for very long. I’ve seen brand new virtual servers at DO and Linode get hit with attempted root logins within minutes.
The good news is that web app security is not hard, just broad.
You can get a good head start on devops security w/ a google search:
For the web app stuff, start w/ the security section here:
http://programmers.stackexchange.com/questions/46716/
For application specific things, google searches for “securing postgres” or “securing django” will get you 70~80% of the way there.
Again none of this stuff is hard. The initial range of vulnerabilities is so broad however. Ask, ask ask and learn.
There’s a strong case to be made for using a mature development framework, but that in itself won’t save you from being hacked. See two great posts from @patio11 on Rails security issues as proof: Security Lessons Learned From The Diaspora Launch and http://www.kalzumeus.com/2013/01/31/what-the-rails-security-issue-means-for-your-startup/. I love Rails, but I’m under no illusions that it is a silver bullet for security. The code I write still needs to conform to best practices, and in order to ensure that, I perform regular security testing and scanning of apps in development.
As for servers, I don’t know enough about Heroku’s architecture to be able to say whether or not they provide a higher level of security. In terms of servers though, the biggest risks come from running unpatched software and/or exposing unnecessary services to the network, and this is a problem common to both physical and virtual servers. To minimize potential threats, it’s important to harden your server (or base server image) before putting it into production and to keep up on software patches.
I’m a Rails freelancer when I’m not working on WiseCash.
Early on, I decided to look for a a hosting company that I could outsource most of the stuff too.
I know how to properly provision and secure a server, but I really wanted to save time.
I ended up using EngineYard (PaaS) and their premium support (which gives a 24/7 proactive support).
The premium support is roughly at $150 extra, but then I can go on week-ends and I definitely sleep well at night now 
Hope this helps!
– Thibaut
Depending on where you are in the world, it might not be that expensive to hire someone to do some customer support for you during your nighttime hours. That person could also have a phone number to reach you at in case the s**t hits the fan and you really want to be woken up to fix things. For LiberWriter, I pay less than $100 a week for someone who does a great job answering support emails while I’m sleeping.
I have a ton to say on this topic (in the region of 50k words in fact) but relevant to this thread, I would just say that the absolute minimum effort required to protect yourself from the lowest hanging fruit would be…
This will absolutely not prevent attackers from exploiting vulnerabilities within your application, but without the above the cost to attacker is effectively zero for a script-kiddie using metasploit. With a patched application and no other time spent on security, you raise the cost from $0 to say between $1k-$50k (for example, one to fifty days of a determined and sophisticated attackers time).
Raising it beyond that point is the primary subject of my book, but to summarise: rather than focusing entirely on countermeasures, you need to understand the threats in as much technical detail as you can manage. Then you will be able to:
Hope this helps!
The “sleeping at night” bit has been a concern of mine, too - my development background is in desktop apps, and the thought of a problem making my app unavailable to all my customers at once is a bit scary… Partly a function of needing to educate myself more to boost my comfort factor…
Everything is a tradeoff, so, yeah, if it goes down, a web app is down for everyone. On the other hand, it’s super easy to upgrade it for everyone, without worrying about people having some ancient version sitting around.
Security threats aren’t my main concern (very likely you aren’t that big yet). My main concern being one-man-show is the quick response to customer support tickets or unexpected errors/bugs on the platform. It happens to all of us.
In my experience (9 years running a SaaS solo) response time isn’t the problem. In fact I have been able to push bug fixes to the server in response to customer complaints very fast (I forget what my record is, possibly as little as an hour).
In larger companies, when a support agent receives an apparent bug report it has to be escalated to a developer before it can be confirmed to be a bug and put in a queue to fix.
As a one-person co, when a customer writes about a bug, the developer gears in my head are immediately turning. I may go look at my codebase before I even reply. Often I have a pretty good idea what the problem is within minutes of getting the email and I’ll get to work fixing it right away.
The key as a solo SaaS dev is to have lots of automation, and solid rollback/undo capabilities. 1 click deploys, instant rollbacks if desired, the ability to give select users a specific version of the code (unless there are DB schema changes), deep monitoring (New Relic) are all conducive to giving you the solo dev the confidence needed to move fast to take care of your customers.
Good luck!
How are you able to do that while you are sleeping/travelling/out of internet connection?
This is an optimistic case.
But what if the customer discovers a defect that blocks their execution, and requires a few days for you to make changes and test?
That happen to me at least once. A team of some 30 people is waiting, some expensive LT environment is waiting, and I was working day and night with barely some sleep, very dizzy at the end. I was lucky I did not have other scheduled work a that time.
And no, I do not have a good solution for that.
It’s the most common case in my experience. The majority of bugs I have been called on are fixed by changing only a few lines of code (sometimes one).
I sympathize with your experience though. I have made my share of mistakes, and I’ll never forget what it was like to try to fix things in a mad rush while stewing with stress and anger and fielding angry phone calls at the same time. It’s completely brutal, probably the most challenging professional experience of my existence.
But it is also highly exceptional. I’ve had one 5-alarm “fire” and two or three 3-alarm in nine years. It sounds like your incident was exceptional too, as it should be.
All businesses are subject to sudden “fires” that have to be dealt with. (If you run a brick and mortar it could literally be a fire.) When that happens we deal with it as best we can. Maybe our income suffers a bit but it is probably not the end of the world.
I understand your question now. Well, you can’t. Or you can stop going on vacation and never disconnect. But who wants that?
The most important thing is to be in a market that can handle a bit of downtime. Pretty much every service out there has had some down time so don’t think your business is toast if you go down for a bit on a vey occasional basis or if you take a couple of days to answer a question.
If you build your service correctly it should not go down regularly. It will go down, but not regularly. So most of the time you’ll be fine.
Sleep: I used to have my monitoring system wake me up. After a few too many false positives, and with the system growing more stable after a couple of years I just sleep.
Vacation: There is internet pretty much everywhere now. Take your laptop with you obviously. I have T-mobile’s plan (in the US) that works in most countries. With today’s smartphones you can answer questions from that device quite readily. If you get a notification that something really is broken, you can head back to your hotel and pull the laptop out and get to work. I think I’ve only done this once, where I debugged something from a high-speed train over an intermittent 3g connection. You make do.
[grandpa voice] When I started I had a dumb-phone and could hardly get away from my computer for fear that I was missing a notification email. Getting a Blackberry Curve was the most liberating experience. [/grandpa]
Offline: This one is a tough one. I love camping in the wilderness, but it was hard to do because I was always worried something would happen to my service and I wouldn’t know about it. Here again the increasing stability of the system and my trust and understanding of it is what allowed me to eventually disconnect for three days without worrying too much.
Here are a couple extra things I learned: