Re: Impressions - April Microsoft Patches

[Adam Shostack <[EMAIL PROTECTED]>]

On Wed, Apr 14, 2004 at 11:35:58AM -0700, Brian Parent wrote:
| This might be too much of a digression for the moderator to allow,
| but basically, I don't think the CAIDA anaylsis concludes that people
| should stop patching, just that efforts be redirected, because the
| current game of whack-a-mole is a losing effort.

I think this is exactly right.

| "Preventing software vulnerabilities in the first place" is the most
| effective and efficient, but possibly also the least likely solution to
| surface in the short term.  I'm hopeful that future generations of
| programmers will obtain better training, but they'll always be human,
| and hence prone to mistakes, and the timeline of the results of such
| changes are eons away in internet time.
|
| As long as there is a business pressure to be first to market, and as 
| long as the effort to be first to market is rewarded with market share,
| software companies will continue to produce lower quality code with
| more bugs, security and otherwise.

I think there are (at least) two important classes of security flaws.
There are design bugs and implementation bugs.  We have a large set of
implementation bugs available for study.  That study is leading to two
classes of tools: Tools that examine code for things that can lead to
problems, (eg, RATS, ITS4, splint), and tools that break entire
classes of problem (stackgaurd, Sana, Okena and the like).

(The code examining tools are the free, static code checkers.  There
are also dymanic testing tools from companies like spidynamics,
sanctum, and WhiteHat.)

I think that as these code checking tools improve, we may see an
improvement in code quality that comes along with that.  Have you
asked your software vendor what they do to assure code quality lately?

| It might be suggested that reversing such a market pressure is up to
| the consumer, yet it isn't reasonable to expect the general consumer, 
| a non software expert, to judge software quality.  We might consider
| setting up some way that software experts' opinions of quality could
| be researched in an easy way by consumers, yet maintaining the integrity
| of such a system might become the insurmountable problem.  Plus, 
| differences of opinion on technical matters don't necessarily boil down
| to terms decipherable by non-technical consumers.
| 
| CAIDA's second suggestion,
| 
| 	...and developing large-scale, robust and reliable infrastructure
|         that can mitigate current security problems without relying on end user
|         intervention.
| 
| Is beyond my expertise to comment on, though it seems the more likely to
| bear fruit.  I look forward to reading comments from experts about the 
| viability and outlines of such an option.

There are a couple of types of solutions.  I think of all of this as
"intrusion prevention," although that term has been coopted by the
intrusion detection vendors, who may be able to make their inline IDS
tools prevent intrusions, but I think that the OS hardening tools work
better.  In this camp are SELinux, Immunix, OpenBSD, Okena, Pelican,
Sana, and lots of others.  How well the tools works varies greatly, as
is the effort to install, configure and manage them.

But many of them may be usable to reduce your patching efforts, by
putting them in a lab with some proof of concept code.  (The vendors
ought to be doing this, and reporting to you "oops, ms-05-92 is not
stopped by our UberWall product, you need to patch.")

I think that patches we'll always have with us, and we need to learn
to manage the risk associated with them.  There are good ways to do
that all along the software construction process, from design to
operations.

Adam


---
To unsubscribe send a blank email to [EMAIL PROTECTED]