For All The Tools Out There

Could it be there is a step or two missing in software development? And what, pray tell, does gaming have to teach us about it?

For all the tools out there, we used to secure our data. Now, we continue to see threats that successfully materialise and cause data loss. Several high-profile institutions have fallen victim to threat attackers who have made away with their data and were holding it ransom. There is, naturally, the same old song about solutions and tools we could use. Zero trust, the new kid on the block, is not a threat prevention or detection tool. It is a security model operating on the principle of “Never Trust, Always Verify.”

A lot can be said about zero trust and its value, but not today. More accurately, not during this article. Preparation always wins in my book. Vulnerable systems are created from the source with vulnerable code. While we cannot completely remove all vulnerabilities from all code, it is important to try and reduce the attack surface and chances of harbouring vulnerable code with exploits waiting to be discovered.

It’s just that other old song of security by design that we will sing about today. And, in particular, code hygiene. Code hygiene refers to best practices in software development that contribute to creating clean, maintainable, secure, and efficient code. We always say that we should know what we want to protect. A lot of the time we focus on the data we have collected, processed and/or stored, then turn away from the software involved in all these processes. Only to add on more tools and software for additional protection. Does this bloat feel like the purpose of strong security? Strong may just be the wrong term. The industry has taught us it is not about how high your walls are, but about how high they are relative to your competitor. We build these walls with new security solutions. But what value is there in protecting vulnerable code?

Code hygiene should be part of any product or service and a part of its pipeline. Not just any ol’ checkbox before go-live. An environment with good code hygiene can sustain its strength over time, monitor for weaknesses, create trust for the developers, and improve cyber resilience. It starts in the first test, no doubt. Code is often written, then tested. However, the right practice is to write the test first and then the code for that test. From there, iterate to more complex tests and more complex code. This first step allows for the automation of tests allowing for faster and more accurate tests during the build phase of the software. This is Test Driven Design. The tests traditionally have included mostly user tests. It is time to expand this to cyber security tests.

The worst thing about software development could be said by others to be the annoying architecture diagram. The latter is hard to prepare and modify. It is the blueprint for the software and how we think it would look. If the design is wrong, or we alter it without record, how can we know what we know to be true? Our knowledge base becomes the catalyst to poor code and introduction to vulnerabilities. As software evolves, we must successfully and continuously update this architectural diagram and not just with the traditional boxes and arrow keys, but with a true diagram.

When changes happen to the software, this diagram is updated within the pipeline as part of the release notes. It then ensures every version of the software has its accurate diagram. This may not seem like much. However, when looking for security solutions, we use our architecture diagrams to help understand weak spots. Think of it this way. How can you use your neighbours’ blueprints to determine changes in your own plumbing?

That takes us to coding standards. Most development teams get to see this only once during orientation. From then on, ‘write the code that works’ practice takes over. Enforceable coding standards all through is critical for code hygiene. It is how you can be sure you are actively writing code that will not have known vulnerabilities. They can be checked via automated tools within the pipeline. These reaffirm even if the code works, it cannot pass into production without meeting those standards.

Design by subtraction, the design philosophy of Fumito Ueda from game development, can help with code hygiene. Simply put, this principle encourages that less is more. In the gaming space, it speaks to the lack of over information in the players HUD (heads up display). With code hygiene, it speaks to less code, less vulnerabilities. Writing more optimised code makes it harder to include known vulnerabilities. In game development we say, “A game is never finished. Only released.” The same ought to be said for software development. Sustainability then means these practices and others to remain constantly in use not just during the development of a product or service, but throughout its lifetime.

We say charity begins at home. Well, so does preventing data breaches. It starts with us and how we build our software. Only then can we add on all the fancy tools and the latest models out there to safeguard.

ARTICLE by ROBERT YAWE