Re: comments on draft-jones-opsec-02

[George Jones <gmj@pobox.com>]

[Reply CCed to opsec with permission ---gmj]

On Thu, 20 Nov 2003, Mike O'Connor wrote:

> Hi!  I talked with George at NANOG promised myself I'd take a look
> at this when the next draft came out.  I'm not subscribed to the
> associated mailing list and haven't looked at the archives, so if
> the particular things I quibble about have already gotten a whole
> lot of thrashing and I'm reopening old debates, my apologies.
>
>
> 1.2
>
> Perhaps it should specify "certain network topology contexts" instead
> of "certain situations"?

I'm going to leave that one as is.   I could see the creation of
profiles that have nothing to do with toplogy.

>
> How about "General purpose hosts not acting as a router/switch"?
> "I run NTP on my router" shouldn't mean it's less of a router for
> purposes of applying these sorts of things.  That's common sense,
> but I think less wiggle-room is in order.

Changed to:

  "General purpose hosts that do not transit traffic"
>
> "AA servers" should be "AAA servers".

Fixed.

>
> 1.3
>
> "(availability,confidentiality)" should be:
> "availability, confidentiality)

Why remove the parens here and not the others in the same list ?

>
> 1.5
>
> "the Appendix Appendix A defines" should be:
> "Appendix A defines"

Fixed.

>
> 1.6
>
> There should be a colon or somesuch after "Security Capability
> Checklist", "Composing Profiles", etc.

Yes.  I'll blame xml2rfc formatting here...and add periods to show
speration.

>
> 2.3.1
>
> Should that be a MUST?

I think so.

>  I'm a big fan of non-IP consoles, don't get
> me wrong.  But I would think that supporting some form of "static" IP
> communications profile, enough to get it up and working along some
> private network connection, would be acceptable, here.

What's needed is a simple-as-dirt*-always-there-works-when-you-need-
it-even-if-a-hacker-has-deleted-all-OS-images-and-configuration-data
config mechanism.  Serial console interfaces work, they are simple
and they are nearly ubiquitous...as BCP as you can get.

* Apologies to those who do chemical analysis of dirt samples :-)

>  I'm thinking
> of some types of consumer-grade routers

Out of scope.

> where I toggle some switch on
> the back, it comes up with enough of a stack to get to a WWW GUI,

See 2.4.4

 and
> one can plug a crossover ethernet cable and connect to a single host
> and access the GUI.

This assumes a lot of functionality (Functional OS/IP Stack/GUI/Bandwith to run GUI).

>  I don't see where any of the considerations would
> apply, unless the other end of the xover cable is so compromised where
> IP vs. serial cable vs. USB vs. whatever wouldn't matter, nor would
> any of the justifying reasons.

Clearly if the management host is compromised, all bets are off, but
security of the management net/hosts is out of scope.

> Consider the NETWORK part of 2.4.5, but
> from the configurator's end rather than the device end.

>
> If you're going to encourage RS232/EIA232, I'd encourage standard
> cabling.

Got a reference (standard) we can just point at ?

>  That's not strictly a security requirement,

No.  The security requirement is being able to connect for managment simply,
at all times.   I was convinced (@ NANOG) that today, for BCP
purposes, this means RS232.

> but let's not
> make the admin interface such a PITA that you need a breakout box
> or play "build your own cable" to get it to work right.

Agreed.

>
> 2.3.3
>
> "To talk to an ethernet interface for management, you must know,
> for instance, it's IP address."
>
> Wake-on-LAN is a counterexample.  There's a limit to the sorts
> of management you can do without IP, routing, whatnot, but as a
> blanket statement, the above is false.

OK.   And I suppose strictly speaking the management interface could
be running DHCP or some such.

I deleted the sentance.

>
> 2.4.1
>
> I'd make a suggestion that undocumented/unsupported options not

Finish the thought ?

> 2.4.3
>
> Perhaps you should have a Warning that the notion of supporting
> scripting means that the outputs should be reasonably defined.
> Ideally, there should be some sort of API, MIB, or somesuch that
> defines what's acceptable to scrape, and how the router/switch's
> outputs are going to be framed for scraping.  It's one thing to
> have a prompt where you can use Expect or whatever to automate,
> quite another to have a reasonable set of feedback such that you
> could reasonably automate, particularly across version changes.

Under "examples" it says the command language should be simple,
regular, and consistent.   I've moved those to the warning section.

I've also added:

gmj> 3.2 Document Command Line Interface
gmj>
gmj>    Requirement. The vendor MUST provide complete documentation of the
gmj>       command line interface with each software release.   The
gmj>       documentation SHOULD include highlights of changes from previous
gmj>       versions. The documentation SHOULD list potential output for each
gmj>       command.
gmj>
gmj>    Justification. Understanding of inputs and outputs is necessary to
gmj>       support scripting. See Section 2.4.3.
gmj>
gmj>    Examples. Separate documentation should be provided for each command
gmj>       listing the syntax, parameters, options, etc. as well as expected
gmj>       output (status, tables, etc.).
gmj>
gmj>    Warnings. None.

