Security and Obscurity
Many of us are familiar with a concept know as Security by Obscurity. The term has quite negative connotations within the security community -- often for the wrong reasons. There's little debate about whether security by obscurity is bad; this is true because it means the secret being hidden is the key to the entire system's security.
Obscurity itself, however, when added to a system that already has decent controls in place, is not necessarily a bad thing. In fact, when done right, obscurity can be a strong addition to an overall approach.
Good Obscurity vs. Bad Obscurity
An example of security by obscurity is when someone has an expensive house outfitted with the latest alarm system, but they keep the key and alarm code in the planter box next to the front door. This is security by obscurity because if anyone knows the secret, i.e. that the key and code are stored in the planter, then the security of the entire system is compromised.
That's security by obscurity: if the secret ever gets out, it's game over. The concept comes from cryptography, where it's utterly sacrilegious to base the security of a cryptographic system on the secrecy of the algorithm.
Obscurity As A Layer
Obscurity as a layer, however, can be used to enhance security that already exists. Examples of this include Portknocking and Single Packet Authorization.
These technologies allow one to hide their network services behind an additional layer of protection. Using the technology you can have an SSH server (or other previously secured daemon) sitting live on the Internet that portscanners literally can't see. This works because your firewall sits between the Internet and your listening service.
Your firewall listens to the incoming requests and ignores all standard attempts to your system. If, however, you ask in a very specific way, i.e. using the secret knock sequence (PK) or a packet with a special payload (SPA), it'll open access to the server for yourspecific source IP. This is where many respond with something like the following:
That's stupid because it's security by obscurity. If anyone figures out the secret, they'll just replay it and be into the system!
That's where they make the error. They are missing the fact that you still have to authenticate to the daemon behind this layer. You didn't replace the service's security with this layer, you simply added it to what already existed. Remember, the NSA most likely has great algorithms, but they still don't publish them.
Real World
Another example of this can be found in the concept of camouflage used throughout history in warfare. Specifically, consider an armored tank such as the M-1. The tank is equipped with some of the most advanced armor ever used, and has been shown repeatedly to be effective in actual real-world battle.
So, given this highly effective armor, would the danger to the tank somehow increase if it were to be painted the same color as its surroundings? Or how about in the future when we can make the tank completely invisible? Did we reduce the effectiveness of the armor? No, we didn't. Making something harder to see does not -- in and of itself -- make something easier to attack if/when it is discovered.
When the goal is to reduce the number of successful attacks, starting with solid, tested security and adding obscurity as a layer does yield an overall benefit to the security posture. Camouflage accomplishes this on the battlefield, and PK/SPA accomplish this when protecting hardened services.
Setting Things Straight
So the next time the subject comes up, remember a simple concept: security by obscurity is bad, but obscurity itself--when added as a layer on top of other controls--can be quite useful. Those who dismiss obscurity out of hand are simply regurgitating something they've heard rather than working through the concepts themselves.:
