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

[George M Jones <[e-mail]>]

> Subject: Re: Last Call: draft-jones-opsec "Operational Security
>       Requirements for IP Network Infrastructure"
> From: David Meyer <[e-mail] <mailto:[e-mail]>>
> Date: Thu, 22 Jan 2004 16:31:46 -0800
> References: <[e-mail] <msg00731.html>>
> 
> 	Folks,
> 
> 	A few initial comments in-line. Please search for @@@.
> 
> 	Dave
> 
> --
> None.                                                   G. Jones,
Editor
> Internet-Draft                                     The MITRE
Corporation
> Expires: June 15, 2004                                 December 16,
2003
> 
> 
>     Operational Security Requirements for IP Network Infrastructure:
>                          Best-Current-Practices
>                           draft-jones-opsec-03
> 
...
> 2.3.7 No Forwarding Between Management Plane And Other Interfaces
> 
>    Requirement. If the device implements separate network interface(s)
>       for the management plane per Section 2.3.6 then the device MUST
>       NOT forward traffic between the management plane and
>       non-management plane interfaces.
> 
> @@@ what if I want this (i.e., MUST NOT)?

How's this ?

   Requirement. If the device implements separate network interface(s)
       for the management plane per Section 2.3.6 then the device MUST
       provide a mechanism to disable and enable forwarding of traffic
       between the management plane and non-management plane
       interfaces.  Forwarding MUST be disabled by default.

> 2.3.8 Provide Separate Resources For The Management Plane
> 
> @@@ isn't this an implementation issue (which perhaps should be
> @@@ left for vendor differentiation)?
> 
>    Requirement. If the device implements separate network interface(s)
>       for the management plane per Section 2.3.6 then the device
SHOULD
>       provide separate resources and use separate software for
different
>       classes of interface.

It is an implementation issue, but one with potentially large security 
implications.  Hence it's inclusion.   Note that it is a SHOULD.

> 2.4.2 CLI Supports Scripting of Configuration
> 
> @@@ In some sense, this shouldn't be a MUST, as again, there may be
many
> @@@ ways to achieve the goals stated in the Justifiation (again,
> @@@ and implementation issue?)
> 
>    Requirement. The CLI or equivalent MUST support external scripting
of
>       configuration functions.  The scripting capability MUST NOT be
>       restricted to use with one specific scripting language.

Note the words "or equivalent" and the definition from 1.8:

   CLI

      Several requirements refer to a Command Line Interface (CLI).
      While this refers at present to a classic text oriented command
      interface, it is not intended to preclude other mechanisms which
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      may meet all the requirements that reference "CLI".
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Today, for a BCP, a CLI fits the bill.  It is Current.  It is a
Practice.
and it's arguably the Best thing that's out there today to meet the
reqs.

Room has been intentionally left for future improvements.

> 2.4.6 Support Remote Configuration Backup
> 

> @@@ maybe we want to get away from "in the clear" 
> @@@ or "anonymous" protocols(e.g. tftp/ftp)? This section doesn't
> @@@ say that the remote config backup MUST be over a secure channel

2.1.1 does:

> 2.1.1 Support Secure Channels For Management
> 
>    Requirement. The device MUST provide mechanisms to ensure
end-to-end
>       integrity and confidentially for all network traffic and
protocols
>       used to support management functions.  This MUST include at
least
>       protocols used for configuration, monitoring, configuration
                                                      ^^^^^^^^^^^^^
>       backup, 
        ^^^^^^
> 
> 2.4.7 Support Remote Configuration Restore
> 
> @@@ ditto

Added to 2.1.1.

> 
> 2.4.8 Support Text Configuration Files
> 
>    Requirement. The device MUST provide a means to remotely save a
copy
>       of the system configuration file(s) in a textual format.  It
MUST
>       NOT be necessary to use a proprietary program to view the
>       configuration. The configuration MUST also be viewable as text
on
>       the device itself. Sensitive information such as passwords that
>       could be used to compromise the security of the device MAY be
>       excluded from the saved configuration.
> 
> @@@ What relationship between what is running and the textual
> @@@ representation is required? For example, there could be
> @@@ default config values that are not by default written into
> @@@ the config.

2.4.6 attempts to address this:

> 2.4.6 Support Remote Configuration Backup
> 
>    Requirement. ...The stored configuration MUST
>       have sufficient information to restore the device to its
>       operational state at the time the configuration is saved.
>       Sensitive information such as passwords that could be used to
>       compromise the security of the device MAY be excluded from the
>       saved configuration.

An earlier draft had a requirement for saving complete configuration
info,
including "hidden" and default values (e.g. if finger is enabled in 
one release, but disabled in subsequent releases, the config should show
the settings even if they are set to the current default).   I was 
told this was impractical so it was removed.

> 2.6.1 Support Rate Limiting
> 
> @@@ I would imagine one would want a mechanism along the lines 
> @@@ of GTSM here, so that you could protect the limited resource
> @@@ (whatever it may be) between the physical interface and the
> @@@ processor performing the management function(s). i.e.,
rate-limiting
> @@@ may not be enough to stop an attacker who has deduced where
> @@@ the resource limitation (potential DoS) exists.

