Re: Penetration testing via shrinkware

[Ted Doty <ted () iss net>]

At 11:03 AM 9/21/98 -0400, Paul D. Robertson wrote:

> While black box scanners are really good at implementation verification, I
> don't think they tend to be the best models of design verification.
> Perhaps some others have some experiences scanning code for bad things
> that they can share, I'm sure grepping for "^printf" can't be the best way
> to find these things.

If you really want to open a can of worms, there are different types of
"defects" that you need to address:

1. Vendor-induced defects, such as missing patch for the foo exploit.  It
seems to me that the discussion so far has focused mostly on this.  Good
designs help out a lot here, and peer review is perhaps the best way to
ensure good designs.  The TCSec requirements for formal security models are
attempting to address this issue.

2. Administrator-induced defects, such as using the same domain name for
both DNS and NIS.  For new products and new technologies, this is maybe
more important that #1.  Scanners help out a *lot* here, both in pointing
out the problem and in (hopefully) `splaining how to do it right, so you
won't make the same mistake twice.  While red team design review should
help redesign grossly broken administrative interface, lots of this is due
to subtle interactions between different protocols or products.  Note that
perhaps one of the best parts of TCSec was the requirement to produce a
"How to Set Up and Use This Securely" document for the admin.

3. User-induced defects, either accidental (cluelessly sharing out the
entire hard disk or making their home directory world writable) or
intentional (installing a modem and PC Anywhere to get around that dang
firewall).  I'm completely mystified how to prevent these, short of
executions at dawn.

"Implementation verification" really needs to address all of these defects.
Localizing things in a single product ("Can't the firewall do that?") will
only give you a pretty limited view of How Bad Things Are.

> The Orange/Red Book criteria are the only real model for secure code
> development we have to work with.  I don't think that we should throw the
> whole idea out because the implementation isn't ideal.  

It's not a real model if it doesn't work in The Real World.

Marcus is on to something with his idea of take the best ideas from it and
ditch the rest, but the fundamental principle of the design should remain
that administrators will screw things up in interesting and unanticipated
ways, and that some users will remain persistently clueless and/or
malicious.  To a certain extent, the TCSec did try to capture this.

- Ted

-----------------------------------------------------------------------
Ted Doty, Internet Security Systems          | Phone: +1 678 443-6000
6600 Peachtree Dunwoody Road, 300 Embassy Row | Fax:   +1 678 443-6479
Atlanta, GA 30328  USA                       | Web: http://www.iss.net
-----------------------------------------------------------------------
PGP key fingerprint: 362A EAC7 9E08 1689  FD0F E625 D525 E1BE