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