idnits 2.17.1 draft-cain-logging-caps-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1050. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1027. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1034. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1040. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 abstract seems to contain references ([CURPRAC]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (September 15, 2006) is 6404 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'CURPRAC' == Outdated reference: A later version (-05) exists of draft-ietf-opsec-framework-03 ** Downref: Normative reference to an Informational draft: draft-ietf-opsec-framework (ref. 'FRMWK') ** Downref: Normative reference to an Informational RFC: RFC 1492 ** Downref: Normative reference to an Informational RFC: RFC 2196 ** Obsolete normative reference: RFC 2271 (Obsoleted by RFC 2571) ** Obsolete normative reference: RFC 3164 (Obsoleted by RFC 5424) -- Possible downref: Non-RFC (?) normative reference: ref. 'SP800-92' Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSEC P. Cain 3 Internet-Draft The Cooper-Cain Group, Inc. 4 Expires: March 19, 2007 G. Jones 5 The MITRE Corporation 6 September 15, 2006 8 Logging Capabilities for IP Network Infrastructure 9 draft-cain-logging-caps-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 19, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document lists logging capabilities originally defined in 43 RFC3871 and needed to support the current practices, including those 44 described in the Operational Security Current Practices 45 document[CURPRAC] Logging is defined as the delivery to another 46 entity or system of messages about the device, the data passing 47 through the device, or the device's interaction with another device. 49 Capabilities are defined without reference to specific technologies. 50 This is done to leave room for deployment of new technologies that 51 implement the capability. Each capability cites the practices it 52 supports. Current implementations that support the capability are 53 cited. Special considerations are discussed as appropriate listing 54 operational and resource constraints, limitations of current 55 implementations, trade offs, etc. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. Capabilities vs. Requirements ? . . . . . . . . . . . . . 4 62 1.3. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 64 2. Functional Capabilities of Log Generating Systems . . . . . . 6 65 2.1. Logging Facility Uses Protocols Subject To Open Review . . 6 66 2.2. Logs Sent To Remote Servers . . . . . . . . . . . . . . . 7 67 2.3. Ability to Select Reliable Delivery . . . . . . . . . . . 8 68 2.4. Ability to Remotely Log Securely . . . . . . . . . . . . . 8 69 2.5. Ability to Log Locally . . . . . . . . . . . . . . . . . . 9 70 2.6. Ability to Log Different Severities to Different 71 Destinations . . . . . . . . . . . . . . . . . . . . . . . 10 72 2.7. Ability to Log to Multiple Destinations . . . . . . . . . 11 73 2.8. Ability to Maintain Accurate System Time . . . . . . . . . 12 74 2.9. Display Timezone And UTC Offset . . . . . . . . . . . . . 13 75 2.10. Default Timezone Should Be UTC . . . . . . . . . . . . . . 14 76 2.11. Log Entries Must Be Timestamped . . . . . . . . . . . . . 14 77 2.12. Log on Exception or Identifed Event . . . . . . . . . . . 15 78 2.13. Logs Contain Untranslated IP Addresses . . . . . . . . . . 16 79 2.14. Logs Contain Records Of Security Events . . . . . . . . . 17 80 2.15. Logs Do Not Contain Passwords . . . . . . . . . . . . . . 18 81 2.16. Devices Should Log Every Message . . . . . . . . . . . . . 19 82 2.17. Syslog-specific Capabilties . . . . . . . . . . . . . . . 20 83 2.17.1. Configurable Facility Values . . . . . . . . . . . . 20 84 2.17.2. Configurable Destination UDP Port . . . . . . . . . . 20 85 2.18. SNMP-specific capabilities . . . . . . . . . . . . . . . . 21 86 2.18.1. Read-only Operations Supported . . . . . . . . . . . 21 87 2.18.2. Restrict Returning Data to specific Hosts . . . . . . 22 88 2.18.3. Only Return Specific Data to Requestor . . . . . . . 22 89 3. Additional Operational Practices . . . . . . . . . . . . . . . 24 90 4. Security Considerations . . . . . . . . . . . . . . . . . . . 25 91 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 92 6. Normative References . . . . . . . . . . . . . . . . . . . . . 26 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 94 Intellectual Property and Copyright Statements . . . . . . . . . . 28 96 1. Introduction 98 The Framework for Operational Security Capabilities [FRMWK] outlines 99 the proposed effort of the IETF OPSEC working group. This includes 100 producing a series of drafts to codify knowledge gained through 101 operational experience about feature sets that are needed to securely 102 deploy and operate managed network elements providing transit 103 services at the data link and IP layers. Current plans include 104 separate capabilities documents for Packet Filtering; Event Logging; 105 In-Band and Out-of-Band Management; Configuration and Management 106 Interfaces; AAA; and Documentation and Assurance. [CURPRAC] defines 107 the goals, motivation, scope, definitions, intended audience, threat 108 model, potential attacks and give justifications for each of the 109 practices. 111 1.1. Threat Model 113 The logging capabilities are derived from real world observations 114 where unexpected activities in a network infrastructure caused 115 concern to the network operator. Examples of such activities are: 117 An adversary or unauthorized user login into an infrastructure 118 device. The risk is that the configuration or other operating 119 parameter could be modified. 121 A device becomes overwhelmed, throttles, or crashes. Without 122 logging or some other mechanism to notifify the operator of the 123 condition, the operator will not know that action is required to 124 return the device to optimal operating condition. 126 Network problems cannot be properly diagnosed without information. 127 Information does not exist unless generated. 129 Threats to the network devices may be classified into broad 130 categories such as: 132 * Unexpected device status or configuration change * Failure to 133 send log messages * Interception of log messages * Failure to 134 store log messages 136 The main technical issues revolve around what events generate a log 137 entry, what mechanisms are used to secure the logged information 138 while it is in transit and while it is stored, and how long are logs 139 retained. Note that guidance in both RFC3871 and the FRAMEWORK 140 documents restrict capabilities to log event generators, so other 141 elements in a logging infrastructure, such as event collection or 142 archival systems, are not discussed in this document. A good 143 overview of building and operating a log infrastructure can be found 144 in NIST Publication 800-62. [SP800-92] 146 One unintended threat to the loggin infrastructure is a self- 147 inflicted denial-of-service attack due to an overwheming amount of 148 log messages on the local machine -- such that the local system is 149 using all it's available effort to capture log messages -- or through 150 the network between the log generator and the log collector -- such 151 that the remore system is innaccesible to management operations. 152 Although not specifically a capability, care should be taken when 153 configuring the logging infrastructure to account for this threat. 155 Although most people equate logging with using the syslog protocol, 156 other protocols such as SNMP [RFC2271] are quite capable of 157 generating a log entry for transmission to a remote log entry 158 collector. 160 1.2. Capabilities vs. Requirements ? 162 Capabilities may or may not be requirements. That is a local 163 determination that must be made by each operator with reference to 164 the policies that they must support. This document, together with 165 [CURPRAC] will assist network operators in identifying their security 166 capability requirements and communicating them clearly to vendors. 168 1.3. Format 170 Each capability has the following subsections: 172 o Capability (what) 174 o Discussion 176 o Supported Practices (why) 178 o Current Implementations (how) 180 o Considerations (caveats, resource issues, protocol issues, etc.) 182 The Capability section describes a feature to be supported by the 183 device. The Supported Practice section cites practices described in 184 [CURPRAC] that are supported by this capability. The Current 185 Implementation section is intended to give examples of 186 implementations of the capability, citing technology and standards 187 current at the time of writing. It is expected that the choice of 188 features to implement the capabilities will change over time. The 189 Considerations section lists operational and resource constraints, 190 limitations of current implementations, trade offs, etc. 192 1.4. Definitions 194 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 195 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 196 document are to be interpreted as described in [RFC2119]. 198 The use of the RFC 2119 keywords is an attempt, by the author, to 199 assign an expectation level ("MUST", "SHOULD", "MAY") to the each 200 capability. It must be noted that different organizations, 201 operational environments, policies and legal environments will 202 generate different requirement levels. 204 NOTE: This document defines capabilities. This document does not 205 define requirements, and there is no requirement that any particular 206 capability be implemented or deployed. The use of the terms MUST, 207 SHOULD, and so on are in the context of each capability in the sense 208 that if you conform to any particular capability then you MUST or 209 SHOULD do what is specified for that capability, but there is no 210 requirement that you actually do conform to any particular 211 capability. 213 2. Functional Capabilities of Log Generating Systems 215 The capabilities in this section are intended to list testable, 216 functional capabilities that are needed to operate devices securely 217 and meet the obligations of Section 1.1Threat Model. 219 2.1. Logging Facility Uses Protocols Subject To Open Review 221 Capability 223 The device provides a logging facility that is based on protocols 224 subject to open review. Custom or proprietary logging protocols 225 MAY be implemented provided the same information is made 226 available. 228 Discussion 230 The use of logging based on protocols subject to open review 231 permits the operator to perform archival and analysis of logs 232 without relying on vendor-supplied software and servers. . 234 Supported Practices. 236 * syslog 238 * syslog with reliable delivery 240 * SNMP with applicable security controls 242 Current Implementations 244 This capability can be satisfied by the use of one or more of 245 syslog [RFC3164], syslog with reliable delivery [RFC3195], TACACS+ 246 [RFC1492], RADIUS [RFC2865] or SNMP [RFC2271]. 248 The current best solution seems to be the following: 250 * Implement syslog [RFC3164]. 252 * Consider implementing syslog with reliable delivery [RFC3195]. 254 Considerations 256 None. 258 2.2. Logs Sent To Remote Servers 260 Capability 262 The device MUST support transmission of records of security 263 related events to one or more remote collection devices. There 264 MUST be configuration settings on the device that allow selection 265 of destination servers. 267 Discussion 269 None. 271 Supported Practices 273 * Use multiple collection devices to enhance reliability. 275 * Use different collection devices to segregate different event 276 sensitivity levels. 278 Current Implementations 280 This capability may be satisfied by the use of one or more of: 281 syslog [RFC3164], syslog with reliable delivery [RFC3195], TACACS+ 282 [RFC1492], or RADIUS [RFC2865]. 284 Considerations 286 This is important because it supports individual accountability. 287 It is important to store them on a separate server to preserve 288 them in case of failure or compromise of the managed device. 290 Note that there may be privacy or legal considerations when 291 logging/monitoring user activity. 293 High volumes of logging may generate excessive network traffic 294 and/or compete for scarce memory and CPU resources on the device. 296 2.3. Ability to Select Reliable Delivery 298 Capability 300 It SHOULD be possible to select reliable delivery of log messages. 302 Discussion 304 Reliable delivery is important to the extent that log data is 305 depended upon to make operational decisions and forensic analysis. 306 Without reliable delivery, log data becomes a collection of hints 307 instead of a true record of events. 309 Supported Practices 311 * Use syslog-ng. 313 * Tunnel the logging stream over a TCP-based connection. 315 * Use an out-of-band network to connect critical logging devices 316 to the collection device. 318 Current Implementations 320 One example of reliable syslog delivery is defined in [RFC3195]. 321 Syslog-ng provides another example, although the protocol has not 322 been standardized 324 Considerations 326 Reliable delivery should be used if the path from log event 327 generator to the collection device transits administrative domains 328 or uses unreliable channels, as it is important that the entire 329 stream of leg events is captured. 331 2.4. Ability to Remotely Log Securely 333 Capability 335 The log data stream SHOULD be able to be delivered to the 336 collection device in a confidential manner. 338 Discussion 340 While syslog *could* provide this capability, it has many security 341 issues and by itself does not address issues from the threat 342 model. See the security considerations section of [RFC3164] for a 343 list of issues. Syslog with reliable delivery provides solutions 344 to most/all of these issues, however at the time of this writing 345 there are few implementations. Other possible solutions might be 346 to tunnel syslog over a secure transport...but this often raises 347 difficult key management and scalability issues. 349 Supported Practices 351 * Log data tunnelled within IPSec or SSH. 353 * Use syslog-ng. 355 Current Implementations 357 There is no common implementation of this capability. 359 Considerations 361 As is the reliable delivery capability, delivering log data across 362 untrusted streams or including sensitive data in a event data may 363 require additional countermeasures to protect the data. This 364 concern should not be addressed lightly. 366 ISPs are fully aware that there is no security with syslog but 367 IPSec is considered too operationally expensive and cumbersome to 368 deploy. Syslog-ng and stunnel could be used for better 369 authentication and integrity protected solutions. Mechanisms to 370 prevent unauthorized personnel from tampering with logs is 371 constrained to auditing who has access to the logging servers and 372 files. 374 2.5. Ability to Log Locally 376 Capability 378 It SHOULD be possible to log locally on the device itself. Local 379 logging SHOULD be written to non-volatile storage. . 381 Discussion 383 Logging of failed authentication attempts to local non-volatile 384 storage is critical as it provides a record of events if the 385 device gets isolated from its authentication interfaces or an 386 attack overwhelms the console interface. Local logging is also 387 important for viewing information when connected to the device and 388 it provides some backup of log data in case remote logging fails. 390 Local logging also provides a way to quickly view logs relevant to 391 one device without having to sort through a possibly large set of 392 logs from other devices at the collection device. 394 Supported Practices 396 * To conserve space, only failed device logins and network 397 connectivity issues are logged locally. 399 Current Implementations 401 One example of local logging would be a memory buffer that 402 receives copies of messages sent to the remote log server. 404 Another example might be a local syslog server (assuming the 405 device is capable of running syslog and has some local 406 storage). 408 Considerations 410 Storage on the device may be limited.; high volumes of log 411 messages may quickly fill the available storage, in which case 412 there are two options: new logs overwrite old logs (possibly via 413 the use of a circular memory buffer or log file rotation), or 414 logging stops. 416 2.6. Ability to Log Different Severities to Different Destinations 417 Capability 419 The device SHOULD allow specified severity levels of log message 420 to be delivered to different collection destinations. 422 Discussion 424 A network of multiple devices may generate a significant amount of 425 log data. The ability to send critical log messages, for example 426 a root login, to a specific destination device will enhance the 427 ability of the network operator to notice the critical event. 429 Supported Practices 431 * Email critical event notices to a 24-hour watched mailbox. 433 * Send critical event notices to a separate log collector that 434 scrolls received messages upon a large display in the NOC. 436 Current Implementations 438 There are no common implementations of this capability. 440 Considerations 442 The use of multiple collectors will incur maintenance and 443 reliability issues. In some cases, multiple filters watching a 444 single collection point may be more efficient than using multiple 445 collectors. 447 2.7. Ability to Log to Multiple Destinations 449 Capability 451 The device SHOULD allow log message to be delivered to multiple 452 collection destinations. 454 Discussion 456 All ISPs have multiple syslog servers - some ISPs choose to use 457 separate syslog servers for varying infrastructure devices (i.e., 458 one syslog server for backbone routers, one syslog server for 459 customer edge routers, etc.) This provides a backup mechanism to 460 see what is going on in the network in the event that a device may 461 'forget' to do syslog if the CPU is busy. 463 Supported Practices 465 * Use multiple log servers to enhance reliability. 467 Current Implementations 469 Most ISPs use multiple, sometimes gegraphic-driven, log 470 collectors. 472 Considerations 474 None. 476 2.8. Ability to Maintain Accurate System Time 478 Capability 480 The device MUST maintain accurate, "high resolution" system time. 482 Discussion 484 Accurate time is important to the generation of reliable log data. 485 Accurate time is also important to the correct operation of some 486 authentication mechanisms. 488 The ability to correlate network events from different devices is 489 directly related to the accuracy of the log timestamps. If a 490 timeline cannot be constructed, the event logs and forensic data 491 is useless. 493 Supported Practices 495 * The time is derived from NTP which is generally configured as a 496 flat hierarchy at stratum1 and stratum2 servers to have less 497 configuration and less maintenance issues. 499 * Each router is configured with one stratum1 peer both locally 500 and remotely. 502 Current Implementations 504 This capability may be satisfied by supporting Network Time 505 Protocol (NTP), Simple Network Time Protocol (SNTP), or via direct 506 connection to an accurate time source. 508 Considerations 510 System clock chips are inaccurate to varying degrees. System time 511 should not be relied upon unless it is regularly checked and 512 synchronized with a known, accurate external time source (such as 513 an NTP stratum-1 server). Also note that if network time 514 synchronization is used, an attacker may be able to manipulate the 515 clock unless cryptographic authentication is used.. 517 2.9. Display Timezone And UTC Offset 519 Capability 521 All displays and logs of system time MUST include a timezone or 522 offset from UTC. 524 Discussion 526 None. 528 Supported Practices 530 * The log timestamps include a timezone indicator like "-05:00". 532 Current Implementations 534 Considerations 536 Knowing the timezone or UTC offset makes correlation of data and 537 coordination with data in other timezones possible. Bob is in 538 Newfoundland, Canada which is UTC -3:30. Alice is somewhere in 539 Indiana, USA. Some parts of Indiana switch to daylight savings 540 time while others do not. A user on Bob's network attacks a user 541 on Alice's network. Both are using logs with local timezones and 542 no indication of UTC offset. Correlating these logs will be 543 difficult and error prone. Including timezone, or better, UTC 544 offset, eliminates these difficulties. 546 Notice that a physical location may have different offsets from 547 UTC during a year as summertime, daylight savings time, or other 548 local customs are applied. 550 2.10. Default Timezone Should Be UTC 552 Capability 554 The default timezone for display and logging SHOULD be UTC. The 555 device MAY support a mechanism to allow the operator to specify 556 the display and logging of times in a timezone other than UTC. 558 Discussion 560 Knowing the timezone or UTC offset makes correlation of data and 561 coordination with data in other timezones possible. 563 Supported Practices 565 * The timezone offset can be entered as part of configuration of 566 a device. 568 Implementation 570 Bob in Newfoundland (UTC -3:30) and Alice in Indiana (UTC -5 or 571 UTC -6 depending on the time of year and exact county in Indiana) 572 are working an incident together using their logs. Both left the 573 default settings, which was UTC, so there was no translation of 574 time necessary to correlate the logs. 576 Considerations 578 None. 580 2.11. Log Entries Must Be Timestamped 582 Capability 583 By default, the device MUST timestamp all log messages. The 584 timestamp MUST be accurate to within a second or less. The 585 timestamp MUST include a timezone. There MAY be a mechanism to 586 disable the generation of timestamps. 588 Discussion 590 Accurate timestamps are necessary for correlating events, 591 particularly across multiple devices or with other organizations. 592 This applies when it is necessary to analyze logs.. 594 Supported Practices 596 * Each entry into the log contains a time value. 598 Current Implementations 600 This capability may be satisfied by writing timestamps into syslog 601 messages. 603 Considerations 605 It is difficult to correlate logs from different time zones. 606 Security events on the Internet often involve machines and logs 607 from a variety of physical locations. For that reason, UTC is 608 preferred, all other things being equal.. 610 2.12. Log on Exception or Identifed Event 612 Capability 614 Log entries should be generated on exceptions (e.g., failures) or 615 event matching (e.g., generate a log entry if an event happens) 616 via a configurable value. 618 Discussion 620 Traditionally log events are generated on exceptions -- failures 621 or errors. Many times this is not sufficient as a network 622 operator cannot tell if an attacker failed to log into a device 623 once, or failed once and then succeeded on the second try. 624 Devices should be configurable to allow for log messages on 625 failures, successes, or everything. 627 Supported Practices 629 * Log all login events to a device but only have the collection 630 device alert on failures. 632 * Log on successful device configuration changes since one must 633 be aware of all modifications on some types of devices. 635 Current Implementations 637 Some ISPs put in passive devices to see routing updates and 638 withdrawals and not rely solely on the device for log files. 640 Considerations 642 None. 644 2.13. Logs Contain Untranslated IP Addresses 646 Capability 648 Log messages MUST NOT list translated addresses (DNS names) 649 associated with the address without listing the untranslated IP 650 address where the IP address is available to the device generating 651 the log message. 653 Discussion 655 Although some times less obtuse than DNS names, IP address 656 assignments tend to be more stable than DNS entries. If an 657 operator is trying to correlate a historical event, the DNS name 658 may have been changed from that used at the event. TO ease this 659 confusion, the IP address of the source of the action that caused 660 the log event should be retained in the log entry. 662 Supported Practices 664 * Include the source IP address in all log messages. 666 * Although a corresponding DNS name is useful, DNS lookups can be 667 slow and consume resources. 669 Current Implementations 671 Most devices include the source IP in event logs 673 Considerations 675 A failed network login should generate a record with the source 676 address of the login attempt, but the Source addresses may be 677 spoofed. Network-based attacks often use spoofed source addresses 678 so they should not be completely trusted unless verified by other 679 means. Having accurate timestamps in the logs increases the 680 chances that the use of an address can be correlated to an 681 individual. 683 2.14. Logs Contain Records Of Security Events 685 Capability 687 The device MUST be able to send a record of at least the following 688 events: * authentication successes, * authentication failures, * 689 session Termination, * authorization changes, * configuration 690 changes, * device status changes. 692 The device SHOULD be able to send a record of all other security 693 related events including filtering (or ACL) exceptions, routing 694 protocol state changes, all device access (regardless of 695 authentication success or failure), all commands issued to a 696 device, and all routing events (boot-up/flaps). 698 Discussion 700 The main function of any of these log messages is to see what the 701 device is doing as well as to try and ascertain what certain 702 malicious attackers are trying to do. 704 Typically the data logged will contain the source and destination 705 IP addresses and layer 4 port numbers as well as a timestamp. 707 Supported Practices 709 * Examples of events recorded include: user logins, bad login 710 attempts, logouts, user privilege level changes, individual 711 configuration commands issued by users and system startup/ 712 shutdown events. 714 Current Implementations 716 Most devices crudely support this capability. 718 Considerations 720 This list is far from complete. Note that there may be privacy or 721 legal considerations when logging/monitoring user activity or 722 personal information. 724 This is an important capability because it supports individual 725 accountability and auditing as well as forensics. See section 726 4.5.4.4 of . 728 2.15. Logs Do Not Contain Passwords 730 Capability 732 Passwords SHOULD be excluded, by default configuration, from all 733 audit records, including records of successful or failed 734 authentication attempts. 736 Discussion 738 A user may make small mistakes in entering a password such as 739 using incorrect capitalization ("my password" vs. "My Password"). 740 Event logs are traditional disperse widely so unexpected events 741 will be noticed. Unauthorized access to event logs that contain 742 these mistakes may compromise more than just the network devices 743 as most users do not have independent passwords for every system. 745 Supported Practices 747 * Login failure log messages include the failed username, 748 timestamp, and source IP address, but not the password used. 750 Current Implementations 752 Access control and authorization requirements differ for 753 accounting records (logs) and authorization databases (passwords). 754 Logging passwords may grant unauthorized access to individuals 755 with access to the logs. Logging failed passwords may also give 756 hints about actual passwords. See section 4.5.4.4 of [RFC2196] 758 Considerations 760 There may be situations where it is appropriate/required to log 761 passwords, such as when performing real-time attack analysis. 762 Caution is advised in these rare circumstances. 764 2.16. Devices Should Log Every Message 766 Capability 768 Devices should be configurable to either log every event or to 769 drop events due to congestion. 771 Discussion 773 Many devices implement logging as an afterthought with the device 774 dropping log messages or failing to log critical events when the 775 device is "busy". This behaviour makes forensic analysis 776 difficult, if not impossible. Devices should be configurable to 777 not drop log events at those operator-defined times when this 778 behaviour s expected. 780 Supported Practices 782 * Use multiple logging devices and collectors to capture enough 783 extra messages to be able to recreate a full log. 785 Current Implementations 787 Use multiple logging devices. 789 Considerations Improper configuration or implementation of this 790 capability may open a device, network, or logging infrastructure 791 to a self-inflicted denial-of-service attack. 793 None. 795 2.17. Syslog-specific Capabilties 797 The predominant logging mechanism within network infrastructures is 798 BSD-syslog and its' variants. With such widespread uses, this 799 section identifies capabilities specific to syslog. 801 2.17.1. Configurable Facility Values 803 Capability 805 The device SHOULD allow for the selection of the syslog facility 806 number via configuration. 808 Discussion 810 A network operator may have many similar devices in their network. 811 The ability to segregate different severity events by the 812 strategic use of the syslog facility number is extremely useful. 814 Supported Practices 816 * Authentication log entries are marked at a different facility 817 code to allow for easier segregation at the event collector. 819 Current Implementations 821 Some devices support this capability via a configuration variable. 823 Considerations 825 None. 827 2.17.2. Configurable Destination UDP Port 829 Capability 831 Devices should allow for the configuration of the destination 832 syslog UDP port number. 834 Discussion 835 In large logging environments, spreading the load amongst multiple 836 receiving daemons is a useful optimization. This capability also 837 allows to differentiate different device functions very easily, 838 for example all backbone router log to port 512 and all access 839 router log to port 513. 841 Supported Practices 843 * Send all backbone routers log to port 512 and all access router 844 log to port 513. 846 Current Implementations 848 Some devices support this capability via a configuration variable. 850 Considerations 852 None. 854 2.18. SNMP-specific capabilities 856 Another commonly used logging mechansim is using the trap and 857 notification messages of the Simple Network Management Protocol. 859 2.18.1. Read-only Operations Supported 861 Capability 863 Devices should support the disablement of SNMP write operations to 864 the device. 866 Discussion 868 Since SNMP is used as a management protocol in adition to its 869 logging functionality, the ability to disable operations that 870 would change the device operations should be supported for those 871 devices whach aren't using the management functions. 873 Supported Practices 875 * Disable SNMP write operations. 877 Current Implementations 879 Some devices support this capability via a configuration variable. 881 Considerations 883 None. 885 2.18.2. Restrict Returning Data to specific Hosts 887 Capability 889 Devices should allow for restricting the IPAddresses that can 890 query the SNMP interface for event data. 892 Discussion 894 Since event data can educate an adversary, devices should be able 895 to only send event data ("responses") to certain, configured IP 896 Addresses, not any system that interrogates them. 898 Supported Practices 900 * Configure devices to only accept SNMP requests from authorized 901 addresses. 903 Current Implementations 905 Some devices support this capability via a configuration variable. 907 Considerations 909 None. 911 2.18.3. Only Return Specific Data to Requestor 913 Capability 915 Devices should support the delivery of specific managed object 916 data (e.g., values linked to a specific OID ) instead of returning 917 all event data in the device (e.g., an entire OID subtree). 919 Discussion 921 Since event data can educate an adversary, devices should be able 922 to only send specific event data instead of returning all the data 923 in every query. 925 Supported Practices 927 * Queries request specific OID values instead of dumping the 928 entire MIB. This practice reduces event data volume in 929 addition to attaining security. 931 Current Implementations 933 Most devices support this capability. 935 Considerations 937 None. 939 3. Additional Operational Practices 941 This section describes practices not covered in [CURPRAC]. They are 942 included here to provide justification for capabilities that 943 reference them. 945 This section will be populated from comments received on this 946 internet-draft. 948 4. Security Considerations 950 Security capabilities of network devices is the subject matter of 951 this entire memo. The capabilities listed cite practices in 952 [CURPRAC] that they are intended to support. [CURPRAC] also defines 953 the general threat model, practices, and lists justifications for 954 each practice. 956 5. IANA Considerations 958 There are no IANA actions required by this document. 960 6. Normative References 962 [CURPRAC] Kaeo, M., "Operational Security Current Practices", 963 May 2006. 965 [FRMWK] Jones, G., Ed., "Framework for Operational Security 966 Capabilities for IP Network Infrastructure, 967 draft-ietf-opsec-framework-03 (work in progress)", 968 October 2005, . 970 [RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called 971 TACACS", RFC 1492, July 1993. 973 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 974 Requirement Levels", BCP 14, RFC 2119, March 1997. 976 [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, 977 September 1997. 979 [RFC2271] "An Architecture for Describing SNMP Management 980 Frameworks", RFC 2271, January 1998. 982 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 983 "Remote Authentication Dial In User Service (RADIUS)", 984 RFC 2865, June 2000. 986 [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, 987 August 2001. 989 [RFC3195] New, D. and M. Rose, "Reliable Delivery for syslog", 990 RFC 3195, November 2001. 992 [SP800-92] 993 Souppaya, M. and K. Kent, "Guide to Security Log 994 Management", FIPS 800-92, April 2006. 996 Authors' Addresses 998 Patrick Cain 999 The Cooper-Cain Group, Inc. 1000 P.O. Box 400992 1001 Cambridge, MA 02140 1002 U.S.A. 1004 Phone: +1 617-848-1950 1005 Email: pcain@coopercain.com 1007 George Jones 1008 The MITRE Corporation 1009 7515 Colshire Drive, M/S WEST 1010 McLean, Virginia 22102-7508 1011 USA 1013 Phone: +1 703 488 974 1014 Fax: 1015 Email: gmjones@mitre.org 1016 URI: 1018 Intellectual Property Statement 1020 The IETF takes no position regarding the validity or scope of any 1021 Intellectual Property Rights or other rights that might be claimed to 1022 pertain to the implementation or use of the technology described in 1023 this document or the extent to which any license under such rights 1024 might or might not be available; nor does it represent that it has 1025 made any independent effort to identify any such rights. Information 1026 on the procedures with respect to rights in RFC documents can be 1027 found in BCP 78 and BCP 79. 1029 Copies of IPR disclosures made to the IETF Secretariat and any 1030 assurances of licenses to be made available, or the result of an 1031 attempt made to obtain a general license or permission for the use of 1032 such proprietary rights by implementers or users of this 1033 specification can be obtained from the IETF on-line IPR repository at 1034 http://www.ietf.org/ipr. 1036 The IETF invites any interested party to bring to its attention any 1037 copyrights, patents or patent applications, or other proprietary 1038 rights that may cover technology that may be required to implement 1039 this standard. Please address the information to the IETF at 1040 ietf-ipr@ietf.org. 1042 Disclaimer of Validity 1044 This document and the information contained herein are provided on an 1045 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1046 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1047 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1048 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1049 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1050 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1052 Copyright Statement 1054 Copyright (C) The Internet Society (2006). This document is subject 1055 to the rights, licenses and restrictions contained in BCP 78, and 1056 except as set forth therein, the authors retain all their rights. 1058 Acknowledgment 1060 Funding for the RFC Editor function is currently provided by the 1061 Internet Society.