Security startup confessions: Choosing a tech partner

My name is Kai Roer and I am a co-founder of a European security startup, and these are my confessions. I hope you will learn from my struggles, and appreciate the choices startups make when security matters. I will share experiences from my own startups (my first was in 1994), and things I have learned by watching and advising numerous other startups around the world.

Today, I will share with you the challenge of choosing a tech partner to allow rapid prototyping and early product development.

In the early phases of my latest startup, we needed to build a prototype which would showcase the benefits and main features of our product, the CLTRe Toolkit. With few resources, no money and no developers, just big dreams and an idea, we were forced to look into frameworks, hosted solutions and “Build and Go” tools.

At that time, I was the most technical of the team, so I was tasked with the job of finding reasonable solutions.

I knew that we would need a server-side API with some database, and a client to interface with the API. Back in the day, I used to build similar solutions, using PHP, and I did consider using PHP for this project.

A few complications quickly surfaced: PHP had evolved quite a bit in the 15 years since I last played with it, it came with some security warnings, and I had already decided to use JavaScript on the client. And I had very limited time, certainly not enough to both learn JavaScript and re-learn PHP.

Enter Node JS, the Google project with JavaScript on the server. It was very easy to buy into the idea of one language on both the client and the server, at least it would speed things up dramatically when building, right? At least, that was my logic. And JavaScript became our server-side language, too.

I also needed a database. Back in the day, MySQL would be the choice of any cool start-up (and many others, too), but in 2014 there were many options. Buying into the JavaScript-on-the-Server hype, it took very little time to buy into the MongoDB hype, too. JSON objects, flexible models, everything made to work together.

So, JavaScript on server and client, with MongoDB. I now had the technology selected, and could move on to hosting, cloud and all!

At that point, I reminded myself that we are a security startup, and as such, we would have to do basic security right. We would need some sort of authentication system, preferably with some sort of password encryption and what not! Again, I asked Google what to do, and this time I came across Parse.com – a back-end database, hosted in the cloud, with APIs that included authentication and many other great things. Relieved, I made up my mind: let’s use Parse.com to host our database and the API.

Now, all I needed to was to build the client, and connect to Parse. Oh, how many hours and how much pain I thought I saved myself!

A few months later, a prototype was available, and people started to use it. In parallel, my software development skills had improved, too. They didn’t reach a level where I could call myself a developer, but I knew enough to start recognizing a few of the fundamental flaws of Parse.com and its security.

For example, it turned out that authentication was done on the client (yes, in JavaScript), not on the server. As if this was not enough, there were no way to remove an authentication token – once a session was authenticated, the token never expired, and it was impossible to kill it from the back-end.

I dont recall exactly when this was, but it was an easy choice to shut down our use of Parse.com at this time. They did, after pressure from clients, add a kill-switch feature later, after first claiming that they would never do so, because this was a design decision.

This experience taught me to do thorough due diligence when it comes to technology, and when signing up for technology platforms. Platforms-as-a-service, it turns out, do come with risks!

A year after we quit the Parse.com service, I get an email from Parse, this time informing me that they are shutting down the services we initially used. To us, this news was irrelevant since we no longer used their services. But the fact that a cloud service provider can pull the plug on their customers just like that, is scary. From a business perspective, this can quickly become critical, and yet again demonstrates how important it is to vet your partners and your technology.

Parse will offer these services for a while still so that clients can migrate to other services without much disruption. But customers heavily invested in their services and APIs will definitely incur a significant cost due to the transition.

(Funnily enough, I pointed out the risks involved in changes of the cloud provider business model back in the Cloud Security Rules, which we published in 2011.)

One decision I made then, and that we use as a mantra in our DevOps team today, is to never be tied up to one single technology partner unless there is no other option. This means that our current platform is built to run on any Platform-as-a-Service (we currently run on IBM Bluemix, because IBM likes CLTRe so much that we were invited to join the IBM Global Entrepreneurs program). If we have to make a change in the future – and I expect that to happen given the ephemeral nature of cloud services – we will be able to move everything to any other PaaS in a matter of days, and we can even set up our own back-end should that be needed.

The other mantra we use is “design with security first”. No matter how important a feature, or big a deadline, we start and end with security. And unlike back in the 1990s, we now expect to be breached.