Subject: [sip-clf] Proposed threat model for SIP CLF

From: Chris Lonvick <[email-masked]>
Date: Sat, 27 Mar 2010 18:15:33 -0700 (PDT)

Hi,

I discussed having a threat model for the SIP CLF file in the WG meeting. 
I whipped this up on the flight home.

==========
Threat Model for SIP CLF

The following threats may be considered for the CLF file while it is 
stored:
- An attacker may gain access to view the CLF file, or may surreptitiously
   make a copy of the CLF file for later viewing.
- An attacker may modify records in the CLF file, or may insert old
   messages into the CLF file - in essence, a replay attack.
- An attacker may delete parts of, or the entirety of the CLF file.

It is outside the scope of this document to specify how to protect the CLF 
file while it is stored.  However, operators may wish to consider using 
common administrative features such as disk encryption and securing log 
files.  [Informational reference here: 
http://www.schneier.com/paper-auditlogs.html ] Operators may also wish to 
consider hardening the machine on which the CLF file is kept by 
restricting access to the device where it is stored and also restricting 
access to the files themselves to only those who need to access it.

The following threats may be considered for transferring the CLF file, or 
while transferring CLF file records:
- An attacker may view the records.
- An attacker may modify the records or may insert old messages into the
   record stream.
- An attacker may remove records in transit, or may stage a
   man-in-the-middle attack to deliver a partially or entirely false CLF
   file.

It is also outside the scope of this document to specify how to protect 
the CLF file or records as they are being transferred.  However, operators 
may wish to consider using common security protocols such as are described 
in RFC 3552 to transfer the CLF file or individual records. 
Alternatively, the CLF file may be transferred via bulk methods that also 
guarantees integrity, or at least detects and alerts to modification 
attempts.

==========

For the latter, the syslog WG produced a threat model for syslog and 
documented it in Section 2 of RFC 5425.  I don't think that the DoS and 
traffic analysis threats really apply to moving around the SIP CLF file or 
records.

There may be other threats and mitigation methods, or other references. 
If you can think of them, please add to this.

Thanks,
Chris

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Sun, 28 Mar 2010 10:32:34 -0500

On 03/27/2010 08:15 PM, Chris Lonvick wrote:
> Hi,
>
> I discussed having a threat model for the SIP CLF file in the WG
> meeting. I whipped this up on the flight home.
[...]

Chris: The write-up is eminently reasonable.  I will include
it in the next revision of the sipclf-problem-statement draft.

Thank you for your time on the suggested text.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 30 Mar 2010 13:21:04 -0500

Chris,

I'd like to echo Vijay's thanks for this suggested text.

I had a chat on the way out of the room on Friday morning about whether we 
might also want to say anything about whether we expect implementations to 
truncate log files from the beginning or the end, when a SIP node runs out 
of log space. There probably are other operational things we need to say 
about the work we're chartered to do, too ;-)

Spencer

> _______________________________________________
> sip-clf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-clf