Re: MUSTs

[ericb@digitaljunkyard.net]

 "bs" == Bill Sommerfeld <sommerfeld@east.sun.com> writes:

>> This requirement was born in our test lab when we recieved a DSLAM
>> from a new vendor.  Nmap returned 65535 ports as "LISTENING", because
>> any SYN packet addressed to the craft interface recieved a SYN/ACK.
>> If it was TCP/23, SYN, SYN/ACK, ACK, connection.  If it was a random
>> port, SYN, SYN/ACK, ACK, RST.  The vendor had taken it upon themselves
>> to rewrite TCP.

bs> Let's distinguish between what the tools check for, and actual
bs> vulnerabilities, eh?

bs> This particular variance from the spec isn't a security problem, is it?

Sure it is.  It prevents authorized people from determining the
configuration of the device by scanning.  Or something like that.

I was not claiming this particular problem as an example of the kind
of thing that would be fixed by this requirement, or even this
document.  I was providing some background on why the requirement made
it into the document in the first place.

Bad code is rampant.  Heck, many of the devices we tested were
terrible, awful, horrible, terrifying.  The idea behind this
requirement was to ensure that at least a modicum of effort had been
spent, that at least a minor clue had been involved in making sure
that the device was functional as an Internet component.

We were not trying to get Cisco, or Juniper, or <your favorite, well
established vendor> to prove that they implement <insert protocol
here> according to the spec.  It was aimed at new, less proven
vendors, who had rushed a product to market.  We were officially
documenting our stance of "If your box is fundamentally broken, we
won't even bother security testing it."

Is this a security requirement?  Yes.  Would you have ANY faith in a
system that cannot even complete a TCP 3 way handshake correctly?  The
device must first be a stable, reliable, well behaved part of the
Network.  Then it must be securable.  No point in building a castle on
sand, Monty Python proved that one.

The RFCs are not neccessarily completely up to date.  But I am not
aware of a more current, widely accepted and relatively stable set of
standards to point at.  And I don't think there's anything in the RFCs
that's bad to implement.

This requirement does not serve the same purpose that it did when we
first added it at UUNET.  There, it was an officially documented way
to stamp "garbage" on a box, and send it back.  Now, it's requiring a
stable, well behaved foundation for a system's security features.
It's not coincidental that this requirement is much easier to meet if
you use a stable, mature, well validated code base.

ericb