idnits 2.17.1 draft-jones-opsec-info-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 260 has weird spacing: '...sed for user/...' == Line 261 has weird spacing: '...In-band manag...' == Line 838 has weird spacing: '...provide refer...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: * The device SHOULD not accept any packets beyond those required to support routing information transfer. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 15, 2003) is 7471 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '6' on line 702 -- Looks like a reference, but probably isn't: '3' on line 703 -- Looks like a reference, but probably isn't: '1' on line 712 == Unused Reference: 'RFC0791' is defined on line 999, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CVE' ** Downref: Normative reference to an Experimental draft: draft-gill-gtsh (ref. 'I-D.gill-gtsh') -- Possible downref: Non-RFC (?) normative reference: ref. 'Nessus' -- Possible downref: Non-RFC (?) normative reference: ref. 'PROTOS' Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 None. G. Jones, Editor 3 Internet-Draft The MITRE Corporation 4 Expires: April 14, 2004 October 15, 2003 6 Operational Security Requirements for IP Network Infrastructure: 7 Advanced Requirements 8 draft-jones-opsec-info-00 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on April 14, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document defines a list of operational security requirements for 39 the infrastructure of large IP networks (such as routers and 40 switches). The goals of this document are to serve as a collection 41 of ideas for security features that would improve operational 42 security and to assist consumers of network equipment in 43 communicating their security requirements to vendors. The 44 requirements in this document are NOT considered to be best current 45 practice (BCP). Comments to: "opsec-comment@ops.ietf.org". 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 50 1.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 1.3 Definition of a Secure Network . . . . . . . . . . . . . . 4 53 1.4 Intended Audience . . . . . . . . . . . . . . . . . . . . 5 54 1.5 Format . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 1.6 Intended Use . . . . . . . . . . . . . . . . . . . . . . . 5 56 1.7 Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 57 2. Functional Requirements . . . . . . . . . . . . . . . . . 7 58 2.1 Device Management Requirements . . . . . . . . . . . . . . 7 59 2.1.1 Restrict Management to Local Interfaces . . . . . . . . . 7 60 2.2 In-Band Management Requirements . . . . . . . . . . . . . 7 61 2.2.1 Key Management Must Be Scalable . . . . . . . . . . . . . 8 62 2.3 Out-of-Band (OoB) Management Requirements . . . . . . . . 8 63 2.3.1 Enforce Separation of Data and Management Planes . . . . . 8 64 2.4 User Interface Requirements . . . . . . . . . . . . . . . 9 65 2.4.1 Display All Configuration Settings . . . . . . . . . . . . 9 66 2.5 IP Stack Requirements . . . . . . . . . . . . . . . . . . 10 67 2.5.1 Ability to Disable Processing of Packets Utilizing IP 68 Options . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 2.5.2 Support Denial-Of-Service (DoS) Tracking . . . . . . . . . 10 70 2.5.3 Traffic Monitoring . . . . . . . . . . . . . . . . . . . . 11 71 2.5.4 Traffic Sampling . . . . . . . . . . . . . . . . . . . . . 12 72 2.5.5 Ability To Remove In-Band Visibility . . . . . . . . . . . 13 73 2.6 Basic Filtering Capabilities . . . . . . . . . . . . . . . 14 74 2.6.1 Ability to Filter Without Performance Degradation . . . . 14 75 2.7 Packet Filtering Criteria . . . . . . . . . . . . . . . . 14 76 2.7.1 Ability to Filter on Layer 2 MAC Addresses . . . . . . . . 14 77 2.8 Event Logging Requirements . . . . . . . . . . . . . . . . 15 78 2.8.1 Ability to Log All Security Related Events . . . . . . . . 15 79 2.8.2 Ability to Select Reliable Delivery . . . . . . . . . . . 15 80 2.8.3 Ability to Classify Events . . . . . . . . . . . . . . . . 16 81 2.8.4 Logs Do Not Contain DNS Names by Default . . . . . . . . . 16 82 2.9 Authentication, Authorization, and Accounting (AAA) 83 Requirements . . . . . . . . . . . . . . . . . . . . . . . 17 84 2.9.1 Enforce Selection of Strong Local Static Authentication 85 Tokens (Passwords) . . . . . . . . . . . . . . . . . . . . 17 86 2.9.2 Support Device-to-Device Authentication . . . . . . . . . 17 87 2.10 Layer 2 Requirements . . . . . . . . . . . . . . . . . . . 18 88 2.10.1 Filtering MPLS LSRs . . . . . . . . . . . . . . . . . . . 18 89 2.10.2 VLAN Isolation . . . . . . . . . . . . . . . . . . . . . . 19 90 2.10.3 Layer 2 Denial-of-Service . . . . . . . . . . . . . . . . 19 91 3. Documentation Requirements . . . . . . . . . . . . . . . . 20 92 3.1 Provide a List of All Protocols Implemented . . . . . . . 20 93 3.2 Provide Documentation for All Protocols Implemented . . . 20 94 3.3 Catalog of Log Messages Available . . . . . . . . . . . . 20 95 4. Assurance Requirements . . . . . . . . . . . . . . . . . . 22 96 4.1 Ability to Withstand Well-Known Attacks and Exploits . . . 22 97 4.2 Vendor Responsiveness . . . . . . . . . . . . . . . . . . 23 98 5. Security Considerations . . . . . . . . . . . . . . . . . 25 99 References . . . . . . . . . . . . . . . . . . . . . . . . 26 100 Author's Address . . . . . . . . . . . . . . . . . . . . . 26 101 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 27 102 Intellectual Property and Copyright Statements . . . . . . 28 104 1. Introduction 106 1.1 Goals 108 The goals of this document are to serve as a collection of ideas for 109 security features that would improve operational security and to 110 assist consumers of network equipment in communicating their security 111 requirements to vendors. 113 1.2 Scope 115 The primary scope of these requirements is intended to cover the 116 infrastructure of large IP networks (e.g. routers and switches). 118 General purpose hosts (including infrastructure hosts such as name/ 119 time/log/AA servers, etc.), unmanaged, or customer managed devices 120 (e.g. firewalls, Intrusion Detection System, dedicated VPN devices, 121 etc.) are explicitly out of scope. 123 Confidentiality and integrity of customer data are outside the scope. 125 While, the examples given are written with IPv4 in mind, most of the 126 requirements are general enough to apply to IPv6. 128 1.3 Definition of a Secure Network 130 For the purposes of this document, a secure network is one in which: 132 o the network keeps passing legitimate customer traffic 133 (availability) 135 o traffic goes where it's supposed to go (availability) 137 o the network elements remain manageable (availability) 139 o only authorized users can manage network elements (authorization) 141 o there is record of all security related events (accountability) 143 o the network operator has the necessary tools to detect and respond 144 to illegitimate traffic 146 The following assumptions are made: 148 o Devices are physically secure. 150 o The management infrastructure (AAA/DNS/log server, SNMP management 151 stations, etc.) is secure. 153 1.4 Intended Audience 155 There are two intended audiences: the end user (consumer) who 156 selects, purchases, and operates IP network equipment, and the 157 vendors who create them. 159 1.5 Format 161 The individual requirements are listed in one of the three sections 162 listed below. 164 o Section 2 lists functional requirements. 166 o Section 3 lists documentation requirements. 168 o Section 4 lists assurance requirements. 170 Within these areas, requirements are grouped in major functional 171 areas (e.g., logging, authentication, filtering, etc.) 173 Each requirement has the following subsections: 175 o The Requirement (What) 177 o The Justification (Why) 179 o Examples (How) 181 o Warnings (if applicable) 183 The requirement describes a policy to be supported by the device. The 184 justification tells why and in what context the requirement is 185 important. The examples section is intended to give examples of 186 implementations that may meet the requirement. Examples cite 187 technology and standards current at the time of this writing. It is 188 expected that the choice of implementations to meet the requirements 189 will change over time. The warnings list operational concerns, 190 deviation from standards, caveats, etc. 192 Security requirements will vary across different device types and 193 different organizations, depending on policy and other factors. A 194 desired feature in one environment may be a requirement in another. 195 Classifications must be made according to local need. 197 1.6 Intended Use 199 It is anticipated that this document will be used in the following 200 manners: 202 Documenting Useful, non-BCP Features This document is a collection 203 of security features that would be useful in improving operational 204 security. The features listed herein are not considered to best 205 current practice (BCP) at this time. It is anticipated that the 206 features listed here may, over time, become widely implemented and 207 thus be candidates for migration to a BCP document. 209 Security Capability Checklist The requirements in this document may 210 be used as a checklist when evaluating networked products. 212 Communicating Requirements This document may be referenced, to 213 clearly communicate security requirements. 215 Basis For Testing and Certification This document may form the basis 216 for testing and certification of security features of networked 217 products. 219 1.7 Definitions 221 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 222 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 223 document are to be interpreted as described in [RFC2119]. 225 Unless otherwise indicated, "IP" refers to IPv4 227 2. Functional Requirements 229 The requirements in this section are intended to list testable, 230 functional requirements that are needed to operate devices securely. 232 2.1 Device Management Requirements 234 2.1.1 Restrict Management to Local Interfaces 236 Requirement. The device MUST have the ability to restrict management 237 traffic to sources within one hop of the device in cases where 238 management done over IP. 240 Justification. Restricting management traffic to devices attached 241 locally reduces the risk of unauthorized configuration of the 242 device from across the Internet. 244 This requirement applies primarily to SOHO equipment, where 245 out-of-band management may not be feasible, and additional 246 security for management traffic is most effectively applied by 247 restricting it to local only. 249 Examples. This requirement MAY be satisfied by reducing the TTL on 250 return TCP management traffic to 1, or by filtering all traffic to 251 the management service not sourced from local subnets. See 252 [I-D.gill-gtsh] 254 Warnings. None. 256 2.2 In-Band Management Requirements 258 This section lists security requirements for devices that are managed 259 In-band. "In-band management" is defined as any management done over 260 the same channels and interfaces used for user/customer data. 261 In-band management has the advantage of lower cost (no extra 262 interfaces or lines), but has significant security disadvantages: 264 o saturation of customer lines or interfaces can make the device 265 unmanageable 267 o since public interfaces/channels are used, it is possible for 268 attackers to directly address and reach the device and to attempt 269 management functions 271 o in-band management traffic on public interfaces may be intercepted 273 o Since the same networking code and interfaces are shared for 274 management and customer data, it is not possible to isolate 275 management functions from failures in other areas (for example, a 276 "magic packet" or buffer overrun that causes the data forwarding 277 portions of a router to crash will also likely make it impossible 278 to manage...this would not necessarily be the case if the 279 management and data forwarding elements were completely separated) 281 2.2.1 Key Management Must Be Scalable 283 Requirement. The number of keys and passwords that must be managed to 284 support other requirements in this document MUST scale well. 285 Specifically, The number of keys and passwords managed MUST 286 increase, at most, linearly as the number of devices and users. 288 Justification. In large networks, or in networks with a large number 289 of users, the key/password space could quickly grow to 290 unmanageable size. 292 Examples. The use of AAA protocols such as RADIUS or the use of 293 Kerberos greatly increases the manageability of keys and passwords 294 however, someone still needs to configure the databases and 295 periodically ensure that the databases have not become 296 compromised. The use of a Public Key Infrastructure (PKI), which 297 utilizes digital certificates to automate the secure distribution 298 of passwords and keys, should be a consideration for networks with 299 a large set of keys/passwords to manage. 301 Warnings. None. 303 2.3 Out-of-Band (OoB) Management Requirements 305 See Section 2.2 for a discussion of the advantages and disadvantages 306 of In-band vs. Out-of-Band management. 308 2.3.1 Enforce Separation of Data and Management Planes 310 Requirement. The device MUST support separation of data and 311 management plane. It MUST support complete physical and logical 312 separation of management and non-management traffic. 314 Justification. Separation of management and data plane enables the 315 application of separate and appropriate controls to each channel, 316 and reduces the possibility that a vulnerability in one area/ 317 environment (data forwarding) could have an adverse impact on 318 another area (control/management). For example, imagine that a 319 "killer packet" or buffer overrun is discovered that allows 320 arbitrary users of a public network to crash the data forwarding 321 elements of a router. If data forwarding and management elements 322 are separated, it is likely that the management elements will 323 continue to function, allowing the network operator to evaluate 324 and respond to the problem. If they are not separated (e.g., they 325 both use the same interfaces and share an operating system and IP 326 stack), then it is likely that the entire device will crash or 327 become unmanageable. 329 Examples. One way to satisfy this requirement would be to do all of 330 the following 332 * Implement management and forwarding planes using separate 333 Operating Systems and IP stacks. 335 * Do not allow forwarding between management and data planes. 337 * Disable (or do not implement) all management functions (e.g., 338 telnet, FTP, TFTP, SSH, SNMP, HTTP, etc.) on the data plane. 340 Warnings. None. 342 2.4 User Interface Requirements 344 2.4.1 Display All Configuration Settings 346 Requirement. The device MUST provide a mechanism to display a 347 complete listing of all possible configuration settings and their 348 current values. This MUST include values for any "hidden" 349 commands. It MUST be possible to display all values, even those 350 that are disabled, "off," or set to default values. 352 Justification. It is not possible to perform thorough audits without 353 a complete listing of all possible configuration settings and 354 their current values. 356 Examples. Sometimes default settings change between releases, for 357 example an older release of software may enable directed 358 broadcasts by default while the newer one disables it. If the 359 device only displays non-default settings, then the customer/ 360 auditor must keep a list of software versions and default settings 361 in order to insure that device configuration complies with local 362 policy (e.g. "directed broadcasts must be disabled"). The task of 363 auditing for policy compliance is made much simpler if there is a 364 way to display *all* settings, default or otherwise. 366 Warnings. It has been stated that it may be unreasonable to expect 367 vendors to expose all settings, as this would lead to confusion 368 due to customers changing settings that did not apply to their 369 situation, and could drive up support costs. 371 2.5 IP Stack Requirements 373 2.5.1 Ability to Disable Processing of Packets Utilizing IP Options 375 Requirement. The device MUST provide a means to disable processing of 376 all packets utilizing IP Options. This option MUST be available 377 on a per-interface basis. It MUST be possible to individually 378 configure which options are processed. Source routing SHOULD be 379 disabled by default. 381 Justification. Options can be used to alter normal traffic flows and 382 thus circumvent network-based access control mechanisms (such as 383 firewalls). They can also be used to provide information (such as 384 routes taken) that could be useful to an attacker mapping a 385 network. 387 Examples. None. 389 Warnings. RFC791 says "The Options provide for control functions 390 needed or useful in some situations but unnecessary for the most 391 common communications... [options] must be implemented by all IP 392 modules (host and gateways). What is optional is their 393 transmission in any particular datagram, not their implementation" 395 2.5.2 Support Denial-Of-Service (DoS) Tracking 397 Requirement. The device MUST include native "spoofed" packet 398 tracking. This feature: 400 * MUST be able to capture data to a tracking table that shows how 401 many packets match a configurable layer 3/4 header pattern or 402 list of patterns from each previous hop router. 404 * MUST display the interface on which a matching packet arrived. 406 * MUST display the layer-2 header information. 408 * MUST implement "unknown source" as an optional part of the 409 header pattern where "unknown" is the set of all addresses that 410 are unreachable by the router (i.e., not in the forwarding 411 table). 413 * MUST be able to display the tracking table showing the pattern 414 that is being tracked and how many matches were received from 415 each previous hop. 417 This feature MUST be implemented with minimal impact to system 418 performance. 420 Justification. This applies in situations where DoS attacks, possibly 421 utilizing spoofed source addresses, must be tracked across one or 422 more routers. Without the capability to track DoS packets, it is 423 possible that an attacker could adversely impact the availability 424 of resources (hosts, routers, network links, etc.) leaving network 425 administrators little to no capability to track and stop the 426 attack. Layer 2 header information is particularly useful for 427 identifying spoofed sources coming in over an Ethernet interface 428 at a peering point and you want to track the source back to a 429 particular ISP so you can ask them to trace the source. 431 Examples. 433 These features must allow the customer to quickly and easily ask 434 the router which packets matching a given profile came into the 435 router, from where, and how many from each source. 437 Warnings. None. 439 2.5.3 Traffic Monitoring 441 Requirement. The device MUST provide a means to monitor selected 442 traffic through the system. It MUST provide the ability to select 443 specific traffic patterns for monitoring based on arbitrary IP 444 header patterns and layer 4 (TCP and UDP) header patterns. This 445 includes: source and destination IP address, IP header flags, 446 layer 4 source and destination ports (TCP, UDP), ICMP type and 447 code fields, and other IP protocol types (e.g., 50 - ESP, 47 - 448 GRE, etc.). It MUST provide the ability to monitor the full 449 contents of the packets. This feature MUST be implemented with 450 minimal impact on system performance. In addition, the device MUST 451 provide a means to remotely capture the data being monitored. 453 Justification. This requirement applies in contexts where traffic 454 headers and content must be monitored. This enables 455 characterization of malicious (and non-malicious) traffic, which 456 may be essential to enable effective response and maintain normal 457 operations. 459 Examples. 461 The addition of any traffic monitoring facility must be 462 implemented with minimal impact on system performance. 464 Remote capture of header data could be implemented by sending it 465 via syslog or SNMP. For the full packet capture, the device may 466 send this information over the network for small data streams, or 467 provide a "port mirroring" capability for large data streams where 468 the data would be duplicated out a second configurable port. 470 Warnings. Monitoring data can add significant network traffic, 471 processor, and memory use. 473 2.5.4 Traffic Sampling 475 NOTE: there is a proposed IETF working group active in this area. See 476 the mailing list archives at https://ops.ietf.org/lists/psamp/. It is 477 possible this section may just reference the product of that working 478 group. 480 Requirement. The device MUST provide a means to sample traffic 481 through the system and summarize data from the layer 3 and 4 482 headers. 484 It MUST be possible to dump the cache at specified intervals to a 485 collection host. It MUST be possible to specify device behavior 486 when the cache is full. Options SHOULD include: dumping the cache 487 to the specified collection host(s), clearing the cache, 488 overwriting the cache, and disabling further sampling. The cache 489 SHOULD be implemented as a circular buffer such that older entries 490 are overwritten first. The device SHOULD provide options to 491 manually dump or clear the cache. 493 The device SHOULD provide a means of summarizing sampled data. 494 The following IP layer header information SHOULD be summarized 495 appropriately: type of service (or DS field), total length, 496 protocol, source, and destination. The following TCP/UDP header 497 information SHOULD be summarized appropriately: source port, 498 destination port, UDP packet length, TCP header length, and TCP 499 flag bits. 501 The device MUST provide the ability to select the traffic-sampling 502 rate. For instance, there MUST be a way to sample every nth 503 packet, where n is a number determined by an authorized user and 504 entered into the system configuration file. This feature must be 505 implemented with minimal impact on system performance. 507 Justification. This requirement enables accurate characterization of 508 data transiting the device. This supports identification of and 509 response to malicious traffic. 511 Examples. This requirement MAY be satisfied by allowing the user to 512 specify that 1 in every N packets should be sampled. 514 Warnings. Traffic sampling can add significant network traffic, 515 processor, and memory use. 517 2.5.5 Ability To Remove In-Band Visibility 519 Requirement. The device MUST provide a mechanism to allow it to 520 become a "black box" as seen from public interfaces. Specifically 521 this means: 523 * The device SHOULD not accept any packets beyond those required 524 to support routing information transfer. 526 * The device SHOULD NOT generate any packets beyond those 527 required to support routing information transfer. This includes 528 ICMP error messages. 530 While the default configuration of the device SHOULD be fully RFC 531 compliant (including the sending of ICMP messages), it MUST be 532 possible to alter the default configuration such that the device 533 is "stealthed" (i.e., does not send ICMP messages or otherwise 534 respond directly to packets directed to it on non-management 535 interfaces). 537 Justification. This applies to devices comprising the core network 538 infrastructure. This enforces out of band only access, and ensures 539 that risk to the core infrastructure from end users is minimized. 541 Examples. Some specific capabilities important to stealthing include: 543 * Ability to filter/deny/ignore pings (ICMP echo requests) 545 * Ability to filter on individual protocol header bits 547 * Ability to control the generation of ICMP messages, including 548 port unreachable and timeouts 550 It MUST be possible to configure each of these settings 551 individually. 553 Warnings. Although some STEALTHING MECHANISMS MAY BE IN VIOLATION OF 554 SOME RFCs, they are desirable/necessary in certain circumstances 555 for security and operational reasons. 557 2.6 Basic Filtering Capabilities 559 2.6.1 Ability to Filter Without Performance Degradation 561 Requirement. The device MUST provide a means to filter packets 562 without performance degradation. The device MUST be able to filter 563 on ALL interfaces (up to the maximum number possible) 564 simultaneously and with multiple filters per interface (e.g., 565 inbound and outbound). 567 Justification. This is important because it enables the 568 implementation of filtering wherever and whenever needed. To the 569 extent that filtering causes degradation, it may not be possible 570 to apply filters that implement the appropriate policies. 572 Examples. Another way of stating the requirement is that filter 573 performance should not be the limiting factor in device 574 throughput. If a device is capable of forwarding, say, 30Mb/sec 575 without filtering, then it should be able to forward the same 576 amount with filtering in place. This requirement most likely 577 implies a hardware-based solution (ASIC). 579 Warnings. Without hardware based filtering, it may be possible for 580 the implementation of filters to degrade the performance of the 581 device or to cause it to cease functioning. 583 2.7 Packet Filtering Criteria 585 2.7.1 Ability to Filter on Layer 2 MAC Addresses 587 Requirement. Filters in layer 2 devices MUST be able to filter based 588 on Media Access Control (MAC) addresses. 590 Justification. This provides a level of control that may be needed to 591 enforce policy and respond to malicious activity. 593 Examples. Policy may require, for example, that personal systems not 594 be allowed to connect to the internal desktop network. Restricting 595 the MAC addresses on a port is one way of enforcing this. 597 Warnings. None. 599 2.8 Event Logging Requirements 601 2.8.1 Ability to Log All Security Related Events 603 Requirement. The logging facility MUST be capable of logging any 604 event that affects system security. 606 Justification. Having the device log all events that might impact 607 system security promotes accountability and enables audit-ability. 609 Examples. 611 The list of items that must be logged includes, but is not limited 612 to, the following events: 614 * Filter matches." 616 * Authentication failures (e.g., bad login attempts) 618 * Authentication successes (e.g., user logins) 620 * Authorization changes (e.g., User privilege level changes) 622 * Configuration changes (e.g., command accounting) 624 * Device status changes (interface up/down, etc.) 626 Warnings. None. 628 2.8.2 Ability to Select Reliable Delivery 630 Requirement. It MUST be possible to select reliable, sequenced 631 delivery of log messages. . 633 Justification. Reliable delivery is important to the extent that log 634 data is depended upon to make operational decisions and forensic 635 analysis. Without reliable delivery, log data becomes a 636 collection of hints. 638 Examples. One example of reliable syslog delivery is defined in 639 [RFC3195]. Syslog-ng provides another example, although the 640 protocol has not been standardized. 642 Warnings. None. 644 2.8.3 Ability to Classify Events 646 Requirement. The device SHOULD provide a mechanism for assigning 647 classifications to all messages. At a minimum, it MUST provide 648 the ability to assign a chosen classification to all security 649 related messages, and different classification(s) to all other 650 messages. 652 Justification. This is important because it allows messages of 653 certain types to be sent to different servers for processing. 654 This is important in environments with large numbers of devices, 655 large numbers of log messages, and/or where responsibilities for 656 certain classes of messages are divided. 658 Examples. This requirement MAY be satisfied by providing a mechanism 659 to assign specific syslog facility codes to specific messages or 660 groups of messages. For example, all security events could be 661 assigned to one facility code, all network routing issues to 662 another, and all physical (power, line card) to another. 664 Warnings. None. 666 2.8.4 Logs Do Not Contain DNS Names by Default 668 Requirement. By default, log messages MUST NOT contain DNS names 669 resolved at the time the message was generated. The device MAY 670 provide a facility to incorporate translated DNS names in addition 671 to the IP address. 673 Justification. This is important because IP to DNS mappings change 674 over time and mappings done at one point in time may not be valid 675 later. Also, the use of the resources (memory, processor, time, 676 bandwidth) required to do the translation could result in *no* 677 data being sent/logged, and, in the extreme case could lead to 678 degraded performance and/or resource exhaustion. 680 Examples. None. 682 Warnings. DNS name translation can impose significant performance 683 delays. 685 2.9 Authentication, Authorization, and Accounting (AAA) Requirements 687 2.9.1 Enforce Selection of Strong Local Static Authentication Tokens 688 (Passwords) 690 Requirement. Strength checks for static passwords fall into three 691 types: 693 1. computational checks against the password itself (length, 694 character set, upper/lower case) 696 2. comparison checks against static data sets (dictionary tests) 698 3. comparison checks against dynamic data sets (history checks, 699 username tests) 701 The device MUST support at least computational checks with the 702 following minimum requirements: The password MUST be at least [6] 703 characters long and MUST contain at least [3] of the following 704 elements 706 * At least [1] Lower case alphabetic character 708 * At least [1] Upper case alphabetic character 710 * At least [1] Numeric character 712 * At least [1] Special character 714 The device MAY enforce the selection of "strong" local passwords 715 through comparison checks against dynamic and/or static data sets. 717 Justification. Trivial passwords are easily guessed, increasing the 718 likelihood of unauthorized access. 720 Examples. An initial configuration dialog may require the user to set 721 a password to control initial access. If the user enters a 722 password that is not strong (e.g. "123") then the configuration 723 dialog should inform the user that the chosen password is weak and 724 provide another opportunity to select a strong password. 726 Warnings. 728 2.9.2 Support Device-to-Device Authentication 729 Requirement. The device MUST support device-to-device authentication 730 for all non-interactive management protocols. 732 Justification. This is required to allow automated management 733 functions to operate with a reasonable level assurance that 734 updates and sharing of management information is occurring only 735 with authorized devices. 737 Examples. Examples of protocols that implement device to device 738 authentication are: SNMP (community strings), NTP and BGP (shared 739 keys). 741 Warnings. None. 743 2.10 Layer 2 Requirements 745 2.10.1 Filtering MPLS LSRs 747 Requirement. The device MUST provide a method to filter packets based 748 on layer 3 and 4 criteria on Label Switch Routers (LSRs) 749 regardless of whether they are encapsulated using Multi Protocol 750 Label Switching (MPLS). The MPLS encapsulated packets MUST NOT be 751 allowed to bypass IP filters. Logging facilities MUST provide 752 sufficient information so that the previous hop for a logged 753 packet can be determined. Packets tagged with MPLS labels MUST be 754 treated as IP packets when crossing an interface on which a filter 755 is applied. Encapsulation/decapsulation MAY take place before or 756 after the filter as long as it does not cause the filters to be 757 ignored. When logging the input interface information for hits on 758 outgoing filter list rules, any MPLS label that was present when 759 the packet was received MUST be logged with the input interface. 760 This functionality is equivalent to the requirement that all layer 761 2 source information must be logged when the input interface is 762 logged. Also, the addition of any filtering and logging MUST be 763 implemented with no significant performance degradation to the 764 normal system operations. 766 Justification. This is important because it may be necessary to 767 filter traffic encapsulated in a LSP. This applies primarily to 768 backbone and large core networks. 770 Examples. None. 772 Warnings. None. 774 2.10.2 VLAN Isolation 776 Requirement. The device MUST NOT allow VLAN Hopping. This applies to 777 the insertion of falsified VLAN IDs or 802.1Q (or equivalent) tags 778 into frames in an attempt to hop from one VLAN to another while 779 traversing the switch. Many VLAN implementations allow hopping if 780 the native VLAN (usually VLAN 1) is set up as the trunk port. If 781 this is the case then the default configuration on the switch MUST 782 NOT allow the trunk port to be set as the native VLAN. Also the 783 switch MUST NOT broadcast ARP requests across VLANs. 785 Justification. This requirement is intended to ensure that layer 2 786 traffic remains isolated to designated VLANs. It applies in 787 situations where data on different VLAN segments have different 788 sensitivity classification. 790 Examples. None. 792 Warnings. None. 794 2.10.3 Layer 2 Denial-of-Service 796 Requirement. It MUST NOT be possible for users connected to a switch 797 port to perform an action which results in denial of service to 798 other users connected to the switch. Examples of denial of service 799 would include: 801 * Causing the switch to crash 803 * Causing long delays (e.g., by forcing spanning tree 804 recalculations) 806 * Redirecting/stealing traffic 808 Justification. This requirement is needed to ensure the 809 confidentiality and availability of data transmitted via the 810 switch. 812 Examples. None. 814 Warnings. None. 816 3. Documentation Requirements 818 The requirements in this section are intended to list information 819 that will assist operators in evaluating and securely operating a 820 device. 822 3.1 Provide a List of All Protocols Implemented 824 Requirement. The vendor SHOULD provide a concise list all protocols 825 implemented by the device. 827 Justification. This facilitates thorough and appropriately targeted 828 testing. 830 Examples. The documentation should contain a concise list in the 831 system/release documentation describing the protocols implemented 832 (link,network,transport,management, routing, etc.) 834 Warnings. None. 836 3.2 Provide Documentation for All Protocols Implemented 838 Requirement. The vendor SHOULD provide references to publicly 839 available specifications for all protocols implemented. 841 Justification. Security thorough obscurity is bad policy. Closed, 842 undocumented protocols that have not undergone through public 843 review may contain undiscovered (by the vendor) vulnerabilities 844 that can easily be exploited. Open, documented protocols 845 facilitate thorough and appropriately targeted testing. 847 Examples. None. 849 Warnings. It is acknowledged that there may be valid business or 850 other non-technical reasons for not releasing documentation for 851 protocols. This requirement should be evaluated on a case-by-case 852 basis. 854 3.3 Catalog of Log Messages Available 856 Requirement. The vendor SHOULD specify a catalog of all messages that 857 a device can emit. This SHOULD be included with every release of 858 software for the device. The contents of variable portions of 859 each message (IP address, hostname, timestamp, etc.) SHOULD be 860 documented. 862 Justification. A complete catalog of all possible messages permits 863 the customer to automate response to possible events. 865 Examples. If the device sends syslog messages, then the documentation 866 should contain a list of all possible syslog messages. 868 Warnings. None. 870 4. Assurance Requirements 872 The requirements in this section are intended to 874 o identify behaviors and information that will increase confidence 875 that the device will meet the security functional requirements. 877 o Provide information that will assist evaluation 879 4.1 Ability to Withstand Well-Known Attacks and Exploits 881 Requirement. The vendor MUST provide software updates or 882 configuration advice "in a timely fashion" to mitigate the effect 883 of "well know vulnerabilities" in the device itself and "well 884 known exploits" directed to the device. These updates or 885 configuration changes MUST NOT result in a reduced feature set - 886 except in cases where removing a feature entirely is the ONLY way 887 to stop the exploit. Updates SHOULD NOT introduce new features. 888 Vendors MUST NOT require customers to pay a fee or purchase 889 support (or other) contracts in order to obtain exploit fixes. 890 These requirements only apply to devices that are supported that 891 the time the exploit or vulnerability becomes "well known". 893 For the purpose of this document, well-known vulnerabilities and 894 exploits are defined as those that have been published by the 895 following: 897 * Computer Emergency Response Team Coordination Center [CERT/CC] 898 Advisories 900 * Common Vulnerabilities and Exposures [CVE] entries 902 * Standard Nessus [Nessus] Plugins 904 * Vendor security bulletins for the device in question. 906 * The [PROTOS] test suite 908 While "in a timely fashion" is open to interpretation, one 909 measurable, customer-centric metric is "before the vulnerability 910 is exploited in my device causing loss of confidentiality, 911 integrity or availability". 913 Justification. Product vulnerabilities and tools to exploit 914 vulnerabilities are all constantly evolving. A configuration that 915 is secure one day may be insecure the next due to the discovery of 916 a new vulnerability or the release of a new exploit script. 918 Devices that are vulnerable to known exploits may be easily 919 compromised or disabled. This can affect confidentiality, 920 availability, and data integrity. 922 Examples. Take for example the SNMP vulnerabilities described in 923 [CERT.2002-03]. These vulnerabilities were discovered and a 924 toolkit for exploiting them was publicly released. What this 925 requirement is saying is that known vulnerabilities such as this 926 should be fixed. 928 It is up to the customer/operator to verify to their satisfaction 929 that the system is "bug free" and free of known exploits. Some 930 possible methods of doing this include 932 * Taking the vendors word 934 * Testing for themselves 936 * Relying on 3rd party testing/certification 938 Warnings. It is acknowledged that the number of known vulnerabilities 939 is constantly expanding and that it is not possible to prove that 940 any system is completely bug and vulnerability free. Any test or 941 "certification" of a device to show compliance with this 942 requirement will be an approximation at a point in time. The most 943 that can be shown is that a given list of exploits failed. 945 4.2 Vendor Responsiveness 947 Requirement. The vendor MUST be responsive to current and future 948 security requirements as specified by the customer. When new 949 security exploits are discovered, either by the customer or the 950 public, the vendor MUST provide patches or workarounds in a timely 951 fashion to mitigate the threat from any existing vulnerability in 952 the system. The vendor MUST ensure that it remains actively aware 953 of security threats. 955 Justification. This is important because new vulnerabilities are 956 regularly discovered. Slow vendor response to vulnerabilities 957 increase the level of risk/window of opportunity for exploit. This 958 requirement applies to ALL devices. 960 Examples. This is a non-technical requirement. The implementation 961 involves process, customer support, engineering, etc. 963 Warnings. This "requirement" has a large element of subjectivity. 964 When evaluating vendor responsiveness, objective data (such as 965 mean time to releasing patches for new exploits) should be 966 evaluated. 968 5. Security Considerations 970 Security is the subject matter of this entire memo. It might be more 971 appropriate to list operational considerations. Operational issues 972 are mentioned as needed in the examples and warnings sections of each 973 requirement. 975 References 977 [CERT.2002-03] 978 CERT/CC, "Multiple Vulnerabilities in Many Implementations 979 of the Simple Network Management Protocol (SNMP)", 2002, 980 . 982 [CERT/CC] CERT/CC, "CERT/CC Advisories", 2003, . 985 [CVE] The MITRE Corporation, "MITRE Common Vulnerabilities and 986 Exposures", 2003, . 988 [I-D.gill-gtsh] 989 Gill, V., Heasley, J. and D. Meyer, "The Generalized TTL 990 Security Mechanism (GTSM)", draft-gill-gtsh-04 (work in 991 progress), October 2003. 993 [Nessus] Deraison, R., "Nessus Security Scanner", 2003, . 996 [PROTOS] University of Oulu, "PROTOS Test Suites", 2003, . 999 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1000 1981. 1002 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1003 Requirement Levels", BCP 14, RFC 2119, March 1997. 1005 [RFC3195] New, D. and M. Rose, "Reliable Delivery for syslog", RFC 1006 3195, November 2001. 1008 Author's Address 1010 George M. Jones, Editor 1011 The MITRE Corporation 1012 7525 Colshire Dr., WEST 1013 McLean, VA 22102 1014 U.S.A. 1016 Phone: +1 703 488 9740 1017 EMail: gmjones@mitre.org 1018 URI: http://www.port111.com/opsec/ 1020 Appendix A. Acknowledgments 1022 This document grew out of an internal security requirements document 1023 used by UUNET for testing devices that were being proposed for 1024 connection to the backbone. 1026 The editor gratefully acknowledges the contributions of: 1028 o Greg Sayadian, author of a predecessor of this document. 1030 o Eric Brandwine, a major source of ideas/critiques. 1032 o The MITRE Corporation for supporting continued development of this 1033 document. NOTE: The editor's affiliation with The MITRE 1034 Corporation is provided for identification purposes only, and is 1035 not intended to convey or imply MITRE's concurrence with, or 1036 support for, the positions, opinions or viewpoints expressed by 1037 the editor. 1039 o UUNET's entire network security team (past and present): Jared 1040 Allison, Eric Brandwine, Clarissa Cook, Dave Garn, Tae Kim, Kent 1041 King, Neil Kirr, Mark Krause, Michael Lamoureux, Maureen Lee, Todd 1042 MacDermid, Chris Morrow, Alan Pitts, Greg Sayadian, Bruce Snow, 1043 Robert Stone, Anne Williams, Pete White. 1045 o Others who have provided significant feedback at various stages of 1046 the life of this document are: Ran Atkinson, Fred Baker, Steve 1047 Bellovin, Michael H. Behringer, Matt Bishop, Scott Blake, Randy 1048 Bush, Steven Christey, Sean Donelan, Robert Elmore, Barry Greene, 1049 Dan Hollis, Merike Kaeo, John Kristoff, Chris Liljenstolpe, James 1050 W. Laferriere, Alan Paller, Rob Pickering, Gregg Schudel, Rodney 1051 Thayer, David Walters, Anthony Williams, Neal Ziring 1053 o Madge B. Harrison, technical writing review. 1055 o This listing is intended to acknowledge contributions, not to 1056 imply that the individual or organizations approve the content of 1057 this document. 1059 o Apologies to those who commented on/contributed to the document 1060 and were not listed...contact the editor to be credited in future 1061 versions 1063 Version: $Id: draft-jones-opsec-01.cpp,v 1.2 2003/08/13 17:45:25 1064 george Exp $ 1066 Intellectual Property Statement 1068 The IETF takes no position regarding the validity or scope of any 1069 intellectual property or other rights that might be claimed to 1070 pertain to the implementation or use of the technology described in 1071 this document or the extent to which any license under such rights 1072 might or might not be available; neither does it represent that it 1073 has made any effort to identify any such rights. Information on the 1074 IETF's procedures with respect to rights in standards-track and 1075 standards-related documentation can be found in BCP-11. Copies of 1076 claims of rights made available for publication and any assurances of 1077 licenses to be made available, or the result of an attempt made to 1078 obtain a general license or permission for the use of such 1079 proprietary rights by implementors or users of this specification can 1080 be obtained from the IETF Secretariat. 1082 The IETF invites any interested party to bring to its attention any 1083 copyrights, patents or patent applications, or other proprietary 1084 rights which may cover technology that may be required to practice 1085 this standard. Please address the information to the IETF Executive 1086 Director. 1088 Full Copyright Statement 1090 Copyright (C) The Internet Society (2003). All Rights Reserved. 1092 This document and translations of it may be copied and furnished to 1093 others, and derivative works that comment on or otherwise explain it 1094 or assist in its implementation may be prepared, copied, published 1095 and distributed, in whole or in part, without restriction of any 1096 kind, provided that the above copyright notice and this paragraph are 1097 included on all such copies and derivative works. However, this 1098 document itself may not be modified in any way, such as by removing 1099 the copyright notice or references to the Internet Society or other 1100 Internet organizations, except as needed for the purpose of 1101 developing Internet standards in which case the procedures for 1102 copyrights defined in the Internet Standards process must be 1103 followed, or as required to translate it into languages other than 1104 English. 1106 The limited permissions granted above are perpetual and will not be 1107 revoked by the Internet Society or its successors or assignees. 1109 This document and the information contained herein is provided on an 1110 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1111 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1112 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1113 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1114 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1116 Acknowledgment 1118 Funding for the RFC Editor function is currently provided by the 1119 Internet Society.