idnits 2.17.1 draft-calabrese-requir-logprot-04.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. ** There are 3 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (January 2001) is 8502 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. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' == Outdated reference: A later version (-12) exists of draft-ietf-syslog-syslog-03 ** Downref: Normative reference to an Informational draft: draft-ietf-syslog-syslog (ref. '10') -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' == Outdated reference: A later version (-12) exists of draft-ietf-syslog-reliable-03 -- Possible downref: Normative reference to a draft: ref. '19' == Outdated reference: A later version (-29) exists of draft-ietf-syslog-sign-00 ** Obsolete normative reference: RFC 2570 (ref. '21') (Obsoleted by RFC 3410) ** Obsolete normative reference: RFC 2574 (ref. '22') (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 2575 (ref. '23') (Obsoleted by RFC 3415) Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1  2 Network Working Group C. J. Calabrese 3 Internet-Draft The SANS Institute 4 Expires: July 2, 2001 M. Apad 5 Association of Hungarian Linux 6 Users 7 January 2001 9 Requirements for a Network Event Logging Protocol 10 draft-calabrese-requir-logprot-04 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on July 2, 2001. 35 Copyright Notice 37 Copyright (C) The Internet Society (2001). All Rights Reserved. 39 Abstract 41 This document presents requirements for sending system event/audit 42 logs over the Internet. In developing these requirements, it 43 considers the needs for log management, security, high-performance, 44 and compatibility with existing practice. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Log Reporting Considerations . . . . . . . . . . . . . . . 4 50 2.1 Introduction and Rationale . . . . . . . . . . . . . . . . 4 51 2.2 Identification of Event Threads . . . . . . . . . . . . . 4 52 2.3 Event Correlation . . . . . . . . . . . . . . . . . . . . 4 53 2.4 Event Filters . . . . . . . . . . . . . . . . . . . . . . 5 54 2.4.1 Introduction and Rationale . . . . . . . . . . . . . . . . 5 55 2.4.2 Filtering By Source . . . . . . . . . . . . . . . . . . . 5 56 2.4.3 Filtering By Priority . . . . . . . . . . . . . . . . . . 5 57 2.4.4 Filtering By Facility . . . . . . . . . . . . . . . . . . 5 58 2.4.5 Filtering By Other Attributes . . . . . . . . . . . . . . 5 59 3. Security Considerations . . . . . . . . . . . . . . . . . 6 60 3.1 Introduction and Rationale . . . . . . . . . . . . . . . . 6 61 3.2 Common Criteria . . . . . . . . . . . . . . . . . . . . . 6 62 3.3 Implications . . . . . . . . . . . . . . . . . . . . . . . 8 63 3.3.1 Policies . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 3.3.2 Access Control Labels . . . . . . . . . . . . . . . . . . 8 65 3.3.3 Identification/Authentication . . . . . . . . . . . . . . 9 66 3.3.4 Selective Storage and Protection of Audit Records . . . . 9 67 3.3.5 Assurance . . . . . . . . . . . . . . . . . . . . . . . . 10 68 3.3.5.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . 10 69 3.3.5.2 Integrity . . . . . . . . . . . . . . . . . . . . . . . . 10 70 3.3.5.3 Availability . . . . . . . . . . . . . . . . . . . . . . . 10 71 3.3.6 Trusted Mechanisms . . . . . . . . . . . . . . . . . . . . 11 72 3.4 Protocol Level for Cryptographic Functions . . . . . . . . 11 73 4. Resource Utilization Considerations . . . . . . . . . . . 13 74 5. Existing Practice . . . . . . . . . . . . . . . . . . . . 14 75 5.1 Existing Syslog . . . . . . . . . . . . . . . . . . . . . 14 76 5.2 Schneier and Kelsey . . . . . . . . . . . . . . . . . . . 14 77 5.3 Nsyslogd . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 5.4 Secure Syslog . . . . . . . . . . . . . . . . . . . . . . 15 79 5.5 ULM . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 5.6 syslog-ng . . . . . . . . . . . . . . . . . . . . . . . . 15 81 5.7 SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . 16 83 References . . . . . . . . . . . . . . . . . . . . . . . . 17 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 19 85 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 20 86 Full Copyright Statement . . . . . . . . . . . . . . . . . 21 88 1. Introduction 90 Computer systems and other network devices often need to "log" or 91 record information about important events. In many systems, these 92 event logs are recorded locally, in persistent storage within the 93 system where the event occurs. These messages may also be 94 transmitted to a remote system where persistent storage takes place. 95 Reasons for such remote transmission include event logging on 96 systems with no local persistent storage and centralization of log 97 record management. 99 This memo concerns itself with the requirements for transmitting log 100 messages over an Internet Protocol network, including requirements 101 for log management, event correlation, security, performance, and 102 compatibility with existing practice. It was originally conceived to 103 guide the workings of the IETF's Security Issues in Network Event 104 Logging Working Group, which is dealing with security issues in the 105 Syslog[2] system. However, the principles apply equally well to 106 other event logging systems. 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119[1]. 112 2. Log Reporting Considerations 114 2.1 Introduction and Rationale 116 The ultimate reason for transmitting log messages over the network 117 is so these messages can be examined later to detect and analyze 118 "interesting" events (security incidents, peak server usage, etc.). 119 Although the transmission of the messages itself is not directly 120 related to this examination, the systems related to transmission 121 should aid the process of examination to the largest extent 122 practical. 124 2.2 Identification of Event Threads 126 Since logging system tend to generate and transmit discrete event 127 messages, one of the most important reporting requirements for a 128 logging system is to be able to figure out how event messages fit 129 together to form a thread of messages about the same incident. 131 Messages in a thread are typically identified by the originating 132 machine, the program or sub-system on the originating machine, and 133 the instance of that program or sub-system. Additionally, some kind 134 of sequence information must be present to determine the order of 135 event messages in the thread. 137 In most cases, the originating machine can be determined by the 138 source IP address of log messages and the sequence determined by the 139 order of arriving packets (UDP) or relative ordering in the 140 transmission stream (TCP). However, the IP address can be forged and 141 is therefore unreliable. Similarly, an attacker could reorder 142 packets in a UDP stream. Furthermore, there is no easy method of 143 determining the program/sub-system and its instance on the 144 originating machine without including such identifying information 145 directly in the message. Therefore, it seems plain that the logging 146 messages must directly contain all these pieces of information in 147 order to facilitate the identification of event threads. 149 This issue is also discussed in the Security section (Section 150 3.3.3). 152 2.3 Event Correlation 154 In addition to identifying event messages within the same incident 155 thread from the same source, it is also desirable to correlate 156 messages regarding the same incident from multiple sources. This 157 implies a standard mechanism for identifying incidents based on 158 various criteria such as the time the event occurred, IP addresses 159 of network entities involved, etc. 161 2.4 Event Filters 163 2.4.1 Introduction and Rationale 165 Selecting which events to transmit reduces network load. Selecting 166 which events to accept when transmitted reduces the amount of data 167 that must be processed by higher-level software and which must be 168 persistently stored. The log transmission protocols can help these 169 efforts by making it easy to select events for filtering. 171 2.4.2 Filtering By Source 173 The most obvious attribute to filter data by in an Internet Protocol 174 network is the source IP address of the data. 176 2.4.3 Filtering By Priority 178 Another obvious filter would be by message priority so that high 179 priority messages can be posted as alarms, very low priority 180 messages ignored, etc. 182 2.4.4 Filtering By Facility 184 Not all high priority messages should necessarily be handled the 185 same way. Aside from message priority, the primary method of 186 filtering in the traditional Syslog[2] system is by something called 187 the message Facility (LOG_AUTH, LOG_DAEMON, LOG_MAIL, etc.) 189 2.4.5 Filtering By Other Attributes 191 Source address, priority and facility are by no means the only 192 pieces of information log messages will need to be filtered by. 193 Indeed, just about any attribute of a log message is fair game, and 194 the potential attributes too many to enumerate here. Some have 195 argued that log messages should be structured to make such filtering 196 easier (and some structure is already needed for thread 197 identification, event correlation, and other reasons). Others have 198 argued that rigid structures are not needed if filters are based on 199 regular expressions.[3] 201 3. Security Considerations 203 3.1 Introduction and Rationale 205 According to the U.S. Department of Defense Trusted Computer System 206 Evaluation Criteria (TCSEC)[4], the fundamental requirements for 207 computer security are: 209 1. An explicit and well-defined security policy enforced by the 210 system. 212 2. Access control labels associated with objects. 214 3. Identification of individual subjects. 216 4. Selective storage and protection of audit records so that 217 actions affecting security can be traced to the responsible 218 party. 220 5. Assurance that the computer system enforces security 221 requirements. 223 6. Trusted mechanisms that enforce these basic requirements that 224 are continuously protected against tampering and/or unauthorized 225 changes. 227 In the case of system event logs, the logs themselves may contain 228 the aforementioned audit records. 230 3.2 Common Criteria 232 To put it another way, a logging system should meet the following 233 requirements from the Common Criteria for Information Technology 234 Security Evaluation[5]: 236 o FAU (Security audit) 238 * FAU_ARP (automatic response) 240 * FAU_GEN (generation) 242 * FAU_SAA (analysis) 244 * FAU_SAR (review) 246 * FAU_SEL (selection) 248 * FAU_STG (storage) 250 o FCS (Cryptographic support) 252 * FCS_COP (operation) 254 o FDP (User data protection) 256 * FDP_ACC (Access control policy) 258 * FDP_ACF (Access control functions) 260 * FDP_DAU (Data authentication) 262 * FDP_ETC (Export to outside TSF control) 264 * FDP_IFC (Information flow control policy) 266 * FDP_IFF (Information flow control functions) 268 * FDP_ITC (Import from outside TSF control) 270 * FDP_ITT (Internal TOE transfer) 272 * FDP_RIP (Residual information protection) 274 * FDP_ROL (Rollback) 276 * FDP_SDI (Stored data integrity) 278 * FDP_UCT (Inter-TSF user data confidentiality transfer 279 protection) 281 * FDP_UIT (Inter-TSF user data integrity transfer protection) 283 o FPT (Protection of the TSF) 285 * FPT_FLS (Fail secure) 287 * FPT_ITA (Availability of exported TSF data) 289 * FPT_ITC (Confidentiality of exported TSF data) 291 * FPT_ITT (Internal TOE transfer) 293 * FPT_RCV (Trusted recovery) 295 * FPT_RPL (Replay detection) 297 * FPT_SSP (State synchrony protocol) 298 * FPT_STM (Time stamps) 300 * FPT_TDC (Inter-TSF data consistency) 302 o FRU (Resource utilization) 304 * FRU_FLT (Fault tolerance) 306 * FRU_PRS (Priority of service) 308 * FRU_RSA (Resource allocation) 310 3.3 Implications 312 3.3.1 Policies 314 The questions of what policies are appropriate for system logging 315 and how to enforce them are beyond the scope of this memo. However, 316 any protocol for transmitting log messages must take into account 317 the fact that different systems may have different security 318 policies. Therefore, such protocols should not require adherence to 319 any particular policy. 321 3.3.2 Access Control Labels 323 Access control labels fall into two categories. Integrity labels 324 (think file permissions) and Sensitivity labels (secret, top-secret, 325 etc.). Logging system implementations would use these labels to 326 determine restrictions on access to the data. However, the details 327 of such implementations are beyond the scope of this memo. 329 In the case of system log messages, Integrity labels could be mapped 330 into the Facility tags present in the existing Syslog[2] system. For 331 such a mapping to be useful, however, there should be be a larger 332 and more orthogonal set of Facility tags than the small set in 333 traditional Syslog. The system should also support the ability to 334 specify multiple Facility tags for a particular message. 336 As for Sensitivity labels, if we recognize that logs operating at 337 lower priority also tend to be much more verbose, then we can allow 338 an inverse relationship between Sensitivity labels and log 339 priorities as used in the existing Syslog system (LOG_DEBUG, 340 LOG_INFO, LOG_NOTICE, LOG_WARNING, etc.)[2]. In other words, 341 higher-priority messages may be more widely viewed and less widely 342 created. Conversely, lower-priority messages may be less widely 343 viewed but more widely created. Of course, this is a big assumption. 344 It also implies that message priority must be present in all 345 messages. 347 Also note that a strictly TCSEC[4] or U.S. National Security Agency 348 Labeled Security Protection Profile (LSPP)[6] environment would 349 require the protocol and the components operating on it to either 350 act as a multilevel channel or use distinct single-level channels 351 for each set of Sensitivity labels. A true multilevel channel would 352 require much closer mapping to the native Sensitivity labels than 353 the simple mapping described above. Furthermore, the any non-labeled 354 to labeled transitions must be done in a single-level channel only. 356 3.3.3 Identification/Authentication 358 Ideally, we want to be able to show by strong identification 359 mechanisms (i.e., digital signatures) that a certain log message was 360 generated by a certain program running with certain 361 privileges/user-id on a certain machine at a certain time. This not 362 only allows the exact/authentic subject originating the message to 363 be identified, but also allows non-repudiation of the messages, and 364 easy correlation of events between machines for purposes such as 365 intrusion detection and forensics. 367 The most direct way of implementing such identification is to issue 368 a digital signature key to each program, user, and machine and to 369 require all messages to be thusly signed by the appropriate 370 program/user/machine keys. However, this runs into two major 371 problems. The first is one of key management (i.e., there are too 372 many keys to manage) and the second one of performance (i.e., not 373 all log messages require such identification capabilities and not 374 all machines have the horsepower to supply them). However, if the 375 logging mechanism on the originating machine is part of the system's 376 trusted computing base (TCB), then it is sufficient for TCB to sign 377 the identity of the log messages on the originating program's behalf 378 when directed to do so. 380 Note that it is not necessary for each message to be digitally 381 signed in its entirity. A common practice is to negotiate and sign a 382 session key and then use that key to encrypt a message digest or 383 message authentication code (MAC) of the individual messages[7]. 385 3.3.4 Selective Storage and Protection of Audit Records 387 The policy side of what audit records need to be stored and how much 388 protection they need is beyond the scope of this memo. On the 389 technology side, we can observe that the general issue of 390 requirements for protecting the audit records of a logging system 391 necessarily refers back to the very same security requirements for a 392 logging system itself (i.e., the logging requirements for a logging 393 system are still logging requirements). Since such security 394 requirements for logging systems are the main topic of this memo, 395 the meta logging issue is already addressed elsewhere in the memo 396 and will not be addressed further here. 398 3.3.5 Assurance 400 Issues such as protocol and implementation evaluation against 401 security policies and requirements are beyond the scope of this 402 memo. However, we can address this issue at a requirements level by 403 observing that all security policies center around confidentially, 404 integrity, and availability. 406 3.3.5.1 Confidentiality 408 It is generally acknowledged that the only practical way to achieve 409 confidentiality of messages traveling over an open network is 410 through the use of cryptography. 412 3.3.5.2 Integrity 414 Integrity of log messages boils down to identification of the 415 sender, immutability of messages without detection, and assurance 416 that logs have reached their destination. Identification and 417 immutability can be addressed through digital signatures as 418 discussed in the Identification/Authentication sub-section (Section 419 3.3.3) above. Therefore this section will deal directly only with 420 assurance of delivery. 422 Essentially this boils down to the requirement that the originator 423 of a log message have the capability to detect that a particular 424 message has or has not reached its destination. This does not 425 necessarily imply that only one copy of the message may reach its 426 destination or that the sender must block waiting for delivery 427 notification, which leaves some room to balance this requirement 428 against issues such as performance[8]. 430 On the other hand, the TCSEC[4], LSPP[6], and the U.S. National 431 Security Agency Controlled Access Protection Profile (CAPP)[9] 432 require security sensitive applications to shut down if they can't 433 log security-related events, so the capability to block waiting for 434 delivery notification must be present in such environments. 436 3.3.5.3 Availability 438 The following seem reasonable requirements for high-availability: 440 1. Logging mechanisms should be able to transmit their log messages 441 to multiple destinations, increasing the probability that at 442 least one will be available. 444 2. Logging protocols should make it easy to filter unwanted 445 messages received, reducing the possibility of a denial of 446 service attack on the recipient through the generation of bogus 447 messages. 449 3. Logging protocols should not require log senders to wait 450 synchronously for positive acknowledgement of messages sent 451 before sending any additional messages, making denial of service 452 attacks on log senders more difficult through the generation of 453 excessive traffic on a particular network link. Note that not 454 requiring applications to wait for positive acknowledgement is 455 not the same thing as precluding them from waiting[8]. Also note 456 that the TCSEC[4], the LSPP[6], and the CAPP[9] require security 457 sensitive applications to shut down if they can't log 458 security-related events, so the capability to block waiting for 459 delivery notification must be present in such environments. 461 4. Logging protocols should provide the capability to retransmit 462 unacknowledged messages, also making denial of service attacks 463 on log senders more difficult through the generation of 464 excessive traffic on a particular network link. Note that this 465 facility may be provided by lower level protocols such as by the 466 data integrity features of TCP[7]. This implies degraded 467 capabilities when running over other lower level protocols, 468 which may be a reasonable trade-off in many circumstances. 470 High availability protocol and implementation issues such as 471 high-availability clustering, resistance to buffer overrun attacks, 472 etc. are beyond the scope of this memo. 474 3.3.6 Trusted Mechanisms 476 This area is beyond the scope of this memo. 478 3.4 Protocol Level for Cryptographic Functions 480 One open issue from the above discussion is whether cryptographic 481 functions for identification signatures and confidentiality should 482 be performed at the network transport layer or at higher-level 483 application-specific protocols. 485 Performing these functions at the network transport layer allows the 486 use of standard transport layer security mechanisms (TLS, IPsec), 487 making implementation easier and possibly leading to higher 488 performance due to hardware assist for standard mechanisms, smaller 489 memory footprint on devices already supporting such mechanisms, etc. 490 It also allows filtering of garbage messages at a lower level, 491 making denial of service attacks more difficult. 493 On the other hand, having identification signatures operate at the 494 network transport level means rejecting all unsigned or improperly 495 signed messages since signing information will be lost to the higher 496 protocol layers. Since not all devices generating log messages will 497 have sufficient computing abilities to sign all messages and not all 498 messages will contain information requiring signature, can be 499 problematic. Furthermore, signing and encrypting individual 500 messages facilitates being able to show the confidentiality and 501 integrity of messages without needing to show full chain-of-custody 502 or prove that all links in the chain were appropriately trusted. 504 Therefore, network logging systems should allow cryptographic 505 identification functions to be performed both at the network 506 transport layer and also at higher layers. Cryptographic 507 confidentiality functions, on the other hand, are likely to be more 508 appropriate at the network transport level. 510 4. Resource Utilization Considerations 512 From a logging protocol standpoint, the following resources may be 513 considered: 515 1. CPU/memory utilization on the sending system to marshal internal 516 log messages into the on-the-wire protocol, including any 517 encryption, signing, and/or compression. 519 2. On-the-wire bandwidth utilization, including amenability of the 520 protocol to be compressed by hardware compressors. 522 3. CPU/memory utilization on the receiving system decompress, 523 filter, verify the integrity of, and/or store incoming messages. 525 Most of these considerations argue for a simple text based protocol 526 that is easy to marshal and compress where application-level 527 compression, encryption, and signatures are a configurable option. 528 However, the need to filter messages argues for a more structured 529 protocol to make filtering easier. Furthermore, there may be 530 interactions between the encryption mechanism and the ability to 531 compress the message stream. 533 5. Existing Practice 535 5.1 Existing Syslog 537 The Syslog system is probably the most widely deployed mechanism for 538 storing, filtering, and transferring log message over the network. 539 It is ubiquitous in *nix environments, being bundled with all *nix 540 flavors. It is also heavily used by routers, switches, and other 541 "network applicances" where its ability to transmit logs over the 542 network, its simplicity, and the availability of free 543 implementations make it a natural choice. It has even crept into 544 usage in the Microsoft Windows world, where the native logging 545 system does not work well in large networked environments nor can it 546 interoperate with the logging mechanisms of other operating systems. 548 Unfortunately, Syslog also has some very serious and widely 549 recognized weaknesses.[10] 551 1. Message authenticity is based on easy-to-spoof IP addresses. 553 2. There is no mechanism to assure message confidentiality or 554 integrity. 556 3. The protocol does not guarantee delivery of messages, or ordered 557 delivery of messages. 559 4. The relatively unstructure nature of Syslog messages makes them 560 difficult to filter and/or analyze. 562 Several systems have been devised to improve upon Syslog, and the 563 rest of this section will address these. 565 5.2 Schneier and Kelsey 567 Bruce Schneier and John Kelsey of Counterpane Internet Security 568 presented a paper at the the Seventh USENIX Security Symposium on 569 cryptographic mechanisms for preserving message integrity and 570 confidentiality when storing log messages on an untrusted 571 system[11]. They also presented a follow-up paper on accessing those 572 logs over a network at the Second International Workshop on the 573 Recent Advances in Intrusion Detection (RAID '99)[12]. To the best 574 of my knowledge, no practical implementations of this system has 575 been built. 577 5.3 Nsyslogd 579 Nsyslogd is a drop-in Syslog replacement developed by Darren Reed of 580 The Australian National University that sports improved filtering 581 based on regular expressions, guaranteed message delivery and 582 ordering through the uses of TCP as a transport mechanism, and 583 on-the-wire privacy through SSL/TLS.[13] 585 5.4 Secure Syslog 587 Secure Syslog is another drop-in Syslog replacement, this one 588 developed by Core-SDI. It offers message integrity and 589 confidentiality guarantees through the use of Core-SDI's PEO-1 590 cryptographic protocol.[14] 592 5.5 ULM 594 ULM is a toolset developed by Herve Schauer Consultants to query 595 Syslog based logs that are stored in a structured format. The 596 original version of this tool used a format described in a 597 now-expired Internet Draft by Abela and Debeaupuis[15]. A newer 598 version uses an XML schema developed by author C. Calabrese and 599 based on the original ULM format.[16] 601 5.6 syslog-ng 603 Syslog-ng is another drop-in Syslog replacement, this one developed 604 by Balazs Scheidler of BaliBit Computing. Like Nsyslogd, it offers 605 improved filtering and guaranteed message delivery and ordering. 606 Unlike Nsyslogd, it does not offer SSL/TLS support, but it does 607 support message integrity through the use of digital signatures.[17] 609 5.7 SNMPv3 611 While not designed purely for logging applications, SNMPv3[21] does 612 provide most of the mechanisms required for secure logging through 613 its User-based Security Model[22] and View-based Access Control 614 Model[23]: 616 o Data encryption to support confidentiality. 618 o Cryptographically based identification of principles (i.e., 619 signing keys). 621 o Cryptographically assured data integrity (i.e., signed message 622 authentication codes). 624 o Ability to detect lost and replayed messages. 626 Looking back at the fundamental requirements for computer security 627 defined in the TCSEC[4], SNMPv3 is still missing the ability to 628 specify access control labels labels associated with each message. 630 6. Conclusions 632 Although several systems have been developed to improve upon the 633 ubiquitous Syslog system, none adequately addresses all the 634 requirements identified here. It is hoped that this exercise of 635 identifying these requirements will provide the designers of these 636 and other logging systems with the input they need to address all 637 these issues. In particular, this document and the process behind 638 its development are playing an important role in the development of 639 system logging protocols being carried out by the IETF Security 640 Issues in Network Event Logging Working Group. 642 This process has identified the following as areas that need to be 643 addressed: 645 o Log message format structures to support Identification of Event 646 Threads, Event Correlation, and Event Filters. 648 o Security mechanisms to support log message Access Control Labels, 649 Message Identification, Selective Storage, Message 650 Confidentiality, Message Integrity, and System Availability. 652 So far, the process has generated Internet-Drafts on 654 o How the current Syslog protocol operates [10]. 656 o Reliable delivery of Syslog data between machines.[18] 658 o Confidentiality and integrity of Syslog messages at the Network 659 level.[19] 661 o Confidentiality and integrity of Syslog messages at the Message 662 level.[20] 664 References 666 [1] Bradner, S., "Key words for use in RFCs to Indicate 667 Requirement Levels", RFC 2119, BCP 14, March 1997. 669 [2] University of California Computer Systems Research Group, 670 "Unix Programmer's Manual, 4.3 Berkeley Software Distribution, 671 Virtual VAX-11 Version", April 1986. 673 [3] Brown, A., Calabrese, C., Lonvick, C.M., Reed, D. and M. Roth, 674 "Messages on the Syslogsec@employees.org mailing list", 675 mailing list archive available from 676 http://www.mail-archive.com/syslog-sec%40employees.org/, 677 October, November and December 1999. 679 [4] U.S. Department of Defense, Assistant Secretary of Defense for 680 Command, Control, Communications, and Intelligence, 681 "Department of Defense Trusted Computer System Evaluation 682 Criteria", DoD 5200.28-STD, available from 683 http://www.radium.ncsc.mil/tpep/library/rainbow/5200.28-STD.html 684 , December 1985. 686 [5] ISO/IEC, "Common Criteria for Information Technology Security 687 Evaluation Version 2.1", International Standard ISO/IEC 688 15408:1999, available from 689 http://www.radium.ncsc.mil/tpep/library/ccitse/ccitse.html, 690 August 1999. 692 [6] U.S. National Security Agency, Information Systems Security 693 Organization, "Labeled Security Protection Profile", available 694 from 695 http://www.radium.ncsc.mil/tpep/library/protection_profiles/index.html 696 , October 1999. 698 [7] Scheidler, B., "Private correspondence", March 2000. 700 [8] Roth, M., "Private Correspondence", March 2000. 702 [9] U.S. National Security Agency, Information Systems Security 703 Organization, "Controlled Access Protection Profile", 704 available from 705 http://www.radium.ncsc.mil/tpep/library/protection_profiles/index.html 706 , October 1999. 708 [10] Lonvick, C.M., "syslog Protocol", draft-ietf-syslog-syslog-03 709 (work in progress), January 2001. 711 [11] Schneier, B. and J. Kelsey, "Cryptographic Support for Secure 712 Logs on Untrusted Machines", The Seventh USENIX Security 713 Symposium Proceedings, USENIX Press pp. 53-62, available from 714 http://www.counterpane.com/secure-logs.html, January 1998. 716 [12] Schneier, B. and J. Kelsey, "Minimizing Bandwidth for Remote 717 Access to Cryptographically Protected Audit Logs", Second 718 International Workshop on the Recent Advances inIntrusion 719 Detection (RAID '99), available from 720 http://www.counterpane.com/auditlog2.html, September 1999. 722 [13] Reed, D., "Nsyslogd home web page", available from 723 http://coombs.anu.edu.au/~avalon/nsyslog.html. 725 [14] Core-SDI, "README file for the Secure Syslog package", 726 available from 727 http://www.core-sdi.com/english/slogging/ssyslog-dl.html, 1998. 729 [15] Abela, J. and T. Debeaupuis, "Universal Format for Logger 730 Messages", May 1999. 732 [16] Jombart, N., "Private correspondence", May 2000. 734 [17] BaliBit Computing, "Syslog-ng home web page,", available from 735 http://www.balabit.hu/products/syslog-ng/. 737 [18] New, D. and M.T. Rose, "Reliable Delivery for Syslog", 738 draft-ietf-syslog-reliable-03 (work in progress), November 739 2000. 741 [19] Kelsey, J., "Syslog-Auth Protocol", draft-ietf-syslog-auth-00 742 (work in progress), December 2000. 744 [20] Kelsey, J., "Syslog-Sign Protocol", draft-ietf-syslog-sign-00 745 (work in progress), December 2000. 747 [21] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction 748 to Version 3 of the Internet-standard Network Management 749 Framework", RFC 2570, April 1999. 751 [22] Blumenthal, U. and B. Winjen, "User-based Security Model (USM) 752 for version 3 of the Simple Network Management Protocol 753 (SNMPv3)", RFC 2574, April 1999. 755 [23] McCloghrie, K., Presuhn, R. and B. Winjen, "View-based Access 756 Control Model (VACM) for the Simple Network Management 757 Protocol (SNMPv3)", RFC 2575, April 1999. 759 Authors' Addresses 761 Christopher J. Calabrese 762 The SANS Institute 763 26 Wellesley Road 764 Upper Montclair, NJ 07043 765 US 767 Phone: +1 973 233 1464 768 EMail: chris_calabrese@yahoo.com 770 Magosanyi Arpad 771 Association of Hungarian Linux Users 773 EMail: mag@lme.linux.hu 775 Appendix A. Acknowledgements 777 The authors gratefully acknowledge the contributions of: Alex Brown, 778 Tony Finch, Chris M. Lonvick, David T. Perkins, Darren Reed, Mark 779 Roth, Herve Schauer, and Balazs Scheidler. 781 Full Copyright Statement 783 Copyright (C) The Internet Society (2001). All Rights Reserved. 785 This document and translations of it may be copied and furnished to 786 others, and derivative works that comment on or otherwise explain it 787 or assist in its implementation may be prepared, copied, published 788 and distributed, in whole or in part, without restriction of any 789 kind, provided that the above copyright notice and this paragraph 790 are included on all such copies and derivative works. However, this 791 document itself may not be modified in any way, such as by removing 792 the copyright notice or references to the Internet Society or other 793 Internet organizations, except as needed for the purpose of 794 developing Internet standards in which case the procedures for 795 copyrights defined in the Internet Standards process must be 796 followed, or as required to translate it into languages other than 797 English. 799 The limited permissions granted above are perpetual and will not be 800 revoked by the Internet Society or its successors or assigns. 802 This document and the information contained herein is provided on an 803 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 804 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 805 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 806 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 807 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 809 Acknowledgement 811 Funding for the RFC editor function is currently provided by the 812 Internet Society.