How to argue for better software security
Software security is hard. Developers don’t focus on security regularly. Before you can begin to make your software secure, you have to convince your organisation, your team, and yourself that security matters at all.
In this article I’m going to give you ammunition for that debate. I’ll argue from multiple angles that software security is worthy of your time, focus, and effort. As someone that talks to my clients about security regularly, I’ve had to develop these arguments to contend with people who aren’t motivated to act on security. Hopefully you’ll find use for these arguments too.
There is a well-established argument from capitalist self-interest. If your software suffers a major public security breach, this puts you at a number of disadvantages as a company. Your investors will lose confidence in your continued operations. Your customers will feel less inclined to use your offering, for fear of the potential negative impact of a security breach on them. Your engineering team might find recruitment more difficult if your company has a reputation for technical incompetence. All of these problems are multiplied when a company is unprepared to handle the PR fall-out of a security incident.
Additionally, if your company operates in a domain who’s technical operation is regulated, you may have legally enforced obligations to comply with some established standard. This line of reasoning usually leads to the most cynical security theatre, so you would want to include this in a broader conversation about security rather than on it’s own.
This set of arguments is best employed with non-technical management. It works better with details of three well-chosen examples of security breaches, noting the bottom-line impact the breach had on the company in question. Your goal in doing so is usually to secure budget or time allocations for your development team to focus on security.
There is an argument from professionalism. Software engineers talk about “craftsmanship” in reference to their work. They, in theory, take pride in creating high quality software.
There are many axes along which we can measure software quality. While I’m not in total agreement with the emphasis, groupings and vocabulary used, ISO/IEC 9126 lists a few of the attributes of good software. Security is one of them. Any professional software team should be taking steps to improve the quality of the software they are providing to their users in a broad range of the categories described therein, including in terms of security.
Software with fewer bugs is higher quality software. Security flaws in your software are a specialised type of bug. By that reasoning, more secure software is also higher quality software. Since we’re all professional software craftspeople, we all want to make higher quality software. One of the ways we can do that is to make software more secure.
The argument from professionalism is appropriate when working with the development team responsible for creating and maintaining an application. They go well when coupled with a few low-cost habits or practices that can quickly improve the security of their code, to at least get them thinking about security regularly.
Lastly, there are arguments from ethics. As someone with the ability to do something that could prevent a security breach, it could be argued you are ethically obliged to take any such action, or at least make a best effort attempt to do so.
Your employer would suffer in the event of a (badly handled) security breach. As an employee there is likely a clause in your contract to the effect of an obligation for you to act in the interests of your employer. You’re therefore contractually obliged to better prepare for, prevent, detect, and respond to security issues.
Depending on the type of security breach, you personally or your development team may suffer. This might be through data disclosure, fraud, or perhaps simply the blame that your team will get for letting the breach happen. While there’s no legal obligation here, you might feel the personal instinct for self-preservation, and for protecting from harm those who work closest to you.
Your users may suffer in the event of a security breach. They may also suffer personal security issues thanks to an otherwise correctly functioning parts of your application too. There is highly likely to be an all-caps clause disavowing any liability for damages in the terms of service document that your users will agree to when purchasing your software. There is therefore no legal reason for you (short of some domain-specific regulation) to focus on security.
However if you care about the impact of your work, it might bother you that users are suffering from fraud, blackmail, or other wrongdoing in part because of software that you created. These are likely to be the people paying your salary. Perhaps you are fine with this state of affairs, or are happy to shift responsibility to your employer.
The general public, users of the internet at large, may also suffer thanks to lapses in your security practices. Modern computers are general-purpose. Once compromised, they can be used for just about any function. If an attacker gains control of your infrastructure, they can sell that control on to the highest bidder. The computers that serve your application may simultaneously be used to host a human-trafficking site, distribute indecent images of children, or participate in a distributed denial of service attack.
Again, this may not cause you to take pause, especially if you’re happy to leave all responsibility for the impact of your work with your employer. However all of these arguments are worth considering when trying to convince others to take security seriously.
The arguments from ethics can be used when discussing these issues with just about any one who has a moral compass. In practice, these arguments are less convincing than the arguments from professionalism or from self-interest. However they are useful to mention to your peers in the industry if you know that you’re of the same political/moral leanings and are already convinced that your listener will see the merit in them once they’re raised.
So those are the arguments I use to get people to focus on security. I try to pick an appropriate line of reasoning depending on the context. It is some combination of capitalist self-interest, professionalism, or ethics. These arguments can provide a basis for discussion on allocating more time, attention, budget, or other resources on focusing on security.
