¬†¬†¬†¬†¬†¬† Ci sono momenti in cui √® operativamente necessario per essere in grado di
¬†¬†¬†¬†¬†¬† immediately and easily access a device for management or
¬†¬†¬†¬†¬†¬† configuration, 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, a console interface can provide
¬†¬†¬†¬†¬†¬† a way to manage and configure the device.
Jones Informational [Page 17]
¬†
RFC 3871 Operational Security Requirements September 2004
¬†¬†¬† Examples.

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

¬†¬†¬†¬†¬†¬† As of this writing, RS232 is still strongly recommended as it
¬†¬†¬†¬†¬†¬† provides the following benefits:

¬†¬†¬†¬†¬†¬† * Simplicity. RS232 is far simpler than the alternatives. It is
¬†¬†¬†¬†¬†¬†¬†¬†¬† simply a hardware specification. By contrast an Ethernet based
¬†¬†¬†¬†¬†¬†¬†¬†¬† solution might require an ethernet interface, an operating
¬†¬†¬†¬†¬†¬†¬†¬†¬† system, an IP stack and an HTTP server all to be functioning
¬†¬†¬†¬†¬†¬†¬†¬†¬† and properly configured.

¬†¬†¬†¬†¬†¬† * Proven. RS232 has more than 30 years of use.

¬†¬†¬†¬†¬†¬† * Well-Understood. Operators have a great deal of experience
¬†¬†¬†¬†¬†¬†¬†¬†¬† with RS232.

¬†¬†¬†¬†¬†¬† * Availability. It works even in the presence of network
¬†¬†¬†¬†¬†¬†¬†¬†¬† failure.

¬†¬†¬†¬†¬†¬† * Ubiquity. It is very widely deployed in mid to high end
¬†¬†¬†¬†¬†¬†¬†¬†¬† network infrastructure.

¬†¬†¬†¬†¬†¬† * Low-Cost. The cost of adding a RS232 port to a device is
¬†¬†¬†¬†¬†¬†¬†¬†¬† small.

¬†¬†¬†¬†¬†¬† * CLI-Friendly. An RS232 interface and a CLI are sufficient in
¬†¬†¬†¬†¬†¬†¬†¬†¬† most cases to manage a device. No additional software is
¬†¬†¬†¬†¬†¬†¬†¬†¬† required.

¬†¬†¬†¬†¬†¬†¬†¬†¬† While other interfaces may be supplied, the properties listed
¬†¬†¬†¬†¬†¬†¬†¬†¬† above should be considered. Interfaces not having these
¬†¬†¬†¬†¬†¬†¬†¬†¬† properties may present challenges in terms of ease of use,
¬†¬†¬†¬†¬†¬†¬†¬†¬† integration or adoption. Problems in any of these areas could
¬†¬†¬†¬†¬†¬†¬†¬†¬† have negative security impacts, particularly in situations
¬†¬†¬†¬†¬†¬†¬†¬†¬† where the console must be used to quickly respond to incidents.

¬†¬†¬†¬†¬†¬† It is common practice is to connect RS232 ports to terminal
¬†¬†¬†¬†¬†¬† servers that permit networked access for convenience. This
¬†¬†¬†¬†¬†¬† increases the potential security exposure of mechanisms available
¬†¬†¬†¬†¬†¬† only via RS232 ports. For example, a password recovery mechanism
¬†¬†¬†¬†¬†¬† that is available only via RS232 might give a remote hacker to
¬†¬†¬†¬†¬†¬† completely reconfigure a router. While operational procedures are
¬†¬†¬†¬†¬†¬† beyond the scope of this document, it is important to note here
¬†¬†¬†¬†¬†¬† that strong attention should be given to policies, procedures,
¬†¬†¬†¬†¬†¬† access mechanisms and physical security governing access to
¬†¬†¬†¬†¬†¬† console ports.

2.3.2. 'Console' Communication Profile Must Support Reset

¬†¬†¬† Requirement.

¬†¬†¬†¬†¬†¬† There MUST be a method defined and published for returning the
¬†¬†¬†¬†¬†¬† console communication parameters to their default settings. This
¬†¬†¬†¬†¬†¬† method must not require the current settings to be known.

¬†¬†¬† Justification.

¬†¬†¬†¬†¬†¬† Having to guess at communications settings can waste time. In a
¬†¬†¬†¬†¬†¬† crisis situation, the operator may need to get on the console of a
¬†¬†¬†¬†¬†¬† device quickly.

¬†¬†¬† Examples.

¬†¬†¬†¬†¬†¬† One method might be to send a break on a serial line.

¬†¬†¬† Warnings.

¬†¬†¬†¬†¬†¬† None.

2.3.3. 'Console' Requires Minimal Functionality of Attached Devices

¬†¬†¬† Requirement.

¬†¬†¬†¬†¬†¬† The use of the 'console' interface MUST NOT require proprietary
¬†¬†¬†¬†¬†¬† devices, protocol extensions or specific client software.

¬†¬†¬†¬†¬†¬† The purpose of having the console interface is to have a
¬†¬†¬†¬†¬†¬† management interface that can be made to work quickly at all
¬†¬†¬†¬†¬†¬† times. Requiring complex or nonstandard behavior on the part of
¬†¬†¬†¬†¬†¬† attached devices reduces the likelihood that the console will work
¬†¬†¬†¬†¬†¬† without hassles.

¬†¬†¬† Examples.

¬†¬†¬†¬†¬†¬† If the console is supplied via an RS232 interface, then it should
¬†¬†¬†¬†¬†¬† function with an attached device that only implements a "dumb"
¬†¬†¬†¬†¬†¬† terminal. Support of "advanced" terminal features/types should be
¬†¬†¬†¬†¬†¬† optional.

¬†¬†¬† Warnings.

¬†¬†¬†¬†¬†¬† None.

2.3.4. 'Console' Supports Fall-back Authentication

¬†¬†¬† Requirement.

¬†¬†¬†¬†¬†¬† The 'console' SHOULD support an authentication mechanism which
¬†¬†¬†¬†¬†¬† does not require functional IP or depend on external services.
¬†¬†¬†¬†¬†¬† This authentication mechanism MAY be disabled until a failure of
¬†¬†¬†¬†¬†¬† other preferred mechanisms is detected.

¬†¬†¬† Justification.

¬†¬†¬†¬†¬†¬† It does little good to have a console interface on a device if you
¬†¬†¬†¬†¬†¬† cannot get into the device with it when the network is not
¬†¬†¬†¬†¬†¬† working.

¬†¬†¬† Examples.

¬†¬†¬†¬†¬†¬† Some devices which use TACACS or RADIUS for authentication will
¬†¬†¬†¬†¬†¬† fall back to a local account if the TACACS or RADIUS server does
¬†¬†¬†¬†¬†¬† not reply to an authentication request.

¬†¬†¬† Warnings.

¬†¬†¬†¬†¬†¬† This requirement represents a trade-off between being able to
¬†¬†¬†¬†¬†¬† manage the device (functionality) and security. There are many
¬†¬†¬†¬†¬†¬† ways to implement this which would provide reduced security for
¬†¬†¬†¬†¬†¬† the device, (eg, a back door for unauthorized access). Local
¬†¬†¬†¬†¬†¬† policy should be consulted to determine if "fail open" or "fail
Jones Informational [Page 20]
¬†
RFC 3871 Operational Security Requirements September 2004
¬†¬†¬†¬†¬†¬† closed" is the correct stance. The implications of "fail closed"
¬†¬†¬†¬†¬†¬† (eg, not being able to manage a device) should be fully
¬†¬†¬†¬†¬†¬† considered.

¬†¬†¬†¬†¬†¬† If the fall-back mechanism is disabled, it is important that the
¬†¬†¬†¬†¬†¬† failure of IP based authentication mechanism be reliably detected
¬†¬†¬†¬†¬†¬† and the fall-back mechanism automatically enabled...otherwise the
¬†¬†¬†¬†¬†¬† operator may be left with no means to authenticate.

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

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

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

¬†¬†¬† Examples.

