Requirement.
The use of security features specified by the requirements in this
document SHOULD NOT cause severe operational problems.
Justification.
Security features which cause operational problems are not useful
and may leave the operator with no mechanism for enforcing
appropriate policy.
Examples.
Some examples of severe operational problems include:
* The device crashes.
* The device becomes unmanageable.
* Data is lost.
* Use of the security feature consumes excessive resources (CPU,
memory, bandwidth).
Warnings.
Determination of compliance with this requirement involves a level
of judgement. What is "severe"? Certainly crashing is severe,
but what about a %5 loss in throughput when logging is enabled?
It should also be noted that there may be unavoidable physical
limitations such as the total capacity of a link.
2.15. Security Features Should Have Minimal Performance Impact
Requirement.
Security features specified by the requirements in this document
SHOULD be implemented with minimal impact on performance. Other
sections of this document may specify different performance
requirements (e.g., "MUST"s).
Justification.
Security features which significantly impact performance may leave
the operator with no mechanism for enforcing appropriate policy.
Examples.
If the application of filters is known to have the potential to
significantly reduce throughput for non-filtered traffic, there
will be a tendency, or in some cases a policy, not to use filters.
Assume, for example, that a new worm is released that scans random
IP addresses looking for services listening on TCP port 1433. An
operator might want to investigate to see if any of the hosts on
their networks were infected and trying to spread the worm. One
way to do this would be to put up non-blocking filters counting
and logging the number of outbound connection 1433, and then to
block the requests that are determined to be from infected hosts.
If any of these capabilities (filtering, counting, logging) have
the potential to impose severe performance penalties, then this
otherwise rational course of action might not be possible.
Warnings.
Requirements for which performance is a particular concern
include: filtering, rate-limiting, counters, logging and anti-
spoofing.
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. Identify Services That May Be Listening
Requirement.
The vendor MUST provide a list of all services that may be active
on the device. The list MUST identify the protocols and default
ports (if applicable) on which the services listen. It SHOULD
provide references to complete documentation describing the
service.
Justification.
This information is necessary to enable a thorough assessment of
the potential security risks associated with the operation of each
service.
Examples.
The list will likely contain network and transport protocols such
as IP, ICMP, TCP, UDP, routing protocols such as BGP and OSPF,
application protocols such as SSH and SNMP along with references
to the RFCs or other documentation describing the versions of the
protocols implemented.
Web servers "usually" listen on port 80. In the default
configuration of the device, it may have a web server listening on
port 8080. In the context of this requirement "identify ...
default port" would mean "port 8080".
Warnings.
There may be valid, non-technical reasons for not disclosing the
specifications of proprietary protocols. In such cases, all that
needs to be disclosed is the existence of the service and the
default ports (if applicable).
3.2. Document Service Defaults
Requirement.
The vendor MUST provide a list of the default state of all
services.
Justification.
Understanding risk requires understanding exposure. Each service
that is enabled presents a certain level of exposure. Having a
list of the services that is enabled by default makes it possible
to perform meaningful risk analysis.
Examples.
The list may be no more than the output of a command that
implements Section 2.5.1.
Warnings.
None.
3.3. Document Service Activation Process
Requirement.
The vendor MUST concisely document which features enable and
disable services.
Justification.
Once risk has been assessed, this list provides the operator a
quick means of understanding how to disable (or enable) undesired
(or desired) services.
Examples.
This may be a list of commands to enable/disable services one by
one or a single command which enables/disables "standard" groups
of commands.
Warnings.
None.
3.4. Document Command Line Interface
Requirement.
The vendor MUST provide complete documentation of the command line
interface with each software release. The documentation SHOULD
include highlights of changes from previous versions. The
documentation SHOULD list potential output for each command.
Justification.
Understanding of inputs and outputs is necessary to support
scripting. See Section 2.4.2.
Examples.
Separate documentation should be provided for each command listing
the syntax, parameters, options, etc. as well as expected output
(status, tables, etc.).
Warnings.
None.
3.5. ’Console’ Default Communication Profile Documented
Requirement.
The console default profile of communications parameters MUST be
published in the system documentation.
Justification.
Publication in the system documentation makes the settings
accessible. Failure to publish them could leave the operator
having to guess.
Examples.
None.
Warnings.
None.
4. Assurance Requirements
The requirements in this section are intended to
o identify behaviors and information that will increase confidence
that the device will meet the security functional requirements.
o Provide information that will assist in the performance of
security evaluations.
4.1. Identify Origin of IP Stack
Requirement.
The vendor SHOULD disclose the origin or basis of the IP stack
used on the system.
Justification.
This information is required to better understand the possible
security vulnerabilities that may be inherent in the IP stack.
Examples.
"The IP stack was derived from BSD 4.4", or "The IP stack was
implemented from scratch."
Warnings.
Many IP stacks make simplifying assumptions about how an IP packet
should be formed. A malformed packet can cause unexpected
behavior in the device, such as a system crash or buffer overflow
which could result in unauthorized access to the system.
4.2. Identify Origin of Operating System
Requirement.
The vendor SHOULD disclose the origin or basis of the operating
system (OS).
Justification.
This information is required to better understand the security
vulnerabilities that may be inherent to the OS based on its
origin.
Examples.
"The operating system is based on Linux kernel 2.4.18."
Warnings.
None.
5. Security Considerations
General
Security is the subject matter of this entire memo. The
justification section of each individual requirement lists the
security implications of meeting or not meeting the requirement.
SNMP
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPSec),
even then, there is no control as to who on the secure network is
allowed to access and GET/SET (read/change/create/delete) the
objects in the MIB.
It is recommended that implementors consider the security features
as provided by the SNMPv3 framework (see [RFC3410], section 8),
including full support for the SNMPv3 cryptographic mechanisms
(for authentication and privacy).
Furthermore, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to MIB
objects is properly configured to give access to the objects only
to those principals (users) that have legitimate rights to indeed
GET or SET (change/create/delete) them.
6. References
6.1. Normative References
[ANSI.X9-52.1998] American National Standards Institute, "Triple Data
Encryption Algorithm Modes of Operation", ANSI
X9.52, 1998.
[FIPS.197] National Institute of Standards and Technology,
"Advanced Encryption Standard", FIPS PUB 197,
November 2001,
<http://csrc.nist.gov/publications/fips/fips197/
fips-197.ps>.
[PKCS.3.1993] RSA Laboratories, "Diffie-Hellman Key-Agreement
Standard, Version 1.4", PKCS 3, November 1993.
[RFC1208] Jacobsen, O. and D. Lynch, "Glossary of networking
terms", RFC 1208, March 1991.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
1321, April 1992.
[RFC1492] Finseth, C., "An Access Control Protocol, Sometimes
Called TACACS", RFC 1492, July 1993.
[RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510, September
1993.
[RFC1704] Haller, N. and R. Atkinson, "On Internet
Authentication", RFC 1704, October 1994.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4
Routers", RFC 1812, June 1995.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de
Groot, G., and E. Lear, "Address Allocation for
Private Internets", BCP 5, RFC 1918, February 1996.
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC
2196, September 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version
1.0", RFC 2246, January 1999.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the
TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture
for the Internet Protocol", RFC 2401, November
1998.
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement
Method", RFC 2631, June 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.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W.
Simpson, "Remote Authentication Dial In User
Service (RADIUS)", RFC 2865, June 2000.
[RFC3013] Killalea, T., "Recommended Internet Service
Provider Security Services and Procedures", BCP 46,
RFC 3013, November 2000.
[RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
August 2001.
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash
Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3195] New, D. and M. Rose, "Reliable Delivery for
syslog", RFC 3195, November 2001.
[RFC3309] Stone, J., Stewart, R. and D. Otis, "Stream Control
Transmission Protocol (SCTP) Checksum Change", RFC
3309, September 2002.
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330,
September 2002.
[RFC3360] Floyd, S., "Inappropriate TCP Resets Considered
Harmful", BCP 60, RFC 3360, August 2002.
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction and Applicability Statements for
Internet-Standard Management Framework", RFC 3410,
December 2002.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network
Management Protocol (SNMP) Management Frameworks",
STD 62, RFC 3411, December 2002.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key
Cryptography Standards (PKCS) #1: RSA Cryptography
Specifications Version 2.1", RFC 3447, February
2003.
[RFC3562] Leech, M., "Key Management Considerations for the
TCP MD5 Signature Option", RFC 3562, July 2003.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote
Authentication Dial In User Service) Support For
Extensible Authentication Protocol (EAP)", RFC
3579, September 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G.,
and J. Arkko, "Diameter Base Protocol", RFC 3588,
September 2003.
[RFC3631] Bellovin, S., Schiller, J., and C. Kaufman, Eds.,
"Security Mechanisms for the Internet", RFC 3631,
December 2003.
6.2. Informative References
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths
For Public Keys Used For Exchanging Symmetric
Keys", BCP 86, RFC 3766, April 2004.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for
Multihomed Networks", BCP 84, RFC 3704, March 2004.
[bmwg-acc-bench] Poretsky, S., "Framework for Accelerated Stress
Benchmarking", Work in Progress, October 2003.
[Schneier] Schneier, B., "Applied Cryptography, 2nd Ed.,
Publisher John Wiley & Sons, Inc.", 1996.
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 minimum set of
requirements to which managed infrastructure of large IP networks
should adhere.
The minimal requirements profile addresses functionality which will
provide reasonable capabilities to manage the devices in the event of
attacks, simplify troubleshooting, keep track of events which affect
system integrity, help analyze causes of attacks, as well as provide
administrators control over IP addresses and protocols to help
mitigate the most common attacks and exploits.
o Support Secure Channels For Management
o Use Protocols Subject To Open Review For Management
o Use Cryptographic Algorithms Subject To Open Review
o Use Strong Cryptography
o Allow Selection of Cryptographic Parameters
o Management Functions Should Have Increased Priority
o Support a ’Console’ Interface
o ’Console’ Communication Profile Must Support Reset
o ’Console’ Default Communication Profile Documented
o ’Console’ Requires Minimal Functionality of Attached Devices.
o Support Separate Management Plane IP Interfaces
o No Forwarding Between Management Plane And Other Interfaces
o ’CLI’ Provides Access to All Configuration and Management
Functions
o ’CLI’ Supports Scripting of Configuration
o ’CLI’ Supports Management Over ’Slow’ Links
o Document Command Line Interface
o Support Software Installation
o Support Remote Configuration Backup
o Support Remote Configuration Restore
o Support Text Configuration Files
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 Addresses
o Ability to Filter Traffic
o Ability to Filter Traffic TO the Device
o Support Route Filtering
o Ability to Specify Filter Actions
o Ability to Log Filter Actions
o Ability to Filter Without Significant Performance Degradation
o Ability to Specify Filter Log Granularity
o Ability to Filter on Protocols
o Ability to Filter on Addresses
o Ability to Filter on Protocol Header Fields
o Ability to Filter Inbound and Outbound
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
o Logging Facility Uses Protocols Subject To Open Review
o Logs Sent To Remote Servers
o Ability to Log Locally
o Ability to Maintain Accurate System Time
o Display Timezone And UTC Offset
o Default Timezone Should Be UTC
o Logs Must Be Timestamped
o Logs Contain Untranslated IP Addresses
o Logs Contain Records Of Security Events
o Authenticate All User Access
o Support Authentication of Individual Users
o Support Simultaneous Connections
o Ability to Disable All Local Accounts
o Support Centralized User Authentication Methods
o Support Local User Authentication Method
o Support Configuration of Order of Authentication Methods
o Ability To Authenticate Without Plaintext Passwords
o Passwords Must Be Explicitly Configured Prior To Use
o No Default Passwords
o Ability to Define Privilege Levels
o Ability to Assign Privilege Levels to Users
o Default Privilege Level Must Be ’None’
o Change in Privilege Levels Requires Re-Authentication
o Support Recovery Of Privileged Access
o Logs Do Not Contain Passwords
o Security Features Must Not Cause Operational Problems
o Security Features Should Have Minimal Performance Impact
o Identify Services That May Be Listening
o Document Service Defaults
o Document Service Activation Process
o Identify Origin of IP Stack
o Identify Origin of Operating System
o Identify Origin of IP Stack
o Identify Origin of Operating System
o Layer 2 Devices Must Meet Higher Layer Requirements
A.2. Layer 3 Network Edge Profile
This section builds on the minimal requirements listed in A.1 and
adds more stringent security functionality specific to layer 3
devices which are part of the network edge. The network edge is
typically where much of the filtering and traffic control policies
are implemented.
An edge device is defined as a device that makes up the network
infrastructure and connects directly to customers or peers. This
would include routers connected to peering points, switches
connecting customer hosts, etc.
o Support Automatic Anti-spoofing for Single-Homed Networks
o Support Automatic Discarding Of Bogons and Martians
o Support Counters For Dropped Packets
o Support Rate Limiting
o Support Directional Application Of Rate Limiting Per Interface
o Support Rate Limiting Based on State
o Ability to Filter Traffic THROUGH the Device
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 The former UUNET network security team: 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