Security through obscurity is underestimated
- Never implement your own cryptography.
- Always use TLS.
- Security by obscurity is bad.
Etc. Most of them are generally correct. However, it seems to me that people are blindly following these axioms as a cargo cult. And many don’t really think about exceptions to the rule. In this article, I will raise my objections to the idea that security through obscurity is bad.
Risk, Layered Defense and Swiss Cheese
One of the main tasks of information security is risk reduction. According to the OWASP methodology, the risk of a problem is calculated using the formula:
Риск = Вероятность * Воздействие
By this formula, the problem of remote code execution (RCE) poses a greater risk than the problem of cross-site scripting, because the RCE has a greater impact. Everything is simple here. But what about the probability metric? According to OWASP, the probability is defined as follows:
At the highest level, it is a rough estimate of the chances that a particular vulnerability will be disclosed and exploited by an attacker.
Thus, if we reduce the likelihood, then we reduce the overall risk. It’s good. In fact, this is very similar to the well-known concept of “defense in depth”. It is also called the “Swiss cheese model”.
According to this model, you need to build defense mechanisms in a layered model in such a way that even if an attacker passes the first level, he will be stopped at others.
Security through obscurity
So let’s talk about security through obscurity. It’s a bad idea to use it as your only layer of protection. If the attacker passes it, then nothing else will protect you. But it’s actually quite good as an “extra” level. Because it has a low implementation cost and usually performs well.
Let’s consider several scenarios:
- On my server, SSH runs on the default port 22, and the credentials
root:123456
… What is the likelihood of compromise?
The probability is almost 100%, since hackers all over the Internet are brute-force services with standard credentials.
- SSH runs on port 22 and credentials
utku:123456
… What is the likelihood of compromise?
Well, we have eliminated the danger of brute-force with standard credentials. The likelihood and risk are reduced. However, we are still faced with a ton of targeted attacks. Someone might guess the utku username since that is my real name.
- SSH runs on port 64323 and credentials
utku:123456
… What is the likelihood of compromise?
We have changed the default port number. Will it help? First, we have eliminated the danger of standard brute-force once again, since it only scans common ports. What about the rest? I ran a small poll on my twitter to find out the behavior of people when scanning ports.