28 June, 2019
In 2017 someone submitted a bug report to Mozilla Firefox bug-reporting service complaining about the HTTPS warning. “Your notice of insecure password and/or log-in automatically appearing on the log-in for my website, Oil and Gas International, is not wanted and was put there without our permission,” a person wrote here. “Please remove it immediately. We have our own security system, and it has never been breached in more than 15 years. Your notice is causing concern by our subscribers and is detrimental to our business.”. Hackers around the world accepted the challenge. They have defaced the site in no time.
The moral of the story is at least twofold. Firstly, always, always, always use HTTPS. Secondly, never claim you are invincible. Though we would like to raise a more important issue, namely how much is the cost of 100% security?
“Is your software system secure?”. What is the right answer?
100% security is a myth.
With the advent of the GDPR the question “Is your web application secure?” is almost part of a standard checklist. “Yes, our firm is an expert in software security” is clearly not the right answer. Especially when you do get breached. “No” is obviously also not the best choice of words. Then you will definitely sound like an amateur. Software architects and security engineers know better. Just like any given quality attribute of a software system, security is never black and white. Software architects think in terms of quality scenarios. Security engineers do so using threat models. So a good answer to this question is “Secure against what?”. A great answer to this question is “Here is our threat model, the mitigating countermeasures and the residual risk”.
Threat modeling is the right answer.
The discipline of threat modeling exists for quite some time. However, it has gained quite some traction in the past years largely thanks to Adam Shostack, whom I had the privilege to meet during an OWASP Chapter Meeting in Brussels a couple of years back. If you are not an expert in software security, his book on threat modeling is your starting point. The essence of threat modeling is to look into the set of all the possible threats. Once you have discovered the threats you have to come up with countermeasures in order to reduce the likelihood and the impact of the threats (i.e., the risk).
Thus, security is all about threats and managing their likelihood and impact. Does that sound familiar? Threat modeling is very similar to risk analysis and risk management in the business world. Thus your managers and customers are going to understand and love threat modeling.
What is the cost of security?
Security is not a one-off thing. It is a continuous process.
100% security doesn’t exist. Security is difficult if not impossible to objectively quantify as opposed to e.g., code coverage in testing. Hence, as a manager, as a customer and even as a software engineer the question how much investment in security is enough is challenging.
The threat modeling should give you an approximation of which threats should be mitigated. So after the threat modeling exercise you should already know the ballpark of effort & costs for the necessary work you need to carry out. However, one thing we didn’t mention about threat modeling is that threat modeling is a continuous process. So is security. None of the two is a one-off thing.
At Codific we are convinced that security should always get a certain portion of the project budget. The right percentage depends on (at least) two essential factors. The first factor depends on how critical the security requirements in a given project are. For instance, a weather app needs to meet only minimal security requirements. A healthcare app that stores patient data will need substantial security investments. The second factor is how much expertise your team already has in software security.
As a result, we obtain a two-by-two matrix that describes the cost of security depending on the two factors.
Observations
A project with low-security criticality delivered by a team with limited security experience has a moderate cost (lower left quadrant). The same project with an expert team will cost you close to nothing (lower right quadrant). The cost is very high for a project with high-security criticality delivered by a low skilled team (upper left quadrant). The same project has only an average cost for a highly skilled team (upper right quadrant).
The less security know-how in the team, the more resources you will need to make sure the most likely threat scenarios are covered. You might even need some external consultants. On the other hand, if your team is very skilled you might already have all the main threat scenarios tackled. Indeed, many security threats (e.g., SQL injections, Cross-Site Scripting, Configuration) are something a team will typically automatically mitigate across different projects.
Philip Crosby said once that “Quality is free, it’s not a gift, but it is free”. He meant that investment in quality will pay back quickly. Given that security IS a quality attribute we believe that the statement is true for security as well. Getting practical know-how in software security will reduce the total security budget a software firm needs to invest in software security for each project.
Conclusion
Software security is one of the qualities of virtually any software system. We believe that the cost of security depends on how strict the security requirements are and how experienced in security your team is. While you cannot really control the first parameter, you can always improve the security skillset of the team.
Achieving a comfortable level of this rare skillset might be a daunting task to start with. Software security is a never-ending game. However, once you have achieved a certain level in the “game” playing it becomes easier.
Are you wondering how Codific might help? Find out more about our security products in the Products section of our website. Contact us for more information.
Key References:
