In the first of this two-part series, our CTO Gavin Ray explained why security is key to absolutely everything we do at digi.me. Here, he looks at what happens when living life on the security edge gets bumpy…
Even at Olympic level, you occasionally see 400m hurdles runners clip the hurdle as they fly past. This won’t necessarily stop a good runner getting gold as long as they recover well and keep going. But if there is a more substantial collision which results in a hurdle being knocked over, it’s rare that gold follows.
In security approaches, based on engineering from-the-ground-up, we know that sometimes we will clip the fine edge of a hurdle.
We see this in the occasional alert from our internal engineering teams, who notice a new vulnerability reported in our code validation suite, or a published change in an external security flow we integrate with that has led to a breakage in our strict testing processes.
In every case, we “stop the train” – the code-line is not allowed to progress to release until the “clip” of the security target has been assessed and fixed. This is all absorbed within the team and managed as a priority inside every release.
There is another way to clip the hurdle, a little more like the effect of headwinds on a runner, which is outside of our direct control. This may happen if the world around us shifts slightly.
We run a reasonably distributed team, spanning a number of technologies and integrate across four application platforms and 12 internal development and pre-production environments. We also integrate with numerous 3rd party systems that themselves may move. The complexity of this means that, somewhere, very occasionally, there will be a small area of infrastructure change linked to code change that has an unintended consequence or even throws up a tiny error.
“To err is human, right?” But as the old saying goes, “to really screw things up, it’s best to get a computer.” In these circumstances, we have a protection mechanism built into our systems. From an external resource, we run our own continuous attack and audit tools to ensure every security angle is validated to save the bad guys needing to do it for us.
It’s a little like a hurdle runner compensating for headwind, you realise it could force errors in peak performance so you rehearse and learn to focus on the risks of failure and remove them.
Say what you do, do what you say, prove it
One of the oldest industrial quality management models is based on a beautifully simple metric. It really says, write down what you do, validate that your plans actually follow what you wrote down, then prove it.
To this end, all our security models are clearly documented. Our coding standards and source control are based on well-defined engineering docs. When we release and validate code, we have typically run 400-500 engineering tasks in every six-week release cycle and these tasks address not only features and bug-fixes, but they specifically explain every security model enhancement and its validation, how our QA team tests security and that system controls are all acting exactly as published.
As a “start-up”, we are entering our third year of production with the technologies we built managing the sharing and control of personal data, for-a-user-by-a-user.
Our challenge was always to build user trust and to ensure that the technology partners around the world who now build on our platforms grow a deep trust based on proof.
We regularly prove what we do and prove what we say – that if we ever clip a hurdle, we fix it – as a priority. But the other challenge was to enjoy the process, as the teams are not driven by long docs and boring process.
We are innovative, but need some of the best corporate traits of security rigor, without destroying the spirit of a game-changing start-up. We do the right amount of docs, and produce strong, compact designs. Simplicity and clarity are the goals. Security risks lurk within complexity and grow in long processes that no-one can understand, or follow.
Our engineering management systems (we love Jira and Confluence from Atlassian) are built and run by engineers for engineers, and everyone takes pride and satisfaction from treating this as the Olympics. It’s obviously the security equivalent of the 400m hurdles, one of the greatest races of the whole event, and we aim to win.
In the end, this means when we sit with security approvals teams from health and banking sectors or major corporates, we confidently show them what we do, tell them about how we designed it and then, prove it.