top - download
⟦5da9deb13⟧ Wang Wps File
Length: 26829 (0x68cd)
Types: Wang Wps File
Notes: CAMPS Sys.Des.Spec.
Names: »0421A «
Derivation
└─⟦74b766e5b⟧ Bits:30006076 8" Wang WCS floppy, CR 0033A
└─ ⟦this⟧ »0421A «
WangText
…02…CPS/SDS/001
…02…OKH/810115…02……02…
CAMPS SYSTEM DESIGN SPECIFICATION
…02……02…CAMPS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
4.9 SECURITY ...................................
4.9.1 Introduction .............................
4.9.2 Security and Access Control ..............
4.9.2.1 General Concepts .....................
4.9.2.1.1 Classification of Data .............
4.9.2.1.2 External Interface Points ..........
4.9.2.1.3 Classification of Control Functions
4.9.2.1.4 User Processes .....................
4.9.2.2 Security Profile .....................
4.9.2.3 Security and Access Control Mechanisms
4.9.2.3.1 CAMPS Modules Involved in Security
4.9.2.3.2 Security Control on User Processes
4.9.2.3.3 Access Control on User Processes .
4.9.2.3.3.1 Access to Messages ...........
4.9.2.3.3.2 Access to System Control Data
4.9.2.3.4 Message Security Profile .........
4.9.2.3.5 User Process Security Profile ....
4.9.2.3.6 Message Distribution Decisions ...
4.9.2.3.7 Management of Profiles ...........
4.9.2.3.8 Operator Verification ............
4.9.2.3.9 Exception Handling ...............
4.9.3 Integrity of Operation .................
4.9.3.1 Introduction .......................
4.9.4 Radiation ..............................
4.9 S̲E̲C̲U̲R̲I̲T̲Y̲
4.9.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
The purpose of this section is to describe the general
security aspects of CAMPS, as well as the principles
used to enforce the required security control functions.
Many details have intentionally been left out, as they
do not contribute to understanding of the general principles.
The general security objective may be stated as follows:
Assure that information on a CAMPS site will neither
be disclosed to nor modified by unauthorized individuals
or external systems, either intentionally or by accident.
CAMPS security has 3 major areas of concern:
1) Functional level controls.
Implements in operational software the security
requirements of the SRS regarding user and message
handling.
2) Integrity of operation.
Protection level controls with the purpose of minimizing
the probability of security violation caused by
errors in the system.
3) Radiation.
The measures used to limit radiation from CAMPS.
Those main areas will be covered in the subsections
4.9.2, 4.9.3 and 4.9.4. The descriptions will include
identification of the subsystems and packages responsible
for various parts of security. Detailed description
of security measures may be found in the appropriate
package descriptions.
4.9.2 S̲e̲c̲u̲r̲i̲t̲y̲ ̲a̲n̲d̲ ̲A̲c̲c̲e̲s̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲
This section describes in general the mechanisms used
to implement all security requirements not connected
with radiation.
The section will attach specific meaning to the terms
s̲e̲c̲u̲r̲i̲t̲y̲ ̲c̲o̲n̲t̲r̲o̲l̲, a̲c̲c̲e̲s̲s̲ ̲c̲o̲n̲t̲r̲o̲l̲ and p̲r̲o̲t̲e̲c̲t̲i̲o̲n̲, state
the objective of those control functions and describe
how CAMPS Application modules, CAMPS System Functions
and Kernel share responsibilities for the controls.
The CAMPS requirements are generalised in a way making
them suitable for a centralized, unified control scheme.
4.9.2.1 G̲e̲n̲e̲r̲a̲l̲ ̲C̲o̲n̲c̲e̲p̲t̲s̲
4.9.2.1.1 C̲l̲a̲s̲s̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲D̲a̲t̲a̲
For the purpose of this section, data within CAMPS
may be divided into three different classes:
a) Operational Data
Consists of data types such as messages, comments,
release notifications etc. the handling of which
is the ultimate objective of CAMPS.
b) System Control Data
Consists of data such as a log data, statistics
data, routing tables, terminal profiles etc., which
are required by SRS and used for management and
control of a CAMPS system.
c) System Data
All other information such as programs, variables
software system tables etc. used in controlling
and manipulating the two other types.
The reason for this classification is that there are
different control and protection requirements for each
of those three classes, as shown in section 4.9.2.1.3.
4.9.2.1.2 E̲x̲t̲e̲r̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲P̲o̲i̲n̲t̲s̲ ̲
Security and access control is, from a functional point
of view, concerned with the exchange of operational
data, system control data and commands between CAMPS
and its environment. The external interface points
are the points where this information exchange may
take place, such as:
a) Unattended Terminals
b) Attended Terminals
c) External Channels to a Network, e.g. NICS/TARE
d) External Channels to other Systems, e.g. CCIS
e) Paper Tape Punch
etc.
In the rest of this section such entities will be called
logical lines. The purpose of the section is then to
describe the requirements for and mechanisms to control
information flow on logical lines.
4.9.2.1.3 C̲l̲a̲s̲s̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
From the functional point of view there are two types
of control on information flow, s̲e̲c̲u̲r̲i̲t̲y̲ ̲c̲o̲n̲t̲r̲o̲l̲ and
a̲c̲c̲e̲s̲s̲ ̲c̲o̲n̲t̲r̲o̲l̲. Each of them applies to pairs (data
unit, logical line). The first one specifies a general
decision rule as to whether the line may receive the
information. The second one defines explicitly which
logical lines may receive or cause modification of
a given operational or system control data unit.
The decision rules are described in the following.
a) Security Control
Each operational data unit and each logical line
has an associated security level. The security
control rule is that a logical line may not receive
a data unit unless
security level of logical line = security level
of data unit.
b) Access Control
For each operational and system control data unit
there will be a data type dependent algorithm defining
the logical lines which may receive and/or update
the data unit.
Examples of access control rules are:
1) Terminal profiles may only be displayed and updated
from supervisor position.
2) A message under preparation may only be displayed
by originating, releasing and coordinating terminal
position.
The applicability of security and access control is
shown in the following table.
Figure 4.9.2.1.3-1 …01…S̲E̲C̲U̲R̲I̲T̲Y̲ ̲A̲N̲D̲ ̲A̲C̲C̲E̲S̲S̲ ̲C̲O̲N̲T̲R̲O̲L̲ ̲O̲N̲ ̲F̲U̲N̲C̲T̲I̲O̲N̲A̲L̲ ̲L̲E̲V̲E̲L̲
4.9.2.1.4 U̲s̲e̲r̲ ̲P̲r̲o̲c̲e̲s̲s̲e̲s̲
Each logical line will have a CAMPS application module
associated with it, handling all information transfers
on the line. Such an application module will be called
a user process. For attended terminals the user process
will then be the CAMPS module that acts on behalf of
the human operator, transforming his commands into
internal processing sequences and system requests.
A user process may typically, but not necessarily,
be implemented as a process in DAMOS sense.
A very simplified view of a single message flowing
through CAMPS may then in terms of user processes be
depicted as shown on figure 4.9.2.1.4-1.
An important detail not shown on the diagram is that
"Intermediate Manipulation" may involve interaction
with for instance MDCO user.
The diagram does readily apply to incoming messages
where most destinations will be terminals. Thus destination
user processes are terminal modules (processes). But
a similar flow applies to message coordination and
message release, where the release terminal may be
seen as originator and some destinations are then external
channels.
There are two aspects of the diagram that turn out
to apply in all cases.
a) An operational data unit is always originated by
a user process. The user process may either read
the data directly from its logical line or combine
information, e.g. edit commands from the line with
stored operational data unit(s). The resulting
operational data unit will always be stored in
its entirety in an item on disk.
b) An operational data unit to be transmitted on a
line will always in its entirety be stored in an
item on disk, and the user process of the line
will read the data unit from disk and transmit
it on the line.
These two observations lead to an assumption which
will form the basis for security and access control
in CAMPS.
c) Information read from items by a user process may
potentially be transmitted on the corresponding
line. So the most important place to put controls
is on user process access to stored data items.
On the functional level this control is the responsibility
of CAMPS Message Monitor.
4.9.2.2 S̲e̲c̲u̲r̲i̲t̲y̲ ̲P̲r̲o̲f̲i̲l̲e̲
In addition to the security classification there are
two other criteria of classification which are handled
in the security control.They are:
a) Those special handling categories which may appear
in terminal, operator and line profiles.
b) Indication of operators which may only receive
exercise information.
The information relevant to those additional security
classification criteria are together with the normal
security classification, collected into an aggregate
called the s̲e̲c̲u̲r̲i̲t̲y̲ ̲p̲r̲o̲f̲i̲l̲e̲, which is consequently
an extension of the security classification mentioned
in previous sections.
Each logical line and each operational data unit will
have an associated security profile, and the security
control described in 4.9.2.1.3 a) is actually extended
to check on security profiles.
The contents of security profile and the check performed
will be as follows:
1) The security profile consists of a set of socalled
compartment field, which are:
a) Security classification compartment covers
the normal security classification and may
assume the levels 0 - 4, ranging from UNCLASSIFIED
to COSMIC TOP SECRET.
b) A number of special handling compartments,
each of which corresponds to a special handling
category, and may assume the levels 1 or 0,
interpreted as "belong to" and "not belong
to" the category.
c) An exercise compartment which may assume the
level 0 for exercise and 1 for non exercise.
2) Each operational data unit will have a security
profile associated with it. The levels in the compartment
fields will correspond to the defined security
classification, special handling categories and
exercise indication for the data unit.
3) Each user process will have a security profile
associated with it. The levels in the compartment
fields correspond to the security classification,
special handling access rights and exercise status
of the corresponding logical line.
4) The basic security rule checks the right of a user
process to read an operation data unit. It states
that the user process may read the data unit only
if within each compartment field of the security
profile:
Security level of user process =
Security level of data unit.
4.9.2.3 S̲e̲c̲u̲r̲i̲t̲y̲ ̲a̲n̲d̲ ̲A̲c̲c̲e̲s̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲M̲e̲c̲h̲a̲n̲i̲s̲m̲s̲
The previous section described general notions and
ideas behind the control functions, and concluded with
the control of user processes access to operational
data. In a static environment this specific control
would cover most of the need for functional level control
in a secure system.
CAMPS, however, is far from being a static system,
as entities such as operators and operational data
units come to existence and disappear all the time
as a result of CAMPS operation. This is the reason
why the control of access to operational data is only
one of the many security aspects to be taken into account.
The purpose of the present section is to start an analysis
identifying all the security aspects and the roles
played by the various CAMPS modules. Operational data
units will be mentioned very frequently in this analysis
and will for reasons of brevity be referred to as m̲e̲s̲s̲a̲g̲e̲s̲.
The following aspects will be mentioned:
a) Security control of user processes access to messages.
b) Access control of user processes access to messages
and system control data.
c) Association of security profile to a message.
d) Association of security profile to a user process.
e) Message distribution decisions.
f) Management of operator, terminal and line profiles.
g) Operator verification.
h) Exception handling.
As mentioned previously, this section will only describe
the f̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲l̲e̲v̲e̲l̲ of security and access control,
that is the means making CAMPS behave as required in
handling messages and logical lines. The p̲r̲o̲t̲e̲c̲t̲i̲o̲n̲
̲l̲e̲v̲e̲l̲ controls, with the purpose of detecting if something
goes wrong on the functional level, are described in
section 4.9.2.4.
The functional level controls are in most cases directly
derived from system requirements. They could in principle
be allocated to the appropriate subsystems each of
which could then invent their own more or less complex
control mechanisms. This is in particular true for
access control to messages.
The purpose of the proposed centralized control is
among others to
1) Generalize the requirements in a way that makes
the control scheme simple, understandable and manageable.
2) Enforce a unified approach to security and access
control.
3) Prevent that subsystem designers overlook problems.
4) Centralize security- and access controls, thereby
facilitating careful design, coding and test of
those parts of CAMPS system.
5) Facilitate implemention of a protection level of
security and access control.
4.9.2.3.1 C̲A̲M̲P̲S̲ ̲M̲o̲d̲u̲l̲e̲s̲ ̲I̲n̲v̲o̲l̲v̲e̲d̲ ̲i̲n̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲
CAMPS processes and functions may for the purpose of
security analysis be divided into three types:
1) User processes.
Each user process is directly associated with a
logical line, and it is the CAMPS module interpreting
user or line protocol commands and carrying out
internal functions according to those commands
and the CAMPS rules of message handling. In short
the user process is said to act on behalf of the
logical line.
Examples are processes associated with user terminals,
supervisor terminals and external channels.
2) Message distribution and support processes.
Perform the internal distribution and routing functions
and support functions such as logging, storage
and retrieval etc.
3) System processes.
Control and mediate other processes access to messages
and lines.
The main groups are
a) IO Control Software.
Mediates access to lines.
b) Storage and File Management
Mediates access to messages and other data.
c) Terminal and Line Control Operating System,
TEMCO.
d) CAMPS System Functions.
Performs queuing and state transitions on messages.
The major relations in terms of message flow channels
are shown in figure 4.9.2.3-1.
FIGURE 4.9.2.3-1…01…G̲E̲N̲E̲R̲A̲L̲I̲Z̲E̲D̲ ̲M̲E̲S̲S̲A̲G̲E̲ ̲F̲L̲O̲W̲ ̲C̲H̲A̲N̲N̲E̲L̲S̲
4.9.2.3.2 S̲e̲c̲u̲r̲i̲t̲y̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲o̲n̲ ̲U̲s̲e̲r̲ ̲P̲r̲o̲c̲e̲s̲s̲e̲s̲
Each message and each user process will have a security
profile associated with it. The security control rule
will then be:
A user process may only get read access to a message
if for each compartment field of security profile:
Security level of message = security level of user
process.
The control will be carried out by Message Monitor
when the user issues the OPEN MESSAGE request. If granted,
subsequent access to the message will not be security
checked. The access permission will be in force until
the user issues a CLOSE MESSAGE.
Message distribution processes may need to know if
a particular user process would be allowed to access
a particular message.This may be done by the CHECK
SECURITY function as described in 4.9.2.3.6.
4.9.2.3.3 A̲c̲c̲e̲s̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲o̲n̲ ̲U̲s̲e̲r̲ ̲P̲r̲o̲c̲e̲s̲s̲e̲s̲
Controls if a user is authorized to read or manipulate
a message or a system control data unit.
4.9.2.3.3.1 A̲c̲c̲e̲s̲s̲ ̲t̲o̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
The algorithms for evaluating a specific user process
access capabilities versus a given message are rather
complicated, as they involve routing tables, standard
distribution lists, manual decisions etc.
The basic access control mechanism will be based on
queues and queue elements. The following principles
will be used:
a) Each queue in the system carries a list of user
processes which may access elements in the queue
and for each user process a list of permitted access
capabilities, such as read, update, create new
version, delete etc.
b) A user process may only access messages which have
been placed in a queue that the user has the appropriate
access to, and after the user process has RECEIVED
the message from the queue. The access control
will be performed by Message Monitor when the user
process issues the OPEN MESSAGE.
Section 4.9.2.3.6 will describe the decisions about
placing messages in queues.
4.9.2.3.3.2 A̲c̲c̲e̲s̲s̲ ̲t̲o̲ ̲S̲y̲s̲t̲e̲m̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲D̲a̲t̲a̲
Most of those data may only be updated by supervisor
user process. The appropriate control scheme is TBD.
4.9.2.3.4 M̲e̲s̲s̲a̲g̲e̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲ ̲P̲r̲o̲f̲i̲l̲e̲
Association of security profile to a message is the
responsibility of the originating user process. It
is done at the time where the original message verion
is created by supplying security profile as an attribute
in the CREATE MESSAGE request to Message Monitor.
Message originators are user processes of:
a) Message preparation terminals
b) External lines
c) PTR
d) OCR
e) Supervisor terminal (rerun)
Security profile may subsequently be changed. This
is done by the CHANGE ATTRIBUTES request to Message
Monitor. A change may in particular take place for
incoming messages where the final detection of security
level will be part of ACP 127 analysis.
The CAMPS modules which may change security profile
for a message are:
1) Originating Terminal User process
2) ACP 127 Analysis
4.9.2.3.5 U̲s̲e̲r̲ ̲P̲r̲o̲c̲e̲s̲s̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲ ̲P̲r̲o̲f̲i̲l̲e̲
The idea of a user process as defined in 4.9.2.1.4
is that it represents the corresponding logical line.
So the security profile of a user process shall at
every time be the current security level assigned to
the line.
The current security level for a logical line is composed
of information from one or two p̲r̲o̲f̲i̲l̲e̲s̲. A profile
is associated with each of the following entities:
a) External lines
b) PTR
c) PTP
d) OCR
e) Terminals
f) Human operators
For user processes of line types a) - d) the security
profile is defined to be that of the corresponding
line, and it is taken directly from the line profile.
For an unattended terminal, the user process security
profile is defined as:
1) Security Classification = UNCLASSIFIED
2) All special handling categories set to zero
3) Exercise indicator as defined by terminal profile
For an attended terminal the user process security
profile is defined as the minimum within each compartment
field of the terminal security level and the operator
security level.
Supervisor and his assistants seem to be exceptions,
as their security profiles must apparently be overruled
when they act in supervisor roles. Details are TBD.
User process security profiles are set by TEMCO. For
a terminal the profile is redefined each time the logical
or physical access state of the terminal changes, that
is when security key is turned ON/OFF and at Sign in-Sign
out. Further details are described in 4.9.2.3.8.
4.9.2.3.6 M̲e̲s̲s̲a̲g̲e̲ ̲D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲D̲e̲c̲i̲s̲i̲o̲n̲s̲
In section 4.9.2.3.3.1, a) - b) the access control
rules for messages were stated. The rule is that if
a user process may receive from a queue, it may access
all messages sent to the queue. This places the burden
on those CAMPS modules distributing messages to user
processes.
As said before the message distribution rules are unfortunately
very complex and message distribution decisions are
taken by several CAMPS packages.
The CAMPS modules which take message distribution decisions
are
a) Message preparation terminal users:
1) Message release
b) Message distribution:
1) Message coordination
2) Local distribution of outgoing messages
3) Incoming message distribution
4) Release notification
c) Traffic handling:
1) Outgoing message routing
d) MDCO terminal user:
1) Manual message distribution decisions
e) Storage and retrieval
This package may on request from a terminal user
process retrieve a message from HDB and place it
in a queue specified by requestor. If possible,
the access right of requestor should be checked
by Message Distribution package
The CAMPS modules involved in message distribution
and routing may have a need for checking if a destination
user process will be allowed to access a particular
message. For that purpose they may call the following
procedure:
CHECK SECURITY
Input: User process identification
Message reference.
Output: Completion code.
The completion code is a YES or NO, telling if the
pair (user process, message) passed the security check.
4.9.2.3.7 M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲o̲f̲ ̲P̲r̲o̲f̲i̲l̲e̲s̲
Profiles for terminals, operators and lines are maintained
by supervisor user process via CAMPS TABLE MANAGEMENT.
For operator profiles there is a very critical issue
of password maintenance, particularly because they
will be changed very frequently.
The profiles are used by TEMCO in the dynamic setting
of security level for user processes. Refer to 4.9.2.3.5.
4.9.2.3.8 O̲p̲e̲r̲a̲t̲o̲r̲ ̲V̲e̲r̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This section describes the mechanisms for verifying
terminal operator identity and performing the proper
actions. It might also be called Logical Access State
Monitoring.
The functions are carried out by TEMCO. They are:
a) Sign on - Sign off commands.
By operator commands which IOC will automatically
direct to TEMCO.
b) Security key ON-OFF state monitoring.
c) Physical on-line-off-line state monitoring
d) Security interrogation.
Performed on notification from Message Monitor
when a terminal user process requests OPEN
MESSAGE for a message with classification above
SECRET (or another limit as specified by supervisor)
e) Security warning.
On same occasions as interrogation, if certain
special handling compartment fields in security
profile are set.
4.9.2.3.9. E̲x̲c̲e̲p̲t̲i̲o̲n̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
Contains rules for handling security violations and
other abnormal situations. Examples are:
a) Consecutive password errors on a terminal during
sign-on, security interrogation or message release.
Handled by TEMCO which will notify supervisor and
block terminal.
b) Messages destined for a terminal can not pass security
check. The messages are sent to MDCO for further
decision.
A complete list will be worked out during package design.
4.9.3 I̲n̲t̲e̲g̲r̲i̲t̲y̲ ̲o̲f̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲
4.9.3.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
The functional level security and access control mechanisms
described previously will, when fully developed, constitute
a complete system satisfying all the functional level
requirements for CAMPS.
In addition to the functional level requirements the
SRS specifies a few defensive mechanisms such as purging
highly classified messages from disk or memory and
overwriting the complete disk pack before reuse. These
mechanisms serve the same purpose as those described
in the following.
There are two basic assumptions of the functional level
controls:
1) The system is errorfree, meaning that all hardware
and software components, or at least those affecting
security, behave according to specifications.
2) The individuals operating the system behave according
to specified operational procedures.
Neither of those assumptions are true.
Hardware will occasionally fail, and some of the failures
could remain undetected for some time and cause one
or more security violations during the period.
Software modules will, even after thorough validation
in form of testing and inspection, contain errors.
They may be due to faulty or misconceived program specifications
or to direct programming errors. Software errors will
by nature remain undetected for some time and may then
like hardware errors result in undetected security
violations.
Human operators may operate the system in an erroneous
way, for example by replacing a disk pack without noticing
the system in advance.
By the term "integrity of operation" is meant the way
in which the system behaves according to the specification,
even in cases where the system contains errors.
Of course it is not possible to preserve integrity
of operation 100% under all circumstances, as this
would require that the system detected any failure
before it had effects on system operation.
By carefully designed defensive mechanisms it is, however,
possible to decrease considerably the likelihood of
serious security violations caused by system errors.
The mechanisms used for that purpose are described
in this section.
The required level of integrity of operation and the
defensive mechanisms used are still under consideration,
so further details are TBD.
4.9.4 E̲l̲e̲c̲t̲r̲o̲-̲m̲a̲g̲n̲e̲t̲i̲c̲ ̲R̲a̲d̲i̲a̲t̲i̲o̲n̲
The CAMPS equipment is designed to meet the TEMPEST
requirements for electromagnetic radiation as specified
in AMSG 719 B and AMSG 720 A.
4.9.4.1 I̲t̲e̲m̲s̲ ̲o̲f̲ ̲E̲q̲u̲i̲p̲m̲e̲n̲t̲
The following items of Terminal Equipment are TEMPEST
certificated:
- Visual Display Unit (VDUs)
- Medium Speed Teleprinter (MSP)
- Paper Tape Punch/Reader (PTP/PTR)
- Line Printer
The system composed by the main computer and line termination
equipment is enclosed in EMI rack assemblies. This
enclosed system is designed to meet AMSG 719B and AMSG
720A as specified above. The system will be approved
by the COMSEC test.
4.9.4.2 I̲n̲s̲t̲a̲l̲l̲a̲t̲i̲o̲n̲
The CAMPS Equipment is designed to meet the installation
requirements of AMSG 719B, when installed at the site
locations.
