October 18, 2001, 5:33 PM — Want to really irritate security architects? Just tell them that their design relies on security through obscurity (http://www.tuxedo.org/~esr/jargon/html/entry/security-through-obscurity....).
That accusation was leveled at me. I'd recommended that a client have internal headers stripped out of email at the firewall before that mail was being outside the company. I thought this was just good common sense. I even provided the technical solution to do it with the MTA the client was running (Sendmail). The admins balked and said, "No one does this." OK. So I asked the gods at Sendmail.org for guidance. To my surprise, they also felt it was unnecessary, even inadvisable. In fact, it was said that I was "paranoid" and relying on "security by obscurity."
Ouch. As a firm believer in full disclosure and open source systems, that really hurt.
Bruce Perens made some good points on this in his July 20 Slashdot article, "Why Security Through Obscurity Won't Work" (http://slashdot.org/features/980720/0819202.shtml).
Sometimes, however, a little obscurity is advisable. The technique is problematic when it is relied upon exclusively as a measure of defense; in the case of my client with the bleeding headers, however, the internal network was protected from intrusion from outside the company by firewalls and other security mechanisms.
I still think it's foolhardy to advertise internal information so promiscuously. The first step in attacking a site is to gather as much information about it as possible, as demonstrated in this July 1998 Phrack article from Brian Martin (aka Jerhico) -- (http://www.attrition.org/~jericho/works/security/phrack-53.html).
Why make it easier than it has to be? Why advertise your internal mail routes and the internal IP addresses of firewalls that accept SMTP traffic? Relying solely on security through obscurity is foolhardy. Blatantly advertising internal information to the outside is even more foolhardy.
With software packages, it's a different matter entirely. End users are at the mercy of the software vendors, and are forced to rely on them to properly test their products. I used to be in a system test group and, believe me, such groups have no status in software development departments. I tried going directly to developers before writing bug reports on their software, and many appreciated my covering for their mistakes. One developer surprised me by telling me to write up the bug report even though she fixed the problem as I was talking to her. When I questioned her on this, she explained that the monthly bug report that was distributed to the entire department forced developers to do a better job at debugging their code. It also forced management to recognize that unrealistic deadlines led to bad code.