top - download
⟦a5282d955⟧ Wang Wps File
Length: 47673 (0xba39)
Types: Wang Wps File
Notes: SEC. Fil. Architecture
Names: »3175A «
Derivation
└─⟦550b0bab9⟧ Bits:30006219 8" Wang WCS floppy, CR 0276A
└─ ⟦this⟧ »3175A «
WangText
…00……00……1b… …1a……0b……1a……00……1a……05……19……0c……19… …86…1
…02…
…02…
…02…
…02…
NATO UNCLASSIFIED…86…1 …02… …02… …02… …02…
…02…
…02…
NATO UNCLASSIFIED
…02……0e…SFS/PFS/001…0f…
KFL/821220
#
PRELIMINARY
FILTER
SPECIFICATION
SFS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1. GENERAL ....................................
1.1 PURPOSE ....................................
1.2 PROJECT REFERENCES .......................
1.3 TERMS AND ABBREVIATIONS ..................
2. SUMMARY OF REQUIREMENTS ....................
2.2 SYSTEM FUNCTIONS .........................
2.2.1 Filter Functions.....................
2.2.2 Auxiliary Functions .................
2.2.2.1 Software Production and Maintenance
2.2.2.2 Validation Information Conversion
2.2.2.3 Test and Verification ............
2.2.2.4 Test Material Production ..........
2.2.2.5 Log Analysis ......................
2.2.2.6 Table Updating .....................
2.2.2.7 Statistics .......................
2.3 ACCURACY AND VALIDITY ....................
2.4 TIMING ...................................
2.5 FLEXIBILITY ..............................
3. ENVIRONMENT ..................................
3.1 EQUIPMENT ENVIRONMENT ....................
3.2 SUPPORT SOFTWARE ENVIRONMENT .............
3.3 INTERFACES ...............................
3.4 SECURITY .................................
3.5 CONTROLS ................................
4. DESIGN DETAILS .............................
4.1 GENERAL OPERATING PROCEDURES ............
4.1.2.1 Reception of messages ............
4.1.2.2 Recognition of Message Type ......
4.1.2.3 A Dat P3 Message Type Validation
4.1.2.4 Recognition of MSGID etc. ........
4.1.2.5 Validation of a Set ..............
4.1.2.6 Validation of Single Fields ......
4.1.2.7 Retransmission of Legal Message ..
4.1.2.8 Logging of Illegal Message .......
4.1.2.9 Calculation of Frequency of Illegal
Messages ..........................
4.1.2.10 Alert Function .................
4.1.2.11 Suspension of Message ..........
4.1.3 Auxiliary Elements ...................
4.1.3.1 Definition of Legal Messages .....
4.1.3.2 Conversion of Validation Information
4.1.3.3 Test and Verification ............
4.1.3.5 Log Analysis .....................
4.1.3.6 Table Updating System (or Procedure)
4.1.3.7 Statistics .......................
1̲.̲ ̲G̲E̲N̲E̲R̲A̲L̲
1.1 P̲U̲R̲P̲O̲S̲E̲
This Preliminary Filter Specification constitutes the
report on work package No 270 of the Security Filter
Study, contract No FK 8219, and is written to fulfil
the following objectives:
a) To provide a preliminary definition of the system
functions
b) To provide a preliminary baseline on which to base
the definition of the filter architecture
c) To discuss the complex of operative and auxiliary
functions necessary for a security filter system
This document is in some places rather detailed and
specific, in other places more brief. The detailed
parts are so in order to explain and clarify the feasibility
rather than to freeze the system definition. Where
a solution is obvious and does not need a more specific
description at this moment, the text is much more brief.
During the study it has become evident to the study
team that many aspects of the security filter can be
constructed in a number of different ways. It is thus
not the only and ultimate solution which is presented
here, and every single paragraph must be considered
undecided, however detailed it is written.
1.2 P̲R̲O̲J̲E̲C̲T̲ ̲R̲E̲F̲E̲R̲E̲N̲C̲E̲S̲
TBS
1.3 T̲E̲R̲M̲S̲ ̲A̲N̲D̲ ̲A̲B̲B̲R̲E̲V̲I̲A̲T̲I̲O̲N̲S̲
F̲i̲r̲m̲w̲a̲r̲e̲: 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". For
the sake of convenience the term "software
is used in this document for both software
and firmware, except where a clear distinction
is necessary.
M̲T̲F̲: Message Text Format.
T̲B̲S̲: To be specified
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 a computer placed in a point-to-point
communication line 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 on
the line but with different filter characteristics.
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 message contents, and
message traffic deviating from the defined legal contents
is consequently considered illegal.
The definition of legal message contents is exchangeable.
Hence the filter can be used on lines with different
legal traffic, and the definition can be modified from
time to time. Illegal messages are logged by the security
filter. Frequent traffic of illegal messages will cause
an alert for immediate action.
The security filter can - if necessary - be expanded
by adding some operator communication facilities to
make possible a human validation of messages too complex
to be validated by the computer.
2.2.2 A̲u̲x̲i̲l̲i̲a̲r̲y̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
To ensure proper operation of the security filter certain
auxiliary functions are necessary.
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 V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲ ̲C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲
The filter function is based both on computer programs
of stable character, and on legal message definitions,
which may vary from time to time and among the various
security filter sites.
To allow for easy and frequent modification of this
validation information a converter system must be at
hand.
The information used for validation of message traffic
must be written in a legible (by humans) form, and
converted into a computer-legible form.
Also this task must be performed on a computer distinct
from the security filter.
2.2.2.3 T̲e̲s̲t̲ ̲a̲n̲d̲ ̲V̲e̲r̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
The validation information converted into tables must
be thoroughly tested to ensure that it is cooperating
correctly with the security filter software. The testing
must be sufficient to verify (render probable beyond
any reasonable doubt) that the filter will allow only
legal messages to pass.…86…1 …02… …02… …02… …02…
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 a thorough testing a considerable amount
of test material (test messages) must be produced.
The quality of the test material is measured not only
by the quantity but also by its variation in lieu of
the constraints to be tested. The use of a computerised
test data generator seems inevitable, and the possibility
of use of a commercially available data generator must
be considered.
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 inposed
on the exchange of validation information.
2.2.2.6 T̲a̲b̲l̲e̲ ̲U̲p̲d̲a̲t̲i̲n̲g̲
The table updating in an operative security filter
must be performed as an exchange of a full set of validation
information. This is necessary since the testing of
the validation information in performed on a complete
set.
The exchange must be performed by or under surveillance
of authorized personnel and precautions shall be taken
to ensure that any unauthorized attempt to change or
alter the validation information results in a break
of the filter operation.
2.2.2.7 S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
Collection of statistics information is an option.
If such an option is chosen it must be ensured that
it will have no influence at all on the message traffic
of the filter software, and the collected statistics
information must be kept safe for unauthorised eyes
very much like the validation information. Compilating
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 on total accuracy
and validity. This means that there will be no tolerances
whatsoever.
It must be described in detail which items shall be
checked, and for each single item it shall be exactly
defined, which values are legal. If a message does
not match exactly and in every item to be checked,
with the prespecified definition, it shall be declared
illegal, logged and not transmitted.
For a security filter site which is fitted with operator
communication facilities the same rules apply. Only
if all items to be automatically checked match the
validation information, a message may be suspended.
The suspension pertains only to items which are prespecified
for human validation. Any other item to be checked
may cause the validation to fail prior to the decision
of suspension.
2.4 T̲I̲M̲I̲N̲G̲
The security filter shall be transparent to the two
ADP systems connected by the line filtered by the system
except for a minor delay defined as the transmission
time plus five seconds.
This means in interpretation that the first bit of
a message shall be sent from the security filter system
not later than 5 seconds after the last bit of the
message has been received. Further, that messages from
each side shall be processed in the same order as they
are received.
For a fully automated security filter system this implies
only that the capacity shall be sufficient to process
the largest and most complex message from each side
within 5 seconds, including handshaking and protocol
and transmission procedures.
For an operator assisted security filter system this
is not true. As soon a message is suspended for human
validation a delay of more than five seconds must be
expected for that message.
To maintain the transparency of the filter to the highest
possible extent, normal operation shall be resumed
immediately after the suspension. The suspended message
shall be transmitted when it has been validated by
the operator (if he declares it legal).
2.5 F̲L̲E̲X̲I̲B̲I̲L̲I̲T̲Y̲
The security filter system shall be flexible as far
as it shall be possible to define new legal messages
to it. This means that other legal contents must be
easy to define and implement, only taking into consideration
that it shall be performed following a secure procedure.
The ability to accept new messages will, however, be
limited to message formats or message format description
types which are known or aforeseen at the time of implementation
of the security filter system computer programs.
If a new message format cannot be formally and structurally
described by means of existing programs, reprogramming
may be necessary. (The impossiblility of describing
the format could, however, be used as a reason for
suspending a message type, i̲f̲ the security filter in
question is equipped with operator communication facilities,
and i̲f̲ it is possible - using the existing programs
- to recognize the message t̲y̲p̲e̲ ̲)
Also the number and complexity of legal messages defined
to a certain security filter shall be flexible, but
the available memory will set limits for the amount
of validation information to be at hand at each time.
3̲ ̲E̲N̲V̲I̲R̲O̲N̲M̲E̲N̲T̲
3̲.̲1̲ E̲Q̲U̲I̲P̲M̲E̲N̲T̲ ̲E̲N̲V̲I̲R̲O̲N̲M̲E̲N̲T̲
The security filter hardware equipment will be described
in the Technical Note No 2, "Architectural Study",
Document No SFS/TN/002.
The equipment to be used for software development and
other auxiliary function is undecided, but at least
the test equipment must be compatible with the filter
equipment.
3.2 S̲U̲P̲P̲O̲R̲T̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲ ̲E̲N̲V̲I̲R̲O̲N̲M̲E̲N̲T̲
N/A
3.3 I̲N̲T̲E̲R̲F̲A̲C̲E̲S̲
The security filter shall be transparent to the communicating
ADP systems, and there is thus no interfaces as such.
The communication interface problems are solved by
standard communication protocol conventions.
3.4 S̲E̲C̲U̲R̲I̲T̲Y̲
The security filter must be physically enclosed with
due consideration to two reasons:
- it shall be shielded for electric radiation (TEMPEST
proof)
- it shall be locked to prevent against unauthorized
intrusion
For the prevention against unauthorized intrusion it
is of concern that the security filter is supposed
to be located within a safe area, and the prevention
needs not be specified to withstand the extreme violence.
It will be sufficient to supply the filter with locks
which prevents from an unintended or "by incident"
opening of the doors of the ceasing, and some supplementary
feature, which stops the operation of the filter and
makes a restart impossible (until duly authorized personnel
have restored the filter), and possibly sounds an
alarm.
3.5 C̲O̲N̲T̲R̲O̲L̲S̲ ̲
The security filter may not control, and may not be
controlled by, any of the two communicating ADP-systems.
No specific controls are established for the security
filter.
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̲S̲ ̲
4.1.1 S̲y̲s̲t̲e̲m̲ ̲E̲l̲e̲m̲e̲n̲t̲s̲
The security filter system elements are separated in
operational elements and auxiliary elements.
The operational elements of the system are those adhering
to the operational security filter site performing
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.
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 musch 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.2.1 R̲e̲c̲e̲p̲t̲i̲o̲n̲ ̲o̲f̲ ̲m̲e̲s̲s̲a̲g̲e̲s̲
The reception of the messages from the transmission
lines are performed by a standard line termination
unit, which receives the signal in accordance with
the specified protocol including bit error check, serial-to-parallel
conversion etc. and stores the message in a dedicated
part of the compartmentalized RAM storage. Further
message handling is controlled by a processor outside
of the line termintation unit.
4.1.2.2 R̲e̲c̲o̲g̲n̲i̲t̲i̲o̲n̲ ̲o̲f̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲T̲y̲p̲e̲
The first task of the main computer after having gained
control over an incoming message is to try to recognize
the message type. The message type is found as a parameter
value in the message header.
Based on the message type the main computer checks
the legal traffic table to decide if the message type
is allowed on the line and in the direction, in which
the message is sent.
This is the first point where a message can be declared
illegal. Two conditions shall be fulfilled: First the
message type itself shall be legal on that line. Second,
it shall be legal in the actual direction.
If either of the two conditions is not fulfilled, the
message shall be declared illegal and handled accordingly
(see paragraph 4.1.2.8).
The two conditions can be checked in one or two tables.
Either there is a table containing all legal message
types and an additional table indicating the legal
directions of each message type, or there is one table
for each direction containing only legal message types
for the corresponding direction.
If the message is declared legal in the actual direction,
the path through the validation program shall be chosen.
The path through the validation program is dependent
of the message type format. The legal messages may
be of a number of different formats. Certain formats
may be so much alike that they can be processed in
the same program path. Others may differ so much that
special paths must be programmed.
4.1.2.3 A̲ ̲D̲a̲t̲ ̲P̲3̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲T̲y̲p̲e̲ ̲V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲
The A Dat P3 type format is anticipated to be the most
complex format, and it is used as a model for the rest
of this description. Other format types may be processed
in a similar or less complex way.
In addition to the choice of program path the prime
entry in the validation table shall be made in this
step of the validation procedure. This includes the
choice of the table for the message traffic direction
in case a certain message type is allowed in both directions.
4.1.2.4 R̲e̲c̲o̲g̲n̲i̲t̲i̲o̲n̲ ̲o̲f̲ ̲M̲S̲G̲I̲D̲ ̲e̲t̲c̲.̲
This and the following paragraphs concentrate on the
processing of an A Dat P3 type message, which has already
been identified as a such. Also the transmission direction
has been determined.
At this time the table for legal A Dat P3 messages
in the correct direction has been chosen.
The MSGID set of the message is located, either as
the first set following the classification and subject
Indicator Code lines, or following the first set when
this is an EXER or OPER set.
The first field of the MSGID set is the message identification.
The message identification shall be found in the Validation
table for A Dat P3 message type for the actual direction.
If the message identification is not found, the message
shall be declared illegal and processed accordingly
(see paragraph 4.1.2.8).
If the message identification is found in the table,
corresponding fields in the table will point to legal
classification(s) for the message in process, and to
Subject Indicator Code(s), and to a set table.
It is checked that the classification (and "Special
Handling" if present) is one of those specified legal
for the message, and that the corresponding subject
indicator code is correct. If either of the two checks
fails the message is declared illegal and processed
accordingly (see paragraph 4.1.2.8).
If classification and subject indicator code are found
OK, validation passes on to the set table for the message.
(In "Functional Analysis" it was suggested that EXER
and OPER sets be analysed in connection with the message
identification. However, after another thought it is
now suggested to move those checks to the standard
set checks).
The set table contains the set identifier of any set
allowed within the message, whether it is mandatory,
conditional, or optional.
In addition the table contains indications (or codes)
for the set's status as mandatory, optional, or conditional.
If the set is conditional, a code indicating the condition
will be present. Further the table contains an indication
if the set is part of a segment, and for possible repeatability.
(If the set is part of a segment, this indicates that
the set may be repeated one time per repetition of
the segment. The repetion code goes for a repetition
of the set itself. If a set may be repeated, the following
sets of the same identification shall follow immediately
after the first, or it may be separated from the preceding
set by means of an AMPN set).
When a segment (group of sets) is repeated the following
segments shall follow immediately after the preceding
segment, or the segments may be separated by a NARR
set.
Nested segments are segments embedded in another segment.
Repeated occurrencies of nested segments follow the
same rules, i.e. they must immediately follow each
other, or be separated by NARR sets only.
4.1.2.5 V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲a̲ ̲S̲e̲t̲
It has already been checked that the occurence of a
set is legal. The validation of the set therefore encompasses
only the legality of the set itself.
The legality of a set depends on its content, and the
content is a number of fields. Since the fields are
only identified by their relative position within a
set, a set can only be validated by checking the number
of fields, and the fields may subsequently be checked
for their contents.
Hence the validation of a set consists solely of splitting
the set into single field, identifying them by their
relative positions, and counting them.
A set must contain at least the number of fields specified
as mandatory, and if no repeatable field or groups
of fields are specified - no more fields than the specified
number.
The splitting of a set into single fields may be performed
by setting up a table containing the addresses of the
start of each field. Also the number of fields must
be stored. This will facilitate the subsequent checking
of the fields.
If the set is a free test set (AMPN, NARR, or RMKS)
only the length of the free text field can be checked.
4.1.2.6 V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲S̲i̲n̲g̲l̲e̲ ̲F̲i̲e̲l̲d̲s̲
The legal contents of a field must be specified in
an unambiguous way. There are several possibilities
of which a few are mentioned here.
a) Set of specific values.
It is specified that the content of a field shall
be one of a set of specific values. Those values
may include a hyphen, indicating that no value
exists, or the omission of the field, if this is
syntactically allowable. The legal values are stored
in a string pointed at by a table of addresses.
If a hyphen or omission is allowed, one entry of
a hyphen must appear in the string of legal contents.
The sequence of the entries must be either numeric/alphabetic
ascending, or it must be in a precedence order
determined by the expected frequency of the single
values in actual messages.
When a field is located the content is compared
with the entries in the specific values string,
either sequentically (if the entries are in frequency
order) of by a binary search (if the entries are
sorted in ascending sequence).
The legal value entries may be stored in one string,
where each entry starts immediately after the preceding.
The relative addresses of the first character of
each entry can be placed in another table, and
the length of an entry can be calculated by subtracting
the address from the address of the next entry.
0101 0112 0124 0135 0147 0158 0169 0182
FIRST ENTRYSECOND ENTRYTHIRD E
b) a specific syntax
It may be specified that a field shall be composed
in a specific syntax. This can include a fixed
length of the field. Further it may mean that the
field must contain only numerals, only alphabetic
characters, or another exact specification, possibly
a specific sequence of characters of varying types,
e.g. 6 numeric followed by 1 alphabetic character
(DTG).
c) within limits
It can be specified that a field shall contain
a value within two prespecified limits. This seems
to be most feasible in case of numeric values.
d) a complex syntax
It may be considered to specify a complex syntax,
by which is meant a combination of length character
types, and values.
As an example is used a geographical position:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
It must be 15 characters of length.
First six characters must be numeric between zero
and 900000.
Characters 3 and 4 must be between zero and 59.
Characters 5 and 6 must be between zero and 59.
Character 7 must be "N" or "S".
Character 8-14 must be numeric between zero and
1600000.
Charater 11 and 12 must be between zero and 59.
Characters 13 and 14 must be between zero and 59.
Characters 15 must be either "E" or "W".
e) no constraint
It may be necessary to convey names of persons,
ships, geographical entities, or other, which are
impossible to specify in beforehand. Fields to
contain such names cannot be constrained.
4.1.2.7 R̲e̲t̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲o̲f̲ ̲L̲e̲g̲a̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲
When a message has been validated and found legal it
is moved to a dedicated part of the compartmentalized
RAM storage, whereupon control of the message is turned
to the line termination unit.
The line termination unit converts the message into
a signal in accordance with the specified protocol
and transmits the message to the ultimate addressee.
4.1.2.8 L̲o̲g̲g̲i̲n̲g̲ ̲o̲f̲ ̲I̲l̲l̲e̲g̲a̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲
If a message fails one of the checks performed during
the validation, it shall be logged and not retransmitted.
The reason for the rejection must be logged with the
message. This can be done by means of a code composed
of several items. Those items can be identifications
of the program modules and the part of the message
in process, when the check fails. A such code can be
evaluated during an offline scrutiny and give rather
exact clues to the revelation of the error, e.g.
mandatory set XXXXX missing.
or
set XXX field no Y not numeric
The message to be logged is packed with the error code
and a clock reading, if necessary in blocks, and written
on the logging medium. The logging medium may be a
separate device, e.g. a cassette tape recorder, or
it may be a dedicated area of a multi-purpose disk.
The area of memory in which the illegal message was
stored shall not be read again until it is ensured
that it is overwritten with new data or erased.
Whenever an illegal message is revealed the frequency
of illegal messages shall be calculated (see paragraph
4.1.2.9).
4.1.2.9 C̲a̲l̲c̲u̲l̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲F̲r̲e̲q̲u̲e̲n̲c̲y̲ ̲o̲f̲ ̲I̲l̲l̲e̲g̲a̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲
Whenever an illegal message has been revealed the frequency
of illegal messages shall be calculated.
The frequency can be expressed as a fraction, where
the number of illegal messages are the numerator, and
the time is the denominator.
The purpose of this calculation is to issue an alert
if the frequency of illegal messages exceeds a prespecified
maximum.
This maximum has not been specified as far but in principle
the calculation shall be performed as follows:
Each time an illegal message has been revealed, this
fact shall be logged on a file (internal or external).
Subsequently this file is read to count the number
of illegal messages revealed within the time frame
given by the denominator of the above mentioned fraction.
If the count exceeds the numerator of the same fraction,
control shall be given to the alert module. If the
count does not exceed the numerator of the said fraction,
control is returned to the main program.
4.1.2.10 A̲l̲e̲r̲t̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
The purpose of the alert function is to alert the security
administrator in case of illegal message traffic exceeding
a prespecified maximum.
The alert function shall issue a signal that causes
an audible alert to sound.
The alert function is called from the module calculating
the frequency of illegal messages (paragraph 4.1.2.9).
The type of audible alarm to use (bell, buzzer, etc.)
must be determined for each site depending on local
circumstances.
If more than one security filter system is located
in the same environment it should be considered to
extend one single audible alarm device with alarm lights
to indicate which security filter system that has actually
started the alert.
Also it must be determined locally by which means the
sounding alert shall be stopped, e.g. by use of a physical
key.
4.1.2.11 S̲u̲s̲p̲e̲n̲s̲i̲o̲n̲ ̲o̲f̲ ̲M̲e̲s̲s̲a̲g̲e̲
The more complex the messages, the more complex the
security filter must be.
A very simple security filter system will only be able
to handle a limited number of simple messages. Even
a more complex security filter system will be unable
to check free text messages and messages, the contents
of which cannot be prespecified or aforeseen.
To facilitate the utilization of a medium complex security
filter system on a large number of sites it is suggested
to consider the possibility of semi-human validation,
facilitated by a suspension function.
Using a suspension function messages of a certain complexity
(or containing free text) can be suspended for human
validation. More simple messages can still be automatically
validated and this traffic need not be interfered by
the suspension.
The suspension function requires certain extra peripherals,
e.g. a video screen for display of the messages, and
a storage medium for storing the suspended messages
until the validation is performed. Also the operator
must have means to input his decision after the scrutiny
of the suspended message. This can be done by use of
a small keyboard of the telephone type. Under no circumstances
may the operator have possibility to change neither
the message, nor the computer programs.
4.1.3 A̲u̲x̲i̲l̲i̲a̲r̲y̲ ̲E̲l̲e̲m̲e̲n̲t̲s̲
The auxiliary elements of the security filter system
encompasses the tasks performed offline in order to
support the operational security filter.
Though these tasks are performed offline, 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.
4.1.3.1 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 definiton of legal messages may also be called
production of input to the conversion of validation
information.
This is a man/machine interface which means that equal
consideration shall be taken to the demands for easy
definition and machine readability.
On one hand it must be rather easy for the person,
who constructs the definition, to write it correctly
and to remember all parameters. On the other hand must
the definition have a format which can readily and
unambiguously be read and "understood" by the computer
assigned to the conversion task.
To facilitate this clear instructions must be worked
out, possibly accompanied by definition forms with
leading texts which guide the person through the definiton
phases.
When defining a legal message the first thing to define
is the header information, which determines the path
through the validation program. Subsequently must be
specified the parameters used in the order, they shall
be used. This must very closely follow the validation
program sequence and specify the parameters in accordance
with the requirements of the conversion program as
set down in paragraph 4.1.3.2.
4.1.3.2 C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲ ̲o̲f̲ ̲V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲ ̲I̲n̲f̲o̲r̲m̲a̲t̲i̲o̲n̲ ̲
The definition of legal messages (see paragraph 4.1.3.1)
must be converted into tables which can be used by
the validation program. This conversion can be performed
on an offline computer located independent of the security
filter sites and handling validation information for
a number of sites.
The type of input device chosen for input of the validation
is not essential for the performance, but in order
to facilitate easy modification of existing legal messages
a Video Display Unit with keyboard should be considered.
The computer program for conversion of validation information
must be separated in three distinct parts
- input collection
- validation and conversion
- consolidation and output
The input collection must operate on all legal messages
for one security filter site at a time. Such a set
of validation information must be identified with a
name or code, which at the same time identifies the
security filter site, for which it is intended.
It must be possible to establish a complete new set
of information for a site, and it must be possible
to modify an existing set.
The input collection part of the computer program operates
on a "source" version of validation information, i.e.
a representation very much alike the definition produced
by man. The collected input is later used as input
for the validation and conversion routine, but the
source version must be kept to facilitate possible
subsequent updates.
The input collection routine must - if apllied on a
VDU - lead the operator through the task of input by
preformatted screen pictures with leading texts ensuring
that all relevant information will be asked for. This
applies mainly to the definition of a new message or
a new part (e.g. set) of an existing message.
Modifying an existing message may be done by calling
the corresponding part of the existing message definition
onto the screen and simply modifying the necessary
item. It must also be possible to delete items from
an existing message description and to add new items.
All input to one security filter site must be collected
prior to the start of the conversion phase.
The validation and conversion phase must start with
a validation of the input. This validation must check
the syntax and possibly part of the logic of the definitions.
Such checks must include e.g. that one message identifier
is not used for more than one message, that one message
has one and only one identifier, that all sets have
valid set identifiers, and that fields are defined
for every set etc. It must also be checked that all
items are described as mandatory, conditional, or optional,
and that conditional items are accompanied by a description
of the condition.
A close analysis of the message traffic on the lines
may reveal the possibility of an amount of logical
checks, but it must also be considered that a computer
program able to perform in-depth logical checks will
be very complex and costly. Possible logical errors
in a legal message definition will often be revealed
easily during a well-planned, subsequent test run.
If any syntactical (or logical) errors are revealed
by the validation phase this shall be reported to the
operator, whereupon he must correct the errors. It
can be considered to report possible errors as warnings,
but the value of such a feature seems dubious.
The conversion of the validation information is done
by setting up a number of tables in a hierarchical
structure, where single entries in a higher level are
pointing at their subordinate entries in lower level
tables using relative addresses.
The highest level table must be one referring to the
"format code" of the transmission header. This format
code is used as the basis for determination of the
path through the message validation. From this highest
level must be set a pointer to the appropriate entry
in the second level, among which one pointing at the
first entry of A Dat P3 type message message identifiers.
The second level table must contain among other an
entry of the message identifier for each A Dat P3 type
message legal on the corresponding communication line.
This entry must - in addition to the message identifier
- contain or point at the classification and subject
indicator code(s) legal for the message, and contain
a pointer to a string in a lower level table giving
the sequence of legal
sets of the message identified by their set identifiers.
If applicable this string of set identifiers shall
be separated into parts and/or segments.
This level must contain - in addition to the set identifiers
- the attributes of the sets, or pointers to sets of
attributes, such as mandatory/conditional/optional,
condition, repeatability, etc, and pointers to a field
table.
The field table must contain the field attributes including
a number indicating how many different legal contents
have been defined for the field and - if applicable
- a pointer to an address table for the legal contents.
The address table shall only contain addresses, one
for each defined legal content of any field.
The legal contents must be arranged in a string, where
each defined legal content does only take up as much
space as necessary. All items defined as legal content
for one field must be placed in succession.
When all tables have been set up a consolidation phase
must be invoked.
The consolidation shall make the dynamically constructed
tables static, put limits to the ends of them, compile
the tables on a storage area as small as possible,
fill in address fields for interfacing purposes and
finally output the ultimate set of tables on the prescribed
output medium.
During the total run of the conversion program a printed
list must be produced to mirror the input, a sort of
compiler list, enabling the operator and other authorities
to trace the definition of legal messages for the security
filter site.
Header
Format Code
HFC Pointer
HFC Pointer
HFC Pointer MSGID CLASS SIC Pointer
HFC Pointer MSGID CLASS SIC Pointer
MSGID CLASS SIC Pointer
MSGID CLASS SIC Pointer
SETID ATTR Pointer
SETID ATTR Pointer
SETID ATTR Pointer
SETID ATTR Pointer
FLD ATTR Pointer
FLD ATTR Pointer
FLD ATTR Pointer
FLD ATTR Pointer…86…1
…02… …02… …02… …02…
Legal contents
Addresses Legal contents string
Address LEGAL CONTENTSLEGAL
CO
Address NTENTSLEGAL CONTENTD
L
Address EGAL CONTENTSLEGAL
CON
Address TENTSLEGAL CONTENTSLEG
4.1.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 tested to verify that it will allow legal
messages to pass the security filter, and that it will
stop illegal messages.
This can be done by specifiying an adequate number
of legal and illegal messages and trying to send them
through the filter with the new set of validation information
installed.
This test might be performed on the actual security
filter site provided it is possible to keep both ADP
systems under surveillance by authorised personnel,
and 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.
However, such a test set up seems to be rather vulnerable
and time consuming, whereas a special test filter will
offer great advantages.
A test filter system must be constructed as a model
of the operative security filter. It can be a larger
computer configuration of the same brand and model,
which is reconfigured and loaded with the security
filter computer programs to act exactly as an operative
security filter.
The roles as the two ADP systems might be played by
any computer applied with a line interface equal to
that of the actual operative ADP systems. (One computer
might act as both systems).
Furthermore, the transmission speed could be raised
to minimize the time frame necessary to perform the
test runs.
To verify - or render probable - that the new set of
validation information is correctly defined and converted,
a variety of both legal and illegal messages must be
sent to the filter. The test must be extensive enough
to show that any message meeting the defined constraints
will pass the filter, and that any violation of any
type of constraint will result in the stopping of the
message.
The definition of test messages is discussed in paragraph
4.1.3.4.
4.1.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 test and verification as described in paragraph
4.1.3.3 requires an amount of varying test messages
including both legal and illegal messages.
The task of generating enough test messages and ensuring
adequate variation is a very cumbersome one if left
to human labour. Therefore it ought to be performed
by a computer, either using a computer program developed
for this specific purpose or using a commercially
available data generator, possibly modified, if such
a generator can be found sufficient.
The test material must consist of messages, which are
numerous and varied enough to cover all constraints,
both with legal and illegal contents. If, for instance,
a list of five legal values is specified for a certain
field, test material shall encompass at least examples
of all five legal values and in addition at least one
example of an illegal value.
All illegal values in the test material shall occur
single at least once. By "single" is meant that there
must be only one illegal value in one message. Messages
with a combination of illegalities may occur, however.
The test messages must vary sufficiently to ensure
as thorough testing of the legal message specification.
This includes, in addition to the use of legal and
illegal contents of fields, omission of mandatory items,
inclusion of illegal items, wrong sequence etc.
When the test material has been produced it must be
stored on a storage medium in a random or quasirandom
sequence as to simulate a real traffic situation. It
shall be possible to print a list of the test messages
in order to analyse them in connection with the test
run.
4.1.3.5 L̲o̲g̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲
Any message stopped by the security filter shall be
logged. The type of logging medium will be chosen in
connection with specification of the hardware configuration.
When a number of illegal messages have been logged
it may be of concern for the security officers to analyse
the log contents.
To facilitate this the logging medium must be interchangeable,
though not removable by unauthorized personnel. The
logging medium must be brought to an off line computer,
where the contents can be displayed or printed for
subsequent scrutiny.
4.1.3.6 T̲a̲b̲l̲e̲ ̲U̲p̲d̲a̲t̲i̲n̲g̲ ̲S̲y̲s̲t̲e̲m̲ ̲(̲o̲r̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲)̲
The system or procedure to be followed by the authorized
personnel when an updating of validation information
has taken place and shall be installed on an operative
security filter site must depend very much on the hardware
solution chosen. The main requirements to the system/procedure
can be summarized as follows:
- unauthorized changes may not take place
- in the event an unauthorized change is forced upon
the filter, its operation shall stop, simultaneously
stopping the message traffic.
- the authorization to make changes shall be unambiguously
recognized by the filter
- the change shall involve as little hardware handling
as possible
- the operational delay caused by a change of validation
information shall be kept within reasonable size
- measures shall be taken to ensure that a set of
validation information is installed at the right
site
To avoid the intrusion of unauthorized people some
hardware solution must be sought. The same applies
to the disconnection in the event of the use of force.
For solution of these requirements please refer to
hardware description.
When authorized personnel wants access to the filter
they must identify themselves towards the filter. This
can be done by use of a key or a code or a combination.
Also this must depend on the hardware chosen. Only
it shall be insured that authorized personnel have
the ability to perform the necesary changes. As long
as the
change is going on the message traffic must be stopped.
This stop shall be invoked by the identification indicating
that a change is going to take place. When the change
is finished a restart of the filter shall be performed,
and during this restart it shall be checked that adequate
validation tables are present and that all security
precautions have been reset.
The means by which the change shall be performed is
also hardware dependent. If it is chosen to use erasable
PROM for storage of the tables, the change may be performed
using some sort of portable device to carry the information
from the production office ot the security filter site,
plug in the device and reprogram the EPROM. If, however,
(non-erasable) PROM is chosen, the whole set of PROMs
must be exchanged. This will require a minimum of hardware
skill, but it may be judged more secure than the EPROM
solution.
4.1.3.7 S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
The possibility of collecting statistics in connection
with the security filter is mentioned as an option.
The statistics system is not part of the original requirements
but is optional.
For the security filter as such a statistics system
shall only imply the collection of statistics data.
This may be achieved in different ways. Either the
data can be collected in accordance with an already
existing statistics system and subsequently be processed
by a corresponding statistics system, or a special
statistics system can be introduced in connection with
the security filter.
The first approach seems to be the easiest and least
expensive to implement. it only requires that 1) an
existing statistics system is adequate for security
filter statistics purposes, and 2) the data necessary
for the statistics system are available at the security
filter system and can be collected without jeopardizing
the security and the performance of the filter.
