PRODUCTION VERSION OF THE RECON GUARD

• Document Type: CREST
• Collection: General CIA Records
• Document Number (FOIA) /ESDN (CREST): CIA-RDP95-00972R000100100014-5
• Release Decision: RIPPUB
• Original Classification: C
• Document Page Count: 14
• Document Creation Date: December 27, 2016
• Document Release Date: August 21, 2012
• Sequence Number: 14
• Publication Date: July 5, 1984
• Content Type: MEMO

Declassified in Part - Sanitized Copy Approved for Release 2012/08/21 :CIA-RDP95-009728000100100014-5
--- ---- - az,q~G 1984
,~
5 July 1984
STAT
MEMORANDUM FOR THE RECORD
Computer/Systems Ana yst- rogrammer, IAB
SUBJECT: Production Version of the RECON Guard
1. The RECON Guard project began in 1981 and has streched into mid-
1984 with the successful conclusion of testing on the prototype system.
During the three years of development, OCR/IAB programmers created several
new software products and procedures to handle the transfer of data between
the two systems. They have also attempted to keep track of potential
problems in the handling of the different system functions and responsi-
bilities such as data security, batch ve 'nteractive ueries, and data
verification, response and query veri ication, leng y update times, and
many more. This memo attempts to point out items that must be addressed if
the RECON Guard System is redesigned for production.
a. Query: The prototype was designed as a batch system which
required the use of a SYTEK GUARD "editor" to create queries. This
editor was installed for use by programmers and was not meant for the
user or for heavy use as it proved to be very cumbersome.
Recommendation: The production RECON Guard System should be
designe as an interactive system or, least, contain a functional way
to enter queries.
b. Update Guard: The prototype system was designed to use a mag-
netic tape update procedure to demonstrate that the Guard System could
be isolated from the on-line systems. The major problems encountered
were: magnetic tapes produced by the IBM system used Ti4S and ACF2
rules that had td be bypassed by logging the tape back in as a Z-tape
and bypass label processing; the Update function of the Guard is very
slow, and requiring some 60-90 minutes to process 2,000 records,
depending on the type of checksum being calculated. On two occasions
tapes were produced by the Update Guard that could not be read.
Recommendation: The production RECON Guard System should have a
direct ink to J /MVS and eliminate the magnetic tape problem.
ADMINISTRAS~Y~C~ INTERNAL USE ONLY
Declassified in Part - Sanitized Copy Approved for Release 2012/08/21 :CIA-RDP95-009728000100100014-5
 Declassified in Part - Sanitized Copy Approved for Release 2012/08/21 :CIA-RDP95-009728000100100014-5
SUBJECT: Production Version of the RECON Guard
STAT
c. Data Security: The protection and verification of the data
being processed through the Update Guard was not addressed in the
systems design. OCR/IAB wrote software and procedures to be used
during the verification process, but this was not exercised because
only test (unclassified) data was processed. The verification software
consists of a simple comparison of the data records, before and after
processing through the Update Guard (minus length and checksum
fields). Any non-matches would have halted the RECON update cycle.
Recommendation: The production RECON Updates cycle should contain
such a feature or a similar data verification procedure.
d. ACF2 Securit Security concerns were raised on several
occasions by OCR IAB that protection of the Linear Files (production
data base) was paramount and that if testing ever progressed beyond the
test data base, that ACF2 security rules would be written to limit
access.
--~~- --
instances that the Guard System had been 'played' with during non-prime
time. There was no damage done nor intended but this does point out
that the Guard System and software must be closely controlled.
Recommendation: The production RECON Guard System should be
accesse through the ACF2 security systems for the data bases involved.
e. RECOIJ Software: The RECON software and procedures have been
modified to limit the types of commands that may be invoked. All RECON
output type commands, such as Display, Print, Save, History, etc., have
been suppressed. The user query will only be permitted to generate a
final 'hit' set containing requested terms. This hit set is then saved
and a predetermined 'Canned Query' is generated according to the
originator's address. The hit set and the Canned Query results are
combined and any record matches are eliminated from the final hit
set..This final hit set contains only those records that the users
organization has access to. The final hit set is then returned to the
Guard System for a checksum security verification.
Recommendation: CIA should consider a similar method to handle
interactive queries on the production RECON System.
f. OCR/IAB Software Security: The RECON software is controlled by
OCR/IAB an is strictly protected by ACF2 rules. This must continue to
be the case and should be considered in a production RECON Guard System.
g. Guard Software and Hardware Security: During testin of the
prototype system, the Guard System resided in the GC03 Center.
-2-
ADMINISTRATIVE - INTERNAL USE ONLY
Declassified in Part - Sanitized Copy Approved for Release 2012/08/21 :CIA-RDP95-009728000100100014-5
 Declassified in Part - Sanitized Copy Approved for Release 2012/08/21 :CIA-RDP95-009728000100100014-5
