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

[David Meyer <[e-mail]>]

>> >    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.

	Sounds fine.

>> > 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.

	Ok.

>> > 2.4.7 Support Remote Configuration Restore
>> > 
>> > @@@ ditto
>> 
>> Added to 2.1.1.

	OK.

>> > 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.

	This turns out to be a major pain though, and it would be
	"nice" if it would be possible.

>> > 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

	Will be RFC 3682 any day now.

>> > 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.

	But isn't this like saying: No bugs in clocks?

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

	Again, who purposely builds inaccurate clocks for this
	application (maybe someone does)? Wouldn't it (the
	inaccurate counter) be a bug? i.e., isn't the requirement
	just saying no bugs in the filter counters?

>> > 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 :-)

	well, you know...

>> 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 ?

	Because I'm an operator and I have some (arbitrary)
	reason want to, and a vendor wants to give it to me. That
	shouldn't violate the BCP. In any event, that was my
	thinking. 
>> 
>> > 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.

	Ok.

>> > 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.

	I understand your point.

>> > 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.

	Seems reasonable.

	Thanks 

	Dave

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