As a security engineer, I regularly work with developers. Together we draft various ideas and try to find the best possible solution to the problem at hand. During this process, the following question always comes up in some form: how secure should this be? Simple as it may seem, usually a lot of thought goes into answering this. Let’s see why!
There are quite a few things in play here: legal and business requirements, the risk of exploitation, cost of mitigation, loss expectancy, business impact, etc. It is usually infeasible for a single person to be familiar with all of these topics. Let’s take a look at what different parties might think about the optimal solution. I know, it is a generalization, but bear with me!
Business: as cheap as possible, optimizing cost.
Development: as simple to implement as possible following KISS and YAGNI.
Security: as secure as possible that is my job after all!
So who is right? And more importantly who is going to decide what to do?
You can see that all parties have good reasons. They all make sense so the right answer must be some combination of these views, right?
Well, kind of! Every single security question is ultimately a business decision. It is the business who is going to pay the cost and it is them who will see the benefit of mitigation. Here is an example. Let’s say you found a bug which allows you to access data for which you have no authorization. Should you fix it?
If you fix it, it will probably take a few days to implement plus another week to gradually roll out the change and make sure it does not break anything. This fix will have an impact on your team’s performance, therefore costing money to the business. On the other hand, if you decide to leave it alone, there is a risk of it being exploited causing significant damage to the business. Now, you do not have to be Sherlock to see where I am going with this. The business must decide which path is acceptable. Most probably they already did in the form of standards and policies or delegated the task to a dedicated party. Of course, these policies cannot cover all possible scenarios, so the question is still valid.
How much security is enough? The answer is just enough!
Okay, are we to do the bare minimum now? — you may ask.
Hell, no! Your job, both as a security engineer and as a developer, is to provide critical information to the business so they can make an informed decision about what to do. This is called due diligence and you are a crucial part of the process.
A good solution must be secure enough that all stakeholders are comfortable with the residual risk. This is the lower bound regarding security. In the meantime, they should not be more expensive than the loss expectancy in the case of exploitation. That is the higher bound regarding cost. Together these two rules are the essence of risk management.
This framework is one of the most fundamental principles. Make sure to keep it in mind next time you talk about security.
You will soon discover that this concept is rather abstract and you need some hands on knowledge to appreciate its value. Don’t worry though we will cover all that soon enough.
For now, just remember how secure something should be: just enough!