OPSEC P. Cain Internet-Draft The Cooper-Cain Group, Inc. Expires: March 19, 2007 G. Jones The MITRE Corporation September 15, 2006 Logging Capabilities for IP Network Infrastructure draft-cain-logging-caps-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 March 19, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document lists logging capabilities originally defined in RFC3871 and needed to support the current practices, including those described in the Operational Security Current Practices document[CURPRAC] Logging is defined as the delivery to another entity or system of messages about the device, the data passing through the device, or the device's interaction with another device. Cain & Jones Expires March 19, 2007 [Page 1] Internet-Draft Logging Capabilities September 2006 Capabilities are defined without reference to specific technologies. This is done to leave room for deployment of new technologies that implement the capability. Each capability cites the practices it supports. Current implementations that support the capability are cited. Special considerations are discussed as appropriate listing operational and resource constraints, limitations of current implementations, trade offs, etc. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Capabilities vs. Requirements ? . . . . . . . . . . . . . 4 1.3. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 2. Functional Capabilities of Log Generating Systems . . . . . . 6 2.1. Logging Facility Uses Protocols Subject To Open Review . . 6 2.2. Logs Sent To Remote Servers . . . . . . . . . . . . . . . 7 2.3. Ability to Select Reliable Delivery . . . . . . . . . . . 8 2.4. Ability to Remotely Log Securely . . . . . . . . . . . . . 8 2.5. Ability to Log Locally . . . . . . . . . . . . . . . . . . 9 2.6. Ability to Log Different Severities to Different Destinations . . . . . . . . . . . . . . . . . . . . . . . 10 2.7. Ability to Log to Multiple Destinations . . . . . . . . . 11 2.8. Ability to Maintain Accurate System Time . . . . . . . . . 12 2.9. Display Timezone And UTC Offset . . . . . . . . . . . . . 13 2.10. Default Timezone Should Be UTC . . . . . . . . . . . . . . 14 2.11. Log Entries Must Be Timestamped . . . . . . . . . . . . . 14 2.12. Log on Exception or Identifed Event . . . . . . . . . . . 15 2.13. Logs Contain Untranslated IP Addresses . . . . . . . . . . 16 2.14. Logs Contain Records Of Security Events . . . . . . . . . 17 2.15. Logs Do Not Contain Passwords . . . . . . . . . . . . . . 18 2.16. Devices Should Log Every Message . . . . . . . . . . . . . 19 2.17. Syslog-specific Capabilties . . . . . . . . . . . . . . . 20 2.17.1. Configurable Facility Values . . . . . . . . . . . . 20 2.17.2. Configurable Destination UDP Port . . . . . . . . . . 20 2.18. SNMP-specific capabilities . . . . . . . . . . . . . . . . 21 2.18.1. Read-only Operations Supported . . . . . . . . . . . 21 2.18.2. Restrict Returning Data to specific Hosts . . . . . . 22 2.18.3. Only Return Specific Data to Requestor . . . . . . . 22 3. Additional Operational Practices . . . . . . . . . . . . . . . 24 4. Security Considerations . . . . . . . . . . . . . . . . . . . 25 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 6. Normative References . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . . . 28 Cain & Jones Expires March 19, 2007 [Page 2] Internet-Draft Logging Capabilities September 2006 1. Introduction The Framework for Operational Security Capabilities [FRMWK] outlines the proposed effort of the IETF OPSEC working group. This includes producing a series of drafts to codify knowledge gained through operational experience about feature sets that are needed to securely deploy and operate managed network elements providing transit services at the data link and IP layers. Current plans include separate capabilities documents for Packet Filtering; Event Logging; In-Band and Out-of-Band Management; Configuration and Management Interfaces; AAA; and Documentation and Assurance. [CURPRAC] defines the goals, motivation, scope, definitions, intended audience, threat model, potential attacks and give justifications for each of the practices. 1.1. Threat Model The logging capabilities are derived from real world observations where unexpected activities in a network infrastructure caused concern to the network operator. Examples of such activities are: An adversary or unauthorized user login into an infrastructure device. The risk is that the configuration or other operating parameter could be modified. A device becomes overwhelmed, throttles, or crashes. Without logging or some other mechanism to notifify the operator of the condition, the operator will not know that action is required to return the device to optimal operating condition. Network problems cannot be properly diagnosed without information. Information does not exist unless generated. Threats to the network devices may be classified into broad categories such as: * Unexpected device status or configuration change * Failure to send log messages * Interception of log messages * Failure to store log messages The main technical issues revolve around what events generate a log entry, what mechanisms are used to secure the logged information while it is in transit and while it is stored, and how long are logs retained. Note that guidance in both RFC3871 and the FRAMEWORK documents restrict capabilities to log event generators, so other elements in a logging infrastructure, such as event collection or Cain & Jones Expires March 19, 2007 [Page 3] Internet-Draft Logging Capabilities September 2006 archival systems, are not discussed in this document. A good overview of building and operating a log infrastructure can be found in NIST Publication 800-62. [SP800-92] One unintended threat to the loggin infrastructure is a self- inflicted denial-of-service attack due to an overwheming amount of log messages on the local machine -- such that the local system is using all it's available effort to capture log messages -- or through the network between the log generator and the log collector -- such that the remore system is innaccesible to management operations. Although not specifically a capability, care should be taken when configuring the logging infrastructure to account for this threat. Although most people equate logging with using the syslog protocol, other protocols such as SNMP [RFC2271] are quite capable of generating a log entry for transmission to a remote log entry collector. 1.2. Capabilities vs. Requirements ? Capabilities may or may not be requirements. That is a local determination that must be made by each operator with reference to the policies that they must support. This document, together with [CURPRAC] will assist network operators in identifying their security capability requirements and communicating them clearly to vendors. 1.3. Format Each capability has the following subsections: o Capability (what) o Discussion o Supported Practices (why) o Current Implementations (how) o Considerations (caveats, resource issues, protocol issues, etc.) The Capability section describes a feature to be supported by the device. The Supported Practice section cites practices described in [CURPRAC] that are supported by this capability. The Current Implementation section is intended to give examples of implementations of the capability, citing technology and standards current at the time of writing. It is expected that the choice of features to implement the capabilities will change over time. The Considerations section lists operational and resource constraints, Cain & Jones Expires March 19, 2007 [Page 4] Internet-Draft Logging Capabilities September 2006 limitations of current implementations, trade offs, etc. 1.4. Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The use of the RFC 2119 keywords is an attempt, by the author, to assign an expectation level ("MUST", "SHOULD", "MAY") to the each capability. It must be noted that different organizations, operational environments, policies and legal environments will generate different requirement levels. NOTE: This document defines capabilities. This document does not define requirements, and there is no requirement that any particular capability be implemented or deployed. The use of the terms MUST, SHOULD, and so on are in the context of each capability in the sense that if you conform to any particular capability then you MUST or SHOULD do what is specified for that capability, but there is no requirement that you actually do conform to any particular capability. Cain & Jones Expires March 19, 2007 [Page 5] Internet-Draft Logging Capabilities September 2006 2. Functional Capabilities of Log Generating Systems The capabilities in this section are intended to list testable, functional capabilities that are needed to operate devices securely and meet the obligations of Section 1.1Threat Model. 2.1. Logging Facility Uses Protocols Subject To Open Review Capability The device provides a logging facility that is based on protocols subject to open review. Custom or proprietary logging protocols MAY be implemented provided the same information is made available. Discussion The use of logging based on protocols subject to open review permits the operator to perform archival and analysis of logs without relying on vendor-supplied software and servers. . Supported Practices. * syslog * syslog with reliable delivery * SNMP with applicable security controls Current Implementations This capability can be satisfied by the use of one or more of syslog [RFC3164], syslog with reliable delivery [RFC3195], TACACS+ [RFC1492], RADIUS [RFC2865] or SNMP [RFC2271]. The current best solution seems to be the following: * Implement syslog [RFC3164]. * Consider implementing syslog with reliable delivery [RFC3195]. Cain & Jones Expires March 19, 2007 [Page 6] Internet-Draft Logging Capabilities September 2006 Considerations None. 2.2. Logs Sent To Remote Servers Capability The device MUST support transmission of records of security related events to one or more remote collection devices. There MUST be configuration settings on the device that allow selection of destination servers. Discussion None. Supported Practices * Use multiple collection devices to enhance reliability. * Use different collection devices to segregate different event sensitivity levels. Current Implementations This capability may be satisfied by the use of one or more of: syslog [RFC3164], syslog with reliable delivery [RFC3195], TACACS+ [RFC1492], or RADIUS [RFC2865]. Considerations This is important because it supports individual accountability. It is important to store them on a separate server to preserve them in case of failure or compromise of the managed device. Note that there may be privacy or legal considerations when logging/monitoring user activity. High volumes of logging may generate excessive network traffic and/or compete for scarce memory and CPU resources on the device. Cain & Jones Expires March 19, 2007 [Page 7] Internet-Draft Logging Capabilities September 2006 2.3. Ability to Select Reliable Delivery Capability It SHOULD be possible to select reliable delivery of log messages. Discussion 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 instead of a true record of events. Supported Practices * Use syslog-ng. * Tunnel the logging stream over a TCP-based connection. * Use an out-of-band network to connect critical logging devices to the collection device. Current Implementations One example of reliable syslog delivery is defined in [RFC3195]. Syslog-ng provides another example, although the protocol has not been standardized Considerations Reliable delivery should be used if the path from log event generator to the collection device transits administrative domains or uses unreliable channels, as it is important that the entire stream of leg events is captured. 2.4. Ability to Remotely Log Securely Capability The log data stream SHOULD be able to be delivered to the collection device in a confidential manner. Cain & Jones Expires March 19, 2007 [Page 8] Internet-Draft Logging Capabilities September 2006 Discussion While syslog *could* provide this capability, it has many security issues and by itself does not address issues from the threat model. See the security considerations section of [RFC3164] for a list of issues. Syslog with reliable delivery provides solutions to most/all of these issues, however at the time of this writing there are few implementations. Other possible solutions might be to tunnel syslog over a secure transport...but this often raises difficult key management and scalability issues. Supported Practices * Log data tunnelled within IPSec or SSH. * Use syslog-ng. Current Implementations There is no common implementation of this capability. Considerations As is the reliable delivery capability, delivering log data across untrusted streams or including sensitive data in a event data may require additional countermeasures to protect the data. This concern should not be addressed lightly. ISPs are fully aware that there is no security with syslog but IPSec is considered too operationally expensive and cumbersome to deploy. Syslog-ng and stunnel could be used for better authentication and integrity protected solutions. Mechanisms to prevent unauthorized personnel from tampering with logs is constrained to auditing who has access to the logging servers and files. 2.5. Ability to Log Locally Capability It SHOULD be possible to log locally on the device itself. Local logging SHOULD be written to non-volatile storage. . Cain & Jones Expires March 19, 2007 [Page 9] Internet-Draft Logging Capabilities September 2006 Discussion Logging of failed authentication attempts to local non-volatile storage is critical as it provides a record of events if the device gets isolated from its authentication interfaces or an attack overwhelms the console interface. Local logging is also important for viewing information when connected to the device and it provides some backup of log data in case remote logging fails. Local logging also provides a way to quickly view logs relevant to one device without having to sort through a possibly large set of logs from other devices at the collection device. Supported Practices * To conserve space, only failed device logins and network connectivity issues are logged locally. Current Implementations One example of local logging would be a memory buffer that receives copies of messages sent to the remote log server. Another example might be a local syslog server (assuming the device is capable of running syslog and has some local storage). Considerations Storage on the device may be limited.; high volumes of log messages may quickly fill the available storage, in which case there are two options: new logs overwrite old logs (possibly via the use of a circular memory buffer or log file rotation), or logging stops. 2.6. Ability to Log Different Severities to Different Destinations Cain & Jones Expires March 19, 2007 [Page 10] Internet-Draft Logging Capabilities September 2006 Capability The device SHOULD allow specified severity levels of log message to be delivered to different collection destinations. Discussion A network of multiple devices may generate a significant amount of log data. The ability to send critical log messages, for example a root login, to a specific destination device will enhance the ability of the network operator to notice the critical event. Supported Practices * Email critical event notices to a 24-hour watched mailbox. * Send critical event notices to a separate log collector that scrolls received messages upon a large display in the NOC. Current Implementations There are no common implementations of this capability. Considerations The use of multiple collectors will incur maintenance and reliability issues. In some cases, multiple filters watching a single collection point may be more efficient than using multiple collectors. 2.7. Ability to Log to Multiple Destinations Capability The device SHOULD allow log message to be delivered to multiple collection destinations. Discussion All ISPs have multiple syslog servers - some ISPs choose to use separate syslog servers for varying infrastructure devices (i.e., one syslog server for backbone routers, one syslog server for customer edge routers, etc.) This provides a backup mechanism to see what is going on in the network in the event that a device may Cain & Jones Expires March 19, 2007 [Page 11] Internet-Draft Logging Capabilities September 2006 'forget' to do syslog if the CPU is busy. Supported Practices * Use multiple log servers to enhance reliability. Current Implementations Most ISPs use multiple, sometimes gegraphic-driven, log collectors. Considerations None. 2.8. Ability to Maintain Accurate System Time Capability The device MUST maintain accurate, "high resolution" system time. Discussion Accurate time is important to the generation of reliable log data. Accurate time is also important to the correct operation of some authentication mechanisms. The ability to correlate network events from different devices is directly related to the accuracy of the log timestamps. If a timeline cannot be constructed, the event logs and forensic data is useless. Supported Practices * The time is derived from NTP which is generally configured as a flat hierarchy at stratum1 and stratum2 servers to have less configuration and less maintenance issues. * Each router is configured with one stratum1 peer both locally and remotely. Cain & Jones Expires March 19, 2007 [Page 12] Internet-Draft Logging Capabilities September 2006 Current Implementations This capability may be satisfied by supporting Network Time Protocol (NTP), Simple Network Time Protocol (SNTP), or via direct connection to an accurate time source. Considerations 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). Also note that if network time synchronization is used, an attacker may be able to manipulate the clock unless cryptographic authentication is used.. 2.9. Display Timezone And UTC Offset Capability All displays and logs of system time MUST include a timezone or offset from UTC. Discussion None. Supported Practices * The log timestamps include a timezone indicator like "-05:00". Current Implementations Considerations Knowing the timezone or UTC offset makes correlation of data and coordination with data in other timezones possible. Bob is in Newfoundland, Canada which is UTC -3:30. Alice is somewhere in Indiana, USA. Some parts of Indiana switch to daylight savings time while others do not. A user on Bob's network attacks a user on Alice's network. Both are using logs with local timezones and no indication of UTC offset. Correlating these logs will be Cain & Jones Expires March 19, 2007 [Page 13] Internet-Draft Logging Capabilities September 2006 difficult and error prone. Including timezone, or better, UTC offset, eliminates these difficulties. Notice that a physical location may have different offsets from UTC during a year as summertime, daylight savings time, or other local customs are applied. 2.10. Default Timezone Should Be UTC Capability The default timezone for display and logging SHOULD be UTC. The device MAY support a mechanism to allow the operator to specify the display and logging of times in a timezone other than UTC. Discussion Knowing the timezone or UTC offset makes correlation of data and coordination with data in other timezones possible. Supported Practices * The timezone offset can be entered as part of configuration of a device. Implementation Bob in Newfoundland (UTC -3:30) and Alice in Indiana (UTC -5 or UTC -6 depending on the time of year and exact county in Indiana) are working an incident together using their logs. Both left the default settings, which was UTC, so there was no translation of time necessary to correlate the logs. Considerations None. 2.11. Log Entries Must Be Timestamped Capability Cain & Jones Expires March 19, 2007 [Page 14] Internet-Draft Logging Capabilities September 2006 By default, the device MUST timestamp all log messages. The timestamp MUST be accurate to within a second or less. The timestamp MUST include a timezone. There MAY be a mechanism to disable the generation of timestamps. Discussion Accurate timestamps are necessary for correlating events, particularly across multiple devices or with other organizations. This applies when it is necessary to analyze logs.. Supported Practices * Each entry into the log contains a time value. Current Implementations This capability may be satisfied by writing timestamps into syslog messages. Considerations It is difficult to correlate logs from different time zones. Security events on the Internet often involve machines and logs from a variety of physical locations. For that reason, UTC is preferred, all other things being equal.. 2.12. Log on Exception or Identifed Event Capability Log entries should be generated on exceptions (e.g., failures) or event matching (e.g., generate a log entry if an event happens) via a configurable value. Discussion Traditionally log events are generated on exceptions -- failures or errors. Many times this is not sufficient as a network operator cannot tell if an attacker failed to log into a device once, or failed once and then succeeded on the second try. Devices should be configurable to allow for log messages on failures, successes, or everything. Cain & Jones Expires March 19, 2007 [Page 15] Internet-Draft Logging Capabilities September 2006 Supported Practices * Log all login events to a device but only have the collection device alert on failures. * Log on successful device configuration changes since one must be aware of all modifications on some types of devices. Current Implementations Some ISPs put in passive devices to see routing updates and withdrawals and not rely solely on the device for log files. Considerations None. 2.13. Logs Contain Untranslated IP Addresses Capability Log messages MUST NOT list translated addresses (DNS names) associated with the address without listing the untranslated IP address where the IP address is available to the device generating the log message. Discussion Although some times less obtuse than DNS names, IP address assignments tend to be more stable than DNS entries. If an operator is trying to correlate a historical event, the DNS name may have been changed from that used at the event. TO ease this confusion, the IP address of the source of the action that caused the log event should be retained in the log entry. Supported Practices * Include the source IP address in all log messages. * Although a corresponding DNS name is useful, DNS lookups can be slow and consume resources. Cain & Jones Expires March 19, 2007 [Page 16] Internet-Draft Logging Capabilities September 2006 Current Implementations Most devices include the source IP in event logs Considerations A failed network login should generate a record with the source address of the login attempt, but the Source addresses may be spoofed. Network-based attacks often use spoofed source addresses so they should not be completely trusted unless verified by other means. Having accurate timestamps in the logs increases the chances that the use of an address can be correlated to an individual. 2.14. Logs Contain Records Of Security Events Capability The device MUST be able to send a record of at least the following events: * authentication successes, * authentication failures, * session Termination, * authorization changes, * configuration changes, * device status changes. The device SHOULD be able to send a record of all other security related events including filtering (or ACL) exceptions, routing protocol state changes, all device access (regardless of authentication success or failure), all commands issued to a device, and all routing events (boot-up/flaps). Discussion The main function of any of these log messages is to see what the device is doing as well as to try and ascertain what certain malicious attackers are trying to do. Typically the data logged will contain the source and destination IP addresses and layer 4 port numbers as well as a timestamp. Supported Practices * Examples of events recorded include: user logins, bad login attempts, logouts, user privilege level changes, individual configuration commands issued by users and system startup/ shutdown events. Cain & Jones Expires March 19, 2007 [Page 17] Internet-Draft Logging Capabilities September 2006 Current Implementations Most devices crudely support this capability. Considerations This list is far from complete. Note that there may be privacy or legal considerations when logging/monitoring user activity or personal information. This is an important capability because it supports individual accountability and auditing as well as forensics. See section 4.5.4.4 of . 2.15. Logs Do Not Contain Passwords Capability Passwords SHOULD be excluded, by default configuration, from all audit records, including records of successful or failed authentication attempts. Discussion A user may make small mistakes in entering a password such as using incorrect capitalization ("my password" vs. "My Password"). Event logs are traditional disperse widely so unexpected events will be noticed. Unauthorized access to event logs that contain these mistakes may compromise more than just the network devices as most users do not have independent passwords for every system. Supported Practices * Login failure log messages include the failed username, timestamp, and source IP address, but not the password used. Current Implementations Access control and authorization requirements differ for accounting records (logs) and authorization databases (passwords). Logging passwords may grant unauthorized access to individuals with access to the logs. Logging failed passwords may also give hints about actual passwords. See section 4.5.4.4 of [RFC2196] Cain & Jones Expires March 19, 2007 [Page 18] Internet-Draft Logging Capabilities September 2006 Considerations There may be situations where it is appropriate/required to log passwords, such as when performing real-time attack analysis. Caution is advised in these rare circumstances. 2.16. Devices Should Log Every Message Capability Devices should be configurable to either log every event or to drop events due to congestion. Discussion Many devices implement logging as an afterthought with the device dropping log messages or failing to log critical events when the device is "busy". This behaviour makes forensic analysis difficult, if not impossible. Devices should be configurable to not drop log events at those operator-defined times when this behaviour s expected. Supported Practices * Use multiple logging devices and collectors to capture enough extra messages to be able to recreate a full log. Current Implementations Use multiple logging devices. Considerations Improper configuration or implementation of this capability may open a device, network, or logging infrastructure to a self-inflicted denial-of-service attack. None. Cain & Jones Expires March 19, 2007 [Page 19] Internet-Draft Logging Capabilities September 2006 2.17. Syslog-specific Capabilties The predominant logging mechanism within network infrastructures is BSD-syslog and its' variants. With such widespread uses, this section identifies capabilities specific to syslog. 2.17.1. Configurable Facility Values Capability The device SHOULD allow for the selection of the syslog facility number via configuration. Discussion A network operator may have many similar devices in their network. The ability to segregate different severity events by the strategic use of the syslog facility number is extremely useful. Supported Practices * Authentication log entries are marked at a different facility code to allow for easier segregation at the event collector. Current Implementations Some devices support this capability via a configuration variable. Considerations None. 2.17.2. Configurable Destination UDP Port Capability Devices should allow for the configuration of the destination syslog UDP port number. Discussion Cain & Jones Expires March 19, 2007 [Page 20] Internet-Draft Logging Capabilities September 2006 In large logging environments, spreading the load amongst multiple receiving daemons is a useful optimization. This capability also allows to differentiate different device functions very easily, for example all backbone router log to port 512 and all access router log to port 513. Supported Practices * Send all backbone routers log to port 512 and all access router log to port 513. Current Implementations Some devices support this capability via a configuration variable. Considerations None. 2.18. SNMP-specific capabilities Another commonly used logging mechansim is using the trap and notification messages of the Simple Network Management Protocol. 2.18.1. Read-only Operations Supported Capability Devices should support the disablement of SNMP write operations to the device. Discussion Since SNMP is used as a management protocol in adition to its logging functionality, the ability to disable operations that would change the device operations should be supported for those devices whach aren't using the management functions. Supported Practices * Disable SNMP write operations. Cain & Jones Expires March 19, 2007 [Page 21] Internet-Draft Logging Capabilities September 2006 Current Implementations Some devices support this capability via a configuration variable. Considerations None. 2.18.2. Restrict Returning Data to specific Hosts Capability Devices should allow for restricting the IPAddresses that can query the SNMP interface for event data. Discussion Since event data can educate an adversary, devices should be able to only send event data ("responses") to certain, configured IP Addresses, not any system that interrogates them. Supported Practices * Configure devices to only accept SNMP requests from authorized addresses. Current Implementations Some devices support this capability via a configuration variable. Considerations None. 2.18.3. Only Return Specific Data to Requestor Capability Devices should support the delivery of specific managed object data (e.g., values linked to a specific OID ) instead of returning all event data in the device (e.g., an entire OID subtree). Cain & Jones Expires March 19, 2007 [Page 22] Internet-Draft Logging Capabilities September 2006 Discussion Since event data can educate an adversary, devices should be able to only send specific event data instead of returning all the data in every query. Supported Practices * Queries request specific OID values instead of dumping the entire MIB. This practice reduces event data volume in addition to attaining security. Current Implementations Most devices support this capability. Considerations None. Cain & Jones Expires March 19, 2007 [Page 23] Internet-Draft Logging Capabilities September 2006 3. Additional Operational Practices This section describes practices not covered in [CURPRAC]. They are included here to provide justification for capabilities that reference them. This section will be populated from comments received on this internet-draft. Cain & Jones Expires March 19, 2007 [Page 24] Internet-Draft Logging Capabilities September 2006 4. Security Considerations Security capabilities of network devices is the subject matter of this entire memo. The capabilities listed cite practices in [CURPRAC] that they are intended to support. [CURPRAC] also defines the general threat model, practices, and lists justifications for each practice. Cain & Jones Expires March 19, 2007 [Page 25] Internet-Draft Logging Capabilities September 2006 5. IANA Considerations There are no IANA actions required by this document. 6. Normative References [CURPRAC] Kaeo, M., "Operational Security Current Practices", May 2006. [FRMWK] Jones, G., Ed., "Framework for Operational Security Capabilities for IP Network Infrastructure, draft-ietf-opsec-framework-03 (work in progress)", October 2005, . [RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called TACACS", RFC 1492, July 1993. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, September 1997. [RFC2271] "An Architecture for Describing SNMP Management Frameworks", RFC 2271, January 1998. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001. [RFC3195] New, D. and M. Rose, "Reliable Delivery for syslog", RFC 3195, November 2001. [SP800-92] Souppaya, M. and K. Kent, "Guide to Security Log Management", FIPS 800-92, April 2006. Cain & Jones Expires March 19, 2007 [Page 26] Internet-Draft Logging Capabilities September 2006 Authors' Addresses Patrick Cain The Cooper-Cain Group, Inc. P.O. Box 400992 Cambridge, MA 02140 U.S.A. Phone: +1 617-848-1950 Email: pcain@coopercain.com George Jones The MITRE Corporation 7515 Colshire Drive, M/S WEST McLean, Virginia 22102-7508 USA Phone: +1 703 488 974 Fax: Email: gmjones@mitre.org URI: Cain & Jones Expires March 19, 2007 [Page 27] Internet-Draft Logging Capabilities September 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Cain & Jones Expires March 19, 2007 [Page 28]