Re: MUSTs/contextualizing

[George Jones <gmj@pobox.com>]

On Mon, 4 Aug 2003, James Carlson wrote:

> ericb@digitaljunkyard.net writes:
> >  "bs" == Bill Sommerfeld <sommerfeld@east.sun.com> writes:
> > 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.
>
> That sounds like it could be called a feature rather than a bug.  ;-}

True, if you do s/authorized/unathorized/

Perhaps we should require all unauthorized scans to set the "evil bit"
(rfc3514) :-)

> > 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.
>
> I don't understand the point here.  I share your disgust with broken
> devices, but I'm unclear on the problem being solved.

RFC non-conformance provides a low pass filter.   It's one objective
measure that lets you say the box is "broken", from a functionality
standpoint.  If the box is broken functionally, it makes no sense to
spend time testing the security features.

> If the applicable RFCs already say MUST/SHOULD/MAY in all the right
> places, then what benefit is gained by having this document
> *duplicate* those -- saying, in effect, "yes, you really had to do
> that?"
.
.
.
>
> It seems to me that the underlying assumption here is that this
> document becomes the single "pass this one special test and you're
> Accepted as an Approved Internet Device" mechanism for multiple
> markets.  Is this an achievable goal?

Good questions.  Ones I keep asking myself as well.  I'm open to feedback.

<indirect-meta-answers>
The history of the doc is that we (UUNET, in a past life) needed
a relatively concise, single document both to communicate our needs
to vendors and to use as the basis for lab testing.  The working
theory was (and is) that this could be useful in a "larger context".
The data I have that says this is useful/doable are that:

  - It was useful/usable in it's original context for it's such purposes
  - We received encouragement form a vendor to move forward with
    making this a public document
  - The ANSI T1M1 doc seems to have had similar objectives in a
    broader context and succeeded (and therein lies another set of
    questions/issues)
  - RFC 1812 provides a model for collecting requirements in one
    doc...it focused on operational reqs, this is focused on security.
  - I am being encouraged by an area director to pursue it.

The current best definition of a "larger context" seems to be the IETF.
The document was IP-centric, written in mostly-RFC style, was mostly
BCP material, and referred to numerous RFCs.

</indirect-meta-answers>

<direct-answers>

> If the applicable RFCs already say MUST/SHOULD/MAY in all the right
> places, then what benefit is gained by having this document
> *duplicate* those -- saying, in effect, "yes, you really had to do
> that?"

Hmm.   History rears it's head again.  This is a holdover from
the pre-IETF versions of this doc.   When it was not an IETF
doc, "Conform to RFCs" had to be explicitly stated.

We could drop it, but I think, given the rational already discussed
here and cited in the reworded req (see earlier post), it makes
sense to keep it....if your functionality is broken (RFC non-compliant),
the need for security testing is questionable.  I think it's useful
to explicitly state that.

Also, keep in mind that other RFC are only cited as possible ways
of implementing generic requirements.   The requirement is "remote
logging", one possible implementation is syslog.  The requirement is
accurate time.  One possible implementation is NTP.

>
> It seems to me that the underlying assumption here is that this
> document becomes the single "pass this one special test and you're
> Accepted as an Approved Internet Device" mechanism

No, it's a longish list of generic requirements from which a series of
detailed tests could be constructed.  It contains pointers (many RFC
citations) to technologies that *could* be used to satisfy the
requirements.  It is an attempt to share collected wisdom regarding
what knobs are needed to operate securely.

It is NOT exhaustive.  Meeting the requirements does not mean the
device can be operated securely, however NOT meeting the requirements
pretty much guarantees that you CAN NOT be operated securely.

> for multiple
> markets.

I'm trying to keep the scope narrow (see latest front-matter changes)

> Is this an achievable goal?

See meta-answers.

</direct-answers>

Thanks,
---George Jones