Return-Path: Received: from murder ([unix socket]) by eikenes.alvestrand.no (Cyrus v2.2.8-Mandrake-RPM-2.2.8-4.2.101mdk) with LMTPA; Fri, 12 Aug 2005 11:09:56 +0200 X-Sieve: CMU Sieve 2.2 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0FA0532009A for ; Fri, 12 Aug 2005 11:09:56 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07967-01 for ; Fri, 12 Aug 2005 11:09:51 +0200 (CEST) X-Greylist: domain auto-whitelisted by SQLgrey-1.4.8 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by eikenes.alvestrand.no (Postfix) with ESMTP id C4144320099 for ; Fri, 12 Aug 2005 11:09:47 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3VVs-00022W-S0; Fri, 12 Aug 2005 05:07:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3VVq-00022N-1p for ietf@megatron.ietf.org; Fri, 12 Aug 2005 05:07:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11911 for ; Fri, 12 Aug 2005 05:07:35 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3W4K-0002Vx-G4 for ietf@ietf.org; Fri, 12 Aug 2005 05:43:16 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1E3VVY-0000Hn-Hk; Fri, 12 Aug 2005 02:07:20 -0700 Message-Id: <6.2.1.2.2.20050812101801.050755a0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 12 Aug 2005 11:07:12 +0200 To: Bill Sommerfeld , Stephen Kent From: "JFC (Jefsey) Morfin" In-Reply-To: <1123798200.14955.137.camel@thunk> References: <42FA5884.9060103@cisco.com> <42FB1640.5020906@zurich.ibm.com> <42FB664A.60605@cisco.com> <01LRP7VL7OTW000092@mauve.mrochek.com> <1123798200.14955.137.camel@thunk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Ned Freed , Michael Thomas , ietf@ietf.org Subject: Re: what is a threat analysis? X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org X-Virus-Scanned: by amavisd-new at alvestrand.no At 00:10 12/08/2005, Bill Sommerfeld wrote: >So an effort to come up with a consensus threat analysis sounds like a >very good idea. It might even be worthy of a working group of its own >as it would likely be useful as a base for more than just the MASS/DKIM >work. Agree. After 9/11 ICANN changed all its priorities towards security. I proposed the BC (Business Constituency) to work on an "ICP-4 Network Security" proposition (ICPs are the ICANN documents). Several large operators, manufacturers contributed to the project which went to an end rather quickly for Layer 8/9 reasons. The first things we tried to do was: - to list all the possible types of threads on the conceptual network (this does not include the user security by itself). - all the motivations for attacks - from war down to employee retaliation or flooding, etc. We saw it was an iterative process. Motivations helping identifying threats, and vice versa. I am not sure I still have a copy of the work we carried (it was privately made in the paranoia of security which was the mood), but I established a method to help it. Anyway from this experience I would suggest the Charter of such a group should be discussed with an enlarged committee including Steve Crocker's ICANN security committee, people from Govs, Military and Commercial Intelligence, people from GAC, people from targeted industries (Banks, Airlines, critical infrastructures, life depending solutions). I used this experience when considering the network security aspects in the dot-root test-bed, carried in 2002/2003, and for the resulting "national vulnerability to the internet" meetings I organised for France in 2003/2004. This lead to the identification of the need of a compartmentalisation of the internet for risk containment, intelligence protection, community development, service innovation, spaces of exhanges, trust and services, etc. and of the need to analyse, organise and run its intergovernance. We incorporated the AFRAC as a national internet community effort to work and test on the matter. We observed that it was the best way to achieve the necessary virtual partitionning of the internet while preventing the grassroots balkanisation which develops. Basically it means that the unicity and the unity of the global network will be supported and stenghtened by a myriad of well established, suited and protected externets (virtual external network look-alike). Security of a distributed network is to be distributed. Also, one has to consider the external implications of the security failures and understand that threats can be to second, third etc. degree, the implication can be major and concern (due to the today implication of the Internet in the world's life) the life of millions. This was the first study, which served as basis for the thinking, and the most important one todate due to its implications: http://whitehouse.gov/pcipb and its preparation is certainly a basic input to consider in that area. Question is: is that IETF? IETF is probably more interested in the resulting specifications? The implications on the current internet structure and vision are important. jfc _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf