RE: When to Shed Light

[InfoSec News <isn () c4i org>]

Forwarded from: Pete Lindstrom <petelind () comcast net>

To further my comments in the article:

I think actively seeking vulnerabilities is just plain destructive.
Sure, if the vulnerability is known we should disclose it, but it
never should have gotten to that. I believe there is a lot of faulty
logic behind the disclosure phenomenon. For example:

1. We claim that disclosure actually makes our systems stronger/more
secure. Of course, if that is the case then Microsoft has the
strongest software on the planet and we should be happy to deploy it
in our enterprise. Any takers? (By the way, I happen to believe
Microsoft gets a bum rap, but use this as a common example of what
goes on in the security space.) The whole concept of counting
vulnerabilities as a measure of security is bogus - it is an
unpopularity contest, nothing more, and doesn't say anything about the
software itself. By the way, enterprises have shown time and again
that they don't patch their systems anyway, so we can't get more
secure this way.

2. The more vulnerabilities we find, the closer we are to "the cure,"
i.e. some sort of security nirvana where no more vulnerabilities exist
in the world. Hmmm, this is a good one. So, count the number of lines
of code in existence, then come up with some metric for the number of
vulnerabilities in that code (I suspect you could use a very, very low
number to be conservative). Now add in the number of lines of code
being added to the world's code base every day. Finally, we factor in
the number of vulnerabilities found. Are we getting any closer to
finding all vulnerabilities in the world? Not a chance. More likely,
we are getting further away. That shouldn't further our resolve to try
harder, it should make us look at alternatives.

3. If we don't find it, then the bad guys will. This is another one
that doesn't work in the "macroeconomics" of the world's code base.
Though I can't prove this, I suspect that, given the amount of code in
the world, the likelihood of a good guy finding the same hole as a bad
guy is probably the same as the likelihood of a collision in a crypto
hash - nearing impossible. The most recent WebDAV vulnerability is the
only case I am aware of where the vulnerability wasn't known
beforehand. So the real question is, how many new exploits would there
be if there weren't such a large pool of vulnerabilities to choose
from? At the very least, it would reduce a lot of noise out there...
(I would love to know about other exploits that occurred with unknown
vulnerabilities, and am glad to keep them anonymous).

I guess what really bothers me are the pretenses under which we
operate. Those engaged in seeking out new vulnerabilities should just
go ahead and say that they think it proves they are smarter than their
competition. Period. It has nothing to do with the common good, it has
to do with boosting egos and generating revenue.

If consultants really want to spend time on this (honestly, I don't
understand how companies can absorb the simple cost of it) they should
be setting up honeypots. I don't advocate honeypots for most
enterprises, but this would be the perfect fishbowl to really
determine what was going on 'in the wild.' Setting up a honeypot would
truly further our understanding of things like likelihood of attack,
prevalence of attacks, the nature of security on the Internet, etc...
All great stuff we really have limited information on, but what we do
have is valuable (thanks, Lance).

There is one other reason that is a bit more difficult to dispense
with - That we really do this just to 'stick it to the vendor' and
make them pay the price for having written poor software. In my
opinion, this seems a bit spiteful and amounts to a pyrrhic victory -
sure we sock it to 'em, but at what cost? The real loser ends up being
enterprises.

My solution for this one is still a bit sketchy, but let me try. I
don't advocate software liability because it is too likely to be wrong
- the old "it's not a bug, it's a feature" cliché would create lots of
problems, and we only think about Microsoft and not the little guys in
our argument. I also don't believe we will ever completely eradicate
vulnerabilities and must therefore come up with a new metric to
measure 'software risk' (how about person hours per vulnerability
found?).

Instead of software liability, I advocate Material Safety Data Sheets
for software. In the same way chemical/pharmaceutical manufacturers
must document the interactions of their chemicals with "the world
around them," we should have software vendors document software
interactions with the rest of the operating environment. This will
ensure that they have completely tested their software and provide us
with a blueprint to create security profiles in host intrusion
prevention software. At least then we have a set of assertions from
the vendor about how their software works. Heck, it also sets the
stage for demonstrable negligence and fraud in the future.

Just some ideas.

Regards,

Pete  


Pete Lindstrom, CISSP
Research Director
Spire Security, LLC



-----Original Message-----
From: owner-isn () attrition org [mailto:owner-isn () attrition org] On Behalf
Of InfoSec News
Sent: Tuesday, June 17, 2003 3:14 AM
To: isn () attrition org
Subject: [ISN] When to Shed Light


http://www.eweek.com/article2/0,3959,1128749,00.asp

By Dennis Fisher
June 16, 2003 

Until recently, software security vulnerabilities were discovered mostly
by chance and by developers, security specialists or other
professionals. Once the flaw was discovered, news about it spread slowly
and typically by word of mouth on bulletin boards or perhaps the
occasional security lecture.

The huge network of security researchers - independent or otherwise -
who race to find the next big vulnerability in Windows or Apache, for
example, is a recent phenomenon.

So, too, are the overlapping and interconnected mailing lists on which
the researchers publish their vulnerability bulletins. Lists such as
BugTraq and Full Disclosure were founded to give administrators and
other IT professionals a place to get early information on developing
software problems.

But the amount of publicity and attention security has commanded in
recent years has brought new, less experienced and less disciplined
people into the security community. This, in turn, has led to
vulnerability reports being published before patches are available,
bulletins being stolen from researchers' computers and posted without
their knowledge, and a litany of other problems.

This chaos has led some in the community to question whether
vulnerability research and disclosure, in its current form, does more
harm than good. One side of the debate argues that because there is
essentially an infinite number of potential vulnerabilities in software,
finding and fixing a handful every year has no effect on the overall
security landscape. On the other hand, since disclosing a vulnerability
to the public means that good guys and bad guys alike get the
information, disclosure can actually cause a great deal of damage.

"The point is not to say that these folks don't have the right to 
disclose anything they want - of course, they do. In fact, we must 
assume that, in general, people are finding vulnerabilities and not 
disclosing them and [that] they can be used against us," said Pete 
Lindstrom, research director at Spire Security LLC, in Malvern, Pa. 
"The point is to demonstrate that those folks that say full disclosure 
is in some way good for us are actually doing more harm than good. 
Just think how much better our security might be if the highly skilled 
people who spend all day, every day, searching for vulnerabilities in 
software would try to design a security solution."

[...]



-
ISN is currently hosted by Attrition.org

To unsubscribe email majordomo () attrition org with 'unsubscribe isn'
in the BODY of the mail.