Does that do it ?

> 2.4.6/2.4.8
>
> These imply that a router/switch much support a way to extract
> passwords to a remote config file.  2.4.8 specifies that it is
> human-readable no less, though perhaps encrypted password fields
> count for something.  This may be at odds with how some vendor
> implemented passwording.  Suppose a vendor scribbles the password
> on a PROM or logic board they _can't_ extract from.  Saving a
> remote config wouldn't save the passwords and would violate 2.4.6.

Added "Sensitive information such as passwords that could be used to
compromise the security of the device MAY be excluded from the saved
configuration" to 2.4.6 and 2.4.8.

> I think that exceptions to 2.4.6 in the name of security ought
> to be noted, that 2.4.8 shouldn't assume user-readable passwords.
>
> Is the 8th bit of Unicode "text-based", or does human-readable only
> apply to humans who deal with 7-bit encoding for their language?

OK.  This one as come full circle.  It started out saying "Text",
whichi is what it ment all along, and now, along with the return
of CLI, it's time for this one to revert to its origin.

Unicode would be fine, as would Heiroglyphics or anything else
that could be called "text".   Machine readable binaries are
what's out.

Revised req:

gmj> 2.4.8 Support Text Configuration Files
gmj>
gmj>   Requirement. The device MUST provide a means to remotely save a copy
gmj>      of the system configuration file(s) in a textual format.  It MUST
gmj>      NOT be necessary to use a proprietary program to view the
gmj>      configuration. The configuration MUST also be viewable as text on
gmj>      the device itself. Sensitive information such as passwords that
gmj>      could be used to compromise the security of the device MAY be
gmj>      excluded from the saved configuration.
gmj>
gmj>   Justification. Having configurations as text is necessary to enable
gmj>      off-line audits of the system configuration.  Having them in
gmj>      simple, non-proprietary formats also facilitates automation of
gmj>      configuration checking.
gmj>
gmj>   Examples. A 7-bit ASCII configuration file that shows all the current
gmj>      settings of the various configuration options wold satisfy the
gmj>      requirement... as would a Unicode configuration or any other
gmj>      "textual" representation. A structured binary format intended only
gmj>      for consumption by programs would not be acceptable.
gmj>
gmj>   Warnings. Offline copies of configurations should be well protected
gmj>      as they often contain sensitive information such as SNMP community
gmj>      strings, passwords, network blocks, customer information, etc.

At this point, I have to run.   Reply to issues below to be continued....

>
> 2.5.1
>
> What about listening on protocols -- IPv4 and IPv6 being examples
> of just two of them?  I know that the scope is primarily IPv4,
> but "service" has a meaning.
>
> Be clear on what is meant by listening.  The draft speaks of this as
> _stack_ functionality, but the kind of listening being discussed here
> is more at the application level.  Does getting "Connection refused"
> mean the _stack_ listened?  Some would say "yes".  "If it responds to
> a port scan" may be a sufficient high-level functional definition for
> TCP and UDP, but what about IGMP?  In your TCP/UDP context, binding to
> a port and listening on said port aren't quite synonymous things in
> the eyes of a socket apps programmer.  A common case where this can
> happen is with a UDP socket, where you typically can't easily bind to
> a particular port for purposes of emitting with that fixed source port
> and not also be "listening", even if your app itself doesn't have a
> receive handler.
>
> 2.5.3
>
> You may want to distinguish between LAN-based sorts of things and
> WAN-based services.  Should I disable listening for ARP by default?
> (Some would argue 'yes' here, mind you.  :) )  What about other
> listening services that only make sense for a LAN?
>
> 2.5.5
>
> Would mentioning Strong ES vs. Weak ES model stuff (a decent summary
> is at http://old.lwn.net/2001/0308/security.php3) be appropriate here
> or elsewhere.  Strong ES vs. Weak ES is more about routing than about
> "source address selection" per se, but implementation of one model or
> the other tends to lead to different source addresses.
>
> 2.5.7
>
> For laughs, you could add "and proably section 4.2.3.14 of RFC1122".
> (If you're wondering what the big joke is, find the text for section
> 4.2.3.14 of RFC1122.)
>
> 2.6.2
>
> Filtering on TCP flags is useful, but "TCP state" is rightfully the
> _result_ of such flags, not the "bit-state" of the flags themselves.
> I think using a term other than "state" ("flags"?) would be helpful,
> or if you really want to use "state", mention things in the context of
> the TCP state engine which is truly about "session state", or mention
> the state of other connections as a filtering factor, or something.
> Mixing "flags" and "state" is a bad precedent.
>
>
> Ok, I am resisting strong urges to make a joke about flag burning not
> being the province of the state... better stop for now.  :-)


Thanks.  More later.

---George Jones

-
>
>
> --
>  Mail: mjo@dojo.mi.org  WWW: http://dojo.mi.org/~mjo/  Phone: +1 248 427 4481
>  =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--=
> "The Ancient Greeks founded the Olympics in about 1896."   -Non Campus Mentis
>