top - download
⟦eb21a0f2e⟧ Wang Wps File
Length: 98812 (0x181fc)
Types: Wang Wps File
Notes: SFS/FS/001
Names: »3668A «
Derivation
└─⟦2c1d27607⟧ Bits:30006216 8" Wang WCS floppy, CR 0284A
└─ ⟦this⟧ »3668A «
WangText
1…07…0…0a…0…02…0…06…/…0b…/…0c…/
.…0a….…00…-…08…-…00…-
-…05…,…0c…, +…0b…+
*…0b…*…02…*…06…*…07…)…08…)…09…)…0a…)…0b…)…0c…)
(…0c……86…1
…02…
…02…
…02…
…02…
NATO
UNCLASSIFIED
NATO UNCLASSIFIED
SFS/FS/001 1983-05-30
FILTER SPECIFICATION Page #
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 GENERAL ........................................
3
1.1 INTRODUCTION ...............................
3
1.2 STUDY REFERENCES............................
3
1.3 TERMS AND ABBREVIATIONS ....................
4
2 SUMMARY OF REQUIREMENTS.........................
6
2.1 SYSTEM DESCRIPTION .........................
6
2.2 SYSTEM FUNCTIONS ...........................
8
2.2.1 Filter Functions .......................
8
2.2.2 Auxiliary Functions ....................
9
2.3 ACCURACY AND VALIDITY ......................
12
2.4 TIMING .....................................
13
3 ENVIRONMENT ....................................
14
4 DESIGN DETAILS .................................
15
4.1 GENERAL OPERATING PROCEDURE ................
15
4.1.1 System Elements ........................
15
4.1.2 Operational Elements ...................
15
4.1.3 Software requirements ..................
16
4.2 PRINCIPLES OF VALIDATION ...................
18
4.2.1 Validation Procedure ...................
19
4.2.2 Analysis of an MSGID ...................
28
4.2.3 Main Text Analysis .....................
29
4.3 PRINCIPLES OF MESSAGE SPECIFICATION ........
40
4.3.1 Message Definition .....................
40
4.3.2 Message Description Conversion .........
49
4.3.3 Test and Verification ..................
57
5 IDENTIFIED MODULES .............................
62
5.1 SOFTWARE MODULES ...........................
62
5.1.1 On-Line Software .......................
62
5.1.2 Off-Line Software ......................
64
5.1.3 On-Line Software Modules ...............
67
5.2 HARDWARE MODULES ...........................
72
5.3 PERFORMANCE ................................
72
5.4 COMMERCIALLY AVAILABLE HARDWARE
AND SOFTWARE ...............................
72
5.5 MEASURES TO PREVENT INTENTIONAL
DISRUPTION .................................
73
5.5.1 Tempest Acceptance .....................
74
1 G̲E̲N̲E̲R̲A̲L̲
1.1 I̲N̲T̲R̲O̲D̲U̲C̲T̲I̲O̲N̲
This Filter Specification represents the output of
work package No. 350, Filter Specification, within
the framework of the Security Filter Study, performed
under contract No. FK 8219 between the Air Materiel
Command of the RDAF and Christian Rovsing A/S.
1.2 S̲T̲U̲D̲Y̲ ̲R̲E̲F̲E̲R̲E̲N̲C̲E̲S̲
Master Project Plan
Functional Description, SFS/FD/001
Preliminary Filter Specification, SFS/PFS/001
Functional Analysis, SFS/TN/001
Security Filter Architecture, SFS/TN/002
Configuration Study, SFS/TN/004
1.3 T̲E̲R̲M̲S̲ ̲A̲N̲D̲ ̲A̲B̲B̲R̲E̲V̲I̲A̲T̲I̲O̲N̲S̲
Firmware Software stored in a type of memory
which is readable but not alterable
by the system in question. Such a type
of memory is often referred to as "read-only-memory"
or ROM. For the sake of convenience
the term "software" is used throughout
this document for both software and
firmware except where clear distinction
is necessary.
Message The act of defining the message types,
definition syntax, and contents towards the security
filter support system.
Message A formalized and structured set of
description human-readable data describing the message
types, syntax, and contents, used as
input to the message description converter
of the security filter support system.
Validation The message description when
information converted into machine-readable tables
which can be processed by the validation
program of the security filter. Output
from the message description converter
of the security filter support system.
Validation A set of commensurable data arranged
in
table a string or otherwise serially accessible.
The sum of validation tables constitutes
the validation information.
Support A computer system consisting of hardware
System and software and peripherals, dedicated
to performance of off-line tasks in
support of the operation, maintenance,
and test of security filters. The support
system must be able to simulate an operative
security filter.
OTA
Off-line A feature in connection with
Test Ac- the suppport system enabling the support
celerator system simulating a security filter
to operate at a higher rate than normal
transmission speed.
TDG Test Data Generator
Validation The act of checking a message for
validity.
Message, Legal A message which is allowed to pass
the security filter.
Message, Illegal A message which is not allowed to
pass the security filter.
Message, Validated A message which has been subject
to
validation.
Message, Accepted A message which by the validation
has been found to be legal.
Message, Rejected A message which by the validation
has been found to be illegal.
Message, Logged A rejected message which has been
written onto the logging medium.
Message, Suspended A message which by its type or contents
or otherwise demands operator assisted
validation and hence has been stored
for this purpose.
2 S̲U̲M̲M̲A̲R̲Y̲ ̲O̲F̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
2.1 S̲Y̲S̲T̲E̲M̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
The Security Filter is an electronic device (computer)
placed on a point-to-point communication line connecting
two ADP-systems of unequal security classification,
with
the purpose of filtering the message traffic, i.e.
to withhold messages which for security reasons are
not allowed to pass the subject communication line.
The security filter operates on traffic both ways but
with different filter characteristics.
The messages which shall be withheld are not only those
which are classified higher than the receiving ADP-
system but also messages containing information outside
the receiving system's scope of "need to know".
To achieve this goal it is necessary to provide full
and positive description of this "need to know", so
that the security filter will only allow messages to
pass if they are positively identified as containing
only such information.
Alert
ADP Security ADP
System Filter System
Log
Fundamentally, the security filter is aimed at automated
operation without any human intervention. This requires,
however, that the traffic consists solely of well structured
messages with a predictable set of contents. If the
traffic on a line is expected to also contain unstructured
messages or free text, which cannot be automatically
analyzed, human support may be introduced as an option.
Even though the concept of a security filter originally
is aiming at a separate filter for each point-to-point
line it may be considered to develop a multiline security
filter, or to share hardware, software, or peripherals
among a number of security filters, to achieve cost
effective operation. The design of such a multiline
system would need to provide for the additional security
required to keep messages separate and to ensure their
proper delivery.
2.2 S̲Y̲S̲T̲E̲M̲ ̲F̲U̲N̲C̲T̲I̲O̲N̲S̲
2.2.1 F̲i̲l̲t̲e̲r̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The filter characteristics are implemented by means
of a definition of all legal messages and their contents.
The security filter software (computer programs) shall
be so constructed that any foreseeable change in message
structure and contents can be handled without modification
of the software.
As a consequence of the definition of all legal traffic,
any message traffic deviating from the definition shall
be considered illegal and handled in accordance with
that condition.
Illegal messages shall be logged by the security filter
and may not be transmitted from the filter. In case
of frequent traffic of illegal messages (frequency
exceeding a prespecified maximum) an audible alert
shall be sounded in order to inform the security officer
of this fact.
To expand the useful scope of the security filter to
encompass lines where the traffic will contain messages
too complex for automatic validation operator communication
facilities can be added. This will allow for human
validation of for instance free text messages. However,
message types or message contents demanding human validation
shall be defined to the filter. The display of a message
for an operator must never be triggered by the fact
that the message is considered illegal by the automatic
validation.
2.2.2 A̲u̲x̲i̲l̲i̲a̲r̲y̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The security filter shall be operative without any
human intervention, and it shall be possible to modify
neither software nor messages on site while the filter
operates.
Hence, any authorized modification must be performed
off-line and installed afterwards on the filter site
following a prespecified procedure.
The following auxiliary functions to be performed off-line
have been identified:
2.2.2.1 S̲o̲f̲t̲w̲a̲r̲e̲ ̲P̲r̲o̲d̲u̲c̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲
The computer programs necessary to perform the security
filter functions must be analyzed, planned, documented,
coded, compiled, tested and verified.
Since the security filter by itself is not applied
with the peripheral equipment necessary for those purposes,
the program development tasks must be performed utilizing
other hardware.
Although the aim is to produce flexible programs able
to handle all present and future legal message traffic,
the possibility exists that a future expansion or modification
not anticipated during the development period will
appear. Accordingly the software production system
ought to be retained for possible future maintenance.
2.2.2.2 D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲ ̲o̲f̲ ̲L̲e̲g̲a̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
The filter function is based on computer programs of
stable character, which use a set of legal message
descriptions to judge the legality of any message transmitted
through the filter. The definition of legal messages
may vary from time to time and among the various security
filter sites.
In connection with the installation and start of a
security filter, and in connection with authorized
subsequent modifications, a system must be present
which can convert the man-made message descriptions
into computer-legible validation information (in the
form of tables built to fulfil the structure requirements
of the security filter software).
This conversion task must be performed on a computer
distinct from the subject security filter, preferably
on the computer system referred to as the Security
Filter Support System.
2.2.2.3 T̲e̲s̲t̲ ̲a̲n̲d̲ ̲V̲e̲r̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
Whenever modifications have been made in the set of
legal messages for a security filter site the modified
part of the validation information shall be thoroughly
tested to ensure that it is cooperating correctly with
the security filter software.
The testing shall be sufficient to render probable
beyond any reasonable doubt that the security filter
will allow only legal messages to pass.
The validation of the modified message description
will be tested through a combination of analysis and
machine testing.
2.2.2.4 T̲e̲s̲t̲ ̲M̲a̲t̲e̲r̲i̲a̲l̲ ̲P̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
To ensure thorough testing a considerable amount of
test material (test messages) must be produced. The
quality of the test material is measured not only by
its quantity but also by the variety, by which various
constraints are tested.
A computerized test data generator will greatly enhance
the test material production.
2.2.2.5 L̲o̲g̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲
The logged illegal messages will be subject to analysis
by security or ADP personnel. This analysis must take
place away from the filter site, and thus the logging
medium must be exchanged and carried to an off-line
display or print station, where the scrutiny of the
illegal messages can be performed.
The exchange of logging medium must be subject to control
by authorized personnel. The logging medium must not
be removed by unauthorized personnel. The removal shall
be governed by restrictions very much like those imposed
on the exchange of validation information.
The software necessary to read and display the logged
messages is expected to be already existing. Hence,
it is not part of the security filter system development.
2.2.2.6 E̲x̲c̲h̲a̲n̲g̲e̲ ̲o̲f̲ ̲V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲
When new or modified legal messages have been defined
and converted into validation information, an exchange
of validation information must take place in the operative
security filter. The procedure to be followed by the
exchange depends on the medium of storage and the ease
of transport from the production and test facility
to the security filter site.
The exchange must be carried out by or under surveillance
of authorized personnel. The procedure may be varying
in accordance with local circumstances but it must
always be approved by the security authorities.
Precautions shall be taken to ensure that any unauthorized
attempt to change or alter the validation information
will result in an immediate break of the security filter
operation. This break shall be repairable only after
an action by an authorized person.
2.2.2.7 S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
Collection of statistics information is an option.
If this option is chosen it must be ensured that the
collection of statistics information does in no way
degrade the capacity or speed of the security filter,
and the message traffic may in no way be influenced
by the task.
Furthermore, it must be ensured that the collected
statistics information is securely stored and kept
safe from unauthorized eyes, very much like the procedures
for the validation information.
Interpretation of eventual statistics must be performed
off-line.
2.3 A̲C̲C̲U̲R̲A̲C̲Y̲ ̲A̲N̲D̲ ̲V̲A̲L̲I̲D̲I̲T̲Y̲
The security filter system is based in principle on
absolute accuracy and validity. This means that no
tolerance whatsoever will be accepted.
The validation information shall describe unambiguously
to the filter software which items are to be checked
and how. Also, if certain items are not subject to
checking, it shall be clearly and unambiguously stated,
how such items are recognised and delimited.
If a message does not match exactly and in every item
to be checked with the validation information for the
subject message it shall be declared illegal, logged,
and not transmitted.
For a security filter fitted with operator communica-
tion facilities the same rules apply. Human validation
of a message may only be performed if it is prescribed
in the validation information, and the human validation
does only encompass those parts of the message which
are prespecified for it.
All other parts of the message will be subject to normal
automatic validation. Thus, a message may be declared
illegal even if the operator (security admini-
strator) has declared it legal.
2.4 T̲I̲M̲I̲N̲G̲
The security filter shall operate continuously and
be transparent to the communicating ADP systems. The
only delay accepted in the transmission time plus a
maximum of 5 seconds. For messages suspended for human
valida-
tion on an operator assisted security filter a longer
delay cannot be avoided.
3 E̲N̲V̲I̲R̲O̲N̲M̲EN̲T̲
The security filter is supposed to receive and transmit
messages in accordance with the X-25 Protocol (CCITT
Recommendation) at a rate of 2400 band.
The security filter shall be installed in a controlled
area equivalent to the area of system high.
Otherwise the security filter shall be environment
independent.
4̲ ̲ ̲D̲E̲S̲I̲G̲N̲ ̲D̲E̲T̲A̲I̲L̲S̲
4.1 G̲E̲N̲E̲R̲A̲L̲ ̲O̲P̲E̲R̲A̲T̲I̲N̲G̲ ̲P̲R̲O̲C̲E̲D̲U̲R̲E̲
4.1.1 S̲y̲s̲t̲e̲m̲ ̲E̲l̲e̲m̲e̲n̲t̲s̲
The security filter system elements are separated into
operational elements and auxiliary elements.
The operational elements of the system are those adhering
to the operational security filter site perfor-
ming the filtering tasks etc.
The auxiliary elements of the system are those performed
off-line with the purpose of preparing software and
validation information for the operational security
filter sites, and processing the logged output from
the filter sites.
This chapter contains a design concept for a complete
security filter software system emphasizing mainly
on
- Principles of Validation,
- Message Definition, and
- Message Description Conversion
which are considered the three most important parts
of the security filter system from a design point of
view.
Other functions which must be included in the filter
software, such as logging facility, alert mechanism,
etc., are only briefly mentioned since they are rather
easily implemented using commonly known methods, that
may vary slightly depending on the hardware and system
software chosen.
4.1.2 O̲p̲e̲r̲a̲t̲i̲o̲n̲a̲l̲ ̲E̲l̲e̲m̲e̲n̲t̲s̲
The operational elements of the security filter system
encompasses the tasks performed at the operational
security filter system site. Those functions are in
principle running in an unattended mode and should
be transparent to the communication ADP systems.
The software used on a computer is generally separated
into an operating system (system software) and some
dedicated computer programs (application software).
This separation is used partly to facilitate ease of
application programming, partly to ensure that errors
in application programs do not jeopardize system files
and simultaneous data processing on the same computer.
In the security filter system, however, file handling
and system control and other tasks normally performed
by the system software, is minimized, and the requirements
for error free application software are extremely high.
Hence, the separation between system software and application
software is not essential. It must be very much depending
on the hardware solution eventually chosen.
Only is it essential to ensure a high degree of modularity
of the software and a perfect interaction between software
modules. For all that is to it, all software could
be either system software or application software.
4.1.3 S̲o̲f̲t̲w̲a̲r̲e̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲
4.1.3.1 O̲p̲e̲r̲a̲t̲i̲n̲g̲ ̲S̲y̲s̲t̲e̲m̲
Most computer systems have a distinction between the
Operating System (or System Software) and the Application
Software.
The operating system will often operate in privileged
mode, and the application software will operate in
a somewhat restricted mode, sometimes called program
mode.
Some critical operations, such as system control and
input/output control can only be involved by the operating
system, because the instructions for such operations
are so-called "privileged" instruction.
The reason for this distinction is that the operating
system is a hardware dependent piece of software, developed
to aid application programmers and to a certain extent
make applications hardware independent.
Also, the operating is considered failsafe and in most
cases it really is close to bug-less.
In the security filter, however, the requirements for
fail-safety and buglessness are equally high for the
application software as they are for the operating
system.
The necessary features of the operating system are
very few in comparison with an ordinary computer system.
The security filter shall not contain any un-used and
superfluous features, since any feature within the
security filter shall be verified to fulfil a requirement.
Accordingly, the distinction between system software
and application software is superfluous, and all the
necessary software for the security filter system may
as well be coded as one unit for each processor in
the privileged mode.
The Operating System modules identified as necessary
are:
- initial program loader
- system control interface
- log tape handler
- terminal handler
Those few Operating System modules may be coded separately
for the security filter system, or they may be derived
from an existing operating system, if possible.
4.1.3.2 F̲i̲l̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲S̲y̲s̲t̲e̲m̲s̲
The security filter does only have one external file
to handle: the log file. This file is suggested to
be a magnetic tape file of the casette deck type. Accordingly
it must be a sequential, write-only file with variable
length record.
The only security feature required is the tape station
being installed within the security filter casing.
Then it will automatically be locked away from unauthorized
use, and at the same time be TEMPEST shielded.
4.1.3.3 C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲L̲i̲n̲e̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲
The communication lines are supposed to use the X.25
protocol, and the protocol handling, including handshaking,
unwrapping, serial-to-parallel conversion and vice
versa, etc., is supposed to be handled by a standard
communication line interface module.
4.1.3.4 D̲i̲s̲p̲l̲a̲y̲ ̲T̲e̲r̲m̲i̲n̲a̲l̲ ̲a̲n̲d̲ ̲K̲e̲y̲b̲o̲a̲r̲d̲
In order to facilitate operator assisted validation
of suspended messages a visual display unit (VDU) must
be present.
Ideally such a terminal is controlled wholly by the
security filter, which means that a screen picture
is built by the security filter and sent to the screen,
and a possible input from the keyboard is sent to the
security filter and interpreted by the security filter
software before any action is taken, also regarding
the screen picture.
If, however, it can be assured that changes of the
message in the VDU memory and on the VDU screen can
be avoided, the simple tasks of screen picture editing,
scrolling, etc., can be left to a built in processor.
Anyhow, the security filter shall accept only simple
codes from the keyboard, annotating the acceptance
or rejection of the message.
4.2 P̲R̲I̲N̲C̲I̲P̲L̲E̲S̲ ̲O̲F̲ ̲V̲A̲L̲I̲D̲A̲T̲I̲O̲N̲
The principles of validation is based on a hierarchical
structure. The major attributes of a message is checked
first, and subsequently checks are performed to examine
the message in even more detail.
The security filter must contain one or more sets of
validation information. One set of validation information
covers solely the message traffic from one sender to
one receiver. Considering that traffic normally is
passing both ways between two ADP systems, even a single-line
security filter must accommodate two sets of validation
information.
Based on the addresses of the sender and the receiver
the security filter must first choose the correct set
of validation information, and this set and no other
set of validation information must be accessed through
the entire task of validation.
The primary attribute to check is the message type.
This is absolutely necessary since the message type
is determining which checks to perform on the message.
Since the receiving transmission processor seems to
have ample time, and since it already handles the protocol
and other formal matters around the trans-
mission, it stands to reason to let it also locate
and mark the message type. Furthermore, it can make
a break-
down of the message where a such break-down is useful.
For instance, it can make a list of the relative addresses
of the slashes and double slashes (field markers and
end-of-set markers) of an A Dat P3 type message.
4.2.1 V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲
4.2.1.1 C̲h̲e̲c̲k̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲T̲y̲p̲e̲
The validation of a message starts with a check of
the message type. The code for message type should
be bound in the message header (this is a prerequisite,
it has not been confirmed yet).
The message type code is used as a key for a look-up
in a message type table. (See figure 4-1). If the end-of-table-marker
is reached without finding a match between the message
type code of the message and one of the entries in
the message type table, it is revealed that the incoming
message is of a type unknown to the security filter
site. Hence, action shall be taken as described in
"Revelation of and Illegal Message".
If, however, a match is found in the table, the corresponding
message type address shall be used for further processing.
4.2.1.2 C̲h̲e̲c̲k̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲T̲y̲p̲e̲ ̲F̲o̲r̲m̲a̲t̲
The message type address read in the Message Type Table
will point at a Message Type "X" Table, and the Validation
Program code will determine which path of the Validation
program shall be followed.
Throughout thus description the A Dat P-3 type message
is referred, since that type is the only presently
known to the study team. All other message types will
be handled in a similar or simpler way.
Consider, this, that it has been determined that the
actual message is of the A Dat P-3 type, and the Message
Type "X" Table actually pointed at by the address from
the Message Type Table, is the Message Type "A Dat
P-3" Table, and the corresponding validation program
code leads to the process validating the A Dat P-3
type messages.
(Other message types may be much simpler than the A
Dat P-3 type. Hence both the program and the table
structure may be much simpler).
The A Dat P-3 type message is a humanly legible message
consisting of numeric, alphabetic, and special characters
grouped to words, numbers, codes, etc., and separated
into fields and sets, resembling words and sentences
in a predefined pattern.
A set ("sentence") has a syntax where the relative
position (sequence) of a field determines the relative
meaning of the content of the field.
A field ("word") may hence contain a numeric value,
an alphabetic value, a (set of) special character(s),
or any combination thereof, depending on what the field
is supposed to express.
All sets and fields are in principle of variable length.
They are delimited by "end-of-set markers" and "field
markers".
4.2.1.3 C̲h̲e̲c̲k̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲I̲d̲e̲n̲t̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
Within the text part of the message the set identifier
"MSGID" is located. It shall be immediately followed
by a field marker (a slash, "/") which is followed
by the message identification (here referred to as
"msgid" written in lower case letters). The "msgid"
is a word of 3 through 8 letters and it is followed
by another field marker.
The "msgid" of the message is isolated and used as
a key for a look-up in the message type "A Dat P-3"
table. If the end-of-table marker i reached without
finding a match between the "msgid" and one of the
entries in the message type "A Dat P-3" table it is
revealed that the message has an identification unknown
to the security filter site. Hence, action shall be
taken as described in "Revelation of an Illegal Message".
If a match is found in the table, the corresponding
Msgid Address shall be used for further processing.
4.2.1.4 B̲r̲e̲a̲k̲d̲o̲w̲n̲ ̲o̲f̲ ̲a̲n̲ ̲A̲ ̲D̲a̲t̲ ̲P̲-̲3̲ ̲T̲y̲p̲e̲ ̲M̲e̲s̲s̲a̲g̲e̲
In order to facilitate the validation of an A Dat P-3
type message a breakdown can be performed. A breakdown
shall not physically touch the message but is rather
the building of a couple of address tables to follow
the message.
The breakdown can be performed by any processor operating
on the message, and it is not necessary to wait until
the validation starts.
The breakdown tables consist of two tables:
one containing the addresses of the end-of-set markers,
one containing the addresses of the field markers.
(See figure 4-3).
The addresses stored in the breakdown tables must be
relative addresses (relative to the start of the message).
The breakdown tables are used to easily locate the
distinct sets and fields of the messages, and - by
simple calculation - to determine the lengths of the
same items.
4.2.2 A̲n̲a̲l̲y̲s̲i̲s̲ ̲o̲f̲ ̲a̲n̲ ̲M̲S̲G̲I̲D̲
4.2.2.1 I̲n̲t̲r̲o̲d̲u̲c̲t̲o̲r̲y̲ ̲T̲e̲x̲t̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲
The Msgid Address of the Message Type "A Dat P-3" Table
points at an MSGID "X" table (see figure 4-4), where
the "X" stands for the "msgid" of the message in question.
Since the security classification and the subject indicator
code(s) (SIC) of a message do not adhere to the normal
set-and-field syntax of an A Dat P-3 type message these
two "lines" of the message must be given special attention.
(The security classification and the subject indicator
code is also called the "introductory text" to distinguish
it from the "main text").
The security classification consists of a classification
statement (e.g. NATO CONFIDENTIAL) which may be followed
by a space and a special handling designator (e.g.
ATOMAL).
It seems to be most feasible to define centrally the
possible security classifications. (Store in a table
common to the entire security filter site all security
classifications that may be used within the filter
site in the direction in question).
Having those security classifications identified by
their relative positions will minimize the necessity
for entries in the MSGID "X" Table to a string as many
bits long as the number of allowed security classifi-
cations in the filter. For the single message id the
bits corresponding to allowed security classifications
could be set to ones, and bits corresponding to not
allowed security classifications set to zeroes.
The subject indicator codes must be listed one by one.
In the message they can be located by searching for
the word "SIC". This word is followed by a space character
and a three letter abbreviated subject indicator code.
This subject indicator code must be found in the list
in the table. If a message contains more than one subject
indicator code each but the last one of them is followed
by a field marker (slash, "/"). All subject indicator
codes must be checked and found in the SIC list in
the MSGID "X" Table.
If the security classification or the subject indicator
codes do not match the information found by means of
the table, the message shall be considered illegal
and action shall be taken as described in "Revelation
of an Illegal Message".
The entries in the MSGID "X" Table for the Introductory
Text will be in a firm fixed format.
4.2.3 M̲a̲i̲n̲ ̲T̲e̲x̲t̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲
4.2.3.1 T̲e̲x̲t̲ ̲S̲e̲t̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲
Following the entries for the introductory text the
MSGID "X" Table will contain a number of SET entries
corresponding to the number of allowed, differently
named sets within the message (see figure 4-4).
Each set entry is identified by a set identifier, in
the figure represented by "SET 1", "SET 2", etc. The
set identifier (SETID) corresponds to the identifier
placed in front of a set within the message.
The first set of the main text is placed immediately
after the SICs (Subject Indicator Codes).
The following sets will be located immediately after
each end-of-set marker except the last one, which marks
the end of message. Hence, all but the first set can
be located using the A Dat P-3 Breakdown Table, see
figure 4-3.
4.2.3.2 M̲O̲C̲ ̲C̲o̲d̲e̲
The next entry in the table entity is the MOC code
(Mandatory/Optional/Conditional).
This code can be
O set is optional, may or may not
be present in one or multiple
appearances
M set is mandatory and shall appear
one or multiple times
C conditional. See conditions.
Other codes may be defined
4.2.3.3 C̲o̲n̲d̲i̲t̲i̲o̲n̲ ̲C̲o̲d̲e̲
The condition code is only applicable for sets which
are conditional ("C" in MOC code).
The condition may be either "mandatory while X" or
"not allowed while X", where X is the presence of another
set.
The condition can be described in the following way:
If SET2 shall be present while SET1 is present the
entry for SET1 can contain in the condition code field:
+ SET2
If SET1 and SET2 are mutually inclusive (when one of
them in present, the other must also be present) also
the entry for SET2 must contain in its condition code
field:
+ SET1.
If SET2 may be present whether or not SET1 is present
but it shall be present if SET1 is present, only the
entry for SET1 must contain the condition code.
If the presence of SET1 forbids the presence of SET2,
the SET1 condition code field must contain -SET2.
Rules for mutual exclusiveness follow the rules described
above.
4.2.3.4 S̲e̲g̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
Part of a message may be segmented. This means that
a number of sets form a segment which may be repeated.
If a set is part of a segment this must be marked by
a code in the SEGM field of the table entry for the
set. The same code must appear in each set belonging
to one segment, e.g. S1.
If a set forms part of a segment the condition codes
apply within each segment.
4.2.3.5 F̲i̲e̲l̲d̲ ̲T̲a̲b̲l̲e̲ ̲A̲d̲d̲r̲e̲s̲s̲
Finally the MSGID "X" Table shall contain the address
of a Field Table.
4.2.3.6 S̲e̲t̲ ̲L̲e̲v̲e̲l̲ ̲V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲
The set level validation must be performed using the
MSGID "X" Table.
Using each set entry in the table the sets of the message
are scanned. During this scanning it must be checked
that the message does not contain sets not specified
in the table. In case an unspecified set is identified
the message shall be considered illegal and action
shall be taken as described in "Revelation of an Illegal
Message".
Each set specified in the table is searched in the
message. If the table specifies the set to be mandatory
it shall be found. If the condition code for an existing
set demands the presence of another set, the presence
of that other set shall be checked immediately. If
the condition code demanding the presence of another
set appears within a segment, i.e. prior to a new appearance
of the first set.
The check for fulfilment of conditions shall be performed
in one level only at the time. (Multilevel conditions
will be checked eventually when the subsequent sets
are checked).
When the set level validation has been performed it
has been verified that:
- all required sets are present
- all present sets are specified
and allowed
If any of the checks fails the message shall be considered
illegal and action shall be taken as described in "Revelation
of an Illegal Message".
When the set level validation has come to an end the
field level validation is invoked.
4.2.3.7 F̲i̲e̲l̲d̲ ̲L̲e̲v̲e̲l̲ ̲V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲
When the set level validation is brought to an end
the field level validation can commence.
The message is validated starting with the first set
and validating the fields of each set until the messages
are exhausted.
The set identifier is used to find the set description
in the MSGID "X" Table (see figure 4-4). The field
table address of this table is used to locate the field
table for each set. The field table (see figure 4-5)
describes the fields of a set in their order of appearance.
A field or a group of fields of a set may be repeated
provided that it/they form the end of the set.
For each field of the set the field table contains
a number of entries. One of them is the Validation
Type. The validation type is a code that determines
which part of the validation program shall be used
for the field in question. Various types can be used,
and a number of them will be described here. This description
does not attempt to be exhaustive since not all types
of validation are thoroughly described to the study
team. For the eventual implementation of a security
filter it is, however, crucial that all types are unambiguously
described and that no superfluous routines exist.
4.2.3.8 F̲i̲e̲l̲d̲ ̲V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ ̲T̲y̲p̲e̲s̲
A number of various types of field constraints has
been identified. In order to ensure that all constraints
are adequately fulfilled an equally varied number of
checks must be performed.
The checking types identified are:
List of specific data (Data List)
Within certain limits (Range)
Special check (Complex Structure)
Suspend for human validation
The data list checking is performed by comparing the
content of a field with each entry of a list of all
legal data for this field.
The range checking is performed by comparing the content
of a field with one or more pairs of lower and upper
limits for legal values. This type seems most useful
for numeric values.
The complex structure checking refers to fields the
contents of which are a combination of fixed and varying
parts.
Certain very complex or undefined structures can be
suspended for human validation if the security filter
is equipped with operator communication equipment (see
"Suspension").
In the definitions of fields (when originally defining
messages) certain attention is paid to the length of
fields and to the composition of their contents. Such
definitions are of less importance when checking a
message for legality. If, for instance, the legal contents
of a field is "A17", "B8" or "CK15" it is quite obviously
of no concern that the length is 2-4 characters, and
that the syntax is one or two alphabetic characters
followed by one or two numeric characters.
A field is considered the characters starting immediately
after a field marker and ending immediately before
the next field marker or end-of-set marker. The length
of the field with the three forementioned examples
will then be 3, 2 and 4. If the field is expanded to
its maximum length of four in the two first cases it
will be illegal since it will then contain one or two
space characters, which are not described in the legal
contents.
In few - if any - occasions will the syntax be of great
interest, since it is the semantics which set the legality
or illegality of the content of the field.
4.2.3.9 L̲i̲s̲t̲ ̲o̲f̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲ ̲D̲a̲t̲a̲
If - as mentioned above - the legal contents can be
listed as a number of specific values the validation
can be performed by comparing the actual content of
a field with each item in a list of all legal possibilities.
This can be done by using a Data Address field in the
Field Table (figure 4-5) which points at a Data Address
Table (see figure 4-6, left part) in which each entry
is an address pointing at an item in a data list (see
figure 4-6, right part). The length of each item in
the data list is determined by subtracting the address
from the next address.
4.2.3.10 W̲i̲t̲h̲i̲n̲ ̲C̲e̲r̲t̲a̲i̲n̲ ̲L̲i̲m̲i̲t̲s̲
If the legal content of a field can be described as
being within a certain range it is possible to perform
the validation by comparison of the actual content
of the field with an upper limit and a lower limit.
A such range check is most conveniently used on numeric
values.
When a range check is performed on numeric values a
length check must also be performed since a superfluous
amount of zeroes (leading zeroes or tailing zeroes
after a decimal point) could be an information carrier.
If the range check is performed on integer values all
characters must be numeric (0-9), and the range can
be given as an upper and a lower limit. If the integer
may be positive or negative it must be specified which
signs are legal, and whether the signs are used as
prefixes or suffixes to the figure.
If broken numbers are allowed it must be clearly stated
how they must be represented. If a decimal number is
presented with a fixed decimal point not shown, the
field can be handled as if it was an integer.
The limits are stored in the Data Address Table (see
figure 4-6) in the same way as for lists of specific
data. The limits are stored as pairs. If more than
one range is legal, additional pairs of limits can
be stored quite easily.
Thus, the only difference seen in the Field Table (figure
4-5)
between data list type fields and range type fields
is the validation type.
4.2.3.11 S̲p̲e̲c̲i̲a̲l̲ ̲C̲h̲e̲c̲k̲s̲
The constraint imposed upon the legal contents of fields
can be various. On the preceding pages are discussed
the use of a limited number of exactly specified values
(words etc.) and a range within certain limits.
Certain combinations of those ways of constraining
the legal contents are also anticipated. Such combinations
are handled by what is here referred as special checks.
Special checks encompass such complex structures as
date-
time groups, geographical positions, etc.
4.2.3.12 D̲a̲t̲e̲ ̲T̲i̲m̲e̲ ̲G̲r̲o̲u̲p̲ ̲(̲D̲T̲G̲)̲
A Date Time Group (DTG) normally consists of 6 numeric
characters and one alphabetic character. The first
two numeric characters specify the day of month (01-31),
the next two numeric characters specify the hour (00-24),
and the last two numeric characters specify the minute
(00-59). The alphabetic character specifies the time
zone (A-Z).
To check the validity of such a complex structure it
is necessary to perform a number of comparisons.
a) The six numeric characters seen as a whole must
be within the limits 010000 and 312400.
b) The four rightmost numeric characters seen as a
whole must be within the limits 0000 and 2400.
c) The two rightmost numeric characters seen as a
whole must be within the limits 00-59.
d) The alphabetic character must be one of the valid
time zone designators.
In addition to the normal DTG may in some cases be
added a space character and a three letter abbreviation
for the month.
In such cases it must also be checked that the three
letter abbreviation is one of the legal month name
abbreviations, and in addition it can be checked that
the day of month does not exceed the number of days
in months with less than 31 days.
Furthermore, there is a possibility of adding the year
of century (00-99). In such cases also the exact number
of days of February may be checked.
All these checks may seem very simple repetitions of
ordinary data list checks and range checks but in order
to keep the routines "clean" it is advisable to implement
a special routine for the DTG block. By keeping the
routines clean is meant that the standard routines
operate on entire fields (from a field marker to the
next field marker or end-of-set marker).
4.2.3.13 G̲e̲o̲g̲r̲a̲p̲h̲i̲c̲a̲l̲ ̲P̲o̲s̲i̲t̲i̲o̲n̲
Another type of special check is a geographical position.
A such position can be given as a latitudinal value
followed by a longitudinal value. In the most precise
form it includes degrees, minutes and seconds, e.g.
421530N - 0152610E
When defining a larger area the seconds may be omitted,
e.g.
4215N - 01526E
(The possibility of even more variations is not investigated,
but it is not excluded).
Analoguous to what is described above for the date-time-group
this complex structure must be validated in a special
routine which is able to handle all viariations allowed.
4.2.3.14 O̲t̲h̲e̲r̲ ̲S̲p̲e̲c̲i̲a̲l̲ ̲C̲h̲e̲c̲k̲s̲
By a thorough analysis of the fields defined for transmission
on filtered lines it must be anticipated that other
types of special checks will be found possible.
4.2.3.15 R̲e̲v̲e̲l̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲a̲n̲ ̲I̲l̲l̲e̲g̲a̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲
Whenever, during the validation, the program fails
to find a match between an item of the message to be
validated and the proper set of validation information,
or the message is returned from suspension without
the proper acceptance flag(s), the message shall be
considered illegal and it shall be rejected.
The mismatch may be found in any of the various checks:
a missing mandatory set; the presence of a set excluded
by the presence of another set; improper length or
content of a field; or whatever syntactical or semantie
error that might be found.
When a message is rejected the following steps shall
be taken:
- The message shall be logged
- The frequency of illegal messages shall be calculated
- If this frequency exceeds the specified maximum,
the alert shall be sounded
- All buffer and memory areas containing (parts of)
the message shall be erased.
All these steps are rather primitive of nature. Their
implementation will be dependent of the hardware ultimately
delivered, and it is left to the bidders to describe
ways and means to ensure their secure functions.
4.2.3.16 S̲u̲s̲p̲e̲n̲s̲i̲o̲n̲ ̲o̲f̲ ̲a̲ ̲M̲e̲s̲s̲a̲g̲e̲
One of the validation types described in paragraph
4.2.3.8 is "suspend for human validation".
This validation type can be used for a field, the legal
contents of which is of a character which makes it
impossible or impractical to prespecify it when defining
the legal message. An example is a free text field.
The suspension for human validation may be used only
on the provision that the security filter site in question
is equipped with operator communication equipment,
e.g. a visual display unit.
Even though only one single field or a small number
of fields shall be subject to human validation, the
whole message shall be available for the operator,
if applicable by forward and backward scrolling. The
reason for this is that the legality of the contents
of the fields to be humanly validated may be depending
on the context.
Prior to the suspension the entire message shall be
searched for fields for human validation in order to
have all fields validated within one suspension.
When displaying the message to the operator, fields
to be validated shall be clearly marked, e.g. by highlighting
(high intensity light). The operator shall have no
means to alter neither the message as stored in memory,
nor as displayed on the screen, except that he may
switch off the highlighting by pressing one of the
two keys to either accept or reject the message.
The operator's accept of a field shall raise a flag
for subsequent checking by the computer.
The operator's rejection of one single field shall
trigger the immediate transfer of control to the computer
to reject the message as being illegal.
4.3 P̲R̲I̲N̲C̲I̲P̲L̲E̲S̲ ̲O̲F̲ ̲M̲E̲S̲S̲A̲G̲E̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
The auxiliary elements of the security filter encompass
the tasks performed off-line in order to support the
operational security filter.
Though these tasks are performed off-line, aperiodically,
and possibly far away from the security filter sites
they are very essential to the filter operation, and
the same demand for care and precision applies to the
auxiliary functions as to the operational security
filter functions.
In this chapter is emphasized mainly on the definition
of legal messages and the conversion of the definitions
into validation information tables.
4.3.1 M̲e̲s̲s̲a̲g̲e̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
The filter function in the security filter is based
on complete "knowledge" about the legal contents of
a message stored in the filter.
Hence, the legal messages must be specified very carefully
and in a structured way so that it is possible for
the security filter software to compare an actual message
with the set of information stored in the filter itself.
To achieve this goal the following chain of actions
must be performed:
- Describe a legal message and all possible legal
contents plus interrelationship of contents.
- Define these descriptions in a formal, structured
way, useful as computer input.
- Let an off-line computer convert this input into
well-structured table information.
- Store the converted validation information in adequate
memory.
- Mount the storage medium in the security filter.
4.3.1.2 D̲e̲s̲c̲r̲i̲b̲e̲ ̲a̲ ̲M̲e̲s̲s̲a̲g̲e̲
Existing regulations already give rules and advice
for the description of a new message. These rules must
of course be obeyed, and they help to get very close
to the goal.
Though the existing procedures are fully sufficient
to ensure consistency and obeyance of security regulations
in a human environment, it must be a little refined
in certain points when it comes to automated handling
in a computer environment.
For instance, for a certain field it may be defined
(today) that it may contain "an item from the x list...".
When defining this it is implied that
a. the operator preparing the message knows the x-list
or has access to it,
b. only such items from the list which are applicable,
will be used.
In a definition to the security filter it must be explicitly
stated which items are legal at the filter in question.
Accordingly, either the total list must be defined
in extenso, or a subset including those items which
are legal at the security filter in question.
4.3.1.3 F̲o̲r̲m̲a̲l̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
In order to ensure correct conversion of the Legal
Message Description the definition must be performed
in a rather formalized way. Various approaches are
feasible, but taking into consideration the complexity
of ADat P-3 messages and the anticipated frequency
of modifications the following approach is suggested
(although details may be altered in accordance with
the ultimate solution).
A number of preprinted forms are used to specify the
details of a message, a set, and a field. Sketches
for the following forms are shown:
Message Definition Form, figure 4.2.4-1
Set Definition Form, figure 4.2.4-2
Field Definition Form, figure 4.2.4-3
On the sketches the forms are made up with a common
header and footer.
The header is used for identification and sorting sequence.
The footer is meant as an illustration of the approval
procedure. It may be quite different from the boxes
shown but the main idea is that every single sheet
of the definition must be approved in some way before
it is input into the message description converter.
4.3.1.4 M̲e̲s̲s̲a̲g̲e̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲ ̲F̲o̲r̲m̲
The message definition form as sketched in figure 4.3.1-1
must be filled in in accordance with the following
rules:
- S̲e̲c̲u̲r̲i̲t̲y̲ ̲F̲i̲l̲t̲e̲r̲ ̲S̲i̲t̲e̲ must contain an identification
of the site and the direction in which the message
shall be legal. The "name" or "title" of the security
filter site could be a combination of the "names"
of the sending and receiving ADP systems.
- M̲e̲s̲s̲a̲g̲e̲ ̲I̲d̲ field must contain the MSGID of the
message, left adjusted in the field. If the MSGID
is shorter than 8 characters the remaining characters
of the box shall be left blank.
- S̲e̲t̲ ̲I̲d̲, S̲e̲t̲ ̲N̲o̲, and F̲i̲e̲l̲d̲ ̲N̲o̲ contain pre-printed
zeroes since they are not applicable on this form.
- P̲a̲g̲e̲ shall only be used if a definition is too
voluminous to be accommodated on one page. When
more than one page is used the pages must be paginated
in ascending sequence.
- S̲e̲c̲u̲r̲i̲t̲y̲ ̲C̲l̲a̲s̲s̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ must contain the highest
allowed security classification spelled out exactly
as used in the message. Must be left adjusted.
- S̲p̲e̲c̲i̲a̲l̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ must contain (if applicable) the
special handling designator used in the message
and spelled likewise. Must be left adjusted.
- S̲u̲b̲j̲e̲c̲t̲ ̲I̲n̲d̲i̲c̲a̲t̲o̲r̲ ̲C̲o̲d̲e̲ must contain the allowed
subject indicator codes in accordance with the
NASIS instruction.
4.3.1.5 S̲e̲t̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲ ̲F̲o̲r̲m̲
The set definition form as sketched in figure 4.3.1-2
must be filled in in accordance with the following
rules:
- S̲e̲c̲u̲r̲i̲t̲y̲ ̲F̲i̲l̲t̲e̲r̲ ̲S̲i̲t̲e̲ as described above under Message
Definition Form and with the same contents.
- M̲e̲s̲s̲a̲g̲e̲ ̲I̲d̲ as described above under Message Definition
Form and with the same content as the message which
the set forms part of.
- S̲e̲t̲ ̲I̲d̲ must contain the set identifier. If the
set identifier is less than eight characters it
must be left adjusted and the remaining characters
must be left blank.
- S̲e̲t̲ ̲N̲o̲ must contain a number (with leading zeroes)
indicating the sequence in which the sets are supposed
to appear in the message. The box - rather than
the set id - will be used for sorting purposes.
- F̲i̲e̲l̲d̲ ̲N̲o̲ must contain zeroes (Pre-printed).
- P̲a̲g̲e̲ is only used if more than one page is necessary
to describe the set. (See above under Message Description
Form).
- M̲a̲n̲d̲/̲O̲p̲t̲/̲C̲o̲n̲d̲ must contain an "M", an "O", or a
"C", respectively, to indicate whether the set
is mandatory, optional, or conditional.
- C̲o̲n̲d̲i̲t̲i̲o̲n̲ is applicable only if the set is conditional
(a "C" in Mand/Opt/Cond). The condition must be
indicated by a "-", a "+", or a "-+" followed by
the set id of the other set of the condition, as
stated in paragraph 4.3.2.9 Condition Description.
If a condition is not mutual only the set containing
the condition shall be considered conditional.
The other set must be considered optional.
- S̲e̲g̲m̲e̲n̲t̲ is applicable only if the set forms part
of a segment. This box must then contain an arbitrary
code which is repeated in all sets belonging to
the same segment.
- R̲e̲p̲e̲a̲t̲ is applicable only for sets which are repeatable
by themselves, i.e. a set is repeated without other
sets interspersed as the case normally is when
a segment is repeated. If a set is repeatable this
box must contain an "R", otherwise it shall be
left blank.
4.3.1.6 F̲i̲e̲l̲d̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲ ̲F̲o̲r̲m̲
The field definition form as sketched in figure 4.3.1-3
must be filled in for each field of a set in accordance
with the following rules:
- S̲e̲c̲u̲r̲i̲t̲y̲ ̲F̲i̲l̲t̲e̲r̲ ̲S̲i̲t̲e̲ as described above under Message
Definition Form and with the same contents.
- M̲e̲s̲s̲a̲g̲e̲ ̲I̲d̲ as described above under Message Definition
Form and with the same content as the message which
the field forms part of.
- S̲e̲t̲ ̲I̲d̲ as described above under Set Definition
Form. The content must be the set identifier for
the set which the field forms part of.
- S̲e̲t̲ ̲N̲o̲ as described above under Set Definition
Form. The content must be the set number of the
set which the field forms part of.
- F̲i̲e̲l̲d̲ ̲N̲o̲ must contain a number (with leading zeroes)
indicating the sequence in which the fields shall
appear in the set. The field numbers must be in
ascending order within each set.
- P̲a̲g̲e̲ is used if the field description cannot be
accommodated within one single sheet. This will
typically be the case when the list of legal values
is very long.
- M̲a̲n̲d̲/̲O̲p̲t̲ must contain an "M" or an "O", respectively,
to indicate whether a field is mandatory or optional.
- R̲e̲p̲e̲a̲t̲a̲b̲l̲e̲ must contain an "R" if the field is
repeatable (alone or as a member of a group of
fields), and must otherwise be left blank..
- H̲y̲p̲h̲e̲n̲ ̲A̲l̲l̲o̲w̲e̲d̲ must contain an "-" if a hyphen
is legal value for a mandatory field.
- M̲i̲n̲/̲M̲a̲x̲ ̲L̲e̲n̲g̲t̲h̲ is a set of two boxes containing
the minimum length and the maximum length, respectively,
of the field.
- V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ ̲T̲y̲p̲e̲ must contain a code indicating
the type of validation to be performed on this
particular field.
- L̲e̲g̲a̲l̲ ̲V̲a̲l̲u̲e̲s̲ is a set of boxes meant to contain
the list of legal values, if applicable. The first
character of each box is separated from the rest
of the box by a vertical line. This first character
is used to indicate that the rest of the box is
a continuation of the preceding box, which makes
it possible to define legal data string values
longer than one box. One box must not contain more
than one legal value. The first separate character
in the first line will only be used on continuation
sheets where the first line of legal values forms
a continuation of the last line of the preceding
sheet. Any character in the separate character
box will be considered a continuation mark, and
when it is not used as such it shall be left blank,
except when used to avoid repetition of a data
list.
In case several fields within one message have
the same legal contents, i.e. they shall use the
same data list of legal values, repetition of the
data list can be avoided. The first time the common
data list appears in the message definition it
must be written in total. In following field definitions
only a reference to the field definition containing
the data list is necessary. It can be done by putting
an equal sign ("=") into the separate character
box of the first line of legal values, and in the
"legal value" stating the set number and field
number of the field definition containing the data
list. The conversion program shall then use the
Data Address Table Address from that field definition,
thus establishing multiple references to that particular
data list.
SECURITY FILTER SITE
MESSAGE DEFINITION FORM
MESSAGE ID SET ID SET NO FIELD NO PAGE
SECURITY CLASSIFICATION
SPECIAL HANDLING
SUBJECT INDICATOR CODE
DATE TITLE RANK AND NAME SIGNATURE
DEFINED
PROOF READ
APPROVED
AUTHORIZED
FIGURE 4.3.1-1
SECURITY FILTER SITE
SET DEFINITION FORM
MESSAGE ID SET ID SET NO FIELD NO PAGE
MAND/OPT/COND
CONDITION
SEGMENT
REPEAT
DATE TITLE RANK AND NAME SIGNATURE
DEFINED
PROOF READ
APPROVED
AUTHORIZED
FIGURE 4.3.1-2
SECURITY FILTER SITE
FIELD DEFINITION FORM
MESSAGE ID SET ID SET NO FIELD NO PAGE
MAND/OPT
REPEATABLE
HYPHEM ALLOWED
MIN/MAX LENGTH
VALIDATION TYPE
LEGAL VALUES
DATE TITLE RANK AND NAME SIGNATURE
DEFINED
PROOF READ
APPROVED
AUTHORIZED
FIGURE 4.3.1-3
4.3.2 M̲e̲s̲s̲a̲g̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲ ̲C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲
When the legal messages have been defined, the definitions
shall be converted into validation tables, which form
the set of validation information for one security
filter site.
The conversion must be performed by an off-line computer
utilizing a computer program developed for this purpose,
called the Message Description Converter.
The input to the Message Description Converter program
are the Message Descriptions as a result of the Legal
Message Definition (See chapter.....).
The input form must be decided based on local circumstances.
It might be paper tape or floppy disk, or it might
be input direct on a terminal, or using other input
media.
After input the message description (source) must be
stored intermediately, e.g. on a disk storage, and
there ought to be a sort of editing facility in order
to enable corrections of typing errors etc.
If a word processor or another computer with editing
facilities are used for input preparation the necessity
for editing facilities in the message description converter
computer can be avoided.
The first part of the message description converter
must be a "debugger" which checks the syntax of the
message descriptions. The debugger shall read the intermediately
stored message descriptions, print a list of them,
check the syntax, and - in case syntax errors are found
- print error information on the message description
list.
4.3.2.1 L̲e̲g̲a̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
Any message to be allowed to pass a security filter
site shall be defined to that particular security filter
as being legal.
Certain procedures must be laid down to ensure that
a message is legal and authorized as a such. This will
imply the cooperation of authorized personnel from
both of the communicating ADP systems. The exact rules
must be defined by military security authorities and
are out of scope for this specification.
The following must be considered a suggestion of how
the legal message definition can be performed. As is
the rule throughout the specification emphasis has
been laid on the A Dat P-3 type of message, and all
other message types are virtually ignored.
4.3.2.2 O̲v̲e̲r̲a̲l̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲ ̲L̲a̲y̲-̲o̲u̲t̲
The message definition must follow rather strict rules
to ensure adherence to security regulations and enable
a not too complex message description converter program
to perform the conversion into tables.
The philosophy behind this is that the simpler a task,
the more secure a task.
A more complex or sophisticated message description
converter might seem more user friendly, but since
the task of message definition is anticipated to be
rather infrequent it may be expected that few - if
any - persons will ever become really familiar with
such a task.
Furthermore, if preprinted message definition forms
are introduced they may soon show up to be exactly
as user friendly as a very sophisticated interactive
message definition system implemented on a display
unit.
4.3.2.3 D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲ ̲o̲f̲ ̲a̲ ̲M̲e̲s̲s̲a̲g̲e̲
A message must be defined in detail starting with defining
it as belonging to a specific
MESSAGE TYPE
(During the rest of this chapter we are only discussing
messages belonging to the messsage type "A Dat P-3")
When a message is identified as an A Dat P-3 message
the next identification object is the
MESSAGE IDENTIFICATION
which is the name found in the MSGID set of the message.
Subsequently, the message is divided by means of
SET IDENTIFIERS
describing each of the sets of which the message is
composed.
Simultaneously with the division into sets, each set
is divided into
FIELDS.
4.3.2.4 M̲e̲s̲s̲a̲g̲e̲ ̲T̲y̲p̲e̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲
When the message description converter recognizes the
message type (code) it looks up in the Message Type
Table to see if this message type already exists.
If the message type exists in the message type table
the corresponding address of "Message Type "X" Table"
is used to locate the table into which the new message
identifier shall be stored.
If the message type does not already exist, a new entry
is made in the Message Type Table, the end-of-table
marker is moved to the next entry address, adequate
space is located in memory for building a new Message
Type "X" Table, and the validation program type is
found in a table within the Message Description Converter
program. If a validation program cannot be found using
the message type code as a key, an error message is
issued and the preceding actions are backed out.
4.3.2.5 M̲e̲s̲s̲a̲g̲e̲ ̲I̲d̲e̲n̲t̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
Since we are discussing only A Dat P-3 type messages
we are now operating with a located or newly established
Message Type "X" Table unique for the A Dat P-3 type
messages. (See figure 2).
The message identification (MSGID) for the message,
the description of which is being converted, shall
be found in this table. If the message identification
already exists this conversion run must be considered
a modification to an existing message description.
The only difference between a modification and a new
specification is that the old entry in the Message
Type "X" Table can be used with a new address to a
MSGID "X" Table. (See below).
If the message identification does not exist in the
Message Type "X" Table it shall be added, followed
by the address of an adequate storage area, where the
next lower level table in the hierarchy can be located.
The next lower level table is the MSGID "X" Table (see
figure 4), which is unique to this message type and
identification.
The MSGID "X" Table is composed of two distinctive
parts: A fixed part containing information on security
classification and an array part containing set information.
The security classification part consists of a number
of fields (yet undecided) all of which shall contain
either spaces or codes denoting one of the legal security
classifications including special handling designator,
if applicable.
The Subject Indicator Code (SIC) part consists of a
number of fields (yet undefined) all of which shall
contain either space characters or a valid subject
indicator code.
4.3.2.6 A̲r̲r̲a̲y̲ ̲P̲a̲r̲t̲
The array part of the MSGID "X" Table contains set
information, i.e. description of the sets of which
the message shall be composed.
For each set the table shall contain the following
information:
SET IDENTIFIER
MOC CODE
CONDITION DESCRIPTION (if applicable)
SEGMENT RELATIONSHIP (if applicable)
FIELD TABLE ADDRESS
4.3.2.7 S̲e̲t̲ ̲I̲d̲e̲n̲t̲i̲f̲i̲e̲r̲
The set identifier is the first part of a set. It is
a combination of alphabetic and numeric characters
of maximum 8 characters, often combined into a mnemonic
for a description of the set's content.
The set identifier uniquely identifies the set, and
without regard to the message in which it appears it
must be constructed in accordance with overall rules
for that set. In spite of this fact a set must be explicitly
defined toward the security filter for each message
in which it will appear since the legal content of
a set or some of its fields may vary depending on the
message.
4.3.2.8 M̲O̲C̲ ̲C̲o̲d̲e̲
The Mandatory/Optional/Conditional Code (MOC-Code)
must always be specified. If a set is mandatory, then
the message will be illegal if the set is missing.
If a set is conditional also the condition description
must be present, and the condition description must
be checked to see if the set must be present or the
opposite.
4.3.2.9 C̲o̲n̲d̲i̲t̲i̲o̲n̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The condition description is only applicable if the
set is conditional.
The possible conditions adhere to relationship between
sets within a message.
a. The presence of one set demands the presence of
another set
(SETID1 + SETID2)
b. The presence of one set demands the absence of
another set
(SETID1 - SETID2)
c. Condition a may be mutual
(SETID1 + SETID2
SETID2 + SETID1)
(Condition b is automatically mutual)
d. The absence of one set demands the presence of
another set
(SETID1 -+ SETID2)
4.3.2.10 S̲e̲g̲m̲e̲n̲t̲ ̲R̲e̲l̲a̲t̲i̲o̲n̲s̲h̲i̲p̲
The segment relationship must be present if the set
forms part of a segment. The segment relationship is
an arbitrary code chosen for each segment within the
message. It must be the same code used for all sets
of one segment.
If a set forms part of a segment the condition description
will be valid within each set.
If a set contains a segment relationship code which
is not found in another set in the message description,
this means that the set is repeatable in itself.
4.3.2.11 F̲i̲e̲l̲d̲ ̲T̲a̲b̲l̲e̲ ̲A̲d̲d̲r̲e̲s̲s̲
The Field Table Address must be generated as an address
of a memory area where the field address table will
be located.
4.3.2.12 F̲i̲e̲l̲d̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The conversion of the field description must take place
in connection with conversion of the set description
for the set, to which the fields belong.
The fields are identified only by their set identifier
and their relative position within the set (first,
second,.... etc. field within the set).
The field description is placed in a three-level hierarchy
of tables, which are:
FIELD ADDRESS TABLE
DATA ADDRESS TABLE
DATA LIST
4.3.2.13 F̲i̲e̲l̲d̲ ̲A̲d̲d̲r̲e̲s̲s̲ ̲T̲a̲b̲l̲e̲
The upper level table within the field description
is the Field Address Table.
Since the fields are identified only by their relative
position the field address table must refer the fields
in exact the order in which they shall appear within
the set.
The field address table shall contain for each field:
VALIDATION TYPE
DATA ADDRESS TABLE ADDRESS
REPEAT CODE
HYPHEN CODE
MO CODE (I/A)
MINIMUM LENGHT (I/A)
MAXIMUM LENGHT (I/A)
4.3.2.14 V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ ̲T̲y̲p̲e̲
The Validation Type Code refers to the path in the
validation program in which the field shall be checked.
(Data List check, Range check, etc.)
4.3.2.15 D̲a̲t̲a̲ ̲A̲d̲d̲r̲e̲s̲s̲ ̲T̲a̲b̲l̲e̲ ̲A̲d̲d̲r̲e̲s̲s̲
The Data Address Table Address is a relative address
pointing at an area in memory where the Data Address
Table will subsequently be built.
For certain special checks the data address table may
be omitted, e.g. a Date Time Group check.
4.3.2.16 R̲e̲p̲e̲a̲t̲ ̲C̲o̲d̲e̲
The Repeat Code is a code indicating whether this field
may be repeated within the set or not.
(Only the last field(s) of a set may be repeated).
4.3.2.17 H̲y̲p̲h̲e̲n̲ ̲C̲o̲d̲e̲
The Hyphen Code is a code indicating whether the value
af this field may be replaced by a hyphen. This will
only refer to a field the MO Code of which is "mandatory".
4.3.2.18 M̲O̲ ̲C̲o̲d̲e̲
The Mandatory/Optional Code (MO Code) states whether
this field is mandatory or optional.
If a field is mandatory it may be filled with a hyphen
if the hyphen code allows this.
Optional fields may be omitted only if all subsequent
fields of the set are also omitted (since a field can
only be identified by its relative position).
If a group of fields is repeated none of the fields
within this group may be omitted.
4.3.2.19 M̲i̲n̲i̲m̲u̲m̲ ̲L̲e̲n̲g̲t̲h̲/̲M̲a̲x̲i̲m̲u̲m̲ ̲L̲e̲n̲g̲t̲h̲
The Minimum Length/Maximum Length refer to the number
of characters within a field. If a field (legally)
contains only a hyphen, the minimum length requirement
may be overruled.
For certain fields the min/max lenght are of minor
interest, for instance free text fields and fields
to be checked against a data list. Fields requiring
operator validation may also be defined without explicit
min/max lengths.
4.3.2.20 D̲a̲t̲a̲ ̲A̲d̲d̲r̲e̲s̲s̲ ̲T̲a̲b̲l̲e̲
The Data Address Table is a table contaning only addresses
pointing to the data list. For each field there must
be one separate data address table, unless the validation
type allows the check to be performed without the use
of a data list.
The addresses point to an entry each within the data
list. The length of the entry in the data list is determined
by subtracting the address from the following address
in the data adress table. After the last address must
thus be placed the address of the first character following
the data list for the field in question. (And subsequently
an end-of-table marker).
For range check type fields the data list shall contain
pair(s) of entries. Such pairs are addressed individually
so that the first address points to a lower limit,
the second to an upper limit, etc.
4.3.2.21 D̲a̲t̲a̲ ̲L̲i̲s̲t̲
The Data List is a simple character string which may
be common to all fields of a message. All entries are
placed in the string in the sequence in which they
are defined, and with each entry immediately following
the preceding entry. The division between entries is
determined by the addresses in the Data Address Table.
4.3.3 T̲e̲s̲t̲ ̲a̲n̲d̲ ̲V̲e̲r̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
Prior to the release of a new set of validation information
it must be verified that it will allow legal messages
to pass the security filter, and that it will reject
and log illegal messages.
There are two obviously possible ways to achieves this
goal: either to trust the conversion program to produce
correct validation information, or to perform test
runs to verify the validation information.
The first way - using trusted software for the message
description converter - has certin valuable advantages:
it will probably work faster, it minimises the burden
on auxiliary hardware, and it concentrates the time
and labour consumming human efforts mainly on the definition
of legal messages, removing the task of test material
productions and test performances.
The second way - producing validation information by
use of untrusted software and subsequent testing -
also has some advantages. Its most obvious advantage
is that it gives possibility to share the legal message
definition between two separate bodies, which implies
a mutual, built-in check.
4.3.3.1 T̲r̲u̲s̲t̲e̲d̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲C̲o̲n̲v̲e̲r̲t̲e̲r̲
In case the solution with trusted software is chosen
it implies additional software development effort and
subsequent verification and certification of the software.
This effort will add considerably to the total development
costs for the security filter software. The added cost
in the development phase may be justified by operational
savings during the system life cycle.
On the other hand it must be considered that even if
the greatest possible flexibility is built into the
security filter software, it is impossible to predict
all development in communication and message structure,
even for a relatively short glance into the future.
This means that any innovation or introduction of new
types of messages may imply an expensive and cumbersome
task of reprogramming/modifying the converter software
a̲n̲d̲ a repeated verification and certification round.
Nevertheless, modification of legal message description,
and introduction of new legal messages will be greatly
facilitated by the use of trusted software. Provided
the composition of message types can be expected to
remain stable for a long period of time, the trusted
software solution is therefore recommended.
4.3.3.2 U̲n̲t̲r̲u̲s̲t̲e̲d̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲C̲o̲n̲v̲e̲r̲t̲e̲r̲
An untrusted message description conversion program
shall in principle perform equally stable as a trusted
one. Only is it not trusted to do so, which means that
the output, the validation information, must be tested
very thoroughly to verify that it acts correct.
An untrusted program can be modified rather easily.
Hence, use of an untrusted converter will give the
possibility of fast and easy introduction of validation
information for new message types.
The importance of such an advantage must be seen in
the light of the close cooperation between the converter
and the security filter validation program. There is
not much use for validation information, which cannot
be handled by the validation program, and it will even
be harmful if it causes the filter to act erroneously.
The use of untrusted software for the message description
conversion program will thus be most advantageous if
relatively frequent changes of message t̲y̲p̲e̲s̲ are expected.
Even though both the conversion program and the validation
program must be modified, only the validation program
needs be certified.
Also, untrusted software for message description conversion,
can be combined with a trusted "certifier".
A certifier is a computer program which reads the validation
information and communicates with an operator terminal.
The certifier can display the validation information
for one message a small part at the time,and it can
compare two different issues of validation information
for one message and display the differences.
The first function helps the security officer check
a complete message description, which is necessary
when a new message is introduced.
The second function helps the security officer check
the changes, when a message description has been modified.
4.3.3.3 T̲e̲s̲t̲ ̲S̲e̲t̲-̲U̲p̲
A testing facility will be necessary whether a trusted
or an untrusted message description conversion program
is chosen. In the latter case the test facility will
have a very central position within the off-line software
production office.
Ideally the test is performed on site, letting the
two ADP-Systems communicate a great number of test
messages. This requires, however, that both ADP Systems
be kept under strict surveillance by authorised personnel
during the test, that ordinary classified communication
is suspended, and it is assured that all "false" messages
used for test purposes can be securely removed from
the receiving system before any action is taken by
either the system or the staff.
Such a test set-up seems to be rather vulnerable and
time and labour consuming, whereas a special test filter
will offer great advantages.
A test system must be constructed as a model of an
operative security filter. The optimal solution is
a real security filter system configures exactly as
the filter it is replacing, and loaded with exactly
the same software as used on the site. This approach
will give an exact picture of the abilities and possible
errors or mistakes of the filter and its software.
The communication of test messages to the test filter
and the reception of accepted test messages retransmitted
from the test filter can be done by any computer supplied
with a line interface equal to that of the real operative
ADP systems. It will even be possible to let one computer
act as both the ADP systems involved in the communication.
The use of such special test set-up not only releaves
the staff of the ADP systems of the problems arising
from the special attention and surveillance necessary
when testing on live system. In case the security filter
and its line interface can work faster than normal
transmission speed, it also opens the possibility of
performing the testing within a narrower time frame
than possible on the "live" system.
The number and variation of test messages to be sent
within a test run depend partly on the character of
the message description conversion program (trusted
or untrusted), partly on the scope and complexity of
the validation information to be tested.
4.3.3.4 T̲e̲s̲t̲ ̲M̲a̲t̲e̲r̲i̲a̲l̲ ̲P̲r̲o̲d̲u̲c̲t̲i̲o̲n̲ ̲
The testing of the security filter software and validation
information requires an amount of varying test messages,
including both legal and illegal messages.
For a small test run of a set of validation information
produced by trusted software only a small amount of
test messages is necessary. It can be produced quite
easily by an experienced staff member who takes into
consideration which points of the validation information
are critical. The tools needed for this purpose can
be limited to a pad of paper and an input terminal.
If, however, the test concerns a set of validation
information produced by untrusted software (or, for
some other reason, a thorough test in desired) a much
larger amount of test data is necessary. And not only
must the amount be much larger: also the variation
and complexity of the test messages must be of a high
degree.
To achieve this within a reasounable time frame, the
assistance of a computer is necessary.
There are produced a number of test data generators
already, but unfortunately we have not succeded in
finding one commercially available test data generator,
which is useful as it is or can be modified to fulfil
the requirements of the security filter. Hence, it
will be necessary to develop a test data generator
especially for the security filter.
A generalized test data generator (TDS) is a very complex
piece of software. Dedicating a TDG to a specific project
reduces the complexity considerably (and also reduces
the TDG's useability). For the TDG specificly produced
for the security filter project the complexity will
still be rather high (compared to a TDG for an ordinary
commercial project), but the necessary effort can be
reduced by good planing and developing the TDG as a
by-product of the message description conversion program.
The test data generator shall produce a number of legal
messages and a number of illegal messages. The illegal
messages shall be so constructed that (normally) only
one constraint is violated within one message. This
is necessary in order to verify that exactly that violation
causes the rejection in the security filter.
5 I̲D̲E̲N̲T̲I̲F̲I̲E̲D̲ ̲M̲O̲D̲U̲L̲E̲S̲
This chapter discusses the modules identified as necessary
in order to implement a security filter system in accordance
with the preceding system description.
5.1. S̲O̲F̲T̲W̲A̲R̲E̲ ̲M̲O̲D̲U̲L̲E̲S̲
5.1.1 O̲n̲-̲l̲i̲n̲e̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The security filter on-line software can be functionally
separated into a number of packages. These functional
packages - as shown in figure 5.1-1 - may be divided
between a number of processors, which need not have
the same characteristics or capabilities.
The functional packages are:
L̲i̲n̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ - a sensitive but not critical package.
May be a standard software package or hard coded
hardware. Works in principle independent of the
rest of the on-line software.
I̲n̲i̲t̲i̲a̲t̲o̲r̲ - is invoked by a press on the "start" button
or
other
physical
intervention.
Sets
up
initial
values
of
registers,
instruction
counters,
etc.
When
finished
it
leaves
control
to
Control
and
Monitor
package,
and
is
since
idle
until
next
start
or
restart.
C̲o̲n̲t̲r̲o̲l̲ ̲a̲n̲d̲ ̲M̲o̲n̲i̲t̲o̲r̲ - governs the common status memory.
All communication between the separate parts of
the on-line software is made as status signals
to and from the control and monitor package. A
process is started when the control and monitor
has set a specific bit pattern in the common status
memory. When a process is finished, the result
is stored as a status, which gives the necessary
input to the control and monitor to determine which
process to start next. When a processor will otherwise
be idle, the control and monitor may start the
built-in test.
If an error status is reported from any part of
the security filter software or hardware, all processors
shall be stopped, possibly after the display of
an error message.
Figure 5.1-1…01…ON-LINE SOFTWARE PACKAGES
B̲u̲i̲l̲t̲-̲I̲n̲-̲T̲e̲s̲t̲ - a program which checks the contents
of
(a part of) program memory. In connection with
the compilation of a program is calculated a checksum
for a certain program storage area following a
specific algebraic formula. The checksum is stored
in connection with the program or with address
information locating the program memory area in
question. When invoked, the built-in test program
calculates the checksum following the same rules.
If it gets the same result an OK status is reported.
Otherwise an error status is reported.
If the possibility exists, that a temporary error
can occur, the built-in test program may be invoked
several consecutive times in case of an error,
before the ultimate decision of disabling the security
filter is taken. The program must though not be
run until an OK status has been reported.
V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ - the soul and heart of the security filter.
It must probably be separated in a number of modules
executing in different processors. Each module
operates on status signals from control and monitor,
and each module sends status reports to control
and monitor.
L̲o̲g̲g̲i̲n̲g̲ - a program module that writes rejected messages
on
the
logging
medium
upon
a
reject
status
from
control
and
monitor.
Each
rejected
message
shall
be
physically
written
on
the
logging
medium,
whereupon
a
"written"
status
is
reported.
A̲l̲e̲r̲t̲ - calculates the frequency of illegal messages
each time a message is rejected. In case of a too
high frequency, an alert signal is given.
S̲u̲s̲p̲e̲n̲s̲i̲o̲n̲ - withholds a message and displays it to
the
operator. The operator reply is reported as an
accept or a reject status.
5.1.2 O̲f̲f̲-̲l̲i̲n̲e̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
Also the off-line software can be divided in a number
of main packages as shown on figure 5.1-2.
The Message Description Conversion can be implemented
on any available computer, and need not use equipment
equal or similar to the security filter system.
Also the Log Display (and - if chosen - the Statistics
Generator) can be run on any available computer.
The Off-Line Test Accelerator must be run on equipment
communicating with a security filter system exactly
like the field site operational security filter.
For Test Data Generator/Test Set-Up may be chosen security
filter-like equipment or other equipment, depending
on which degree of testing is supposed to be laid on
this package.
Figure 5.1-2…01…OFF-LINE SOFTWARE PACKAGES
5.1.3 O̲n̲-̲L̲i̲n̲e̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲ ̲M̲o̲d̲u̲l̲e̲s̲
The on-line software packages can be divided into a
number of smaller modules. A package may be implemented
on one processor or shared between several. A module
is a unit run in one processor, but some modules (e.g.
the built-in test) may be duplicated and run separately
in several or all processors.
The following on-line software modules have been identified:
a) L̲i̲n̲e̲ ̲T̲e̲r̲m̲i̲n̲a̲t̲i̲o̲n̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
This encompasses protocol handling, serial-to-parallel
conversion, etc. It is anticipated that standard
line termination hardware modules can be used,
and that the necessary software/firmware is supplied
with the hardware.
b) C̲o̲n̲t̲r̲o̲l̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
- E̲n̲a̲b̲l̲i̲n̲g̲ ̲a̲n̲d̲ ̲d̲i̲s̲a̲b̲l̲i̲n̲g̲ ̲o̲f̲ ̲o̲t̲h̲e̲r̲ ̲f̲u̲n̲c̲t̲i̲o̲n̲s̲. A module
which shall set and set off enabling bits in a
status memory based on status bits set by other
modules and by hardware. One detected hardware
or software error shall result in the disabling
of all functions of the security filter, possibly
with the exception of an error message displayed
on the visual display unit.
- B̲u̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲. A module which shall check and ensure
that data transmission on the buses is executed
correctly. This module will probably be hardware
resident.
- C̲h̲e̲c̲k̲ ̲o̲f̲ ̲m̲e̲s̲s̲a̲g̲e̲ ̲t̲y̲p̲e̲. This is the first module
looking into the contents of the message. Until
now the traffic has only been considered a string
of bits. The type of message shall be determined
on basis of defined identification characteristics
within the message header. No accept or rejection
is determined as far, but a breakdown can be performed
on the ADatP-3 type messages as soon as it is recognized
as a such.
- B̲r̲e̲a̲k̲-̲D̲o̲w̲n̲ ̲o̲f̲ ̲M̲e̲s̲s̲a̲g̲e̲ is performed if the previous
check reveals the message as an ADatP-3 type message.
The "break-down" is performed establishing a table
of relative addresses pointing at the delimiters
of the message. The message itself is not touched
at all. The address tables form part of the internal
message header.
- B̲u̲i̲l̲d̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲H̲e̲a̲d̲e̲r̲. In order to ensure that the
message eventually transmitted from the security
filter is identical to the message received an
internal message header is used. This header which
may be placed ahead of the message or both ahead
of and behind the message shall contain significant
information about the physical construction of
the message, such as length, the tables of relative
addresses, and a cyclic redundancy check (CRC)
sum, which will be checked again prior to the eventual
transmission.
c) V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The validation software is extensively described
in paragraphs 4.2 and 4.3.
d) L̲o̲g̲g̲i̲n̲g̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
- W̲r̲i̲t̲e̲ ̲t̲o̲ ̲L̲o̲g̲. Upon the decision of rejecting a
message, the message shall be logged. This is done
by enabling the logging module, which addresses
the message in memory, if necessary divides the
message into a number of records, and issues a
(number of) write command(s) to the magnetic tape
control unit.
- C̲l̲e̲a̲r̲ ̲B̲u̲f̲f̲e̲r̲ ̲A̲r̲e̲a̲. When the rejected message has
been written upon the log tape the buffer area,
in which the message resided, must be cleared.
This can be done by zeroing or blanking the memory
area.
e) S̲u̲s̲p̲e̲n̲s̲i̲o̲n̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
- M̲o̲v̲e̲ ̲t̲o̲ ̲S̲u̲s̲p̲e̲n̲s̲i̲o̲n̲ ̲B̲u̲f̲f̲e̲r̲. When the decision has
been made that a message shall be suspended, it
shall be moved to the suspended buffer area. The
suspension buffer area must contain a map or dictionary
area, where the suspended messages are listed with
their appropriate addresses within the suspension
buffer area. If the suspension buffer area cannot
accommodate a new suspended message, when it is
suspended, the ordinary security filter operation
must be halted until sufficient space is available.
The operator must be notified on this calamity.
When the suspended message has been stored in suspension
buffer area, ordinary filter operation is resumed.
- N̲o̲t̲i̲f̲y̲ ̲O̲p̲e̲r̲a̲t̲o̲r̲. If the operator terminal is idle
when a message is suspended, a notification shall
be sent to the operator. This can be done by a
simple message on the screen, possibly accompanied
by an audible signal.
If the operator terminal is busy when a new suspended
message comes in, this notification shall wait
until the ongoing operation is terminated.
- C̲h̲e̲c̲k̲ ̲O̲p̲e̲r̲a̲t̲o̲r̲ ̲I̲d̲e̲n̲t̲i̲f̲i̲c̲a̲t̲i̲o̲n̲. If the operator
terminal is idle when a message is suspended, the
operator's identification shall be checked prior
to the display of the message on the screen. This
checking can be done by password checking or any
other feasible and trustworthy procedure..
- D̲i̲s̲p̲l̲a̲y̲ ̲M̲e̲s̲s̲a̲g̲e̲. The suspended message is accompanied
by a header or control field containing information
on the reasons for suspension, such as relative
address and field length of the field(s) to be
checked. Using this information the screen display
is edited to draw the eyes to the field(s) of interest
(by using double intensity, blinking, reverse video,
underscoring, different colour, or other means).
To aid the operator it will be an advantage to
divide the screen picture into a data area and
a control area (the latter being of only one or
a few lines).
The message shall be displayed in the data area,
which shall be controlled by the computer. There
must be no means for the operator to change the
contents of the data area.
Using the control area of the screen for communication
between the computer and the operator, the operator
is requested to check the fields one at the time.
When a decision is given, it is conveyed into the
computer at once. If the decision is an "Accept"
the highlight (or other mean of attraction) is
removed from the display for the corresponding
field, and an accept bit is placed in the control
field. If the decision is a "Reject" the message
is cleared from the screen, a reject bit is placed
in the control field, and a flag is set to indicate
to the logging module that logging of the message
shall take place as soon as the logging module
can gain control.
-S̲c̲r̲o̲l̲l̲. Since a suspended message may be larger than
the space available in the data area of a display screen,
a scrolling feature shall be available, allowing the
operator to scroll the message forwards and backwards.
f) A̲l̲e̲r̲t̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
- C̲a̲l̲c̲u̲l̲a̲t̲e̲ ̲f̲r̲e̲q̲u̲e̲n̲c̲y̲. Whenever a message is rejected
the frequency of illegal messages must be calculated.
This can be done by the formula shown on figure
5.1-1
The calculated frequency shall be compared with
a predefined maximum. If this maximum is exceeded
alert shall be given.
- S̲e̲n̲d̲ ̲A̲l̲e̲r̲t̲ ̲C̲o̲m̲m̲a̲n̲d̲. When an alert shall be given
(se above) this is done by sending an electric
signal to an audible alert device. The character
of this device must be decided locally, and also
the location is depending on local circumstances.
The security filter casing shall, however, be prepared
to accommodate at least one type of audible alert
device, which cannot be unauthorized dismounted
or switched off without violating the security
precautions around the security filter.
Figure 5.1-1…01…CALCULATION OF FREQUENCY
g) B̲u̲i̲l̲t̲-̲I̲n̲ ̲T̲e̲s̲t̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
To achieve the highest possible security the security
filter must be able to check itself to a high degree.
One feasible way to check the software and the
memory area is to let a built-in test program run
while the processor for some reason is otherwise
idle.
A way to perform a built-in test is to calculate
a checksum, in principle a cyclic redundancy check,
for a certain area of the memory. The calculated
checksum shall then be compared with a predefined
correct result. In case of discrepancy an error
or a security violation has possibly occurred,
and the filter shall be disabled.
A such check can be performed on ROM memory at
any time. On RAM memory the check is only feasible
before modification of software loaded from a known
source, or after restoring the software to the
original status.
5.2 H̲A̲R̲D̲W̲A̲R̲E̲ ̲M̲O̲D̲U̲L̲E̲S̲
For a detailed description of the identified hardware
modules, please refer to technical note No. 4, Configuration
Study, chapter 2.2: "Multichannel Security Filter".
5.3 P̲E̲R̲F̲O̲R̲M̲A̲N̲C̲E̲
For detailed performance calculations for the security
filter equipment, please refer to technical note No.
4, Configuration Study, chapter 2.3: "Performance".
5.4 C̲O̲M̲M̲E̲R̲C̲I̲A̲L̲L̲Y̲ ̲A̲V̲A̲I̲L̲A̲B̲L̲E̲ ̲H̲A̲R̲D̲W̲A̲R̲E̲ ̲A̲N̲D̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲
5.4.1 H̲a̲r̲d̲w̲a̲r̲e̲
Due to the highly specific security requirements only
the tape recorder can be procured as an off-the-shelf
item. The terminal is functionally very close to a
normal dumb terminal, but e.g. the Tempest requirement
precludes an off-the shelf procurement.
5.4.2 S̲o̲f̲t̲w̲a̲r̲e̲
The contraints mentioned above for hardware are equally
valid for the operational software of the security
filter.
The line interface software (protocol handling etc.),
which probably will be stored in hardware or firmware,
may though be an off-the-shelf type, if the line termination
hardware unit can be found on a shelf.
All software used in the critical or most critical
part of the security filter must be coded specifically
for the filter, or derived from general software for
the hardware in question.
5.5 M̲E̲A̲S̲U̲R̲E̲S̲ ̲T̲O̲ ̲P̲R̲E̲V̲E̲N̲T̲ ̲I̲N̲T̲E̲N̲T̲I̲O̲N̲A̲L̲ ̲D̲I̲S̲R̲U̲P̲T̲I̲O̲N̲
It is necessary to take some measures to prevent the
security filter system from intentional disruption.
The measures taken to prevent from disruption during
development and maintenance are covered by "Verification
Methods".
To prevent disruption in service are taken measures,
which can be separated in three groups: procedural,
hardware and software.
The procedural measures must be specified by the security
authorities and may vary slightly from site to site.
The procedural measures must encompass physical access
control, surveillance, etc.
The hardware and software measures are described in
more detail in corresponding documents. They are, in
summary:
- Electrical Protection Circuit - protects against
intelligent electrical modification through a communication
line.
- use of PROM (Programmable Read-Only Memory) instead
of RAM (Random Access Memory) - protects against
modification of programs.
- Locked enclosure around the entire security filter
system.
- Limited operator communication facilities - the
operator can (in principle) do nothing but accept
or reject a message.
S̲o̲f̲t̲w̲a̲r̲e̲
- Built-in check - memory areas are checked periodically
or aperiodically for modifications.
- Checksum on messages - a checksum created by the
input line terminator and checked by output line
terminator ensures that the message transmitted
is exactly the same as was received.
5.5.1 T̲e̲m̲p̲e̲s̲t̲ ̲A̲c̲c̲e̲p̲t̲a̲n̲c̲e̲
Our baseline is that the components of the security
filter equipment, except operator communication equipment,
shall be assembled in a TEMPEST proof EMI rack.
The rack shall be supplied with a mechanical switch
disabling the filter when doors are opened.
During short periods of corrective or preventive maintenance
the emanation requirements are degraded. It must be
within the operational procedures, that the security
officer is currently informed on activities concerning
corrective and preventive maintenance and thus is able
to decide whether it is acceptable to continue operation
or not.
To meet the NATO Security Requirements, the equipment
must be installed in accordance with criteria laid
down in AMSG 719B. The production equipment shall be
subject to inspection and testing by ACE COMSEC Radiation
Team at the factory premises prior to dispatch/distribution
to locations. After installation, a final COMSEC Radiation
Survey must be carried out at each location prior to
operational approval being given. Rectification of
the equipment characteristics shortcomings shall be
the responsibility of the contractor.
Special earthing arrangements with respect to
- AC power neutral
- safety ground
- signalling and control ground
are necessary within the system in order to comply
with criteria laid down in AMSG 719B.
To assist in the assessment of physical security and
guarding of classified information, a list of all items
of equipment which will store, display, or record classified
information shall be supplied to ACE COMSEC by the
contractor. From the list an assessment is made for
physical security in accordance with AMSG 293D.
