So many things have gotten better on the product side of SaaS in the past few years. Amazing tools, the evolution of AWS as “enterprise grade”, so many great things.
One thing I am less impressed with though is the evolution of SaaS security — application-level security, in particular.
Let me give you two recent examples from Public Unicorns.
Public Unicorn #1: Extremely broad access to my “encrypted-at-rest” data. Recently, a public company SaaS app whose product I use threw a big error in my data. After some escalation, I was routed to a contractor in support. Not an employee, mind you, but a contractor. A temporary one, in fact. She went straight into my “enterprise” account (without any permission), showed me my data … and changed it on the fly.
Problem solved, yes. But …
Maybe you are OK when this happens at say, AOL or Yahoo! Mail. I’m not. But in any event, the fact that thousands of employees and contractors, in an enterprise environment, can access and change my data on their own is … troubling.
Yes, maybe it makes for a better customer support experience. Maybe. But it’s not OK.
Public Unicorn #2: Failure to de-provision ex-employee accounts. In another recent meeting, I was helping with recruiting a potential hire. He had worked at a public SaaS company that I was well aware of, but had never actually seen or used their product. Not a problem! He gave me a live demo! This ex-employee (who had been gone from the public SaaS company for months) logged in using his old user credentials and showed me his account.
Not OK. Isn’t this what we have LDAP, SAML, 2-factor this and 3-factor that for?
If these Public Unicorns have these basic application-level security issues, what else is lurking beneath the surface? You know when you see one flag, there’s another 10 to follow …
And so …
If you think your little SaaS application is so safe and secure because your co-founder told you so. Let me tell you. It isn’t. It’s not remotely secure.
In fact, the only reason you haven’t been hacked, most likely, is because you are too small and boring. Not worth the trouble. No one really cares. Or put differently … because of The Grace of God.
You really think you are so much smarter than Target, than Ashely Madison (who got a lot of things right), than all these guys? Of course you aren’t. With your security team of Zero Full Time Employees.
Ok. Fair point, you say. Getting nervous. But what can I do about it?
Let me help. It’s SaaStr. So let me boil it down to a fewer actionable steps. To at least making things better.
- First, until you have your first real Enterprise customer with a true security audit — do the best you can. Just do the best you can.
- Then, you’ll go through your first security audit. Don’t roll your eyes. Don’t shrug. Don’t let your team push back. Here’s the Trick, the Hack — It’s a Gift. A detailed, written security audit. Because It’s Your Roadmap. It’s Your Necessary and Brighter Future. The first time you get one of these, it will be 20 pages and 100s of questions. And you’ll fail a lot of them. And you’ll only sorta, kinda pass a few others. It’s not OK, but it is what it is. If there are 200 questions, and you can only answer a clear “Yes” to 20 … use the other 180 as part of your product roadmap to a better future.
- Take all the security items you fail on, and devote at least 15% of your dev budget to them. For every release. Forever. Maybe even more than 15%. With no excuses.
- If you can, do something like Salesforce Appexchange certification early. This will force you to be better.
- And finally, once you hit $10m ARR at the latest, hire a full-time Chief Security Officer to manage this. Take it away from your VP of Product or VP of Engineering.
And if you do this … and use your SecOps audits as an integral part of your new Product Roadmap (at least, a piece of it) …
- Security will no longer be a tax. Because instead of dealing with it as best you can, you’ll be dealing with it every single day.
- You’ll win more deals. Turns out, this approach more than pays for itself. Wait until you lose a $100,000 deal because you don’t have a proper Incident Response Plan, or a true approach to DR, or back-up that actually works, or a properly encrypted key-store, or whatever. Fix this stuff, and make it a core part of product … and you’ll win more deals.
- And it turns out you can charge for this … indirectly at least. Enterprise customers will pay more for the most secure product. They may even pay a lot more.
Security. It’s a big and broad topic. And the more you learn, the scarier it can be.
Just do this to start. Make it a core part of the roadmap for every single release, for every SCRUM, for every discussion.
And you’ll come out way, way, way ahead in the medium and long term.