If you have been following along with my posts you will realise that my company SafeStack has been working with a range of fast moving and fast growing organisations in Australia and New Zealand. We help rethink the way these teams and companies approach security to try and bake this in from the start.

We aim to make security continuous, integrated and easy to digest, a vital piece to building for growth and sustainability.

That’s well and good but…

It’s all a bit high level and fluffy right?

Well let’s change that.

You see, SafeStack is starting to build a product of their own. An actual tangled mess of application that belongs to us.

As a security firm this is a pretty ridiculous move.

We are going to try and build it in the way we help our clients work, with security built in from day 1.

I’m going to share how we get on here and hopefully share some tools, templates and techniques as we go along. We will make assumptions, learn lessons and fall over but hopefully we can share all of this so you can improve too.

Being a security firm is far from a promise of writing secure software. We will have to work even harder than most. But if we can’t follow our own teachings and share our lessons then expecting the rest of the dev world to achieve security from startup onwards is insane.

So let’s start right now

We are in the planning stage of our product but don’t be confused — we are not green fields.

We are like every other startup or fast moving application development organisation. This is not blue skies fantasy land. The green fields have been trampled to a muddy wasteland.

The ugly truth is we are just like you

• We have existing legacy and prototype code from pre-validation phases.
• We have technical debt — lots of it.
• We have a distributed team with varying levels of technical ability.
• We have pretty much no money.

Our fears and circumstances are the same as yours and our approach to building a product will no doubt be eerily similar… albeit hopefully more security focused.

From idea onwards

Securing software from day zero means that we have to capture our ideas and analyse them with security in mind.

Requirements capture in brand new companies and projects is highly variable with some teams doing a much more detailed job than others. A lot of this comes down to founder experience level and background.

Requirements however define what we are going to build and how it needs to function. They are the framework on which we pin our code, they are part of the map for our product development.

What do we require from our requirements?

For us at SafeStack, our requirements define the features and functions of our product.

At a high level they are just simple statements like “Login” or “Export data” but we have to take those simple functional statements and turn them into a set of requirements that we can actually build.

This means breaking them down into 3 things:

• Use Cases
• Acceptance Criteria
• Security Requirements

Use Cases

This is a subject that will probably have an article all of its own but for now let’s keep it simple.

The Use Cases are a way for us to identify what role or persona will be using this functionality and what they are trying to achieve.

I will come back to roles and personas in more detail another time but here is an example use case from our product:

“As a player, I would like to reset my password when I forget it”

Nice and easy. In this Use Case, “player” is a role or persona we have previously designed or written about and the task is a simple statement that doesn’t go into any detail. We don’t put steps or exact technical elements in these statements.

Acceptance Criteria

These are the functional and non-functional requirements that must be met to say that this feature has been implemented and completed.

These are not a security specific thing. Acceptance criteria have been used for years and years as a mechanism for breaking down functionality into steps and developer obligations.

Example acceptance critera

If there is a player registered for this identifier, the system generates a link and sends it to the users registered email address.

The Player clicks on the link in their email and is sent to change password form

The Player chooses a new password

These acceptance criteria are your check list for what must be done and also a way to plan your unit tests. Each of these criteria must be met before the function is declared as finished.

Security Requirements

Security Requirements

Security requirements may change as your acceptance criteria are defined which makes it hard to spot the security impacts of the who feature. Doing this sequentially reduces this risk.

Security requirements are the things we need to build in or consider when implementing our acceptance criteria. They are the constraints that help us build with security in mind.

Example security requirements:

Example security requirements:

Password reset link or token expires after suitable period of time

Password reset link is unique

Password reset link or token is sent to registered email address for the player

Password reset link or token is suitably unique to prevent guessing or bruteforcing

Password validation must ensure password is strong

Player cannot change or affect which email address password reset link or token is sent to

Recording Requirements and Collaboration

One of the biggest challenges that many of the firms I work with have is that they don’t naturally document things. Documentation is easily outdated and a giant time sink.

We agree in many cases.

To ensure we keep our requirements documented and do so in a lightweight, time and collaboration friendly way, we use Trello.

Come and share our templates

We have developed a set of template cards and boards that allow use to create new requirements easily and work on them across multiple countries and time zones.

The beauty of us using Trello like this is we can share our templates with you.

You can find these templates at https://trello.com/b/l8WpTtQK/security-templates

Feel free to come and have a look, perhaps try them out.

We will be adding more templates to this board as we go along so feel free to send us your comments, improvements and feedback. Perhaps then we can bring a good free set of templates to any new development team who wants to bring security in from the very beginning.