Re: draft-jones-opsec-01.txt comments: in-band management

[George Jones <gmj@pobox.com>]

On Thu, 23 Oct 2003 ericb@digitaljunkyard.net wrote:

>  "jnw" == Joel N Weber, <Joel> writes:
>
> >> If people have suggestions for ways to tie the current
> >> implementations more strongly to the requirements
> >> without precuding better implemetaionts later, I'm all for
> >> it.
>
> List current protocols that "at the time of this writing" met the
> requirements, and _why_ they work.
>
> >> I'd love to say "SSH, no telnet", "SNMPv3, no SNMPv1",
> >> "SCP/SFTP, no TTP".
>
> Then say "currently, SSH is an acceptable terminal access protocol
> (encryption, user auth, host auth, etc), while telnet is not (clear
> text, no host auth)."
>
> SSH is then stood up as an example, not as a recommendation or
> requirement.

Which is essentially how things are now.  I've tended to put
"why" information in the "justification" section.

To quote the intro from the doc:

   The examples section is intended to give examples of
   implementations that may meet the requirement.  Examples cite
   technology and standards current at the time of this writing.  It is
   expected that the choice of implementations to meet the requirements
   will change over time.


I think a pass over the examples to add verbiage such as:


  Acceptable implementations at the time of this writing include...
  because...

would probabably clear things up/give implementers clear guidance.


> Terminal, yes.  What if the device in question is a Cisco VOIP call
> manager running on a Cisco that's really an HP that's really a Compaq
> running Win2k?  You need a GUI, and forwarding MS Windows over ssh
> doesn't quite work correctly yet.

In that particular case, it would violate the "must be scriptable"
requirement, "must work over low bandwith", and possibly the
the "must be able to use a CLI over RS232" reqs (still under discussion).

>
> Let the vendors and the users negotiate whatever is acceptable to
> themselves.  In this case, Windows Terminal Services over IPSec works
> great, as it's a homogenous network.

Right.  This touches on how the doc can/should be used and assumptions
made.

It documents what are precieved best current practices for the
managemnt of large IP based networks.  It currently assumes, for
instance, that you want to do remote, centralized, secure management
of lights-out facilities...hence the documentation of current BCPs
that support that (OoB mgt, CLIs, low-bandwith, Serial interfaces,
scriptable)

If it is acceptable to the customer require someone to be onsite,
Windows-install and patch CDs in hand, and to have to be standing
in front of the GUI console of each device to patch them one-by-one
in a non-scripted fashion, then the customer is free to say to the
vendor "my reqs are everything in the BCP MINUS x,y and z".

That's the intellegent approach.

The other approach is the "I don't want to think about it and I'm
willing to buy all the assumptions in the BCP, so just implement
everything in the BCP and I'll treat the entire BCP as a single
checkbox" approach.

That's the "don't make me think approach."

Either way, I think the docment will have succeeded if results in
vendors implementing a better, more standard, secure set of features.

---George