Hi, I tried to create a prioritized list of threats, however as I see we have separate threats that affect the hop-by-hop nature of syslog (which is not present in SNMP, AFAIK) and the messages itself.
So the list of threats is doubled: a threat can be affecting a single sender and each message of that sender (per-message threats), and a threat can affect the hop-by-hop link between two relays where the information sent by multiple senders are "merged". Primary threats: ---------------- * modification of information while transported from one relay to the next (integrity checking, hop-by-hop) * disclosure of information while transported from one relay to the next (encryption, hop-by-hop) * masquerading as an information sender while transported from one relay to the next (authenticity checking, hop-by-hop) Secondary threats: ------------------ * modification of information while it traverses multiple relays (integrity checking, per-message) * masquerading as an information sender while the message traverses multiple relays (authenticity checking, per-message) * message stream modification for an individual sender (reordering and replay, per-message) * message stream modification while messages are being transported from one relay to the next (reordering and replay, hop-by-hop) Less important threats: ----------------------- * DoS * Traffic Analysis My rationale of giving more importance to hop-by-hop threats is that it is easier to build a syslog infrastructure which does hop-by-hop encryption/integrity/authenticity than one which expects _ALL_ sending devices to sign messages. And additionally a dedicated syslog infrastructure can already be trusted enough not to modify in-transit messages which makes per-message authenticity less important. My vision is as follows: legacy syslog device -> encryption capable relay -> log center where the encryption capable relay is close to the syslog source, so that the link between them can be trusted (e.g. possibly dedicated local LAN), and the encryption capable relay can use all nifty crypto stuff to make sure that the center receives what it originally received. And one last note: I've put message stream modification to the secondary group, even though I know that any decent crypto transport layer is capable of eliminating this threat. On Thu, 2006-01-26 at 09:46 -0500, HarringtonDavid 73653 wrote: > Hi, > > Since syslog and snmp are both IETF standards for network management, I think > it would be beneficial to consider the same set of security requirements. The > set of requirements in RFC3411 have undergone signficant review within the > IETF, and especially within the security community of the IETF. Therefore I > recommend that the syslog WG consider the threats described in RFC3411, > section 1.4. > > It is possible the requirements will be different for syslog than for snmp, > but it would be good to discuss the requirements in similar terms so > operators can understand how to balance the security properties, and mitigate > the security threats, of the two protocols when used within the same system. > > >From RFC3411: > 1.4. Security Requirements of this Architecture > > Several of the classical threats to network protocols are applicable > to the management problem and therefore would be applicable to any > Security Model used in an SNMP Management Framework. Other threats > are not applicable to the management problem. This section discusses > principal threats, secondary threats, and threats which are of lesser > importance. > > The principal threats against which any Security Model used within > this architecture SHOULD provide protection are: > > Modification of Information > The modification threat is the danger that some unauthorized > entity may alter in-transit SNMP messages generated on behalf > of an authorized principal in such a way as to effect > unauthorized management operations, including falsifying the > value of an object. > Masquerade > The masquerade threat is the danger that management operations > not authorized for some principal may be attempted by assuming > the identity of another principal that has the appropriate > authorizations. > > Secondary threats against which any Security Model used within this > architecture SHOULD provide protection are: > > Message Stream Modification > The SNMP protocol is typically based upon a connectionless > transport service which may operate over any subnetwork > service. The re-ordering, delay or replay of messages can and > does occur through the natural operation of many such > subnetwork services. The message stream modification threat is > the danger that messages may be maliciously re-ordered, delayed > or replayed to an extent which is greater than can occur > through the natural operation of a subnetwork service, in order > to effect unauthorized management operations. > > Disclosure > The disclosure threat is the danger of eavesdropping on the > exchanges between SNMP engines. Protecting against this threat > may be required as a matter of local policy. > > There are at least two threats against which a Security Model within > this architecture need not protect, since they are deemed to be of > lesser importance in this context: > > Denial of Service > A Security Model need not attempt to address the broad range of > attacks by which service on behalf of authorized users is > denied. Indeed, such denial-of-service attacks are in many > cases indistinguishable from the type of network failures with > which any viable management protocol must cope as a matter of > course. > > Traffic Analysis > A Security Model need not attempt to address traffic analysis > attacks. Many traffic patterns are predictable - entities may > be managed on a regular basis by a relatively small number of > management stations - and therefore there is no significant > advantage afforded by protecting against traffic analysis. -- Bazsi _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
