[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 3871

None.                                                   G. Jones, Editor
Internet-Draft                                     The MITRE Corporation
Expires: April 24, 2004                                 October 25, 2003


    Operational Security Requirements for IP Network Infrastructure:
                         Best-Current-Practices
                          draft-jones-opsec-02

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 24, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

   This document defines a list of operational security requirements for
   the infrastructure of large IP networks (routers and switches) which
   are considered to be best current practice (BCP). A framework is
   defined for specifying "profiles", which are collections of
   requirements applicable to certain classes of devices (all,
   core-only, edge-only...). The goal is to provide consumers of network
   equipment a clear, concise way of communicating their security
   requirements to vendors of such equipment. The requirements in this
   document are considered to be best current practice (BCP). Comments
   to: "opsec-comment@ops.ietf.org".





Jones, Editor            Expires April 24, 2004                 [Page 1]

Internet-Draft     Operational Security Requirements        October 2003


Table of Contents

   1.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  5
   1.1     Goals  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   1.2     Scope  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   1.3     Definition of a Secure Network . . . . . . . . . . . . . .  5
   1.4     Intended Audience  . . . . . . . . . . . . . . . . . . . .  6
   1.5     Format . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   1.6     Intended Use . . . . . . . . . . . . . . . . . . . . . . .  7
   1.7     Definitions  . . . . . . . . . . . . . . . . . . . . . . .  7
   2.      Functional Requirements  . . . . . . . . . . . . . . . . .  8
   2.1     Device Management Requirements . . . . . . . . . . . . . .  8
   2.1.1   Support Secure Management Channels . . . . . . . . . . . .  8
   2.2     In-Band Management Requirements  . . . . . . . . . . . . .  8
   2.2.1   Use Encryption Algorithms Subject To Open Review . . . . .  9
   2.2.2   Use Strong Encryption  . . . . . . . . . . . . . . . . . .  9
   2.3     Out-of-Band (OoB) Management Requirements  . . . . . . . . 10
   2.3.1   Support a Non-IP 'Console' interface . . . . . . . . . . . 10
   2.3.2   Support A Simple Default Communication Profile On The
           'Console'  . . . . . . . . . . . . . . . . . . . . . . . . 10
   2.3.3   Support Separate Management Plane IP Interfaces  . . . . . 11
   2.3.4   No Forwarding Between Management Plane And Other
           Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 12
   2.3.5   Provide Separate Resources For The Management Plane  . . . 12
   2.4     Configuration and Management Interface Requirements  . . . 12
   2.4.1   CLI Provides Access to All Configuration and
           Management Functions . . . . . . . . . . . . . . . . . . . 13
   2.4.2   CLI Uses Existing Authentication Mechanisms  . . . . . . . 13
   2.4.3   CLI Supports Scripting of Configuration  . . . . . . . . . 13
   2.4.4   CLI Supports Management Over 'Slow' Links  . . . . . . . . 14
   2.4.5   Support Software Installation  . . . . . . . . . . . . . . 14
   2.4.6   Support Remote Configuration Backup  . . . . . . . . . . . 15
   2.4.7   Support Remote Configuration Restore . . . . . . . . . . . 16
   2.4.8   Support Human-Readable Configuration File  . . . . . . . . 16
   2.5     IP Stack Requirements  . . . . . . . . . . . . . . . . . . 16
   2.5.1   Ability to Identify All Listening Services . . . . . . . . 17
   2.5.2   Ability to Disable Any and All Services  . . . . . . . . . 17
   2.5.3   Listening Services Should Be Off By Default  . . . . . . . 17
   2.5.4   Ability to Control Service Bindings for Listening
           Services . . . . . . . . . . . . . . . . . . . . . . . . . 18
   2.5.5   Ability to Control Service Source Address  . . . . . . . . 18
   2.5.6   Support Automatic Anti-spoofing for Single-Homed
           Networks . . . . . . . . . . . . . . . . . . . . . . . . . 19
   2.5.7   Directed Broadcasts Disabled by Default  . . . . . . . . . 20
   2.6     Rate Limiting Requirements . . . . . . . . . . . . . . . . 20
   2.6.1   Support Rate Limiting  . . . . . . . . . . . . . . . . . . 20
   2.6.2   Support Rate Limiting Based on State . . . . . . . . . . . 21
   2.7     Basic Filtering Capabilities . . . . . . . . . . . . . . . 21



Jones, Editor            Expires April 24, 2004                 [Page 2]

Internet-Draft     Operational Security Requirements        October 2003


   2.7.1   Ability to Filter Traffic  . . . . . . . . . . . . . . . . 21
   2.7.2   Ability to Filter Traffic TO the Device  . . . . . . . . . 22
   2.7.3   Ability to Filter Traffic THROUGH the Device . . . . . . . 22
   2.7.4   Ability to Filter Without Performance Degradation  . . . . 22
   2.7.5   Ability to Filter Updates  . . . . . . . . . . . . . . . . 23
   2.7.6   Ability to Specify Filter Actions  . . . . . . . . . . . . 24
   2.7.7   Ability to Log Filter Actions  . . . . . . . . . . . . . . 24
   2.8     Packet Filtering Criteria  . . . . . . . . . . . . . . . . 25
   2.8.1   Ability to Filter on Protocols . . . . . . . . . . . . . . 25
   2.8.2   Ability to Filter on Addresses . . . . . . . . . . . . . . 25
   2.8.3   Ability to Filter on Any Protocol Header Fields  . . . . . 25
   2.8.4   Ability to Filter Inbound and Outbound . . . . . . . . . . 26
   2.9     Packet Filtering Counter Requirements  . . . . . . . . . . 26
   2.9.1   Ability to Accurately Count Filter Hits  . . . . . . . . . 26
   2.9.2   Ability to Display Filter Counters . . . . . . . . . . . . 27
   2.9.3   Ability to Display Filter Counters per Rule  . . . . . . . 27
   2.9.4   Ability to Display Filter Counters per Filter
           Application  . . . . . . . . . . . . . . . . . . . . . . . 28
   2.9.5   Ability to Reset Filter Counters . . . . . . . . . . . . . 28
   2.9.6   Filter Counters Must Be Accurate . . . . . . . . . . . . . 28
   2.10    Other Packet Filtering Requirements  . . . . . . . . . . . 29
   2.10.1  Filter, Counters, and Filter Log Must Have Minimal
           Performance Impact . . . . . . . . . . . . . . . . . . . . 29
   2.10.2  Ability to Specify Filter Log Granularity  . . . . . . . . 30
   2.11    Event Logging Requirements . . . . . . . . . . . . . . . . 30
   2.11.1  Logging Facility Conforms to Open Standards  . . . . . . . 30
   2.11.2  Ability to Log to Remote Server  . . . . . . . . . . . . . 31
   2.11.3  Ability to Log Locally . . . . . . . . . . . . . . . . . . 31
   2.11.4  Ability to Maintain Accurate System Time . . . . . . . . . 31
   2.11.5  Logs Must Be Timestamped . . . . . . . . . . . . . . . . . 32
   2.11.6  Logs Contain Untranslated Addresses  . . . . . . . . . . . 32
   2.12    Authentication, Authorization, and Accounting (AAA)
           Requirements . . . . . . . . . . . . . . . . . . . . . . . 33
   2.12.1  Authenticate All User Access . . . . . . . . . . . . . . . 33
   2.12.2  Support Authentication of Individual Users . . . . . . . . 33
   2.12.3  Support Simultaneous Connections . . . . . . . . . . . . . 34
   2.12.4  Ability to Disable All Local Accounts  . . . . . . . . . . 34
   2.12.5  Support Centralized User Authentication Methods  . . . . . 35
   2.12.6  Support Local User Authentication Method . . . . . . . . . 35
   2.12.7  Support Configuration of Order of Authentication
           Methods  . . . . . . . . . . . . . . . . . . . . . . . . . 36
   2.12.8  No Unencrypted Transmission of Reusable Plain-text
           Passwords  . . . . . . . . . . . . . . . . . . . . . . . . 36
   2.12.9  No Default Passwords . . . . . . . . . . . . . . . . . . . 37
   2.12.10 Passwords Must Be Explicitly Configured Prior To Use . . . 37
   2.12.11 Ability to Define Privilege Levels . . . . . . . . . . . . 38
   2.12.12 Ability to Assign Privilege Levels to Users  . . . . . . . 38
   2.12.13 Default Privilege Level Must Be Read Only  . . . . . . . . 39



Jones, Editor            Expires April 24, 2004                 [Page 3]

Internet-Draft     Operational Security Requirements        October 2003


   2.12.14 Change in Privilege Levels Requires Re-Authentication  . . 39
   2.12.15 Support Recovery Of Privileged Access  . . . . . . . . . . 39
   2.12.16 Accounting Records . . . . . . . . . . . . . . . . . . . . 40
   2.13    Layer 2 Devices Must Meet Higher Layer Requirements  . . . 41
   3.      Documentation Requirements . . . . . . . . . . . . . . . . 42
   3.1     Document Listening Services  . . . . . . . . . . . . . . . 42
   4.      Assurance Requirements . . . . . . . . . . . . . . . . . . 43
   4.1     Comply With Relevant IETF RFCs on All Protocols
           Implemented  . . . . . . . . . . . . . . . . . . . . . . . 43
   4.2     Identify Origin of IP Stack  . . . . . . . . . . . . . . . 44
   4.3     Identify Origin of Operating System  . . . . . . . . . . . 44
   5.      Security Considerations  . . . . . . . . . . . . . . . . . 46
           References . . . . . . . . . . . . . . . . . . . . . . . . 47
           Author's Address . . . . . . . . . . . . . . . . . . . . . 48
   A.      Requirement Profiles . . . . . . . . . . . . . . . . . . . 49
   A.1     Minimum Requirements Profile . . . . . . . . . . . . . . . 49
   A.1.1   Functional Requirements  . . . . . . . . . . . . . . . . . 49
   A.1.2   Documentation Requirements . . . . . . . . . . . . . . . . 52
   A.1.3   Assurance Requirements . . . . . . . . . . . . . . . . . . 53
   A.2     Layer 3 Network Core Profile . . . . . . . . . . . . . . . 53
   A.2.1   Functional Requirements  . . . . . . . . . . . . . . . . . 53
   A.3     Layer 3 Network Edge Profile . . . . . . . . . . . . . . . 53
   A.3.1   Functional Requirements  . . . . . . . . . . . . . . . . . 53
   B.      Acknowledgments  . . . . . . . . . . . . . . . . . . . . . 55
           Intellectual Property and Copyright Statements . . . . . . 56


























Jones, Editor            Expires April 24, 2004                 [Page 4]

Internet-Draft     Operational Security Requirements        October 2003


1. Introduction

1.1 Goals

   This document defines a list of operational security requirements for
   the infrastructure of large IP networks (routers and switches) which
   are considered to be best current practice (BCP). The goal is to
   provide consumers of IP network infrastructure a clear, concise way
   of communicating their security requirements to equipment vendors.

1.2 Scope

   The primary scope of these requirements is intended to cover the
   infrastructure of large IP networks (e.g. routers and switches).
   Certain groups (or "profiles", see below) apply only in specific
   situations (e.g. all, edge-only, core-only).  The requirements listed
   in the minimum profile are intended to apply to all managed
   infrastructure devices.

   General purpose hosts (including infrastructure hosts such as name/
   time/log/AA servers, etc.), unmanaged, or customer managed devices
   (e.g.  firewalls, Intrusion Detection System, dedicated VPN devices,
   etc.) are explicitly out of scope.  This means that while the
   requirements in the minimum profile (and others) may apply,
   additional requirements will not be added to account for their unique
   needs.

   Confidentiality and integrity of customer data are outside the scope.

   While, the examples given are written with IPv4 in mind, most of the
   requirements are general enough to apply to IPv6.

1.3 Definition of a Secure Network

   For the purposes of this document, a secure network is one in which:

   o  the network keeps passing legitimate customer traffic
      (availability)

   o  traffic goes where its supposed to go
      (availability,confidentiality)

   o  the network elements remain manageable (availability)

   o  only authorized users can manage network elements (authorization)

   o  there is record of all security related events (accountability)




Jones, Editor            Expires April 24, 2004                 [Page 5]

Internet-Draft     Operational Security Requirements        October 2003


   o  the network operator has the necessary tools to detect and respond
      to illegitimate traffic

   The following assumptions are made:

   o  Devices are physically secure.

   o  The management infrastructure (AAA/DNS/log server, SNMP management
      stations, etc.) is secure.


1.4 Intended Audience

   There are two intended audiences: the end user (consumer) who
   selects, purchases, and operates IP network equipment, and the
   vendors who create them.

1.5 Format

   The individual requirements are listed in one of the three sections
   listed below.

   o  Section 2 lists functional requirements.

   o  Section 3 lists documentation requirements.

   o  Section 4 lists assurance requirements.

   Within these areas, requirements are grouped in major functional
   areas (e.g., logging, authentication, filtering, etc.)

   Each requirement has the following subsections:

   o  The Requirement (What)

   o  The Justification (Why)

   o  Examples (How)

   o  Warnings (if applicable)

   The requirement describes a policy to be supported by the device. The
   justification tells why and in what context the requirement is
   important. 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. The warnings list operational concerns,



Jones, Editor            Expires April 24, 2004                 [Page 6]

Internet-Draft     Operational Security Requirements        October 2003


   deviation from standards, caveats, etc.

   Security requirements will vary across different device types and
   different organizations, depending on policy and other factors. A
   desired feature in one environment may be a requirement in another.
   Classifications must be made according to local need.

   In order to assist in classification, the Appendix Appendix A defines
   several requirement "profiles" for different types of devices.
   Profiles are simply collections of requirements.  They provide a
   concise list of the requirements that apply to certain classes of
   devices.  The profiles in this document should be reviewed to
   determine if they are appropriate the local environment.

1.6 Intended Use

   It is anticipated that this document will be used in the following
   manners:

   Security Capability Checklist The requirements in this document may
      be used as a checklist when evaluating networked products.

   Composing Profiles Different subsets of these requirements may be
      compiled to describe the needs of different devices,
      organizations, and operating environments.

   Communicating Requirements This document may be referenced, along
      with profiles, to clearly communicate security requirements.

   Basis For Testing and Certification This document may form the basis
      for testing and certification of security features of networked
      products.


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

   Unless otherwise indicated, "IP" refers to IPv4










Jones, Editor            Expires April 24, 2004                 [Page 7]

Internet-Draft     Operational Security Requirements        October 2003


2. Functional Requirements

   The requirements in this section are intended to list testable,
   functional requirements that are needed to operate devices securely.

2.1 Device Management Requirements

2.1.1 Support Secure Management Channels

   Requirement. The device MUST provide secure end-to-end channels for
      all network traffic and protocols used to support management
      functions.  This MUST include at least protocols used for
      configuration, monitoring, configuration backup, logging, time
      synchronization, authentication, and routing. This requirement MAY
      be satisfied using either In-Band or Out-of-Band management.  See
      Section 2.2 and Section 2.3.

   Justification. Secure channels ensure confidentiality and integrity
      of management traffic.

   Examples. Different mechanisms may be used with different protocols
      to satisfy this requirement.   Secure management can be achieved
      by the use of in-band protocols that support encryption, by using
      insecure protocols over top of secure transports such as TLS or
      IPsec or by the use of out-of-band management. For example

      Secure protocols: SSH, SFTP, SNMPv3, BGP, NTP, Kerberos.

      Insecure protocols tunneled: telnet, TFTP, SNMPv1 syslog, over TLS
         or IPsec

   Warnings. None.


2.2 In-Band Management Requirements

   This section lists security requirements for devices that are managed
   In-band.  "In-band management" is defined as any management done over
   the same channels and interfaces used for user/customer data.
   Examples would include using SSH for management via customer or
   Internet facing network interfaces. In-band  management has the
   advantage of lower cost (no extra interfaces or lines), but has
   significant security disadvantages:

   o  saturation of customer lines or interfaces can make the device
      unmanageable

   o  since public interfaces/channels are used, it is possible for



Jones, Editor            Expires April 24, 2004                 [Page 8]

Internet-Draft     Operational Security Requirements        October 2003


      attackers to directly address and reach the device and to attempt
      management functions

   o  in-band management traffic on public interfaces may be intercepted

   o  Since the same networking code and interfaces are shared for
      management and customer data, it is not possible to isolate
      management functions from failures in other areas (for example, a
      "magic packet" or buffer overrun that causes the data forwarding
      portions of a router to crash will also likely make it impossible
      to manage...this would not necessarily be the case if the
      management and data forwarding elements were completely separated)


2.2.1 Use Encryption Algorithms Subject To Open Review

   Requirement. If encryption is used to satisfy the Section 2.1.1
      requirements, then the encryption algorithms used MUST be subject
      to open review.

   Justification. Proprietary encryption algorithms and protocols that
      have not been subjected to public/peer review are more likely to
      have undiscovered weaknesses or flaws than open standards and
      publicly reviewed algorithms.

   Examples. For applications requiring symmetric encryption AES or 3DES
      satisfy the requirement.  For applications requiring asymmetric
      encryption RSA and Elliptic Curve satisfy the requirement.  For
      key exchange Diffie-Hellman meets the requirement.  For message
      digests MD5 and SHA meet the requirement.

   Warnings. Open review is necessary but not sufficient.  The strength
      of the algorithm and key length must also be considered.  For
      example, 56-bit DES meets the open review requirement, but is
      today considered too weak and is therefore not recommended.


2.2.2 Use Strong Encryption

   Requirement. If encryption is used to satisfy the Section 2.1.1
      requirements, then the key lengths and algorithms SHOULD be
      "strong".

   Justification. Short keys and weak algorithms threaten the
      confidentiality and integrity of communications.






Jones, Editor            Expires April 24, 2004                 [Page 9]

Internet-Draft     Operational Security Requirements        October 2003


   Examples. This document explicitly does not attempt to make any
      authoritative statement about what key lengths and algorithms
      constitute "strong" encryption. The reader is encouraged to
      consult the literature and to seek advice from trusted third
      parties to determine which algorithms and key lengths provide
      sufficiently "strong" encryption at any given time to protect data
      of a given value.

   Warnings. "Strong" is a relative term.  Long keys and strong
      algorithms are intended to increase the work factor required to
      compromise the security of the data protected.  Over time, as
      processing power increases, the security provided by a given
      algorithm and key length will degrade.  The definition of "Strong"
      must be constantly reevaluated. There may be legal issues
      governing the use of encryption and the strength of encryption
      used.


2.3 Out-of-Band (OoB) Management Requirements

   See Section 2.2 for a discussion of the advantages and disadvantages
   of In-band vs. Out-of-Band management.

2.3.1 Support a Non-IP 'Console' interface

   Requirement. The device MUST support complete configuration and
      management via a non-IP interface.

   Justification. There are times when the device *must* be managed or
      configured, even when the network is unavailable, routing and
      network interfaces are incorrectly configured, the IP stack and/or
      operating system may not be working (or may be vulnerable to
      recently discovered exploits that make their use impossible/
      inadvisable), or when high bandwidth paths to the device are
      unavailable.  In such situations, non-IP interfaces can provide a
      way to manage and configure the device.

   Examples. One example would be an RS232 (EIA232) interface that
      provides the capability to load new versions of the system
      software and to perform configuration via a command line
      interface. RS232 interfaces are ubiquitous and well understood.

   Warnings. None.


2.3.2 Support A Simple Default Communication Profile On The 'Console'





Jones, Editor            Expires April 24, 2004                [Page 10]

Internet-Draft     Operational Security Requirements        October 2003


   Requirement. The device MUST support a simple default profile of
      communications parameters on the Non-IP management interface.
      These communications parameters MUST be published in the system
      documentation. There SHOULD be a method defined and published for
      returning to the default configuration.

   Justification. A simple, standard profile minimizes confusion and
      maximizes the chances of successful and well understood recovery
      practices. This profile follows the principals of "least surprise"
      and "Be liberal in what you accept and conservative in what you
      send."

   Examples. The following is a profile widely used for RS232 console
      connections: the only required signals SHOULD be Transmit Data
      (TD), Receive Data (RD) and Signal Ground (SG).  Other signals,
      SHOULD NOT be required (e.g. DCD, RTS, CTS, DSR, etc.).  The
      default settings SHOULD be 9600bps, 8 bit data, no parity, one
      stop-bit (9600 8n1). Sending a break would be one way to signal
      that the communications parameters should be reset.

   Warnings. The default RS232 profile described above does not support
      hardware flow control.


2.3.3 Support Separate Management Plane IP Interfaces

   Requirement. The device MAY provide designated network interface(s)
      that are used for management plane traffic.

   Justification. A separate management plane interface allows
      management traffic to be segregated from other traffic (data/
      forwarding plane, control plane).  This reduces the risk that
      unauthorized individuals will be able to observe management
      traffic and/or compromise the device.

      This requirement applies in situations where a separate OoB
      management network exists.

   Examples. This requirement may be satisfied, for example, with a
      predefined Ethernet port dedicated to management and isolated from
      customer traffic.

   Warnings. The use of this type of interface depends on proper
      functioning of both the operating system and the IP stack, as well
      as good, known configuration at least on the portions of the
      device dedicated to management.  To talk to an ethernet interface
      for management, you must know, for instance, it's IP address.




Jones, Editor            Expires April 24, 2004                [Page 11]

Internet-Draft     Operational Security Requirements        October 2003


2.3.4 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.3 then the device MUST
      not forward traffic between the management plane and
      non-management plane interfaces.

   Justification. This prevents the flow, intentional or unintentional,
      of management traffic to/from places that it should not be
      originating/terminating (e.g. anything beyond the customer-facing
      interfaces).

   Examples. This requirement may be satisfied by implementing separate
      forwarding tables for management plane and non-management plane
      interfaces that do not propagate routes to each other.

   Warnings. None.


2.3.5 Provide Separate Resources For The Management Plane

   Requirement. If the device implements separate network interface(s)
      for the management plane per Section 2.3.3 then the device SHOULD
      provide separate resources and use separate software for different
      classes of interface.

   Justification. The use of separate resources and system software
      allows for fault isolation and increased reliability.  If
      something (a hacker sending a DoS flood or exercising a buffer
      overrun) takes out the forwarding plane, the management plane is
      likely to keep working, which will facilitate recovery.
      Likewise, if something causes the management plane to stop
      working, it is possible that the forwarding plane will keep doing
      its job (forwarding packets).

   Examples. Resources which should be separate include hardware
      (memory, processor), data (forwarding table), and software (OS, IP
      stack).

   Warnings. None.


2.4 Configuration and Management Interface Requirements

   This section lists requirements that document current best practice
   in device configuration and management methods.  In most cases, this
   currently involves some sort of command line interface (CLI) and
   configuration files.  It may be possible in the future to meet the



Jones, Editor            Expires April 24, 2004                [Page 12]

Internet-Draft     Operational Security Requirements        October 2003


   individual requirements via other mechanisms, specifically via
   mechanisms currently (October 2003) being defined by the IETF netconf
   working group [netconf].

2.4.1 CLI Provides Access to All Configuration and Management Functions

   Requirement. The Command Line Interface (CLI) or equivalent MUST
      allow complete access to all configuration and management
      functions.

   Justification. Restricted or incomplete access to configuration or
      management functions may make it impossible to perform necessary
      tasks.

   Examples. Examples of configuration include setting interface
      addresses, defining and applying filters, configuring logging and
      authentication, etc.  Examples of management functions include
      displaying dynamic state information such as CPU load, memory
      utilization, packet processing statistics, etc.

   Warnings. None.


2.4.2 CLI Uses Existing Authentication Mechanisms

   Requirement. The CLI or equivalent MUST utilize existing
      authentication methods.

   Justification. The use of existing authentication methods keeps the
      implementation simple and avoids needless complexity.

   Examples. If a CLI function requires authentication functions and a
      remote AAA (TACACS+, RADIUS, etc.) server is in use, then the CLI
      should be able to use that server of authentication.

   Warnings. None.


2.4.3 CLI Supports Scripting of Configuration

   Requirement. The CLI or equivalent MUST support external scripting of
      configuration functions.  The scripting capability MUST NOT
      require the use of a particular scripting language.

   Justification. Scripting is necessary when the number of managed
      devices is large and/or when changes must be implemented quickly.
      The ability to script configuration functions provides operators
      with the ability to implement solutions to problems not foreseen



Jones, Editor            Expires April 24, 2004                [Page 13]

Internet-Draft     Operational Security Requirements        October 2003


      or addressed by the vendor.

   Examples. Example uses of scripting include: tracking an attack
      across a large network, updating authentication parameters,
      updating logging parameters, updating filters, configuration
      fetching/auditing etc.  Some languages that are currently used for
      scripting include expect, Perl and TCL. Some properties of the
      command language that enhance the ability to script are:
      simplicity, regularity and consistency.

   Warnings. None.


2.4.4 CLI Supports Management Over 'Slow' Links

   Requirement. The device MUST support a command line interface (CLI)
      or equivalent mechanism that works over low bandwidth connections

   Justification. There are situations where high bandwidth for
      management is not available, for example when in-band connections
      are overloaded during an attack or when low-bandwidth, out-of-band
      connections such as modems must be used... and it is often under
      these conditions that it is most crucial to be able to perform
      management and configuration functions.

   Examples. The network is down.  The network engineer just disabled
      routing by mistake on the sole gateway router in a remote unmanned
      data center. The only access to the device is over a modem
      connected to a console port. The data center customers are
      starting to call the support line. The GUI management interface is
      redrawing the screen multiple times...slowly... at 9600bps.

   Warnings. One consequence of this requirement may be that requiring a
      GUI interface for management is unacceptable unless it can be show
      to work acceptably over slow links.


2.4.5 Support Software Installation

   Requirement. The device MUST provide a means to install new software
      versions. It MUST be possible to install new software while the
      device is disconnected from all public IP networks. This MUST NOT
      rely on previous installation and/or configuration.

   Justification.

      *  Vulnerabilities are often discovered in the base software
         (operating systems, etc.) shipped by vendors. Often mitigation



Jones, Editor            Expires April 24, 2004                [Page 14]

Internet-Draft     Operational Security Requirements        October 2003


         of the risk presented by these vulnerabilities can only be
         accomplished by updates to the vendor supplied software (e.g.
         bug fixes, new versions of code, etc.). Without a mechanism to
         load new vendor supplied code, it may not be possible to
         mitigate the risk posed by these vulnerabilities.

      *  It is also conceivable that malicious behavior on the part of
         hackers or unintentional behaviors on the part of operators
         could cause software on devices to be corrupted or erased.   In
         these situations, it is necessary to have a means to (re)load
         software onto the device to restore correct functioning.

      *  It is important to be able to load new software while
         disconnected from all public IP networks because the device may
         be vulnerable to old attacks before the update is complete.

   Examples.

      RS-232 The device could support uploading new code via an RS232
         console port.

      CD-ROM The device could support installing new code from a locally
         attached CD-ROM drive.

      NETWORK The device could support installing new code via a network
         interface, assuming that (a) it is disconnected from all public
         networks and (b) the device can boot an OS and IP stack from
         some read-only media with sufficient capabilities to load new
         code  from the network.

   Warnings. None.


2.4.6 Support Remote Configuration Backup

   Requirement. The device MUST provide a means to store the system
      configuration to a remote server.  The stored configuration MUST
      have sufficient information to restore the device to its
      operational state at the time the configuration is saved.

   Justification. Archived configurations are essential to enable
      auditing and recovery.

   Examples. Possible implementations include SCP, SFTP or FTP over a
      secure channel. See Section 2.1.1 for requirements related to
      secure communication channels for management protocols and data.





Jones, Editor            Expires April 24, 2004                [Page 15]

Internet-Draft     Operational Security Requirements        October 2003


   Warnings. The security of the remote server is assumed, with
      appropriate measures being outside the scope of this document.


2.4.7 Support Remote Configuration Restore

   Requirement. The device MUST provide a means to restore a
      configuration that was saved as described in Section 2.4.6. The
      system MUST be restored to its operational state at the time the
      configuration was.

   Justification. Restoration of archived configurations allows quick
      restoration of service following an outage (security related as
      well as from other causes).

   Examples. Configurations may be restored using SCP, SFTP or FTP over
      a secure channel. See Section 2.1.1 for requirements related to
      secure communication channels for management protocols and data.

   Warnings. The security of the remote server is assumed, with
      appropriate measures being outside the scope of this document.


2.4.8 Support Human-Readable Configuration File

   Requirement. The device MUST provide a means to remotely save a copy
      of the system configuration file(s) in a human-readable form.  It
      MUST NOT be necessary to use a proprietary program to view the
      configuration. The configuration MUST also be viewable in human
      readable form on the device itself.

   Justification. Having configurations in human-readable format is
      necessary to enable off-line audits of the system configuration.
      Having them in simple, non-proprietary formats also facilitates
      automation of configuration checking.

   Examples. A simple text-based configuration file would satisfy this
      requirement.

   Warnings. Offline copies of configurations should be well protected
      as they often contain sensitive information such as SNMP community
      strings, passwords, network blocks, customer information, etc.


2.5 IP Stack Requirements






Jones, Editor            Expires April 24, 2004                [Page 16]

Internet-Draft     Operational Security Requirements        October 2003


2.5.1 Ability to Identify All Listening Services

   Requirement. The vendor MUST:

      *  Provide a means to display all services that are listening for
         network traffic directed at the device from any external
         source.

      *  Display the interfaces on which each service is listening.

      *  Include both open standard and vendor proprietary services.

   Justification. This information is necessary to enable a thorough
      assessment of the security risks associated with the operation of
      the device (e.g., "does this protocol allow complete management of
      the device without also requiring authentication, authorization,
      or accounting"?).  The information also assists in determining
      what steps should be taken to mitigate risk (e.g., "should I turn
      this service off "?)

   Examples. If, for example, the device is listening for SNMP on all
      interfaces, then this requirement could be met by the provision of
      a command which displays that fact.

   Warnings. None.


2.5.2 Ability to Disable Any and All Services

   Requirement. The device MUST provide a means to turn off any external
      services listening.

   Justification. The ability to disable services for which there is no
      operational need will allow administrators to reduce the overall
      risk posed to the device.

   Examples. Processes that listen on TCP and UDP ports would be prime
      examples of services that it must be possible to disable.

   Warnings. None.


2.5.3 Listening Services Should Be Off By Default

   Requirement. Services that cause the device to listen for traffic
      destined for itself SHOULD be off by default.  The user SHOULD
      have to take explicit actions to enable any such services.




Jones, Editor            Expires April 24, 2004                [Page 17]

Internet-Draft     Operational Security Requirements        October 2003


   Justification. Open ports have the potential to expose
      vulnerabilities. The user, not the vendor, should decide which
      services are required and what risks to accept.  This will also
      prevent systems from being compromised through the misuse of
      services which the user was unaware were enabled.

   Examples. If the device supports SSH, HTTP, telnet and SNMP, in the
      default configuration they should all be disabled.

   Warnings. None.


2.5.4 Ability to Control Service Bindings for Listening Services

   Requirement. The device MUST provide a means for the user to specify
      the bindings used for all listening services.  It MUST support
      binding to a list of addresses and netblocks and SHOULD support
      configuration of binding services to particular interfaces,
      including loopback addresses.

   Justification. This greatly reduces the need for complex filters.  It
      reduces the number of ports listening, and thus the number of
      potential avenues of attack.  It ensures that only traffic
      arriving from legitimate addresses and/or on designated interfaces
      can access services on the device.

   Examples. If the device listens for inbound SSH connections, this
      requirement means that it should be possible to specify that the
      device will only listen to connections destined to specific
      addresses (e.g. the address of the loopback interface) or received
      on certain interfaces (e.g. an ethernet interface designated as
      the "management" interface). It should be possible in this example
      to configure the device such that the SSH is NOT listening on
      every interface or to every address configured on the device.

   Warnings. None.


2.5.5 Ability to Control Service Source Address

   Requirement. The device MUST provide a means that allows the user to
      specify the source address used for all outbound connections or
      transmissions originating from the device.  It MUST be possible to
      specify source addresses independently for each type of outbound
      connection or transmission.  Source addresses MUST be limited to
      addresses that are assigned to interfaces (including loopbacks)
      local to the device.




Jones, Editor            Expires April 24, 2004                [Page 18]

Internet-Draft     Operational Security Requirements        October 2003


   Justification. This allows remote devices receiving connections or
      transmissions to use source filtering as one means of
      authentication.  For example, if SNMP traps were configured to use
      a known loopback address as their source, the SNMP workstation
      receiving the traps (or a firewall in front of it) could be
      configured to receive SNMP packets only from that address.

   Examples. None.

   Warnings. None.


2.5.6 Support Automatic Anti-spoofing for Single-Homed Networks

   Requirement. The device MUST provide a means to designate particular
      interfaces as servicing single-homed networks and MUST provide an
      option to automatically apply anti-spoofing to such interfaces.
      This option MUST work in the presence of dynamic routing and
      dynamically assigned addresses.  It MUST NOT negatively impact
      performance.  It MUST provide accurate counts of spoofed packets
      that were dropped with logging options. It SHOULD be possible to
      apply the option to an interface with a single command.  For the
      purposes of this requirement a "single-homed network" is defined
      as one for which

      *  There is only one (logical) upstream connection

      *  Routing is symmetric

      A "spoofed packet" is defined as a "packet having a source address
      that, by application of the current forwarding tables, would not
      have its return traffic routed back through the interface on which
      it was received."

   Justification. See [RFC2867] Network Ingress Filtering.

   Examples. This requirement could be satisfied in several ways.  It
      could be satisfied by the provision of a single command that
      automatically generates and applies filters to an interface that
      implements anti-spoofing.   It could be satisfied by the provision
      of a command that causes the return path for packets received to
      be checked against the current routing tables and dropped if they
      would not be forwarded back through the interface on which they
      were received.

   Warnings. None.





Jones, Editor            Expires April 24, 2004                [Page 19]

Internet-Draft     Operational Security Requirements        October 2003


2.5.7 Directed Broadcasts Disabled by Default

   Requirement. The default configuration of the device MUST ensure
      that:

      *  It will not respond to any directed broadcasts to any broadcast
         domains of which it is a member.

      *  It will not propagate any directed broadcasts to any broadcast
         domains to which it is directly connected.

      There SHOULD be a mechanism to re-enable directed broadcasts on a
      per-interface basis.

   Justification. Directed broadcasts have few legitimate uses in modern
      networks and are easily abused to amplify denial of service
      attacks (e.g., SMURF attacks). [RFC2644] recommends the same
      change in default settings as a Best Current Practice.

   Examples. None.

   Warnings. The requirement is in violation of [RFC1812].


2.6 Rate Limiting Requirements

2.6.1 Support Rate Limiting

   Requirement. The device MUST provide the capability to limit the rate
      at which it will pass traffic based on protocol, port, and
      interface: and to rate-limit input and/or output separately on
      each interface.  It SHOULD allow filtering on any protocol and
      MUST allow filtering on at least IP, ICMP, UDP, and TCP. This
      feature SHOULD be implemented with minimal impact to system
      performance.

   Justification. This requirement provides a means of reducing or
      eliminating the impact of certain types of attacks.

   Examples. Assume that a web hosting company provides space in its
      data-center to a company that becomes unpopular with a certain
      element of network users, who then decide to flood the web server
      with inbound ICMP traffic. It would be useful in such a situation
      to be able to rate-filter inbound ICMP traffic at the
      data-center's border routers.   On the other side, assume that a
      new worm is released that infects vulnerable database servers such
      that they then start spewing traffic on TCP port 1433 aimed at
      random destination addresses as fast as the system and network



Jones, Editor            Expires April 24, 2004                [Page 20]

Internet-Draft     Operational Security Requirements        October 2003


      interface of the infected  server is capable. Further assume that
      a data center has many vulnerable servers that are infected and
      simultaneously sending large amounts of traffic with the result
      that all outbound links are saturated. Implementation of this
      requirement, would allow the network operator to rate limit
      inbound and/or outbound TCP 1433 traffic (possibly to a rate of 0
      packets/bytes per second) to respond to the attack and maintain
      service levels for other legitimate customers/traffic.

   Warnings. None.


2.6.2 Support Rate Limiting Based on State

   Requirement. For stateful protocols it SHOULD be possible to rate
      limit traffic based on session state.

   Justification. This allows appropriate response to certain classes of
      attack.

   Examples. For example, for TCP sessions, it should be possible to
      rate limit based on the SYN, SYN-ACK, RST, or other bit state.

   Warnings. None.


2.7 Basic Filtering Capabilities

2.7.1 Ability to Filter Traffic

   Requirement. The device MUST provide a means to filter IP packets on
      any interface implementing IP.

      In this document a "filter" is defined as a group of one or more
      rules where each rule specifies one or more match criteria as
      specified in Section 2.8.

      Also see the specific filtering requirements that follow this one.

   Justification. Packet filtering is important because it provides a
      basic means of implementing policies that specify which traffic is
      allowed and which is not.  It also provides a basic tool for
      responding to malicious traffic.

   Examples. Access control lists that allow filtering based on protocol
      and/or source/destination address and or source/destination port
      would be one example.




Jones, Editor            Expires April 24, 2004                [Page 21]

Internet-Draft     Operational Security Requirements        October 2003


   Warnings. None.


2.7.2 Ability to Filter Traffic TO the Device

   Requirement. It MUST be possible to apply the filtering mechanism to
      traffic that is addressed directly to the device via any of its
      interfaces - including loopback interfaces.

   Justification. This is important because it allows filters to be
      applied that protect the device itself from attacks and
      unauthorized access.

   Examples. Examples of this might include filters that permit only
      SNMP and SSH traffic from an authorized management segment
      directed to the device itself, while dropping all other traffic
      addressed to the device.

   Warnings. None.


2.7.3 Ability to Filter Traffic THROUGH the Device

   Requirement. It MUST be possible to apply the filtering mechanism to
      traffic that is being routed (switched) through the device.

   Justification. This is important because it permits implementation of
      basic policies on devices that carry transit traffic (routers,
      switches, firewalls, etc.).

   Examples. One simple and common way to meet this requirement is to
      provide the ability to filter traffic inbound to each interface
      and/or outbound from each interface. Ingress filtering as
      described in [RFC2827] provides one example of the use of this
      capability.

   Warnings. None.


2.7.4 Ability to Filter Without Performance Degradation

   Requirement. The device MUST provide a means to filter packets
      without performance degradation. The device MUST be able to filter
      on ALL interfaces (up to the maximum number possible)
      simultaneously and with multiple filters per interface (e.g.,
      inbound and outbound).





Jones, Editor            Expires April 24, 2004                [Page 22]

Internet-Draft     Operational Security Requirements        October 2003


   Justification. This is important because it enables the
      implementation of filtering wherever and whenever needed.  To the
      extent that filtering causes degradation, it may not be possible
      to apply filters that implement the appropriate policies.

   Examples. Another way of stating the requirement is that filter
      performance should not be the limiting factor in device
      throughput.  If a device is capable of forwarding, say, 30Mb/sec
      without filtering, then it should be able to forward the same
      amount with filtering in place. This requirement most likely
      implies a hardware-based solution (ASIC).

   Warnings. Without hardware based filtering, it may be possible for
      the implementation of filters to degrade the performance of the
      device or to cause it to cease functioning.


2.7.5 Ability to Filter Updates

   Requirement. The device MUST provide a means to filter updates for
      all protocols that could be used to update operational
      characteristics of the device. Note that it MUST be possible to
      specify a filter that disables all updates.

      This requirement MAY be satisfied through the use of filters as
      described in Section 2.7.1 and/or with mechanisms specific to each
      protocol.  Also note that update filtering is required in addition
      to secure channels (Section 2.1.1) and authentication (Section
      2.12)

   Justification. Without the ability to filter protocols used for
      management and operational updates, unauthorized users might be
      able to change operational parameters (e.g., routing tables,
      passwords, etc.) and/or completely disable the device.

   Examples. This should include the ability to:

      *  Filter routing protocol updates

      *  Disable SNMP writing completely

      *  Filter addresses permitted to manage the device regardless of
         protocol (SNMP,SSH,TELNET,HTTP,TFTP,SNMP...)

   Warnings. None.






Jones, Editor            Expires April 24, 2004                [Page 23]

Internet-Draft     Operational Security Requirements        October 2003


2.7.6 Ability to Specify Filter Actions

   Requirement. The device MUST provide a mechanism to allow the
      specification of the action to be taken when a filter rule
      matches.   Actions must include "permit" (allow the traffic),
      "reject" (drop with appropriate notification to sender), and
      "drop" (drop with no notification to sender). Also see Section
      2.7.7 and Section 2.9

   Justification. This capability is essential to the use of filters to
      enforce policy.

   Examples. Assume that you have a small DMZ network connected to the
      Internet. You want to allow management using SSH coming from your
      corporate office.  In this case, you might "permit" all traffic to
      port 22 in the DMZ from your corporate network, "rejecting" all
      others. Port 22 traffic from the corporate network is allowed
      through. Port 22 traffic from all other addresses results in an
      ICMP message to the sender.  For those who are slightly more
      paranoid, you might choose to "drop" instead of "reject" traffic
      from unauthorized addresses, with the result being that *nothing*
      is sent back to the source.

   Warnings. [Ed. Does "drop" with no ICMP unreachable violate any RFCs
      ?]


2.7.7 Ability to Log Filter Actions

   Requirement.

      It MUST be possible to log all filter actions. The logging
      capability MUST be able to capture at least the following data:
      permit/deny/drop status, source and destination ports, source and
      destination IP address, which network element forwarded the packet
      (interface, MAC address or other layer 2 information that
      identifies the previous hop source of the packet), and time-stamp
      to millisecond accuracy.

      Logging of filter actions is subject to the requirements of
      Section 2.11.

   Justification. Logging is essential for auditing, incident response,
      and operations.

   Examples. A desktop network may not provide any services that should
      be accessible from "outside."  In such cases, all inbound
      connection attempts should be logged as possible intrusion



Jones, Editor            Expires April 24, 2004                [Page 24]

Internet-Draft     Operational Security Requirements        October 2003


      attempts.

   Warnings. None.


2.8 Packet Filtering Criteria

2.8.1 Ability to Filter on Protocols

   Requirement. The device MUST provide a means to filter traffic based
      on protocol.

   Justification. Being able to filter on protocol is necessary to allow
      implementation of policy, secure operations and for support of
      incident response.

   Examples. Some denial of service attacks are based on the ability to
      flood the victim with ICMP traffic.  One quick way (admittedly
      with some negative side effects) to mitigate the effects of such
      attacks is to drop all ICMP traffic headed toward the victim.

   Warnings. None.


2.8.2 Ability to Filter on Addresses

   Requirement. The function MUST be able to control the flow of traffic
      based on source and/or destination IP address or blocks of
      addresses such as Classless Inter-Domain Routing (CIDR) blocks.

   Justification. The capability to filter on addresses and address
      blocks is a fundamental tool for establishing boundaries between
      different networks.

   Examples. One example of the use of address based filtering is to
      implement ingress filtering per [RFC2827].

   Warnings. None.


2.8.3 Ability to Filter on Any Protocol Header Fields

   Requirement. The filtering mechanism MUST support filtering based on
      the value(s) of any portion of the protocol headers.

   Justification. Being able to filter on portions of the header is
      necessary to allow implementation of policy, secure operations,
      and support incident response.



Jones, Editor            Expires April 24, 2004                [Page 25]

Internet-Draft     Operational Security Requirements        October 2003


   Examples. For example, this requirement implies that it is possible
      to filter based on TCP or UDP port numbers, TCP flags such as SYN,
      ACK and RST bits, and ICMP type and code fields. One common
      example is to reject "inbound" TCP connection attempts (TCP, SYN
      bit set).   Another common example is the ability to control what
      services are allowed in/out of a network.  For example, it may be
      desirable to only allow inbound connections on port 80 (HTTP) and
      443 (HTTPS) to a network hosting web servers.

   Warnings. None.


2.8.4 Ability to Filter Inbound and Outbound

   Requirement. It MUST be possible to filter both incoming and outgoing
      traffic on any interface.

   Justification. This requirement allows flexibility in applying
      filters at the place that makes the most sense.  It allows invalid
      or malicious traffic to be dropped as close to the source as
      possible.

   Examples. It might be desirable on a border router, for example, to
      apply an egress filter outbound on the interface that connects a
      site to its external ISP to drop outbound traffic that does not
      have a valid internal source address.  Inbound, it might be
      desirable to apply a filter that blocks all traffic from a site
      that is known to forward or originate lots of junk mail.

   Warnings. None.


2.9 Packet Filtering Counter Requirements

2.9.1 Ability to Accurately Count Filter Hits

   Requirement. The device MUST supply a facility for accurately
      counting all filter hits.

   Justification. Accurate counting of filter rule matches is important
      because it shows the magnitude/frequency of attempts to violate
      policy. This enables resources to be focused on areas of greatest
      need.

   Examples. Assume, for example, that a ISP network implements
      anti-spoofing egress filters (see [RFC2827]) on interfaces of its
      edge routers that support single-homed stub networks.  Counters
      could enable the ISP to detect cases where large numbers of



Jones, Editor            Expires April 24, 2004                [Page 26]

Internet-Draft     Operational Security Requirements        October 2003


      spoofed packets are being sent.  This may indicate that the
      customer is performing potentially malicious actions (possibly in
      violation of the IPS's Acceptable Use Policy), or that system(s)
      on the customers network have been "owned" by hackers and are
      being (mis)used to launch attacks.

   Warnings. None.


2.9.2 Ability to Display Filter Counters

   Requirement. The device MUST provide a mechanism to display filter
      counters.

   Justification. Information that is collected is not useful unless it
      can be displayed in a useful manner.

   Examples. Assume there is a router with four interfaces.   One is an
      up-link to an ISP providing routes to the Internet.  The other
      three connect to separate internal networks.  Assume that a host
      on one of the internal networks has been compromised by a hacker
      and is sending traffic with bogus source addresses.  In such a
      situation, it might be desirable to apply ingress filters to each
      of the internal interfaces. Once the filters are in place, the
      counters can be examined to determine the source (inbound
      interface) of the bogus packets.

   Warnings. None.


2.9.3 Ability to Display Filter Counters per Rule

   Requirement. The device MUST provide a mechanism to display filter
      counters per rule.

   Justification. This makes it possible to see which rules are matching
      and how frequently.

   Examples. Assume that a filter has been defined that has two rules,
      one permitting all SSH traffic (tcp/22) and the second dropping
      all remaining traffic.  If three packets are directed toward/
      through the point at which the filter is applied, one to port 22,
      the others to different ports, then the counter display should
      show 1 packet matching the permit tcp/22 rule and 2 packets
      matching the deny all others rule.






Jones, Editor            Expires April 24, 2004                [Page 27]

Internet-Draft     Operational Security Requirements        October 2003


   Warnings. None.


2.9.4 Ability to Display Filter Counters per Filter Application

   Requirement. If it is possible for a filter to be applied more than
      once at the same time, then the device MUST provide a mechanism to
      display filter counters per filter application.

   Justification. It may make sense to apply the same filter definition
      simultaneously more than one time (to different interfaces, etc.).
      If so, it would be much more useful to know which instance of a
      filter is matching than to know that some instance was matching
      somewhere.

   Examples. One way to implement this requirement would be to have the
      counter display mechanism show the interface (or other entity) to
      which the filter has been applied, along with the name (or other
      designator) for the filter.  For example if a filter named
      "desktop_outbound" applied two different interfaces, say,
      "ethernet0" and "ethernet1," the display should indicate something
      like "matches of filter 'desktop_outbound' on ethernet0 ..." and
      "matches of filter 'desktop_outbound' on ethernet1 ..."

   Warnings. None.


2.9.5 Ability to Reset Filter Counters

   Requirement. It MUST be possible to reset counters to zero on a per
      filter basis.

   Justification. This allows operators to get a current picture of the
      traffic matching particular rules/filters.

   Examples. Assume that filter counters are being used to detect
      internal hosts that are infected with a new worm.  Once it is
      believed that all infected hosts have been cleaned up and the worm
      removed, the next step would be to verify that.  One way of doing
      so would be to reset the filter counters to zero and see if
      traffic indicative of the worm has ceased.

   Warnings. None.


2.9.6 Filter Counters Must Be Accurate





Jones, Editor            Expires April 24, 2004                [Page 28]

Internet-Draft     Operational Security Requirements        October 2003


   Requirement. Filter counters MUST be accurate.   They MUST reflect
      the actual number of matching packets since the last counter
      reset.

   Justification. Inaccurate data can not be relied on as the basis for
      action. Underreported data can conceal the magnitude of a problem.

   Examples. If N packets matching a filter are sent to/through a
      device, then the counter should show N matches.

   Warnings. None.


2.10 Other Packet Filtering Requirements

2.10.1 Filter, Counters, and Filter Log Must Have Minimal Performance
       Impact

   Requirement. Filtering, logging, and counting functionality MUST be
      implemented such that they have minimal impact on performance.

   Justification. The possibility of severe performance degradation in
      the use of filtering, logging, or counting would reduce their
      utility. Fear of adverse operational consequences might cause
      operators to limit or discard their use completely in situations
      where they are needed.

   Examples.

      Assume, for example, that a new worm is released that scans random
      IP addresses looking for services listening on TCP port 1433.  An
      operator might want to investigate to see if any of the hosts on
      their networks were infected and trying to spread the worm.  One
      way to do this would be to put up non-blocking filters counting
      and logging the number of outbound connection 1433, and then to
      block the requests that are determined to be from infected hosts.
      If any of these capabilities (filtering, counting, logging) have
      the potential to impose severe performance penalties, then this
      otherwise rational course of action might not be possible.

      Some examples of things that would make the logging features
      unusable might include situations where their use:

      *  crashes the device

      *  consumes excessive resources (CPU, memory, bandwidth)

      *  makes the device unmanageable



Jones, Editor            Expires April 24, 2004                [Page 29]

Internet-Draft     Operational Security Requirements        October 2003


      *  causes the loss of data

   Warnings.

      While there are some objective measures that indicate clearly when
      a feature is unusable (its use crashes the device), "usability" is
      largely a subjective term.  Lab tests may be constructed to
      determine how well the device behaves under certain loads, but the
      ultimate test of usability for filtering, counting and logging
      will come under live, quite possibly heavy, loads.


2.10.2 Ability to Specify Filter Log Granularity

   Requirement. It MUST be possible to enable/disable logging on a per
      rule basis.

   Justification. The ability to tune the granularity of logging allows
      the operator to log only the information that is desired. Without
      this capability, it is possible that extra data (or none at all)
      wold be logged, making it more difficult to find relevant
      information.

   Examples. If a filter is defined that has several rules, and one of
      the rules denies telnet (tcp/23) connections, then it should be
      possible to specify that only matches on the rule that denies
      telnet should generate a log message.

   Warnings. None.


2.11 Event Logging Requirements

2.11.1 Logging Facility Conforms to Open Standards

   Requirement. The device MUST provide a logging facility that conforms
      to open standards. Custom/Proprietary log protocols MAY be
      implemented provided the same information is made available via
      logging facilities that conform to open standards.

   Justification. The use of open standards logging is important because
      it permits the customer to perform archival and analysis of logs
      without relying on vendor-supplied software and servers.

   Examples. [RFC3195] meets this requirement. The use of SNMP traps may
      also satisfy this requirement.





Jones, Editor            Expires April 24, 2004                [Page 30]

Internet-Draft     Operational Security Requirements        October 2003


   Warnings. While [RFC3164] and SNMP may satisfy this requirement, they
      both fail to satisfy several other logging requirements.


2.11.2 Ability to Log to Remote Server

   Requirement. The device MUST be capable of logging to a remote
      server. It SHOULD be able to log to multiple servers.

   Justification. External logging allows the storage of large,
      persistent logs that may not be possible with local (on the
      device) logging.

   Examples. One example of a remote log server would be a host running
      a syslog server.  See [RFC3164].

   Warnings. High volumes of logging may generate excessive network
      traffic and/or compete for scarce memory and CPU resources on the
      device.


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.


2.11.4 Ability to Maintain Accurate System Time





Jones, Editor            Expires April 24, 2004                [Page 31]

Internet-Draft     Operational Security Requirements        October 2003


   Requirement. The device MUST maintain accurate, high resolution
      system time. All displays of system time MUST include a timezone.
      The default timezone SHOULD be UTC or GMT. The device SHOULD
      support a mechanism to allow the operator to specify the timezone
      for local system time.

   Justification. This is important because the system clock is used for
      time-stamping log messages.

   Examples. This requirement may be satisfied by supporting Network
      Time Protocol (NTP), Simple Network Time Protocol (SNTP), or via
      direct connection to an accurate time source. See Section 2.1.1
      for requirements related to secure communication channels for
      management protocols and data.

   Warnings. System clock chips are inaccurate to varying degrees.
      System time should not be relied upon unless it is regularly
      checked and synchronized with a known, accurate external time
      source (such as an NTP stratum-1 server). Also note that if
      network time synchronization is used, an attacker may be able to
      manipulate the clock unless cryptographic authentication is used.


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

   Justification. This is important because accurate timestamps are
      necessary for correlating events, particularly across multiple
      devices or with other organizations. This applies when it is
      necessary to analyze logs.

   Examples. This requirement MAY be satisfied by writing timestamps
      into syslog messages.

   Warnings. It is difficult to correlate logs from different time
      zones. Security events on the Internet often involve machines and
      logs from a variety of physical locations.  For that reason, UTC
      is preferred, all other things being equal.


2.11.6 Logs Contain Untranslated Addresses

   Requirement. Log messages MUST contain relevant IP addresses.





Jones, Editor            Expires April 24, 2004                [Page 32]

Internet-Draft     Operational Security Requirements        October 2003


   Justification. It is important to include IP address of access list
      violation logs, authentication attempts.  This enables a level of
      individual and organizational accountability and is necessary to
      enable analysis of network events, incidents, policy violations,
      etc.

   Examples. None.

   Warnings.

      *  Source addresses may be spoofed.  Network-based attacks often
         use spoofed source addresses.  Source addresses should not be
         completely trusted unless verified by means.

      *  Addresses may be reassigned to different individual, for
         example, in a desktop environment using DHCP. In such cases the
         individual accountability afforded by this requirement is weak.

      *  Network topologies may change. Even in the absence of dynamic
         address assignment, network topologies and address block
         assignments do change. Logs of an attack one month ago may not
         give an accurate indication of which host, network or
         organization owned the system(s) in question at the time.


2.12 Authentication, Authorization, and Accounting (AAA) Requirements

2.12.1 Authenticate All User Access

   Requirement. The device MUST provide a facility to perform
      authentication of all user access to the system.

   Justification. This functionality is required so that access to the
      system can be restricted to authorized personnel.

   Examples. This requirement MAY be satisfied by implementing a
      centralized authentication system.  See Section 2.12.5. It MAY
      also be satisfied using local authentication. See Section 2.12.6

   Warnings. None.


2.12.2 Support Authentication of Individual Users

   Requirement. Each authentication mechanism supported by the device
      MUST support the authentication of distinct, individual users.





Jones, Editor            Expires April 24, 2004                [Page 33]

Internet-Draft     Operational Security Requirements        October 2003


   Justification. The use of individual accounts, in conjunction with
      logging, promotes accountability.   The use of group or default
      accounts undermines individual accountability.

   Examples. The implementation depends on the types of authentication
      supported by the device.  Local usernames and passwords are one
      possibility. Centralized authentication servers using usernames
      and onetime passwords is another.

   Warnings. This simply requires that the mechanism to support
      individual users be present.  Policy (e.g., forbidding shared
      group accounts) and enforcement are also needed but beyond the
      scope of this document.


2.12.3 Support Simultaneous Connections

   Requirement. The device SHOULD support multiple simultaneous
      connections by distinct users, possibly at different authorization
      levels.

   Justification. This allows multiple people to perform authorized
      management functions simultaneously.

   Examples. None.

   Warnings. None.


2.12.4 Ability to Disable All Local Accounts

   Requirement. The device MUST provide a means of disabling all local
      accounts including:

      *  Local users

      *  Default accounts (vendor, maintenance, guest...)

      *  Privileged and unprivileged accounts

   Justification. Default accounts, well-know accounts, and old accounts
      provide easy targets for someone attempting to gain access to a
      device. It must be possible to disable them to reduce the
      potential vulnerability.

   Examples. The implementation depends on the types of authentication
      supported by the device.




Jones, Editor            Expires April 24, 2004                [Page 34]

Internet-Draft     Operational Security Requirements        October 2003


   Warnings. None.


2.12.5 Support Centralized User Authentication Methods

   Requirement. The device MUST support a method of centralized
      authentication of all user access via standard authentication
      protocols.

   Justification. Support for centralized authentication is particularly
      important in large environments where the network devices are
      widely distributed and where many people have access to them. This
      reduces the effort needed to effectively restrict and track access
      to the system by authorized personnel.

   Examples. Terminal Access This requirement can be satisfied through
      the use of Terminal Controller Access Control System Plus
      (TACACS+), Remote Authentication Dial-In User Service (RADIUS), or
      Kerberos. See Section 2.1.1 for requirements related to secure
      communication channels for management protocols and data.

   Warnings. None.


2.12.6 Support Local User Authentication Method

   Requirement. The device SHOULD support a local authentication method.
      If implemented, the method MUST NOT require interaction with
      anything external to the device (such as remote AAA servers),  and
      MUST work in conjunction with Section 2.3.1 (Support a Non-IP
      'Console' interface) and Section 2.12.7 (Support Configuration of
      Order of Authentication Methods).

   Justification. Support for local authentication may be required in
      smaller environments where there may be only a few devices and a
      limited number of people with access.  The overhead of maintaining
      centralized authentication servers may not be justified.

   Examples. The use of local, per-device usernames and passwords
      provides one way to implement this requirement.

   Warnings. Authentication information must be protected wherever it
      resides.  Having, for instance, local usernames and passwords
      stored on 100 network devices means that there are 100 potential
      points of failure where the information could be compromised vs.
      storing authentication data centralized server(s), which would
      reduce the potential points of failure to the number of servers
      and allow protection efforts (system hardening, audits, etc.) to



Jones, Editor            Expires April 24, 2004                [Page 35]

Internet-Draft     Operational Security Requirements        October 2003


      be focused on, at most, a few servers.


2.12.7 Support Configuration of Order of Authentication Methods

   Requirement. The device MUST support the ability to configure the
      order in which supported authentication methods are attempted.
      Authentication SHOULD "fail closed", i.e. access should be denied
      if none of the listed authentication methods succeeds.

   Justification. This allows the operator flexibility in implementing
      appropriate security policies that balance operational and
      security needs.

   Examples. If, for example, a device supports RADIUS authentication
      and local usernames and passwords, it should be possible to
      specify that RADIUS authentication should be attempted if the
      servers are available, and that local usernames and passwords
      should be used for authentication only if the RADIUS servers are
      not available. Similarly, it should be possible to specify that
      only RADIUS or only local authentication be used.

   Warnings. None.


2.12.8 No Unencrypted Transmission of Reusable Plain-text Passwords

   Requirement. The device MUST perform authentication without the
      unencrypted transmission of reusable plain-text passwords across a
      network. The implementation:

      *  MUST NOT cause significant performance degradation

      *  MUST NOT require additional devices (e.g., encryption cards,
         etc.)

      *  MUST scale well/be supportable on large numbers of devices
         (e.g., the number of keys and configuration settings that need
         to be managed should increase at most linearly as the number of
         devices).

      This requirement MAY be satisfied by tunneling protocols that use
      plain-text passwords over secure channels per Section 2.1.1.

   Justification. Reusable plain-text passwords can easily be observed
      using packet sniffers on shared networks. Mechanisms that impose
      too high of an overhead or are not manageable will not be used.
      This requirement specifically precludes the use of reusable



Jones, Editor            Expires April 24, 2004                [Page 36]

Internet-Draft     Operational Security Requirements        October 2003


      passwords with standard telnet without being carried over a secure
      channel (see Section 2.1.1) for device management.  It does allow
      the use of standard telnet with one time passwords. Note that this
      does not preclude the use of extra hardware; it simply says that
      additional hardware (smart cards, encryption cards, etc.) must not
      be required to support authentication without the use of clear
      text passwords. See [RFC1704] for a through discussion of the
      issues.

   Examples. None.

   Warnings. None.


2.12.9 No Default Passwords

   Requirement. The initial configuration of the device MUST NOT contain
      any default passwords or similar static authentication tokens.
      "Similar static authentication tokens" includes any form of shared
      secret, public or private key.

   Justification. Default passwords provide an easy way for attackers to
      gain unauthorized access to the device.

   Examples. Passwords such as the name of the vendor, device, "default"
      etc. are easily guessed.  The SNMP community strings "public" and
      "private" are well known defaults that provide read and write
      access to devices.

   Warnings. Lists of default passwords for various devices are readily
      available at numerous websites.


2.12.10 Passwords Must Be Explicitly Configured Prior To Use

   Requirement. The device MUST require the operator to explicitly
      configure passwords and similar static authentication tokens prior
      to use. "Similar authentication tokens" includes any form of
      shared secret, public or private key.

   Justification. This requirement is intended to prevent unauthorized
      management access. Requiring the operator to explicitly configure
      passwords will tend to have the effect of ensuring a diversity of
      passwords.  It also shifts the responsibility for password
      selection to the user.






Jones, Editor            Expires April 24, 2004                [Page 37]

Internet-Draft     Operational Security Requirements        October 2003


   Examples. Assume that a device comes with console port for management
      and a default administrative account.  This requirement together
      with No Default Passwords says that the administrative account
      should come with no password configured.  One way of meeting this
      requirement would be to have the device require the operator to
      choose a password for the administrative account as part of a
      dialog the first time the device is configured.

   Warnings. While this device requires operators to set passwords, it
      does not prevent them from doing things such as using scripts to
      configure 100s of devices with the same easily guessed passwords.


2.12.11 Ability to Define Privilege Levels

   Requirement. It MUST be possible to define arbitrary subsets of all
      management and configuration functions and assign them to groups
      or "privilege levels," which can be assigned to users per Section
      2.12.12

   Justification. This requirement supports the implementation of the
      principal of "least privilege", which states that an individual
      should only have the privileges necessary to execute the
      operations he/she is required to perform.

   Examples. Examples of privilege levels might include "default," which
      allows read-only access to device configuration and operational
      statistics, "root/superuser/administrator" which allows update
      access to all configurable parameters, and "operator" which allows
      updates to a limited, user defined set of parameters. Note that
      privilege levels may be defined locally on the device or on
      centralized authentication servers.

   Warnings. None.


2.12.12 Ability to Assign Privilege Levels to Users

   Requirement. The device MUST be able to assign a defined set of
      authorized functions, or "privilege level," to each user once they
      have authenticated themselves the device.  Privilege level
      determines which functions a user is allowed to execute.   Also
      see See Section 2.12.11.

   Justification. This requirement supports the implementation of the
      principal of "least privilege," which states that an individual
      should only have the privileges necessary to execute the
      operations he/she is required to perform.



Jones, Editor            Expires April 24, 2004                [Page 38]

Internet-Draft     Operational Security Requirements        October 2003


   Examples. The implementation of this requirement will obviously be
      closely coupled with the authentication mechanism.  So for
      example, if RADIUS is used, an attribute could be set in the
      user's RADIUS profile that can be used to map the ID to a certain
      privilege level.

   Warnings. None.


2.12.13 Default Privilege Level Must Be Read Only

   Requirement. The default privilege level MUST only allow read access
      to device settings and operational parameters.

   Justification. This requirement supports the implementation of the
      principal of "least privilege," which states that an individual
      should only have the privileges necessary to execute the
      operations he/she is required to perform.

   Examples. None.

   Warnings. None.


2.12.14 Change in Privilege Levels Requires Re-Authentication

   Requirement. The device MUST re-authenticate a user prior to granting
      any change in user authorizations.

   Justification. This requirement insures that users are able to
      perform only authorized actions.

   Examples. This requirement might be implemented by assigning base
      privilege levels to all users and allowing the user to request
      additional privileges, with the requests validated by the AAA
      server.

   Warnings. None.


2.12.15 Support Recovery Of Privileged Access

   Requirement. The device MUST support a mechanism to allow authorized
      individuals to recover full privileged administrative access in
      the event that access is lost. Use of the mechanism MUST require
      physical access to the device. There MAY be a mechanism for
      disabling the recovery feature.




Jones, Editor            Expires April 24, 2004                [Page 39]

Internet-Draft     Operational Security Requirements        October 2003


   Justification. There are times when local administrative passwords
      are forgotten, when the only person who knows them leaves the
      company, or when hackers set or change the password.   In all
      these cases, legitimate administrative access to the device is
      lost.  There should be a way to recover access.  Requiring
      physical access to invoke the procedure makes it less likely that
      it will be abused.  Some organizations may want an even higher
      level of security and be willing to risk total loss of authorized
      access by disabling the recovery feature, even for those with
      physical access.

   Examples. Some examples of ways to satisfy this requirement are to
      have the device give the user the chance to set a new
      administrative password when:

         The user sets a jumper on the system board to a particular
         position.

         The user sends a special sequence to the RS232 console port
         during the initial boot sequence.

         The user sets a "boot register" to a particular value.

   Warnings. This mechanism, by design,  provides a "back door" to
      complete administrative control of the device and may not be
      appropriate for environments where those with physical access to
      the device can not be trusted.


2.12.16 Accounting Records

   Requirement. The device MUST be able to store a record of at least
      the following events:

      *  Failed logins

      *  Successful logins

      *  All Commands executed by the user during their session,
         including via the management/serial port and interactions with
         an underlying OS (e.g., Unix "shell" commands)

      *  Change in privilege level

      *  All logouts






Jones, Editor            Expires April 24, 2004                [Page 40]

Internet-Draft     Operational Security Requirements        October 2003


      The device MUST support transmission of accounting records to one
      or more remote devices.  There MUST be configuration settings on
      the device that allow selection of servers.

   Justification. This is important because it supports individual
      accountability by providing a record of changes that were made and
      who made them. It is important to store them on a separate server
      to preserve them in case of failure or compromise of the managed
      device.

   Examples. This requirement MAY be satisfied by the use of
      RADIUS,TACACS+, or syslog. See Section 2.1.1 for requirements
      related to secure communication channels for management protocols
      and data.

   Warnings. Syslog is known to be unreliable/lossy during network
      transmission (due to use of UDP).  It has also been observed that
      some devices lose a significant number of UDP packets before they
      are ever transmitted, due (apparently) to low prioritization of
      the internal processing of UDP packets.  Similar problems have
      been observed in various syslog servers (syslogd on UNIX systems).
      Bottom line: be aware that syslog data may be lost at one of
      several points.


2.13 Layer 2 Devices Must Meet Higher Layer Requirements

   Requirement. If a device provides layer 2 services that are dependent
      on layer 3 or greater services, then the portions that operate at
      or above layer 3 MUST conform to the requirements listed in this
      document.

   Justification. All layer 3 devices have similar security needs and
      should be subject to similar requirements.

   Examples. For example, signaling protocols required for layer 2
      switching may exchange information with other devices using layer
      3 communications. In such cases, the device must provide a secure
      layer 3 facility.  Also, if higher layer capabilities (say, SSH or
      SNMP) are used to manage a layer 2 device, then the rest of the
      requirements in this document apply to those capabilities.

   Warnings. None.








Jones, Editor            Expires April 24, 2004                [Page 41]

Internet-Draft     Operational Security Requirements        October 2003


3. Documentation Requirements

   The requirements in this section are intended to list information
   that will assist operators in evaluating and securely operating a
   device.

3.1 Document Listening Services

   Requirement. The vendor MUST:

      *  Provide a documented explanation for all network services that
         may be active on the system.

      *  Concisely document which features enable listening ports on the
         device.

      *  List which services are on by default.

      This information MUST be provided in a single, contiguous section
      of the documentation.  This list MUST include both open standard
      and vendor proprietary services.

   Justification. This information is necessary to enable a thorough
      assessment of the security risks associated with the operation of
      the device (e.g., "does this protocol allow complete management of
      the device without also requiring authentication, authorization,
      or accounting"?).  The information also assists in determining
      what steps should be taken to mitigate risk (e.g., "should I turn
      this service off "?)

   Examples. This documentation should include at least a list of all
      possible network services that could be activated to listen on any
      TCP and/or UDP port, or any vendor-proprietary port/protocol.

   Warnings. None.
















Jones, Editor            Expires April 24, 2004                [Page 42]

Internet-Draft     Operational Security Requirements        October 2003


4. Assurance Requirements

   The requirements in this section are intended to

   o  identify behaviors and information that will increase confidence
      that the device will meet the security functional requirements.

   o  Provide information that will assist evaluation


4.1 Comply With Relevant IETF RFCs on All Protocols Implemented

   Requirement. The default configuration of the device MUST fully
      comply with IETF RFCs for all protocols implemented.  "Compliance"
      is defined in terms of [RFC2119].   The device MUST conform to the
      absolute requirements.  Any optional or recommended functionality
      implemented MUST be in conformance with the RFC.  The device MAY
      provide means by which it can be configured in ways that are not
      compliant with the RFCs (for instance, if conformance is
      determined to be insecure).

   Justification. A device must first perform its primary function
      correctly.  Once it is proven to perform its primary function, it
      makes sense to ask if it does/can perform securely.  For Internet
      connected devices, compliance with RFCs provides a minimum level
      of assurance that the device will function as intended and
      inter-operate as part of an operational network.  Failure to
      comply with RFCs calls correct functioning into question and makes
      the determination of secure functioning a secondary concern.

   Examples. Some of the relevant RFCs include:

      ICMP.

         [RFC0792] INTERNET CONTROL MESSAGE PROTOCOL

         [RFC1812] Requirements for IP Version 4 Routers

      IP.

         [RFC0791] INTERNET PROTOCOL

         [RFC0922] BROADCASTING INTERNET DATAGRAMS IN THE PRESENCE OF
         SUBNETS

         [RFC1812] Requirements for IP Version 4 Routers





Jones, Editor            Expires April 24, 2004                [Page 43]

Internet-Draft     Operational Security Requirements        October 2003


         [RFC1858] Security Considerations for IP Fragment Filtering

         [RFC2644] Changing the Default for Directed Broadcasts in
         Routers

         [RFC2827] Network Ingress Filtering

      TCP.

         [RFC0793] TRANSMISSION CONTROL PROTOCOL

         [RFC1858] Security Considerations for IP Fragment Filtering

         [RFC1948] Defending Against Sequence Number Attacks

      UDP.

         [RFC0768] User Datagram Protocol

         [RFC1122] Requirements for Internet Hosts -- Communication
         Layers

         [RFC1812] Requirements for IP Version 4 Routers

   Warnings. None.


4.2 Identify Origin of IP Stack

   Requirement. The vendor MUST disclose the origin or basis of the IP
      stack used on the system.

   Justification. This information is required to better understand the
      possible security vulnerabilities that may be inherent in the IP
      stack.

   Examples. For example, "The IP stack was derived from BSD 4.4," or
      "The IP stack was implemented from scratch."

   Warnings. Many IP stacks make simplifying assumptions about how an IP
      packet should be formed. A malformed packet can cause unexpected
      behavior in the device, such as a system crash or buffer overflow
      which could result in  unauthorized access to the system.


4.3 Identify Origin of Operating System





Jones, Editor            Expires April 24, 2004                [Page 44]

Internet-Draft     Operational Security Requirements        October 2003


   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. For example, "The operating system is based on Linux kernel
      2.4.18."

   Warnings. None.








































Jones, Editor            Expires April 24, 2004                [Page 45]

Internet-Draft     Operational Security Requirements        October 2003


5. Security Considerations

   Security is the subject matter of this entire memo. It might be more
   appropriate to list operational considerations. Operational issues
   are mentioned as needed in the examples and warnings sections of each
   requirement.













































Jones, Editor            Expires April 24, 2004                [Page 46]

Internet-Draft     Operational Security Requirements        October 2003


References

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
              1981.

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, September 1981.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
              793, September 1981.

   [RFC0922]  Mogul, J., "Broadcasting Internet datagrams in the
              presence of subnets", STD 5, RFC 922, October 1984.

   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122, October 1989.

   [RFC1704]  Haller, N. and R. Atkinson, "On Internet Authentication",
              RFC 1704, October 1994.

   [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers", RFC
              1812, June 1995.

   [RFC1858]  Ziemba, G., Reed, D. and P. Traina, "Security
              Considerations for IP Fragment Filtering", RFC 1858,
              October 1995.

   [RFC1948]  Bellovin, S., "Defending Against Sequence Number Attacks",
              RFC 1948, May 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2644]  Senie, D., "Changing the Default for Directed Broadcasts
              in Routers", BCP 34, RFC 2644, August 1999.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, May 2000.

   [RFC2867]  Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
              Modifications for Tunnel Protocol Support", RFC 2867, June
              2000.

   [RFC3164]  Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August



Jones, Editor            Expires April 24, 2004                [Page 47]

Internet-Draft     Operational Security Requirements        October 2003


              2001.

   [RFC3195]  New, D. and M. Rose, "Reliable Delivery for syslog", RFC
              3195, November 2001.

   [netconf]  IETF, "Network Configuration Working Group", 2003, <http:/
              /www.ietf.org/html.charters/netconf-charter.html>.


Author's Address

   George M. Jones, Editor
   The MITRE Corporation
   7525 Colshire Dr., WEST
   McLean, VA  22102
   U.S.A.

   Phone: +1 703 488 9740
   EMail: gmjones@mitre.org
   URI:   http://www.port111.com/opsec/































Jones, Editor            Expires April 24, 2004                [Page 48]

Internet-Draft     Operational Security Requirements        October 2003


Appendix A. Requirement Profiles

   This Appendix lists different profiles.  A profile is a list of list
   of requirements that apply to a particular class of devices.  The
   minimum requirements profile applies to all devices.

A.1 Minimum Requirements Profile

   The functionality listed here represents a bare minimum set of
   requirements which any managed networking infrastructure device
   should adhere to.  This includes all core and edge devices which are
   part of an IP network (such as routers, and switches).  Note that
   SOHO equipment (typically DSL modem/routers, cable modem/routers,
   etc) and wireless networking infrastructure equipment have their own
   set of requirements and are not expected to adhere to this particular
   set of minimal requirements.

   The minimal requirements profile addresses functionality which will
   provide reasonable capabilities to manage the devices in the event of
   attacks, simplify troubleshooting, keep track of events which affect
   system integrity, help analyze causes of attacks, as well as provide
   administrators  control over IP addresses and protocols to help
   mitigate the most common attacks and exploits.

A.1.1 Functional Requirements

A.1.1.1 Device Management Requirements

   o  Support Secure Management Channels


A.1.1.2 In-Band Management Requirements

   The following requirements apply only if In-Band management is used
   to satisfy Section 2.1.1 (Support Secure Management Channels)

   o  Use Encryption Algorithms Subject To Open Review

   o  Use Strong Encryption


A.1.1.3 Out-of-Band (OoB) Management Requirements

   The following requirements apply only if Out-of-Band  management is
   used to satisfy Section 2.1.1 (Support Secure Management Channels)

   o  Support a Non-IP 'Console' interface




Jones, Editor            Expires April 24, 2004                [Page 49]

Internet-Draft     Operational Security Requirements        October 2003


   o  Support A Simple Default Communication Profile On The 'Console'

   o  Support Separate Management Plane IP Interfaces

   o  No Forwarding Between Management Plane And Other Interfaces

   o  Provide Separate Resources For The Management Plane


A.1.1.4 Configuration Requirements

   CLI Provides Access to All Configuration and Management Functions

   CLI Uses Existing Authentication Mechanisms

   CLI Supports Scripting of Configuration

   CLI Supports Management Over 'Slow' Links

   Support Software Installation

   Support Remote Configuration Backup

   Support Remote Configuration Restore

   Support Human-Readable Configuration File

A.1.1.5 IP Stack Requirements

   o  Comply With Relevant IETF RFCs on All Protocols Implemented

   o  Ability to Identify All Listening Services

   o  Ability to Disable Any and All Services

   o  Listening Services Should Be Off By Default

   o  Ability to Control Service Bindings for Listening Services

   o  Ability to Control Service Source Address

   o  Support Automatic Anti-spoofing for Single-Homed Networks

   o  Directed Broadcasts Disabled by Default







Jones, Editor            Expires April 24, 2004                [Page 50]

Internet-Draft     Operational Security Requirements        October 2003


A.1.1.6 Basic Filtering Capabilities

   o  Ability to Filter Traffic

   o  Ability to Filter Traffic TO the Device

   o  Ability to Filter Updates

   o  Ability to Specify Filter Actions

   o  Ability to Log Filter Actions


A.1.1.7 Packet Filtering Criteria

   o  Ability to Filter on Protocols

   o  Ability to Filter on Addresses

   o  Ability to Filter on Any Protocol Header Fields

   o  Ability to Filter Inbound and Outbound


A.1.1.8 Packet Filtering Counter Requirements

   o  Packet Filtering Counter Requirements

   o  Ability to Display Filter Counters

   o  Ability to Display Filter Counters per Rule

   o  Ability to Display Filter Counters per Filter Application

   o  Ability to Reset Filter Counters

   o  Filter Counters Must Be Accurate


A.1.1.9 Other Packet Filtering Requirements

   o  Filter, Counters, and Filter Log Must Have Minimal Performance
      Impact


A.1.1.10 Event Logging Requirements

   o  Logging Facility Conforms to Open Standards



Jones, Editor            Expires April 24, 2004                [Page 51]

Internet-Draft     Operational Security Requirements        October 2003


   o  Ability to Log to Remote Server

   o  Ability to Log Locally

   o  Ability to Maintain Accurate System Time

   o  Logs Must Be Timestamped

   o  Logs Contain Untranslated Addresses


A.1.1.11 Authentication, Authorization, and Accounting (AAA)
         Requirements

   o  Authenticate All User Access

   o  Support Authentication of Individual Users

   o  Support Simultaneous Connections

   o  Ability to Disable All Local Accounts

   o  Support Centralized User Authentication Methods

   o  Support Local User Authentication Method

   o  Support Configuration of Order of Authentication Methods

   o  No Unencrypted Transmission of Reusable Plain-text Passwords

   o  Ability to Define Privilege Levels

   o  Ability to Assign Privilege Levels to Users

   o  Default Privilege Level Must Be Read Only

   o  Change in Privilege Levels Requires Re-Authentication

   o  Support Recovery Of Privileged Access

   o  Accounting Records


A.1.2 Documentation Requirements

   o  Document Listening Services

   o  Identify Origin of IP Stack



Jones, Editor            Expires April 24, 2004                [Page 52]

Internet-Draft     Operational Security Requirements        October 2003


   o  Identify Origin of Operating System


A.1.3 Assurance Requirements

   o  Comply With Relevant IETF RFCs on All Protocols Implemented

   o  Identify Origin of IP Stack

   o  Identify Origin of Operating System


A.2 Layer 3 Network Core Profile

   This section builds on the minimal requirements listed in A.1 and
   adds more stringent security functionality specific to layer 3
   devices which are part of the network core.  The network core devices
   need to be as free as possible from features which affect high-speed
   packet forwarding.

   A core device is defined as a device that makes up the network
   infrastructure but does not connect directly to customers or peers.
   This would include backbone core routers.

A.2.1 Functional Requirements

A.2.1.1 IP Stack Requirements


A.3 Layer 3 Network Edge Profile

   This section builds on the minimal requirements listed in A.1 and
   adds more stringent security functionality specific to layer 3
   devices which are part of the network edge.  The network edge is
   typically where much of the filtering and traffic control policies
   are implemented.

   An edge device is defined as a device that makes up the network
   infrastructure and connects directly to customers or peers. This
   would include routers connected to peering points, switches
   connecting customer hosts, etc.

A.3.1 Functional Requirements

A.3.1.1 IP Stack Requirements

   o  Support Automatic Anti-spoofing for Single-Homed Networks




Jones, Editor            Expires April 24, 2004                [Page 53]

Internet-Draft     Operational Security Requirements        October 2003


A.3.1.2 Rate Limiting Requirements

   o  Support Rate Limiting

   o  Support Rate Limiting Based on State


A.3.1.3 Basic Filtering Capabilities

   o  Ability to Filter Traffic THROUGH the Device









































Jones, Editor            Expires April 24, 2004                [Page 54]

Internet-Draft     Operational Security Requirements        October 2003


Appendix B. Acknowledgments

   This document grew out of an internal security requirements document
   used by UUNET for testing devices that were being proposed for
   connection to the backbone.

   The editor gratefully acknowledges the contributions of:

   o  Greg Sayadian, author of a predecessor of this document.

   o  Eric Brandwine, a major source of ideas/critiques.

   o  The MITRE Corporation for supporting continued development of this
      document.  NOTE: The editor's affiliation with The MITRE
      Corporation is provided for identification purposes only, and is
      not intended to convey or imply MITRE's concurrence with, or
      support for, the positions, opinions or viewpoints expressed by
      the editor.

   o  UUNET's entire network security team (past and present): Jared
      Allison, Eric Brandwine, Clarissa Cook, Dave Garn, Tae Kim, Kent
      King, Neil Kirr, Mark Krause, Michael Lamoureux, Maureen Lee, Todd
      MacDermid, Chris Morrow, Alan Pitts, Greg Sayadian, Bruce Snow,
      Robert Stone, Anne Williams, Pete White.

   o  Others who have provided significant feedback at various stages of
      the life of this document are: Ran Atkinson, Fred Baker, Steve
      Bellovin, Michael H. Behringer, Matt Bishop, Scott Blake, Randy
      Bush, Steven Christey, Owen Delong, Sean Donelan, Robert Elmore,
      Barry Greene, Dan Hollis, Merike Kaeo, John Kristoff, Chris
      Liljenstolpe, James W. Laferriere, Jared Mauch, Alan Paller, Rob
      Pickering, Gregg Schudel, Don Smith, Rodney Thayer, David Walters,
      Joel N. Weber II, Anthony Williams, Neal Ziring

   o  Madge B. Harrison, technical writing review.

   o  This listing is intended to acknowledge contributions, not to
      imply that the individual or organizations approve the content of
      this document.

   o  Apologies to those who commented on/contributed to the document
      and were not listed...contact the editor to be credited in future
      versions

   Version: $Id: draft-jones-opsec-01.cpp,v 1.4 2003/10/13 11:39:26
   george Exp $





Jones, Editor            Expires April 24, 2004                [Page 55]

Internet-Draft     Operational Security Requirements        October 2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Jones, Editor            Expires April 24, 2004                [Page 56]

Internet-Draft     Operational Security Requirements        October 2003


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Jones, Editor            Expires April 24, 2004                [Page 57]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/