![]() |
Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
--On Wednesday, March 27, 2013 6:42 PM -0400 Tom Metro <tmetro+blu at gmail.com> wrote: > We're getting a bit wrapped up in dogma. This isn't a black-and-white > issue. If you take a broad enough definition of "obscurity" it could be > taken to mean your knowledge of a password - it's obscure, you know it, > and yet it's guessable, just like the oddball port your service is > running on. Passwords aren't obscured things. They're supposed to be secrets. A password that is not a secret but merely obscured is a password that has been compromised. > There's really no reason why a system administrator should reject an > obscurity layer, if their security fundamentals are already good, as > long as in their judgment the obscurity doesn't impact their users. (For If the fundamentals are good then the obscurity layer adds no tangible security to the system while at the same time making the system more inconvenient for users. If the fundamentals aren't good then obscurity provides only a semblance of security while adding the same layer of inconvenience for users. Either way, obscurity is of no benefit to either security or to those who use the system. Obscurity makes it harder to manage the system. I can't use standard tools to monitor my services if they're not running on standard ports and protocols. I can't automatically install system and security updates with cron-apt; I have to validate every non-standard change. This makes my job that much more difficult. It is prone to mistakes and unforeseen consequences, and as a direct result makes the whole system that much less secure and reliable. I'd say that's more than enough reason to say "no" to obfuscation. > But the real value in obscurity measures is cutting down on noise, which > doesn't directly impact security, but can indirectly help it by making > real attacks far more visible, and avoid alarm fatigue. You're merely > filtering out the nuisance. I want that "noise" because it isn't noise. It's useful information. In terms of security, that "noise" can be used to tune passive and active defenses, much like how a corpus of spam can be used to train a spam filtering engine. If I don't have that "noise" then it's harder to tune my security rules. Genuine noise, the genuinely useless information, can be masked out of sight. It's there if I come to need it but it doesn't get in the way of immediate work. In terms of finances, having a huge list of attack logs can be used to justify the expense of intrusion detection and prevention systems. If I don't have that "noise" then I can't show the fiscal office anything tangible to justify the expense of intrusion detection and prevention systems. As a matter of fact, yes, I have once been asked to provide such logs for such purposes. Unintended consequences, indeed. -- Rich P.