Re: [cicm] Use Cases
"Davidson, John A." <JOHN.A.DAVIDSON@saic.com> Mon, 29 August 2011 14:25 UTC
Return-Path: <JOHN.A.DAVIDSON@saic.com>
X-Original-To: cicm@ietfa.amsl.com
Delivered-To: cicm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE0D21F8876 for <cicm@ietfa.amsl.com>; Mon, 29 Aug 2011 07:25:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.386
X-Spam-Level:
X-Spam-Status: No, score=-1.386 tagged_above=-999 required=5 tests=[AWL=-1.087, BAYES_00=-2.599, MANGLED_STOP=2.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICW39PYDVl4i for <cicm@ietfa.amsl.com>; Mon, 29 Aug 2011 07:25:57 -0700 (PDT)
Received: from cpmx2.mail.saic.com (cpmx2.mail.saic.com [139.121.17.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0906921F893C for <cicm@ietf.org>; Mon, 29 Aug 2011 07:25:57 -0700 (PDT)
Received: from 0599-its-sbg02.saic.com ([139.121.20.253] [139.121.20.253]) by cpmx2.mail.saic.com with ESMTP id BT-MMP-9101199 for cicm@ietf.org; Mon, 29 Aug 2011 07:27:09 -0700
X-AuditID: 8b7911db-b7cafae00000407d-0a-4e5ba1bcf18a
Received: from 0599-its-exbh01.us.saic.com (cpe-z7-si-srcnat.sw.saic.com [139.121.20.253]) by 0599-its-sbg02.saic.com (Symantec Brightmail Gateway) with SMTP id 9B.5A.16509.DB1AB5E4; Mon, 29 Aug 2011 07:27:09 -0700 (PDT)
Received: from 0461-its-exmb09.us.saic.com ([10.8.67.20]) by 0599-its-exbh01.us.saic.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 29 Aug 2011 07:27:09 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 29 Aug 2011 07:27:08 -0700
Message-Id: <7EDDD87A9A1D7F4DB6F78BC55AA4955002085E7C@0461-its-exmb09.us.saic.com>
In-Reply-To: <F9AB58FA72BAE7449E7723791F6993ED0630EDD3B8@IMCMBX3.MITRE.ORG>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [cicm] Use Cases
Thread-Index: AcxkLTeZAvR3bwFMSYqPf+pySxYTSgCJ2nxA
References: <F9AB58FA72BAE7449E7723791F6993ED0630EDD3B8@IMCMBX3.MITRE.ORG>
From: "Davidson, John A." <JOHN.A.DAVIDSON@saic.com>
To: CICM Discussion List <cicm@ietf.org>
X-OriginalArrivalTime: 29 Aug 2011 14:27:09.0106 (UTC) FILETIME=[BC1C4920:01CC6657]
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [cicm] Use Cases
X-BeenThere: cicm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: CICM Discussion List <cicm@ietf.org>
List-Id: CICM Discussion List <cicm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cicm>, <mailto:cicm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cicm>
List-Post: <mailto:cicm@ietf.org>
List-Help: <mailto:cicm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cicm>, <mailto:cicm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Aug 2011 14:25:57 -0000
Lev, When you refer to "sides" in #4, it may lead us to model the "red side" as "considered secure" and the black side as "considered unsecured". The secure/unsecured view leads us to think that there is something more than isolation that makes the red domain "secure." That has a "my machine; my data vs. their stuff" security policy orientation. There is another orientation that may be more applicable for so-called high assurance. That is the Their (the gov's) Top Secret, Their Secret and Their Unclassified, where none of the domains are "considered secure" from a trustworthy-ness POV. The reason we have to treat all application SW domains as "not trustworthy" for the latter orientation is that we do not have the COMPUSEC technology to make software good enough to be trustworthy. So we must enforce the policy from externally to the application SW, that is, from the OE to achieve high assurance. In a model that realistically addresses high assurance today, all the software has to do is stay out of the way (not try to violate rules). I mention this because it the link in #4 implies just 2 "sides" and it implies communication between those "sides" that encourages software to fail to "stay out of the way" and violate rules by trying to communicate from red to black with bypass and such. While lots of people (HAIPE et al) want to do that, I suggest our models stop short of encouraging, suggesting or even enabling it because to do so creates an architecture that we don't know how to secure today. That is not what we are about. John -----Original Message----- From: cicm-bounces@ietf.org [mailto:cicm-bounces@ietf.org] On Behalf Of Novikov, Lev Sent: Friday, August 26, 2011 1:18 PM To: CICM Discussion List (cicm@ietf.org) Subject: [cicm] Use Cases I started a rewrite of draft-lanz-cicm-lm and want to discuss the use cases we want included in the Logical Model. Here's a short list I've got so far: 1. Two networks each in their own security domain (archetypal high assurance data-in-transit case) 2. Traditional data-in-transit and -at-reset case (cf. PKCS#11) 3. One network with two security domains (cf. network storage; data-in-transit and -at-rest ) 4. One machine with two security domains in software (cf. Vincent Roca's slides http://www.ietf.org/proceedings/81/slides/cicm-1.pdf) The resulting model will be used to analyze the impact on existing protocols where, for example, there might not be separate security domains. ** Anything else to add to the use case list? Thanks, Lev _______________________________________________ cicm mailing list cicm@ietf.org https://www.ietf.org/mailman/listinfo/cicm
- [cicm] Use Cases Novikov, Lev
- Re: [cicm] Use Cases Kevin W. Wall
- Re: [cicm] Use Cases Davidson, John A.
- Re: [cicm] Use Cases Novikov, Lev
- Re: [cicm] Use Cases Kevin W. Wall
- Re: [cicm] Use Cases Novikov, Lev
- Re: [cicm] Use Cases Krishnamurthy, Hema - ES
- Re: [cicm] Use Cases Davidson, John A.
- Re: [cicm] Use Cases Fitton, John
- Re: [cicm] Use Cases Novikov, Lev
- Re: [cicm] Use Cases Davidson, John A.
- Re: [cicm] Use Cases Cottrell Jr., James R.
- Re: [cicm] Use Cases Davidson, John A.
- Re: [cicm] Use Cases Fitton, John
- Re: [cicm] Use Cases Fitton, John
- Re: [cicm] Use Cases Davidson, John A.
- Re: [cicm] Use Cases Davidson, John A.
- Re: [cicm] Use Cases Fitton, John