top - download
⟦3dce00b9e⟧ Wang Wps File
Length: 35672 (0x8b58)
Types: Wang Wps File
Notes: S F S Architecture
Names: »3160A «
Derivation
└─⟦550b0bab9⟧ Bits:30006219 8" Wang WCS floppy, CR 0276A
└─ ⟦this⟧ »3160A «
WangText
NATO UNCLASSIFIED…86…1 …02… …02… …02… …02…
…02…
NATO UNCLASSIFIED
Security Filter Architecture page
#
821217
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1. GENERAL ....................................
1.1 INTRODUCTION ............................
1.2 TERMS AND ABBREVIATIONS ..................
1.2.1 Terms ..............................
1.2.2 Abbreviations ........................
2. SUMMARY OF REQUIREMENTS ....................
2.1 BACKGROUND ...............................
2.2 OBJECTIVES ...............................
2.2.1 Operational Requirements .............
2.2.2 Performance Requirements .............
3. ENVIRONMENT ................................
3.1 SECURITY RISKS ...........................
3.1.1 Entities to be protected .............
3.1.2 Sources of threat ....................
3.1.3 Risks ................................
3.1.4 Countermeasures .....................
4. SELECTION OF ARCHITECTURES .................
4.1 SECURITY .................................
4.1.1 Migration ............................
4.1.2 Corruption ...........................
4.2 CERTIFYABILITY ...........................
4.3 VULNERABILITY ............................
4.4 RELIABILITY ..............................
4.5 FLEXIBILITY .............................
4.6 PERFORMANCE ..............................
4.7 COST .....................................
5. SELECTED ARCHITECTURES ....................
5.1 COMMON BUS ..............................
5.1.1 Bus Communication Restrictions .......
5.1.2 Example 1 ............................
5.1.3 Example 2 ...........................
5.2 IDEALIZED ARCHITECTURE ...................
6.2.1 An example ...........................
6. CONCLUSIONS ................................
1̲ ̲G̲E̲N̲E̲R̲A̲L̲
1.1 I̲N̲T̲R̲O̲D̲U̲C̲T̲I̲O̲N̲
This technical note represents the output of work package
No 250, Architectural Study, within the framework of
the Security Filter Study, performed under contract
No. FK8219 between the Air Materiel Command of the
RDAF and Christian Rovsing A/S. The Architectural Study
shall evaluate various filter architectures, particularly
with regard to Security Aspects.
The baseline for the architectural study is laid by
the Functional Description of the Security Filter,
document No. SFS/FD/001, dated 820827.
1.2 T̲E̲R̲M̲S̲ ̲A̲N̲D̲ ̲A̲B̲B̲R̲E̲V̲I̲A̲T̲I̲O̲N̲S̲
Within this document, the definitions of terms and
abbreviations below are used.
1.2.1 T̲e̲r̲m̲s̲ ̲
Accepted message a message validated with
a positive result (legal)
Channel Filter (CF): Functional part of the Security
filter System, performing
all automated reception,
filtering and transmission
of messages for one single,
unidirectional channel.
Certification the verification given by
a national security agency,
based on a study of the
system by a technically
competent independent organization,
that the system as designed
meets the security specifications
of the systems.
Corruption Transmission of a message
with a higher classification
than low side level from
low to high…86…1 …02…
…02… …02… …02… …02…
Covert Channels Non-authorized means of
conveying information which
could lead to security breach
Illegal Message a message which by security
regulations is not allowed
to pass the security filter.
Legal Message a message which by security
regulations is allowed to
pass the security filter,
i.e. the message type, format,
and contents of all constrained
fields are equal to entries
in the validation information.
Migration Transmission of a message
with a higher classification
level than low side level
from high to low
Recognized/recognizable a detectable message the
message identification type of which
is contained in the validation
information.
Rejected message a message validated with
a negative result (illegal)
Security Breach The non-authorized disclosure
of classified information
Unrecognized/non-recog- a detectable message the
nizable message identification type of which
is not contained in the
validation information.
Validation the act of evaluating the
legality of a message.
Validated message a message which has been
subject to the validation
process (with a positive
or negative result)
1.3.2 A̲b̲b̲r̲e̲v̲i̲a̲t̲i̲o̲n̲s̲
ADP Automatic Data Processing
MTBF Mean Time Between Failure
MTTR Mean Time To Repair
PFSB Probability For Security Breach
SA Security Administrator
SF Security Filter (SYSTEM)
SFS Security Filter Study
2 S̲U̲M̲M̲A̲R̲Y̲ ̲O̲F̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
The requirements to the Security Filter are described
in Chapter 2 of the document SFS/FD/001, Functional
Description. For convenience, chapters 2.1 and 2.2.
repeated here.
2.1 B̲A̲C̲K̲G̲R̲O̲U̲N̲D̲
The function to be performed by the Security filter
is the security monitoring of the traffic on an electronic
communication line between two ADP centers (or systems)
of unequal level of classification.
The filter shall on one hand prevent highly classified
data from being compromised by unauthorized disclosure,
on the other hand guarantee that certain pieces of
data are not corrupted or otherwise tampered with without
authorization.
The filter function has in some cases been performed
by manual verification of the message traffic. However,
increasing traffic on the communication lines between
ADP systems containing classified data has resulted
in the demand for fully or partly automatisation of
the security monitoring in order to increase capacity
and reduce time delay and cost.
2.2 O̲B̲J̲E̲C̲T̲I̲V̲E̲S̲
The objectives of the security filter is an automatising
of the security administration functions on a dedicated
communication line between two ADP systems of unequal
security classification.
The functional capabilities of a security filter are
described in terms of the following main requirements.…86…1
…02… …02… …02… …02… …02…
2.2.1 O̲p̲e̲r̲a̲t̲i̲o̲n̲a̲l̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲
The security filter shall fulfil the following requirements:
a) receive and compile data into message and prevent
transmission to receiver prior to validation
b) compare messages with predefined patterns and validate
the classification for legality of the messages
c) release messages passing the validation with a
positive result and withhold all other messages.
d) log illegal messages and alert duty officer in
case of high frequency of illegal messages.
e) prevent unauthorized disclosure or modification
of messages at the security filter.
2.2.2 P̲e̲r̲f̲o̲r̲m̲a̲n̲c̲e̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲
The funtions of the security filter shall be performed
under the following conditions:
a) the preferred order of technology used is hardware,
firmware, and software.
b) the filter operation shall be independent of and
transparent to the ADP systems except for a minor
delay.
c) the filter must not degrade transmission capacity.
d) the design shall accommodate certification by an
independent NATO authority.
e) introduction of new predefined validation patterns
shall be facilitated.
2.2.3 A̲d̲d̲i̲t̲i̲o̲n̲a̲l̲ ̲F̲e̲a̲t̲u̲r̲e̲s̲
In addition to the main requirements considerations
shall be made to the following features:
a) operator communication (man-machine interface)
b) multiplexing (communication from one high-classified
to several low-classified ADP systems and vice
versa).
3 E̲N̲V̲I̲R̲O̲N̲M̲E̲N̲T̲
The environment is described in document No SFS/FD/001:
Functional description, chapter 4.
The important part of the environment is the security
related, which will be analyzed here for the purpose
of establishing a frame of reference for the evaluation
of various architectures.
3.1 S̲E̲C̲U̲R̲I̲T̲Y̲ ̲R̲I̲S̲K̲S̲
Security risks encompasses here all risks caused by
or influenced by the presence of a security filter
in the communication channel between two ADP systems.
It should be pointed out here that the security filter
functions are limited to those related to the message
itself and to the clearance level of the communicating
ADP systems.
The filter will not in any way modify, correct or combine
messages, but simply be transparent to all legal messages.
The historical memory of the filter is delimited to
the present message. The previous and the subsequent
message has no influence on the validation of the present
message.
Also, it should be kept in mind that the function of
the filter to monitor message traffic which should
ideally be all legal. Ideally, all inadvertent or deliberate
attempts which could lead to security breach should
be inhibited by software or hardware protection mechanisms
of the ADP systems.
It has, however, been realized that the complexity
generally encountered in such systems, the desire for
concurrent processing, sharing of data bases etc. makes
it virtually impossible, at least in the near future,
to properly verify and certify such systems for multi-security-level
operation.
So, the real purpose of the security filter is to monitor
the message traffic between ADP systems for the purpose
of detecting possible flaws in the protection mechanisms
and, perhaps, to patch known deficiencies.
This means that the filter is not the only, but the
only and ultimately t̲r̲u̲s̲t̲e̲d̲ security protection.
3.1.1 E̲n̲t̲i̲t̲i̲e̲s̲ ̲t̲o̲ ̲b̲e̲ ̲p̲r̲o̲t̲e̲c̲t̲e̲d̲
The entity to be protected is primarily the m̲e̲s̲s̲a̲g̲e̲,
as well in part as in total.
The message shall be protected against non-authorized
disclosure, modification and loss. Among these three
threats, the non-authorized disclosure has by far the
highest priority, while the threat of modification
(before the filtering), is important only if the modification
is made in such an ingenious way that the result is
another legal message.
Loss of a message poses no security risks, but may
give operational inconvenience only. All messages of
importance will require an acknowledge-of-receipt in
return, so loss of a message will cause an automatic
retransmission performed by the ADP System and/or a
message to the sender (human) of the missing acknowledgement.
Also the h̲a̲r̲d̲w̲a̲r̲e̲ and s̲o̲f̲t̲w̲a̲r̲e̲ must be protected against
non-authorized modification which could lead to non-authorized
disclosure or modification of messages.
3.1.2 S̲o̲u̲r̲c̲e̲s̲ ̲o̲f̲ ̲t̲h̲r̲e̲a̲t̲
The sources of threat, caused by or influenced by the
security filter are e.g.:
o Design errors or lack of completeness in the filter
hardware or software which could lead to security
breach
o Hardware failures which could lead to security
breach.
o Eavesdropping, electromagnetic emanation or leakage
to one of the communication lines.
o Tampering with security filter hardware or software
o Excessive power on the communication line, adversely
affecting security, momentarily or permanently.
3.1.3 R̲i̲s̲k̲s̲
The risks of prime concern for this study is considered
to be
o Transmission of a message from high to low with
a higher classification than low side level (migration)
o Transmission of a message from low to high with
a higher classification code than low side level
(corruption)
o Modification within the security filter of a message
into another legal message (corruption))
o Covert channels, around or through the security
filter
The above risks could be caused by one or more of the
threats. The risk of migration is probably the most
obvious and the security risks will often be directly
related to the type of information which was disclosed.
There may, however, be an important exception if the
disclosure is recognized by a subsequent auditing of
the log presuming that such one is available.
The mere knowledge of the disclosure in due time may
reduce or diminish the security risks.
Corruption of data may be as serious as the disclosure.
The corruption may be caused by e.g. covert software
in the security filter itself, or in a multitude of
different ways from the low side.
A covert channel is a non-authorized means of communication
which could lead to security breach.
Covert channels around the security filter are channels
which by-passes the filter function proper. Examples
are intelligible electrical cross coupling from input
to output or an error in the software which under certain
circumstances can set the validation result to a wrong
value.
3.1.4 C̲o̲u̲n̲t̲e̲r̲m̲e̲a̲s̲u̲r̲e̲s̲ ̲
Countermeasures to the threats are aimed at reducing
or removing the risks.
Among these are:
o Formal design methods, reviews, detailed description,
design verification methods, testing
o Robust and reliable design in particular of the
interface to external unsupervised lines.
Failure mode analysis of critical hardware.
Testing at high and low temperatures, approaching
the specified maximum ratings.
o TEMPEST proof design and enclosure.
TEMPEST certification.
o Use of personnel with adequate clearing, establishing
and maintaining security procedures etc. for design
as well as development and maintenance activities.
o Adequate security environment during normal operation
o Regular verification of primary functions
4 S̲E̲L̲E̲C̲T̲I̲O̲N̲ ̲O̲F̲ ̲A̲R̲C̲H̲I̲T̲E̲C̲T̲U̲R̲E̲S̲
The architecture is in broad terms the structural systems
design.
The choice of architecture is in fact the first and
often the most important step in the process of implementing
a given facility from the requirements specification.The
most important characteristics for the security filter
is the protection it provides against significant threats.
There are, however, several other significant characteristics
for a real-world security filter
The most important have been found to be
o security
o certifiability
o vulnerablility
o reliability
o flexibility
o performance
o cost
A good architecture will support at least the most
important of the characteristics. The subsequent paragraphs
will discuss how these characteristics influence choice
of architecture.
4.1 S̲E̲C̲U̲R̲I̲T̲Y̲
Referring to para. 3.1.3, the most important security
risks have been identified to
o migration
o corruption
4.1.1 M̲i̲g̲r̲a̲t̲i̲o̲n̲
Migration is the non-authorized transfer of information
from high to low. Protection against migration through
the channels is supported by a structure which imitates
a comprehensive physical access control system, i.e.
with one or more trusted gate keepers which performs
control of identification before allowing access.
The security is relying upon an "insurmountable" wall
to avoid sneakpaths out of the control of the gate
keeper.
Using this analogy, the architecture of the security
filter should exhibit at least one "gate" which is
constructed in such a way that it is robust against
penetration and inherently free of sneakpaths outside
the gate control.
The gate control shall be exhaustive, i.e. comprise
each and all of a uniquely defined set of requirements.
The denial of access shall be definitely effective
in case the identification control turns out negative.
4.1.2 C̲o̲r̲r̲u̲p̲t̲i̲o̲n̲
Corruption is the unauthorized writing to higher security
levels.
The term corruption covers here as well the erasing
of as writing of information as long as this is not
made in an authorized way.
The protection against corruption, as far as this can
be supported by the security filter, is supported by
the same means as protection against migration, the
direction is just the opposite (low to high).
4.2 C̲E̲R̲T̲I̲F̲I̲A̲B̲I̲L̲I̲T̲Y̲
Certification is the process of qualifying the filter
security performance. This process may be infeasible
or extremely expensive unless the design, design process
and documentation is made with certifiability in mind.
This is greatly facilitated by a meticulous separation
and simplification of security determining functions,
leaving all other functions to be performed in a non-trusted
area.
This means that the "gate-keeping" function shall be
separated as far as possible and be designed as simple,
clearcut logic, verifyable and reliable as possible.
These attributes shall also be valid for the types
of updates to the software which can be foreseen, e.g.
change or addition of message formats, other input
or other output protocols.
The above requirements are strongly supported by a
highly modular structure with simple and in-depth detailed
interface specifications which are as restricted as
possible for performing just the required function.
The software structure should support a multilevel
verification, e.g. a bottom-up verification, first
of the individual modules, each performing simple,
well defined functions, next package of modules, performing
a well defined task, et cetera until the final integrated
system level.
The blind persuance of such a structure will inevitably
lead to excessive amounts of hardware and code due
to excessive use of dedicated hardware and software,
This may lead to a lack of overview and clarity, because
too much participation into subfunctions tends to blur
the end: The correspondence between the requirements
specifications and the actual implementation. So, broadly
speaking, the modularisation should be brought to the
lowest (most detailed) level where there is still an
easily comprehensible correspondence to the real-world
requirements.
Of course, the internal structure of a module could
and should be subdivided into one or more levels as
applicable. Here, however, will the lower level not
be referenced to the real-world requirements but to
the internal structure and to the methods and tools
by which the function is implemented.
Here, again, the structure should be subdivided into
conceptually well understood and well defined subfunctions.
4.3 V̲U̲L̲N̲E̲R̲A̲B̲I̲L̲I̲T̲Y̲
Vulnerability is, in broad terms, described by the
ability to withstand the real-world environment without
degradation of the important performance, here the
security.
The filter design should be as robust as possible for
inadvertant or deliberate attempts to damage or change
filter functions, in particular through easily accessible
connecting lines.
The filter architecture should therefore include a
robust protecting layer in all external interfaces.
The design of all hardware and software should be made
such that errors will have limited effect only.
This could be achieved by a failure criticality analysis
of all sensitive hardware and software.
The vulnerability to design errors or failures is efficiently
minimized by checking input and output against known
properties at each transition from one module to the
next.
Within modules, there should also be an operational
verification checking of as well input to as output
from each security relevant subfunction. A convenient
means for detection of a large class of failures is
a cyclic redundancy check pattern, conveyed together
with the message throughout the filter and checked
at all intermediate stages.
4.4 R̲E̲L̲I̲A̲B̲I̲L̲I̲T̲Y̲
Reliability is an indispensable prerequisite for security.
The security of the filter relies upon the reliable
performance of the equipment.
The reliability is also a key figure for the avilability
which may be very important for some types of communication
channels.
Methods to achieve the required type and degree of
reliability are well known and implemented for purposes
with similar requirements.
4.5 F̲L̲E̲X̲I̲B̲I̲L̲I̲T̲Y̲ ̲
It is desireable that the filter architecture supports
inexpensive changes to accomodate different input/output
interfaces, multiple input/output lines and other foreseeable
needs.
The flexibility must not, however, sacrifice security
like e.g. design with embedded but not yet exploited
functions.…86…1 …02… …02… …02… …02… …02…
Flexibility can be achieved without sacrificing security
if it is based upon a modular plug-in structure. The
modularity shall be specifically oriented against functions
like e.g.
o input
performing all subfunctions necessary for presenting
a full message, presented in well defined and directly
interpretable format.
o identification
analysis of the message to identify classification
and type
o verification
verification of a message (type)
against the programmed requirements
etc. etc.
4.6 P̲E̲R̲F̲O̲R̲M̲A̲N̲C̲E̲
The critical performance measures for the security
filter are those related to security and to the completeness
of the automatic service offered.
Other performance parameters like channel capacity,
message delay, reliability etc. are all considered
to be feasible at a moderate or at least predictable
cost.
The impact from the security requirement upon the architecture
has been dicussed already.
The automatic service can be divided into the trusted
and non-trusted services. The trusted services are
part of the security system, while the non-trusted
services are desireable but not vital. Examples of
the latter is the function which, in a security operator
assisted system, decides which messages are to be routed
through the automatic validation circuit and which
are routed to the operator. Other examples are control
of data overflow and built-in testing.
In order to be able to provide inexpensive non-trusted
service, this service will have to be located into
an area which can be non-trusted but still have the
necessary access to the message stream.
It is therefore highly desireable that the architecture
supports the presence of such a non-trusted area.…86…1
…02… …02… …02… …02… …02…
4.7 C̲O̲S̲T̲
The cost/performance will have to be carefully matched
to the need. This is particularly important for a security
filter because some performance will be relatively
easy to implement at low cost while others (not always
obviously) may have significant impact on total price.
Often, a high performance can be achieved at a remarkably
low cost if it is possible to use general-purpose large-quantity
items.
The cost/performance ratio can therefore be improved
by using commercially available sub-units, but this
is of course on the precondition that the security
aspects are considered adequately.
5 S̲E̲L̲E̲C̲T̲E̲D̲ ̲A̲R̲C̲H̲I̲T̲E̲C̲T̲U̲R̲E̲S̲ ̲
There is no direct, analytic way of selecting the "right"
architecture. The architectures discussed here and
in the following subsection have therefore been selected
on the two different baselines.
a) Architectures widely used and supported by inexpensive
components and modules.
b) Idealized architecture, designed to support filter
security in an optimized way, yet technologically
and economically feasible.
The suitability for the security filter is evaluated
by an analysis of how the architecture supports the
requirements as they were set up in and discussed in
the previous chapter.
5.1 C̲O̲M̲M̲O̲N̲ ̲B̲U̲S̲ ̲
Essentially all general-purpose computer systems are
built around variants of the common bus structure.
The various versions include e.g. bus with separate
address and data lines, bus with multiplexed data and
address, dual or multiple bus principles with identical
busses or different bus structures like memory/intermodule
communication bus and separate input/output bus. In
all cases, the common bus concept is adopted because
of its obvious advantages in terms of e.g. systems
design …86…1 …02… …02… …02… …02… …02…
flexibility, flexibility to product line enhancements
and improvements, ease of repair at module level.
Most of the advantages are due to the fact that the
bus is a true multipoint to multipoint structure, easily
adaptable to as well functionally peer modules as active/possive
(master/slave) grouping.
This feature is absolutely not desireable from a security
point of view, since this architecture inherently supports
a multitude of undesireable communication paths and
hence is vulnerable to e.g. eavesdropping on the bus
and hardware and software errors in the bus communication
area.
This architecture is, however, particularly advantageous
from most other points of view.
It will therefore be examined whether the disadvantages
can be reduced or eliminated by modifications and addition.
5.1.1 B̲u̲s̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲R̲e̲s̲t̲r̲i̲c̲t̲i̲o̲n̲s̲
The undesireable communication paths can be restricted
in a multitude of ways, both hardware and software-wise.
The tools are named like privileged instructions (I/O)
mapping, (memory), physical separation of memory, Bus
Supervisor or Bus Controller. Another widely used architecture,
in particular among the more recent designs, is a distributed
structure with a few, general types of modules (CPU,
RAM)
interconnected by a "main" common bus while the support
functions (terminal, background storage, file management
system, mathematical processor) are implemented as
dedicated, self-contained subsystem, communicating
over the common bus via a general-purpose interface.
Of the tools named, the hardware-supported are the
most interesting. This is e.g. privileged I/O instructions
with hardware supervision, hardware or firmware controlled
memory mapping and Bus Supervisor and controller.
Although the tools in combination can provide almost
any desired type of restriction on transfer and access
rights, it is judged that presently known methods are
all rather vulnerable and/or quite complex. A combination
of methods (double-protection) might lead to an acceptable
security.…86…1 …02… …02… …02… …02… …02…
5.1.2 E̲x̲a̲m̲p̲l̲e̲ ̲1̲
A tentative system architecture is shown on FIG. 6-1
overleaf. The security filter may be wired for a two-directional
use or unidirectional use according to the required
security.
The structure is a common bus architecture with a single
active device, the CPU. This means that all transfers
on the bus takes place via the CPU. All other modules
are passively moving information to or from the compartmentalized
RAM.…86…1 …02… …02… …02… …02… …02…
FIG. 6-1…86…1 …02… …02… …02… …02… …02…
The Bus Supervisor and Memory Map is a combined hardware
and firmware module which performs the translation
between logical and physical addresses, a translation
which is not known by software in execution. This module
also provides at the same time for the restriction
in the available memory according to the program in
execution, and monitors/gives alarm in case of attempts
to violate the restrictions.
The Line Termination Units (LTU) are small microprocessor
units, performing all functions required for the reception,
serial to parallel conversion, error detection and
the corresponding functions for the transmitting LTU.
Data for output to the line is read from the compartmentalized
RAM, likewise, data from the line is placed into the
RAM in a standardized format.
The CPU reads the messages, one at a time, controls
the syntax and contents as far as this has been specified,
and subsequently decides upon the destination of the
message: The output-LTU, the Terminal Interface for
Security-Operator validation of free-text fields and/or
the Tape Recorder Interface for logging. The CPU has
the full control over the data transfer. Messages which
must be validated by the security operator are displayed
with the non-validated sets or fields amplified by
e.g. high intensity.
A positive validation from the operator, given by e.g.
depressing a button, is conveyed to the CPU in a "hard"
way, for example by a direct line.
The Tape Recorder Interface is simply recording the
data delivered into the compartmentalized RAM.
The RAM module is used as scratch pad memory for the
CPU, and (if necessary) for the intermediate storage
of messages. The RAM may be an integral part of the
CPU if the memory requirement is modest, e.g. less
than 64 Kbytes. In this case, the memory map function
must be extended to this internal memory.
The PROM module stores the entire program and all fixed
data. The storage technology could be ultra-violet
eraseable memories or fusible link or mask programmable,
listed in increasing order of price and security and,
at the same time in decreasing order of convenience
in maintenance.
Also the PROM may be an integral part of the CPU.
5.1.3 E̲x̲a̲m̲p̲l̲e̲ ̲2̲ ̲
The previous example represents a very flexible architecture,
and perhaps more flexibility than strictly required.
Example 2 is an architecture which can be considered
as a lower cost version of example 1 with slightly
increased security due to a less general structure.
The flexibility is sacrificed to achieve this.
See FIG. 6-2 overleaf.
This filter comprises the same functions as the previous
example, but here the CPU, RAM, PROM, Bus Supervisor
etc, Tape Recorder Interface and Terminal Interface
are all integrated into the same module. This will
reduce the price significantly and the design can still
be made in such a way that functional modularity and
verifiability is essentially maintained.
The inherent security is improved over that of example
1 because the number of communication paths is reduced
to approach the necessary minimum. The flexibility
is sacrificed because extensions in memory area, can
not be just plugged in.…86…1 …02… …02… …02… …02…
…02…
FIG. 6-2…86…1 …02… …02… …02… …02… …02…
5.2 I̲D̲E̲A̲L̲I̲Z̲E̲D̲ ̲A̲R̲C̲H̲I̲T̲E̲C̲T̲U̲R̲E̲
The idealized architecture presented here is the result
of a search for structures which in the best possible
way could support the security, taking into account
available technology and economy.
The following points have been particularly addressed
o The system may use non-trusted software and hardware,
provided it is surrounded by trusted "gate-keepers"
and the risk of covert software in such an area
is acceptable.
o Hardware/Firmware/Software split should be decided
only after a careful trade-off between the required
robustness versus flexibility.
o Data paths should be as restrictive (preferably
by hardware) as possible.
5.2.1 A̲n̲ ̲e̲x̲a̲m̲p̲l̲e̲
A functional diagram is depicted in FIG. 6-3 overleaf.
It is illustrated as a simplex line. A duplex line
will require two one-way systems.
The filter is divided into four layers, each with a
conceptually clear, well defined and non-overlapping
task and with extremely simple interfaces.
Layer 1 provides the input termination function. This
includes the electrical protection, bit synchronization,
frame synchronization, serial to parallel conversion
and error detection. The layer is physically wired
to allow input function only. The interface to layer
2 is a one-way point-to-point interface, typically
eight bit wide with two control lines.
Layer 2 is a normal microprocessor system. The hardware
and software is non-trusted, and hence only non-vital
functions can be performed here.
FIG. 6-3…86…1 …02… …02… …02… …02… …02…
Non-vital functions could be logging, operator-aided
validation (if required) built-in test generator and
checker etcetera.
It should be understood that all input and output to/from
layer 2 must be physically confined within areas authorized
for the clearance level of system high.
The interface to layer 3 could be identical to the
layer 1-2 interface, augmented with e.g. a single line
reporting back the validation result (positive/negative).
Layer 3 is the trusted, security-determining layer
which performs the automated validation of message.
Layer 3 performs the validation by analyzing the format
and contents of the message and compare these to the
specifications, accessible in the form of tables and
decision logic in read-only memory.
The validation results in one of two actions: Release
for transfer or not. A signal is given to layer 2 if
the validation is negative. This will cause a logging
of the message and possibly an alert to the operator.
Optionally, layer 2 may have detected a message which
can not be (entirely) automatically validated.
This message will be routed to the operator terminal.
The operator terminal is a video monitor with refresh
memory. The refresh memory is updated from the multi-purpose
processor.
The physical connection to the processor is off during
the validation .
After the operator's validation of the proper field(s)
(this must be a trusted process), the message is passed
to the Gate-Keeper(2), augmented with the flag(s) indicating
the operator approval.
The Gate-Keeper then validates the remaining sets and
fields of the message before release to the output.
Layer 4 is the output layer which provides electrical
protection, parallel to serial conversion, formatting,
check pattern generation and output drive.
The internal structure of the Gate-Keeper is of particular
interest. Many structures have been considered, from
the centralized to the hierarchical/tree-structure
and the multiparallel structure. The conclusion to
these considerations is that the structure which best
meets the ideal in security is one which imitates the
message structure.
An"ideal" solution to this will hence be non-ideal
or perhaps not useable for a line carrying two or more
different formats without expensive duplication. It
therefore seems adequate to seek for a resonably general
structure.
The most general structure is the centralized, with
one general-purpose processor performing the entire
validation process for all types of messages.
Another functionally oriented structure could participate
the Gate-Keeper into a format/syntax checker and a
checker for the contents.
A message-type oriented structure would ultimately
have a path for each type of message.
6. C̲O̲N̲C̲L̲U̲S̲I̲O̲N̲S̲
The purpose of this technical note is to evaluate architectures
while the final judgements should be made within a
more broad forum.
