Re: Concepts: Security and Obscurity

[Daniel Miessler <daniel () dmiessler com>]

On Apr 11, 2007, at 1:36 AM, Craig Wright wrote:

> To translate: "Limiting access to a potentially vulnerable daemon by
> 99.9% of the Internet population."
>
> You get....
> Control:
> Limit the number of people who are likely to access this daemon to
> 1,114,274 people.

I'm not sure if you are being argumentative for the sake of doing so,  
or if you really thought I meant that 0.01% of the Internet  
population would be given valid access to the PK/SPA client being  
used by our fictional organization. I'm going to assume the former  
since the latter just sounds too silly.

I used 99.9% to mean "the vast majority", with *VERY* few exceptions  
(i.e. like 25, or 50, or 1,000)

> Costs:
> 1       Running a vulnerable service with a false sense of security and
> little concern
> 2       Documentation of the service and the time to reconfigure devices
>
> Thus the summary is that there is no gain and some cost.

Where is the false sense of security if you already have your CURRENT  
security, only you've added something in addition to it?  We're NOT  
MODIFYING existing security, whether that's via SSH, VPN, or  
whatever. That stays in place. All we're doing is making it so people  
can't see the service in the first place.

> Now if you consider the number of people who scan well know ports
> against those who scan for "hidden" ports and the levels of skills -
> what you have done is make the site a target.

How about people who scan for closed ports? Are we worried about  
people making a list of sites NOT running certain services? I'm  
personally not so worried about being put on such a list.

> You have done nothing to stop those with skills (and thus who are more
> likely to compromise the system) from attacking - but have removed  
> some
> of the noise element as the script kiddies generally scan for attacks
> they have exploits for. Thus the resultant population consists of  
> people
> who have a greater likelihood of compromising the system and these
> people have not been controlled at all.

Right, other than the fact that they'd never see the service in the  
first place due to the port not listening. Again, how do you expect  
this fictional super-hacker to open a port on a firewall that's NOT  
open? If there are people that can do that then every company in the  
world with an Internet presence is in grave danger.

> Bering that the population of users who have found the port are  
> unlikely
> to be those with valid reasons; you have not secured the daemon at  
> all.
> With the current Honeynet statistics, you may survive in this state  
> for
> 72 hours or so...

Wow.

> The system of algebraically assigning a number for each control is not
> mathematically valid. Survival in this situation forms a poisson model
> on the length of time that the service is maintained in a "secure"
> state. In this, the additional benefit would (even if algebraically
> equal - which is not the case) be included as an additional factor  
> to an
> inverse exponential. Thus it would have a minimal additional effect.

Easy killer. I'm still trying to figure out how to open closed ports  
on remote firewalls.

> The manner which you have assigned values to risk is not  
> mathematically
> sound. There are centuries of research into risk. Survival models  
> apply
> to IT risk as well. Making up numbers to state that an added layer of
> security is an improvement is unscientific at best and does nothing to
> improve the risk modelling process.

You're trying to condescend but you don't seem qualified to do so.  
Let me leave you with a few simple questions that will hopefully jar  
you back to us:

Why do we hide missile launch sites?
Why does the presidential motorcade not disclose which car the  
president is actually in?

The reason, my friend, is because no matter what security is placed  
on a given system -- making it difficult to actually INITIATE an  
attack against said security is still valuable! No algebra or list of  
references is going to make this less so.

I ask you to reconsider.

--
Daniel Miessler
E: daniel () dmiessler com
W: http://dmiessler.com
G: 0xDA6D50EAC

Attachment: PGP.sig
Description: This is a digitally signed message part