This is the second blog (first one here) from a meeting of the North-East England chapter of (ISC)2, where security experts from the region used the world café conversational format to discuss a number of topics. I lead a table discussing secure software development and the topic of how to design security in from the start of a project came up as a key issue.

When a software project is nearing completion, there are typically rapidly approaching deadlines and any features that aren’t considered as part of the minimum viable product can get cut to ensure deadlines are met. Security is rarely considered part of a minimum viable product.

Depending on the product and the company there may also be strict budgets to adhere to, where money for security tools, time (equals money) for threat modelling may not be provided and towards the end of development the money for expensive things like penetration tests may simply not be there. Even security bugs may not get fixed if the budget starts to run out.

So there may be no time and no money to put security in at the end of development. Worse still, if you want to put it in near the end, it’s likely to be much more complicated to do than if you’d designed it in from the start.

How do we stop security being an afterthought?

It depends entirely on what you’re doing.

Are you a major bank adding a new API to help customers service their credit cards? Okay, do lots of security at the start and throughout development. You’ve also got money for a penetration test. Great.

Are you a start-up with limited funds creating an artificially intelligent API to determine people’s Harry Potter character name? Security probably isn’t so important, go get your product out the door before you go bust.

What’s that? Your Harry Potter name chooser accepts people’s first pet name, mother’s maiden name, first car, postcode, email address, favourite colour and shoe size as parameters to help decide your name and keeps them in a database for easy access?
Okay, maybe we should think about security a little bit at the start, no matter what it is we’re doing.

So what is the solution?

Pragmatism is clearly important, you should try not to get too much or too little security in your software, you want it just right (the Goldilocks Principle). Adding too much security can be time consuming, add unnecessary complication and detract from the usefulness of the product itself. By trying to get too much security, other parts of the business may start to put up barriers to get the necessary security into the product.

How do you know how much security you want?

Somewhere near the start of the project you need to think about security implications, then as you get more into the details of what and how the software works, you need to think about it some more.

When you think about security you’ll start to gather information on how much security you may need and this analysis should help define key pieces of security you REALLY need (minimum viable product) and which pieces you would like to have (can be done after launch). Then as the project goes on you can keep your eyes open for anything that might become important.

It strikes me as a similar to the Green Cross Code - before you cross the road, stop, look and listen, then as you cross, keep looking and listening, that way you shouldn’t get hit by a major security breach.

Training is important too of course, some knowledge of what to look for is vital to understanding your security requirements.

What about helping the business see the importance of security?

To me respect for your customers is important and with that comes security to ensure you’re not doing anything reckless with their personal information. A breach of your security can lead to a wide range of negative impacts for the people whose details are in the breach, including financial loss and identity theft.

If respect for customers isn’t too important to the business then money probably is and without adequate security the financial losses to a business can be sizeable, even causing the end of the business itself.

Security can be hard, but some thought to it early in the process can go a long way to making a secure product.