Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] Security through obscurity



--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.



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org