The rules of security by obscurity
2013-10-01The first rule of security by obscurity is: DON'T
There, I said it. Now you can stop reading. Or you can continue. But watch where you step.
Security by obscurity is generally frowned upon, because people have relied on it as their only layer of defense. When you think that nobody will be able to reverse engineer your clever code, or find that specific file holding all the secrets, you have already lost. People got quite efficient at reverse engineering and finding secrets.
That's why it is recommended to rely on safer algorithms and techniques to protect your system. They have been tested, and were created especially for that purpose. That can be encryption algorithms, authorization systems, etc.
The second rule of security by obscurity is: you should not need it
Defense is hard because of information asymmetry: the attacker often has more information than you to approach the system. That could be 0-day vulnerabilities, or the knowledge that you misconfigured one of your servers. The attacker has basically more time and more money than what you can spend on security.
The tools you have at hand? Patching the code, controlling authorizations, verifying your logs... You get a system that should not be easy to attack even if the attacker is familiar with the underlying software.
Except that the attacker might be well informed on the problems of deploying that particular CMS. Or there's a specific vulnerability you don't know about that is exploited automatically by botnets...
The third rule of security by obscurity is: DON'T, but...
The goal of your defense layers is to drive up the cost of an attack. A really motivated attacker will always find a way (with enough ressources, they could break in your office to steal data directly). So, what you want is to make an attack costly, to drive off attackers with less ressources.
And what will security through obscurity provide you? Time! They will provide you with time to defend, and waste the attacker's time. It is in no way enough to protect you, but it can give you a lot of benefits:
- confuse automated tools: moving some specific files or pages of your CMS out of their default location will prevent most automated attacks. That will not stop human attackers, but they might need to modify their scripts, and we all know that's annoying :p
- slow down information gathering: removing the server headers is a pretty standard practice. Some more sophisticated tools might be able to guess server version and/or framework type in other ways, but basic tools will not.
- lie to the attackers to send them through a honeypot. Then, you can observe them, learn about their process and prepare for other attacks.
- detect suspect behaviour, like bruteforce queries, and send bogus data instead of rejecting them. That means more data to analyze manually for the adversary.
- Are you trying to send encrypted data? Do you really need a public handshake protocol, displaying the whole algorithm negotiation? Sometimes, communicating directly with a pre shared key and pre negotiated algorithms will work just fine, and only show garbage to the attacker.
See the pattern there? We already know ressourceful attackers will get past those false defenses. But the point is to make them waste time in basically three ways:
- forbid automated attacks, they should ressort to manual ways
- make them work to get useful information
- mess with their heads
Security by obscurity is basically the fun side of defense, because you're always looking for ways to annoy the adversary ;)
The fourth rule of security by obscurity is: you are not the attacker
While those defense techniques can be useful, be aware that they can significantly hamper your day to day work. They should not prevent you from managing your system correctly. Every "WTF" moment for an attacker might be a "WTF" moment for one of your developers, system administrators, or even worse, one of your users.
Worse, sometimes, it might annoy you, but will be bypassed easily by the adversary (do not underestimate their ability to write clever automated tools).
So, be careful with security by obscurity, do not rely only on it, and have fun annoying the attackers :)