[sip-clf] Proposed threat model for SIP CLF

Chris Lonvick <clonvick@cisco.com> Sun, 28 March 2010 01:15 UTC

Return-Path: <clonvick@cisco.com>
X-Original-To: sip-clf@core3.amsl.com
Delivered-To: sip-clf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D5543A683B for <sip-clf@core3.amsl.com>; Sat, 27 Mar 2010 18:15:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.869
X-Spam-Level:
X-Spam-Status: No, score=-6.869 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l90QqnD7935F for <sip-clf@core3.amsl.com>; Sat, 27 Mar 2010 18:15:22 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D30DE3A6810 for <sip-clf@ietf.org>; Sat, 27 Mar 2010 18:15:09 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AoQGAPtJrkurR7H+/2dsb2JhbACPSAEBi2dzo3yYQIUBBIMe
X-IronPort-AV: E=Sophos;i="4.51,320,1267401600"; d="scan'208";a="173409088"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 28 Mar 2010 01:15:33 +0000
Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2S1FX2L026975 for <sip-clf@ietf.org>; Sun, 28 Mar 2010 01:15:33 GMT
Date: Sat, 27 Mar 2010 18:15:33 -0700 (PDT)
From: Chris Lonvick <clonvick@cisco.com>
To: sip-clf@ietf.org
Message-ID: <Pine.GSO.4.63.1003271739350.14383@sjc-cde-011.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Subject: [sip-clf] Proposed threat model for SIP CLF
X-BeenThere: sip-clf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Common Log File format discussion list <sip-clf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip-clf>, <mailto:sip-clf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip-clf>
List-Post: <mailto:sip-clf@ietf.org>
List-Help: <mailto:sip-clf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip-clf>, <mailto:sip-clf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Mar 2010 01:15:33 -0000

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