Re: Fwd: Re: Last Call: draft-jones-opsec "Operational Security Requirements for IP Network Infrastructure"

[George Jones <[e-mail]>]

On Tue, 16 Mar 2004, Alex Zinin wrote:

> not sure if you saw this

Nope.  As noted, I was not on rtg-dir and was not copied.  Thanks for
forwarding.

> From: Jeffrey Haas
> To: Alex Zinin
> Cc: [e-mail]
> Date: Friday, January 23, 2004, 7:26:55 AM
> Subject: Last Call: draft-jones-opsec "Operational Security Requirements for IP Network Infrastructure"
>
> ===8<==============Original message text===============
> Presuming you comments to go here rather than routing-discussion.
> I'll repost there if that's not the case.
>
> I like this document in general and would make a few minor suggestions:
>
> Requiring the origin of the stack or the OS, while nice in theory, is
> unlikely to happen.  While it may be common knowledge as to what
> certain vendors have based their products upon, that knowledge seems
> to be to the detriment of the vendor in many cases.  "That vendor based
> their routing engine on Linux instead of FreeBSD" for example.  While
> the origin may indeed affect the security implications it doesn't take
> into account internal security audits or modifications to the
> original.

A couple of thoughts here.

First, these are now "SHOULD"s (possibly "should"s) in a draft aiming
at coming out as INFO (consensus of the BoF was that it should come
out as INFO soon, not BCP).  This requirement will not be usable as a
hammer.

Second, it's here to enable "trust but verify" testing.  "OK, you say
your high-end router is based on NT4 (:-)) and you've patched
everything...I've (customer testing person) got a bag of 'sploits
here that are widely available to kiddies....I just want to be sure
that they will not be able to knock down my core.  It allows
more focused use of time in the test cycle.

Third, lack of this knowledge may be to the detrement of the operator
and network users.   There two sides to the coin.

>
> Similarly, separate resources for the management plane while a nice
> idea in theory seem unlikely to happen for lower-end boxes.

This one has already been removed due to other input
(But note the scope. This is not talking about low end boxes.)

>
> I would suggest that it would be a Good Thing to make recommendations
> that the console interface support some common data transfer protocol,
> e.g. XMODEM.  This seems partially addressed in the section that covers
> "support software installation", however that section seems to deal more with
> non-console mechanisms.

The req IS intended to deal with console (non-IP) mechanisms for
loading new software.

At the risk of making the req too complex, I've added:

04> 2.4.5 Support Software Installation
04>
04> Requirement
04>
04>      The installation procedures SHOULD support mechanisms to
04>      ensure reliability and integrity of data transfers.
04>
04>Justification
04>
04>
04>	System images may be corrupted in transit (from vendor to customer, or
04>	during the loading process) or in storage (bit rot, defective media,
04>	etc.)  Failure to reliably load a new image, for example after a
04>	hacker deletes or corrupts the installed image, could result in
04>	extended loss of availability.
04>
04>
04>Examples
04>
04>      Simple mechanisms currently in use to protect the integrity of
04>      system images and data transfer include image checksums and
04>      simple serial file transfer protocols such as XMODEM and Kermit.

Does that do it ?

> With regards to the "slow link" issue, I would suggest that it would be
> a Good Thing to provide some form of text filtering mechanism in order
> to allow large queries of some form to return relevant data quickly.
> An example is the Cisco-style |include or |exclude.  Grep is your
> friend over slow links.

Added the following to examples:

04>      One mechanism that supports operation over slow links is the
04>      ability to apply filters to the output of CLI commands which
04>      have potentially large output.  This may be implemented with
04>      something similar to the UNIX pipe facility and "grep" command.
04>
04>      For example,
04>
04>        cat largefile.txt | grep interesting-string
04>
04>      Another is the ablity to "page" through large command output, a
04>      la the UNIX "more" command:
04>
04>      For example,
04>
04>        cat largefile.txt | more

> For the console fallback scenario, I would suggest that it is critical
> to log failed login attempts locally, preferably in some non-volatile
> storage to prevent attacks where the device is isolated from it's
> authentication interfaces and attacked at the console.

How's this (updated):

04> 2.11.4 Ability to Log Locally
04>
04>    Requirement.
04>
04>       It SHOULD be possible to log locally on the device itself. Local
04>       logging SHOULD be written to non-volatile storage.
04>
04>    Justification.
04>
04>       Local logging of failed authentication attempts to non-volatile
04>       storage is critical.  It provides a means of detecting attacks
04>       where the device is isolated from it's authentication interfaces
04>       and attacked at the console.
.
.
.

Please CC replies to [e-mail].   I'll approve bounces if you
don't want to become a list memeber.

Thanks,
---George Jones