Software security != security software
How is software security different from security software - and why is it important? Let's take a closer look.
Security breaches can be caused by many factors: malicious insiders, theft, or even accidental data leakage. However, the most common causes by far are hacking, misconfiguration, and poor security. Since hacking a system involves the exploitation of a vulnerability – ultimately a bug in the code – all three of these are direct problems with the security of the software product, or software security.
What’s in a name?
So, what is software security, and what does it mean when securing a product?
Cyber securityhas many different aspects, from securing networks to handling incident response; many of these are about securing processes and infrastructure. In case of a software product, the security of the product itself is referred to as application security, product security, and software security. Application security is sometimes used as a synonym for the rest of the phrases, but in practice it is more of a subset. As per Gary McGraw, application security is the protection of software after it has already been developed, while software security also includes secure software development aspects and adopting secure coding practices.
All cyber security measures cost money – whether it’s buying security software such as firewalls and IDS, bankrolling a bug bounty program, paying appsec companies for penetration testing, or purchasing cyber security certifications. In case of security, the cost comprises the time investment by engineers as well as training costs. Considering that the Gordon-Loeb model identifies that a company should not spend more than 37% of the expected loss by security breaches due to diminishing returns, the available pool of money is limited.
With that in mind, how can a company best protect themselves when operating on a limited budget? Some argue the best way to handle software security is to do nothing at all. Daniel Miessler, leader of the OWASP IoT Project explains it as, “Basically, software remains vulnerable because the benefits created by insecure products far outweigh the downsides. Once that changes, security will improve—but not a moment before.”
This statement is not wrong, but this situation is changing quickly in a heavily networked and automated world. As Bruce Schneier put it, “This is true, and is something I worry will change in a world of physically capable computers. Automation, autonomy, and physical agency will make computer security a matter of life and death, and not just a matter of data.”
Top-down security software vs bottom-up software security
It is tempting to focus on ‘catch-all’ measures such as security software (IDS, web application firewalls, automated security audit tools). After all, software vendors claim these tools will automatically find vulnerabilities or catch attackers before they can exploit them.
Similarly, all systems have security measures implemented via controls and making use of security features of the platform or programming language. Typical examples are cryptography, TLS, access control, and authentication.
However, security software and security functionality don’t address the root cause that enables all those breaches in the first place: design flaws and programming bugs that make the system vulnerable. Even if authentication is implemented correctly and the communication channel is secured, an attacker still may be able to send a malicious message that causes the entire application to crash, or even execute arbitrary code on the server.
Security functionality is useful to set a ‘top-down’ baseline for the system’s security, and security software is useful as a layer of security against the (in)famous “unknown unknowns”, threats that we can’t even currently consider. But to actually prevent breaches and eliminate vulnerabilities, the only solution is ‘bottom-up’ software security: making the developers aware of these issues and making sure to follow secure software development best practices at all times.