Security by Obscurity is Underrated
In the information security field, we have developed lots of thoughts that can’t be discussed (or rarely discussed):
And goes like this. Most of them are very generally correct. However, I started to think that people are telling those because everyone is telling them. And, most of the people are actually not thinking about exceptional cases. In this post, I will raise my objection against the idea of “Security by obscurity is bad”.
Risk, Defense in Depth and Swiss Cheese
One of the main goal of defensive security is reducing the risk for the target business. According to the OWASP’s methodology, the risk of an issue is calculated with the formula below:
Risk = Likelihood * Impact
According to this formula, a Remote Code Execution issue poses more risk than a Cross Site Scripting one since the RCE causes more impact. This is easy. But what about the likelihood metric. According to the OWASP, likelihood refers that:
So, if we can reduce the likelihood, we can reduce the overall risk. That’s good. It’s actually very similar to a very common idea called “Defense in Depth”. It’s also referred as “Swiss Cheese Model”
According to this model, you need to build your defense mechanisms in a layered model so that even the attackers pass the first one, they will get caught on the others.
Security by Obscurity
So let’s talk about security by obscurity. It’s a bad idea to use it as a single layer of defense. If the attacker passes it, there is nothing else to protect you. But it’s actually would be good to use it as an “additional” layer of defense. Because it has a low implementation cost and it usually works well.
Let’s think about a couple of scenarios here:
It’s almost 100% since the hackers are conducting brute force attacks to the services with common credentials globally.
Well, we have eliminated the global brute forcers since we are not using a common username. The likelihood and risk are reduced. However, we still have to deal with targeted attackers. A targeted attacker can guess the username as
utku since it's my name.
Now we changed the default port number. Does it help? Firstly, we’ve eliminated the global brute forcers again since they scan only the common ports. What about the others? To find this out, I did a small survey on my Twitter to find out people’s port scan behaviors.
I’m trying to prove a point for my new article. I need your answers for the question below. (please be honest)
-When you do a port scan with nmap to find open ports on the target, are you specify a custom port range to scan all 65,535 ports? (with -p0–65535 parameter)
- Utku Şen (@utkusen) September 7, 2020
As you can see here, lots of people tend to scan the default/most popular ports only. So, if you switch your port from 22 to 64323, you will eliminate some of them. You will reduce the likelihood and risk.
The same thing goes for software vulnerabilities as well. If a vulnerability found in the Microsoft Remote Desktop Protocol, everybody will scan for the port 3389 globally. You can reduce your risk just by changing the default port.
Of course, it’s possible to use the same methodology in other fields other than changing the defaults. For example, the following ideas might be a good idea for some specific cases (not always)
- Obfuscating codes: Of course, it’s common knowledge. Hackers are people too. If you obfuscate your code well, they will need to spend more time to find issues. They may give up eventually.
- Using random variable names for a web application: Instead of using clear variable names, you can switch them with random strings. It might help just like the code obfuscation.
- Using Symmetric Encryption in the Database: When you write data to the database, use a function like
encryption_algorithm(data,key). Likewise, when you read data, use a function like
decryption_algorithm(data,key). If the attacker can read your backend code, obviously he/she can decrypt your database. But if there is an issue that allows an attacker to read data from the database, but not the backend code (like SQL Injection), the gathered data won't be helpful for the attacker.
Real Life Applications
Security by obscurity is widely used in physical/real-life security. For example, the president goes from point A to point B with his 30 cars convoy. But he’s not sitting on his own presidential car so that the attacker won’t target him easily. He can be in any car and it reduces the risk of an attack.
Camouflaged animals are using security by obscurity as well. Obscurity reduces the likelihood of being killed. Therefore, they gained this ability in the evolutionary process.
Security by obscurity is not enough by itself. You should always enforce the best practices. However, if you can reduce the risk with zero cost, you should do that. Obscurity is a good layer of security.
Originally published at https://utkusen.com on September 8, 2020.