Re: Initial Logging capabiltiies document

["George Jones" <eludom@gmail.com>]

Comments inline.   Search for "gmj>".

----George

Abstract

  This document lists logging capabilities needed to support the
  current practices described in Operational Security Current Practices
  [CURPRAC] and logical enhancements to those practices if the
  capability existed.

gmj> Awkward.  Try "[CURPRAC].  It also lists capabilities needed
gmj> to support good security practices not listed in [CURPRAC].

1.1.  Threat Model

  The logging capabilities are derived from real world observations
  where unexpected activities in a network infrastructure caused
  concern to the network operator.  Examples of such activities are:

     An adversary or unauthorized user login into an infrastructure
     device.  The risk is that the configuration or other operating
     parameter could be modified.

     A device becomes overwhelmed, throttles, or crashes.  An unaware
     operator cannot return the device to optimal operating conditions

gmj>  Replace that last sentance:  "Without logging or some other mechanism
gmj>  to notifify the operator of the condition, the operator will not know
gmj>  that action is required to return the device to optimal
operating condition."

     Network problems cannot be properly diagnosed without information.
     Information does not exist unless generated

  Threats to the network devices may be classified into broad
  categories such as the device status or configuration is modified
  without notice by the network operator, captured data traffic or
  notification messages from the device are intercepted by a third
  party, or logging data may not be properly stored rendering forensic
  activity worthless.

gmj> s/previous paragraph/
gmj>    Threats to the network devices may be classified into broad
gmj>    categories such as:
gmj>
gmj>      * Unexpected device status or configuration change
gmj>      * Failure to send log messages
gmj>      * Interception of log messages
gmj>      * Failure to store log messages/


1.2.  Capabilities or Requirements ?

gmj> s/or/vs./,s/ ?//

  Capabilities may or may not be requirements.  That is a local
  determination that must be made by each operator with reference to



Cain                    Expires December 28, 2006               [Page 3]

Internet-Draft            Logging Capabilities                 June 2006


  the policies that they must support.  This document, together with
  [CURPRAC] will assist network operators in identifying their security
  capability requirements and communicating them clearly to vendors.

gmj> May also want to cite profiles here (if we do them).

gmj> Thses sections (1.2-1.4) should be boilerlate for capabilities docs.

1.4.  Definitions

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in [RFC2119].

  The use of the RFC 2119 keywords is an attempt, by the author, to
  assign an expectation level ("MUST", "SHOULD", "MAY") to the each
  capability.  It must be noted that different organizations,
  operational environments, policies and legal environments will
  generate different requirement levels.

  NOTE: This document defines capabilities.  This document does not
  define requirements, and there is no requirement that any particular
  capability be implemented or deployed.  The use of the terms MUST,
  SHOULD, and so on are in the context of each capability in the sense
  that if you conform to any particular capability then you MUST or
  SHOULD do what is specified for that capability, but there is no
  requirement that you actually do conform to any particular
  capability.

gmj> These last two paragraphs look like 3871 boilerplate.  The
framework addresses
gmj> these.  They don't need to be here.  Leave the first paragraph
(the required
gmj> citation of RFC2119) in, but don't use the keywords in the
capability descritions.


Cain                    Expires December 28, 2006               [Page 4]

Internet-Draft            Logging Capabilities                 June 2006


2.  Functional Capabilities of Log Generating Systems

  The capabilities in this section are intended to list testable,
  functional capabilities that are needed to operate devices securely
  and meet the obligations of Section Threat Model.

2.1.   Logging Facility Uses Protocols Subject To Open Review

  Capability

     The device MUST provide a logging facility that is based on

gmj>  1,$s/MUST provide/provides/g

     protocols subject to open review.  Custom or proprietary logging
     protocols MAY be implemented provided the same information is made
     available.

2.17.2.   Configurable Destination TCP Port

  Capability

     Devices should allow for the configuration of the destination
     syslog TCP port number.

gmj> Standard syslog rides on UDP.


3.  Functional Capabilities of Log Storage Systems

gmj> I would argue that these are out of scope.

4.  Additional Operational Practices

  This section describes practices not covered in [CURPRAC].  They are
  included here to provide justification for capabilities that
  reference them.

  This section will be populated from comments received on this
  internet-draft.

gmj> good.  All capabilities drafts should have a section like this....
gmj> if no capababiliites are added in addition to those in Merike's draft,
gmj> it just gets deleted prior to publication.


5.  Security Considerations

  Security capabilities of network devices is the subject matter of
  this entire memo.  The capabilities listed cite practices in
  [CURPRAC] that they are intended to support.  [CURPRAC] also defines
  the general threat model, practices, and lists justifications for
  each practice.

gmj> You should have Chris Lonvick and crew look this over (Chris ?)

---George