Re: Re: Concepts: Security and Obscurity

["Lord Bane" <lordl3ane () gmail com>]

Joe,
---------- Forwarded message ----------
From: "Joe Yong" <justasqlguy () gmail com>
To: security-basics () securityfocus com
Date: Tue, 10 Apr 2007 22:59:23 -0700
Subject: Re: Concepts: Security and Obscurity

> > Half the responses are slamming security that is dependent exclusively
> > or heavily on obscurity. Was that really what the article proposed?
> > Show me where. It's been a while since high school English classes so
> > I will be the first to admit I can misread things at times.

Although my previous post already stated so, in summary I believe that
many of the topic participants are blending "Confidentiality,"
"Privacy," and "Obscurity".  Because of this, Obscurity gets confused
with other Confidentiality-domain controls.  In effect, I think a lot
of people read these threads as, "There is no effective gain in
security through Confidentiality".  Many of the arguments I read seem
to be quoting the relative gains of Obscurity controls while judging
their efforts against implementing Authentication and Encryption
controls.

Obscurity controls generally require inaction and thus have a minimal
cost.  As Mr. Miessler put it, "Why do we hide missile launch sites?
Why does the presidential motorcade not disclose which car the
president is actually in?"  In effect, these controls cost very little
-- but they also provided very little in overall security.  My
assumption is that any potential threat actors would simply adjust
their attack vectors to encompass all possible missle launch
facilities (blanket MRV the area); fire RPGs at all the cars in the
motorcade.  A high-cost & high-value control would be to have an
intercept system for all the MRVs (IPS) and have RPG-proof cars carry
the President (Firewall).

Even if the attack vector was limited; for example: we're only
allowing the terrorists to have one RPG; we still have not limited or
prevented the attacker's ability to cause damage, only slightly
reduced the probability that the target of the damage will be the most
valuable target.  Nor have we inhibited them from trying again when
they get another RPG.  So, even though it is a security control, the
confidence in the control is low.  Since the cost is generally also
low, unless it causes some operational interference (trying to hide
the door by taking down all the fire-exit signs), then there's really
no harm in implementing it.

> > Quite a few security researchers have done this but feel free to try
> > it for yourself. Setup some server application that is a common target
> > for attacks (just so you'll get some quick responses) using standard
> > secure configuration and setup another one in exactly the same secure
> > way but listening on some completely off-the-wall port and non-default
> > protocol. Track how many attempts you get on each.

Actually, this works inside a short frame of reference.  At first,
both systems are scanned an equal amount for services.  The one with
the service running on a standard port (SQL or SMTP as an example)
begins to increase exponetially almost immediatly.  However, I found
that the attacks against non-standard ports begin to increase
exponentially once that service is found to be open -- although not at
the same rate.  It seems that obscuring the service at least
temporarily mislead attackers (probably the ones using
default-configured automated tools or malware-infected systems), but
again did not stop the attackers from causing damage once the service
was found.

Eric