None. G. Jones, Editor
Internet-Draft The MITRE Corporation
Expires: February 11, 2004 August 13, 2003
Operational Security Requirements for IP Network Infrastructure
draft-jones-opsec-01
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 except that the right to
produce derivative works is not granted.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 11, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document defines a list of operational security requirements for
the infrastructure large IP networks (such as routers and switches).
A framework is defined for specifying "profiles", which are
collections of requirements applicable to certain classes of devices.
The goal is to provide consumers of network equipment a clear,
concise way of communicating their security requirements to vendors
of such equipment. Please send any COMMENTS TO:
"opsec-comment@ops.ietf.org". ALSO SEE "http://www.port111.com/
opsec/opsec-meta.txt".
Jones, Editor Expires February 11, 2004 [Page 1]
Internet-Draft Operational Security Requirements August 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Definition of a Secure Network . . . . . . . . . . . . . . 5
1.4 Intended Audience . . . . . . . . . . . . . . . . . . . . 6
1.5 Format . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Intended Use . . . . . . . . . . . . . . . . . . . . . . . 7
1.7 Definitions . . . . . . . . . . . . . . . . . . . . . . . 7
2. Functional Requirements . . . . . . . . . . . . . . . . . 8
2.1 Device Management Requirements . . . . . . . . . . . . . . 8
2.1.1 Support Secure Management Channels . . . . . . . . . . . . 8
2.1.2 Support Remote Configuration Backup . . . . . . . . . . . 9
2.1.3 Support Remote Configuration Restore . . . . . . . . . . . 9
2.1.4 Support Management Over Slow Links . . . . . . . . . . . . 10
2.1.5 Support Scripting of Management Functions . . . . . . . . 10
2.1.6 Restrict Management to Local Interfaces . . . . . . . . . 11
2.2 In-Band Management Requirements . . . . . . . . . . . . . 11
2.2.1 Use Non-Proprietary Encryption . . . . . . . . . . . . . . 12
2.2.2 Use Strong Encryption . . . . . . . . . . . . . . . . . . 12
2.2.3 Key Management Must Be Scalable . . . . . . . . . . . . . 13
2.3 Out-of-Band (OoB) Management Requirements . . . . . . . . 13
2.3.1 Support Out-of-Band Management (OoB) Interfaces . . . . . 13
2.3.2 Enforce Separation of Data and Management Channels . . . . 14
2.3.3 Separation Not Achieved by Filtering . . . . . . . . . . . 14
2.3.4 No Forwarding Between Management and Data Planes . . . . . 15
2.4 User Interface Requirements . . . . . . . . . . . . . . . 15
2.4.1 Support Human-Readable Configuration File . . . . . . . . 15
2.4.2 Display of 'Sanitized' Configuration . . . . . . . . . . . 15
2.4.3 Display All Configuration Settings . . . . . . . . . . . . 16
2.5 IP Stack Requirements . . . . . . . . . . . . . . . . . . 17
2.5.1 Ability to Identify All Listening Services . . . . . . . . 17
2.5.2 Ability to Disable Any and All Services . . . . . . . . . 17
2.5.3 Ability to Control Service Bindings for Listening
Services . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.4 Ability to Control Service Source Address . . . . . . . . 18
2.5.5 Support Automatic Anti-spoofing for Single-Homed
Networks . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.6 Ability to Disable Processing of Packets Utilizing IP
Options . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.7 Directed Broadcasts Disabled by Default . . . . . . . . . 20
2.5.8 Support Denial-Of-Service (DoS) Tracking . . . . . . . . . 20
2.5.9 Traffic Monitoring . . . . . . . . . . . . . . . . . . . . 21
2.5.10 Traffic Sampling . . . . . . . . . . . . . . . . . . . . . 22
2.6 Rate Limiting Requirements . . . . . . . . . . . . . . . . 23
2.6.1 Support Rate Limiting . . . . . . . . . . . . . . . . . . 23
2.6.2 Support Rate Limiting Based on State . . . . . . . . . . . 24
Jones, Editor Expires February 11, 2004 [Page 2]
Internet-Draft Operational Security Requirements August 2003
2.7 Basic Filtering Capabilities . . . . . . . . . . . . . . . 24
2.7.1 Ability to Filter Traffic . . . . . . . . . . . . . . . . 24
2.7.2 Ability to Filter Traffic to the Device . . . . . . . . . 25
2.7.3 Ability to Filter Traffic Through the Device . . . . . . . 25
2.7.4 Ability to Filter Updates . . . . . . . . . . . . . . . . 25
2.7.5 Ability to Specify Filter Actions . . . . . . . . . . . . 26
2.7.6 Ability to Log Filter Actions . . . . . . . . . . . . . . 27
2.7.7 Ability to Filter Without Performance Degradation . . . . 27
2.8 Packet Filtering Criteria . . . . . . . . . . . . . . . . 28
2.8.1 Ability to Filter on Protocols . . . . . . . . . . . . . . 28
2.8.2 Ability to Filter on Addresses . . . . . . . . . . . . . . 28
2.8.3 Ability to Filter on Any Protocol Header Fields . . . . . 28
2.8.4 Ability to Filter Inbound and Outbound . . . . . . . . . . 29
2.8.5 Ability to Filter on Layer 2 MAC Addresses . . . . . . . . 29
2.9 Packet Filtering Counter Requirements . . . . . . . . . . 30
2.9.1 Ability to Accurately Count Filter Hits . . . . . . . . . 30
2.9.2 Ability to Display Filter Counters . . . . . . . . . . . . 30
2.9.3 Ability to Display Filter Counters per Rule . . . . . . . 31
2.9.4 Ability to Display Filter Counters per Filter
Application . . . . . . . . . . . . . . . . . . . . . . . 31
2.9.5 Ability to Reset Filter Counters . . . . . . . . . . . . . 32
2.9.6 Filter Counters Must Be Accurate . . . . . . . . . . . . . 32
2.10 Other Packet Filtering Requirements . . . . . . . . . . . 32
2.10.1 Filter, Counters, and Filter Log Performance Must Be
Usable . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.10.2 Ability to Specify Filter Log Granularity . . . . . . . . 33
2.11 Event Logging Requirements . . . . . . . . . . . . . . . . 34
2.11.1 Ability to Log All Events That Affect System Integrity . . 34
2.11.2 Logging Facility Conforms to Open Standards . . . . . . . 34
2.11.3 Ability to Log to Remote Server . . . . . . . . . . . . . 35
2.11.4 Ability to Select Reliable Delivery . . . . . . . . . . . 35
2.11.5 Ability to Log Locally . . . . . . . . . . . . . . . . . . 35
2.11.6 Ability to Maintain Accurate System Time . . . . . . . . . 36
2.11.7 Logs Must Be Timestamped . . . . . . . . . . . . . . . . . 36
2.11.8 Logs Contain Untranslated Addresses . . . . . . . . . . . 37
2.11.9 Logs Do Not Contain DNS Names by Default . . . . . . . . . 37
2.12 Authentication, Authorization, and Accounting (AAA)
Requirements . . . . . . . . . . . . . . . . . . . . . . . 38
2.12.1 Authenticate All User Access . . . . . . . . . . . . . . . 38
2.12.2 Support Authentication of Individual Users . . . . . . . . 38
2.12.3 Support Simultaneous Connections . . . . . . . . . . . . . 39
2.12.4 Ability to Disable All Local Accounts . . . . . . . . . . 39
2.12.5 Support Centralized User Authentication . . . . . . . . . 39
2.12.6 Support Local User Authentication . . . . . . . . . . . . 40
2.12.7 Support Configuration of Order of Authentication
Methods . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.12.8 Ability to Authenticate Without Reusable Plaintext
Passwords . . . . . . . . . . . . . . . . . . . . . . . . 41
Jones, Editor Expires February 11, 2004 [Page 3]
Internet-Draft Operational Security Requirements August 2003
2.12.9 No Default Static Authentication Tokens (Passwords) . . . 42
2.12.10 Static Authentication Tokens (Passwords) Must Be
Configured . . . . . . . . . . . . . . . . . . . . . . . . 42
2.12.11 Enforce Selection of Strong Local Static
Authentication Tokens (Passwords) . . . . . . . . . . . . 43
2.12.12 Support Device-to-Device Authentication . . . . . . . . . 43
2.12.13 Ability to Define Privilege Levels . . . . . . . . . . . . 44
2.12.14 Ability to Assign Privilege Levels to Users . . . . . . . 44
2.12.15 Default Privilege Level Must Be Read Only . . . . . . . . 45
2.12.16 Change in Privilege Levels Requires Re-Authentication . . 45
2.12.17 Accounting Records . . . . . . . . . . . . . . . . . . . . 45
2.13 Layer 2 Requirements . . . . . . . . . . . . . . . . . . . 46
2.13.1 Filtering MPLS LSRs . . . . . . . . . . . . . . . . . . . 46
2.13.2 VLAN Isolation . . . . . . . . . . . . . . . . . . . . . . 47
2.13.3 Layer 2 Denial-of-Service . . . . . . . . . . . . . . . . 47
2.13.4 Layer 3 Dependencies . . . . . . . . . . . . . . . . . . . 48
3. Documentation Requirements . . . . . . . . . . . . . . . . 49
3.1 Document Listening Services . . . . . . . . . . . . . . . 49
3.2 Provide a List of All Protocols Implemented . . . . . . . 49
3.3 Provide Documentation for All Protocols Implemented . . . 50
3.4 Catalog of Log Messages Available . . . . . . . . . . . . 50
4. Assurance Requirements . . . . . . . . . . . . . . . . . . 51
4.1 Ability to Withstand Well-Known Attacks and Exploits . . . 51
4.2 Vendor Responsiveness . . . . . . . . . . . . . . . . . . 52
4.3 Comply With Relevant IETF RFCs on All Protocols
Implemented . . . . . . . . . . . . . . . . . . . . . . . 52
4.4 Identify Origin of IP Stack . . . . . . . . . . . . . . . 54
4.5 Identify Origin of Operating System . . . . . . . . . . . 54
5. Security Considerations . . . . . . . . . . . . . . . . . 56
References . . . . . . . . . . . . . . . . . . . . . . . . 57
Author's Address . . . . . . . . . . . . . . . . . . . . . 58
A. Requirement Profiles . . . . . . . . . . . . . . . . . . . 59
A.1 Minimum Requirements Profile . . . . . . . . . . . . . . . 59
A.1.1 Functional Requirements . . . . . . . . . . . . . . . . . 59
A.1.2 Documentation Requirements . . . . . . . . . . . . . . . . 63
A.1.3 Assurance Requirements . . . . . . . . . . . . . . . . . . 63
A.2 Layer 3 Network Core Profile . . . . . . . . . . . . . . . 63
A.2.1 Functional Requirements . . . . . . . . . . . . . . . . . 63
A.3 Layer 3 Network Edge Profile . . . . . . . . . . . . . . . 63
A.3.1 Functional Requirements . . . . . . . . . . . . . . . . . 64
A.4 Layer 2 Network Core Profile . . . . . . . . . . . . . . . 64
A.4.1 Functional Requirements . . . . . . . . . . . . . . . . . 64
A.5 Layer 2 Edge Profile . . . . . . . . . . . . . . . . . . . 65
A.5.1 Functional Requirements . . . . . . . . . . . . . . . . . 65
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 66
Intellectual Property and Copyright Statements . . . . . . 67
Jones, Editor Expires February 11, 2004 [Page 4]
Internet-Draft Operational Security Requirements August 2003
1. Introduction
1.1 Goals
The goal of this document is to define a list of operational security
requirements for network infrastructure devices that implement
Internet Protocol (IP). The intent of the list is to provide
consumers of IP network infrastructure a clear, concise way of
communicating their security requirements to equipment vendors.
1.2 Scope
The primary scope of these requirements is intended to cover the
infrastructure of large IP networks (e.g. routers and switches).
Certain groups (or "profiles", see below) apply only in specific
situations (e.g. edge or core routers). The requirements listed in
the minimum profile are intended to apply to all managed
infrastructure devices.
General purpose hosts (including infrastructure hosts such as name/
time/log/AA servers, etc.), unmanaged, or customer managed devices
(e.g. firewalls, Intrusion Detection System, dedicated VPN devices,
etc.) are explicitly out of scope. This means that while the
requirements in the minimum profile (and others) may apply,
additional requirements will not be added to account for their unique
needs.
While, the examples given are written with IPv4 in mind, most of the
requirements are general enough to apply to IPv6.
1.3 Definition of a Secure Network
For the purposes of this document, a secure network is one in which:
o the network keeps passing legitimate customer traffic
(availability)
o traffic goes where it's supposed to go (availability)
o the network elements remain manageable (availability)
o only authorized users can manage network elements (authorization)
o there is record of all security related events (accountability)
o the network operator has the necessary tools to detect and respond
to illegitimate traffic
Jones, Editor Expires February 11, 2004 [Page 5]
Internet-Draft Operational Security Requirements August 2003
Confidentiality and integrity of customer data are outside the scope.
1.4 Intended Audience
There are two intended audiences: the end user (consumer) who
selects, purchases, and operates IP network equipment, and the
vendors who create them.
1.5 Format
The individual requirements are listed in one of the three sections
listed below.
o Section 2 lists functional requirements.
o Section 3 lists documentation requirements.
o Section 4 lists assurance requirements.
Within these areas, requirements are grouped in major functional
areas (e.g., logging, authentication, filtering, etc.)
Each requirement has the following subsections:
o The Requirement (What)
o The Justification (Why)
o Examples (How)
o Warnings (if applicable)
The requirement describes a policy to be supported by the device. The
justification tells why and in what context the requirement is
important. The examples section is intended to give examples of
implementations that may meet the requirement. Examples cite
technology and standards current at the time of this writing. It is
expected that the choice of implementations to meet the requirements
will change over time. The warnings list operational concerns,
deviation from standards, caveats, etc.
Security requirements will vary across different device types and
different organizations, depending on policy and other factors. A
desired feature in one environment may be a requirement in another.
Classifications must be made according to local need.
In order to assist in classification, the Appendix Appendix A defines
several requirement "profiles" for different types of devices.
Jones, Editor Expires February 11, 2004 [Page 6]
Internet-Draft Operational Security Requirements August 2003
Profiles are simply collections of requirements. They provide a
concise list of the requirements that apply to certain classes of
devices. The profiles in this document should be reviewed to
determine if they are appropriate the local environment.
1.6 Intended Use
It is anticipated that this document will be used in the following
manners:
Security Capability Checklist The requirements in this document may
be used as a checklist when evaluating networked products.
Composing Profiles Different subsets of these requirements may be
compiled to describe the needs of different devices,
organizations, and operating environments.
Communicating Requirements This document may be referenced, along
with profiles, to clearly communicate security requirements.
Basis For Testing and Certification This document may form the basis
for testing and certification of security features of networked
products.
1.7 Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Unless otherwise indicated, "IP" refers to IPv4
Jones, Editor Expires February 11, 2004 [Page 7]
Internet-Draft Operational Security Requirements August 2003
2. Functional Requirements
The requirements in this section are intended to list testable,
functional requirements that are needed to operate devices securely.
2.1 Device Management Requirements
2.1.1 Support Secure Management Channels
Requirement. The device MUST provide secure end-to-end channels for
all network traffic and protocols used to support management
functions. This MUST include at least protocols used for
configuration, monitoring, configuration backup, logging, time
synchronization, authentication, and routing. This requirement MAY
be satisfied using either In-Band or Out-of-Band management. See
Section 2.2 and Section 2.3.
Justification. Secure channels ensure confidentiality and integrity
of management traffic.
Examples. Secure channels are most commonly implemented using
encryption...one can imagine other secure channels, such as
shielded cable run in tamper-evident conduit monitored by armed
guards... but in most cases "secure channel" will mean encryption.
See [ANSI.T1.276-200x] for a discussion of appropriate algorithms.
The following table shows examples of the security requirements
for different classes of protocols. The rows list different
classes of protocols. The columns show the required security
attributes. The attributes are: Confidentiality (Conf.),
Integrity (Integ.), User-to-Device Authentication (Auth. U2D), and
Device-to-Device Authentication (Auth D2D).:
+---------------+-------+-------+-------+-------+
| Type | Conf. | Integ.| Auth. | Auth. |
| Protocol(s) | | | U2D | D2D |
+---------------+-------+-------+-------+-------+
| Management | X | X | X | |
| telnet, HTTP| | | | |
| FTP, | | | | |
+---------------+-------+-------+-------+-------+
| Management | X | X | | X |
| TFTP,SNMP | | | | |
+---------------+-------+-------+-------+-------+
| Logging | X | X | | X |
| Syslog | | | | |
| | | | | |
+---------------+-------+-------+-------+-------+
Jones, Editor Expires February 11, 2004 [Page 8]
Internet-Draft Operational Security Requirements August 2003
| Time | | | | |
| NTP | | X | | X |
| | | | | |
+---------------+-------+-------+-------+-------+
| AAA | | | | |
| TACACS, | | | | |
| RADIUS, | X | X | X | X |
| DIAMETER, | | | | |
| Kerberos, | | | | |
+---------------+-------+-------+-------+-------+
| Routing | | | | |
| BGP,OSPF, | | X | | X |
| RIP | | | | |
+---------------+-------+-------+-------+-------+
Warnings. None.
2.1.2 Support Remote Configuration Backup
Requirement. The device MUST provide a means to store the system
configuration to a remote server. The stored configuration MUST
have sufficient information to restore the device to its
operational state at the time the configuration is saved.
Justification. Archived configurations are essential to enable
auditing and recovery.
Examples. Possible implementations include SCP 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.1.3 Support Remote Configuration Restore
Requirement. The device MUST provide a means to restore a
configuration that was saved as described in Section 2.1.2. The
system MUST be restored to its operational state at the time the
configuration was.
Justification. Restoration of archived configurations allows quick
restoration of service following an outage (security related as
well as from other causes).
Jones, Editor Expires February 11, 2004 [Page 9]
Internet-Draft Operational Security Requirements August 2003
Examples. Configurations may be restored using SCP 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.1.4 Support Management Over Slow Links
Requirement. The device MUST provide a management interface that
enables management over low bandwidth links (e.g., modem or serial
port)
Justification. This is important because it is often necessary to
manage remote devices for which high bandwidth access is not
available.
Examples. A consistent command line interface is one possible
implementation of this requirement. An open, well-defined,
scriptable management protocol is another.
Warnings. None.
2.1.5 Support Scripting of Management Functions
Requirement. The device MUST support scripting of management
functions that:
* Has a simple, regular syntax
* Allows complete access to all management functions
* Works consistently on both in-band and out-of-band interfaces
* Utilizes existing authentication methods
* Support scripts running on external systems
* Support the use of multiple common scripting languages
The scripting function MUST NOT
* be a text-based menu, windowing system, or GUI.
* require the use of a scripting language on the device itself.
Jones, Editor Expires February 11, 2004 [Page 10]
Internet-Draft Operational Security Requirements August 2003
Justification. Scripting support is important for configuration
fetching, auditing, attack tracking, automated administration,
etc.
Examples. A consistent command line interface is one possible
implementation of this requirement. An open, well-defined,
scriptable management protocol is another. An example of this
would be the work currently being done by the netconf working
group ([netconf].) Perl, Expect and TCL would be some current
examples of scripting languages.
Warnings. None.
2.1.6 Restrict Management to Local Interfaces
Requirement. The device MUST have the ability to restrict management
traffic to sources within one hop of the device in cases where
management done over IP.
Justification. Restricting management traffic to devices attached
locally reduces the risk of unauthorized configuration of the
device from across the Internet.
This requirement applies primarily to SOHO equipment, where
out-of-band management may not be feasible, and additional
security for management traffic is most effectively applied by
restricting it to local only.
Examples. This requirement MAY be satisfied by reducing the TTL on
return TCP management traffic to 1, or by filtering all traffic to
the management service not sourced from local subnets.
Warnings. Restricting management to locally attached devices only is
not desirable for devices intended for use primarily by large
organizations.
2.2 In-Band Management Requirements
This section lists security requirements for devices that are managed
In-band. "In-band management" is defined as any management done over
the same channels and interfaces used for user/customer data.
In-band management has the advantage of lower cost (no extra
interfaces or lines), but has significant security disadvantages:
o saturation of customer lines or interfaces can make the device
unmanageable
Jones, Editor Expires February 11, 2004 [Page 11]
Internet-Draft Operational Security Requirements August 2003
o since public interfaces/channels are used, it is possible for
attackers to directly address and reach the device and to attempt
management functions
o in-band management traffic on public interfaces may be intercepted
o Since the same networking code and interfaces are shared for
management and customer data, it is not possible to isolate
management functions from failures in other areas (for example, a
"magic packet" or buffer overrun that causes the data forwarding
portions of a router to crash will also likely make it impossible
to manage...this would not necessarily be the case if the
management and data forwarding elements were completely separated)
2.2.1 Use Non-Proprietary Encryption
Requirement. If encryption is used to satisfy the Section 2.1.1
requirements, then the encryption algorithms used MUST be
non-proprietary. See [ANSI.T1.276-200x]
Justification. Proprietary encryption algorithms and protocols that
have not been subjected to public/peer review are more likely to
have undiscovered weaknesses or flaws than open standards and
publicly reviewed algorithms.
Examples. None.
Warnings. None.
2.2.2 Use Strong Encryption
Requirement. If encryption is used to satisfy the Section 2.1.1
requirements, then the key lengths and algorithms MUST be "strong"
by current definitions.
Justification. Short keys and weak algorithms threaten the
confidentiality and integrity of communications.
Examples. [ANSI.T1.276-200x] provides a list of acceptable key
lengths for various types of encryption algorithms at the time of
this writing.
Warnings. "Strong" is a relative term. Long keys and strong
algorithms are intended to increase the work factor required to
compromise the security of the data protected. Over time, as
processing power increases, the security provided by a given
Jones, Editor Expires February 11, 2004 [Page 12]
Internet-Draft Operational Security Requirements August 2003
algorithm and key length will degrade. The definition of "Strong"
must be constantly reevaluated. There may be legal issues
governing the use of encryption and the strength of encryption
used.
2.2.3 Key Management Must Be Scalable
Requirement. The number of keys and passwords that must be managed to
support other requirements in this document MUST scale well.
Specifically, The number of keys and passwords managed MUST
increase, at most, linearly as the number of devices and users.
Justification. In large networks, or in networks with large number of
users, the key/password space could quickly grow to unmanageable
size, inhibiting proper management and making audits difficult if
not impossible.
Examples. [Ed. insert verbiage about PKIs, etc. Contributions to
this space solicited.] See Section 2.1.1.
Warnings. [Ed. insert verbiage about PKIs, etc. Contributions to
this space solicited]
2.3 Out-of-Band (OoB) Management Requirements
See Section 2.2 for a discussion of the advantages and disadvantages
of In-band vs. Out-of-Band management.
2.3.1 Support Out-of-Band Management (OoB) Interfaces
Requirement. The device MUST provide an interface for management
access that is never used by non-management traffic.
Justification. This is allows all management of the device to be done
via separate control channels and thus reduce the risk that
unauthorized individuals will be able to observe management
traffic and/or compromise the device.
This requirement applies in situations where a separate OoB
management network exists or other OoB access mechanisms (e.g.,
modems) are used to provide secure remote management.
Examples. This requirement MAY be satisfied with a serial console
port or a separate network interface, such as an Ethernet port.
Jones, Editor Expires February 11, 2004 [Page 13]
Internet-Draft Operational Security Requirements August 2003
Warnings. OoB management may not be required or feasible in all
situations: for instance; if remote management is not a
requirement.
2.3.2 Enforce Separation of Data and Management Channels
Requirement. The device MUST support separation of data and
management channels. It MUST support complete physical and logical
separation of management and non-management traffic.
Justification. Separation of management and data channels enables the
application of separate and appropriate controls to each channel,
and reduces the possibility that a vulnerability in one area/
environment (data forwarding) could have an adverse impact on
another area (control/management). For example, imagine that a
"killer packet" or buffer overrun is discovered that allows
arbitrary users of a public network to crash the data forwarding
elements of a router. If data forwarding and management elements
are separated, it is likely that the management elements will
continue to function, allowing the network operator to evaluate
and respond to the problem. If they are not separated (e.g., they
both use the same interfaces and share an operating system and IP
stack), then it is likely that the entire device will crash or
become unmanageable.
Examples. This requirement may be satisfied by supporting OoB
management interfaces per Section 2.3.1 and supporting the ability
to disable all protocols that support management functions (e.g.,
telnet, FTP, TFTP, SSH, SNMP, HTTP, etc.) on all non-management
ports.
Warnings. None.
2.3.3 Separation Not Achieved by Filtering
Requirement. The requirements to enforce separation of data and
control channels SHALL NOT be satisfied using a filtering
mechanism alone.
Justification. Filters do not guarantee internal separation of
traffic.
Examples. None.
Jones, Editor Expires February 11, 2004 [Page 14]
Internet-Draft Operational Security Requirements August 2003
Warnings. None.
2.3.4 No Forwarding Between Management and Data Planes
Requirement. It MUST NOT be possible to forward data between data
plane and management plane.
Justification. This is to ensure that it is impossible to route
packets to the management interface through the publicly
accessible ports on the device.
Examples. One way of meeting this requirement would be to have
completely separate IP stacks and forwarding tables for management
and non-management interfaces and to prohibit propagation of
routing information between the two forwarding tables.
Warnings. None.
2.4 User Interface Requirements
2.4.1 Support Human-Readable Configuration File
Requirement. The device MUST provide a means to remotely save a copy
of the system configuration file(s) in a human-readable form. It
MUST NOT be necessary to use a proprietary program to view the
configuration. The configuration MUST also be viewable in human
readable form on the device itself.
Justification. Having configurations in human-readable format is
necessary to enable off-line audits of the system configuration.
Having them in simple, non-proprietary formats also facilitates
automation of configuration checking.
Examples. A simple text-based configuration file would satisfy this
requirement.
Warnings. Offline copies of configurations should be well protected
as they often contain sensitive information such as SNMP community
strings, passwords, network blocks, customer information, etc.
2.4.2 Display of 'Sanitized' Configuration
Requirement. The device MUST support the display of a "sanitized"
configuration in which all sensitive information that appears in
the system configuration must be replaced with innocuous data.
Jones, Editor Expires February 11, 2004 [Page 15]
Internet-Draft Operational Security Requirements August 2003
Justification. This is necessary to allow safe distribution and
analysis of configurations.
Examples. Some examples of "sensitive information" include:
* system passwords
* usernames and passwords
* shared secrets (RADIUS, TACACS, IKE, VPN, SNMP, NTP, routing
protocols, etc.)
* Private keys
* All IP addresses and blocks.
* System names
* Domain names
* Comments
* Banners
* User defined data (filter names, SNMP profile names, etc.)
* Contact information (snmp server, contact, location info, etc.)
One simple way of obscuring the information would be to replace it
with "***"s or similar characters in the display of the device
configuration.
Warnings. Some information may be "sensitive" in some situations, but
not in others. Passwords are clearly sensitive. Other
information in configurations that may be considered sensitive
could include: IP addresses on particular interfaces (one way of
obscuring these might be to replace the first octet with "10." in
all cases), the name of the device, comments, banners, addresses
of peers/upstream devices, addresses of logging devices, AAA
servers, NTP servers, etc.
2.4.3 Display All Configuration Settings
Requirement. The device MUST provide a mechanism to display a
complete listing of all possible configuration settings and their
current values. This MUST include values for any "hidden"
commands. It MUST be possible to display all values, even those
Jones, Editor Expires February 11, 2004 [Page 16]
Internet-Draft Operational Security Requirements August 2003
that are disabled, "off," or set to default values.
Justification. It is not possible to perform thorough audits without
a complete listing of all possible configuration settings and
their current values.
Examples. None.
Warnings. It has been stated that it may be unreasonable to expect
vendors to expose all settings, as this would lead to confusion
due to customers changing settings that did not apply to their
situation, and could drive up support costs.
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 interfaces on which each service is listening.
* Include both open standard and vendor proprietary services.
Justification. This information is necessary to enable a thorough
assessment of the security risks associated with the operation of
the device (e.g., "does this protocol allow complete management of
the device without also requiring authentication, authorization,
or accounting"?). The information also assists in determining
what steps should be taken to mitigate risk (e.g., "should I turn
this service off "?)
Examples. If, for example, the device is listening for SNMP on all
interfaces, then this requirement could be met by the provision of
a command which displays that fact.
Warnings. None.
2.5.2 Ability to Disable Any and All Services
Requirement. The device MUST provide a means to turn off any external
services listening.
Jones, Editor Expires February 11, 2004 [Page 17]
Internet-Draft Operational Security Requirements August 2003
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 a list of addresses and netblocks and SHOULD support
configuration of binding services to particular interfaces,
including loopback addresses.
Justification. This greatly reduces the need for complex filters. It
reduces the number of ports listening, and thus the number of
potential avenues of attack. It ensures that only traffic
arriving from legitimate addresses and/or on designated interfaces
can access services on the device.
Examples. The default configuration as displayed by Section 2.4.3
should list all interfaces and all potential services along with
the ports they listen to, the addresses they listen to, and the
interfaces they bind to. These should all be made configurable.
Warnings. None.
2.5.4 Ability to Control Service Source Address
Requirement. The device MUST provide a means that allows the user to
specify the source address used for all outbound connections or
transmissions originating from the device. It MUST be possible to
specify source addresses independently for each type of outbound
connection or transmission. Source addresses MUST be limited to
addresses that are assigned to interfaces (including loopbacks)
local to the device.
Justification. This allows remote devices receiving connections or
transmissions to use source filtering as one means of
authentication. For example, if SNMP traps were configured to use
a known loopback address as their source, the SNMP workstation
receiving the traps (or a firewall in front of it) could be
configured to receive SNMP packets only from that address.
Jones, Editor Expires February 11, 2004 [Page 18]
Internet-Draft Operational Security Requirements August 2003
Examples. None.
Warnings. None.
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 and MUST provide an
option to automatically apply anti-spoofing to such interfaces.
This option MUST work in the presence of dynamic routing and
dynamically assigned addresses. It MUST NOT negatively impact
performance. It MUST provide accurate counts of spoofed packets
that were dropped with logging options. It SHOULD be possible to
apply the option to an interface with a single command. For the
purposes of this requirement a "single-homed network" is defined
as one for which
* There is only one (logical) upstream connection
* Routing is symmetric
A "spoofed packet" is defined as a "packet having a source address
that, by application of the current forwarding tables, would not
have its return traffic routed back through the interface on which
it was received."
Justification. See [RFC2867] Network Ingress Filtering.
Examples. This requirement could be satisfied in several ways. It
could be satisfied by the provision of a single command that
automatically generates and applies filters to an interface that
implements anti-spoofing. It could be satisfied by the provision
of a command that causes the return path for packets received to
be checked against the current routing tables and dropped if they
would not be forwarded back through the interface on which they
were received.
Warnings. None.
2.5.6 Ability to Disable Processing of Packets Utilizing IP Options
Requirement. The device MUST provide a means to disable processing of
all packets utilizing IP Options. This option MUST be available
on a per-interface basis. It MUST be possible to individually
configure which options are processed. Source routing SHOULD be
disabled by default.
Jones, Editor Expires February 11, 2004 [Page 19]
Internet-Draft Operational Security Requirements August 2003
Justification. Options can be used to alter normal traffic flows and
thus circumvent network-based access control mechanisms (such as
firewalls). They can also be used to provide information (such as
routes taken) that could be useful to an attacker mapping a
network.
Examples. None.
Warnings. RFC791 says "The Options provide for control functions
needed or useful in some situations but unnecessary for the most
common communications... [options] must be implemented by all IP
modules (host and gateways). What is optional is their
transmission in any particular datagram, not their implementation"
2.5.7 Directed Broadcasts Disabled by Default
Requirement. The default configuration of the device MUST ensure
that:
* It will not respond to any directed broadcasts to any broadcast
domains of which it is a member.
* It will not propagate any directed broadcasts to any broadcast
domains to which it is directly connected.
There SHOULD be a mechanism to re-enable directed broadcasts on a
per-interface basis.
Justification. Directed broadcasts have few legitimate uses in modern
networks and are easily abused to amplify denial of service
attacks (e.g., SMURF attacks). [RFC2644] recommends the same
change in default settings as a Best Current Practice.
Examples. None.
Warnings. The requirement is in violation of [RFC1812].
2.5.8 Support Denial-Of-Service (DoS) Tracking
Requirement. The device MUST include native "spoofed" packet
tracking. This feature:
* MUST be able to capture data to a tracking table that shows how
many packets match a configurable layer 3/4 header pattern or
list of patterns from each previous hop router.
Jones, Editor Expires February 11, 2004 [Page 20]
Internet-Draft Operational Security Requirements August 2003
* MUST display the interface on which a matching packet arrived.
* MUST display the layer-2 header information. arrived.
* MUST implement "unknown source" as an optional part of the
header pattern where "unknown" is the set of all addresses that
are unreachable by the router (i.e., not in the forwarding
table).
* MUST be able to display the tracking table showing the pattern
that is being tracked and how many matches were received from
each previous hop.
This feature MUST be implemented with minimal impact to system
performance.
Justification. This applies in situations where DoS attacks, possibly
utilizing spoofed source addresses, must be tracked across one or
more routers. Without the capability to track DoS packets, it is
possible that an attacker could adversely impact the availability
of resources (hosts, routers, network links, etc.) leaving network
administrators little to no capability to track and stop the
attack. Layer 2 header information is particularly useful for
identifying spoofed sources coming in over an Ethernet interface
at a peering point and you want to track the source back to a
particular ISP so you can ask them to trace the source.
Examples.
These features must allow the customer to quickly and easily ask
the router which packets matching a given profile came into the
router, from where, and how many from each source.
Note that this requirement MAY be satisfied by implementing the
requirements listed in Section 2.7.1
Warnings. None.
2.5.9 Traffic Monitoring
Requirement. The device MUST provide a means to monitor selected
traffic through the system. It MUST provide the ability to select
specific traffic patterns for monitoring based on arbitrary IP
header patterns and layer 4 (TCP and UDP) header patterns. This
includes: source and destination IP address, IP header flags,
layer 4 source and destination ports (TCP, UDP), ICMP type and
code fields, and other IP protocol types (e.g., 50 - ESP, 47 -
Jones, Editor Expires February 11, 2004 [Page 21]
Internet-Draft Operational Security Requirements August 2003
GRE, etc.). It MUST provide the ability to monitor the full
contents of the packets. This feature MUST be implemented with
minimal impact on system performance. In addition, the device MUST
provide a means to remotely capture the data being monitored.
Justification. This requirement applies in contexts where traffic
headers and content must be monitored. This enables
characterization of malicious (and non-malicious) traffic, which
may be essential to enable effective response and maintain normal
operations.
Examples.
The addition of any traffic monitoring facility must be
implemented with minimal impact on system performance. See Section
2.1.1 for requirements related to secure communication channels
for management protocols and data.
Remote capture of header data could be implemented by sending it
via syslog or SNMP. For the full packet capture, the device may
send this information over the network for small data streams, or
provide a "port mirroring" capability for large data streams where
the data would be duplicated out a second configurable port.
Warnings. Monitoring data can add significant network traffic,
processor, and memory use.
2.5.10 Traffic Sampling
NOTE: there is a proposed IETF working group active in this area. See
the mailing list archives at https://ops.ietf.org/lists/psamp/. It is
possible this section may just reference the product of that working
group.
Requirement. The device MUST provide a means to sample traffic
through the system and summarize data from the layer 3 and 4
headers.
It MUST be possible to dump the cache at specified intervals to a
collection host. It MUST be possible to specify device behavior
when the cache is full. Options SHOULD include: dumping the cache
to the specified collection host(s), clearing the cache,
overwriting the cache, and disabling further sampling. The cache
SHOULD be implemented as a circular buffer such that older entries
are overwritten first. The device SHOULD provide options to
manually dump or clear the cache.
Jones, Editor Expires February 11, 2004 [Page 22]
Internet-Draft Operational Security Requirements August 2003
The device SHOULD provide a means of summarizing sampled data.
The following IP layer header information SHOULD be summarized
appropriately: type of service (or DS field), total length,
protocol, source, and destination. The following TCP/UDP header
information SHOULD be summarized appropriately: source port,
destination port, UDP packet length, TCP header length, and TCP
flag bits.
The device MUST provide the ability to select the traffic-sampling
rate. For instance, there MUST be a way to sample every nth
packet, where n is a number determined by an authorized user and
entered into the system configuration file. This feature must be
implemented with minimal impact on system performance.
Justification. This requirement enables accurate characterization of
data transiting the device. This supports identification of and
response to malicious traffic.
Examples. This requirement MAY be satisfied by allowing the user to
specify that 1 in every N packets should be sampled. See Section
2.1.1 for requirements related to secure communication channels
for management protocols and data.
Warnings. Traffic sampling can add significant network traffic,
processor, and memory use.
2.6 Rate Limiting Requirements
2.6.1 Support Rate Limiting
Requirement. The device MUST provide the capability to limit the rate
at which it will pass traffic based on protocol, port, and
interface: and to rate-limit input and/or output separately on
each interface. It SHOULD allow filtering on any protocol and
MUST allow filtering on at least IP, ICMP, UDP, and TCP. This
feature SHOULD be implemented with minimal impact to system
performance.
Justification. This requirement provides a means of reducing or
eliminating the impact of certain types of attacks.
Examples. Assume that a web hosting company provides space in its
data-center to a company that becomes unpopular with a certain
element of network users, who then decide to flood the web server
with inbound ICMP traffic. It would be useful in such a situation
to be able to rate-filter inbound ICMP traffic at the
data-center's border routers. On the other side, assume that a
Jones, Editor Expires February 11, 2004 [Page 23]
Internet-Draft Operational Security Requirements August 2003
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.
Warnings. None.
2.6.2 Support Rate Limiting Based on State
Requirement. For stateful protocols it SHOULD be possible to rate
limit traffic based on session state.
Justification. This allows appropriate response to certain classes of
attack.
Examples. For example, for TCP sessions, it should be possible to
rate limit based on the SYN, SYN-ACK, RST, or other bit state.
Warnings. None.
2.7 Basic Filtering Capabilities
2.7.1 Ability to Filter Traffic
Requirement. The device MUST provide a means to filter IP packets on
any interface implementing IP.
In this document a "filter" is defined as a group of one or more
rules where each rule specifies one or more match criteria as
specified in Section 2.8.
Also see the specific filtering requirements that follow this one.
Justification. Packet filtering is important because it provides a
basic means of implementing policies that specify which traffic is
allowed and which is not. It also provides a basic tool for
responding to malicious traffic.
Jones, Editor Expires February 11, 2004 [Page 24]
Internet-Draft Operational Security Requirements August 2003
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 is important because it allows filters to be
applied that protect the device itself from attacks and
unauthorized access.
Examples. Examples of this might include filters that permit only
SNMP and SSH traffic from an authorized management segment
directed to the device itself, while dropping all other traffic
addressed to the device.
Warnings. None.
2.7.3 Ability to Filter Traffic Through the Device
Requirement. It MUST be possible to apply the filtering mechanism to
traffic that is being routed (switched) through the device.
Justification. This is important because it permits implementation of
basic policies on devices that carry transit traffic (routers,
switches, firewalls, etc.).
Examples. One simple and common way to meet this requirement is to
provide the ability to filter traffic inbound to each interface
and/or outbound from each interface. Ingress filtering as
described in [RFC2827] provides one example of the use of this
capability.
Warnings. None.
2.7.4 Ability to Filter Updates
Requirement. The device MUST provide a means to filter updates for
all protocols that could be used to update operational
characteristics of the device. Note that it MUST be possible to
Jones, Editor Expires February 11, 2004 [Page 25]
Internet-Draft Operational Security Requirements August 2003
specify a filter that disables all updates.
This requirement MAY be satisfied through the use of filters as
described in Section 2.7.1 and/or with mechanisms specific to each
protocol. Also note that update filtering is required in addition
to secure channels (Section 2.1.1) and authentication (Section
2.12)
Justification. Without the ability to filter protocols used for
management and operational updates, unauthorized users might be
able to change operational parameters (e.g., routing tables,
passwords, etc.) and/or completely disable the device.
Examples. This should include the ability to:
* Filter routing protocol updates
* Disable SNMP writing completely
* Filter addresses permitted to manage the device regardless of
protocol (SNMP,SSH,TELNET,HTTP,TFTP,SNMP...)
Warnings. None.
2.7.5 Ability to Specify Filter Actions
Requirement. The device MUST provide a mechanism to allow the
specification of the action to be taken when a filter rule
matches. Actions must include "permit" (allow the traffic),
"reject" (drop with appropriate notification to sender), and
"drop" (drop with no notification to sender). Also see Section
2.7.6 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.
Jones, Editor Expires February 11, 2004 [Page 26]
Internet-Draft Operational Security Requirements August 2003
Warnings. [Ed. Does "drop" with no ICMP unreachable violate any RFCs
?]
2.7.6 Ability to Log Filter Actions
Requirement.
It MUST be possible to log all filter actions. The logging
capability MUST be able to capture at least the following data:
permit/deny/drop status, source and destination ports, source and
destination IP address, which network element forwarded the packet
(interface, MAC address or other layer 2 information that
identifies the previous hop source of the packet), and time-stamp
to millisecond accuracy.
Logging of filter actions is subject to the requirements of
Section 2.11.
Justification. Logging is essential for auditing, incident response,
and operations.
Examples. A desktop network may not provide any services that should
be accessible from "outside." In such cases, all inbound
connection attempts should be logged as possible intrusion
attempts.
Warnings. None.
2.7.7 Ability to Filter Without Performance Degradation
Requirement. The device MUST provide a means to filter packets
without performance degradation. The device MUST be able to filter
on ALL interfaces (up to the maximum number possible)
simultaneously and with multiple filters per interface (e.g.,
inbound and outbound).
Justification. This is important because it enables the
implementation of filtering wherever and whenever needed. To the
extent that filtering causes degradation, it may not be possible
to apply filters that implement the appropriate policies.
Examples. Another way of stating the requirement is that filter
performance should not be the limiting factor in device
throughput. If a device is capable of forwarding, say, 30Mb/sec
without filtering, then it should be able to forward the same
amount with filtering in place. This requirement most likely
Jones, Editor Expires February 11, 2004 [Page 27]
Internet-Draft Operational Security Requirements August 2003
implies a hardware-based solution (ASIC).
Warnings. Without hardware based filtering, it may be possible for
the implementation of filters to degrade the performance of the
device or to cause it to cease functioning.
2.8 Packet Filtering Criteria
2.8.1 Ability to Filter on Protocols
Requirement. The device MUST provide a means to filter traffic based
on protocol.
Justification. Being able to filter on protocol is necessary to allow
implementation of policy, secure operations and for support of
incident response.
Examples. Some denial of service attacks are based on the ability to
flood the victim with ICMP traffic. One quick way (admittedly
with some negative side effects) to mitigate the effects of such
attacks is to drop all ICMP traffic headed toward the victim.
Warnings. None.
2.8.2 Ability to Filter on Addresses
Requirement. The function MUST be able to control the flow of traffic
based on source and/or destination IP address or blocks of
addresses such as Classless Inter-Domain Routing (CIDR) blocks.
Justification. The capability to filter on addresses and address
blocks is a fundamental tool for establishing boundaries between
different networks.
Examples. One example of the use of address based filtering is to
implement ingress filtering per [RFC2827].
Warnings. None.
2.8.3 Ability to Filter on Any Protocol Header Fields
Requirement. The filtering mechanism MUST support filtering based on
the value(s) of any portion of the protocol headers.
Jones, Editor Expires February 11, 2004 [Page 28]
Internet-Draft Operational Security Requirements August 2003
Justification. Being able to filter on portions of the header is
necessary to allow implementation of policy, secure operations,
and support incident response.
Examples. For example, this requirement implies that it is possible
to filter based on TCP or UDP port numbers, TCP flags such as SYN,
ACK and RST bits, and ICMP type and code fields. One common
example is to reject "inbound" TCP connection attempts (TCP, SYN
bit set). Another common example is the ability to control what
services are allowed in/out of a network. For example, it may be
desirable to only allow inbound connections on port 80 (HTTP) and
443 (HTTPS) to a network hosting web servers.
Warnings. None.
2.8.4 Ability to Filter Inbound and Outbound
Requirement. It MUST be possible to filter both incoming and outgoing
traffic on any interface.
Justification. This requirement allows flexibility in applying
filters at the place that makes the most sense. It allows invalid
or malicious traffic to be dropped as close to the source as
possible.
Examples. It might be desirable on a border router, for example, to
apply an egress filter outbound on the interface that connects a
site to its external ISP to drop outbound traffic that does not
have a valid internal source address. Inbound, it might be
desirable to apply a filter that blocks all traffic from a site
that is known to forward or originate lots of junk mail.
Warnings. None.
2.8.5 Ability to Filter on Layer 2 MAC Addresses
Requirement. Filters in layer 2 devices MUST be able to filter based
on Media Access Control (MAC) addresses.
Justification. This provides a level of control that may be needed to
enforce policy and respond to malicious activity.
Examples. Policy may require, for example, that personal systems not
be allowed to connect to the internal desktop network. Restricting
the MAC addresses on a port is one way of enforcing this.
Jones, Editor Expires February 11, 2004 [Page 29]
Internet-Draft Operational Security Requirements August 2003
Warnings. None.
2.9 Packet Filtering Counter Requirements
2.9.1 Ability to Accurately Count Filter Hits
Requirement. The device MUST supply a facility for accurately
counting all filter hits.
Justification. Accurate counting of filter rule matches is important
because it shows the magnitude/frequency of attempts to violate
policy. This enables resources to be focused on areas of greatest
need.
Examples. Assume, for example, that a ISP network implements
anti-spoofing egress filters (see [RFC2827]) on interfaces of its
edge routers that support single-homed stub networks. Counters
could enable the ISP to detect cases where large numbers of
spoofed packets are being sent. This may indicate that the
customer is performing potentially malicious actions (possibly in
violation of the IPS's Acceptable Use Policy), or that system(s)
on the customers network have been "owned" by hackers and are
being (mis)used to launch attacks.
Warnings. None.
2.9.2 Ability to Display Filter Counters
Requirement. The device MUST provide a mechanism to display filter
counters.
Justification. Information that is collected is not useful unless it
can be displayed in a useful manner.
Examples. Assume there is a router with four interfaces. One is an
up-link to an ISP providing routes to the Internet. The other
three connect to separate internal networks. Assume that a host
on one of the internal networks has been compromised by a hacker
and is sending traffic with bogus source addresses. In such a
situation, it might be desirable to apply ingress filters to each
of the internal interfaces. Once the filters are in place, the
counters can be examined to determine the source (inbound
interface) of the bogus packets.
Jones, Editor Expires February 11, 2004 [Page 30]
Internet-Draft Operational Security Requirements August 2003
Warnings. None.
2.9.3 Ability to Display Filter Counters per Rule
Requirement. The device MUST provide a mechanism to display filter
counters per rule.
Justification. This makes it possible to see which rules are matching
and how frequently.
Examples. Assume that a filter has been defined that has two rules,
one permitting all SSH traffic (tcp/22) and the second dropping
all remaining traffic. If three packets are directed toward/
through the point at which the filter is applied, one to port 22,
the others to different ports, then the counter display should
show 1 packet matching the permit tcp/22 rule and 2 packets
matching the deny all others rule.
Warnings. None.
2.9.4 Ability to Display Filter Counters per Filter Application
Requirement. If it is possible for a filter to be applied more than
once at the same time, then the device MUST provide a mechanism to
display filter counters per filter application.
Justification. It may make sense to apply the same filter definition
simultaneously more than one time (to different interfaces, etc.).
If so, it would be much more useful to know which instance of a
filter is matching than to know that some instance was matching
somewhere.
Examples. One way to implement this requirement would be to have the
counter display mechanism show the interface (or other entity) to
which the filter has been applied, along with the name (or other
designator) for the filter. For example if a filter named
"desktop_outbound" applied two different interfaces, say,
"ethernet0" and "ethernet1," the display should indicate something
like "matches of filter 'desktop_outbound' on ethernet0 ..." and
"matches of filter 'desktop_outbound' on ethernet1 ..."
Warnings. None.
Jones, Editor Expires February 11, 2004 [Page 31]
Internet-Draft Operational Security Requirements August 2003
2.9.5 Ability to Reset Filter Counters
Requirement. It MUST be possible to reset counters to zero on a per
filter basis.
Justification. This allows operators to get a current picture of the
traffic matching particular rules/filters.
Examples. Assume that filter counters are being used to detect
internal hosts that are infected with a new worm. Once it is
believed that all infected hosts have been cleaned up and the worm
removed, the next step would be to verify that. One way of doing
so would be to reset the filter counters to zero and see if
traffic indicative of the worm has ceased.
Warnings. None.
2.9.6 Filter Counters Must Be Accurate
Requirement. Filter counters MUST be accurate. They MUST reflect
the actual number of matching packets since the last counter
reset.
Justification. Inaccurate data can not be relied on as the basis for
action. Underreported data can conceal the magnitude of a problem.
Examples. If N packets matching a filter are sent to/through a
device, then the counter should show N matches.
Warnings. None.
2.10 Other Packet Filtering Requirements
2.10.1 Filter, Counters, and Filter Log Performance Must Be Usable
Requirement. Filtering, logging, and counting functionality MUST be
implemented such that they are usable, from a performance
standpoint, in situations where they are the logical solution.
Justification. The possibility of severe performance degradation in
the use of filtering, logging, or counting would reduce their
utility. Fear of adverse operational consequences might cause
operators to limit or discard their use completely in situations
where they are needed.
Jones, Editor Expires February 11, 2004 [Page 32]
Internet-Draft Operational Security Requirements August 2003
Examples.
Assume, for example, that a new worm is released that scans random
IP addresses looking for services listening on TCP port 1433. An
operator might want to investigate to see if any of the hosts on
their networks were infected and trying to spread the worm. One
way to do this would be to put up non-blocking filters counting
and logging the number of outbound connection 1433, and then to
block the requests that are determined to be from infected hosts.
If any of these capabilities (filtering, counting, logging) have
the potential to impose severe performance penalties, then this
otherwise rational course of action might not be possible.
Some examples of things that would make the logging features
unusable might include situations where their use:
* crashes the device
* consumes excessive resources (CPU, memory, bandwidth)
* makes the device unmanageable
* causes the loss of data
Warnings.
While there are some objective measures that indicate clearly when
a feature is unusable (its use crashes the device), "usability" is
largely a subjective term. Lab tests may be constructed to
determine how well the device behaves under certain loads, but the
ultimate test of usability for filtering, counting and logging
will come under live, quite possibly heavy, loads.
2.10.2 Ability to Specify Filter Log Granularity
Requirement. It MUST be possible to enable/disable logging on a per
rule basis.
Justification. The ability to tune the granularity of logging allows
the operator to log only the information that is desired. Without
this capability, it is possible that extra data (or none at all)
wold be logged, making it more difficult to find relevant
information.
Examples. If a filter is defined that has several rules, and one of
the rules denies telnet (tcp/23) connections, then it should be
possible to specify that only matches on the rule that denies
Jones, Editor Expires February 11, 2004 [Page 33]
Internet-Draft Operational Security Requirements August 2003
telnet should generate a log message.
Warnings. None.
2.11 Event Logging Requirements
2.11.1 Ability to Log All Events That Affect System Integrity
Requirement. The logging facility MUST be capable of logging any
event that affects system integrity.
Justification. Having the device log all events that might impact
system integrity promotes accountability and enables
audit-ability.
Examples.
The list of items that must be logged includes, but is not limited
to, the following events:
* Filter matches, described in Section 2.7.6
* Authentication failures (e.g., bad login attempts)
* Authentication successes (e.g., user logins)
* Authorization changes (e.g., User privilege level changes)
* Configuration changes (e.g., command accounting)
* Device status changes (interface up/down, etc.)
Warnings. None.
2.11.2 Logging Facility Conforms to Open Standards
Requirement. The device MUST provide a logging facility that conforms
to open standards. Custom/Proprietary log protocols MAY be
implemented provided the same information is made available via
logging facilities that conform to open standards.
Justification. The use of open standards logging is important because
it permits the customer to perform archival and analysis of logs
without relying on vendor-supplied software and servers.
Jones, Editor Expires February 11, 2004 [Page 34]
Internet-Draft Operational Security Requirements August 2003
Examples. [RFC3195] meets this requirement. The use of SNMP traps may
also satisfy this requirement.
Warnings. While [RFC3164] and SNMP may satisfy this requirement, they
both fail to satisfy several other logging requirements.
2.11.3 Ability to Log to Remote Server
Requirement. The device MUST be capable of logging to a remote
server. It SHOULD be able to log to multiple servers.
Justification. External logging allows the storage of large,
persistent logs that may not be possible with local (on the
device) logging.
Examples. One example of a remote log server would be a host running
a syslog server. See [RFC3164].
Warnings. High volumes of logging may generate excessive network
traffic and/or compete for scarce memory and CPU resources on the
device.
2.11.4 Ability to Select Reliable Delivery
Requirement. It MUST be possible to select reliable, sequenced
delivery of log messages between device sending the message and
server receiving the message.
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.
Warnings. None.
2.11.5 Ability to Log Locally
Requirement.
Jones, Editor Expires February 11, 2004 [Page 35]
Internet-Draft Operational Security Requirements August 2003
It SHOULD be possible to log locally on the device itself.
Justification. Local logging is important for viewing information
when connected to the device. It provides some backup of log data
in case remote logging fails. It provides a way to view logs
relevant to one device without having to sort through a possibly
large set of logs from other devices.
Examples. One example of local logging would be a memory buffer that
receives copies of messages sent to the remote log server.
Another example might be a local syslog server (assuming the
device is capable of running syslog and has some local storage).
Warnings. Storage on the device may be limited. High volumes of
logging may quickly fill available storage, in which case there
are two options: new logs overwrite old logs (possibly via the use
of a circular memory buffer or log file rotation), or logging
stops.
2.11.6 Ability to Maintain Accurate System Time
Requirement. The device MUST maintain accurate, high resolution
system time. All displays of system time MUST include a timezone.
The default timezone SHOULD be UTC or GMT. The device SHOULD
support a mechanism to allow the operator to specify the timezone
for local system time.
Justification. This is important because the system clock is used for
time-stamping log messages.
Examples. This requirement MAY be satisfied by supporting Network
Time Protocol (NTP). See Section 2.1.1 for requirements related to
secure communication channels for management protocols and data.
Warnings. System clock chips are inaccurate to varying degrees.
System time should not be relied upon unless it is regularly
checked and synchronized with a known, accurate external time
source (such as an NTP stratum-1 server).
2.11.7 Logs Must Be Timestamped
Requirement. The device MUST time-stamp all log messages. The
time-stamp MUST be accurate to within a second or less. The
time-stamp MUST include a timezone.
Jones, Editor Expires February 11, 2004 [Page 36]
Internet-Draft Operational Security Requirements August 2003
Justification. This is important because accurate timestamps are
necessary for correlating events, particularly across multiple
devices or with other organizations. This applies when it is
necessary to analyze logs.
Examples. This requirement MAY be satisfied by writing timestamps
into syslog messages.
Warnings. It is difficult to correlate logs from different time
zones. Security events on the Internet often involve machines and
logs from a variety of physical locations. For that reason, UTC
is preferred, all other things being equal.
2.11.8 Logs Contain Untranslated Addresses
Requirement. Log messages MUST contain relevant IP addresses.
Justification. It is important to include IP address of access list
violation logs, authentication attempts. This enables a level of
individual and organizational accountability and is necessary to
enable analysis of network events, incidents, policy violations,
etc.
Examples. None.
Warnings.
* Source addresses may be spoofed. Network-based attacks often
use spoofed source addresses. Source addresses should not be
completely trusted unless verified by means.
* Addresses may be reassigned to different individual, for
example, in a desktop environment using DHCP. In such cases the
individual accountability afforded by this requirement is weak.
* Network topologies may change. Even in the absence of dynamic
address assignment, network topologies and address block
assignments do change. Logs of an attack one month ago may not
give an accurate indication of which host, network or
organization owned the system(s) in question at the time.
2.11.9 Logs Do Not Contain DNS Names by Default
Requirement. By default, log messages MUST NOT contain DNS names
resolved at the time the message was generated. The device MAY
provide a facility to incorporate translated DNS names in addition
Jones, Editor Expires February 11, 2004 [Page 37]
Internet-Draft Operational Security Requirements August 2003
to the IP address.
Justification. This is important because IP to DNS mappings change
over time and mappings done at one point in time may not be valid
later. Also, the use of the resources (memory, processor, time,
bandwidth) required to do the translation could result in *no*
data being sent/logged, and, in the extreme case could lead to
degraded performance and/or resource exhaustion.
Examples. None.
Warnings. DNS name translation can impose significant performance
delays.
2.12 Authentication, Authorization, and Accounting (AAA) Requirements
2.12.1 Authenticate All User Access
Requirement. The device MUST provide a facility to perform
authentication of all user access to the system.
Justification. This functionality is required so that access to the
system can be restricted to authorized personnel.
Examples. This requirement MAY be satisfied by implementing a
centralized authentication system. See Section 2.12.5. It MAY
also be satisfied using local authentication. See Section 2.12.6
Warnings. None.
2.12.2 Support Authentication of Individual Users
Requirement. Each authentication mechanism supported by the device
MUST support the authentication of distinct, individual users.
Justification. The use of individual accounts, in conjunction with
logging, promotes accountability. The use of group or default
accounts undermines individual accountability.
Examples. The implementation depends on the types of authentication
supported by the device. Local usernames and passwords are one
possibility. Centralized authentication servers using usernames
and onetime passwords is another.
Jones, Editor Expires February 11, 2004 [Page 38]
Internet-Draft Operational Security Requirements August 2003
Warnings. This simply requires that the mechanism to support
individual users be present. Policy (e.g., forbidding shared
group accounts) and enforcement are also needed but beyond the
scope of this document.
2.12.3 Support Simultaneous Connections
Requirement. The device SHOULD support multiple simultaneous
connections by distinct users, possibly at different authorization
levels.
Justification. This allows multiple people to perform authorized
management functions simultaneously.
Examples. None.
Warnings. None.
2.12.4 Ability to Disable All Local Accounts
Requirement. The device MUST provide a means of disabling all local
accounts including:
* Local users
* Default accounts (vendor, maintenance, guest...)
* Privileged and unprivileged accounts
Justification. Default accounts, well-know accounts, and old accounts
provide easy targets for someone attempting to gain access to a
device. It must be possible to disable them to reduce the
potential vulnerability.
Examples. The implementation depends on the types of authentication
supported by the device.
Warnings. None.
2.12.5 Support Centralized User Authentication
Requirement. The device MUST support centralized authentication of
all user access via standard authentication protocols.
Jones, Editor Expires February 11, 2004 [Page 39]
Internet-Draft Operational Security Requirements August 2003
Justification. Support for centralized authentication is particularly
important in large environments where the network devices are
widely distributed and where many people have access to them. This
reduces the effort needed to effectively restrict and track access
to the system by authorized personnel.
Examples. This requirement MAY be satisfied by implementing Terminal
Access Controller Access Control System Plus (TACACS+), Remote
Authentication Dial-In User Service (RADIUS), or Kerberos 5. See
Section 2.1.1 for requirements related to secure communication
channels for management protocols and data.
Warnings. None.
2.12.6 Support Local User Authentication
Requirement. The device MAY support local authentication.
Justification. Support for local authentication may be required in
smaller environments where there may be only a few devices and a
limited number of people with access. The overhead of maintaining
centralized authentication servers may not be justified.
Examples. The use of local, per-device usernames and passwords
provides one way to implement this requirement.
Warnings. Authentication information must be protected wherever it
resides. Having, for instance, local usernames and passwords
stored on 100 network devices means that there are 100 potential
points of failure where the information could be compromised vs.
storing authentication data centralized server(s), which would
reduce the potential points of failure to the number of servers
and allow protection efforts (system hardening, audits, etc.) to
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.
Justification. This allows the operator flexibility in implementing
appropriate security policies that balance operational and
security needs.
Jones, Editor Expires February 11, 2004 [Page 40]
Internet-Draft Operational Security Requirements August 2003
Examples. If, for example, a device supports RADIUS authentication
and local usernames and passwords, it should be possible to
specify that RADIUS authentication should be attempted if the
servers are available, and that local usernames and passwords
should be used for authentication only if the RADIUS servers are
not available. Similarly, it should be possible to specify that
only RADIUS or only local authentication be used.
Warnings. None.
2.12.8 Ability to Authenticate Without Reusable Plaintext Passwords
Requirement. The device MUST perform authentication without the
transmission of reusable plain-text passwords across a network.
The implementation:
* MUST NOT cause significant performance degradation
* MUST NOT require additional devices (e.g., encryption cards,
etc.)
* MUST scale well/be supportable on large numbers of devices
(e.g., the number of keys and configuration settings that need
to be managed should increase at most linearly as the number of
devices).
This requirement MAY be satisfied by tunneling protocols that use
plain-text passwords over secure channels per Section 2.1.1.
Justification. Reusable plain-text passwords can easily be observed
using packet sniffers on shared networks. Mechanisms that impose
too high of an overhead or are not manageable will not be used.
This requirement specifically precludes the use of reusable
passwords with standard telnet without being carried over a secure
channel (see Section 2.1.1) for device management. It does allow
the use of standard telnet with one time passwords. Note that this
does not preclude the use of extra hardware; it simply says that
additional hardware (smart cards, encryption cards, etc.) must not
be required to support authentication without the use of clear
text passwords. See [RFC1704] for a through discussion of the
issues.
Examples. None.
Warnings. None.
Jones, Editor Expires February 11, 2004 [Page 41]
Internet-Draft Operational Security Requirements August 2003
2.12.9 No Default Static Authentication Tokens (Passwords)
Requirement. The initial configuration of the device MUST NOT contain
any default passwords or similar static authentication tokens.
"Similar static authentication tokens" includes any form of shared
secret, public or private key.
Justification. Default passwords provide an easy way for attackers to
gain unauthorized access to the device.
Examples. Passwords such as the name of the vendor, device, "default"
etc. are easily guessed. The SNMP community strings "public" and
"private" are well known defaults that provide read and write
access to devices.
Warnings. Lists of default passwords for various devices are readily
available at numerous websites.
2.12.10 Static Authentication Tokens (Passwords) Must Be Configured
Requirement. The device MUST require the operator to explicitly
configure passwords and similar static authentication tokens.
"Similar authentication tokens" includes any form of shared
secret, public or private key.
Justification. This requirement is intended to prevent unauthorized
management access. Requiring the operator to explicitly configure
passwords will tend to have the effect of ensuring a diversity of
passwords. It also shifts the responsibility for password
selection to the user.
Examples. Assume that a device comes with console port for management
and a default administrative account. This requirement together
with No Default Static Authentication Tokens (Passwords) says that
the administrative account should come with no password
configured. One way of meeting this requirement would be to have
the device require the operator to choose a password for the
administrative account as part of a dialog the first time the
device is configured.
Warnings. While this device requires operators to set passwords, it
does not prevent them from doing things such as using scripts to
configure 100s of devices with the same easily guessed passwords.
Jones, Editor Expires February 11, 2004 [Page 42]
Internet-Draft Operational Security Requirements August 2003
2.12.11 Enforce Selection of Strong Local Static Authentication Tokens
(Passwords)
Requirement. Strength checks for static passwords fall into three
types:
1. computational checks against the password itself (length,
character set, upper/lower case)
2. comparison checks against static data sets (dictionary tests)
3. comparison checks against dynamic data sets (history checks,
username tests)
The device MUST support at least computational checks with the
following minimum requirements: The password MUST be at least [6]
characters long and MUST contain at least [3] of the following
elements
The device MAY enforce the selection of "strong" local passwords
through comparison checks against dynamic and/or static data sets.
Justification. Trivial passwords are easily guessed, increasing the
likelihood of unauthorized access.
Examples. An initial configuration dialog may require the user to set
a password to control initial access. If the user enters a
password that is not strong (e.g. "123") then the configuration
dialog should inform the user that the chosen password is weak and
provide another opportunity to select a strong password.
Warnings.
2.12.12 Support Device-to-Device Authentication
Requirement. The device MUST support device-to-device authentication
for all non-interactive management protocols. Also see Section
2.12.8 and Section 2.1.1
Justification. This is required to allow automated management
functions to operate with a reasonable level assurance that
updates and sharing of management information is occurring only
with authorized devices.
Examples. Examples of protocols that implement device to device
authentication are: SNMP (community strings), NTP and BGP (shared
keys).
Jones, Editor Expires February 11, 2004 [Page 43]
Internet-Draft Operational Security Requirements August 2003
Warnings. None.
2.12.13 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.14
Justification. This requirement supports the implementation of the
principal of "least privilege", which states that an individual
should only have the privileges necessary to execute the
operations he/she is required to perform.
Examples. Examples of privilege levels might include "default," which
allows read-only access to device configuration and operational
statistics, "root/superuser/administrator" which allows update
access to all configurable parameters, and "operator" which allows
updates to a limited, user defined set of parameters. Note that
privilege levels may be defined locally on the device or on
centralized authentication servers.
Warnings. None.
2.12.14 Ability to Assign Privilege Levels to Users
Requirement. The device MUST be able to assign a defined set of
authorized functions, or "privilege level," to each user once they
have authenticated themselves the device. Privilege level
determines which functions a user is allowed to execute. Also
see See Section 2.12.13.
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. So for
example, if RADIUS is used, an attribute could be set in the
user's RADIUS profile that can be used to map the ID to a certain
privilege level.
Warnings. None.
Jones, Editor Expires February 11, 2004 [Page 44]
Internet-Draft Operational Security Requirements August 2003
2.12.15 Default Privilege Level Must Be Read Only
Requirement. The default privilege level MUST only allow read access
to device settings and operational parameters.
Justification. This requirement supports the implementation of the
principal of "least privilege," which states that an individual
should only have the privileges necessary to execute the
operations he/she is required to perform.
Examples. None.
Warnings. None.
2.12.16 Change in Privilege Levels Requires Re-Authentication
Requirement. The device MUST re-authenticate a user prior to granting
any change in user authorizations.
Justification. This requirement insures that users are able to
perform only authorized actions.
Examples. This requirement might be implemented by assigning base
privilege levels to all users and allowing the user to request
additional privileges, with the requests validated by the AAA
server.
Warnings. None.
2.12.17 Accounting Records
Requirement. The device MUST be able to store a record of at least
the following events:
* Failed logins
* Successful logins
* All Commands executed by the user during their session,
including via the management/serial port and interactions with
an underlying OS (e.g., Unix "shell" commands)
* Change in privilege level
* All logouts
Jones, Editor Expires February 11, 2004 [Page 45]
Internet-Draft Operational Security Requirements August 2003
The device MUST support transmission of accounting records to one
or more remote devices. There MUST be configuration settings on
the device that allow selection of servers.
Justification. This is important because it supports individual
accountability by providing a record of changes that were made and
who made them. It is important to store them on a separate server
to preserve them in case of failure or compromise of the managed
device.
Examples. This requirement MAY be satisfied by the use of
RADIUS,TACACS+, or syslog. See Section 2.1.1 for requirements
related to secure communication channels for management protocols
and data.
Warnings. Syslog is known to be unreliable/lossy during network
transmission (due to use of UDP). It has also been observed that
some devices lose a significant number of UDP packets before they
are ever transmitted, due (apparently) to low prioritization of
the internal processing of UDP packets. Similar problems have
been observed in various syslog servers (syslogd on UNIX systems).
Bottom line: be aware that syslog data may be lost at one of
several points.
2.13 Layer 2 Requirements
2.13.1 Filtering MPLS LSRs
Requirement. The device MUST provide a method to filter packets based
on layer 3 and 4 criteria on Label Switch Routers (LSRs)
regardless of whether they are encapsulated using Multi Protocol
Label Switching (MPLS). The MPLS encapsulated packets MUST NOT be
allowed to bypass IP filters. Logging facilities MUST provide
sufficient information so that the previous hop for a logged
packet can be determined. Packets tagged with MPLS labels MUST be
treated as IP packets when crossing an interface on which a filter
is applied. Encapsulation/decapsulation MAY take place before or
after the filter as long as it does not cause the filters to be
ignored. When logging the input interface information for hits on
outgoing filter list rules, any MPLS label that was present when
the packet was received MUST be logged with the input interface.
This functionality is equivalent to the requirement that all layer
2 source information must be logged when the input interface is
logged. Also, the addition of any filtering and logging MUST be
implemented with no significant performance degradation to the
normal system operations.
Jones, Editor Expires February 11, 2004 [Page 46]
Internet-Draft Operational Security Requirements August 2003
Justification. This is important because it may be necessary to
filter traffic encapsulated in a LSP. This applies primarily to
backbone and large core networks.
Examples. None.
Warnings. None.
2.13.2 VLAN Isolation
Requirement. The device MUST NOT allow VLAN Hopping. This applies to
the insertion of falsified VLAN IDs or 802.1Q (or equivalent) tags
into frames in an attempt to hop from one VLAN to another while
traversing the switch. Many VLAN implementations allow hopping if
the native VLAN (usually VLAN 1) is set up as the trunk port. If
this is the case then the default configuration on the switch MUST
NOT allow the trunk port to be set as the native VLAN. Also the
switch MUST NOT broadcast ARP requests across VLANs.
Justification. This requirement is intended to ensure that layer 2
traffic remains isolated to designated VLANs. It applies in
situations where data on different VLAN segments have different
sensitivity classification.
Examples. None.
Warnings. None.
2.13.3 Layer 2 Denial-of-Service
Requirement. It MUST NOT be possible for users connected to a switch
port to perform an action which results in denial of service to
other users connected to the switch. Examples of denial of service
would include:
* Causing the switch to crash
* Causing long delays (e.g., by forcing spanning tree
recalculations)
* Redirecting/stealing traffic
Justification. This requirement is needed to ensure the
confidentiality and availability of data transmitted via the
switch.
Jones, Editor Expires February 11, 2004 [Page 47]
Internet-Draft Operational Security Requirements August 2003
Examples. None.
Warnings. None.
2.13.4 Layer 3 Dependencies
Requirement. If a device provides layer 2 services that are dependent
on layer 3 or greater services, then the portions that operate at
layer 3 MUST conform to the layer 3 security requirements listed
in this document where appropriate. For example, signaling
protocols required for layer 2 switching may exchange information
with other devices using layer 3 communications. The device must
provide a secure layer 3 facility.
Justification. All layer 3 devices have similar security needs and
should be subject to similar requirements.
Examples. None.
Warnings. None.
Jones, Editor Expires February 11, 2004 [Page 48]
Internet-Draft Operational Security Requirements August 2003
3. Documentation Requirements
The requirements in this section are intended to list information
that will assist operators in evaluating and securely operating a
device.
3.1 Document Listening Services
Requirement. The vendor MUST:
* Provide a documented explanation for all network services that
may be active on the system.
* Concisely document which features enable listening ports on the
device.
* List which services are on by default.
This information MUST be provided in a single, contiguous section
of the documentation. This list MUST include both open standard
and vendor proprietary services.
Justification. This information is necessary to enable a thorough
assessment of the security risks associated with the operation of
the device (e.g., "does this protocol allow complete management of
the device without also requiring authentication, authorization,
or accounting"?). The information also assists in determining
what steps should be taken to mitigate risk (e.g., "should I turn
this service off "?)
Examples. This documentation should include at least a list of all
possible network services that could be activated to listen on any
TCP and/or UDP port, or any vendor-proprietary port/protocol.
Warnings. None.
3.2 Provide a List of All Protocols Implemented
Requirement. The vendor SHOULD provide a concise list all protocols
implemented by the device.
Justification. This facilitates thorough and appropriately targeted
testing.
Examples. None.
Jones, Editor Expires February 11, 2004 [Page 49]
Internet-Draft Operational Security Requirements August 2003
Warnings. None.
3.3 Provide Documentation for All Protocols Implemented
Requirement. The vendor SHOULD provide references to publicly
available specifications for all protocols implemented.
Justification. Security thorough obscurity is bad policy. Closed,
undocumented protocols that have not undergone through public
review may contain undiscovered (by the vendor) vulnerabilities
that can easily be exploited. Open, documented protocols
facilitate thorough and appropriately targeted testing.
Examples. None.
Warnings. It is acknowledged that there may be valid business or
other non-technical reasons for not releasing documentation for
protocols, This requirement should be evaluated on a case-by-case
basis.
3.4 Catalog of Log Messages Available
Requirement. The vendor SHOULD specify a catalog of all messages that
a device can emit. This SHOULD be included with every release of
software for the device.
Justification. A complete catalog of all possible messages permits
the customer to automate response to possible events.
Examples. None.
Warnings. None.
Jones, Editor Expires February 11, 2004 [Page 50]
Internet-Draft Operational Security Requirements August 2003
4. Assurance Requirements
The requirements in this section are intended to
o identify behaviors and information that will increase confidence
that the device will meet the security functional requirements.
o Provide information that will assist evaluation
4.1 Ability to Withstand Well-Known Attacks and Exploits
Requirement. The vendor SHOULD provide software updates or
configuration advice "in a timely fashion" to mitigate the effect
of "well know vulnerabilities" in the device itself and "well
known exploits" directed to the device.
For the purpose of this document, well-known vulnerabilities and
exploits are defined as those that have been published by the
following:
* Computer Emergency Response Team Coordination Center [CERT/CC]
Advisories
* Common Vulnerabilities and Exposures [CVE] entries
* Standard Nessus [Nessus] Plugins
* Vendor security bulletins for the device in question.
* The [PROTOS] test suite
While "in a timely fashion" is open to interpretation, one
measurable, customer-centric metric is "before the vulnerability
is exploited in my device causing loss of confidentiality,
integrity or availability".
Justification. Product vulnerabilities and tools to exploit
vulnerabilities are all constantly evolving. A configuration that
is secure one day may be insecure the next due to the discovery of
a new vulnerability or the release of a new exploit script.
Devices that are vulnerable to known exploits may be easily
compromised or disabled. This can affect confidentiality,
availability, and data integrity.
Examples. Take for example the SNMP vulnerabilities described in
[CERT.2002-03]. These vulnerabilities were discovered and a
toolkit for exploiting them was publicly released. What this
Jones, Editor Expires February 11, 2004 [Page 51]
Internet-Draft Operational Security Requirements August 2003
requirement is saying is that known vulnerabilities such as this
should be fixed.
It is up to the customer/operator to verify to their satisfaction
that the system is "bug free" and free of known exploits. Some
possible methods of doing this include
* Taking the vendors word
* Testing for themselves
* Relying on 3rd party testing/certification
Warnings. It is acknowledged that the number of known vulnerabilities
is constantly expanding and that it is not possible to prove that
any system is completely bug and vulnerability free. Any test or
"certification" of a device to show compliance with this
requirement will be an approximation at a point in time. The most
that can be shown is that a given list of exploits failed.
4.2 Vendor Responsiveness
Requirement. The vendor MUST be responsive to current and future
security requirements as specified by the customer. When new
security exploits are discovered, either by the customer or the
public, the vendor MUST provide patches or workarounds in a timely
fashion to mitigate the threat from any existing vulnerability in
the system. The vendor MUST ensure that it remains actively aware
of security threats.
Justification. This is important because new vulnerabilities are
regularly discovered. Slow vendor response to vulnerabilities
increase the level of risk/window of opportunity for exploit. This
requirement applies to ALL devices.
Examples. This is a non-technical requirement. The implementation
involves process, customer support, engineering, etc.
Warnings. This "requirement" has a large element of subjectivity.
When evaluating vendor responsiveness, objective data (such as
mean time to releasing patches for new exploits) should be
evaluated.
4.3 Comply With Relevant IETF RFCs on All Protocols Implemented
Jones, Editor Expires February 11, 2004 [Page 52]
Internet-Draft Operational Security Requirements August 2003
Requirement. The default configuration of the device MUST fully
comply with IETF RFCs for all protocols implemented. "Compliance"
is defined in terms of [RFC2119]. The device MUST conform to the
absolute requirements. Any optional or recommended functionality
implemented MUST be in conformance with the RFC. The device MAY
provide means by which it can be configured in ways that are not
compliant with the RFCs (for instance, if conformance is
determined to be insecure).
Justification. A device must first perform its primary function
correctly. Once it is proven to perform its primary function, it
makes sense to ask if it does/can perform securely. For Internet
connected devices, compliance with RFCs provides a minimum level
of assurance that the device will function as intended and
interoperate as part of an operational network. Failure to comply
with RFCs calls correct functioning into question and makes the
determination of secure functioning a secondary concern.
Examples. Some of the relevant RFCs include:
ICMP.
[RFC0792] INTERNET CONTROL MESSAGE PROTOCOL
[RFC1812] Requirements for IP Version 4 Routers
IP.
[RFC0791] INTERNET PROTOCOL
[RFC0922] BROADCASTING INTERNET DATAGRAMS IN THE PRESENCE OF
SUBNETS
[RFC1812] Requirements for IP Version 4 Routers
[RFC1858] Security Considerations for IP Fragment Filtering
[RFC2644] Changing the Default for Directed Broadcasts in
Routers
[RFC2827] Network Ingress Filtering
TCP.
[RFC0793] TRANSMISSION CONTROL PROTOCOL
Jones, Editor Expires February 11, 2004 [Page 53]
Internet-Draft Operational Security Requirements August 2003
[RFC1858] Security Considerations for IP Fragment Filtering
[RFC1948] Defending Against Sequence Number Attacks
UDP.
[RFC0768] User Datagram Protocol
[RFC1122] Requirements for Internet Hosts -- Communication
Layers
[RFC1812] Requirements for IP Version 4 Routers
Warnings. None.
4.4 Identify Origin of IP Stack
Requirement. The vendor MUST disclose the origin or basis of the IP
stack used on the system.
Justification. This information is required to better understand the
possible security vulnerabilities that may be inherent in the IP
stack.
Examples. For example, "The IP stack was derived from BSD 4.4," or
"The IP stack was implemented from scratch."
Warnings. Many IP stacks make simplifying assumptions about how an IP
packet should be formed. A malformed packet can cause unexpected
behavior in the device, such as a system crash or buffer overflow
which could result in unauthorized access to the system.
4.5 Identify Origin of Operating System
Requirement. The vendor MUST disclose the origin or basis of the
operating system (OS).
Justification. This information is required to better understand the
security vulnerabilities that may be inherent to the OS based on
its origin.
Examples. For example, "The operating system is based on Linux kernel
2.4.18."
Jones, Editor Expires February 11, 2004 [Page 54]
Internet-Draft Operational Security Requirements August 2003
Warnings. None.
Jones, Editor Expires February 11, 2004 [Page 55]
Internet-Draft Operational Security Requirements August 2003
5. Security Considerations
Security is the subject matter of this entire memo. It might be more
appropriate to list operational considerations. Operational issues
are mentioned as needed in the examples and warnings sections of each
requirement.
Jones, Editor Expires February 11, 2004 [Page 56]
Internet-Draft Operational Security Requirements August 2003
References
[ANSI.T1.276-200x]
American National Standards Institute (ANSI),
"T1.276-200x: Draft proposed American National Standard
for Telecommunications Operations, Administration,
Maintenance, and Provisioning Security Requirements for
the Public Telecommunications Network: A Baseline of
Security Requirements for the Management Plane", April
2003.
[Bugtraq] SecurityFocus/Symantec, "Bugtraq mailing list", 2003,
<http://www.securityfocus.com/archive/1>.
[CERT.2002-03]
CERT/CC, "Multiple Vulnerabilities in Many Implementations
of the Simple Network Management Protocol (SNMP)", 2002,
<http://www.cert.org/advisories/CA-2002-03.html>.
[CERT/CC] CERT/CC, "CERT/CC Advisories", 2003, <http://www.cert.org/
advisories/>.
[CVE] The MITRE Corporation, "MITRE Common Vulnerabilities and
Exposures", 2003, <http://www.cve.mitre.org>.
[Nessus] Deraison, R., "Nessus Security Scanner", 2003, <http://
www.nessus.org>.
[PROTOS] University of Oulu, "PROTOS Test Suites", 2003, <http://
www.ee.oulu.fi/research/ouspg/protos/>.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC0922] Mogul, J., "Broadcasting Internet datagrams in the
presence of subnets", STD 5, RFC 922, October 1984.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
Jones, Editor Expires February 11, 2004 [Page 57]
Internet-Draft Operational Security Requirements August 2003
[RFC1704] Haller, N. and R. Atkinson, "On Internet Authentication",
RFC 1704, October 1994.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[RFC1858] Ziemba, G., Reed, D. and P. Traina, "Security
Considerations for IP Fragment Filtering", RFC 1858,
October 1995.
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",
RFC 1948, May 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2644] Senie, D., "Changing the Default for Directed Broadcasts
in Routers", BCP 34, RFC 2644, August 1999.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2867] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
Modifications for Tunnel Protocol Support", RFC 2867, June
2000.
[RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August
2001.
[RFC3195] New, D. and M. Rose, "Reliable Delivery for syslog", RFC
3195, November 2001.
[netconf] IETF, "Network Configuration Working Group", 2003, <http:/
/www.ietf.org/html.charters/netconf-charter.html>.
Author's Address
George M. Jones, Editor
The MITRE Corporation
7525 Colshire Dr., WEST
McLean, VA 22102
U.S.A.
Phone: +1 703 488 9740
EMail: gmjones@mitre.org
URI: http://www.port111.com/opsec/
Jones, Editor Expires February 11, 2004 [Page 58]
Internet-Draft Operational Security Requirements August 2003
Appendix A. Requirement Profiles
This Appendix lists different profiles. A profile is a list of list
of requirements that apply to a particular class of devices. The
minimum requirements profile applies to all devices.
A.1 Minimum Requirements Profile
The functionality listed here represents a bare minimum set of
requirements which any managed networking infrastructure device
should adhere to. This includes all core and edge devices which are
part of an IP network (such as routers, and switches). Note that
SOHO equipment (typically DSL modem/routers, cable modem/routers,
etc) and wireless networking infrastructure equipment have their own
set of requirements and are not expected to adhere to this particular
set of minimal requirements.
The minimal requirements profile addresses functionality which will
provide reasonable capabilities to manage the devices in the event of
attacks, simplify troubleshooting, keep track of events which affect
system integrity, help analyze causes of attacks, as well as provide
administrators control over IP addresses and protocols to help
mitigate the most common attacks and exploits.
A.1.1 Functional Requirements
A.1.1.1 Device Management Requirements
o Support Secure Management Channels
o Support Remote Configuration Backup
o Support Remote Configuration Restore
o Support Management Over Slow Links
o Support Scripting of Management Functions
o Restrict Management to Local Interfaces
A.1.1.2 In-Band Management Requirements
The following requirements apply only if In-Band management is used
to satisfy Support Secure Management Channels
o Use Non-Proprietary Encryption
Jones, Editor Expires February 11, 2004 [Page 59]
Internet-Draft Operational Security Requirements August 2003
o Use Strong Encryption
o Key Management Must Be Scalable
A.1.1.3 Out-of-Band (OoB) Management Requirements
The following requirements apply only if Out-of-Band management is
used to satisfy Support Secure Management Channels
o Support Out-of-Band Management (OoB) Interfaces
o Enforce Separation of Data and Management Channels
o Separation Not Achieved by Filtering
o No Forwarding Between Management and Data Planes
A.1.1.4 User Interface Requirements
o Support Human-Readable Configuration File
o Display of 'Sanitized' Configuration
o Display All Configuration Settings
A.1.1.5 IP Stack Requirements
o Comply With Relevant IETF RFCs on All Protocols Implemented
o Ability to Identify All Listening Services
o Ability to Disable Any and All Services
o Ability to Control Service Bindings for Listening Services
o Ability to Control Service Source Address
o Support Automatic Anti-spoofing for Single-Homed Networks
o Ability to Disable Processing of Packets Utilizing IP Options
o Directed Broadcasts Disabled by Default
Jones, Editor Expires February 11, 2004 [Page 60]
Internet-Draft Operational Security Requirements August 2003
A.1.1.6 Basic Filtering Capabilities
o Ability to Filter Traffic
o Ability to Filter Traffic to the Device
o Ability to Filter Updates
o Ability to Specify Filter Actions
o Ability to Log Filter Actions
o Ability to Filter Without Performance Degradation
A.1.1.7 Packet Filtering Criteria
o Ability to Filter on Protocols
o Ability to Filter on Addresses
o Ability to Filter on Any Protocol Header Fields
o Ability to Filter Inbound and Outbound
A.1.1.8 Packet Filtering Counter Requirements
o Packet Filtering Counter Requirements
o Ability to Display Filter Counters
o Ability to Display Filter Counters per Rule
o Ability to Display Filter Counters per Filter Application
o Ability to Reset Filter Counters
o Filter Counters Must Be Accurate
A.1.1.9 Other Packet Filtering Requirements
o Filter, Counters, and Filter Log Performance Must Be Usable
Jones, Editor Expires February 11, 2004 [Page 61]
Internet-Draft Operational Security Requirements August 2003
A.1.1.10 Event Logging Requirements
o Ability to Log All Events That Affect System Integrity
o Logging Facility Conforms to Open Standards
o Ability to Log to Remote Server
o Ability to Select Reliable Delivery
o Ability to Log Locally
o Ability to Maintain Accurate System Time
o Logs Must Be Timestamped
o Logs Contain Untranslated Addresses
o Logs Do Not Contain DNS Names by Default
A.1.1.11 Authentication, Authorization, and Accounting (AAA)
Requirements
o Authenticate All User Access
o Support Authentication of Individual Users
o Support Simultaneous Connections
o Ability to Disable All Local Accounts
o Support Centralized User Authentication
o Support Local User Authentication
o Support Configuration of Order of Authentication Methods
o Ability to Authenticate Without Reusable Plaintext Passwords
o Ability to Define Privilege Levels
o Ability to Assign Privilege Levels to Users
o Default Privilege Level Must Be Read Only
o Change in Privilege Levels Requires Re-Authentication
Jones, Editor Expires February 11, 2004 [Page 62]
Internet-Draft Operational Security Requirements August 2003
o Accounting Records
A.1.2 Documentation Requirements
o Document Listening Services
o Provide a List of All Protocols Implemented
o Identify Origin of IP Stack
o Identify Origin of Operating System
A.1.3 Assurance Requirements
o Ability to Withstand Well-Known Attacks and Exploits
o Vendor Responsiveness
A.2 Layer 3 Network Core Profile
This section builds on the minimal requirements listed in A.1 and
adds more stringent security functionality specific to layer 3
devices which are part of the network core. The network core devices
need to be as free as possible from features which affect high-speed
packet forwarding.
A core device is defined as a device that makes up the network
infrastructure but does not connect directly to customers or peers.
This would include backbone core routers.
A.2.1 Functional Requirements
A.2.1.1 IP Stack Requirements
o Support Denial-Of-Service (DoS) Tracking
o Traffic Monitoring
o Traffic Sampling
A.3 Layer 3 Network Edge Profile
This section builds on the minimal requirements listed in A.1 and
adds more stringent security functionality specific to layer 3
Jones, Editor Expires February 11, 2004 [Page 63]
Internet-Draft Operational Security Requirements August 2003
devices which are part of the network edge. The network edge is
typically where much of the filtering and traffic control policies
are implemented.
An edge device is defined as a device that makes up the network
infrastructure and connects directly to customers or peers. This
would include routers connected to peering points, switches
connecting customer hosts, etc.
A.3.1 Functional Requirements
A.3.1.1 IP Stack Requirements
o Support Automatic Anti-spoofing for Single-Homed Networks
o Support Denial-Of-Service (DoS) Tracking
o Traffic Monitoring
o Traffic Sampling
A.3.1.2 Rate Limiting Requirements
o Support Rate Limiting
o Support Rate Limiting Based on State
A.3.1.3 Basic Filtering Capabilities
o Ability to Filter Traffic Through the Device
A.4 Layer 2 Network Core Profile
This section builds on the minimal requirements listed in A.1 and
adds more stringent security functionality specific to layer 2
devices which are part of the network core.
A.4.1 Functional Requirements
A.4.1.1 Layer 2 Requirements
o Layer 3 Dependencies
Jones, Editor Expires February 11, 2004 [Page 64]
Internet-Draft Operational Security Requirements August 2003
A.5 Layer 2 Edge Profile
This section builds on the minimal requirements listed in A.1 and
adds more stringent security functionality specific to layer 2
devices which are part of the network edge. The network edge is
typically where much of the filtering and traffic control policies
are implemented so more emphasis on this is added to the security
profile.
A.5.1 Functional Requirements
A.5.1.1 Layer 2 Requirements
o Filtering MPLS LSRs
o Ability to Filter on Layer 2 MAC Addresses
o VLAN Isolation
o Layer 2 Denial-of-Service
o Layer 3 Dependencies
Jones, Editor Expires February 11, 2004 [Page 65]
Internet-Draft Operational Security Requirements August 2003
Appendix B. Acknowledgments
This document grew out of an internal security requirements document
used by UUNET for testing devices that were being proposed for
connection to the backbone.
The editor gratefully acknowledges the contributions of:
o Greg Sayadian, author of a predecessor of this document.
o Eric Brandwine, a major source of ideas/critiques.
o The MITRE Corporation for supporting continued development of this
document. NOTE: The editor's affiliation with The MITRE
Corporation is provided for identification purposes only, and is
not intended to convey or imply MITRE's concurrence with, or
support for, the positions, opinions or viewpoints expressed by
the editor.
o UUNET's entire network security team (past and present): Jared
Allison, Eric Brandwine, Clarissa Cook, Dave Garn, Tae Kim, Kent
King, Neil Kirr, Mark Krause, Michael Lamoureux, Maureen Lee, Todd
MacDermid, Chris Morrow, Alan Pitts, Greg Sayadian, Bruce Snow,
Robert Stone, Anne Williams, Pete White.
o Others who have provided significant feedback at various stages of
the life of this document are: Ran Atkinson, Fred Baker, Steve
Bellovin, Michael H. Behringer, Matt Bishop, Scott Blake, Randy
Bush, Steven Christey, Sean Donelan, Robert Elmore, Barry Greene,
Dan Hollis, Merike Kaeo, John Kristoff, Chris Liljenstolpe, James
W. Laferriere, Alan Paller, Rob Pickering, Gregg Schudel, Rodney
Thayer, David Walters, Anthony Williams, Neal Ziring
o Madge B. Harrison, technical writing review.
o This listing is intended to acknowledge contributions, not to
imply that the individual or organizations approve the content of
this document.
o Apologies to those who commented on/contributed to the document
and were not listed...contact the editor to be credited in future
versions
Version: $Id: draft-jones-opsec-01.cpp,v 1.1 2003/08/13 14:10:02
george Exp $
Jones, Editor Expires February 11, 2004 [Page 66]
Internet-Draft Operational Security Requirements August 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Jones, Editor Expires February 11, 2004 [Page 67]
Internet-Draft Operational Security Requirements August 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jones, Editor Expires February 11, 2004 [Page 68]