Product

It’s Time For You To Make Security a Core Feature — Not a Tax

echojason@gmail.com'

Jason Lemkin

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 …

NUP_168822_0856.jpgMaybe 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?

So …

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.

Screen Shot 2015-10-21 at 9.14.14 AM

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.

Screen Shot 2015-10-19 at 2.34.54 PMAnd 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.

Published on October 21, 2015
  • Great post. I’ve seen so many examples of these behaviours working in both private and public saas companies over the years.

    De-provisioning is a huge problem when you consider all of the saas apps being used outside of IT’s knowledge. The funny thing is as creators of early saas tools we fundamentally contributed to this problem. With my first saas company litmos.com part of our pitch was always, you don’t need to bother IT, just sign up and get started, get productive in minutes etc.

    My latest company thisdata.com is set to solve this problem and many of the other common issues that manifest in fast growing cloud native companies. Its a super hot space and we’re excited about delivering innovative solutions to this fast growing problem.

  • Love the post Jason! Definitely this is someone we think about in Eventfuel.io as our client’s customer data flows through our system. And we do everything we can for a wholly bootstrapped company to secure that. But making the leap to be an “enterprise grade” system seems like a chasm of challenges.

    If you have a big enterprise client driven by end user adoption, how do you transition from being outside IT’s knowledge/focus to going through a security audit and being approved without bringing down the wrath of the IT department and being offline/de-provisioned (with no income) for potentially months?

    My only guess is go through the “official” process hand-in-hand with an IT department of another big client, get approved, then take that knowledge back to the clients without IT approval and approach their IT departments with all the information they might need to try and minimise any downtime for the users in that business.
    Would anyone disagree with that strategy or have an alternative?

Share This