| TOC |
|
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 November 14, 2003.
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document defines a list of security requirements for devices that implement the Internet Protocol (IP). These requirements apply to devices that makeup the network core infrastructure (such as routers and switches) as well other devices that implement IP (e.g. cable modems, personal firewalls,hosts). A framework is defined for specifying "profiles", which are collections of devices 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.
opsec@ops.ietf.org is a public mailing list for discussion of this draft. A list of goals, next steps and outstanding issues is available at http://www.port111.com/opsec/opsec-meta.txt
| TOC |
| TOC |
The goal of this document is to define a list of security requirements for devices that implement Internet Protocol (IP). The intent of the list is to provide consumers of IP devices a clear, concise way of communicating their security requirements to equipment vendors.
These requirements apply to devices that makeup the network core infrastructure (such as routers and switches) as well other devices that implement IP (e.g. cable modems, personal firewalls,hosts).
While, the examples given are written with IPv4 in mind, most of the requirements are general enough to apply to IPv6.
Devices are expected to conform to protocol specifications as defined by the Internet Engineering Task Force (IETF) Request for Comment (RFC) series for all protocols which they implement unless otherwise noted.
There are two intended audiences: the end user (consumer) who selects, purchases, and operates IP network equipment, and the vendors who create them.
The individual requirements are listed in one of three sections below.
Within these areas, requirements are grouped in major functional areas (e.g. logging, authentication, filtering, etc.
Each requirement has the following subsections:
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 Requirement Profiles defines several requirement "profiles" for different types of devices. Profiles are simply collections of requirements. They provide a concise list of the requirements that apply to certain classes of devices. The profiles in this document are suggestions only and should be reviewed to determine if they are appropriate the local environment.
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.
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 RFC 2119.
Unless otherwise indicated, "IP" refers to IPv4
| TOC |
This section is intended to to list security features that comprise best practice at the time of writing. They are know to be implemented and useful for improving security.
- Requirement
- The device MUST provide an out-of-band (OoB) interface for management access.
- Justification
- This is important because it allows all management of the device to be done via separate control channels and reduces that risk that unauthorized individuals will observe management traffic and/or compromise the device.
- It applies in situations where a separate out-of-band management network exists or other out-of-band 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
- Warnings
- Out-of-band management may not be required or feasible in all situations, for instance if remote management is not a requirement.
- Requirement
- The device MUST support separation of data and control channels. It MUST support complete physical and logical separation of management and non management traffic.
- Justification
- Separation of control and data channels enables the application of separate and appropriate controls to each channel, and reduces the possibility that a vulnerability in one are 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 control elements are separated, it is likely that the control elements will continue to function, allowing the network operator to evaluate and respond to the problem. If they are not separated (for instance if, 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 out-of-band management interfaces per Support Out-Of-Band Management Interfaces 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.
- See [8] for related requirements.
- Warnings
- None.
- Requirement
- 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
- Warnings
- None.
- 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 seperate 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.
- Requirement
- The device MUST remain manageable at all times, even in the presence of attacks directed to or through the device.
- Justification
- This requirement is particularly important for management ports. If a malicious user is able to effectively disable the management port, then it may be impossible for authorized users to access the device to respond to incidents and maintain normal operation.
- Examples
- Assume that an attacker is able to flood the management port, launch a large number of well known attacks (See Ability To Withstand Well-Known Attacks And Exploits) directly against the management port, or to use a group of compromised hosts to saturate all links connected to the device. It is precisely under these conditions that is is critical to preserve ability to connect to the device to perform management functions. The issuance of such management commands may be the primary tool for mitigating the effects of the attacks. Also see Ability To Filter Traffic.
- Warnings
- There is a never-ending arms race between the discovery/exploitation of new vulnerabilities and the full deployment of code and and configurations necessary to remove the vulnerabilities. This requirement is therefore something of an ideal. It will require constant attention both on the part of vendors and operators to achieve the best approximation of meeting the requirement at any given time. Also see the warning on Maintain Primary Function At All Times
- Requirement
- The device MUST provide a means to store and retrieve the system configuration to/from 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 Support Secure Management Channels 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.
- 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.
- 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.
- 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.
- 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
- Requirement
- The device MUST fully comply with IETF RFCs for all protocols implemented.
- Justification
- This is important because it ensures interoperability of products from multiple vendors.
- Examples
- Some of the relevant RFCs include:
- ICMP
- RFC792 INTERNET CONTROL MESSAGE PROTOCOL
- RFC1812 Requirements for IP Version 4 Routers
- IP
- RFC791 INTERNET PROTOCOL
- RFC922 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
- RFC793 TRANSMISSION CONTROL PROTOCOL
- RFC1858 Security Considerations for IP Fragment Filtering
- RFC1948 Defending Against Sequence Number Attacks
- UDP
- RFC768 User Datagram Protocol
- RFC1122 Requirements for Internet Hosts -- Communication Layers
- RFC1812 Requirements for IP Version 4 Routers
- Requirement
- The vendor SHOULD provide a concise list all protocols implemented by the device.
- Justification
- This facilitates through and appropriately targeted testing.
- Examples
- None.
- Warnings
- None.
- Requirement
- The vendor SHOULD provide references to publicly available specifications for all protocols implemented.
- Justification
- Security through obscurity is bad policy. Closed, undocumented protocols that have not undergone through public review may contain undiscovered (by the vendor) vulnerabilities that can be easily exploited. Open, documented protocols facilitate through 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.
- 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. The mechanism should also display the interfaces on which each service is listening.
- 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.
- Requirement
- The device MUST provide a means to turn off any external services.
- 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
- It SHOULD be possible to enable/disable each service independently. ports protocols internal, if not needed.
- Warnings
- None.
- Requirement
- The device MUST provide a means that allows 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 Display All Configuration Settings 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.
- 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 address 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 its source, the SNMP workstation receiving the traps (or a firewall in front of it) could be configured to only receive SNMP packets from that address.
- Examples
- None.
- Warnings
- None.
- Requirement
- The device MUST have an IP stack and operating system that is robust enough to withstand well-known attacks and exploits. For the purpose of this document, well-known attacks and exploits are defined as those that have been published by the following:
- Computer Emergency Response Team (CERT) Coordination Center Advisories http://www.cert.org/
- Common Vulnerabilities and Exposures (CVE) entries http://cve.mitre.org/
- Bugtraq postings http://www.securityfocus.org/
- Standard Nessus Plugins http://www.nessus.org/
- Vendor security bulletins for the device in question.
- 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 affects confidentiality, availability, and data integrity.
- Examples
- Take for example the SNMP vulnerabilities described in [10]. These vulnerabilities were discovered and and toolkit for exploiting them was publicly released. What this 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 (with apologies to any computer science researchers who may think otherwise). 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.
- Requirement
- The device MUST maintain its primary function at all times, even in the presence of attacks directed to or through the device.
- Justification
- One of the primary goals of security is to preserve availability of resources (such as routers, switches or hosts) for authorized use. That is the goal of this requirement.
- Examples
- Assume that several attacks (See Ability To Withstand Well-Known Attacks And Exploits were directed at the management port or that a flood attack was directed through the device. In both these cases, the device should continue to perform its routing/switching functions. Also see Ability To Filter Traffic.
- Warnings
- There is a never ending arms race between those who would discover and exploit vulnerabilities and those who would defend against them. New vulnerabilities are discovered continually, and there is a window of opportunity for harm between the time of discovery and the time that the vendor is made aware of the problem, analyzes it, implements fixes, makes updated code/images available, and the time that the operator acquires and installs the patched code and/or performs the necessary configuration to defend against the new vulnerability. In this context, this requirement is admittedly an idealized goal.
- 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 that
- 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 implement 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.
- 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.
- 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"
- Requirement
- The device MUST provide a configuration mechanism so 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.
- These SHOULD be the default settings.
- Justification
- Directed broadcasts have few legitimate uses in modern networks and are easily abused to amplify denial of service attacks (e.g. SMURF attacks). RFC 2664 recommends the same change in default setting as Best Current Practice.
- Examples
- None.
- Warnings
- None.
- 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. When encountering a malformed packet, unexpected behavior often occurs in the device such as a system crash or buffer overflow (where unauthorized access to the system could be granted).
- 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 the source of that OS.
- Examples
- For example, "The operating system is based on Linux kernel 2.4.18".
- Warnings
- None.
- 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 it's data-center to a company that that becomes unpopular with a certain element of network users who decide to flood the web server with inbound ICMP traffic. It would be useful in such a situation to be able to rate-filter inbound ICMP traffic at the data-center's border routers. On the other side, assume that a new worm is released that infects vulnerable database servers such that they then start spewing traffic on TCP port 1433 aimed at random destination addresses as fast as the system and network interface of the infected 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 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.
- 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.
- 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 Packet Filtering Criteria
- Also see the specific filtering requirements that follow this one.
- Justification
- Packet filtering is important because it provides a basic means of implementing policies that specify which traffic is allowed and which is not. It also provides a basic tool for responding to malicious traffic.
- Examples
- Access control lists that allow filtering based on protocol and/or source/destination address and or source/destination port would be one example.
- Warnings
- None.
- 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 to support 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.
- 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 [4]
- Warnings
- None.
- Requirement
- The filtering mechanism MUST support filtering based on the value(s) of any portion of the protocol headers.
- Justification
- Being able to filter on portions of the header is necessary to allow implementation of policy, secure operations and to 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.
- 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 as 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 site that is known to forward or originate lots of junk mail.
- Warnings
- None.
- 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.
- Warnings
- None.
- 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
- Ingress filtering as described in RFC2827 Network Ingress Filtering is one example of filtering traffic intended to pass through the device.
- Warnings
- None.
- 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 to 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.
- Requirement
- The device MUST provide a means to filter updates for all protocols that could be used to update operational characteristics of the device. Note that it MUST be possible to specify a filter that disables all updates.
- This requirement MAY be satisfied through the use of filters as described in Ability To Filter Traffic and/or with mechanisms specific to each protocol. Also note that update filtering is required in addition to secure channels (Support Secure Management Channels) and authentication (Authentication, Authorization, and Accounting (AAA) Requirements)
- 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.
- 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 Ability To Log Filter Actions and Packet Filtering Counter Requirements
- Justification
- This capability is essential to the use of filters to enforce policy.
- Examples
- Assume that you have a small DMZ network connected to the Internet. You want to allow management using SSH coming from your corporate office. In this case, you might "permit" all traffic to port 22 in the DMZ from your corporate network, "rejecting" all others. Port 22 traffic from the corporate network is allowed through. Port 22 traffic from all other addresses results in an ICMP message to the sender. For those who are slightly more paranoid, you might choose to "drop" instead of "reject" traffic from unauthorized addresses, with the result being that *nothing* is sent back to the source.
- Warnings
- [Ed. Does "drop" with no ICMP unreachable violate any RFCs ?]
- 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 [4]) on interfaces of it's 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.
- 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 seperate internal networks. Assume that a host on one of the internal networks has been compromised by a hacker and is sending traffic with bogus source addresses. In such a situation, it might be desirable to apply ingress filters to each of the internal interfaces. Once the filters are in place, the counters can be examined to determine the source (inbound interface) of the bogus packets.
- Warnings
- None.
- 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.
- Requirement
- If it is possible for a filter to be applied more then 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 there is 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.
- 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 the traffic matching particular rules/filters.
- Examples
- Assume that filter counters are being used to detect internal hosts that are infected with 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.
- 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.
- 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 Event Logging Requirements.
- 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.
- Requirement
- It MUST be possible to enable/disable logging on a per rule basis.
- Justification
- The ability to tune the granularity of logging allows the operator to log only the information that is desired. Without this capability, it is possible that extra data (or none at all) wold be logged, making it more difficult to find relevant information.
- Examples
- If a filter is defined that has several rules, and one of the rules denies telnet (tcp/23) connections, then it should be possible to specify that only matches on the rule that denies telnet should generate a log message.
- Warnings
- None.
- 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 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.
- 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.
- 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 that a feature is unusable (it's 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.
- 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
- This items that must be logged includes, but is not limited to, the following events:
- Filter matches, described in Ability To Log Filter Actions
- 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.
- Requirement
- The device MUST provide a logging facility that conforms to open standards. Custom/Proprietary log protocols MAY be implemented provided the same information is made available via logging facilities that conform to open standards.
- Justification
- The use of open standards logging is important because it permits the customer to perform archival and analysis of logs without relying on vendor supplied software and servers.
- Examples
- [6] meets this requirement. The use of SNMP traps may also satisfy this requirement.
- Warnings
- While [5] and SNMP may satisfy this requirement, they both fail to satisfy several other logging requirements.
- Requirement
- The vendor MUST specify a catalog of all messages that a device can emit. This MUST 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.
- Requirement
- The device MUST be possible to log 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 [5].
- Warnings
- High volumes of logging may generate excessive network traffic and/or compete for scarce memory and CPU resources on the device.
- 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 [6]. Syslog-ng provides another example, although the protocol has not been standardized.
- Warnings
- None.
- Requirement
- It MUST be possible to configure the logging mechanism such that there is independent control of the authenticity, integrity, confidentiality and replay prevention of log messages.
- Justification
- See section 5 of [6], and section 6 of [5].
- Examples
- [6] defines one way of meeting these requirements.
- Warnings
- None.
- Requirement
- It SHOULD be possible to log locally on the device itself.
- Justification
- Local logging is important for viewing information when connected to the device. It provides some backup of log data in case remote logging fails. It provides a way to view logs relevant to one device without having to sort through a possibly large set of logs from other devices.
- Examples
- One example of local logging would be a memory buffer which 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.
- Requirement
- The device MUST allow the remote log server to be specified by the event classification. For example, security related messages would go to one log server, while operational messages would go to another.
- Justification
- This is important because it allows (in concert with requirement Ability To Classify Events ) messages of certain types to be sent to different servers for processing. This is important in environments with large numbers of devices, large numbers of log messages, and/or where responsibilities for certain classes of messages are divided.
- Examples
- This requirement MAY be satisfied by providing configuration commands that allow the user to assign syslog facilities to each message or class of messages. For example, it should be possible to specify that all security related events be assigned syslog facility local4 and that messages classified as local4 should be sent to syslog server 10.9.8.7.
- Warnings
- None.
- Requirement
- The device SHOULD provide a mechanism for assigning classifications to all messages. At a minimum, it MUST provide the ability to assign a chosen classification to all security related messages, and different classification(s) to all other messages.
- Justification
- This is important because it allows (in concert with requirement Ability To Specify Logservers By Event Classification ) messages of certain types to be sent to different servers for processing. This is important in environments with large numbers of devices, large numbers of log messages, and/or where responsibilities for certain classes of messages are divided.
- Examples
- This requirement MAY be satisfied by providing a mechanism to assign specific syslog facility codes to specific messages or groups of messages. For example, all security events could be assigned one facility code, all network routing issues to another, and all physical (power, line card) to another.
- Warnings
- None.
- Requirement
- The device MUST maintain accurate, high resolution system time. All display of system time MUST include a timezone. The default timezone SHOULD be UTC. 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 Support Secure Management Channels 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).
- 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 timezone.
- Justification
- This is important because accurate timestamps are necessary for correlating events, particularly across multiple devices or with other organizations. This applies when it is necessary to analyze logs.
- Examples
- This requirement MAY be satisfied by writing timestamps into syslog messages.
- Warnings
- It is difficult to correlate logs from different time zones. Security events on the Internet often involve machines and logs from a variety of physical locations. For that reason, UTC is preferred, all other things being equal.
- 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 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.
- 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 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 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.
- 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 Support Centralized User Authentication. It MAY also be satisfied using local authentication, see Support Local User Authentication
- Warnings
- None.
- 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.
- Warnings
- This simply requires that the mechanism to support individual users be present. Policy (say forbidding shared group accounts) and enforcement are also needed but beyond the scope of this document.
- 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.
- 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.
- Requirement
- The device MUST support centralized authentication of all user access via standard authentication protocols.
- Justification
- Support for centralized authentication is particularly important in large environments where the network devices are widely distributed and where many people have access to the network devices. 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 Support Secure Management Channels for requirements related to secure communication channels for management protocols and data.
- Warnings
- None.
- 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.
- 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.
- Examples
- If, for example, a device supports RADIUS authentication and local username/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.
- 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 Support Secure Management Channels.
- Justification
- Reusable plain-text passwords can be easily 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 Support Secure Management Channels) for device management. It does allow the use of standard telnet with 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 [1] for a through discussion
- Examples
- of the issues.
- Warnings
- None.
- Requirement
- The device MUST support device to device authentication for all non-interactive management protocols. Also see Ability To Authenticate Without Reusable Plaintext Passwords and Support Secure Management Channels
- 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).
- Warnings
- None.
- 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 Ability to Assign Privilege Levels to Users
- 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.
- Requirement
- The device MUST be able to assign a defined set of authorized functions, or "privilege level", to each user once they are authenticated the device. Privilege level determines which functions a user is allowed to execute. Also see See Ability Define Privilege Levels.
- Justification
- This requirement supports the implementation of the principal of "least privilege", which states that an individual should only have the privileges necessary to execute the operations he/she is required to perform.
- Examples
- 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.
- 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.
- Requirement
- The device MUST re-authenticate a user prior to granting any change in user authorizations.
- Justification
- This requirement insures that only 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.
- 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
- 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 Support Secure Management Channels for requirements related to secure communication channels for management protocols and data.
- Warnings
- Syslog is known to be unreliable/lossy both 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.
- 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 that provide previous-hop information when logging packets MUST provide the MPLS label as part of this information so 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.
- 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.
- 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.
- 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.
- Examples
- None.
- Warnings
- None.
- 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.
- 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.
| TOC |
This section is intended to to list security features that may not be implemented at the time of this writing, would be useful for improving security, and are not thought to present significant challenges in terms of technology required, support costs, performance impact, etc.
- Requirement
- The device MUST provide a secure end-to-end channel 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, routing. This requirement MAY be satisfied by using protocols that support secure channels directly or by layering insecure protocols over secure transport protocols.
- 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 See [9] 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 | | | | |
| | | | | |
+---------------+-------+-------+-------+-------+
| Time | | | | |
| NTP | | X | | X |
| | | | | |
+---------------+-------+-------+-------+-------+
| AAA | | | | |
| TACACS, | | | | |
| RADIUS, | X | X | X | X |
| DIAMETER, | | | | |
| Kerberos, | | | | |
+---------------+-------+-------+-------+-------+
| Routing | | | | |
| BGP,OSPF, | | X | | X |
| RIP | | | | |
+---------------+-------+-------+-------+-------+
| Security Needs Of Management Protocols |
- Requirement
- If encryption is used to satisfy the Support Secure Management Channels requirements, then the encryption algorithms used MUST be non-proprietary. See [9]
- 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.
- Requirement
- If encryption is used to satisfy the Support Secure Management Channels 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
- [9] 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 algorithms 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.
- 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 Support Secure Management Channels
- Warnings
- [Ed. insert verbiage about PKIs, etc. Contributions to this space solicited]
- Requirement
- The device MUST provide a management interface that:
- Supports external scripting.
- Has a simple, regular syntax.
- Allows complete access to all management functions.
- Works consistently on both in-band and out-of-band interfaces.
The interface MUST NOT be a text-based menu, windowing system or GUI. The implementation should support scripts running on external systems using Perl, Expect or other common scripting languages. This requirement explicitly does not anticipate support for scripting languages on the device itself.
- 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 in the IETF on xmlconf. See [7].
- Warnings
- None.
- 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 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.
- 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.
- 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 denial of service 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 Ability To Filter Traffic
- Warnings
- None.
- 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 - 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 Support Secure Management Channels 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.
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 a1nd 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.
- 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 Support Secure Management Channels for requirements related to secure communication channels for management protocols and data.
- Warnings
- Traffic sampling can add significant network traffic, processor and memory use.
| TOC |
This section is intended to to list security features that may not be implemented at the time of this writing, would be useful for improving security, but which may present significant challenges in terms of technology required, support costs, performance impact, etc.
- Requirement
- The device MUST provide a mechanism to allow it to become a "black box" as seen from public interfaces. Specifically this means:
- The device SHOULD provide no information about itself (e.g. system type, HW configuration, operating system type/revision, etc.) beyond the edge of the network (except for what's required to route traffic)
- Edge interfaces SHOULD be visible beyond the network.
- Internal interfaces SHOULD NOT be visible beyond the network (but would be visible within the network)
- It MUST be possible to not only disable all listening ports, but also to prevent them from initiating any traffic (such as ICMP error messages) in response to user activity.
While the default configuration of the device SHOULD be fully RFC compliant (including the sending of ICMP messages), it MUST be possible to alter the default configuration such that the device is "stealthed" (i.e. does not send ICMP messages or otherwise respond directly to packets directed to it on non-management interfaces).
- Justification
- This applies primarily in the context of core network infrastructure. A stealthed infrastructure which can not be addressed is less susceptible to direct attack. Stealthing the core network infrastructure would eliminate the possibility of large classes of attacks and thus increase reliability and availability.
- Examples
- Some specific capabilities important to stealthing include:
- Ability to filter/deny/ignore pings (ICMP echo requests)
- Ability to filter on individual protocol header bits
- Ability to control the generation of ICMP messages, including port unreachable and timeouts
It MUST be possible to configure each of these settings individually.
- Warnings
- Although some STEALTHING MECHANISMS MAY BE IN VIOLATION OF SOME RFCs, it is desirable/necessary in certain circumstances for security and operational reasons.
| TOC |
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.
| TOC |
| TOC |
| George M. Jones, Editor | |
| MITRE Corporation | |
| 7525 Colshire Dr., WEST | |
| McLean, VA 22102 | |
| US | |
| Phone: | +1 703 488 9740 |
| EMail: | gmjones@mitre.org |
| URI: | http://www.port111.com/opsec/ |
| TOC |
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.
[Ed. there have been major changes to the individual requirements since these profiles were created. They will be updated in -01].
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. This section lists layer requirements specific to core devices.
An edge device is defined as a device that makes up the network infrastructure and connects directly to customers or peers. This would include routers connected to peering points, switches connecting customer hosts, etc. This section lists layer requirements specific to edge devices. In general, edge device requirements are a superset of those for core devices.
This section lists layer two requirements specific to core devices.
This section lists layer two requirements specific to edge devices.
| TOC |
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:
Version: $Id: draft-jones-netsec-reqs-00.cpp,v 1.21 2003/05/17 11:47:04 george Exp $
| TOC |
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.
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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Funding for the RFC Editor function is currently provided by the Internet Society.