💾 Archived View for gemini.spam.works › mirrors › textfiles › magazines › NIA › nia-71.phk captured on 2022-06-12 at 13:39:10.
-=-=-=-=-=-=-
Founded By: | _ _______
Guardian Of Time | __ N.I.A. _ ___ ___ Are you on any WAN? are
Judge Dredd | ____ ___ ___ ___ ___ you on Bitnet, Internet
------------------+ _____ ___ ___ ___ ___ Compuserve, MCI Mail,
\ / ___ ___ ___ ___ ___________ Sprintmail, Applelink,
+---------+ ___ ___ ___ ___ ___________ Easynet, MilNet,
| 06MAR91 | ___ ______ ___ ___ ___ FidoNet, et al.?
| File 71 | ___ _____ ___ ___ ___ If so please drop us a
+---------+ ____ _ __ ___ line at
/ \ ___ _ ___ elisem@nuchat.sccsi.com
------------------+ __
Editors: | _ Network Information Access
Judge Dredd | Ignorance, There's No Excuse.
Lord Macduff |
------------------+ Issue 071 :: Volume 02
"The liberty of the press is not confined to newspapers and periodicals.
It necessarily embraces pamphlets and leaflets....The press in its
historical connotation comprehends every sort of publication which
affords a vehicle of information and opinion."
-- Lowell v. City of Griffin, 303 U.S. 444, 452 (1938), quoted by Mike
Godwin in comp.org.eff.talk
=============================================================================
1. Index .......................................................NIA Editors
2. Analysis of the 4-wire Line - An Explanation ........Donald E. Kimberlin
3. Using the UK Academic Network PSS Gateway ......Scantronics Publications
4. DoD Trusted System Evaluation Criteria [02/02] ..............Judge Dredd
5. List of Texas Internet Sites ...............................Lord Macduff
6. Steve Jackson Games vs. Secret Service....................EFF Foundation
7. Editor's Comments ...........................................NIA Editors.
============================================================================
/ /
/ File 02 / NIA071 /
/ The Four Line - An Explanation /
/ Donald E. Kimberlin /
/ /
[Editoral Info: Mr. Kimberlin has been a broadcasting engineer since 1957, with
added time at AT&T in international communications, later
at ITT preforming the same work with international cables and
satellites. Then manufacturers of communications equipmnet
as an export marketer to the government PTT's of 70 countries
on five continents.]
It seems many participants thought such a transmission circuit is
a rather special form of transmission medium; one infrequently used
and perhaps of exceedingly high cost. What follows is an attempt to
describe what is actually a rather common and age-old technique in a
way that might help readers know how to use it for their own benefit.
Most people involved with telephony have only been exposed to
local use, adn even local subscriber line physical plant, where a
single pair of wires is used for a dial subscriber line for one over-
riding reason: The cost of providing service to the majority of users,
people who simply want dial voice-grade telephone service.
Were the local telephone exchanges to use a "four-wire line" to
each and every subscriber, we could have a far more idealized Public
Switched Telephone Network (PSTN - the proper CCITT name). We in the
US often mistitle the PSTN as "DDD," which actually is the Bell
acronym for Direct Distance Dialing (long-distance subscriber dialing,
called STD in the UK, or a close equivalent in other nations).
Transmission losses could have historically been much less, as there
would be no echoes to combat. We would transmit in one direction on
one pair and transmit in the other direction on the other, without
interaction between the two directions. However, to provide such a
plant would require double the literally millions of tones of copper
wire that have been installed worldwide. The economic cost factors
are obvious. Paying for the local cable plant has been a major cost
factor for public telephone networks worldwide. (Other alternatives
such as fiber and coaxial cable used by cable TV companies are making
some change, but the millions of tons of copper are already there ...
and ISDN is planned in a way to try to continue to use that imbedded
investment.
So, a local telephone plant uses only one pair per subscriber.
In engineering terms, it is far from a perfect transmission line. The
main reason is that no transmission line operates at its normal
electrical "impedance" until it is a significant portion of an
electrical wavelength of the signal it carries. Studying a beginning
physics book will show that one wavelength at 3000 Hertz in a perfect
line is 61 miles, and at 300 Hertz, it would be 610 miles! (Another
factor called the "propagation velocity" even stretches this _much_
more in practical wire.) Obviously, to have even reasonably
well-matched wire would not be reasonable, and it wasn't at all
economical in the developmental era of the PSTN. So, this network
evolved assuming some very large tradeoffs were needed.
An electrical transmission line has one interesting
characteristic just opposite from water pipes or acoustical guides
(hollow tubes). Instead of an open distant end letting all the energy
spill out, an open-ended electrical line _reflects_ all its received
power back toward the source. A shorted line absorbs all the energy
(as you find out when you short a power line and blow the fuse!).
What this characteristic means to telephone transmission is that with
lines as short as they must be in local plant, echoes are reflected
back toward the speaker, subject only to the losses they incur
rattling back and forth. They really are pretty high, but we don't
notice them. The reason: Echoes that return to our ear in less than
about 10-15 thousandths of a second are heard by us a part of the
outbound signal ... we just don't hear them. Local connections are
short enough that for general telephony, echoes can be largely
discounted, even thought they are there.
Very early in the development of longer transmission paths, it
was learned that transmission losses mount rapidly when one really
does have miles and miles of wire to talk on. In intercity
transmission lines, use of electronics to amplify the signal as
intervals was seen to be mandatory to achieve commercially successful
"long lines." Thus, as soon as the three-electrode vacuum tube was
available, the telephone industry had a very real interest in it, and
pressed to realize its use as soon as possible. (In fact, a Bell Labs
worker contributed "negative feedback" to the early vacuum-tube
circuitry, making the "tube" a controllable, useful technology instead
of a physics lab curio.)
But, the vacuum tube (as its descendant, the transistor) has one
limitation. It can pass a signal in only one direction, a
characteristic that happens to match that idealized "four-wire"
transmission line. So, "long lines" very early on (in the 1910-15
time frame) all became "four-wire lines."
They did, however, have to interface to the echo-prone and less
controllable local "two-wire" (single pair) telephone networks. The
method devised was the "hybrid," in telephony mostly an arrangement of
trans- formers that had three windings, one for the local two-wire
side and one each for the sending and receiving "long lines." Now,
echoes were a real problem. Not only would echoes from the local
two-wire line take long enough to return to the distant city to be
heard, but impedance mismatching of the two-wire local line to the
transformer could cause received distant signals to reflect right in
the transformer back down the transmitting channel as well. "Echo
control" became a major topic in handling "long lines." (The trick is
to add a fourth winding set to the transformer with an "artificial
line" that is adjusted to create the match. In telephony, its name is
a "balancing network."
All this sort of work was at first (and for decades) the work of
the "long lines" people. Very little of it was in the hands of the
local people. The "long lines" people were AC and electronics people,
while the local people were DC and electrical people. The oeprational
reasons for having a "Long Lines Department" are obvious in this
context.
As multichannel "carrier systems" evolved (and early, too,
beginning around 1915 between Toledo, Ohio and South Bend, Indiana in
the US), their intrinsic electronic transmission using vacuum tubes
made a "four-wire" (of virtual wires, certainly) a commonplace in
intercity transmission. And every "carrier system" since the
beginning has been made of "four-wire" paths ... set up in pairs of
channels, one for each direction of transmission, needing that
"hybrid" function at each end to connect to the local plant.
In intercity (and more so international) carrier systems, a
"line" transiting a junction point can be (and is) connected on a
"four-wire" basis, either _through_ a "four wire switching machine"
for PSTN temporary connections, or hard-wired _around_ the switching
machine if the use is a semi-permanent "special services" circuit,
like a dedicated data line or indeed, a permanent speech circuit, as
is CNN's "four-wire line," our subject here. At the end points, one
local pair is used for each direction of transmission ... at a price
reflective of using twice the local plant. Local wire pairs ...
"loops" ... for "special services" are expensive to rent. After all,
they are no longer available for the local telco to derive PSTN
revenue on. If reaching the "long lines" point of presence (now
called a "POP" in American jargon) requires use of local wire
(nowadays local carrier channels) across a city, these are no longer
available for "trunk" use between local PSTN exchanges, considerable
revnue potential is lost, and is going to be paid for. Thus, many
speech-only "private circuits" do have a hybrid in the "POP" and use
only one local pair anyway ... but are STILL "four wire channels"
between cities.
The British have some excellent descriptive terminology we
Americans never developed. They speak of transmission circuits as
"two wire presented" or "four wire presented" to the end user. These
terms, of course recognize that long circuits are all "four wire,"
regardless of how they are 'presented" to the end user.
What are the advantages of "four wire presentation?" Avoidance of
the electrical echo bugaboo. And, part of the "control" of echoes in
"two-wire presentations" is to deliberately insert transmission loss
to make the echoes a bit lower, so "four wire presented" channels can
have less loss and sound louder ... and deliver the received signal
higher above the noise ... making the signal sound "cleaner." This of
course is why high-quality dedicated data circuits are four-wire
presented ... to give the modem signals the most advantage possible.
Hopefully, if you have persisted through this longish
explanation, you now know that the "four wire line" is indeed not rare
at all. Rather, it is the norm between cities, and especially between
nations. You know it isn't new. It's just that most people have
never seen one. Improvements in the local plant (including widespread
deployment of digital carrier, the "T" carrier so often spoken of
today) have made extension of the "four-wire line" right into your
local exchange a reality in most places, so even your PSTN phone
sounds much louder and cleaner than it did twenty years ago. That's
what solid-state electronics coupled to digital transmission did for
us all.
Those who really _needed_ the advantages of "four-wire" have used
it for a long time. Major examples were the FAA's network of
dedicated lines that had to be interconnected at random (reflected in
Bell parlance as the "FAA 300-type switching system), and the US
military's AUTOVON network. While AUTOVON was based on four-wire
switching machines throughout right to four-wire telephone sets,
economics even there forced the allowance of two-wire user lines and
telephones for voice-only stations, and many AUTOVON lines wound up
being four-wire. But, AUTOVON also has many "four-wire" user stations
where dedicated-line type "full-duplex' data modems can be used.
For those who really want to learn more, I recommend the following books:
1.) "Basic Carrier Telephony" by David Talley, a real chestnut
of telephone transmission for the non-technical reader who is
weak on physics. Originally published by Hayden Book Company
as their stock number 5749 (Library of Congress catalog number
60-10470 in its second edition, I understand that Wiley in
New York has republished it and finds several Telcos use it for
textbook for technicians.
2.) "Understanding Communications Systems," by Don L. Cannon and
Gerald Luecke, originally published and sold by Radio Shack
stores as part number 62-2018 (ISBN 0-89512-035-6) for $2.95,
this book has been republished by Howard Sams at Indianapolis
for about six times the price in hardback. It uses far less
classic "telephonese" but has excellent ways of showing how
analog and digital transmission are far more related than most
non-technical people can understand.
I recommend both of these books to the harried educators on here
who are frustrated in finding short texts for introductory curricula.
============================================================================
/ /
/ FILE 03 / NIA071 /
/ Scantronics Publications /
/ How to Use the U.K. Academic Network /
/ Packet SwitchStream (PSS) Gateway /
/ and PSS Address List /
/ Submitted By: /<ludge /
/ /
_________________
TABLE OF CONTENTS
1. Warning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.1 Your contacts . . . . . . . . . . . . . . . . . . . . . . . . . 1
3. Summary of Facilities Available Across the Network . . . . . . . . 2
4. Permission to Use the Gateway . . . . . . . . . . . . . . . . . . . 2
4.1 Authentication and Authorisation . . . . . . . . . . . . . . . 2
4.2 Charging and Accounting . . . . . . . . . . . . . . . . . . . . 3
5. How to make Terminal Calls TO the Gateway . . . . . . . . . . . . . 3
6. How to make Terminal Calls THROUGH the Gateway . . . . . . . . . . . 4
6.1 The Transport Service Called Address . . . . . . . . . . . . . 4
6.2 Making Calls using TS29 Protocol . . . . . . . . . . . . . . . 6
6.3 The full address . . . . . . . . . . . . . . . . . . . . . . . 6
6.4 Making Calls Using X29 Protocol . . . . . . . . . . . . . . . . 6
7. Facilities Provided by the Gateway Machine . . . . . . . . . . . . . 7
7.1 HELP Facility . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.2 Account Facility and Changing Your Password . . . . . . . . . . 8
8. Facilities Available THROUGH the Gateway . . . . . . . . . . . . . . 9
8.1 Demonstration Facility . . . . . . . . . . . . . . . . . . . . 9
8.2 Address Mnemonics of Remote Hosts on Networks Connected to
the Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9. Facilities Available on PSS . . . . . . . . . . . . . . . . . . . 10
9.1 Fast Select . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.2 Reverse Charge Facility . . . . . . . . . . . . . . . . . . . 10
9.3 Access to IPSS . . . . . . . . . . . . . . . . . . . . . . . 10
9.4 Calls to Other, Non-Transport Service Networks . . . . . . . 10
9.5 Adjusting Packet Sizes . . . . . . . . . . . . . . . . . . . 11
10. Protocols Available if Supported by Both Local and Remote
Host Machines . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1 Network Independent File Transfer Protocol (FTP) . . . . . . 11
10.2 JNT MAIL Protocol . . . . . . . . . . . . . . . . . . . . . . 12
10.3 Job Transfer and Manipulation Protocol (JTMP) . . . . . . . . 12
11. Restrictions and Errors . . . . . . . . . . . . . . . . . . . . . 12
11.1 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 12
11.2 Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Warning
BETWEEN 8.00 am and 10.00 am every Tuesday, network development and service
work is carried out on JANET. This means that if you make a call during
these hours there is an increased danger of the system going down which may
result in loss of data.
_________________
2. Introduction
The Gateway is a two-way link between the U.K. Academic Network (JANET) and
PSS. At present there are two Gateways between JANET and PSS, one at
Rutherford and another at ULCC in <garbled>.
The Gateway consists of a computer which holds a communications program and
sits between two networks (JANET and PSS in this case). This allows the
user to bridge the gap between the networks and access target computers on
the other network. It is important to realise that there are two ways of
communicating with the Gateway - you can make calls TO the Gateway computer
to access its limited user facilities or you can make calls THROUGH it to a
target computer on the other network.
The Gateway operates as a Transport Level Gateway in accordance with the
'Yellow Book' Transport Service. However the present implementation does
not have a full Transport Service and therefore, there are some limitations
in the service provided. For X29 which is incompatible with the Yellow Book
Transport Service, special facilities are provided for the input of user
identification and addresses.
The Gateway is a protocol transparent link. This means that the Gateway
cannot be used for protocol conversion; to do this a third party machine
must be used.
__________________
2.1 Your Contacts
If you have any problems, or if you want additional information contact the
JANET Network Executive. You can reach them at the following address:-
* By Post at . . . . . . . Network Executive,
c/o Rutherford Appleton Laboratory,
Chilton,
Didcot,
OXON.
OX11 0QX
* By Electronic MAIL to . . PSS Gateway Support@RL.GB
The network address for RL.GB is 00000000210
5
* By Telephone on . . . . . Abingdon (O235) 446748
How to Use the U.K. Academic Network - Packet SwitchStream (PSS) Gateway
_______________________________________________________
3. Summary of Facilities Available across the Network
The network offers a number of facilities. These are listed below for your
information.
* Facilities Provided by the Gateway Machine
- Help Facility
- Accounting Facility
* Facilities Available on the Way Through the Gateway
- Demonstration Facility
- Addresses and Mnemonics
* Facilities Available on PSS
- Fast Select Facility
- Reverse Charge Facility
- Access to IPSS (International Packet Switch Stream)
- Calls to Other, Non-Transport Service Networks
* Protocols Available if Supported by Both Local and Remote Host Machine
s
- Network Independent File Transfer Protocol (FTP)
- JNT MAIL Protocol
- Job Transfer and Manipulation Protocol (JTMP)
__________________________________
4. Permission to Use the Gateway
_____________________________________
4.1 Authentication and Authorisation
No unauthenticated use of the Gateway from JANET is allowed regardless of
whether charges are incurred at the Gateway or not. Therefore to use the
Gateway you have to obtain authentication (a userid and password) and
authorisation (a call allocation) from the JANET Network Executive. This
consists of:
a. USERID
b. PASSWORD
c. USAGE ALLOCATION
Note that the authorisation for PSS and IPSS is managed separately, although
a single USERID may have authoristation for both.
There is no restriction on access from PSS.
How to Use the U.K. Academic Network - Packet SwitchStream (PSS) Gateway
____________________________
4.2 Charging and Accounting
There are 4 separate charging rates, which are:
PSS full rate: PSS (FULL)
PSS discount rate: PSS (DISC)
TLXN: Telex access via Interstream 1.
IPSS full rate: IPSS (FULL)
Note that the TELEX access is expensive, as the cost includes the use of
PSS, Interstream 1 and TELEX. Anyone who is interested in TELEX access
should first discuss it with the Network Executive.
To be able to make chargeable calls you must request a call allocation to
cover the charging rates you want to use when you ask for your
authentication. For calls that are free e.g. calls within JANET or normal
charge calls from PSS you do not need an allocation.
The PSS discount rate applies from 1800 to 0800 each night and all day on
Sundays, Christmas Day and New Year's Day. The PSS full rate applies at ALL
OTHER times. The IPSS full rate applies at ALL times for international
calls. For details of the international rates to various countries consult
Network User Note 2.
If your allocation runs out during an active call, then that call will be
cleared and all further calls at that rate will be refused.
______________________________________________
5. How to Make Terminal Calls to the Gateway
It is possible to make calls to the Gateway to access the HELP and ACCOUNT
facilities.
The HELP facility contains the whole of this user guide in its most uptodate
form. The facility allows random scans of the document and searches for
text within the document.
The Account facility allows the user to inspect the state of his account and
to change the password for that account.
_____________________________________
How to make contact with the Gateway.
If you are calling the RAL Gateway from PSS use the DTE address
234223519191.
If you are calling the RAL Gateway from JANET use the DTE address
000000000040.
If you are calling the London Gateway from PSS use the DTE address
234219200100.
If you are calling the London Gateway from JANET use the DTE address
000040000040.
Make a terminal call to the Gateway.
How to Use the U.K. Academic Network - Packet SwitchStream (PSS) Gateway
A title message will appear on the terminal announcing the Gateway, followed
by the lines:
OS4000+Rlix V30 PSS Gateway
Logging in
user
If nothing appears, keep pressing <CARRIAGE RETURN> until the above message
appears.
It is now possible to log in and use the Help or Account facilities. For
details of these facilities see section 7 of this document.
___________________________________________________
6. How to Make Terminal Calls Through the Gateway
The method used to make a call through the Gateway depends on the type of
PAD being used. If your PAD supports TS29 the procedure is simplified as
this protocol allows you to make calls that can cross several networks via
several Gateways. If your PAD supports X29 then if you wish to cross
several Gateways you normally have to stop at each one before you can pass
through it. However a special facility is provided using the Call User Data
Field to allow X29 calls non-stop through the JANET PSS Gateway.
Whichever protocol your PAD supports, you must have some way of generating a
Transport Service Called Address for onward routing by the Gateway.
_________________________________________
6.1 The Transport Service Called Address
To make a call through the Gateway you have to supply the following
information in the form of a Transport Service Called Address to your local
PAD.
a. Netname: the name of the network you are calling.
b. Authentication: consisting of Userid and Password in that order.
This can be omitted for free calls.
c. Host address: the network address of the remote host.
The format of the Transport Service Called Address is as follows:
<Netname>(<Authentication>).<Host Address>
These are explained below.
_______
Netname
This is one of the following:
JANET to connect to JANET
PSS to connect to PSS
J an alias for JANET.
How to Use the U.K. Academic Network - Packet SwitchStream (PSS) Gateway
______________
Authentication
This consists of 3 fields which must be entered in the order shown.
a. user id,
b. password,
c. A request for the call to be reverse charged.
The last field is optional.
____
Note that the whole authentication string must be enclosed in parentheses.
_______
Example
(FRED,XYZ,R) Requests a reverse charge call
(FRED,XYZ) Requests a chargeable call.
____________
Host Address
This is the numeric address of the machine being called. However to make
things easier the numeric address can be replaced with an alphanumeric
mnemonic if one has been set up on the Gateway.
_______
Example
use RLGB instead of 000000002105 to call the Rutherford GEC 'B' machine
use SALF instead of 234261643210 to call Salford on PSS.
For a list of these mnemonics see JANET User Notes 5 and 6.
Host addresses can be complex and it is possible to specify several Gateways
that you must pass through to reach a specific remote host and/or the
service required. Note that a point (.) must be used to separate the
numeric addresses or mnemonics from the service names.
_______
Example
RLPA - this calls the Rutherford ICF Prime on Janet.
RLPA.FTP - this calls FTP on the Rutherford ICF Prime on Janet.
To connect to some machines, an X25 sub-address is required, which consists
of a number of extra digits added on to the machine address. This can be
easily entered on the Gateway by using the delimiter '-' at the end of the
mnemonic address and then typing the sub-address. When the mnemonic is
translated the delimiter is ignored and the whole address is converted into
a continuous string.
_______
Example
Janet-69 is translated to 23422351919169
How to Use the U.K. Academic Network - Packet SwitchStream (PSS) Gateway
_____________________________________
6.2 Making Calls Using TS29 Protocol
TS29 is the ideal protocol to use through the Gateway, since there should be
no problem entering the Transport Service Called Address. However, first
make sure that the machine you are calling will support TS29. When using
this protocol for network terminal calls the service name of the TS29 server
should be entered explicitly.
_____________________
6.3 The Full Address
Combining all these factors a full address might look like this.
J(FRED,XYZ).RLGB.TS29
____________________________________
6.4 Making Calls Using X29 Protocol
X29 is incompatible with the 'Yellow Book' Transport Service and some PADS
are unable to generate the Transport Service Called Address. When making an
X29 call, the onward Called Address may be entered into the Call User Data
Field of the Call. Some PADs, e.g. the British Telecom PAD are unable to
generate a Call User Data Field longer than 12 characters and so there may
not be enough space to hold all the information required. In this case, a
Call must be established only as far as the Gateway, and a dialogue held
with the Gateway to establish the next part of the connection.
If your PAD can generate a Call User Data Field, then the first character of
the text is treated as a delimiter, and should be entered as the character
'@' followed by the onward Called address.
_______
Example
On a CAMTEC PAD one might enter:-
CALL 00004000004096 D=@(FRED,XYZ).SOMEWHERE
t
make a call through the London Gateway to SOMEWHERE on PSS.
________________________________________
Overcoming Call User Data Field Problems
With X29 PADs the onward Called Address can be supplied interactively at the
Gateway without having to set up a Call User Data field. To do this the
Gateway must be called with the correct X25 sub-address. This involves
adding an extra 2 digits onto the normal 12 digit address of the Gateway.
The sub-address for JANET is 69 and 96 for PSS. The Gateway will then
prompt for the onward Called Address.
The procedure is as follows: Call the Gateway using the correct
sub-address:
23422351919169 to call JANET from PSS via the RAL Gateway
00000000004096 (or the mnemonic RL.PSS) to call PSS from JANET
via the RAL Gateway.
23421920010069 to call JANET from PSS via the London Gateway
00004000004096 (or the mnemonic LON.PSS) to call PSS from
JANET via the London Gateway.
How to Use the U.K. Academic Network - Packet SwitchStream (PSS) Gateway
The response from the Gateway will be the following message:
Please enter your authorisation and address required in form:
(user,password).address
>
Reply with the appropriate response.
_______
Example
(FRED,XYZ).SOMEWHERE
As the X29 protocol is being used there is no need to include the service
name X29.
Authentication is not required for incoming calls to JANET. In this case
the string (FRED,XYZ) can be omitted, note however that the address should
still be preceded with a point.
_______
Example
.RLGB
There is a timeout of between 3 and 4 minutes for this response after which
the call will be cleared, however there is no limit to the number of
attempts which can made within this time limit. If the authorisation or
adress entered is invalid the Gateway will request it again. To abandon the
attempt clear the call from the PAD. For further details of how to do this
see Network User Note 11.
You will find that on some PADs a 'call connected' message will appear on
the terminal as soon as the call has been connected to the Gateway. This
does not mean that you have made contact with your ultimate destination.
When you have contacted the remote host the Gateway will show a 'Call
connected to remote address' message.
_______________________________________________
7. Facilities Provided by the Gateway Machine
__________________
7.1 HELP Facility
A HELP Facility is available which contains the whole of this guide in its
most uptodate form. The utility which is used to view the guide allows the
text to be searched for strings as well as allowing random movement about
the document.
There is also additional up-to-the-minute information and details of
forthcoming changes. Use the HELP system from time to time to find out
about changes which may affect your access to the machine.
How to Use the U.K. Academic Network - Packet SwitchStream (PSS) Gateway
To connect to the HELP system, simply make a terminal call to the Gateway as
described in section 5 above. When the Logging in / User prompt appears
type HELP. The following message will then be displayed.
OS4000+Rlix V30 PSS Gateway
Logging in
user HELP
ID last used Wednesday, 10 December 1986 06:11
Started - Wed 10 Dec 1986 11:15:55
Please enter your name and establishment.
Enter your name and establishment. You will be then be presented with the
following message.
The following options are available:
NOTES GUIDE TITILES ERRORS TARRIF HELP QUIT
Which option do you require?
The following list describes each command briefly.
NOTES replies to user queries and any other useful information.
GUIDE the complete Gateway user guide.
TITLES list of JANET and PSS addresses and mnemonics
ERRORS list of error codes that you may receive.
TARRIF list of the PSS and IPSS charges.
HELP is the HELP option.
QUIT exits from the session.
When you exit from the HELP facility by typing QUIT, the following message
will appear.
If you have any comments, please type them now, terminate with E
on a line on its own. Otherwise just type <cr>
CPU used: 1 ieu, Elapsed: 2 mins, IO: 1583 units, Breaks: 14
Budgets: this period = 10.00 AUs, used = 0.010 AUs, left = 9.51 AUs
User HELP terminal 2 logged out Wed 10 Dec 1986 09:20:12
The above prompt gives the user an opportunity to type in any queries or
comments that he has about the Gateway. These comments are viewed daily by
the support staff at RAL.
________________________________________________
7.2 Account Facility and Changing Your Password
An account can be inspected and the password changed by using this facility.
First make a call to the Gateway as described in section 5. When the
Logging in /User prompt appears type ACNT.
After a short delay, there will be a prompt for a Userid. Enter your PSS
userid, you will then be prompted for your password. Enter your password
(this is not echoed), three attempts are allowed to enter the correct
password. The message 'Enter command' will now appear.
How to Use the U.K. Academic Network - Packet SwitchStream (PSS) Gateway
_______
Example
OS4000+Rlix V30 PSS Gateway
Logging in
user ACNT
ID last used Wednesday, 10 December 1986 09:14
Enter userid FRED
Password
Enter command
The following commands are available:
ACCOUNT Prints the state of your account on the terminal
PASSWORD Allows the password to be changed. The new password
should be typed in twice on the following two
lines when prompted. It is not echoed
END Terminates the session.
Note that each command may be abbreviated to a minimum of 2 characters.
_____________________________________________
8. Facilities Available Through the Gateway
___________________________
8.1 Demonstration Facility
There is an account available which has a small allocation available for
users to try out the Gateway. The password will be supplied on request from
the Network Executive. Note that excessive use of this account will soon
exhaust its allocation and deprive others of its use.
___________________________________________________
8.2 Address Mnemonics of Remote Hosts on Networks
________________________
Connected to the Gateway
Many network addresses consist of 12 or even 14 digits which may be
rm 33; Next>
difficult to remember and awkward to enter. To make life easier the Gateway
has a table which consists of a number of mnemonics and their respective
network addresses. When these mnemonics are typed within a call through the
Gateway the mnemonic is translated into the appropriate network address.
Therefore if you have a frequently used network address which is not in the
table, please contact the Network Executive with a request to insert the
address along with an appropriate mnemonic. Equally if you know of
mnemonics which are no longer useable contact the Network Executive.
It is hoped that the Gateway will support the Network Registration Scheme
(NRS) in the near future.
JANET User Notes 5 and 6 include mnemonics for a number of remote machines
and networks on both PSS and JANET.
How to Use the U.K. Academic Network - Packet SwitchStream (PSS) Gateway
_______________________________
9. Facilities Available on PSS
________________
9.1 Fast Select
This allows calls to have up to 128 bytes in the Call User Data field. You
can use this to expand address information available for the next hop of the
call. As a PSS user we have subscribed to this facility; however you
should note that some remote Hosts on PSS and IPSS cannot accept Fast Select
calls. If a Fast Select call is made to an address which does not subscribe
to the Fast Select facility the call will fail with clearing code Hex'29'.
When a mnemonic is used, the Gateway will know whether the address can
support Fast Select or not, and will make the correct call automatically.
If the full numeric address is used, then the Gateway has to be told not to
use Fast Select. This can be done by preceding the address with the string
'NFS-'. In fact the NFS is a mnemonic which translates to a null string
with the No Fast Select attribute and the minus is just a delimiter which
will be ignored.
For example, calling TELENET
PSS(FRED,XYZ).NFS-311012345678
____________________________
9.2 Reverse Charge Facility
If this facility is used the remote Host will accept all the call charges,
therefore your allocation on the Janet Gateway will not be debited. Note
that there are not many remote Hosts which will accept 'reverse charging'.
Unfortunately the only way to find out if a remote Host will accept reverse
charging is to experiment. Do this by appending 'R' to the authorisation
field, for example
(FRED,XYZ,R)
If this does not work, it could be because the remote host will only accept
calls from 'known' network addresses and the JANET addresses are 'unknown'
___________________
9.3 Access to IPSS
It is possible to access IPSS, the International Packet Switch Stream,
through PSS. This is done by entering the IPSS address in place of the PSS
address. IPSS calls are accounted separately from PSS so you will have to
make a specific request for an IPSS allocation before you make calls on
IPSS.
___________________________________________________
9.4 Calls to Other, Non-Transport Service Networks
Some networks (for example, TYMNET) require a Call User Data Field with a
different format from the one normally generated by the Gateway. A facility
has been provided to enable an arbitrary string to be included in the Call
User Data Field. This is done by terminating the numeric address (or
mnemonic) with the delimiter '*D' followed by the required string.
Everything following the '*D' is then copied into the Call User Data Field.
How to Use the U.K. Academic Network - Packet SwitchStream (PSS) Gateway
_______
Example
PSS(FRED,XYZ).NFS-31060000*DZRRT;IPSSLON
This would call a (fictitious) address on TYMMNET.
Finally some machines do not expect to receive any user data at all, so you
will need to enter '*D' on its own for these.
_______
Example
PSS(FRED,XYZ).YONDER*D
___________________________
9.5 Adjusting Packet Sizes
The Gateway normally tries to establish its calls with a packet size of 256
bytes, even if the incoming call had only 128 byte packets. This normally
does not cause problems, but there may be difficulties with some systems.
If you find your call being cleared even though all the addressing is
correct, or if it fails as soon as data starts to flow, try calling with the
additional data, '*P7W2', to force a packet size of 128 bytes.
_______
Example
PSS(FRED,XYZ).OVERTHERE*P7W2
If you also need to use the *D parameter that must follow the *P/W paramter.
_______
Example
PSS(FRED,XYZ).HERE*P7W2*DTOYOU
___________________________________________________
10. Protocols Available if Supported by Both Local
________________________
and Remote Host Machines
Other sorts of calls, besides terminal calls, may be possible through the
Gateway. In these cases Transport Service is required. The mechanisms
required for insertion of authorisation information vary from computer to
computer, and therefore your local support staff should be consulted for
information in this area.
Care needs to be exercised here, especially when replying to MAIL from PSS
without considering how the authorisation will be managed. Problems can
also occur with FTP, which will continue to retry a call until it receives a
fatal error, causing unnecessary network traffic.
_____________________________________________________
10.1 Network Independent File Transfer Protocol (FTP)
This allows files from one computer's file store to be sent to the file
store of another computer. Although the two computers may have very
different ways of working internally, FTP will overcome these difficulties
and arrange for the transfer of the file without the user being aware of the
special procedures that are being carried out.
How to Use the U.K. Academic Network - Packet SwitchStream (PSS) Gateway
______________________
10.2 JNT MAIL Protocol
This allows MAIL messages to be sent from one user to another user. The
users may be using the same machine or may be using machines on different
networks. In both cases the user types his message into the machine being
used and the MAIL program then adds a header to the message, so that it can
be transmitted to the remote Host by FTP. The received message is stored on
the remote Host and made available to the addressee.
__________________________________________________
10.3 Job Transfer and Manipulation Protocol (JTMP)
This protocol lets you:
transfer files for storage or execution
make status enquiries and get reports on these files.
modify the progress of the above.
This protocol requires standard FTP to carry out the transfers.
____________________________
11. Restrictions and Errors
_________________
11.1 Restrictions
Due to the present lack of a full Transport Service in the gateway, the
ADDRESS, DISCONNECT and RESET primitives are not fully supported. However
this should not present serious problems, since the ADDRESS and RESET
primitives are not widely used, and the DISCONNECT primitive can be carried
in a Clear Request packet.
The gateway does however support continuation of Transport Service Connect
messages into the first data packet. This is particularly useful when
attempting file transfers for which the 12-byte CUDF limitation pertains
(i.e. NSF- calls).
___________
11.2 Errors
When a call fails, there is an error code associated with the failure which
will normally be displayed on your PAD. A list of the most common codes and
their meanings is given in Network User Note 15.
PSS Address List
____________
Introduction
This is an address list of all the mnemonics that can be accessed via the
JANET Packet SwitchStream Gateway.
The list is sorted in numerical order using the machine address. The first
three digits of the address are a code which indicates the country where the
machine is situated. Headings appear throughout the list giving the country
name followed by the machines available there.
The list is divided into 3 columns which show:
a. The numeric address (DTE address)
b. A mnemonic for the address
c. A description of where the machine is located.
____________
Address List
_______ ________ ___________
ADDRESS MNEMONIC DESCRIPTION
Netherlands
204 NL Netherlands
20412900433 SARA National Institute for High Enery
Physics (NIKHEF) SARA network
20412900434 NIKHEF National Institute for High Enery
Physics (NIKHEF) SARA network
204129004353 NIKHEFH NIKHEF Gould
20418800110680 CELEX CELEX Lexical Database, Nijmegen
Belgium
206 B Belgium
2062210168 BBVA Brussels DEC A (Belgium) - 9600 bps
2062221006 BBDA Brussels DEC A (Belgium) - 2400 bps
France
208 F France
2080 TRANSPAC French Transpac
208031001511 ARGOS Argos service at Toulouse
208034020258 CNUSC CNUSC Montpelier
20803802067602 ILLDA ILL DEC-10 at Grenoble
20806911011912 FRCPN11 HEP Computing Centre, Paris
208075000394 IRST ESA - Quest
208075001282 FRCPN11X HEP Computing Centre, Paris
208075040390*DV6 MINITEL French Prestel
208075040390*DV2 MINITEL1 French Prestel
20807802016901 INRIA Institute National de Recherche
en Infoatique ...
208091000309*DCISIFMST CISI IBM - TSO
208091000309*DCISIFMST CISI1 IBM - TSO
208091000519*DCISIFMST CISI2 IBM - TSO
208091000270*DCISIFMST CISI3 IBM - TSO
208091010320 CJRCE
20809104057310 SIMBAD Stellar data centre CDC system
2080911101 SACLAY Saclay - France
Spain
214 E Spain
2141 SPAIN Spanish data network
2145222020109 LAPALMA La Palma Observatory, Canaries
Yugoslavia
220 Y Yugoslavia
2201 YUPAK Yugoslav YUPAK
220161120100 RRC RRC Computer Centre, Ljubljana
220161140001 LJUBLJANA University of Ljubljana, DEC 10 & 20
220161140015 STEFAN Institute of Jozef Stefan, Ljubljana
220162120031 MARIBOR University of Maribor - VAX 8800
Italy
222 I Italy
2222260164608 ISPRA Euratom Joint Research Centre
2222650143 ESA2 ESA - IRS
Switzerland
228 CH Switzerland
228464110115 DATASTAR2 Data-Star, Switzerland
22846431007014 DATASTAR Data-Star, no-echo on password
22848411011014 DATASTAR1 Data-Star, no-echo on password
2284681140510*DLO CERNLO CERN 300 bps
2284681140510*DME CERNME CERN 1200 bps
Austria
232 A Austria
UK
234 GB United Kingdom
2341 IPSS IPSS UK network
23421230012000 DIALOG6 DIALOG2 in US
23421230012011*D DIALOG2 DIALOG2 in US
23421230012011*D DIALOG DIALOG2 in US
23421230012013*D DIALMAIL DIALMAIL in US
234212300120*D@ DIALNET IGS Leased line to DIALOG in US
234212300187 TELEMAIL Telemail
23421230021001 CAMPUS2000 Campus 2000
23421230021001 TTNS Times Network System 01
2342123012026 DATASTREAM Datastream Service
234212300331 LASER LASER
234213300124 PROFILE Was Datasolve
234215700117 CONTEXT Context Legal Systems
234215700147 ORBIT Orbit.
234216401146 GOULDUK Gould Uk in Surrey
234216700127 PCR Pfizer Central Research
234219200101 FINSBURY
234219200146*D CEGB CEGB, Park Street, London
23421920014870 EAN EAN Gateway at ULCC
234219200171 LEXIS LEXIS/NEXIS
234219200190 INFOLINE Pergamon - Infoline
234219200203 IPSH IP-SHARP
234219200300 UCL University College London -
Computer Science
234219200394*D AREMOS Sianet
234219201002 POOLE PCL - Poole C.A.E. Service
23421920100404 BTGOLD04 BTGOLD service.
23421920100474 BTGOLD74 BTGOLD service.
23421920100476 BTGOLD76 BTGOLD service.
23421920100479 BTGOLD79 BTGOLD service.
23421920100479 LANET BTGOLD 79 service.
23421920100481 BTGOLD81 BTGOLD service.
23421920100482 BTGOLD82 BTGOLD service.
23421920100483 BTGOLD83 BTGOLD service.
23421920100484 BTGOLD84 BTGOLD service.
23421920100487 BTGOLD87 BTGOLD service.
234219201004 BTGOLD BTGOLD service.
23421920100513 EUROINFO Euronet Diane Information Service
23421920100515 HOSTESS Hostess system (BT)
23421920102517 PRESTEL Prestel
234219201156 ERS ESA - Quest
234219201156 ESA ESA - Quest
23421960116750 HRC GEC - Hirst Research (Mail)
234219709111 NPL1 NPL - use subaddress 04
234219709210 NPL2 National Physical Laboratory
2342212001450 OCLC
234222339399 CAMB University of Cambridge
234222715151 KENT University of Kent
234223519191 JANET Gateway to JANET at Rutherford
234227900102 BLAISE British Library Information System
234231354354 ERCC Edinburgh Regional Computer Centre
234233400101 BEST B.E.S.T. Database, Longman
Cartermill, St. Andrews
234212900115 STL STL
234243800105 IDEC STL IDEC
23426164336548*P7*W2 ICLB ICL network at Manchester
23424830012489 SUNCAM SUN Microsystems - Camberley
234248300124 SUN SUN Microsystems - Camberley - mail
23425272424111 INFOSEARCH ISTEL Communications Network
23425330012406 CAMTEC Camtec, Leicester (hard copy printer)
234253300124 CAMTEC Camtec, Leicester
23426160013930 NCC National Computing Centre - LEO
234261600152 UMDAFL University of Manchester Dataflow VAX
23426164321090 NRS NRS
234261643210 SALF Salford University
234261643343 FERRANTI Ferranti Computer Systems
23423440016782 PRIME Prime - Leeds
234263259159 NUMAC University of Newcastle
234274200103*DCODUS CODUS Codus
234284400108 CULHAM Culham Laboratory
234284400162 PFDS Pergamon Financial Data Systems
23428580010801*D LIBTELVT Menzies LIBTEL for VT100 terminals.
23428580010802*D LIBTELTV Menzies LIBTEL for TV910, etc
23428580010803*D LIBTELADM Menzies LIBTEL for ADM3 terminals.
23429084011100*d POLIS SCION
234293765265 ARTTEL British Library, Boston Spa
2348 TELEX UK Telex network
23523592592500 KINGLINE Hull Telephone GOLD system
Denmark
238 DK Denmark
238241745600 RECKU Univac in Copenhagen University
Sweden
240 S Sweden
2405 SWEDEN Swedish data network
240200100110 QZDB QZ via reverse pad.
240200101915 QZCOM80 QZCOM NIFTP80 service.
240200101928 QZXA UPNOD local network
2402001027 QZXB Stockholm University Computing
Centre Gateway.
240200102701 QZCOM QZ ODEN DEC-10
Norway
242 N Norway
2422 NORWAY Norwegian data network
242211000107 OSLO DEC10 at Oslo University
242223000151 RBK Cyber 170 at IFE (Energy Research
Centre), Kjeller
242245000101 BERGEN Univac at Bergen University
242253000101 RUNIT Univac at Trondheim University
242265000101 TROMSOE Cyber at Troms University
Finland
244 SF Finland
244203008 HELVA High Energy Physics Vax,
University of Helsinki
Russia
2502040300 NCADE NCADE USSR electronic mail, Moscow
Germany
262 D Germany
2624 GERMANY German data network
26245221040006*d DIMDI
26245221040104*d DIMDI2
26245228040187 BNVA Bonn VAX
26245234040194 RUB Cyber 205, Ruhr University - Bochum
262453000217 HMI Hans Mietner Institute in Berlin
26245300043042 DFNHELP Help system at DFN in Berlin
2624540009306 DYVA MARK J VAX at DESY
26245615144000 ESOC European Space Operations Centre,
Darmstadt
2624562213002 EMBL ALKOR VAX
26245724790114 CASGER2 STN International - 48K link
26245724720001 CASGER STN International - 64K link
262457610420*D FREIBURG Freiburg University
26245772340095 FURTWANGEN Furtwangen, W. Germany
26245890040220 IPP Max Planck Institute of
Plasma Physics, Garching
26245890090218 MPE Max Planck Institute for Extra
Terrestial Physics
2624589009301 ESO European Southern Observatory
in Germany VAX 11/780
Portugal
268 P Portugal
Luxembourg
270 L Luxembourg
270429200*D ODPECC Office for Official Publications,
European Communities Commision.
270448112*D ECHO IES - DC
Ireland
272 IRL Ireland
272431001992 EUROKOM EEC harmonisation COM system at
UC, Dublin - inverse PAD
27243159000630 UCD EEC harmonisation COM system at
UC, Dublin - local X25 net
Canada
302 CDN Canada
3020 DATAPAC Canadian Datapac
302067200040 UBCVCR Amdahl, Univ British Columbia,
Vancouver
302068100058 UVIC Victoria University, British Columbia
302068100256 UVICVVA Physics VAX, Victoria University,
British Columbia
302083200013 TRIUMF The Tri-University Meson Facility,
Vancouver
3025 GLOBEDAT Canadian Globedat
3029 INFOSWITCH Canadian Infoswitch
3103 ITT USA - ITT
31033010000542 DIALCOM42 DIALCOM - System 42
3104 WUI USA - WUI
3104004759 MCI MCII mail system
USA - TYMNET
3106 TYMNET USA - Tymnet
3106*DENSCL ONTYME ONTYME information system
3106*DINFORMATION TYMNETINFO TYMNET information system
3106001475 SDC2
3106001509 SDC1
310690157800*D BIX Byte Information Exchange
310600232901*D MFE Magnetic Fusion Energy Centre,
Lawrence Livermore
310600455141 UNINET U.N. database.
310600562200 FNAL Fermilab
31060061*DSDDC;IPSSLON ORBIT2 SDC Search Service
3106009211 ORBIT1 SDC Search Service
3106900803*D DIALOG3 Lockheed DIALOG service
3106900061*D DIALOG4 Lockheed DIALOG service
31069 SLAC SLAC via TYMNET
USA - TELENET
3110 TELENET USA - Telenet
31102020010900 CIS Chemical Information Systems
311021200141 JPLM1 Jet Propulsion Laboratory mail 1, USA
311021200142 JPLM2 Jet Propulsion Laboratory mail 2, USA
31102130003300*D ORBIT SDC Search Service
31102130017000*D DIALOG2 Lockheed DIALOG service
311021300219 CALTECH Caltech VAX 11/780
31103010002000 NLM National Medical Library
31103010025442 DIALCOM42 DIALCOM - system 42
311030100341 UNINET1 U.N. database.
31103010047 SOURCE Source system in USA
311030200612 OCEANIC Database on oceans of the world.
31103150002002*d BRS Biblographic Research Services, NY
31103210010400 NASAMAIL NASA telemail system.
31103210016000 SPANSSL Space Science Lab, NASA Marshal Space
Flight Control and SPAN
311032107035 NSSDCA National Space Science Data Centre,
node NSSDCA on the SPAN Network.
31104150004800*D DIALOG1 Lockheed DIALOG service
31106070002000 CORNELL0 Cornell University
31106070002100 CORNELL1 Cornell University
31106070002200 CORNELL2 Cornell University
31106070002200 CORNELL Cornell University
31106070002300 CORNELL3 Cornell University
31106140002124 CASUSA STN International
311070300463 NOAANETB NOAAnet system B, Washington DC.
31108080004010 UKTH UK Telescope in Hawaii
31108080004010 JACH UK Telescope in Hawaii
31108080004020 UKIRT UK Infra Red Telescope in Hawaii
31108080004030 JCMT James Clerk Maxwell Telescope
in Hawaii
311090900003 TELEMAIL1 Telemail on Telenet
311090900406 TELEMAIL2 Telemail on Telenet
311090900761 TELEMAIL3 Telemail on Telenet
31109090080000 JPLM3 Jet Propulsion Laboratory mail 2, USA
USA - RCA
3113 RCA USA - RCA
USA
312530300007 NCAR National Centre for Atmospheric
Research, Boulder
312541500007 DIALOGUNI
3126 AUTONET USA - Autonet
31343155859900 CORNELLF Cornell F m/c on ACCUNET
340 FA French Antilles
342 BDS Barbados
425 IL Israel
426 BRN Bahrain
431 DXB United Arab Emirates - Dubai
Japan
440 J Japan
4408 VENUSP Japanese data network
440820015 JOIST Japan Online Information System
454 HK Hong Kong
Australia
505 AUS Australia
505202230003.SPCP UTAS UTAS
505233430001 DITMELB CSIRO
50523343000301 MELBOURNE University of Melbourne - VAX X
505272223015 QUT Queensland University of Technology
505273720000 UQXA University of Queensland
ANF-10 gateway
5052737200001 UQKL10 University of Queensland
50527372000090 WOMBAT University of Queensland
50527372000094 UQVAX University of Queensland
505282720012 FLINDERS EDU.FLINDERS
50528622004 SAIT EDU.SAIT
505294320006 MURDOCH Murdoch University
505320000000 MINERVA MINERVA Mail service
525 SGP Singapore
New Zealand
530 NZ New Zealand
530130000034 CANTERBURY Canterbury University
530130000047 LINCOLN Lincoln University
530147000049 VUWCOMP VUW.COMP
530163000005 MASSEY Massey University Computer Centre
530171000004 WAIKATO Waikato University
530197000073 AUCKLAND Auckland University
South Africa
655 ZA South Africa
6550 SAPONET_P Saponet
655010601702 SACSIR CSIR, Pretoria
6559 SAPONET Saponet_P
=============================================================================
/ /
/ FILE 04 / NIA071 /
/ DOD-TCSEC Manual Part 02 of 02 /
/ Judge Dredd /
/ /
CSC-STD-001-83
Library No. S225,711
DEPARTMENT OF DEFENSE
TRUSTED COMPUTER SYSTEM EVALUATION CRITERIA
15 August 1983
CSC-STD-001-83
7.0 THE RELATIONSHIP BETWEEN POLICY AND THE CRITERIA
Section 1 presents fundamental computer security requirements and Section 5
presents the control objectives for Trusted Computer Systems. They are
general requirements, useful and necessary, for the development of all secure
systems. However, when designing systems that will be used to process
classified or other sensitive information, functional requirements for meeting
the Control Objectives become more specific. There is a large body of policy
laid down in the form of Regulations, Directives, Presidential Executive
Orders, and OMB Circulars that form the basis of the procedures for the
handling and processing of Federal information in general and classified
information specifically. This section presents pertinent excerpts from these
policy statements and discusses their relationship to the Control Objectives.
7.1 Established Federal Policies
A significant number of computer security policies and associated requirements
have been promulgated by Federal government elements. The interested reader
is referred to reference [32] which analyzes the need for trusted systems in
the civilian agencies of the Federal government, as well as in state and local
governments and in the private sector. This reference also details a number
of relevant Federal statutes, policies and requirements not treated further
below.
Security guidance for Federal automated information systems is provided by the
Office of Management and Budget. Two specifically applicable Circulars have
been issued. OMB Circular No. A-71, Transmittal Memorandum No. 1, "Security
of Federal Automated Information Systems,"[26] directs each executive agency
to establish and maintain a computer security program. It makes the head of
each executive branch, department and agency responsible "for assuring an
adequate level of security for all agency data whether processed in-house or
commercially. This includes responsibility for the establishment of physical,
administrative and technical safeguards required to adequately protect
personal, proprietary or other sensitive data not subject to national security
regulations, as well as national security data."[26, para. 4 p. 2]
OMB Circular No. A-123, "Internal Control Systems,"[27] issued to help
eliminate fraud, waste, and abuse in government programs requires: (a) agency
heads to issue internal control directives and assign responsibility, (b)
managers to review programs for vulnerability, and (c) managers to perform
periodic reviews to evaluate strengths and update controls. Soon after
promulgation of OMB Circular A-123, the relationship of its internal control
requirements to building secure computer systems was recognized.[4] While not
stipulating computer controls specifically, the definition of Internal
Controls in A-123 makes it clear that computer systems are to be included:
"Internal Controls - The plan of organization and all of the methods and
measures adopted within an agency to safeguard its resources, assure the
accuracy and reliability of its information, assure adherence to
applicable laws, regulations and policies, and promote operational
economy and efficiency."[27, sec. 4.C]
The matter of classified national security information processed by ADP
systems was one of the first areas given serious and extensive concern in
computer security. The computer security policy documents promulgated as a
result contain generally more specific and structured requirements than most,
keyed in turn to an authoritative basis that itself provides a rather clearly
articulated and structured information security policy. This basis, Executive
Order 12356, "National Security Information," sets forth requirements for the
classification, declassification and safeguarding of "national security
information" per se.[14]
7.2 DoD Policies
Within the Department of Defense, these broad requirements are implemented and
further specified primarily through two vehicles: 1) DoD Regulation 5200.1-R
[7], which applies to all components of the DoD as such, and 2) DoD 5220.22-M,
"Industrial Security Manual for Safeguarding Classified Information" [11],
which applies to contractors included within the Defense Industrial Security
Program. Note that the latter transcends DoD as such, since it applies not
only to any contractors handling classified information for any DoD component,
but also to the contractors of eighteen other Federal organizations for whom
the Secretary of Defense is authorized to act in rendering industrial security
services.*
____________________________________________________________
* i.e., NASA, Commerce Department, GSA, State Department,
Small Business Administration, National Science Foundation,
Treasury Department, Transportation Department, Interior
Department, Agriculture Department, Health and Human
Services Department, Labor Department, Environmental
Protection Agency, Justice Department, U.S. Arms Control and
Disarmament Agency, Federal Emergency Management Agency,
Federal Reserve System, and U.S. General Accounting Office.
____________________________________________________________
For ADP systems, these information security requirements are further amplified
and specified in: 1) DoD Directive 5200.28 [8] and DoD Manual 5200.28-M [9],
for DoD components; and 2) Section XIII of DoD 5220.22-M [11] for contractors.
DoD Directive 5200.28, "Security Requirements for Automatic Data Processing
(ADP) Systems," stipulates: "Classified material contained in an ADP system
shall be safeguarded by the continuous employment of protective features in
the system's hardware and software design and configuration . . . ."[8,
sec. IV] Furthermore, it is required that ADP systems that "process, store,
or use classified data and produce classified information will, with
reasonable dependability, prevent:
a. Deliberate or inadvertent access to classified material by
unauthorized persons, and
b. Unauthorized manipulation of the computer and its associated
peripheral devices."[8, sec. I B.3]
Requirements equivalent to these appear within DoD 5200.28-M [9] and in DoD
5220.22-M [11].
>From requirements imposed by these regulations, directives and circulars, the
three components of the Security Policy Control Objective, i.e., Mandatory and
Discretionary Security and Marking, as well as the Accountability and
Assurance Control Objectives, can be functionally defined for DoD
applications. The following discussion provides further specificity in Policy
for these Control Objectives.
7.3 Criteria Control Objective for Security Policy
7.3.1 Marking
The control objective for marking is: "Systems that are designed
to enforce a mandatory security policy must store and preserve the
integrity of classification or other sensitivity labels for all
information. Labels exported from the system must be accurate
representations of the corresonding internal sensitivity labels
being exported."
DoD 5220.22-M, "Industrial Security Manual for Safeguarding
Classified Information," explains in paragraph 11 the reasons for
marking information:
"Designation by physical marking, notation or other means
serves to inform and to warn the holder about the
classification designation of the information which requires
protection in the interest of national security. The degree
of protection against unauthorized disclosure which will be
required for a particular level of classification is directly
commensurate with the marking designation which is assigned
to the material."[11]
Marking requirements are given in a number of policy statements.
Executive Order 12356 (Sections 1.5.a and 1.5.a.1) requires that
classification markings "shall be shown on the face of all
classified documents, or clearly associated with other forms of
classified information in a manner appropriate to the medium
involved."[14]
DoD Regulation 5200.1-R (Section 1-500) requires that: ". . .
information or material that requires protection against
unauthorized disclosure in the interest of national security shall
be classified in one of three designations, namely: 'Top Secret,'
'Secret' or 'Confidential.'"[7] (By extension, for use in computer
processing, the unofficial designation "Unclassified" is used to
indicate information that does not fall under one of the other
three designations of classified information.)
DoD Regulation 5200.1-R (Section 4-304b) requires that: "ADP
systems and word processing systems employing such media shall
provide for internal classification marking to assure that
classified information contained therein that is reproduced or
generated, will bear applicable classification and associated
markings." (This regulation provides for the exemption of certain
existing systems where "internal classification and applicable
associated markings cannot be implemented without extensive system
modifications."[7] However, it is clear that future DoD ADP
systems must be able to provide applicable and accurate labels for
classified and other sensitive information.)
DoD Manual 5200.28-M (Section IV, 4-305d) requires the following:
"Security Labels - All classified material accessible by or within
the ADP system shall be identified as to its security
classification and access or dissemination limitations, and all
output of the ADP system shall be appropriately marked."[9]
7.3.2 Mandatory Security
The control objective for mandatory security is: "Security
policies defined for systems that are used to process classified
or other specifically categorized sensitive information must
include provisions for the enforcement of mandatory access control
rules. That is, they must include a set of rules for controlling
access based directly on a comparison of the individual's
clearance or authorization for the information and the
classification or sensitivity designation of the information being
sought, and indirectly on considerations of physical and other
environmental factors of control. The mandatory access control
rules must accurately reflect the laws, regulations, and general
policies from which they are derived."
There are a number of policy statements that are related to
mandatory security.
Executive Order 12356 (Section 4.1.a) states that "a person is
eligible for access to classified information provided that a
determination of trustworthiness has been made by agency heads or
designated officials and provided that such access is essential
to the accomplishment of lawful and authorized Government
purposes."[14]
DoD Regulation 5200.1-R (Chapter I, Section 3) defines a Special
Access Program as "any program imposing 'need-to-know' or access
controls beyond those normally provided for access to
Confidential, Secret, or Top Secret information. Such a program
includes, but is not limited to, special clearance, adjudication,
or investigative requirements, special designation of officials
authorized to determine 'need-to-know', or special lists of persons
determined to have a 'need-to- know.'"[7, para. 1-328] This
passage distinguishes between a 'discretionary' determination of
need-to-know and formal need-to-know which is implemented through
Special Access Programs. DoD Regulation 5200.1-R, paragraph 7-100
describes general requirements for trustworthiness (clearance) and
need-to-know, and states that the individual with possession,
knowledge or control of classified information has final
responsibility for determining if conditions for access have been
met. This regulation further stipulates that "no one has a right
to have access to classified information solely by virtue of rank
or position." [7, para. 7-100])
DoD Manual 5200.28-M (Section II 2-100) states that, "Personnel
who develop, test (debug), maintain, or use programs which are
classified or which will be used to access or develop classified
material shall have a personnel security clearance and an access
authorization (need-to-know), as appropriate for the highest
classified and most restrictive category of classified material
which they will access under system constraints."[9]
DoD Manual 5220.22-M (Paragraph 3.a) defines access as "the
ability and opportunity to obtain knowledge of classified
information. An individual, in fact, may have access to
classified information by being in a place where such information
is kept, if the security measures which are in force do not
prevent him from gaining knowledge of the classified
information."[11]
The above mentioned Executive Order, Manual, Directives and
Regulations clearly imply that a trusted computer system must
assure that the classification labels associated with sensitive
data cannot be arbitrarily changed, since this could permit
individuals who lack the appropriate clearance to access
classified information. Also implied is the requirement that a
trusted computer system must control the flow of information so
that data from a higher classification cannot be placed in a
storage object of lower classification unless its "downgrading"
has been authorized.
7.3.3 Discretionary Security
The term discretionary security refers to a computer system's
ability to control information on an individual basis. It stems
from the fact that even though an individual has all the formal
clearances for access to specific classified information, each
individual's access to information must be based on a demonstrated
need-to-know. Because of this, it must be made clear that this
requirement is not discretionary in a "take it or leave it" sense.
The directives and regulations are explicit in stating that the
need-to-know test must be satisfied before access can be granted
to the classified information. The control objective for
discretionary security is: "Security policies defined for systems
that are used to process classified or other sensitive information
must include provisions for the enforcement of discretionary
access control rules. That is, they must include a consistent set
of rules for controlling and limiting access based on identified
individuals who have been determined to have a need-to-know for the
information."
DoD Regulation 5200.1-R (Paragraph 7-100) In addition to excerpts
already provided that touch on need-to- know, this section of the
regulation stresses the need- to-know principle when it states "no
person may have access to classified information unless . . .
access is necessary for the performance of official duties."[7]
Also, DoD Manual 5220.22-M (Section III 20.a) states that "an
individual shall be permitted to have access to classified
information only . . . when the contractor determines that access
is necessary in the performance of tasks or services essential to
the fulfillment of a contract or program, i.e., the individual has
a need-to-know."[11]
7.4 Criteria Control Objective for Accountability
The control objective for accountability is: "Systems that are used to
process or handle classified or other sensitive information must assure
individual accountability whenever either a mandatory or discretionary
security policy is invoked. Furthermore, to assure accountability the
capability must exist for an authorized and competent agent to access and
evaluate accountability information by a secure means, within a reasonable
amount of time, and without undue difficulty."
This control objective is supported by the following citations:
DoD Directive 5200.28 (VI.A.1) states: "Each user's identity shall be
positively established, and his access to the system, and his activity in
the system (including material accessed and actions taken) controlled and
open to scrutiny."[8]
DoD Manual 5200.28-M (Section V 5-100) states: "An audit log or file
(manual, machine, or a combination of both) shall be maintained as a
history of the use of the ADP System to permit a regular security review
of system activity. (e.g., The log should record security related
transactions, including each access to a classified file and the nature
of the access, e.g., logins, production of accountable classified
outputs, and creation of new classified files. Each classified file
successfully accessed [regardless of the number of individual references]
during each 'job' or 'interactive session' should also be recorded in the
audit log. Much of the material in this log may also be required to
assure that the system preserves information entrusted to it.)"[9]
DoD Manual 5200.28-M (Section IV 4-305f) states: "Where needed to assure
control of access and individual accountability, each user or specific
group of users shall be identified to the ADP System by appropriate
administrative or hardware/software measures. Such identification
measures must be in sufficient detail to enable the ADP System to provide
the user only that material which he is authorized."[9]
DoD Manual 5200.28-M (Section I 1-102b) states:
"Component's Designated Approving Authorities, or their designees
for this purpose . . . will assure:
. . . . . . . . . . . . . . . . .
(4) Maintenance of documentation on operating systems (O/S)
and all modifications thereto, and its retention for a
sufficient period of time to enable tracing of security-
related defects to their point of origin or inclusion in the
system.
. . . . . . . . . . . . . . . . .
(6) Establishment of procedures to discover, recover,
handle, and dispose of classified material improperly
disclosed through system malfunction or personnel action.
(7) Proper disposition and correction of security
deficiencies in all approved ADP Systems, and the effective
use and disposition of system housekeeping or audit records,
records of security violations or security-related system
malfunctions, and records of tests of the security features
of an ADP System."[9]
DoD Manual 5220.22-M (Section XIII 111) states: "Audit Trails
a. The general security requirement for any ADP system audit
trail is that it provide a documented history of the use of
the system. An approved audit trail will permit review of
classified system activity and will provide a detailed
activity record to facilitate reconstruction of events to
determine the magnitude of compromise (if any) should a
security malfunction occur. To fulfill this basic
requirement, audit trail systems, manual, automated or a
combination of both must document significant events
occurring in the following areas of concern: (i) preparation
of input data and dissemination of output data (i.e.,
reportable interactivity between users and system support
personnel), (ii) activity involved within an ADP environment
(e.g., ADP support personnel modification of security and
related controls), and (iii) internal machine activity.
b. The audit trail for an ADP system approved to process
classified information must be based on the above three
areas and may be stylized to the particular system. All
systems approved for classified processing should contain
most if not all of the audit trail records listed below. The
contractor's SPP documentation must identify and describe
those applicable:
1. Personnel access;
2. Unauthorized and surreptitious entry into the
central computer facility or remote terminal areas;
3. Start/stop time of classified processing indicating
pertinent systems security initiation and termination events
(e.g., upgrading/downgrading actions pursuant to paragraph
107);
4. All functions initiated by ADP system console
operators;
5. Disconnects of remote terminals and peripheral
devices (paragraph 107c);
6. Log-on and log-off user activity;
7. Unauthorized attempts to access files or programs,
as well as all open, close, create, and file destroy
actions;
8. Program aborts and anomalies including
identification information (i.e., user/program name, time
and location of incident, etc.);
9. System hardware additions, deletions and maintenance
actions;
10. Generations and modifications affecting the
security features of the system software.
c. The ADP system security supervisor or designee shall
review the audit trail logs at least weekly to assure that
all pertinent activity is properly recorded and that
appropriate action has been taken to correct any anomaly.
The majority of ADP systems in use today can develop audit
trail systems in accord with the above; however, special
systems such as weapons, communications, communications
security, and tactical data exchange and display systems,
may not be able to comply with all aspects of the above and
may require individualized consideration by the cognizant
security office.
d. Audit trail records shall be retained for a period of one
inspection cycle."[11]
7.5 Criteria Control Objective for Assurance
The control objective for assurance is: "Systems that are used to process
or handle classified or other sensitive information must be designed to
guarantee correct and accurate interpretation of the security policy and
must not distort the intent of that policy. Assurance must be provided
that correct implementation and operation of the policy exists throughout
the system's life-cycle."
A basis for this objective can be found in the following sections of DoD
Directive 5200.28:
DoD Directive 5200.28 (IV.B.1) stipulates: "Generally, security of an ADP
system is most effective and economical if the system is designed
originally to provide it. Each Department of Defense Component
undertaking design of an ADP system which is expected to process, store,
use, or produce classified material shall: From the beginning of the
design process, consider the security policies, concepts, and measures
prescribed in this Directive."[8]
DoD Directive 5200.28 (IV.C.5.a) states: "Provision may be made to permit
adjustment of ADP system area controls to the level of protection
required for the classification category and type(s) of material actually
being handled by the system, provided change procedures are developed and
implemented which will prevent both the unauthorized access to classified
material handled by the system and the unauthorized manipulation of the
system and its components. Particular attention shall be given to the
continuous protection of automated system security measures, techniques
and procedures when the personnel security clearance level of users
having access to the system changes."[8]
DoD Directive 5200.28 (VI.A.2) states: "Environmental Control. The ADP
System shall be externally protected to minimize the likelihood of
unauthorized access to system entry points, access to classified
information in the system, or damage to the system."[8]
DoD Manual 5200.28-M (Section I 1-102b) states:
"Component's Designated Approving Authorities, or their designees
for this purpose . . . will assure:
. . . . . . . . . . . . . . . . .
(5) Supervision, monitoring, and testing, as appropriate, of
changes in an approved ADP System which could affect the
security features of the system, so that a secure system is
maintained.
. . . . . . . . . . . . . . . . .
(7) Proper disposition and correction of security
deficiencies in all approved ADP Systems, and the effective
use and disposition of system housekeeping or audit records,
records of security violations or security-related system
malfunctions, and records of tests of the security features
of an ADP System.
(8) Conduct of competent system ST&E, timely review of
system ST&E reports, and correction of deficiencies needed
to support conditional or final approval or disapproval of
an ADP System for the processing of classified information.
(9) Establishment, where appropriate, of a central ST&E
coordination point for the maintenance of records of
selected techniques, procedures, standards, and tests used
in the testing and evaluation of security features of ADP
Systems which may be suitable for validation and use by
other Department of Defense Components."[9]
DoD Manual 5220.22-M (Section XIII 103a) requires: "the initial approval,
in writing, of the cognizant security office prior to processing any
classified information in an ADP system. This section requires
reapproval by the cognizant security office for major system
modifications made subsequent to initial approval. Reapprovals will be
required because of (i) major changes in personnel access requirements,
(ii) relocation or structural modification of the central computer
facility, (iii) additions, deletions or changes to main frame, storage or
input/output devices, (iv) system software changes impacting security
protection features, (v) any change in clearance, declassification, audit
trail or hardware/software maintenance procedures, and (vi) other system
changes as determined by the cognizant security office."[11]
A major component of assurance, life-cycle assurance, is concerned with
testing ADP systems both in the development phase as well as during
operation. DoD Directive 5215.1 (Section F.2.C.(2)) requires
"evaluations of selected industry and government-developed trusted
computer systems against these criteria."[10]
8.0 A GUIDELINE ON COVERT CHANNELS
A covert channel is any communication channel that can be exploited by a
process to transfer information in a manner that violates the system's
security policy. There are two types of covert channels: storage channels and
timing channels. Covert storage channels include all vehicles that would
allow the direct or indirect writing of a storage location by one process and
the direct or indirect reading of it by another. Covert timing channels
include all vehicles that would allow one process to signal information to
another process by modulating its own use of system resources in such a way
that the change in response time observed by the second process would provide
information.
>From a security perspective, covert channels with low bandwidths represent a
lower threat than those with high bandwidths. However, for many types of
covert channels, techniques used to reduce the bandwidth below a certain rate
(which depends on the specific channel mechanism and the system architecture)
also have the effect of degrading the performance provided to legitimate
system users. Hence, a trade-off between system performance and covert
channel bandwidth must be made. Because of the threat of compromise that
would be present in any multilevel computer system containing classified or
sensitive information, such systems should not contain covert channels with
high bandwidths. This guideline is intended to provide system developers with
an idea of just how high a "high" covert channel bandwidth is.
A covert channel bandwidth that exceeds a rate of one hundred (100) bits per
second is considered "high" because 100 bits per second is the approximate
rate at which many computer terminals are run. It does not seem appropriate
to call a computer system "secure" if information can be compromised at a rate
equal to the normal output rate of some commonly used device.
In any multilevel computer system there are a number of relatively
low-bandwidth covert channels whose existence is deeply ingrained in the
system design. Faced with the large potential cost of reducing the bandwidths
of such covert channels, it is felt that those with maximum bandwidths of less
than one (1) bit per second are acceptable in most application environments.
Though maintaining acceptable performance in some systems may make it
impractical to eliminate all covert channels with bandwidths of 1 or more bits
per second, it is possible to audit their use without adversely affecting
system performance. This audit capability provides the system administration
with a means of detecting -- and procedurally correcting -- significant
compromise. Therefore, a Trusted Computing Base should provide, wherever
possible, the capability to audit the use of covert channel mechanisms with
bandwidths that may exceed a rate of one (1) bit in ten (10) seconds.
The covert channel problem has been addressed by a number of authors. The
interested reader is referred to references [5], [6], [19], [21], [22], [23],
and [29].
9.0 A GUIDELINE ON CONFIGURING MANDATORY ACCESS CONTROL FEATURES
The Mandatory Access Control requirement includes a capability to support an
unspecified number of hierarchical classifications and an unspecified number
of non-hierarchical categories at each hierarchical level. To encourage
consistency and portability in the design and development of the National
Security Establishment trusted computer systems, it is desirable for all such
systems to be able to support a minimum number of levels and categories. The
following suggestions are provided for this purpose:
* The number of hierarchical classifications should be greater than or
equal to eight (8).
* The number of non-hierarchical categories should be greater than or
equal to twenty-nine (29).
10.0 A GUIDELINE ON SECURITY TESTING
These guidelines are provided to give an indication of the extent and
sophistication of testing undertaken by the DoD Computer Security Center
during the Formal Product Evaluation process. Organizations wishing to use
"Department of Defense Trusted Computer System Evaluation Criteria" for
performing their own evaluations may find this section useful for planning
purposes.
As in Part I, highlighting is used to indicate changes in the guidelines from
the next lower division.
10.1 Testing for Division C
10.1.1 Personnel
The security testing team shall consist of at least two
individuals with bachelor degrees in Computer Science or the
equivalent. Team members shall be able to follow test plans
prepared by the system developer and suggest additions, shall
be familiar with the "flaw hypothesis" or equivalent security
testing methodology, and shall have assembly level programming
experience. Before testing begins, the team members shall have
functional knowledge of, and shall have completed the system
developer's internals course for, the system being evaluated.
10.1.2 Testing
The team shall have "hands-on" involvement in an independent run
of the tests used by the system developer. The team shall
independently design and implement at least five system-specific
tests in an attempt to circumvent the security mechanisms of the
system. The elapsed time devoted to testing shall be at least
one month and need not exceed three months. There shall be no
fewer than twenty hands-on hours spent carrying out system
developer-defined tests and test team-defined tests.
10.2 Testing for Division B
10.2.1 Personnel
The security testing team shall consist of at least two
individuals with bachelor degrees in Computer Science or the
equivalent and at least one individual with a master's degree in
Computer Science or equivalent. Team members shall be able to
follow test plans prepared by the system developer and suggest
additions, shall be conversant with the "flaw hypothesis" or
equivalent security testing methodology, shall be fluent in the
TCB implementation language(s), and shall have assembly level
programming experience. Before testing begins, the team members
shall have functional knowledge of, and shall have completed the
system developer's internals course for, the system being
evaluated. At least one team member shall have previously
completed a security test on another system.
10.2.2 Testing
The team shall have "hands-on" involvement in an independent run
of the test package used by the system developer to test
security-relevant hardware and software. The team shall
independently design and implement at least fifteen system-
specific tests in an attempt to circumvent the security
mechanisms of the system. The elapsed time devoted to testing
shall be at least two months and need not exceed four months.
There shall be no fewer than thirty hands-on hours per team
member spent carrying out system developer-defined tests and
test team-defined tests.
10.3 Testing for Division A
10.3.1 Personnel
The security testing team shall consist of at least one
individual with a bachelor's degree in Computer Science or the
equivalent and at least two individuals with masters' degrees in
Computer Science or equivalent. Team members shall be able to
follow test plans prepared by the system developer and suggest
additions, shall be conversant with the "flaw hypothesis" or
equivalent security testing methodology, shall be fluent in the
TCB implementation language(s), and shall have assembly level
programming experience. Before testing begins, the team members
shall have functional knowledge of, and shall have completed the
system developer's internals course for, the system being
evaluated. At least one team member shall be familiar enough
with the system hardware to understand the maintenance diagnostic
programs and supporting hardware documentation. At least two
team members shall have previously completed a security test on
another system. At least one team member shall have
demonstrated system level programming competence on the system
under test to a level of complexity equivalent to adding a device
driver to the system.
10.3.2 Testing
The team shall have "hands-on" involvement in an independent run
of the test package used by the system developer to test
security-relevant hardware and software. The team shall
independently design and implement at least twenty-five system-
specific tests in an attempt to circumvent the security
mechanisms of the system. The elapsed time devoted to testing
shall be at least three months and need not exceed six months.
There shall be no fewer than fifty hands-on hours per team
member spent carrying out system developer-defined tests and
test team-defined tests.
APPENDIX A
Commercial Product Evaluation Process
"Department of Defense Trusted Computer System Evaluation Criteria" forms the
basis upon which the Computer Security Center will carry out the commercial
computer security evaluation process. This process is focused on commercially
produced and supported general-purpose operating system products that meet the
needs of government departments and agencies. The formal evaluation is aimed
at "off-the-shelf" commercially supported products and is completely divorced
>from any consideration of overall system performance, potential applications,
or particular processing environments. The evaluation provides a key input to
a computer system security approval/accreditation. However, it does not
constitute a complete computer system security evaluation. A complete study
(e.g., as in reference [18]) must consider additional factors dealing with the
system in its unique environment, such as it's proposed security mode of
operation, specific users, applications, data sensitivity, physical and
personnel security, administrative and procedural security, TEMPEST, and
communications security.
The product evaluation process carried out by the Computer Security Center has
three distinct elements:
* Preliminary Product Evaluation - An informal dialogue between a vendor
and the Center in which technical information is exchanged to create a
common understanding of the vendor's product, the criteria, and the
rating that may be expected to result from a formal product evaluation.
* Formal Product Evaluation - A formal evaluation, by the Center, of a
product that is available to the DoD, and that results in that product
and its assigned rating being placed on the Evaluated Products List.
* Evaluated Products List - A list of products that have been subjected
to formal product evaluation and their assigned ratings.
PRELIMINARY PRODUCT EVALUATION
Since it is generally very difficult to add effective security measures late
in a product's life cycle, the Center is interested in working with system
vendors in the early stages of product design. A preliminary product
evaluation allows the Center to consult with computer vendors on computer
security issues found in products that have not yet been formally announced.
A preliminary evaluation is typically initiated by computer system vendors who
are planning new computer products that feature security or major
security-related upgrades to existing products. After an initial meeting
between the vendor and the Center, appropriate non-disclosure agreements are
executed that require the Center to maintain the confidentiality of any
proprietary information disclosed to it. Technical exchange meetings follow
in which the vendor provides details about the proposed product (particularly
its internal designs and goals) and the Center provides expert feedback to the
vendor on potential computer security strengths and weaknesses of the vendor's
design choices, as well as relevant interpretation of the criteria. The
preliminary evaluation is typically terminated when the product is completed
and ready for field release by the vendor. Upon termination, the Center
prepares a wrap-up report for the vendor and for internal distribution within
the Center. Those reports containing proprietary information are not
available to the public.
During preliminary evaluation, the vendor is under no obligation to actually
complete or market the potential product. The Center is, likewise, not
committed to conduct a formal product evaluation. A preliminary evaluation
may be terminated by either the Center or the vendor when one notifies the
other, in writing, that it is no longer advantageous to continue the
evaluation.
FORMAL PRODUCT EVALUATION
The formal product evaluation provides a key input to certification of a
computer system for use in National Security Establishment applications and is
the sole basis for a product being placed on the Evaluated Products List.
A formal product evaluation begins with a request by a vendor for the Center
to evaluate a product for which the product itself and accompanying
documentation needed to meet the requirements defined by this publication are
complete. Non-disclosure agreements are executed and a formal product
evaluation team is formed by the Center. An initial meeting is then held with
the vendor to work out the schedule for the formal evaluation. Since testing
of the implemented product forms an important part of the evaluation process,
access by the evaluation team to a working version of the system is negotiated
with the vendor. Additional support required from the vendor includes
complete design documentation, source code, and access to vendor personnel who
can answer detailed questions about specific portions of the product. The
evaluation team tests the product against each requirement, making any
necessary interpretations of the criteria with respect to the product being
evaluated.
The evaluation team writes a two-part final report on their findings about the
system. The first part is publicly available (containing no proprietary
information) and contains the overall class rating assigned to the system and
the details of the evaluation team's findings when comparing the product
against the evaluation criteria. The second part of the evaluation report
contains vulnerability analyses and other detailed information supporting the
rating decision. Since this part may contain proprietary or other sensitive
information it will be distributed only within the U.S. Government on a
strict need-to-know and non- disclosure basis, and to the vendor. No portion
of the evaluation results will be withheld from the vendor.
APPENDIX B
Summary of Evaluation Criteria Divisions
The divisions of systems recognized under the trusted computer system
evaluation criteria are as follows. Each division represents a major
improvement in the overall confidence one can place in the system to protect
classified and other sensitive information.
Division (D): Minimal Protection
This division contains only one class. It is reserved for those systems that
have been evaluated but that fail to meet the requirements for a higher
evaluation class.
Division (C): Discretionary Protection
Classes in this division provide for discretionary (need-to-know) protection
and, through the inclusion of audit capabilities, for accountability of
subjects and the actions they initiate.
Division (B): Mandatory Protection
The notion of a TCB that preserves the integrity of sensitivity labels and
uses them to enforce a set of mandatory access control rules is a major
requirement in this division. Systems in this division must carry the
sensitivity labels with major data structures in the system. The system
developer also provides the security policy model on which the TCB is based
and furnishes a specification of the TCB. Evidence must be provided to
demonstrate that the reference monitor concept has been implemented.
Division (A): Verified Protection
This division is characterized by the use of formal security verification
methods to assure that the mandatory and discretionary security controls
employed in the system can effectively protect classified or other sensitive
information stored or processed by the system. Extensive documentation is
required to demonstrate that the TCB meets the security requirements in all
aspects of design, development and implementation.
APPENDIX C
Summary of Evaluation Criteria Classes
The classes of systems recognized under the trusted computer system evaluation
criteria are as follows. They are presented in the order of increasing
desirablity from a computer security point of view.
Class (D): Minimal Protection
This class is reserved for those systems that have been evaluated but that
fail to meet the requirements for a higher evaluation class.
Class (C1): Discretionary Security Protection
The Trusted Computing Base (TCB) of a class (C1) system nominally satisfies
the discretionary security requirements by providing separation of users and
data. It incorporates some form of credible controls capable of enforcing
access limitations on an individual basis, i.e., ostensibly suitable for
allowing users to be able to protect project or private information and to
keep other users from accidentally reading or destroying their data. The
class (C1) environment is expected to be one of cooperating users processing
data at the same level(s) of sensitivity.
Class (C2): Controlled Access Protection
Systems in this class enforce a more finely grained discretionary access
control than (C1) systems, making users individually accountable for their
actions through login procedures, auditing of security-relevant events, and
resource isolation.
Class (B1): Labeled Security Protection
Class (B1) systems require all the features required for class (C2). In
addition, an informal statement of the security policy model, data labeling,
and mandatory access control over named subjects and objects must be present.
The capability must exist for accurately labeling exported information. Any
flaws identified by testing must be removed.
Class (B2): Structured Protection
In class (B2) systems, the TCB is based on a clearly defined and documented
formal security policy model that requires the discretionary and mandatory
access control enforcement found in class (B1) systems be extended to all
subjects and objects in the ADP system. In addition, covert channels are
addressed. The TCB must be carefully structured into protection-critical and
non- protection-critical elements. The TCB interface is well-defined and the
TCB design and implementation enable it to be subjected to more thorough
testing and more complete review. Authentication mechanisms are strengthened,
trusted facility management is provided in the form of support for system
administrator and operator functions, and stringent configuration management
controls are imposed. The system is relatively resistant to penetration.
Class (B3): Security Domains
The class (B3) TCB must satisfy the reference monitor requirements that it
mediate all accesses of subjects to objects, be tamperproof, and be small
enough to be subjected to analysis and tests. To this end, the TCB is
structured to exclude code not essential to security policy enforcement, with
significant system engineering during TCB design and implementation directed
toward minimizing its complexity. A security administrator is supported,
audit mechanisms are expanded to signal security- relevant events, and system
recovery procedures are required. The system is highly resistant to
penetration.
Class (A1): Verified Design
Systems in class (A1) are functionally equivalent to those in class (B3) in
that no additional architectural features or policy requirements are added.
The distinguishing feature of systems in this class is the analysis derived
>from formal design specification and verification techniques and the resulting
high degree of assurance that the TCB is correctly implemented. This
assurance is developmental in nature, starting with a formal model of the
security policy and a formal top-level specification (FTLS) of the design. In
keeping with the extensive design and development analysis of the TCB required
of systems in class (A1), more stringent configuration management is required
and procedures are established for securely distributing the system to sites.
A system security administrator is supported.
APPENDIX D
Requirement Directory
This appendix lists requirements defined in "Department of Defense Trusted
Computer System Evaluation Criteria" alphabetically rather than by class. It
is provided to assist in following the evolution of a requirement through the
classes. For each requirement, three types of criteria may be present. Each
will be preceded by the word: NEW, CHANGE, or ADD to indicate the following:
NEW: Any criteria appearing in a lower class are superseded
by the criteria that follow.
CHANGE: The criteria that follow have appeared in a lower class
but are changed for this class. Highlighting is used
to indicate the specific changes to previously stated
criteria.
ADD: The criteria that follow have not been required for any
lower class, and are added in this class to the
previously stated criteria for this requirement.
Abbreviations are used as follows:
NR: (No Requirement) This requirement is not included in
this class.
NAR: (No Additional Requirements) This requirement does not
change from the previous class.
The reader is referred to Part I of this document when placing new criteria
for a requirement into the complete context for that class.
Figure 1 provides a pictorial summary of the evolution of requirements through
the classes.
Audit
C1: NR.
C2: NEW: The TCB shall be able to create, maintain, and protect from
modification or unauthorized access or destruction an audit trail of
accesses to the objects it protects. The audit data shall be
protected by the TCB so that read access to it is limited to those
who are authorized for audit data. The TCB shall be able to record
the following types of events: use of identification and
authentication mechanisms, introduction of objects into a user's
address space (e.g., file open, program initiation), deletion of
objects, and actions taken by computer operators and system
administrators and/or system security officers. For each recorded
event, the audit record shall identify: date and time of the event,
user, type of event, and success or failure of the event. For
identification/authentication events the origin of request (e.g.,
terminal ID) shall be included in the audit record. For events that
introduce an object into a user's address space and for object
deletion events the audit record shall include the name of the object.
The ADP system administrator shall be able to selectively audit the
actions of any one or more users based on individual identity.
B1: CHANGE: For events that introduce an object into a user's address
space and for object deletion events the audit record shall include
the name of the object and the object's security level. The ADP
system administrator shall be able to selectively audit the actions
of any one or more users based on individual identity and/or object
security level.
ADD: The TCB shall also be able to audit any override of
human-readable output markings.
B2: ADD: The TCB shall be able to audit the identified events that may be
used in the exploitation of covert storage channels.
B3: ADD: The TCB shall contain a mechanism that is able to monitor the
occurrence or accumulation of security auditable events that may
indicate an imminent violation of security policy. This mechanism
shall be able to immediately notify the security administrator when
thresholds are exceeded.
A1: NAR.
Configuration Management
C1: NR.
C2: NR.
B1: NR.
B2: NEW: During development and maintenance of the TCB, a configuration
management system shall be in place that maintains control of changes
to the descriptive top-level specification, other design data,
implementation documentation, source code, the running version of the
object code, and test fixtures and documentation. The configuration
management system shall assure a consistent mapping among all
documentation and code associated with the current version of the TCB.
Tools shall be provided for generation of a new version of the TCB
from source code. Also available shall be tools for comparing a
newly generated version with the previous TCB version in order to
ascertain that only the intended changes have been made in the code
that will actually be used as the new version of the TCB.
B3: NAR.
A1: CHANGE: During the entire life-cycle, i.e., during the design,
development, and maintenance of the TCB, a configuration management
system shall be in place for all security-relevant hardware, firmware,
and software that maintains control of changes to the formal model,
the descriptive and formal top-level specifications, other design
data, implementation documentation, source code, the running version
of the object code, and test fixtures and documentation. Also
available shall be tools, maintained under strict configuration
control, for comparing a newly generated version with the previous
TCB version in order to ascertain that only the intended changes have
been made in the code that will actually be used as the new version
of the TCB.
ADD: A combination of technical, physical, and procedural safeguards
shall be used to protect from unauthorized modification or
destruction the master copy or copies of all material used to
generate the TCB.
Covert Channel Analysis
C1: NR.
C2: NR.
B1: NR.
B2: NEW: The system developer shall conduct a thorough search for covert
storage channels and make a determination (either by actual
measurement or by engineering estimation) of the maximum bandwidth of
each identified channel. (See the Covert Channels Guideline section.)
B3: CHANGE: The system developer shall conduct a thorough search for
covert channels and make a determination (either by actual
measurement or by engineering estimation) of the maximum bandwidth
of each identified channel.
A1: ADD: Formal methods shall be used in the analysis.
Design Documentation
C1: NEW: Documentation shall be available that provides a description of
the manufacturer's philosophy of protection and an explanation of how
this philosophy is translated into the TCB. If the TCB is composed
of distinct modules, the interfaces between these modules shall be
described.
C2: NAR.
B1: ADD: An informal or formal description of the security policy model
enforced by the TCB shall be available and an explanation provided to
show that it is sufficient to enforce the security policy. The
specific TCB protection mechanisms shall be identified and an
explanation given to show that they satisfy the model.
B2: CHANGE: The interfaces between the TCB modules shall be described. A
formal description of the security policy model enforced by the TCB
shall be available and proven that it is sufficient to enforce the
security policy.
ADD: The descriptive top-level specification (DTLS) shall be shown to
be an accurate description of the TCB interface. Documentation shall
describe how the TCB implements the reference monitor concept and
give an explanation why it is tamperproof, cannot be bypassed, and is
correctly implemented. Documentation shall describe how the TCB is
structured to facilitate testing and to enforce least privilege.
This documentation shall also present the results of the covert
channel analysis and the tradeoffs involved in restricting the
channels. All auditable events that may be used in the exploitation
of known covert storage channels shall be identified. The bandwidths
of known covert storage channels, the use of which is not detectable
by the auditing mechanisms, shall be provided. (See the Covert
Channel Guideline section.)
B3: ADD: The TCB implementation (i.e., in hardware, firmware, and
software) shall be informally shown to be consistent with the DTLS.
The elements of the DTLS shall be shown, using informal techniques,
to correspond to the elements of the TCB.
A1: CHANGE: The TCB implementation (i.e., in hardware, firmware, and
software) shall be informally shown to be consistent with the formal
top-level specification (FTLS). The elements of the FTLS shall be
shown, using informal techniques, to correspond to the elements of
the TCB.
ADD: Hardware, firmware, and software mechanisms not dealt with in
the FTLS but strictly internal to the TCB (e.g., mapping registers,
direct memory access I/O) shall be clearly described.
Design Specification and Verification
C1: NR.
C2: NR.
B1: NEW: An informal or formal model of the security policy supported by
the TCB shall be maintained that is shown to be consistent with its
axioms.
B2: CHANGE: A formal model of the security policy supported by the TCB
shall be maintained that is proven consistent with its axioms.
ADD: A descriptive top-level specification (DTLS) of the TCB shall be
maintained that completely and accurately describes the TCB in terms
of exceptions, error messages, and effects. It shall be shown to be
an accurate description of the TCB interface.
B3: ADD: A convincing argument shall be given that the DTLS is consistent
with the model.
A1: CHANGE: The FTLS shall be shown to be an accurate description of the
TCB interface. A convincing argument shall be given that the DTLS is
consistent with the model and a combination of formal and informal
techniques shall be used to show that the FTLS is consistent with the
model.
ADD: A formal top-level specification (FTLS) of the TCB shall be
maintained that accurately describes the TCB in terms of exceptions,
error messages, and effects. The DTLS and FTLS shall include those
components of the TCB that are implemented as hardware and/or
firmware if their properties are visible at the TCB interface. This
verification evidence shall be consistent with that provided within
the state-of-the-art of the particular Computer Security Center-
endorsed formal specification and verification system used. Manual
or other mapping of the FTLS to the TCB source code shall be
performed to provide evidence of correct implementation.
Device Labels
C1: NR.
C2: NR.
B1: NR.
B2: NEW: The TCB shall support the assignment of minimum and maximum
security levels to all attached physical devices. These security
levels shall be used by the TCB to enforce constraints imposed by
the physical environments in which the devices are located.
B3: NAR.
A1: NAR.
Discretionary Access Control
C1: NEW: The TCB shall define and control access between named users and
named objects (e.g., files and programs) in the ADP system. The
enforcement mechanism (e.g., self/group/public controls, access
control lists) shall allow users to specify and control sharing of
those objects by named individuals or defined groups or both.
C2: CHANGE: The enforcement mechanism (e.g., self/group/public controls,
access control lists) shall allow users to specify and control
sharing of those objects by named individuals, or defined groups of
individuals, or by both.
ADD: The discretionary access control mechanism shall, either by explicit
user action or by default, provide that objects are protected from
unauthorized access. These access controls shall be capable of
including or excluding access to the granularity of a single user.
Access permission to an object by users not already possessing access
permission shall only be assigned by authorized users.
B1: NAR.
B2: NAR.
B3: CHANGE: The enforcement mechanism (e.g., access control lists) shall
allow users to specify and control sharing of those objects. These
access controls shall be capable of specifying, for each named
object, a list of named individuals and a list of groups of named
individuals with their respective modes of access to that object.
ADD: Furthermore, for each such named object, it shall be possible to
specify a list of named individuals and a list of groups of named
individuals for which no access to the object is to be given.
A1: NAR.
Exportation of Labeled Information
C1: NR.
C2: NR.
B1: NEW: The TCB shall designate each communication channel and I/O
device as either single-level or multilevel. Any change in this
designation shall be done manually and shall be auditable by the
TCB. The TCB shall maintain and be able to audit any change in the
current security level associated with a single-level communication
channel or I/O device.
B2: NAR.
B3: NAR.
A1: NAR.
Exportation to Multilevel Devices
C1: NR.
C2: NR.
B1: NEW: When the TCB exports an object to a multilevel I/O device, the
sensitivity label associated with that object shall also be exported
and shall reside on the same physical medium as the exported
information and shall be in the same form (i.e., machine-readable or
human-readable form). When the TCB exports or imports an object over
a multilevel communication channel, the protocol used on that channel
shall provide for the unambiguous pairing between the sensitivity
labels and the associated information that is sent or received.
B2: NAR.
B3: NAR.
A1: NAR.
Exportation to Single-Level Devices
C1: NR.
C2: NR.
B1: NEW: Single-level I/O devices and single-level communication channels
are not required to maintain the sensitivity labels of the
information they process. However, the TCB shall include a mechanism
by which the TCB and an authorized user reliably communicate to
designate the single security level of information imported or
exported via single-level communication channels or I/O devices.
B2: NAR.
B3: NAR.
A1: NAR.
Identification and Authentication
C1: NEW: The TCB shall require users to identify themselves to it before
beginning to perform any other actions that the TCB is expected to
mediate. Furthermore, the TCB shall use a protected mechanism (e.g.,
passwords) to authenticate the user's identity. The TCB shall
protect authentication data so that it cannot be accessed by any
unauthorized user.
C2: ADD: The TCB shall be able to enforce individual accountability by
providing the capability to uniquely identify each individual ADP
system user. The TCB shall also provide the capability of
associating this identity with all auditable actions taken by that
individual.
B1: CHANGE: Furthermore, the TCB shall maintain authentication data that
includes information for verifying the identity of individual users
(e.g., passwords) as well as information for determining the
clearance and authorizations of individual users. This data shall be
used by the TCB to authenticate the user's identity and to determine
the security level and authorizations of subjects that may be created
to act on behalf of the individual user.
B2: NAR.
B3: NAR.
A1: NAR.
Label Integrity
C1: NR.
C2: NR.
B1: NEW: Sensitivity labels shall accurately represent security levels of
the specific subjects or objects with which they are associated. When
exported by the TCB, sensitivity labels shall accurately and
unambiguously represent the internal labels and shall be associated
with the information being exported.
B2: NAR.
B3: NAR.
A1: NAR.
Labeling Human-Readable Output
C1: NR.
C2: NR.
B1: NEW: The ADP system administrator shall be able to specify the
printable label names associated with exported sensitivity labels.
The TCB shall mark the beginning and end of all human-readable,
paged, hardcopy output (e.g., line printer output) with human-
readable sensitivity labels that properly* represent the sensitivity
of the output. The TCB shall, by default, mark the top and bottom of
each page of human-readable, paged, hardcopy output (e.g., line
printer output) with human-readable sensitivity labels that
properly* represent the overall sensitivity of the output or that
properly* represent the sensitivity of the information on the page.
The TCB shall, by default and in an appropriate manner, mark other
forms of human-readable output (e.g., maps, graphics) with human-
readable sensitivity labels that properly* represent the sensitivity
of the output. Any override of these marking defaults shall be
auditable by the TCB.
B2: NAR.
B3: NAR.
A1: NAR.
____________________________________________________________
* The hierarchical classification component in human-readable
sensitivity labels shall be equal to the greatest
hierarchical classification of any of the information in the
output that the labels refer to; the non-hierarchical
category component shall include all of the non-hierarchical
categories of the information in the output the labels refer
to, but no other non-hierarchical categories.
____________________________________________________________
Labels
C1: NR.
C2: NR.
B1: NEW: Sensitivity labels associated with each subject and storage
object under its control (e.g., process, file, segment, device) shall
be maintained by the TCB. These labels shall be used as the basis
for mandatory access control decisions. In order to import non-
labeled data, the TCB shall request and receive from an authorized
user the security level of the data, and all such actions shall be
auditable by the TCB.
B2: CHANGE: Sensitivity labels associated with each ADP system resource
(e.g., subject, storage object) that is directly or indirectly
accessible by subjects external to the TCB shall be maintained by
the TCB.
B3: NAR.
A1: NAR.
Mandatory Access Control
C1: NR.
C2: NR.
B1: NEW: The TCB shall enforce a mandatory access control policy over all
subjects and storage objects under its control (e.g., processes,
files, segments, devices). These subjects and objects shall be
assigned sensitivity labels that are a combination of hierarchical
classification levels and non-hierarchical categories, and the labels
shall be used as the basis for mandatory access control decisions.
The TCB shall be able to support two or more such security levels.
(See the Mandatory Access Control guidelines.) The following
requirements shall hold for all accesses between subjects and objects
controlled by the TCB: A subject can read an object only if the
hierarchical classification in the subject's security level is
greater than or equal to the hierarchical classification in the
object's security level and the non-hierarchical categories in the
subject's security level include all the non-hierarchical categories
in the object's security level. A subject can write an object only
if the hierarchical classification in the subject's security level is
less than or equal to the hierarchical classification in the object's
security level and all the non-hierarchical categories in the
subject's security level are included in the non-hierarchical
categories in the object's security level.
B2: CHANGE: The TCB shall enforce a mandatory access control policy over
all resources (i.e., subjects, storage objects, and I/O devices) that
are directly or indirectly accessible by subjects external to the TCB.
The following requirements shall hold for all accesses between all
subjects external to the TCB and all objects directly or indirectly
accessible by these subjects:
B3: NAR.
A1: NAR.
Object Reuse
C1: NR.
C2: NEW: When a storage object is initially assigned, allocated, or
reallocated to a subject from the TCB's pool of unused storage
objects, the TCB shall assure that the object contains no data for
which the subject is not authorized.
B1: NAR.
B2: NAR.
B3: NAR.
A1: NAR.
Security Features User's Guide
C1: NEW: A single summary, chapter, or manual in user documentation shall
describe the protection mechanisms provided by the TCB, guidelines on
their use, and how they interact with one another.
C2: NAR.
B1: NAR.
B2: NAR.
B3: NAR.
A1: NAR.
Security Testing
C1: NEW: The security mechanisms of the ADP system shall be tested and
found to work as claimed in the system documentation. Testing shall
be done to assure that there are no obvious ways for an unauthorized
user to bypass or otherwise defeat the security protection mechanisms
of the TCB. (See the Security Testing guidelines.)
C2: ADD: Testing shall also include a search for obvious flaws that would
allow violation of resource isolation, or that would permit
unauthorized access to the audit or authentication data.
B1: NEW: The security mechanisms of the ADP system shall be tested and
found to work as claimed in the system documentation. A team of
individuals who thoroughly understand the specific implementation of
the TCB shall subject its design documentation, source code, and
object code to thorough analysis and testing. Their objectives shall
be: to uncover all design and implementation flaws that would permit
a subject external to the TCB to read, change, or delete data
normally denied under the mandatory or discretionary security policy
enforced by the TCB; as well as to assure that no subject (without
authorization to do so) is able to cause the TCB to enter a state
such that it is unable to respond to communications initiated by
other users. All discovered flaws shall be removed or neutralized
and the TCB retested to demonstrate that they have been eliminated
and that new flaws have not been introduced. (See the Security
Testing Guidelines.)
B2: CHANGE: All discovered flaws shall be corrected and the TCB retested
to demonstrate that they have been eliminated and that new flaws have
not been introduced.
ADD: The TCB shall be found relatively resistant to penetration.
Testing shall demonstrate that the TCB implementation is consistent
with the descriptive top-level specification.
B3: CHANGE: The TCB shall be found resistant to penetration.
ADD: No design flaws and no more than a few correctable
implementation flaws may be found during testing and there shall be
reasonable confidence that few remain.
A1: CHANGE: Testing shall demonstrate that the TCB implementation is
consistent with the formal top-level specification.
ADD: Manual or other mapping of the FTLS to the source code may form
a basis for penetration testing.
Subject Sensitivity Labels
C1: NR.
C2: NR.
B1: NR.
B2: NEW: The TCB shall immediately notify a terminal user of each change
in the security level associated with that user during an interactive
session. A terminal user shall be able to query the TCB as desired
for a display of the subject's complete sensitivity label.
B3: NAR.
A1: NAR.
System Architecture
C1: NEW: The TCB shall maintain a domain for its own execution that
protects it from external interference or tampering (e.g., by
modification of its code or data structures). Resources controlled
by the TCB may be a defined subset of the subjects and objects in
the ADP system.
C2: ADD: The TCB shall isolate the resources to be protected so that they
are subject to the access control and auditing requirements.
B1: ADD: The TCB shall maintain process isolation through the provision
of distinct address spaces under its control.
B2: NEW: The TCB shall maintain a domain for its own execution that
protects it from external interference or tampering (e.g., by
modification of its code or data structures). The TCB shall maintain
process isolation through the provision of distinct address spaces
under its control. The TCB shall be internally structured into well-
defined largely independent modules. It shall make effective use of
available hardware to separate those elements that are protection-
critical from those that are not. The TCB modules shall be designed
such that the principle of least privilege is enforced. Features in
hardware, such as segmentation, shall be used to support logically
distinct storage objects with separate attributes (namely: readable,
writeable). The user interface to the TCB shall be completely
defined and all elements of the TCB identified.
B3: ADD: The TCB shall be designed and structured to use a complete,
conceptually simple protection mechanism with precisely defined
semantics. This mechanism shall play a central role in enforcing the
internal structuring of the TCB and the system. The TCB shall
incorporate significant use of layering, abstraction and data hiding.
Significant system engineering shall be directed toward minimizing
the complexity of the TCB and excluding from the TCB modules that are
not protection-critical.
A1: NAR.
System Integrity
C1: NEW: Hardware and/or software features shall be provided that can be
used to periodically validate the correct operation of the on-site
hardware and firmware elements of the TCB.
C2: NAR.
B1: NAR.
B2: NAR.
B3: NAR.
A1: NAR.
Test Documentation
C1: NEW: The system developer shall provide to the evaluators a document
that describes the test plan and results of the security mechanisms'
functional testing.
C2: NAR.
B1: NAR.
B2: ADD: It shall include results of testing the effectiveness of the
methods used to reduce covert channel bandwidths.
B3: NAR.
A1: ADD: The results of the mapping between the formal top-level
specification and the TCB source code shall be given.
Trusted Distribution
C1: NR.
C2: NR.
B1: NR.
B2: NR.
B3: NR.
A1: NEW: A trusted ADP system control and distribution facility shall be
provided for maintaining the integrity of the mapping between the
master data describing the current version of the TCB and the on-site
master copy of the code for the current version. Procedures (e.g.,
site security acceptance testing) shall exist for assuring that the
TCB software, firmware, and hardware updates distributed to a
customer are exactly as specified by the master copies.
Trusted Facility Management
C1: NR.
C2: NR.
B1: NR.
B2: NEW: The TCB shall support separate operator and administrator
functions.
B3: ADD: The functions performed in the role of a security administrator
shall be identified. The ADP system administrative personnel shall
only be able to perform security administrator functions after taking
a distinct auditable action to assume the security administrator role
on the ADP system. Non-security functions that can be performed in
the security administration role shall be limited strictly to those
essential to performing the security role effectively.
A1: NAR.
Trusted Facility Manual
C1: NEW: A manual addressed to the ADP system administrator shall present
cautions about functions and privileges that should be controlled
when running a secure facility.
C2: ADD: The procedures for examining and maintaining the audit files as
well as the detailed audit record structure for each type of audit
event shall be given.
B1: ADD: The manual shall describe the operator and administrator
functions related to security, to include changing the
characteristics of a user. It shall provide guidelines on the
consistent and effective use of the protection features of the
system, how they interact, how to securely generate a new TCB, and
facility procedures, warnings, and privileges that need to be
controlled in order to operate the facility in a secure manner.
B2: ADD: The TCB modules that contain the reference validation mechanism
shall be identified. The procedures for secure generation of a new
TCB from source after modification of any modules in the TCB shall
be described.
B3: ADD: It shall include the procedures to ensure that the system is
initially started in a secure manner. Procedures shall also be
included to resume secure system operation after any lapse in system
operation.
A1: NAR.
Trusted Path
C1: NR.
C2: NR.
B1: NR.
B2: NEW: The TCB shall support a trusted communication path between
itself and user for initial login and authentication. Communications
via this path shall be initiated exclusively by a user.
B3: CHANGE: The TCB shall support a trusted communication path between
itself and users for use when a positive TCB-to-user connection is
required (e.g., login, change subject security level).
Communications via this trusted path shall be activated exclusively
by a user or the TCB and shall be logically isolated and unmistakably
distinguishable from other paths.
A1: NAR.
Trusted Recovery
C1: NR.
C2: NR.
B1: NR.
B2: NR.
B3: NEW: Procedures and/or mechanisms shall be provided to assure that,
after an ADP system failure or other discontinuity, recovery without a
protection compromise is obtained.
A1: NAR.
(this page is reserved for Figure 1)
GLOSSARY
Access - A specific type of interaction between a subject and an object
that results in the flow of information from one to the other.
Approval/Accreditation - The official authorization that is
granted to an ADP system to process sensitive information in
its operational environment, based upon comprehensive
security evaluation of the system's hardware, firmware, and
software security design, configuration, and implementation
and of the other system procedural, administrative,
physical, TEMPEST, personnel, and communications security
controls.
Audit Trail - A set of records that collectively provide
documentary evidence of processing used to aid in tracing
from original transactions forward to related records and
reports, and/or backwards from records and reports to their
component source transactions.
Authenticate - To establish the validity of a claimed identity.
Automatic Data Processing (ADP) System - An assembly of computer
hardware, firmware, and software configured for the purpose
of classifying, sorting, calculating, computing,
summarizing, transmitting and receiving, storing, and
retrieving data with a minimum of human intervention.
Bandwidth - A characteristic of a communication channel that is
the amount of information that can be passed through it in a
given amount of time, usually expressed in bits per second.
Bell-LaPadula Model - A formal state transition model of computer
security policy that describes a set of access control
rules. In this formal model, the entities in a computer
system are divided into abstract sets of subjects and
objects. The notion of a secure state is defined and it is
proven that each state transition preserves security by
moving from secure state to secure state; thus, inductively
proving that the system is secure. A system state is
defined to be "secure" if the only permitted access modes of
subjects to objects are in accordance with a specific
security policy. In order to determine whether or not a
specific access mode is allowed, the clearance of a subject
is compared to the classification of the object and a
determination is made as to whether the subject is
authorized for the specific access mode. The
clearance/classification scheme is expressed in terms of a
lattice. See also: Lattice, Simple Security Property, *-
Property.
Certification - The technical evaluation of a system's security
features, made as part of and in support of the
approval/accreditation process, that establishes the extent
to which a particular computer system's design and
implementation meet a set of specified security
requirements.
Channel - An information transfer path within a system. May also
refer to the mechanism by which the path is effected.
Covert Channel - A communication channel that allows a process to
transfer information in a manner that violates the system's
security policy. See also: Covert Storage Channel, Covert
Timing Channel.
Covert Storage Channel - A covert channel that involves the
direct or indirect writing of a storage location by one
process and the direct or indirect reading of the storage
location by another process. Covert storage channels
typically involve a finite resource (e.g., sectors on a
disk) that is shared by two subjects at different security
levels.
Covert Timing Channel - A covert channel in which one process
signals information to another by modulating its own use of
system resources (e.g., CPU time) in such a way that this
manipulation affects the real response time observed by the
second process.
Data - Information with a specific physical representation.
Data Integrity - The state that exists when computerized data is
the same as that in the source documents and has not been
exposed to accidental or malicious alteration or
destruction.
Descriptive Top-Level Specification (DTLS) - A top-level
specification that is written in a natural language (e.g.,
English), an informal program design notation, or a
combination of the two.
Discretionary Access Control - A means of restricting access to
objects based on the identity of subjects and/or groups to
which they belong. The controls are discretionary in the
sense that a subject with a certain access permission is
capable of passing that permission (perhaps indirectly) on
to any other subject.
Domain - The set of objects that a subject has the ability to
access.
Dominate - Security level S1 is said to dominate security level
S2 if the hierarchical classification of S1 is greater than
or equal to that of S2 and the non-hierarchical categories
of S1 include all those of S2 as a subset.
Exploitable Channel - Any channel that is useable or detectable
by subjects external to the Trusted Computing Base.
Flaw Hypothesis Methodology - A system analysis and penetration
technique where specifications and documentation for the
system are analyzed and then flaws in the system are
hypothesized. The list of hypothesized flaws is then
prioritized on the basis of the estimated probability that a
flaw actually exists and, assuming a flaw does exist, on the
ease of exploiting it and on the extent of control or
compromise it would provide. The prioritized list is used
to direct the actual testing of the system.
Flaw - An error of commission, omission, or oversight in a system
that allows protection mechanisms to be bypassed.
Formal Proof - A complete and convincing mathematical argument,
presenting the full logical justification for each proof
step, for the truth of a theorem or set of theorems. The
formal verification process uses formal proofs to show the
truth of certain properties of formal specification and for
showing that computer programs satisfy their specifications.
Formal Security Policy Model - A mathematically precise statement
of a security policy. To be adequately precise, such a
model must represent the initial state of a system, the way
in which the system progresses from one state to another,
and a definition of a "secure" state of the system. To be
acceptable as a basis for a TCB, the model must be supported
by a formal proof that if the initial state of the system
satisfies the definition of a "secure" state and if all
assumptions required by the model hold, then all future
states of the system will be secure. Some formal modeling
techniques include: state transition models, temporal logic
models, denotational semantics models, algebraic
specification models. An example is the model described by
Bell and LaPadula in reference [2]. See also: Bell-
LaPadula Model, Security Policy Model.
Formal Top-Level Specification (FTLS) - A Top-Level Specification
that is written in a formal mathematical language to allow
theorems showing the correspondence of the system
specification to its formal requirements to be hypothesized
and formally proven.
Formal Verification - The process of using formal proofs to
demonstrate the consistency (design verification) between a
formal specification of a system and a formal security
policy model or (implementation verification) between the
formal specification and its program implementation.
Functional Testing - The portion of security testing in which the
advertised features of a system are tested for correct
operation.
General-Purpose System - A computer system that is designed to
aid in solving a wide variety of problems.
Lattice - A partially ordered set for which every pair of
elements has a greatest lower bound and a least upper bound.
Least Privilege - This principle requires that each subject in a
system be granted the most restrictive set of privileges (or
lowest clearance) needed for the performance of authorized
tasks. The application of this principle limits the damage
that can result from accident, error, or unauthorized use.
Mandatory Access Control - A means of restricting access to
objects based on the sensitivity (as represented by a label)
of the information contained in the objects and the formal
authorization (i.e., clearance) of subjects to access
information of such sensitivity.
Multilevel Device - A device that is used in a manner that
permits it to simultaneously process data of two or more
security levels without risk of compromise. To accomplish
this, sensitivity labels are normally stored on the same
physical medium and in the same form (i.e., machine-readable
or human-readable) as the data being processed.
Multilevel Secure - A class of system containing information with
different sensitivities that simultaneously permits access
by users with different security clearances and needs-to-
know, but prevents users from obtaining access to
information for which they lack authorization.
Object - A passive entity that contains or receives information.
Access to an object potentially implies access to the
information it contains. Examples of objects are: records,
blocks, pages, segments, files, directories, directory
trees, and programs, as well as bits, bytes, words, fields,
processors, video displays, keyboards, clocks, printers,
network nodes, etc.
Object Reuse - The reassignment to some subject of a medium
(e.g., page frame, disk sector, magnetic tape) that
contained one or more objects. To be securely reassigned,
such media must contain no residual data from the previously
contained object(s).
Output - Information that has been exported by a TCB.
Password - A private character string that is used to
authenticate an identity.
Penetration Testing - The portion of security testing in which
the penetrators attempt to circumvent the security features
of a system. The penetrators may be assumed to use all
system design and implementation documentation, which may
include listings of system source code, manuals, and circuit
diagrams. The penetrators work under no constraints other
than those that would be applied to ordinary users.
Process - A program in execution. It is completely characterized
by a single current execution point (represented by the
machine state) and address space.
Protection-Critical Portions of the TCB - Those portions of the
TCB whose normal function is to deal with the control of
access between subjects and objects.
Protection Philosophy - An informal description of the overall
design of a system that delineates each of the protection
mechanisms employed. A combination (appropriate to the
evaluation class) of formal and informal techniques is used
to show that the mechanisms are adequate to enforce the
security policy.
Read - A fundamental operation that results only in the flow of
information from an object to a subject.
Read Access - Permission to read information.
Reference Monitor Concept - An access control concept that refers
to an abstract machine that mediates all accesses to objects
by subjects.
Resource - Anything used or consumed while performing a function.
The categories of resources are: time, information, objects
(information containers), or processors (the ability to use
information). Specific examples are: CPU time; terminal
connect time; amount of directly-addressable memory; disk
space; number of I/O requests per minute, etc.
Security Kernel - The hardware, firmware, and software elements
of a Trusted Computing Base that implement the reference
monitor concept. It must mediate all accesses, be protected
from modification, and be verifiable as correct.
Security Level - The combination of a hierarchical classification
and a set of non-hierarchical categories that represents the
sensitivity of information.
Security Policy - The set of laws, rules, and practices that
regulate how an organization manages, protects, and
distributes sensitive information.
Security Policy Model - An informal presentation of a formal
security policy model.
Security Testing - A process used to determine that the security
features of a system are implemented as designed and that
they are adequate for a proposed application environment.
This process includes hands-on functional testing,
penetration testing, and verification. See also: Functional
Testing, Penetration Testing, Verification.
Sensitive Information - Information that, as determined by a
competent authority, must be protected because its
unauthorized disclosure, alteration, loss, or destruction
will at least cause perceivable damage to someone or
something.
Sensitivity Label - A piece of information that represents the
security level of an object and that describes the
sensitivity (e.g., classification) of the data in the
object. Sensitivity labels are used by the TCB as the basis
for mandatory access control decisions.
Simple Security Property - A Bell-LaPadula security model rule
allowing a subject read access to an object only if the
security level of the subject dominates the security level
of the object.
Single-Level Device - A device that is used to process data of a
single security level at any one time. Since the device
need not be trusted to separate data of different security
levels, sensitivity labels do not have to be stored with the
data being processed.