¬†¬†¬†¬†¬†¬† Implementing separate forwarding tables for management plane and
¬†¬†¬†¬†¬†¬† non-management plane interfaces that do not propagate routes to
¬†¬†¬†¬†¬†¬† each other satisfies this requirement.

¬†¬†¬† Warnings.

¬†¬†¬†¬†¬†¬† None.

2.4. Configuration and Management Interface Requirements

¬†¬†¬† This section lists requirements that support secure 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 to meet these requirements with other
¬†¬†¬† mechanisms, for instance SNMP or a script-able HTML interface that
¬†¬†¬† provides full access to management and configuration functions. In
¬†¬†¬† the future, there may be others (eg, XML based configuration).

¬†¬†¬†¬†¬†¬† The Command Line Interface (CLI) or equivalent MUST allow complete
¬†¬†¬†¬†¬†¬† access to all configuration and management functions. The CLI
¬†¬†¬†¬†¬†¬† MUST be supported on the console (see Section 2.3.1) and SHOULD be
¬†¬†¬†¬†¬†¬† supported on all other interfaces used for management.

¬†¬†¬† Justification.

¬†¬†¬†¬†¬†¬† The CLI (or equivalent) is needed to provide the ability to do
¬†¬†¬†¬†¬†¬† reliable, fast, direct, local management and monitoring of a
¬†¬†¬†¬†¬†¬† device. It is particularly useful in situations where it is not
¬†¬†¬†¬†¬†¬† possible to manage and monitor the device in-band via "normal"
¬†¬†¬†¬†¬†¬† means (eg, SSH or SNMP [RFC3410], [RFC3411]) that depend on
¬†¬†¬†¬†¬†¬† functional networking. Such situations often occur during
¬†¬†¬†¬†¬†¬† security incidents such as bandwidth-based denial of service
¬†¬†¬†¬†¬†¬† attacks.
Jones Informational [Page 22]
¬†
RFC 3871 Operational Security Requirements September 2004
¬†¬†¬† Examples.

¬†¬†¬†¬†¬†¬† The CLI or equivalent MUST support external scripting of
¬†¬†¬†¬†¬†¬† configuration functions. This CLI SHOULD support the same command
¬†¬†¬†¬†¬†¬† set and syntax as that in Section 2.4.1.

¬†¬†¬† Justification.

¬†¬†¬†¬†¬†¬† During the handling of security incidents, it is often necessary
¬†¬†¬†¬†¬†¬† to quickly make configuration changes on large numbers of devices.
¬†¬†¬†¬†¬†¬† Doing so manually is error prone and slow. Vendor supplied
¬†¬†¬†¬†¬†¬† management solutions do not always foresee or address the type or
¬†¬†¬†¬†¬†¬† scale of solutions that are required. The ability to script
¬†¬†¬†¬†¬†¬† provides a solution to these problems.

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

¬†¬†¬† Warnings.

¬†¬†¬†¬†¬†¬† Some properties of the command language that enhance the ability
¬†¬†¬†¬†¬†¬† to script are: simplicity, regularity and consistency. Some
¬†¬†¬†¬†¬†¬† implementations that would make scripting difficult or impossible
¬†¬†¬†¬†¬†¬† include: "text menu" style interfaces (eg, "curses" on UNIX) or
¬†¬†¬†¬†¬†¬† a hard-coded GUI interfaces (eg, a native Windows or Macintosh
¬†¬†¬†¬†¬†¬† GUI application) that communicate using a proprietary or
¬†¬†¬†¬†¬†¬† undocumented protocol not based on a CLI.

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

¬†¬†¬†¬†¬†¬† One mechanism that supports operation over slow links is the
¬†¬†¬†¬†¬†¬† ability to apply filters to the output of CLI commands which have
¬†¬†¬†¬†¬†¬† potentially large output. This may be implemented with something
¬†¬†¬†¬†¬†¬† similar to the UNIX pipe facility and "grep" command.

¬†¬†¬†¬†¬†¬† For example,

¬†¬†¬†¬†¬†¬†¬†¬†¬† cat largefile.txt | grep interesting-string

¬†¬†¬†¬†¬†¬† Another is the ability to "page" through large command output,
¬†¬†¬†¬†¬†¬† e.g., the UNIX "more" command:

¬†¬†¬†¬†¬†¬† For example,

¬†¬†¬†¬†¬†¬†¬†¬†¬† cat largefile.txt | more

¬†¬†¬† Warnings.

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

¬†¬†¬†¬†¬†¬† The command line interface (CLI) or equivalent mechanism MUST
¬†¬†¬†¬†¬†¬† support a configurable idle timeout value.

¬†¬†¬† Justification.

¬†¬†¬†¬†¬†¬† Network administrators go to lunch. They leave themselves logged
¬†¬†¬†¬†¬†¬† in with administrative privileges. They forget to use screen-
¬†¬†¬†¬†¬†¬† savers with password protection. They do this while at
¬†¬†¬†¬†¬†¬† conferences and in other public places. This behavior presents
¬†¬†¬†¬†¬†¬† opportunity for unauthorized access. Idle timeouts reduce the
¬†¬†¬†¬†¬†¬† window of exposure.

¬†¬†¬† Examples.

¬†¬†¬†¬†¬†¬† The CLI may provide a configuration command that allows an idle
¬†¬†¬†¬†¬†¬† timeout to be set. If the operator does not enter commands for
¬†¬†¬†¬†¬†¬† that amount of time, the login session will be automatically
¬†¬†¬†¬†¬†¬† terminated.

¬†¬†¬† Warnings.

¬†¬†¬†¬†¬†¬† None.

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. While new software
¬†¬†¬†¬†¬†¬† MAY be loaded from writable media (disk, flash, etc.), the
¬†¬†¬†¬†¬†¬† capability to load new software MUST depend only on non-writable
¬†¬†¬†¬†¬†¬† media (ROM, etc.). The installation procedures SHOULD support
¬†¬†¬†¬†¬†¬† mechanisms to ensure reliability and integrity of data transfers.

¬†¬†¬† Justification.

