3 Pillars of Security at Day 1 Start Ups - Risk
Build it, sell it, then secure it. That unspoken mantra echoes down the halls of software start-ups around the world going back to ages past and resonating into the distant future. Likewise, you have security purists in every feed on every social media platform preaching the good word of building securely from the ground up. These two viewpoints are often positioned directly opposite each other. Engineering leaders warily push back against anything that would take away product development hours and security consultants wag their fingers while pointing to various standards in hopes of swaying their opponents.
The above is dramatic and a little bit ridiculous, but that is the point. The idea that security is something you worry about when you succeed or that progress should never come at the cost of security is equally wild and wrong. The core tenant of security that underpins all standards and controls is the same one that good code is built on, intentionality. Security is not the absence of vulnerabilities or even the presence of controls. Security, especially at a start-up, is the mitigation of unforeseen failure, in dev terms: Error Handling. The mark of a good security program at a new software company is the ability to gracefully recover from an unexpected error condition while having a plan for the ones you are aware of. Regardless of size or maturity there are three pieces that should be in place to comprise a security program from the beginning.
The ability to acknowledge and document risk
Multi Factor Authentication
The Ability to Categorize Critical Items
That is it, those 3 items are all you need when you start. They can be implemented at any stage, only one of them requires potential dev time, and they naturally steer you away from problems and into progress.
Today I want to talk to you about the first one.
Overview
The Ability to Document and Acknowledge Risk is effectively a paperwork exercise. Processes like this are easy for technical teams to dismiss out of hand as being tertiary to technical efforts. There is also the initial impression that this process is going to be heavy-handed and complicated. The process can be both of those things, but it does not have to be. Perfection is the enemy of progress and the same is true for this. We want to lay a foundation, that foundation will gently steer people towards the center of the road and away from the cliff.
Implementation
So how we lay the foundation is simple. Have a document like a Google Document, a tracking board like Trello, or a no code solution like Notion. When your team identifies a concern that is relevant to security it gets recorded. This could be anything from a stray thought from an engineer to a vulnerability found in a penetration test. The leadership team looks at these entries and makes one of three decisions, fix it now, fix it later, or accept it.
“Fix it” is self-explanatory, you just fix the issue right away; in most cases this will be some impactful critical issue. The other two have more to them. If you decide to fix it later, you write down that the plan is to fix it within some amount of time, any mitigating factors, and a date that this issue will be checked up on. If you choose to accept it, you write it down, denote when you plan to review this entry in the future and then someone with the authority to accept financial risk annotates that the company is aware of the issue and is not currently planning to correct it within the next year.
This document will populate over time and naturally create the company’s threat model and security risk appetite. The discourse around the identified issues and their visibility will shape the way the company builds and promotes awareness. This will also satisfy a number of compliance requirements down the road.
Whatever this document is, adding to it should be easy. Anyone should be able to easily submit their concerns. New concerns can be reviewed at a set interval and triaged.
With this in place the company can continue to move at pace while internalizing intentionality and consideration for security decisions and setting the organization up for success later in its evolution.
My last note on this is that while it might seem counter intuitive, 100% rigor with this implementation or overly strict enforcement will sabotage this program. All programs need to demonstrate value, especially if people are concerned it detracts from progress. Get a minimal set of this implemented, release the positive results and your stakeholders will help you grow it without heavy-handed enforcement.
Next time we will talk about classification and how we use that to triage our engineering decisions.