--On Wednesday, March 27, 2013 6:42 PM -0400 Tom Metro
<[email protected]> 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.
_______________________________________________
Discuss mailing list
[email protected]
http://lists.blu.org/mailman/listinfo/discuss
