Writing secure software is hard. Technology is complicated. Writing secure financial software, creating medical devices, designing life critical systems is stressful. But what exactly is security? What is the goal?

Too often security discussions revolve around tools like formal verification, fuzzy testing, artificial intelligence, machine learning. Discussing these technologies can be similar to stockpiling locks in a drawer. It will do little to protect your house from burglars. Using the lock every single day and not losing the keys is more important than the type of lock: the number 1 recommendation of police.uk about burglaries is to always lock your doors and windows (see [1] https://www.police.uk/crime-prevention-advice/burglary/). Actually, 30 percent of burglars enter a home through an unlocked door or window! Locking your door is called operational security.

The $ 327 million NASA Mars Climate Orbiter was lost in 1999 due to an undetected unit conversion mismatch between pound-force seconds and Newton second in the trajectory calculation software.

Security is a process and not something you own. When designing and implementing a process, it is good to remember why this is done. This can keep the process on track and increase engagement. What are the goals of the security process? Every project aiming to build secure software needs a business specification that specifies what the software is supposed to do.

When NASA Mars Climate Orbiter crashed on Mars, every system component was behaving as intended and passed testing according to their suppliers. However, one of the system components was producing data in pound-force seconds while the component receiving this data expected Newton second. A system-wide specification should clearly specify the operating conditions of the system as well as its control inputs, and their units. Later on, when designing every system component, the system / business specification can be used as reference. If the requirement is missing from that specification, it is open to interpretation and different people can and will make different assumptions.

Now that we understand the importance of the problem and what it looks like, what can we do about it? Writing a business specification sounds like a daunting task to most entrepreneurs who are short in time, budget and resources. First of all, it doesn't have to be long, and it doesn't have to be perfect. The hardest thing might be to start writing it. Can you describe in one sentence which problem the software product should solve? Which actors are using it? Users, partners, staff? What actions can they all take? What actions are specific to each of them? What are the other system components (external software systems)? What are the most frequent events, their consequences, and what are the less likely events? A document answering these questions is probably a great start. For those interested in more formal methods, the UML specification, with its use cases and finite state machines can be useful.

Let us know about any method, framework or tool you like to use, or any question you may have!

In our next post we will consider how the business specification can be translated into a technical architecture. Read our introductory post here if you missed it and check out our company site at jita.digital.

If you enjoyed reading this article, feel free to like it and share it!