The -00 draft included GTSM, but as it was not standardized, it was
moved
to the -info draft.  See

  http://www.ietf.org/internet-drafts/draft-jones-opsec-info-00.txt

> 2.9.1 Ability to Accurately Count Filter Hits
> 
> @@@ s/Accurately// 
> @@@ i.e., as opposed to inaccurately count, I suppose

Yes.  The adverb was placed there deliberately as a result of
experience using filter counters that were not accurate.

> 2.9.6 Filter Counters Must Be Accurate
> 
> @@@ Again, as opposed to "inaccurate" filter counts?

Yes.

> 2.11.3 Ability to Log Locally
> 
>    Requirement.
> 
>       It SHOULD be possible to log locally on the device itself.
> 
>    Justification. Local logging is important for viewing information
>       when connected to the device.  It provides some backup of log
data
>       in case remote logging fails.  It provides a way to view logs
>       relevant to one device without having to sort through a possibly
>       large set of logs from other devices.
> 
>    Examples. One example of local logging would be a memory buffer
that
>       receives copies of messages sent to the remote log server.
>       Another example might be a local syslog server (assuming the
>       device is capable of running syslog and has some local storage).
> 
>    Warnings. Storage on the device may be limited.  High volumes of
>       logging may quickly fill available storage, in which case there
>       are two options: new logs overwrite old logs (possibly via the
use
>       of a circular memory buffer or log file rotation), or logging
>       stops.
> 
> @@@ also, it should be possible to log to a local device (say
> @@@ the console)

This req had that sort of logging in view, as well as the possibility
of logging to local disk Let me know if there is wording that could
make it more clear

> without hanging the box.

What ?  You want boxes to not crash ?  Picky, picky :-)

The following two:

> 2.14 Security Features Must Not Cause Operational Problems
> 2.15 Security Features Should Have Minimal Performance Impact

are intended to be catch-alls.


> 2.11.4 Ability to Maintain Accurate System Time
> 
> @@@ again, it looks like the requirement is for resolution rather
> @@@ than accuracy. i.e., "high resolution inaccurate system
> @@ time"?

Both are important to security.   Could be split as separate reqs
with different justification, but I think they are linked closely
enough that it makes sense to leave them together.

> 2.11.7 Logs Must Be Timestamped
> 
>    Requirement. The device MUST time-stamp all log messages.  The
>       time-stamp MUST be accurate to within a second or less.  The
>       time-stamp MUST include a timezone.
> 
> @@@ and maybe it should be possible to turn timestamping off?

Why ?

> 2.12.13 Default Privilege Level Must Be 'None'
> 
>    Requirement. The default privilege level MUST NOT allow any access
to
>       management or configuration functions.  
> 
> @@@ MUST seems too strong here. SHOULD would be more appropriate.

Changed.

> 2.14 Security Features Must Not Cause Operational Problems
> 
>    Requirement. The use of security features specified by the
>       requirements in this document MUST NOT cause severe operational
>       problems.
> 
>    Justification. Security features which cause operational problems
may
>       leave the operator with no mechanism for enforcing appropriate
>       policy.
> 
>    Examples. Some examples of severe operational problems include:
> 
>       *  crashes the device
> 
>       *  makes the device unmanageable
> 
>       *  causes the loss of data
> 
>       *  consumes excessive resources (CPU, memory, bandwidth)
> 
>    Warnings. None.
> 
> @@@ this is like saying "The device MUST NOT have bugs". I don't
> @@@ see what this one gains us

Actually, there was one in there that said basically "vendor shall fix
well known vulnerabilities in a timely fashion", but the devil was
in the definitions, so it got moved to -info.

And, yes, not crashing seems obvious.   Not slowing to a crawl or 
freezing when logging is enabled seems obvious.  But I've seen
enough of this in live, released, operational systems that I 
think it needs to be made explicit.

> 4.1 Identify Origin of IP Stack
> 
> 
> @@@ I'm not sure about this one. At some point in the (near) future
> @@@ there will likely be so many IP stacks that this won't be
> @@@ useful. In addition, what are the commercial concerns that
> @@@ this forces a vendor to disclose (I'm not sure about the
> @@@ implications, which is why I ask)?
> 
> 4.2 Identify Origin of Operating System
> 
>    Requirement. The vendor MUST disclose the origin or basis of the
>       operating system (OS).
> 
>    Justification. This information is required to better understand
the
>       security vulnerabilities that may be inherent to the OS based on
>       its origin.
> 
>    Examples. "The operating system is based on Linux kernel 2.4.18."
> 
>    Warnings. None.
>
> @@@ ditto section 4.1

These are there to aid in testing and certification.  Knowing that a
system is based on a BSD core, I can more effectively use my testing
time by hitting it with know BSD exploits rather than wasting time
with Windows exploits.  It allows focused testing.  If you're still
vulnerable to old, well-know exploits, it will reduce my confidence
in the product.  If you pass, it shows due diligence.

If you're not going to do such testing, I can see that these might 
not be important to you.

I see that they may be hard business issues.

Both dropped a SHOULD.  Customers who have a stronger requirement
can "negotiate" this back up to a "MUST" when talking to a vendor.

Thanks,
---George Jones






_______________________________________________
routing-discussion mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/routing-discussion