In the first of a two-part series, our CTO Gavin Ray explains why security is key to everything we do at digi.me – and what that means in practice
Security is the equal and opposite of the threat you face.
It almost sounds too simplistic, but it really is true that the only purpose of security is to counter threats.
Where most people go wrong is that they see security as a thing, a bolt-on of some kind to be put somewhere: a piece of secure code welded into the app, a crypto algorithm inserted here and there, or a software package to install inside a core system that stops something bad happening.
In building the digi.me team and the original product roadmap, we decided that security had to be woven into the fabric of the engineering team and the day-to-day business operations.
It’s fair to say that in many startups, this is viewed as a second order objective, which sits behind the illustrious MVP, that minimal value proposition that so many people aim to prove their point with.
In many markets, it’s a great plan; build a skinny app or service that seems real, then grow it in layers as you learn what the market (and investors) will give you money for.
For digi.me, we had a mission to securely manage personal data, for the individual, as their proxy. This means our MVP was a secure app from the outset – that’s a pretty expensive and high effort MVP, but you don’t turn up to a gunfight with a knife, right?
From the beginning, we knew we had to allow users to trust their own data security and to do that we had to be the equal and opposite of any threat to personal data security and privacy.
How high is the security hurdle?
To give you an idea of how we approached security, we looked at it as a problem defined by well-motivated, well-funded smart people who want to get at a user’s personal data because it has value.
Whether for identity theft or simple commercial re-sale of private data, it’s pretty obvious there is a clear market value if the bad guys can go and crack the storage to get details of someone’s personal profile, all their online activity and their finance or health records.
That is what digi.me protects for the user, and so for us to be successful we have to establish our own credentials and build a reputation for security and trust around the way our app captures, stores and manages consent, and ultimately shares users’ data under their control.
The security hurdle is therefore as high as those defined by international electronic banking and electronic health standards, which are genuinely rigorous.
Imagine what that means for a company with under 100 engineers – we are working to the same standards as multi-hundred or thousand-engineer companies in the finance and health sectors. So we had to get smart and build a highly organised approach.
Leaping the hurdles
The analogy moves from that of a high jump to a hurdle race – and there are a long line of hurdles to be passed in saying “we protect your data and are secure”.
To reach the level of security approval we require, we treated everything as a security-from-the-ground-up problem and designed it into our day-to-day engineering activity and team evolution.
To give you an idea of the challenge, before we talk about how we met it, the hurdle race analogy meant we need to have secure approach to each of the following obstacles:
- Write code to a high security standard so there are no known “hacker” holes – or even pin-pricks hidden anywhere in over 500,000 lines of code spanning multiple application platforms on mobile, desktop and cloud.
- Create a secure storage model that spans mobile/desktop apps all the way to personal cloud storage that is outside of our own domain, meaning our apps and secure cloud services are encrypted and secure end to end.
- Build a cloud service that can process user data between their digi.me app and their online services (like bank, hospital, Facebook, Fitbit etc) without looking at it, taking copies or putting it in harm’s way.
- Build a security and cryptographic key chain that would do everything known to the industry today to make the bad guys’ lives miserable. Bearing in mind they love cracking this kind of thing, that’s a very high hurdle.
- Teach our entire engineering team how to write and manage code in a way that removes all major areas of infiltration and protects us from all the known techniques adversaries will use to try and infect our apps and cloud services.
It takes time to build the team and dev processes around this, but that is why its essential to run a long-range roadmap that is split into layers.
The layers of a good roadmap include high level features that are negotiated with the business teams and a low-level security infrastructure roadmap negotiated with the security gurus.
But that’s not enough, you need at least two more intermediate layers showing the rolling plans for dev efforts to refine and validate security implementations between different application and cloud platforms; and you also end up with a security roadmap where you expand the way the internal application layer merges with the underlying infrastructure.
In the next installment of this blog, we’ll talk more about living life on the security edge, and what happens when we clip the fine edge of a hurdle…