¬†¬†¬† * Vulnerabilities are often discovered in the base software
¬†¬†¬†¬†¬†¬† (operating systems, etc.) shipped by vendors. Often mitigation of
¬†¬†¬†¬†¬†¬† the risk presented by these vulnerabilities can only be
¬†¬†¬†¬†¬†¬† accomplished by updates to the vendor supplied software (eg, bug

Jones Informational [Page 25]
¬†
RFC 3871 Operational Security Requirements September 2004
¬†¬†¬†¬†¬†¬† 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.

¬†¬†¬† * One has to assume that hackers, operators, etc. may erase or
¬†¬†¬†¬†¬†¬† corrupt all writable media (disks, flash, etc.). In such
¬†¬†¬†¬†¬†¬† situations, it is necessary to be able to recover starting with
¬†¬†¬†¬†¬†¬† only non-writable media (eg, CD-ROM, a true ROM-based monitor).

¬†¬†¬† * System images may be corrupted in transit (from vendor to
¬†¬†¬†¬†¬†¬† customer, or during the loading process) or in storage (bit rot,
¬†¬†¬†¬†¬†¬† defective media, etc.). Failure to reliably load a new image, for
¬†¬†¬†¬†¬†¬† example after a hacker deletes or corrupts the installed image,
¬†¬†¬†¬†¬†¬† could result in extended loss of availability.

¬†¬†¬† Examples.

¬†¬†¬†¬†¬†¬† The device could support booting into a simple ROM-based monitor
¬†¬†¬†¬†¬†¬† that supported a set of commands sufficient to load new operating
¬†¬†¬†¬†¬†¬† system code and configuration data from other devices. The
¬†¬†¬†¬†¬†¬† operating system and configuration might be loaded from:

¬†¬†¬† RS232. 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.
Jones Informational [Page 26]
¬†
RFC 3871 Operational Security Requirements September 2004
¬†¬†¬† FLASH. The device could support booting from flash memory cards.

¬†¬†¬†¬†¬†¬† Simple mechanisms currently in use to protect the integrity of
¬†¬†¬†¬†¬†¬† system images and data transfer include image checksums and simple
¬†¬†¬†¬†¬†¬† serial file transfer protocols such as XMODEM and Kermit.

¬†¬†¬† 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. Stored versions of the
¬†¬†¬†¬†¬†¬† configuration MAY be compressed using an algorithm which is
¬†¬†¬†¬†¬†¬† subject to open review, as long as the fact is clearly identified
¬†¬†¬†¬†¬†¬† and the compression can be disabled. Sensitive information such
¬†¬†¬†¬†¬†¬† as passwords that could be used to compromise the security of the
¬†¬†¬†¬†¬†¬† device MAY be excluded from the saved configuration.

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

¬†¬†¬† 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 saved.

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

¬†¬†¬†¬†¬†¬† Note that if passwords or other sensitive information are excluded
¬†¬†¬†¬†¬†¬† from the saved copy of the configuration, as allowed by Section
¬†¬†¬†¬†¬†¬† 2.4.6, then the restore may not be complete. The operator may
¬†¬†¬†¬†¬†¬† have to set new passwords or supply other information that was not
¬†¬†¬†¬†¬†¬† saved.

2.4.8. Support Text Configuration Files

¬†¬†¬† Requirement.

¬†¬†¬†¬†¬†¬† The device MUST support display, backup and restore of system
¬†¬†¬†¬†¬†¬† configuration in a simple well defined textual format. The
¬†¬†¬†¬†¬†¬† configuration MUST also be viewable as text on the device itself.
¬†¬†¬†¬†¬†¬† It MUST NOT be necessary to use a proprietary program to view the
¬†¬†¬†¬†¬†¬† configuration.

¬†¬†¬† Justification.

¬†¬†¬†¬†¬†¬† Simple, well-defined textual configurations facilitate human
¬†¬†¬†¬†¬†¬† understanding of the operational state of the device, enable off-
¬†¬†¬†¬†¬†¬† line audits, and facilitate automation. Requiring the use of a
¬†¬†¬†¬†¬†¬† proprietary program to access the configuration inhibits these
¬†¬†¬†¬†¬†¬† goals.

¬†¬†¬† Examples.

¬†¬†¬†¬†¬†¬† A 7-bit ASCII configuration file that shows the current settings
¬†¬†¬†¬†¬†¬† of the various configuration options would satisfy the
¬†¬†¬†¬†¬†¬† requirement, as would a Unicode configuration or any other
¬†¬†¬†¬†¬†¬† "textual" representation. A structured binary format intended
¬†¬†¬†¬†¬†¬† only for consumption by programs would not be acceptable.

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

¬†¬†¬†¬†¬†¬† "Well defined" and "textual" are open to interpretation. Clearly
¬†¬†¬†¬†¬†¬† an ASCII configuration file with a regular, documented command
¬†¬†¬†¬†¬†¬† oriented-syntax would meet the definition. These are currently in
¬†¬†¬†¬†¬†¬† wide use. Future options, such as XML based configuration may
¬†¬†¬†¬†¬†¬† meet the requirement. Determining this will require evaluation
¬†¬†¬†¬†¬†¬† against the justifications listed above.

2.5. IP Stack Requirements

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 addresses to which each service is bound.

¬†¬†¬†¬†¬†¬† * Display the addresses assigned to each interface.

¬†¬†¬†¬†¬†¬† * Display any and all port(s) on which the service is listing.

¬†¬†¬†¬†¬†¬† * 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
¬†¬†¬†¬†¬†¬† (eg, "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 (eg, "should I turn this
¬†¬†¬†¬†¬†¬† service off ?")

¬†¬†¬†¬†¬†¬† If the device is listening for SNMP traffic from any source
¬†¬†¬†¬†¬†¬† directed to the IP addresses of any of its local 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 "services" (see
¬†¬†¬†¬†¬†¬† Section 1.8).

¬†¬†¬† 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. 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 any address or net-block associated with any interface local to
¬†¬†¬†¬†¬†¬† the device. This must include addresses bound to physical or
¬†¬†¬†¬†¬†¬† non-physical (e.g., loopback) interfaces.

¬†¬†¬† Justification.

¬†¬†¬†¬†¬†¬† It is a common practice among operators to configure "loopback"
¬†¬†¬†¬†¬†¬† pseudo-interfaces to use as the source and destination of
¬†¬†¬†¬†¬†¬† management traffic. These are preferred to physical interfaces

¬†¬†¬†¬†¬†¬† This requirement makes it possible to restrict access to
¬†¬†¬†¬†¬†¬† management services using routing. Management services may be
¬†¬†¬†¬†¬†¬† bound only to the addresses of loopback interfaces. The loopback
¬†¬†¬†¬†¬†¬† interfaces may be addressed out of net-blocks that are only routed
¬†¬†¬†¬†¬†¬† between the managed devices and the authorized management
¬†¬†¬†¬†¬†¬† networks/hosts. This has the effect of making it impossible for
¬†¬†¬†¬†¬†¬† anyone to connect to (or attempt to DoS) management services from
¬†¬†¬†¬†¬†¬† anywhere but the authorized management networks/hosts.

¬†¬†¬†¬†¬†¬† It also 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 (eg, the address of the loopback interface) or
¬†¬†¬†¬†¬†¬† received on certain interfaces (eg, 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 to every address configured on the device. Similar
¬†¬†¬†¬†¬†¬† effects may be achieved with the use of global filters, sometimes
¬†¬†¬†¬†¬†¬† called "receive" or "loopback" ACLs, that filter traffic destined
¬†¬†¬†¬†¬†¬† for the device itself on all interfaces.

¬†¬†¬† Warnings.

¬†¬†¬†¬†¬†¬† None.

2.5.4. Ability to Control Service Source Addresses

¬†¬†¬† Requirement.

¬†¬†¬†¬†¬†¬† The device MUST provide a means that allows the user to specify
¬†¬†¬†¬†¬†¬† the source addresses used for all outbound connections or
¬†¬†¬†¬†¬†¬† transmissions originating from the device. It SHOULD 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.

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

¬†¬†¬†¬†¬†¬† The operator may allocate a distinct block of addresses from which
¬†¬†¬†¬†¬†¬† all loopbacks are numbered. NTP and syslog can be configured to
¬†¬†¬†¬†¬†¬† use those loopback addresses as source, while SNMP and BGP may be
¬†¬†¬†¬†¬†¬† configured to use specific physical interface addresses. This
¬†¬†¬†¬†¬†¬† would facilitate filtering based on source address as one way of
¬†¬†¬†¬†¬†¬† rejecting unauthorized attempts to connect to peers/servers.

¬†¬†¬† Warnings.

¬†¬†¬†¬†¬†¬† Care should be taken to assure that the addresses chosen are
¬†¬†¬†¬†¬†¬† routable between the sending and receiving devices, (eg, setting
¬†¬†¬†¬†¬†¬† SSH to use a loopback address of 10.1.1.1 which is not routed
¬†¬†¬†¬†¬†¬† between a router and all intended destinations could cause
¬†¬†¬†¬†¬†¬† problems).

¬†¬†¬†¬†¬†¬† Note that some protocols, such as SCTP [RFC3309], can use more
¬†¬†¬†¬†¬†¬† than one IP address as the endpoint of a single connection.

¬†¬†¬†¬†¬†¬† Also note that [RFC3631] lists address-based authentication as an
¬†¬†¬†¬†¬†¬† "insecurity mechanism". Address based authentication should be
¬†¬†¬†¬†¬†¬† replaced or augmented by other mechanisms wherever possible.

2.5.5. Support Automatic Anti-spoofing for Single-Homed Networks

¬†¬†¬† Requirement.

¬†¬†¬†¬†¬†¬† The device MUST provide a means to designate particular interfaces
¬†¬†¬†¬†¬†¬† as servicing "single-homed networks" (see Section 1.8) and MUST
¬†¬†¬†¬†¬†¬† provide an option to automatically drop "spoofed packets" (Section
¬†¬†¬†¬†¬†¬† 1.8) received on such interfaces where application of the current
¬†¬†¬†¬†¬†¬† forwarding table would not route return traffic back through the
¬†¬†¬†¬†¬†¬† same interface. This option MUST work in the presence of dynamic
¬†¬†¬†¬†¬†¬† routing and dynamically assigned addresses.

¬†¬†¬†¬†¬†¬† See sections 3 of [RFC1918], sections 5.3.7 and 5.3.8 of
¬†¬†¬†¬†¬†¬† [RFC1812], and [RFC2827].

¬†¬†¬† 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 forwarding tables and dropped if they
¬†¬†¬†¬†¬†¬† would not be forwarded back through the interface on which they
¬†¬†¬†¬†¬†¬† were received.

¬†¬†¬†¬†¬†¬† See [RFC3704].

¬†¬†¬† Warnings.

¬†¬†¬†¬†¬†¬† This requirement only holds for single-homed networks. Note that
¬†¬†¬†¬†¬†¬† a simple forwarding table check is not sufficient in the more
¬†¬†¬†¬†¬†¬† complex scenarios of multi-homed or multi-attached networks, ie,
¬†¬†¬†¬†¬†¬† where the traffic may be asymmetric. In these cases, a more
¬†¬†¬†¬†¬†¬† extensive check such as Feasible Path RPF could be very useful.

2.5.6. Support Automatic Discarding Of Bogons and Martians

¬†¬†¬† Requirement.

¬†¬†¬†¬†¬†¬† The device MUST provide a means to automatically drop all "bogons"
¬†¬†¬†¬†¬†¬† (Section 1.8) and "martians" (Section 1.8). This option MUST work
¬†¬†¬†¬†¬†¬† in the presence of dynamic routing and dynamically assigned
¬†¬†¬†¬†¬†¬† addresses.

¬†¬†¬† Justification.

¬†¬†¬†¬†¬†¬† These sorts of packets have little (no?) legitimate use and are
¬†¬†¬†¬†¬†¬† used primarily to allow individuals and organization to avoid
¬†¬†¬†¬†¬†¬† identification (and thus accountability) and appear to be most
¬†¬†¬†¬†¬†¬† often used for DoS attacks, email abuse, hacking, etc. In
¬†¬†¬†¬†¬†¬† addition, transiting these packets needlessly consumes resources
¬†¬†¬†¬†¬†¬† and may lead to capacity and performance problems for customers.

¬†¬†¬†¬†¬†¬† See sections 3 of [RFC1918], sections 5.3.7 and 5.3.8 of
¬†¬†¬†¬†¬†¬† [RFC1812], and [RFC2827].

¬†¬†¬†¬†¬†¬† This requirement could be satisfied by the provision of a command
¬†¬†¬†¬†¬†¬† that causes the return path for packets received to be checked
¬†¬†¬†¬†¬†¬† against the current forwarding tables and dropped if no viable
¬†¬†¬†¬†¬†¬† return path exists. This assumes that steps are taken to assure
¬†¬†¬†¬†¬†¬† that no bogon entries are present in the forwarding tables (for
¬†¬†¬†¬†¬†¬† example filtering routing updates per Section 2.7.5 to reject
¬†¬†¬†¬†¬†¬† advertisements of unassigned addresses).

¬†¬†¬†¬†¬†¬† See [RFC3704].

¬†¬†¬† Warnings.

¬†¬†¬†¬†¬†¬† This requirement only holds for single-homed networks. Note that
¬†¬†¬†¬†¬†¬† a simple forwarding table check is not sufficient in the more
¬†¬†¬†¬†¬†¬† complex scenarios of multi-homed or multi-attached networks, ie,
¬†¬†¬†¬†¬†¬† where the traffic may be asymmetric. In these cases, a more
¬†¬†¬†¬†¬†¬† extensive check such as Feasible Path RPF could be very useful.

¬†¬†¬†¬†¬†¬† Counters can help in identifying the source of spoofed traffic.

¬†¬†¬† Examples.

¬†¬†¬†¬†¬†¬† An edge router may have several single-homed customers attached.
¬†¬†¬†¬†¬†¬† When an attack using spoofed packets is detected, a quick check of
¬†¬†¬†¬†¬†¬† counters may be able to identify which customer is attempting to
¬†¬†¬†¬†¬†¬† send spoofed traffic.

¬†¬†¬†¬†¬†¬† The device MUST provide the capability to limit the rate at which
¬†¬†¬†¬†¬†¬† it will pass traffic based on protocol, source and destination IP
¬†¬†¬†¬†¬†¬† address or CIDR block, source and destination port, and interface.
¬†¬†¬†¬†¬†¬† Protocols MUST include at least IP, ICMP, UDP, and TCP and SHOULD
¬†¬†¬†¬†¬†¬† include any protocol.

¬†¬†¬† Justification.

¬†¬†¬†¬†¬†¬† This requirement provides a means of reducing or eliminating the
¬†¬†¬†¬†¬†¬† impact of certain types of attacks. Also, rate limiting has the
¬†¬†¬†¬†¬†¬† advantage that in some cases it can be turned on a priori, thereby
¬†¬†¬†¬†¬†¬† offering some ability to mitigate the effect of future attacks
¬†¬†¬†¬†¬†¬† prior to any explicit operator reaction to the 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 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.

¬†¬†¬†¬†¬†¬† The device MUST provide support to rate-limit input and/or output
¬†¬†¬†¬†¬†¬† separately on each interface.

¬†¬†¬† Justification.

¬†¬†¬†¬†¬†¬† This level of granular control allows appropriately targeted
¬†¬†¬†¬†¬†¬† controls that minimize the impact on third parties.

¬†¬†¬† Examples.

¬†¬†¬†¬†¬†¬† If an ICMP flood is directed a single customer on an edge router,
¬†¬†¬†¬†¬†¬† it may be appropriate to rate-limit outbound ICMP only on that
¬†¬†¬†¬†¬†¬† customers interface.

¬†¬†¬† Warnings.

¬†¬†¬†¬†¬†¬† None.

2.6.3. Support Rate Limiting Based on State

¬†¬†¬† Requirement.

¬†¬†¬†¬†¬†¬† The device MUST be able to rate limit based on all TCP control
¬†¬†¬†¬†¬†¬† flag bits. The device SHOULD support rate limiting of other
¬†¬†¬†¬†¬†¬† stateful protocols where the normal processing of the protocol
¬†¬†¬†¬†¬†¬† gives the device access to protocol 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.

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

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

¬†¬†¬† 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 allows the operator to apply filters that protect the device
¬†¬†¬†¬†¬†¬† itself from attacks and unauthorized access.

¬†¬†¬† Examples.

¬†¬†¬†¬†¬†¬† Examples of this might include filters that permit only BGP from
¬†¬†¬†¬†¬†¬† peers and SNMP and SSH from an authorized management segment and
¬†¬†¬†¬†¬†¬† directed to the device itself, while dropping all other traffic
¬†¬†¬†¬†¬†¬† addressed to the device.
Jones Informational [Page 37]
¬†
RFC 3871 Operational Security Requirements September 2004
¬†¬†¬† 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.

¬†¬†¬†¬†¬†¬† 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 Significant Performance Degradation

¬†¬†¬† Requirement.

¬†¬†¬†¬†¬†¬† The device MUST provide a means to filter packets without
¬†¬†¬†¬†¬†¬† significant performance degradation. This specifically applies to
¬†¬†¬†¬†¬†¬† stateless packet filtering operating on layer 3 (IP) and layer 4
¬†¬†¬†¬†¬†¬† (TCP or UDP) headers, as well as normal packet forwarding
¬†¬†¬†¬†¬†¬† information such as incoming and outgoing interfaces.

¬†¬†¬†¬†¬†¬† The device MUST be able to apply stateless packet filters on ALL
¬†¬†¬†¬†¬†¬† interfaces (up to the maximum number possible) simultaneously and
¬†¬†¬†¬†¬†¬† with multiple filters per interface (eg, inbound and outbound).

¬†¬†¬† Justification.

¬†¬†¬†¬†¬†¬† This 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.
Jones Informational [Page 38]
¬†
RFC 3871 Operational Security Requirements September 2004
¬†¬†¬† 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 30Mb/sec without filtering, then
¬†¬†¬†¬†¬†¬† it should be able to forward the same amount with filtering in
¬†¬†¬†¬†¬†¬† place.

¬†¬†¬† Warnings.

¬†¬†¬†¬†¬†¬† The definition of "significant" is subjective. At one end of the
¬†¬†¬†¬†¬†¬† spectrum it might mean "the application of filters may cause the
¬†¬†¬†¬†¬†¬† box to crash". At the other end would be a throughput loss of
¬†¬†¬†¬†¬†¬† less than one percent with tens of thousands of filters applied.
¬†¬†¬†¬†¬†¬† The level of performance degradation that is acceptable will have
¬†¬†¬†¬†¬†¬† to be determined by the operator.

¬†¬†¬†¬†¬†¬† This requirement does not address stateful filtering, filtering
¬†¬†¬†¬†¬†¬† above layer 4 headers or other more advanced types of filtering
¬†¬†¬†¬†¬†¬† that may be important in certain operational environments.

2.7.5. Support Route Filtering

¬†¬†¬† Requirement.

¬†¬†¬†¬†¬†¬† The device MUST provide a means to filter routing updates for all
¬†¬†¬†¬†¬†¬† protocols used to exchange external routing information.

¬†¬†¬† Justification.

¬†¬†¬†¬†¬†¬† See [RFC3013] and section 3.2 of [RFC2196].

¬†¬†¬† Examples.

¬†¬†¬†¬†¬†¬† Operators may wish to ignore advertisements for routes to
¬†¬†¬†¬†¬†¬† addresses allocated for private internets. See eBGP.

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

¬†¬†¬†¬†¬†¬† While silently dropping traffic without sending notification may
¬†¬†¬†¬†¬†¬† be the correct action in security terms, consideration should be
¬†¬†¬†¬†¬†¬† given to operational implications. See [RFC3360] for
¬†¬†¬†¬†¬†¬† consideration of potential problems caused by sending
¬†¬†¬†¬†¬†¬† inappropriate TCP Resets.

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:

¬†¬†¬†¬†¬†¬† 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 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 the
¬†¬†¬†¬†¬†¬† value of the protocol field in the IP header.

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

¬†¬†¬†¬†¬†¬† 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 Protocol Header Fields

¬†¬†¬† Requirement.

¬†¬†¬†¬†¬†¬† The filtering mechanism MUST support filtering based on the
¬†¬†¬†¬†¬†¬† value(s) of any portion of the protocol headers for IP, ICMP, UDP
¬†¬†¬†¬†¬†¬† and TCP. It SHOULD support filtering of all other protocols
¬†¬†¬†¬†¬†¬† supported at layer 3 and 4. It MAY support filtering based on the
¬†¬†¬†¬†¬†¬† headers of higher level protocols. It SHOULD be possible to
¬†¬†¬†¬†¬†¬† specify fields by name (eg, "protocol = ICMP") rather than bit-
¬†¬†¬†¬†¬†¬† offset/length/numeric value (e.g., 72:8 = 1).

¬†¬†¬† Justification.

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

¬†¬†¬† Examples.

¬†¬†¬†¬†¬†¬† 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+ACK bit clear
¬†¬†¬†¬†¬†¬† or SYN bit set+ACK,FIN and RST bits clear). Another common

Jones Informational [Page 42]
¬†
RFC 3871 Operational Security Requirements September 2004
¬†¬†¬†¬†¬†¬† example is the ability to control what services are allowed in/out
¬†¬†¬†¬†¬†¬† of a network. 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.

¬†¬†¬†¬†¬†¬† Accurate counting of filter rule matches is important because it
¬†¬†¬†¬†¬†¬† shows the 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 spoofed packets are
¬†¬†¬†¬†¬†¬† being sent. This may indicate that the customer is performing
¬†¬†¬†¬†¬†¬† potentially malicious actions (possibly in violation of the ISPs
¬†¬†¬†¬†¬†¬† 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.

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

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

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

¬†¬†¬†¬†¬†¬† For the purposes of this requirement it would be acceptable for
¬†¬†¬†¬†¬†¬† the system to maintain two counters: an "absolute counter",
¬†¬†¬†¬†¬†¬† C[now], and a "reset" counter, C[reset]. The absolute counter
¬†¬†¬†¬†¬†¬† would maintain counts that increase monotonically until they wrap
¬†¬†¬†¬†¬†¬† or overflow the counter. The reset counter would receive a copy
¬†¬†¬†¬†¬†¬† of the current value of the absolute counter when the reset
¬†¬†¬†¬†¬†¬† function was issued for that counter. Functions that display or
¬†¬†¬†¬†¬†¬† retrieve the counter could then display the delta (C[now] -
¬†¬†¬†¬†¬†¬† C[reset]).

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

¬†¬†¬†¬†¬†¬† Filter counters MUST be accurate. They MUST reflect the actual
¬†¬†¬†¬†¬†¬† number of matching packets since the last counter reset. Filter
¬†¬†¬†¬†¬†¬† counters MUST be capable of holding up to 2^32 - 1 values without
¬†¬†¬†¬†¬†¬† overflowing and SHOULD be capable of holding up to 2^64 - 1
¬†¬†¬†¬†¬†¬† values.

¬†¬†¬† 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. 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) would
¬†¬†¬†¬†¬†¬† 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.
Jones Informational [Page 47]
¬†
RFC 3871 Operational Security Requirements September 2004
¬†¬†¬† Warnings.

¬†¬†¬†¬†¬†¬† None.

2.11. Event Logging Requirements

2.11.1. Logging Facility Uses Protocols Subject To Open Review

¬†¬†¬† Requirement.

¬†¬†¬†¬†¬†¬† The device MUST provide a logging facility that is based on
¬†¬†¬†¬†¬†¬† protocols subject to open review. See Section 1.8. Custom or
¬†¬†¬†¬†¬†¬† proprietary logging protocols MAY be implemented provided the same
¬†¬†¬†¬†¬†¬† information is made available.

¬†¬†¬† Justification.

¬†¬†¬†¬†¬†¬† The use of logging based on protocols subject to open review
¬†¬†¬†¬†¬†¬† permits the operator to perform archival and analysis of logs
¬†¬†¬†¬†¬†¬† without relying on vendor-supplied software and servers.

¬†¬†¬† Examples.

¬†¬†¬†¬†¬†¬† This requirement may be satisfied by the use of one or more of
¬†¬†¬†¬†¬†¬† syslog [RFC3164], syslog with reliable delivery [RFC3195], TACACS+
¬†¬†¬†¬†¬†¬† [RFC1492] or RADIUS [RFC2865].

¬†¬†¬† Warnings.

¬†¬†¬†¬†¬†¬† While [RFC3164] meets this requirement, it has many security
¬†¬†¬†¬†¬†¬† issues and by itself does not meet the requirements of Section
¬†¬†¬†¬†¬†¬† 2.1.1. See the security considerations section of [RFC3164] for
¬†¬†¬†¬†¬†¬† a list of issues. [RFC3195] provides solutions to most/all of
¬†¬†¬†¬†¬†¬† these issues....however at the time of this writing there are few
¬†¬†¬†¬†¬†¬† implementations. Other possible solutions might be to tunnel
¬†¬†¬†¬†¬†¬† syslog over a secure transport...but this often raises difficult
¬†¬†¬†¬†¬†¬† key management and scalability issues.

¬†¬†¬†¬†¬†¬† The device MUST support transmission of records of security
¬†¬†¬†¬†¬†¬† related events 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.
¬†¬†¬†¬†¬†¬† 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 one or more of:
¬†¬†¬†¬†¬†¬† syslog [RFC3164], syslog with reliable delivery [RFC3195], TACACS+
¬†¬†¬†¬†¬†¬† [RFC1492] or RADIUS [RFC2865].

¬†¬†¬† Warnings.

¬†¬†¬†¬†¬†¬† Note that there may be privacy or legal considerations when
¬†¬†¬†¬†¬†¬† logging/monitoring user activity.

¬†¬†¬†¬†¬†¬† 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 Select Reliable Delivery

¬†¬†¬† Requirement.

¬†¬†¬†¬†¬†¬† It SHOULD be possible to select reliable delivery of log messages.

¬†¬†¬† Justification.

¬†¬†¬†¬†¬†¬† Reliable delivery is important to the extent that log data is
¬†¬†¬†¬†¬†¬† depended upon to make operational decisions and forensic analysis.
¬†¬†¬†¬†¬†¬† Without reliable delivery, log data becomes a collection of hints.

¬†¬†¬† Examples.

¬†¬†¬†¬†¬†¬† One example of reliable syslog delivery is defined in [RFC3195].
¬†¬†¬†¬†¬†¬† Syslog-ng provides another example, although the protocol has not
¬†¬†¬†¬†¬†¬† been standardized.

¬†¬†¬†¬†¬†¬† It SHOULD be possible to log locally on the device itself. Local
¬†¬†¬†¬†¬†¬† logging SHOULD be written to non-volatile storage.

¬†¬†¬† Justification.

¬†¬†¬†¬†¬†¬† Local logging of failed authentication attempts to non-volatile
¬†¬†¬†¬†¬†¬† storage is critical. It provides a means of detecting attacks
¬†¬†¬†¬†¬†¬† where the device is isolated from its authentication interfaces
¬†¬†¬†¬†¬†¬† and attacked at the console.

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

¬†¬†¬†¬†¬†¬† Accurate time is important to the generation of reliable log data.
¬†¬†¬†¬†¬†¬† Accurate time is also important to the correct operation of some
¬†¬†¬†¬†¬†¬† authentication mechanisms.

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

¬†¬†¬† 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.6. Display Timezone And UTC Offset

¬†¬†¬† Requirement.

¬†¬†¬†¬†¬†¬† All displays and logs of system time MUST include a timezone or
¬†¬†¬†¬†¬†¬† offset from UTC.

¬†¬†¬† Justification.

¬†¬†¬†¬†¬†¬† Knowing the timezone or UTC offset makes correlation of data and
¬†¬†¬†¬†¬†¬† coordination with data in other timezones possible.

¬†¬†¬† Examples.

¬†¬†¬†¬†¬†¬† Bob is in Newfoundland, Canada which is UTC -3:30. Alice is
¬†¬†¬†¬†¬†¬† somewhere in Indiana, USA. Some parts of Indiana switch to
¬†¬†¬†¬†¬†¬† daylight savings time while others do not. A user on Bob's
¬†¬†¬†¬†¬†¬† network attacks a user on Alice's network. Both are using logs
¬†¬†¬†¬†¬†¬† with local timezones and no indication of UTC offset. Correlating
¬†¬†¬†¬†¬†¬† these logs will be difficult and error prone. Including timezone,
¬†¬†¬†¬†¬†¬† or better, UTC offset, eliminates these difficulties.

¬†¬†¬†¬†¬†¬† The default timezone for display and logging SHOULD be UTC. The
¬†¬†¬†¬†¬†¬† device MAY support a mechanism to allow the operator to specify
¬†¬†¬†¬†¬†¬† the display and logging of times in a timezone other than UTC.

¬†¬†¬† Justification.

¬†¬†¬†¬†¬†¬† Knowing the timezone or UTC offset makes correlation of data and
¬†¬†¬†¬†¬†¬† coordination with data in other timezones possible.

¬†¬†¬† Examples.

¬†¬†¬†¬†¬†¬† Bob in Newfoundland (UTC -3:30) and Alice in Indiana (UTC -5 or
¬†¬†¬†¬†¬†¬† UTC -6 depending on the time of year and exact county in Indiana)
¬†¬†¬†¬†¬†¬† are working an incident together using their logs. Both left the
¬†¬†¬†¬†¬†¬† default settings, which was UTC, so there was no translation of
¬†¬†¬†¬†¬†¬† time necessary to correlate the logs.

¬†¬†¬† Warnings.

¬†¬†¬†¬†¬†¬† None.

2.11.8. Logs Must Be Timestamped

¬†¬†¬† Requirement.

¬†¬†¬†¬†¬†¬† By default, the device MUST timestamp all log messages. The
¬†¬†¬†¬†¬†¬† timestamp MUST be accurate to within a second or less. The
¬†¬†¬†¬†¬†¬† timestamp MUST include a timezone. There MAY be a mechanism to
¬†¬†¬†¬†¬†¬† disable the generation of timestamps.

¬†¬†¬† Justification.

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

¬†¬†¬†¬†¬†¬† 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.9. Logs Contain Untranslated IP Addresses

¬†¬†¬† Requirement.

¬†¬†¬†¬†¬†¬† Log messages MUST NOT list translated addresses (DNS names)
¬†¬†¬†¬†¬†¬† associated with the address without listing the untranslated IP
¬†¬†¬†¬†¬†¬† address where the IP address is available to the device generating
¬†¬†¬†¬†¬†¬† the log message.

¬†¬†¬†¬†¬†¬† DNS entries tend to change more quickly than IP block assignments.
¬†¬†¬†¬†¬†¬† This makes the address more reliable for data forensics.

¬†¬†¬†¬†¬†¬† DNS lookups can be slow and consume resources.

¬†¬†¬† Examples.

¬†¬†¬†¬†¬†¬† A failed network login should generate a record with the source
¬†¬†¬†¬†¬†¬† address of the login attempt.

¬†¬†¬† Warnings.

¬†¬†¬†¬†¬†¬† * Source addresses may be spoofed. Network-based attacks often
¬†¬†¬†¬†¬†¬†¬†¬†¬† use spoofed source addresses. Source addresses should not be
¬†¬†¬†¬†¬†¬†¬†¬†¬† completely trusted unless verified by other 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. Having accurate time in the logs increases the chances
¬†¬†¬†¬†¬†¬†¬†¬†¬† that the use of an address can be correlated to an individual.
Jones Informational [Page 53]
¬†
RFC 3871 Operational Security Requirements September 2004
¬†¬†¬†¬†¬†¬† * 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.11.10. Logs Contain Records Of Security Events

¬†¬†¬† Requirement.

¬†¬†¬†¬†¬†¬† The device MUST be able to send a record of at least the following
¬†¬†¬†¬†¬†¬† events:

¬†¬†¬†¬†¬†¬† * authentication successes,

¬†¬†¬†¬†¬†¬† * authentication failures,

¬†¬†¬†¬†¬†¬† * session Termination,

¬†¬†¬†¬†¬†¬† * authorization changes,

¬†¬†¬†¬†¬†¬† * configuration changes,

¬†¬†¬†¬†¬†¬† * device status changes.

¬†¬†¬†¬†¬†¬† The device SHOULD be able to send a record of all other security
¬†¬†¬†¬†¬†¬† related events.

¬†¬†¬† Justification.

¬†¬†¬†¬†¬†¬† This is important because it supports individual accountability.
¬†¬†¬†¬†¬†¬† See section 4.5.4.4 of [RFC2196].

¬†¬†¬† Examples.

¬†¬†¬†¬†¬†¬† Examples of events for which there must be a record include: user
¬†¬†¬†¬†¬†¬† logins, bad login attempts, logouts, user privilege level changes,
¬†¬†¬†¬†¬†¬† individual configuration commands issued by users and system
¬†¬†¬†¬†¬†¬† startup/shutdown events.

¬†¬†¬† Warnings.

¬†¬†¬†¬†¬†¬† This list is far from complete.

¬†¬†¬†¬†¬†¬† Note that there may be privacy or legal considerations when
¬†¬†¬†¬†¬†¬† logging/monitoring user activity.

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

¬†¬†¬†¬†¬†¬† Mechanisms used to authenticate interactive access for
¬†¬†¬†¬†¬†¬† configuration and management MUST support the authentication of
¬†¬†¬†¬†¬†¬† distinct, individual users. This requirement MAY be relaxed to
¬†¬†¬†¬†¬†¬† support system installation Section 2.4.5 or recovery of
¬†¬†¬†¬†¬†¬† authorized access Section 2.12.15.

¬†¬†¬† Justification.

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

¬†¬†¬† Examples.

¬†¬†¬†¬†¬†¬† A user may need to log in to the device to access CLI functions
¬†¬†¬†¬†¬†¬† for management. Individual user authentication could be provided
¬†¬†¬†¬†¬†¬† by a centralized authentication server or a username/password
¬†¬†¬†¬†¬†¬† database stored on the device. It would be a violation of this
¬†¬†¬†¬†¬†¬† rule for the device to only support a single "account" (with or
¬†¬†¬†¬†¬†¬† without a username) and a single password shared by all users to
¬†¬†¬†¬†¬†¬† gain administrative access.

¬†¬†¬† 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 MUST support multiple simultaneous connections by
¬†¬†¬†¬†¬†¬† distinct users, possibly at different authorization levels.

¬†¬†¬† Justification.

¬†¬†¬†¬†¬†¬† This allows multiple people to perform authorized management
¬†¬†¬†¬†¬†¬† functions simultaneously. This also means that attempted
¬†¬†¬†¬†¬†¬† connections by unauthorized users do not automatically lock out
¬†¬†¬†¬†¬†¬† authorized users.

¬†¬†¬†¬†¬†¬† The device MUST provide a means of disabling all local accounts
¬†¬†¬†¬†¬†¬† including:

¬†¬†¬† * local users,

¬†¬†¬† * default accounts (vendor, maintenance, guest, etc.),

¬†¬†¬† * privileged and unprivileged accounts.

¬†¬†¬†¬†¬†¬† A local account defined as one where all information necessary for
¬†¬†¬†¬†¬†¬† user authentication is stored on the device.

¬†¬†¬† Justification.

¬†¬†¬†¬†¬†¬† Default accounts, well-known 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.

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

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

¬†¬†¬†¬†¬†¬† This requirement can be satisfied through the use of DIAMETER
¬†¬†¬†¬†¬†¬† [RFC3588], TACACS+ [RFC1492], RADIUS [RFC2865], or Kerberos
¬†¬†¬†¬†¬†¬† [RFC1510].

¬†¬†¬†¬†¬†¬† See [RFC3579] for a discussion security issues related to RADIUS.

¬†¬†¬† 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 '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.

¬†¬†¬†¬†¬†¬† 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 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", ie, access should be denied
¬†¬†¬†¬†¬†¬† if none of the listed authentication methods succeeds.

¬†¬†¬†¬†¬†¬† 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. Ability To Authenticate Without Plaintext Passwords

¬†¬†¬† Requirement.

¬†¬†¬†¬†¬†¬† The device MUST support mechanisms that do not require the
¬†¬†¬†¬†¬†¬† transmission of plaintext passwords in all cases that require the
¬†¬†¬†¬†¬†¬† transmission of authentication information across networks.

¬†¬†¬†¬†¬†¬† The initial configuration of the device MUST NOT contain any
¬†¬†¬†¬†¬†¬† default passwords or other authentication tokens.

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

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

¬†¬†¬† 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
¬†¬†¬†¬†¬†¬† hundreds 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. There MUST be at least three possible privilege levels.

¬†¬†¬† 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 "user" which only
¬†¬†¬†¬†¬†¬† allows the initiation of a PPP or telnet session, "read only",
¬†¬†¬†¬†¬†¬† 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

¬†¬†¬†¬†¬†¬† The device MUST be able to assign a defined set of authorized
¬†¬†¬†¬†¬†¬† functions, or "privilege level", to each user once they have
¬†¬†¬†¬†¬†¬† authenticated themselves to the device. Privilege level
¬†¬†¬†¬†¬†¬† determines which functions a user is allowed to execute. Also 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.

¬†¬†¬† Examples.

¬†¬†¬†¬†¬†¬† The implementation of this requirement will obviously be closely
¬†¬†¬†¬†¬†¬† coupled with the authentication mechanism. 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 'None'

¬†¬†¬† Requirement.

¬†¬†¬†¬†¬†¬† The default privilege level SHOULD NOT allow any access to
¬†¬†¬†¬†¬†¬† management or configuration functions. It MAY allow access to
¬†¬†¬†¬†¬†¬† user-level functions (eg, starting PPP or telnet). It SHOULD be
¬†¬†¬†¬†¬†¬† possible to assign a different privilege level as the default.
¬†¬†¬†¬†¬†¬† This requirement MAY be relaxed to support system installation per
¬†¬†¬†¬†¬†¬† Section 2.4.5 or recovery of authorized access per Section
¬†¬†¬†¬†¬†¬† 2.12.15.

¬†¬†¬†¬†¬†¬† 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 "user" which only
¬†¬†¬†¬†¬†¬† allows the initiation of a PPP or telnet session, "read-only",
¬†¬†¬†¬†¬†¬† 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.

¬†¬†¬†¬†¬†¬† It may be required to provide exceptions to support the
¬†¬†¬†¬†¬†¬† requirements to support recovery of privileged access (Section
¬†¬†¬†¬†¬†¬† 2.12.15) and to support OS installation and configuration (Section
¬†¬†¬†¬†¬†¬† 2.4.5). For example, if the OS and/or configuration has somehow
¬†¬†¬†¬†¬†¬† become corrupt an authorized individual with physical access may
¬†¬†¬†¬†¬†¬† need to have "root" level access to perform an install.

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

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

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

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

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

2.14. Security Features Must Not Cause Operational Problems

¬†¬†¬† Requirement.

¬†¬†¬†¬†¬†¬† The use of security features specified by the requirements in this
¬†¬†¬†¬†¬†¬† document SHOULD NOT cause severe operational problems.

¬†¬†¬† Justification.

¬†¬†¬†¬†¬†¬† Security features which cause operational problems are not useful
¬†¬†¬†¬†¬†¬† and may leave the operator with no mechanism for enforcing
¬†¬†¬†¬†¬†¬† appropriate policy.

¬†¬†¬†¬†¬†¬† Determination of compliance with this requirement involves a level
¬†¬†¬†¬†¬†¬† of judgement. What is "severe"? Certainly crashing is severe,
¬†¬†¬†¬†¬†¬† but what about a %5 loss in throughput when logging is enabled?
¬†¬†¬†¬†¬†¬† It should also be noted that there may be unavoidable physical
¬†¬†¬†¬†¬†¬† limitations such as the total capacity of a link.

2.15. Security Features Should Have Minimal Performance Impact

¬†¬†¬† Requirement.

¬†¬†¬†¬†¬†¬† Security features specified by the requirements in this document
¬†¬†¬†¬†¬†¬† SHOULD be implemented with minimal impact on performance. Other
¬†¬†¬†¬†¬†¬† sections of this document may specify different performance
¬†¬†¬†¬†¬†¬† requirements (e.g., "MUST"s).

¬†¬†¬† Justification.

¬†¬†¬†¬†¬†¬† Security features which significantly impact performance may leave
¬†¬†¬†¬†¬†¬† the operator with no mechanism for enforcing appropriate policy.

¬†¬†¬† Examples.

¬†¬†¬†¬†¬†¬† If the application of filters is known to have the potential to
¬†¬†¬†¬†¬†¬† significantly reduce throughput for non-filtered traffic, there
¬†¬†¬†¬†¬†¬† will be a tendency, or in some cases a policy, not to use filters.

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

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

3.1. Identify Services That May Be Listening

¬†¬†¬† Requirement.

¬†¬†¬†¬†¬†¬† The vendor MUST provide a list of all services that may be active
¬†¬†¬†¬†¬†¬† on the device. The list MUST identify the protocols and default
¬†¬†¬†¬†¬†¬† ports (if applicable) on which the services listen. It SHOULD
¬†¬†¬†¬†¬†¬† provide references to complete documentation describing the
¬†¬†¬†¬†¬†¬† service.

¬†¬†¬† Justification.

¬†¬†¬†¬†¬†¬† This information is necessary to enable a thorough assessment of
¬†¬†¬†¬†¬†¬† the potential security risks associated with the operation of each
¬†¬†¬†¬†¬†¬† service.

¬†¬†¬† Examples.

¬†¬†¬†¬†¬†¬† The list will likely contain network and transport protocols such
¬†¬†¬†¬†¬†¬† as IP, ICMP, TCP, UDP, routing protocols such as BGP and OSPF,
¬†¬†¬†¬†¬†¬† application protocols such as SSH and SNMP along with references
¬†¬†¬†¬†¬†¬† to the RFCs or other documentation describing the versions of the
¬†¬†¬†¬†¬†¬† protocols implemented.

¬†¬†¬†¬†¬†¬† Web servers "usually" listen on port 80. In the default
¬†¬†¬†¬†¬†¬† configuration of the device, it may have a web server listening on
¬†¬†¬†¬†¬†¬† port 8080. In the context of this requirement "identify ...
¬†¬†¬†¬†¬†¬† default port" would mean "port 8080".

¬†¬†¬† Warnings.

¬†¬†¬†¬†¬†¬† There may be valid, non-technical reasons for not disclosing the
¬†¬†¬†¬†¬†¬† specifications of proprietary protocols. In such cases, all that
¬†¬†¬†¬†¬†¬† needs to be disclosed is the existence of the service and the
¬†¬†¬†¬†¬†¬† default ports (if applicable).

3.2. Document Service Defaults

¬†¬†¬† Requirement.

¬†¬†¬†¬†¬†¬† The vendor MUST provide a list of the default state of all
¬†¬†¬†¬†¬†¬† services.

¬†¬†¬†¬†¬†¬† Understanding risk requires understanding exposure. Each service
¬†¬†¬†¬†¬†¬† that is enabled presents a certain level of exposure. Having a
¬†¬†¬†¬†¬†¬† list of the services that is enabled by default makes it possible
¬†¬†¬†¬†¬†¬† to perform meaningful risk analysis.

¬†¬†¬† Examples.

¬†¬†¬†¬†¬†¬† The list may be no more than the output of a command that
¬†¬†¬†¬†¬†¬† implements Section 2.5.1.

¬†¬†¬† Warnings.

¬†¬†¬†¬†¬†¬† None.

3.3. Document Service Activation Process

¬†¬†¬† Requirement.

¬†¬†¬†¬†¬†¬† The vendor MUST concisely document which features enable and
¬†¬†¬†¬†¬†¬† disable services.

¬†¬†¬† Justification.

¬†¬†¬†¬†¬†¬† Once risk has been assessed, this list provides the operator a
¬†¬†¬†¬†¬†¬† quick means of understanding how to disable (or enable) undesired
¬†¬†¬†¬†¬†¬† (or desired) services.

¬†¬†¬† Examples.

¬†¬†¬†¬†¬†¬† This may be a list of commands to enable/disable services one by
¬†¬†¬†¬†¬†¬† one or a single command which enables/disables "standard" groups
¬†¬†¬†¬†¬†¬† of commands.

¬†¬†¬† Warnings.

¬†¬†¬†¬†¬†¬† None.

3.4. Document Command Line Interface

¬†¬†¬† Requirement.

¬†¬†¬†¬†¬†¬† The vendor MUST provide complete documentation of the command line
¬†¬†¬†¬†¬†¬† interface with each software release. The documentation SHOULD
¬†¬†¬†¬†¬†¬† include highlights of changes from previous versions. The
¬†¬†¬†¬†¬†¬† documentation SHOULD list potential output for each command.
Jones Informational [Page 68]
¬†
RFC 3871 Operational Security Requirements September 2004
¬†¬†¬† Justification.

¬†¬†¬†¬†¬†¬† Understanding of inputs and outputs is necessary to support
¬†¬†¬†¬†¬†¬† scripting. See Section 2.4.2.

¬†¬†¬† Examples.

¬†¬†¬†¬†¬†¬† Separate documentation should be provided for each command listing
¬†¬†¬†¬†¬†¬† the syntax, parameters, options, etc. as well as expected output
¬†¬†¬†¬†¬†¬† (status, tables, etc.).

¬†¬†¬† Warnings.

¬†¬†¬†¬†¬†¬† None.

3.5. 'Console' Default Communication Profile Documented

¬†¬†¬† Requirement.

¬†¬†¬†¬†¬†¬† The console default profile of communications parameters MUST be
¬†¬†¬†¬†¬†¬† published in the system documentation.

¬†¬†¬† Justification.

¬†¬†¬†¬†¬†¬† Publication in the system documentation makes the settings
¬†¬†¬†¬†¬†¬† accessible. Failure to publish them could leave the operator
¬†¬†¬†¬†¬†¬† having to guess.

¬†¬†¬† Examples.

¬†¬†¬†¬†¬†¬† None.

¬†¬†¬† Warnings.

¬†¬†¬†¬†¬†¬† None.

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.

¬†¬†¬†¬†¬†¬† The vendor SHOULD 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.

¬†¬†¬†¬†¬†¬† "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.2. Identify Origin of Operating System

¬†¬†¬† Requirement.

¬†¬†¬†¬†¬†¬† The vendor SHOULD 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.

¬†¬†¬†¬†¬†¬† Security is the subject matter of this entire memo. The
¬†¬†¬†¬†¬†¬† justification section of each individual requirement lists the
¬†¬†¬†¬†¬†¬† security implications of meeting or not meeting the requirement.

¬†¬†¬† SNMP

¬†¬†¬†¬†¬†¬† SNMP versions prior to SNMPv3 did not include adequate security.
¬†¬†¬†¬†¬†¬† Even if the network itself is secure (for example by using IPSec),
¬†¬†¬†¬†¬†¬† even then, there is no control as to who on the secure network is
¬†¬†¬†¬†¬†¬† allowed to access and GET/SET (read/change/create/delete) the
¬†¬†¬†¬†¬†¬† objects in the MIB.

¬†¬†¬†¬†¬†¬† It is recommended that implementors consider the security features
¬†¬†¬†¬†¬†¬† as provided by the SNMPv3 framework (see [RFC3410], section 8),
¬†¬†¬†¬†¬†¬† including full support for the SNMPv3 cryptographic mechanisms
¬†¬†¬†¬†¬†¬† (for authentication and privacy).

¬†¬†¬†¬†¬†¬† Furthermore, deployment of SNMP versions prior to SNMPv3 is NOT
¬†¬†¬†¬†¬†¬† RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
¬†¬†¬†¬†¬†¬† enable cryptographic security. It is then a customer/operator
¬†¬†¬†¬†¬†¬† responsibility to ensure that the SNMP entity giving access to MIB
¬†¬†¬†¬†¬†¬† objects is properly configured to give access to the objects only
¬†¬†¬†¬†¬†¬† to those principals (users) that have legitimate rights to indeed
¬†¬†¬†¬†¬†¬† GET or SET (change/create/delete) them.

¬†¬†¬† 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 minimum set of
¬†¬†¬† requirements to which managed infrastructure of large IP networks
¬†¬†¬† should adhere.

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

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

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

¬†¬†¬† Copyright (C) The Internet Society (2004). This document is subject
¬†¬†¬† to the rights, licenses and restrictions contained in BCP 78, and
¬†¬†¬† except as set forth therein, the authors retain all their rights.

¬†¬†¬† This document and the information contained herein are provided on an
¬†¬†¬† "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
¬†¬†¬† OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
¬†¬†¬† ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
¬†¬†¬† INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
¬†¬†¬† INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
¬†¬†¬† WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

¬†¬†¬† The IETF takes no position regarding the validity or scope of any
¬†¬†¬† Intellectual Property Rights 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; nor does it represent that it has
¬†¬†¬† made any independent effort to identify any such rights. Information
¬†¬†¬† on the procedures with respect to rights in RFC documents can be
¬†¬†¬† found in BCP 78 and BCP 79.

¬†¬†¬† Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
¬†¬†¬† specification can be obtained from the IETF on-line IPR repository at
¬†¬†¬† http://www.ietf.org/ipr.

¬†¬†¬† The IETF invites any interested party to bring to its attention any
¬†¬†¬† copyrights, patents or patent applications, or other proprietary
¬†¬†¬† rights that may cover technology that may be required to implement
¬†¬†¬† this standard. Please address the information to the IETF at ietf-
¬†¬†¬† ipr@ietf.org.

Acknowledgement

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