AUP'11N151KAllVt - 1WItK~~AL UJt UNLT
SUBJECT: Production Version of the RECON Guard
Recommendation: The production Guard System hardware and software
phys~ca security controls should be closely considered.
h. Guard and JES/MVS Linkage: The Guard and JES/h1YS linkage uses
80-character card image protocol for queries and variable-length
spanned-record protocol during RECUN output to the Guard. The Guard
software does not have any problems with this, but it will require
alteration if an interactive production system is required.
2. The above items are, at best, a partial list that should be
considered for a production Community RECON Guard System. Of all of the
above, only the interative RECON System represents a major task. It would
require a great deal of effort to write software to handle interactive
users and multiple organizations.
STAT
STAT
DI/OCR/SSG/SSD/IAB~
Typed Final:
K13 Aug 84)
STAT
STAT
Distribution:
Original - IAB File
1 -~C/55~
ADI~~INISTRATIVE - ItdTEFNAL USE ONLY
Declassified in Part - Sanitized Copy Approved for Release 2012/08/21 :CIA-RDP95-009728000100100014-5
 Declassified in Part -Sanitized Copy Approved for Release 2012/08/21 :CIA-RDP95-009728000100100014-5
~~
ROUTING AND RECORD SHEET
Testing of the RECON GUARD Prototype
NO - _
TO: (Officer designation, room number, and
building)
FORM ~~ O USE PREVIOUS
1_79 EDITIONS
OFFICER'S
INITIALS
~f~(1ni~!~cn(~! n ~
Proj~
Ames_Bui7Yh_ ng
COMMENTS (Number each comment to show from whom
ro whom. Draw a line across column after each comment.)
Chuck,
Attached is the RECON GUARD
Prototype Test Report, which I
showed you last week. I've sent
a copy of this to
as a draft.
I intend to submit this same
memo to go from the Director of
Security to and
Claire Rice, ere-ore, p ease
consider this official between
you and me but not the official
OS response.
~ ~~
~~~~
res~
~ D~ /~ ~:~c~c~~G~
,G~ ~e ~r~ rip .
.U/S ;7 ko,
Declassified in Part -Sanitized Copy Approved for Release 2012/08/21 :CIA-RDP95-009728000100100014-5
 Declassified in Part - Sanitized Copy Approved for Release 2012/08/21 :CIA-RDP95-009728000100100014-5
VV~~~~ ~Ji_~.1 i is .~
~ 4 III; ~~~4
MEMORANDUM FUR: RECON Project Officer
Processing and Analysis 'Technology Group,
Information Systems Research Division,
Office of Research and Development
Industrial Systems Branch,
Information Systems Security Group, OS
SUBJECT: Testing of the REL'ON GUARD Prototype
1. Between 14 May and 11 June lytS4, Information Systems
Security Group performed testing of the RECON GUARD prototype
hardware which was developed ny Sytek, Incorporated, under con-
tract to the Office of Research and Development. The objective
of this Project was to demonstrate the feasibility of the
GUARD-Device concept and its applicability to the problem of
connecting classified Agency data bases to external networks.
Preliminary examination of the test results, indicate that the
GUARD performs this function. I recommend, therefore, that the
GUARD Device be c as having passed the tests described
in attachment A.
L. Testing was performed using the Guard Test System
(GTS) which emulated a Host Access System (HAS). Use of the
GTS allowed for easier manipulation and verification of the
data than if using a live COINS HAS. Additionally, testing was
performed using only aL,000 record test RECUN data base. It
is most important to note teiat extensive testing with a live
network and a live data base must take place before a GUARD-
Device can hold ttie trusted position of protecting classified
A~ency data rrom unauthorized exposure to an external network.
.3. It is also noted that the GUARD cannot control what
Happens to data before data enters RECUN via the Update Guard,
wizile data is stored in the RECUN data base. or after data is
25X1 released from RECON via the On-line Guard.
25X1
25X1
4. The boundary of effect or the GUARD system is defined
to be these entry and exit points. There are currently no
known Trojan Horses or trap-doors i+n the MVS, JES:3 or RECUN
systems. Since RECUN GUARD, as it is presently configured
does not address the 'Crojan Ho~ssue, the GUARll system must
~ n n ~~ t r~ ~~L~-
Declassified in Part - Sanitized Copy Approved for Release 2012/08/21 :CIA-RDP95-009728000100100014-5
 Declassified in Part - Sanitized Copy Approved for Release 2012/08/21 :CIA-RDP95-009728000100100014-5
25X1
25X1
5. Testing was intended to address the trustworthiness of
the GUARD as a gateway to allow tue release of authorized data
and to prevent the release of unauthorized data. It did n~r_
for instance, consider issues such as throughput.
~ All currently planned testing has been accomplished.
Attachments:
A. RECON GUARD Test Plan (Attached)
F3. RECON GUARD Test Results (Pending)
Ch e In Syst s Secu ity Group
Scl~ ~sa~
nn~~renrni-ri n i
Declassified in Part - Sanitized Copy Approved for Release 2012/08/21 :CIA-RDP95-009728000100100014-5
 Declassified in Part - Sanitized Copy Approved for Release 2012/08/21 :CIA-RDP95-009728000100100014-5
The tests outlined in the following pages were performed
based upon several assumptions. The GUARD must be operated
within these constraints for the test results to remain valid.
These assumptions are as follows:
One AGB1 is dedicated to each site for this test (i.e.,
State, llIA, and NSA).
Individuals at each site are cleared system high and
identified to the networx; terminals are physically
located in system ,sign approved areas.
Sufficient physical and personnel security standards for
system high processing are afforded to the GUARD hardware
and the Security Officer Interface Device (SOLD).
'The GUARD cannot control what happens to data oefore data
enters RECON via the Update Guard, while data is stored
in the RECON data base, or after data is released from
RECON via the Unline Guard. The boundary of effect of
the GUAiZll system is defined to oe these entry and exit
points.
Testing was performed using identical secret keys for the
multiple sites.
Testing was performed using the Guard Test System (GTS)
which emulated a Host Access System (HAS). Use of the
GTS allowed for easier manipulation and verification of
the data than if using a live COINS HAS.
A Trap-Door program was utilized to allow for limited
data manipulation of RECON records. Releasable RECUN
records could probably be created within the RECON data
base given the knowledge of the appropriate secret key,
sufficient time, systems tcriowledge, and accessioility.
Testing was performed using only a 2,000 record test
Rt;CON Data base .
There are currently no known Trojan Horses or trap-doors
in the MVS, JES3 or RECUN systems. Since the GUARD as it
is presently configured, does not address the Trojan
Horse issue, the GUARD system must be assessed on tnis
basis.
1 See the glossary of definitions on tine following page.
Declassified in Part - Sanitized Copy Approved for Release 2012/08/21 :CIA-RDP95-009728000100100014-5
 Declassified in Part - Sanitized Copy Approved for Release 2012/08/21 :CIA-RDP95-009728000100100014-5
L;
Tne following; definitions will be used ttirougnout this
document:
A record or a RECUN record is defined to ue a collection
of eta which meets the ormat requirements for entrance
to RECUN, or such a collection of data after it teas peen
marked for distribution to specified communities.
~' A secret ice or key and initial value consists of a
cryptogr~c type o numeric cey va ue and initial value
used by the DES algorithm to encrypt or decrypt a given
data stream. Both the secret ke and the category expres-
sion reside ici an erasao a programmable read only memory
(EPROM) that is located on one or more Authentication
Generator Board (AGBj. .
An authenticator is a digital signature attached to a
recor It is either a blank field called a null authen-
ticator or it is a field of the record containing a va ue
ca~ated for the record with an algorithm such as DES
using tine record itself and a secret key. Authenticators
are used to control release and distribution of RECON
records.
A cate~or care be identified for a record by specific
fie s o the record. A Boolean function called a
category expression is associated with each releasable
eta set. ~f t- le ategory expression when applied to a
given record evaluates to "TRUE," then the authenticator
is computed with the secret key associated with that
category expression.
A record is a candidate for release ~ the GUARD or the
GUARD is ant orize to re ease a record if and only ii
there is a category expression an secret Key within the
GUARD which is associated with the record.
Z
Declassified in Part - Sanitized Copy Approved for Release 2012/08/21 :CIA-RDP95-009728000100100014-5
 I I
Declassified in Part - Sanitized Copy Approv(led (`for Release 2012/08/21 :CIA-RDP95-009728000100100014-5
~ 1 .j, ~ ~ ~
Review and confirm teat Theorems and Corollaries are valid in
the "GUARD System Verification Report," dated 3 May 19134.
Review and confirm "vmulti pl" master, dated li May 1984.
Review and confirm "vupisly pl" (outer block of code that runs
on the Update Guard Input Slave Board), dated 11 May 19134.
Review and confirm "vupdate pl" master, dated 11 i~1ay 19134.
Review and confirm "vassembly al", dated 11 May 1984.
Review and confirm "vagbmod al", dated 4 January 19134.
Review and confirm "vagb pl" (outer block of code that runs on
the AGB), dated 4 January 19134.
Evaluate security relevant material from "Guard System
Operation and Maintenance" report, dated lb April 1984.
Evaluate security relevant material from "KECON IV Users
Manual," dated April 1980.
Declassified in Part - Sanitized Copy Approved for Release 2012/08/21 :CIA-RDP95-009728000100100014-5
 Declassified in Part - Sanitized Copy Approved for Release 2012/08/21 :CIA-RDP95-009728000100100014-5
1. Develop 2U test queries.
2. Run the test queries directly through the RECON Test Data
Base without interfacing with the GUARD.
3. Run the test queries through the GUARD System utilizing all
possible AGB's and sites (nine runs per query).
4. Compare the results of the test runs to ensure functional
operation of the GTS and ensure that improper release or
spillage has not taken place.
SECURITY VULNERABILITY DETERMINATION
Operational Tests
1. Incorrect EPROM insertion/removal.
2. Induced errors on the Update Guard (UDG).
a. Write to an output tape where the records from the
input tape exceed tue length of the output tape.
b. Invalid record test requiring improperly formatted
input tapes.
1) A record too short.
l) A record longer tuan the UDG buffer (tU48 nytes).
3) A record with an incorrect checksum.
4) A record that already has an authenticator.
5) A record with a category expression unknown to the
UDG.
ti) A record that goes off the end of the input tape.
7) A record with incorrect tape parity.
Declassified in Part - Sanitized Copy Approved for Release 2012/08/21 :CIA-RDP95-009728000100100014-5
 Declassified in Part - Sanitized Copy Approved for Release 2012/08/21 :CIA-RDP95-009728000100100014-5
c. Configuration test illustrating UDG's reaction to
changes in slave Board configuration and placement.
1) Kemove output slave processor uoard.
L) Start system witiz drives off load-point and offline.
:3j Start system with drives powered off.
d. hfanipulation of alarm system and auditing device
connection.
1) Unplug the alarm cable nefore starting UDG.
2) Unplug the audit cable before starting UllG.
3) Unplug the alarm cable while UllG is running.
4) Unplug the audit cable while UDG is running.
e. Abnormal AGB data EPRUM contents.
1) Improper checksum.
L) Corrupted secret xey.
3) Corrupted initial value.
4) Corrupted stock plain text.
5) Corrupted cyphertext.
f. Aunormal tape contents.
1) A tape without IBM labels.
2) A tape wita improper IIiM labels.
Abnormal tape procedures..
1) Attempt to combine multiple input tapes
single output tape.
2) Take drives offline.
3) Alter tape position by hand.
4) Put write ring on input tape.
S) Remove write ring from output tape.
given a
5
r"'(1~IClf'1Ct~ITi A 1
Declassified in Part - Sanitized Copy Approved for Release 2012/08/21 :CIA-RDP95-009728000100100014-5
 Declassified in Part - Sanitized Copy Approved for Release 2012/08/21 :CIA-RDP95-009728000100100014-5
.i. Induced errors on Online Guard (OLG).
a. Manipulation of alarm system and auditing device
connection.
1) Unplug the alarm cable before starting OLG.
2) Unplug the audit cable before starting OLG.
:~) Unplug the alarm cable while OLG is running.
4) Unplug the audit cable while ULG is running.
b.
Random start, stop and power disruption.
GUARD System Outage Tests
1.
Random start/stop during record transmission.
a.
b.
c.
Power off the protocol converter during record
transmission.
Reset GUARD during record transmission.
Power off GUARD during record transmission.
~.
Random unplugging of Online Guard.
a.
u.
During record transmission.
After system configuration but prior to query
submission.
3.
Random switching/removal of AGB's.
a.
b.
c.
Removal of AGB during record transmission.
Insertion of new AGB after system configuration but
prior to query submission.
Insertion of new AGB during record transmission.
4.
Disruption of Security Officer Interface Device.
a.
b.
c.
By random/intermittent power down.
Incorrect keyboard entries.
Preparation of EPRUM on a EPKUM ourner whicri is not a
part of the SOID.
5.
Inducement of tape errors for Update Guarci.
a. Tape too short for specified records.
b Random manip~.lation of alarm, audit device, etc.
c. Invalid data.
b
Declassified in Part - Sanitized Copy Approved for Release 2012/08/21 :CIA-RDP95-009728000100100014-5
 Declassified in Part - Sanitized Copy Approved for Release 2012/08/21 :CIA-RDP95-009728000100100014-5
\ 'r ~.)
.~
~~fanipulation of
No AGB.
Single AGB
wit11 multiple category expressions.
3. Single AGB with multiple category expressions and secret
keys.
4. Multiple AGB's with same category expression and secret key.
5. Multiple AGB's with
6. Multiple AGB's with
7. Multiple AGB's with
different category expressions.
same secret trey.
different secret keys.
8. Random manipulation of AGB's from one site and office/
organization identification from another site.
9. General manipulation of AGB sites, secret treys and release
categories.
Trap - lloor Program
1. hlanipulate data without modifying authenticator.
2. Modify only authenticator.
3. Modify both authenticator and data.
4. Attempt to manipulate data in such a way to achieve same
checksum.
S. Attempt to manipulate data in such a way to ac[iieve same
authenticator.
u. [Modify data, attempt to release, then return data to
original condition.
7. Modify data and/or authenticator, determine anti append new
checksum.
d. Modify data and/or authenticator, determine and append new
authenticator.
y. Reautiienticate records in test iZgCUN.
10. Alteration of record content.
Declassified in Part - Sanitized Copy Approved for Release 2012/08/21 :CIA-RDP95-009728000100100014-5
 I 1
Declassified in Part - Sanitized Copy Approved for Release 2012/08/21 :CIA-RDP95-009728000100100014-5
Covert Signalling Cnannel Tests Attempt to Transmit Data:
1. Modulation of hands~zake sequence.
a. Time lapse Between error responses.
b. Device Interrupt error.
c. Number of interrupts/time period.
d. Use of CANCEL and STATUS acknowledge requests.
2. Modulation of error messages through manipulation of records
via the trap door program.
3. Modulations of legitimate traffic (intact RECUN records).
Declassified in Part - Sanitized Copy Approved for Release 2012/08/21 :CIA-RDP95-009728000100100014-5