Re: [cicm] Use Cases

["Novikov, Lev" <[e-mail]>]

John,

On 2011-08-29 10:27, John Davidson wrote:
> 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.

This is an excellent point. Security domains do not define trust, per se. They
are defined by a security policy which specifies, among other things, how data
moves into/out of that domain. This is the definition we previously used.
For example, see "$ security domain" in
http://tools.ietf.org/html/draft-lanz-cicm-lm-01

Therefore, I'm going to add "multiple levels of security domains" to the list of
use cases. This should cover a broad list of arrangements including Joe Mitola's
use cases (personal data, NDAs, content-based roles).

FYI: By adding this use case, I'm not saying that CICM needs to support Multiple
Levels of Security (MLS) and/or Multiple Independent Levels of Security (MILS),
but I am saying we shouldn't do anything to prevent someone from using it those
configurations, if they so choose.
See http://tools.ietf.org/html/draft-lanz-cicm-lm-01#section-1.4

> 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.

The use cases are intentionally broad because we are trying to build a framework
which will facilitate analysis of existing IETF protocols using a domain-centric
approach. Certainly, the classic high assurance cases (1, 3) can be used, but
we're evaluating the impact on existing approaches.

Our current list so far:
1. high assurance data-in-transit (two networks, two domains)
2. traditional data-in-transit or -at-rest (cf. PKCS#11)
3. one network, two domains (cf. network storage; data-in-transit + -at-rest)
4. one machine, two domains in software (via Vincent Roca)
5. secure key exchange (via Kevin Wall)
6. multiple levels of security domains (via John Davidson/Joe Mitola;
  one or more networks, multiple domains)

Any others?

Regards,
Lev