[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SAs and SPIs
Several contributors to the SA-SPI discussion effort have expressed
concern that the Corporations mentioned in my examples were from the
Military-Industrial complex and were not typical. In fact they were as far
from this area as I could manage. Among the firms referenced were Amgen,
Genzyme, Polaroid, Kodak, Solomon Industries, Hickok, Honeywell, and
Genelabs. It is my observation that commercial international concerns are at
least as concerned with security as the Military-Industrial complex. A look
at current litigation at GM, Kodak, VW, and other firms would seem to
confirm this. Also, large multinational corporations must protect themselves
since divisions and projects are spread out and there is no simple inside
and outside. The same applies to smaller firms which often do business with
several larger firms and are expected to keep the work and transaction
details carefully protected. A good example is the biotech firms where
product development must be carefully protected and success or failure can
depend on this protection. These firms are often divided into separate
development areas, which have funding from and interaction with larger
(well-financed) pharmaceutical corporations.
I appreciate that there is an effort to "crash out" such documents as ARCH,
ESP, AH, ISAKAMP, OAKLEY, DOMAIN, etc. (and I apologize for adding to the
general glut of responses.) The question remains: How can business
requirements be managed in a less than simple environment where contractor
channels need to be easily opened and closed, and new projects started and
old terminated without untoward management strains. All this should be done
without passing access control (based on other than simple address-based key
management) off to something lurking outside a tunnel-like environment?
In looking for answers, we notice Steve Kent's comments on the possible use
of a blank section in the architecture document. This looked like a real
possibility, however, work on this section will apparently be deferred to
later versions .
Fortunately, we notice the security domain draft has in Section 4.6.1 two
fields (with associated length fields) which can be used for (1) security
levels, and, (2) categories.
There are several things to be noticed concerning the term "security
categories." (First, lets note that the term "security markings" is
generally used to delineate security categories like "Company Confidential",
"Release to Camera Production", "Release to Hickok Accounting", etc.) I'll
use names like these for categories as a help in writing.
There are two basic types of categories. These are often called
"compartments" and "release markings".
1. Compartments are normally taken to be "all or nothing" markings. Lets
consider the simple case of a single organization and its employees (or
departments) which need to communicate. Among the compartments we find:
"Camera-Engineering", "New-PL-Project", and "Shutter-Design". These markings
name compartments which are a particular kind of category, and if a document
has all three compartment names on it, an employee must be in all three
compartments to have a right to the information in this area. (Perhaps the
best known philosopher (he was Austrian) of this century worked on
representation techniques like this and their meanings (also on language
games and truth tables.) There is an English film about him which is good
silly fun if you are not easily shocked. Does anyone know
philosopher-logician and who directed the film? We note the last Security
Intellectual Prize went to Steve Goldhaber for Clockwork Orange and Soldier
of Orange (Soldaat von Orange.)) If we consider the bit map representation
in the domain document, and if we assume the first three bits represent
these compartment markings, communications would require 1s in these
positions when establishing a connection to exchange the document. The
beauty of the bit map is: an access determination can be made by a program
blindly performing a simple logical operation on the two fields and then
testing for 1s in the result. This can be done with three or four machine
language instructions for up to 64 markings (categories-compartments.) The
test can be made without the testing program knowing anything about what the
markings are, leaving the system managers to establish their communications
networking as required. This, of course, assumes system managers have some
easy way to set up the compartments and their names.)
2. Levels are subcategories of compartments. If Level A is higher than
Level B then any entity with an A marking can communicate using B markings
(as can, of course, those with Bs.) If B is higher than C then A can use A,
C, or B; B can use B or C; and C only can use C. This means levels can be
placed in compartment bit maps with no alteration of the simple program
steps which were used for compartments in general. For the above we have 111
for A, 011 for B, and 001 for C. (If you're not familiar with this, try it.
I'm not suggesting the domain protocol be modified by omitting the level
field, just showing possibilities.)
3. The type of commercial marking not covered above is generally called a
"release category" (for historical reasons, among others.) This is an OR
operation from a logical viewpoint while compartments are ANDed. Typical
markings would be "Release to Genzyme", "Release to Production", "Release to
Accounting", "Release to France," etc. We note that studies indicate release
markings are at least as much used as compartments and are possibly more
used. Processing is as fast as for compartments. They should not be ignored.
It is not possible to mix compartment and release markings in a single bit
map and process with the simple steps described above.
Possible alternatives for fixing the domain document so program developers
can be assured of interoperability are: (a) divide the bit map field length
in two and place compartment bits in the first half and release bits in the
second half. This means that programs written to comply with the standard
must process the halves separately. (b) Have an extra length field that
gives the length of the compartment field (or release) markings. (c) Decide
once and for all which part of the field is for compartments and which is
for release markings and fix the length. (d) Have separate fields for
compartment and release markings, including length fields. The above will
result in approved (OK) standards programs which can process without
additional information, simplifying standard compliant program preparation.
It also helps clarify what the standard means.
My choice would be (d), which allows programs to process the fields without
further information exchange and also gives maximum freedom of category
representation. It would also not be a bad idea to label the fields. Lets
hear from those who understand the above and see possibilities. A little
care might expand markets.
Follow-Ups: