DTIC ADA464976: Improving Inter-Enclave Information Flow for a Secure Strike Planning Application

11 Pages·0.25 MB·English

by  Defense Technical Information Center

J.N.Froscher,D.M.Goldschlag,M.H.Kang,C.E.Landwehr,A.Moore,I.S.Moskowitz,C.N.Payne. \ImprovingInter-Enclave
InformationFlowforaSecureStrikePlanningApplication,"Proceedingsofthe11’thAnnualComputerSecurityApplicationsConference,
NewOrleans,Louisiana,December,1995,pages89-98.
Improving Inter-Enclave Information Flow for a Secure Strike
Planning Application
Judith N. Froscher, David M. Goldschlag, Myong H. Kang,
Carl E. Landwehr, Andrew P. Moore, Ira S. Moskowitz,
(cid:3)
Charles N. Payne
Center For High Assurance Computer Systems
Naval Research Laboratory
Washington, D.C. 20375-5337
y
+1 202.767.2389
Abstract curity levels. Too often, the result is duplication of
DoD operates many system high enclaves with lim- operations and inconsistent and untimelydata at dif-
ited information (cid:13)ow between enclaves at di(cid:11)erent se- ferent sites, which reduces the e(cid:11)ectiveness of DoD
curity levels. Too often, the result is duplication of decision support systems. This paper describes our
operations and inconsistent and untimely data at dif- solution to an instance of this problem that arises in
ferent sites, which reduces the e(cid:11)ectiveness of DoD operations of the Joint Maritime CommandInforma-
decision support systems. This paper describes our tionSystem(JMCIS), anintegratedNavyC4Isystem
solution to this problem as it arises in installations used for tracking ships and planningmissions.
of the Joint Maritime Command Information System NRL’s Center for High Assurance Computer Sys-
(JMCIS), an integrated C4I system. Our approach tems is leading a one-year project to improve infor-
views databases in more classi(cid:12)ed enclaves as poten- mation (cid:13)ow in JMCIS. Most installations have two
tial replica sites for data from less classi(cid:12)ed enclaves. JMCIS systems: a less classi(cid:12)ed (LOW) JMCIS sys-
Replicated data (cid:13)ows from lower enclaves to higher temandamoreclassi(cid:12)ed(HIGH)JMCISsystem. The
ones via one-way connections, yielding a high assur- LOW and HIGH systems each includes its own copy
ance MLS (multi-levelsecure)distributedsystem. The of the Central Data Base Server (CDBS) that serves
one-way connections are the only trusted components. many applications. Users at each level update their
This approach is based on our work on SINTRA (Se- local CDBSs independently, although updates to the
cure Information Through Replicated Architecture), LOW level system are provided periodically to the
and appliesgenerally toany collectionof systems each HIGHlevel systemviatape. The current modeofop-
running a database at system high. It complements eration does not permit HIGH users to exploit LOW
and exploits modern system design methods, which CDBS updates promptlyor consistently.
separate data management from data processing, and Aconventionalapproachtothisproblemmightcall
enables e(cid:11)ective, low-cost MLS operation within that for installing a bi-directional \guard" processor be-
paradigm. In addition to describing current JMCIS tween the two systems. Such guard systems, though
installations and our architecturalapproach, the paper increasingly prevalent, typically require a human re-
presentsourapproachforjustifyingasystem’ssecurity viewer tomonitortra(cid:14)cthey pass, because they have
and our use of formal methods to increase assurance the capability for sending tra(cid:14)c in either direction.
that security requirements are met. Our experience developing SINTRA (Secure Infor-
Keywords: Accreditation, con(cid:12)dentiality, formal mationThrough Replicated Architecture)[5]provided
methods, high assurance, replication, security. uswithadi(cid:11)erentframeworkinwhichtoconsiderpos-
sible solutions. From the SINTRA perspective, the
1 Introduction HIGH CDBS simplyneeds to include replicas of data
DoDoperates manysystemhighenclaves withlim- residing in the LOW CDBS. Instead of a potentially
ited information(cid:13)owbetween enclaves at di(cid:11)erent se- bi-directionalguard processor, the SINTRAapproach
(cid:3) callsforadevicethatpermitsone-way(cid:13)owofinforma-
Author’scurrentaddress: SecureComputingCorporation,
tionupward. Because the (cid:13)ow is upward and consists
2675LongLakeRoad,Roseville,MN 55113,+1 612.628.2700,
of structured database records, not programs to be
[email protected]
ye-mailaddresses: ffroscher, goldschlag,mkang, landwehr, executed, humanreview should not be required.
moore,[email protected] We need not alter the basic operation or the com-
89
Report Documentation Page Form Approved
OMB No. 0704-0188
Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and
maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information,
including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington
VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it

does not display a currently valid OMB control number.
1. REPORT DATE 3. DATES COVERED
1995 2. REPORT TYPE 00-00-1995 to 00-00-1995
4. TITLE AND SUBTITLE 5a. CONTRACT NUMBER
Improving Inter-Enclave Information Flow for a Secure Strike Planning
5b. GRANT NUMBER
Application
5c. PROGRAM ELEMENT NUMBER
6. AUTHOR(S) 5d. PROJECT NUMBER
5e. TASK NUMBER
5f. WORK UNIT NUMBER
7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION
Naval Research Laboratory,Center for High Assurance Computer REPORT NUMBER
Systems,4555 Overlook Avenue, SW,Washington,DC,20375
9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S)
11. SPONSOR/MONITOR’S REPORT
NUMBER(S)
12. DISTRIBUTION/AVAILABILITY STATEMENT
Approved for public release; distribution unlimited
13. SUPPLEMENTARY NOTES
14. ABSTRACT
15. SUBJECT TERMS
16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF 18. NUMBER 19a. NAME OF
ABSTRACT OF PAGES RESPONSIBLE PERSON

a. REPORT b. ABSTRACT c. THIS PAGE 10
unclassified unclassified unclassified
Standard Form 298 (Rev. 8-98)
Prescribed by ANSI Std Z39-18
J.N.Froscher,D.M.Goldschlag,M.H.Kang,C.E.Landwehr,A.Moore,I.S.Moskowitz,C.N.Payne. \ImprovingInter-Enclave
InformationFlowforaSecureStrikePlanningApplication,"Proceedingsofthe11’thAnnualComputerSecurityApplicationsConference,
NewOrleans,Louisiana,December,1995,pages89-98.
puting platforms of the systems; instead, we add a bothdefensive and o(cid:11)ensiveplans,whichmayinclude
small set of untrusted software and a single trusted air-strikes,re(cid:12)nement offorces inconsiderationofthe
device which combine to automatically replicate se- local environment, and actions to obtain more infor-
lected data from low databases to high databases in mation. JMCISapplicationsanalyzemilitarymessage
real time,while maintainingthe con(cid:12)dentiality of the tra(cid:14)c, satellite imagery,and data from other sources
highdata. Inthisway,usersofamorehighlyclassi(cid:12)ed todevelopacoherentpictureofsomepartoftheworld,
system can use data produced by a less highly classi- presented to the user as an annotated map. Users
(cid:12)ed system without degrading the security posture of can click on map objects to get more information.
the existing systems. Friendly platforms are colored blue, enemy red, and
The SINTRA approach replicates some of the ta- neutral white. Incoming information cannot be pro-
bles on the LOW CDBS as read-only tables on the cessed completely automatically, since data are often
HIGH CDBS. As LOW users update their primary ambiguous: humanintelligencemaybe needed to rec-
copies, the updates are forwarded to tables in the ognize that two messages refer to the same ship by
HIGH database. HIGH users can read, but not mod- di(cid:11)erent names or to recognize a meaningful pattern
ify, the replicated tables, so they remain consistent in a combination of sensor reports. The resolved in-
with the LOW tables. Replication is accomplished formationandsuccessfully parsed messages arestored
by a commercial database replication product, inte- in CDBS.
grated with a highassurance one-way communication Much of this information is available at the LOW
device. The technical challenge is to (cid:12)nd a way to level. It makes sense to correct the data at that level
use the replication product in an environment where if possible, because there are many LOW customers
con(cid:12)dentiality requirements dictate that there be lit- for the information.
tle or no communication, even indirectly, from the Concurrently, analysts on another JMCIS system
HIGHCDBStotheLOWCDBS,andhencenowayto running at the HIGH level are also annotating their
pass error messages orother control informationfrom maps, using informationfrom HIGH sources. For ex-
HIGHtoLOW.Thesolutionmustsatisfyboththese- ample, HIGH sources may con(cid:12)rm that one track in
curityrequirementsandthefunctionalrequirementsof fact represents two ships, or they may suggest that
reliable data replication. a white merchant ship is not neutral after all. This
Beforeasystemcanbeusedtoprocess classi(cid:12)edin- informationcan change the mapor the interpretation
formation,itmustbeaccredited forthatpurpose. We ofits objects. The LOWanalysis helps the HIGHan-
must provide rigorous evidence that the system is se- alysts, but to reduce the chance of leaking HIGH in-
cure. The SINTRA approach provides a framework formation,itisprimarilyconveyedbyphysicallymov-
that isolates critical functions, making the analysis ing data by tape. This approach limits the timeli-
tractable and amenable to mathematical techniques, nessandconsistency ofdatabetween thetwosystems.
including the application of formalmethods. The same track may be assigned a di(cid:11)erent number
The rest of this paper is organized as follows: Sec- in each system, makingcoordination di(cid:14)cult and po-
tion 2 describes the (cid:12)elded JMCIS and discusses the tentially yielding incorrect HIGH plans. The existing
securityissuesthatconstrainourdesign. Section3de- constraints on data (cid:13)ow thus either reduce the qual-
scribes SINTRA and how the SINTRA approach can ityofthedataorrequireduplicationofe(cid:11)ort, wasting
be applied to improve information (cid:13)ow between JM- scarce resources.
CIS enclaves. Section 4 describes a replicated archi- 2.2 JMCIS Architecture
tecture forJMCIS basedoncommercialproducts, but
A typical JMCIS con(cid:12)guration, shipboard or
lacking needed security controls. Section 5 describes
ashore, is a collection of workstations, all operating
howtousethecommercialreplicationarchitecture,to-
at the sameclassi(cid:12)cation level, running JMCIS appli-
gether with a high assurance one-way communication
cations that communicate over a local area network
device and suitable \wrappers," to build a practical
(LAN) ((cid:12)gure 1). One distinguished workstation pro-
system that meets the security requirements. Section
cesses external message tra(cid:14)c. Another provides the
6describesourapproachforconstructinganassurance
central database service, CDBS, using a commercial
argument that includes the use of formal methods to
relationaldatabase. OracleisusedonlandandSybase
provideevidencetoaccreditorsthatthearchitectureis
aboard ships. CDBS currently stores both national
secure. Section 7 describes our plans and conclusions
resources, including maps, image catalogs, and ref-
based on our progress to date.
erence information, and tactical resources, including
messages, plans, and tracking data. It will continue
2 JMCIS Context
to grow in importance as JMCIS applications share
2.1 JMCIS Operation data better.
JMCIS is acollectionofapplicationprogramsinte- An installationwith both LOW and HIGH JMCIS
gratedwithashareddatabase(CDBS).Ittracksships systems has two LANs ((cid:12)gure 2), each running JM-
and ground forces in support of the development of CIS workstations, CDBS, and a server that processes
90
J.N.Froscher,D.M.Goldschlag,M.H.Kang,C.E.Landwehr,A.Moore,I.S.Moskowitz,C.N.Payne. \ImprovingInter-Enclave
InformationFlowforaSecureStrikePlanningApplication,"Proceedingsofthe11’thAnnualComputerSecurityApplicationsConference,
NewOrleans,Louisiana,December,1995,pages89-98.
Message
Server tify the mechanisms that are needed to exploit these
External
leaks. This analysis can then be used to evaluate the
Comms
risk to the con(cid:12)dentiality of the HIGH information.
CDBS The requirements for protection of classi(cid:12)ed in-
formation are usually speci(cid:12)ed by the agency that
JMCIS LAN \owns" the information. In JMCIS, HIGH infor-
mation is owned by the Defense Intelligence Agency
(DIA).DIA’srequirements(DODIIS[4])arethesource
of our concern about leakage (both overt and covert).
This document also requires a careful analysis of the
system to justify its security. Our approach to this
assurance argument is presented in section 6 and is
JMCIS Client
intended to satisfy the DODIIS requirements, but is
morerigorous than is typicallyapplied. We use infor-
mation theory to quantify the capacity of the covert
Figure 1: A single JMCIS LAN. channels, and we use other formal methods to ana-
lyze both the system design and the security of criti-
cal components, and how they compose. The system
external messages. A standard serial cable with a pin
is designed so critical operation is localized, to make
cut to eliminate physically the return data path con-
this formalanalysis tractable.
nects the LOW message server to the HIGH message
server, replicating incomingLOW messages. 3 How the SINTRA Approach Fits
LOW MSeersvseagre MSeersvsaegre HIGH JMCIS
Comms Comms TheSINTRAapproachtoprovidingMLSdatabase
CDBS CDBS service isbased on physicalseparation anddatarepli-
LOW LAN HIGH LAN cation. Adatabaseexistsforeachhierarchicalsecurity
level and contains all data at that level and below.
Since users of each database are cleared for all data
it contains, commercial,untrusted database products
can be used. The databases reside onphysicallysepa-
JMCIS Client JMCIS Client ratemachines,soaccess toeach databaseiscontrolled
in the same way as access to its host machine.
The only information (cid:13)ow required by this ap-
Figure 2: Partially linked LOW and HIGH JMCIS
proach is from low to high, an inherently secure (cid:13)ow
LANs.
with respect to con(cid:12)dentiality. In this way, SIN-
TRA limits opportunities for malicious code in un-
Other informationfromthe LOW LAN can be for-
trusted applications to exploit system vulnerabilities.
warded to the HIGH LAN by disk or tape, or it can
The technical di(cid:14)culty is to ensure the consistency
beroutedmanuallythroughtheLOWmessageserver.
of the replicas without introducing downward infor-
Although this architecture preserves the con(cid:12)dential-
mation (cid:13)ow. The SINTRA approach, solutions to
ity of HIGH information,a HIGH analyst’s access to
technical problems, and prototype SINTRA imple-
LOW results is neither automaticnor e(cid:14)cient.
mentations are documented in numerous papers and
2.3 Security Requirements reports[5, 9, 3, 10].
Our goal is to provide a direct, reliable one-way A SINTRA database can be realized in centralized
connection fromthe LOWCDBS to the HIGH CDBS or distributed con(cid:12)gurations. In the centralized case,
that permits timely use of LOW results while limit- users at di(cid:11)erent levels connect to the appropriate
ingthe possibilitythat HIGH informationcan leakto databases via a Trusted Front End, which also acts
the LOW system. Leaks could occur directly through as a replica controller, propagating upwards changes
thetransmissionofsensitiveinformation,orindirectly to lower level databases. In a distributed SINTRA
throughthetransmissionofsensitiveinformationthat con(cid:12)guration, users at a given security level connect
has been encoded in covert channels (e.g., [18]). In- directlytotheirdatabase,andchangesarepropagated
formationcan be encoded by manipulatinglegitimate upwards to other databases via a trusted backend.
communication, for example, changing message for- Thenotionofsecurity enclaves meshes particularly
mats slightly (storage channels) or by manipulating well with the distributed SINTRA approach: users in
the timingof legitimateoperations (timingchannels). each enclave connect directly to their local database,
The fundamental security requirement is to quan- and the databases in di(cid:11)erent enclaves are connected
tifythe informationleakagethat is possible and iden- byreplicacontrollers. Thus,viewedfromtheSINTRA
91
J.N.Froscher,D.M.Goldschlag,M.H.Kang,C.E.Landwehr,A.Moore,I.S.Moskowitz,C.N.Payne. \ImprovingInter-Enclave
InformationFlowforaSecureStrikePlanningApplication,"Proceedingsofthe11’thAnnualComputerSecurityApplicationsConference,
NewOrleans,Louisiana,December,1995,pages89-98.
perspective, two JMCIS systems, one LOW and the store and forward device blocks any information ex-
other HIGH, each with its own CDBS, is an instance ceptfor(cid:13)owcontrol(conveyedbythetimingofsimple
of the distributed SINTRA architecture lacking only ACKs) from being transmitted from HIGH to LOW.
the trusted backend to provide the replica controller Inaddition,the amountofinformationleakagedue to
function. (cid:13)owcontrolcanbe madearbitrarilysmall(see section
5.2).
4 A Non-secure, Commercial Ap-
LOW HIGH
proach
The commercial marketplace is also (cid:12)nding many LOW Replication Oanned- wFaoyrw Satrodre HIGH
applications for replicated databases, typically to CDBS Server Device CDBS
ensure data availability, reliability, autonomy, and
fault tolerance. Consequently, commercialreplication
servers are becoming available that can provide one
Figure 4: Secure replication architecture (abstract
part of a trusted replica controller; adding the high
view).
assurance guarantee of restricted downward commu-
nication is a technical challenge that is solved in our
RSand its stable bu(cid:11)ers on the LOWside are sep-
e(cid:11)ort.
arated fromthe HIGH side by a secure one-way store
Ifcon(cid:12)dentialitywere not aconcern, we could sim-
and forward device. This device accepts data from
ply use Sybase’s Replication Server (RS) to repli-
the LOW side and guarantees that the data will be
cate LOW CDBS tables to the HIGH CDBS ((cid:12)gure
bu(cid:11)ered until the HIGH side processes them. More
3). In Sybase’s terminology, there is a single pri-
precisely, RS, running on the LOW LAN, forwards
mary database and possibly many replicates of that
datato the secure store and forwarddevice. That de-
database.
vice’sacknowledgmentisacommitmentonits partto
LOW Replication HIGH forward that information to the HIGH LAN. There-
CDBS Server CDBS
fore,RScaninterpret the acknowledgmentas atrans-
action committed response fromthe HIGH CDBS.
Figure4leavesmanydetailsunspeci(cid:12)ed. Theinter-
Figure 3: Non-secure replication architecture (ab-
faces presented by the commercial products and the
stract view).
feasibility of implementing the one-way device could
makethis approach either easy or impossible. In par-
RScontinuallymonitorsthe primarydatabase, the ticular, this approach requires a wrapper on each side
LOW CDBS, identifying the transactions that are to of the one-way device, which
bereplicated. EachsuchtransactionisqueuedinRS’s
(cid:15)
makesitappear tothe RSthat itiscommunicat-
stablestorageandforwardedtothereplicatedatabase,
ing directly with an ordinary replicated CDBS,
the HIGH CDBS. It is only removed from the queue
when it is in fact communicating with the one-
when the replicate database acknowledges that the
way device, and
transaction committed.
This con(cid:12)guration requires the downward commu- (cid:15)
makes it appear to the HIGH CDBS that it
nication of acknowledgements and other error mes-
is communicating directly with a typical client
sages from RS to the primary database and from the
which is providing a stream of SQL commands,
replicate database toRS.Inourapplication,however,
when it, too, is in fact communicating with the
there must not be signi(cid:12)cant downward communica-
one-way device.
tionfromHIGHtoLOW,sowemustbeabletodivide
this architecture into a LOW and a HIGH part and These wrappers must be designed so replication is
guarantee that no HIGH information passes directly, reliableand e(cid:14)cient and the systemas a wholeis still
and very little indirectly, to the LOW system. We manageable. They mustalsointerface e(cid:11)ectively with
must also guarantee that updates are not lost during the one-way device.
replication. Thebalanceofthissection(cid:12)rstaddresses thewrap-
pers. Since our primary realization of the store and
5 A Practical, Secure Architecture for
forward device is the Pump[11, 13], we will describe
JMCIS these wrappers with reference to the Pump, but will
Despite the di(cid:14)culties that security requirements assume nothing about the Pump beyond the already
raise for the use of commercialreplication servers, we described behavior of the store and forward device
havebeenabletoidentifyareplication-basedarchitec- (i.e.,that device’s acknowledgmentof a message from
ture for improvingthe integration of a pair of JMCIS LOW is a commitmentto forward the informationto
CDBSs inLOWand HIGHenclaves. Figure 4depicts HIGH).ThePumpitselfisdescribednext. Finally,we
the architecture simply but abstractly. The one-way describe an interim solution[8] that limits reliability,
92
J.N.Froscher,D.M.Goldschlag,M.H.Kang,C.E.Landwehr,A.Moore,I.S.Moskowitz,C.N.Payne. \ImprovingInter-Enclave
InformationFlowforaSecureStrikePlanningApplication,"Proceedingsofthe11’thAnnualComputerSecurityApplicationsConference,
NewOrleans,Louisiana,December,1995,pages89-98.
LOW HIGH
but also downward information (cid:13)ow, more than the
transactions transactions transactions transactions
Pump and mayprovide a simpleraccreditation path. Low Pump High
Wrapper Wrapper
ACKs ACKs ACKs ACKs/error messages
5.1 Locating and Specifying the Wrap-
pers
A more detailed look at the simplest replication
architecture using Sybase products[24] ((cid:12)gure 5) will Figure 7: The Pump with wrappers.
help us locate the wrappers and de(cid:12)ne their require-
ments.
Clientproducts. AllSybaseserverandclientprocesses
Low Log transactions (Primary) transactions High have uniform interfaces. The Open Server and Open
in LTL in SQL
(Primary) Transfer Replication (Replicated) Client products are sets of library functions that as-
CDBS Manager ACKs/NAKs Server ACKs/error messages CDBS sistapplicationprogrammerstowritetheirownserver
andclientprogramsthatcancommunicatewithother
Sybase servers and clients.
Figure5: Non-securereplicationarchitecture(detailed TheLOWwrapperisanapplicationprogrambased
view). on the Sybase Open Server product. Its main func-
tions are
Replication is accomplished by two major pro- (cid:15)
toreceive transactions fromRS,passthemtothe
cesses: theLogTransferManager(LTM)andRS.The
Pump, and send an ACK back to RS after re-
responsibilities of the LTM include reading the trans-
ceiving an ACK from the Pump. No error mes-
actionsfromthelogoftheprimarydatabaseandsend-
sagesaresenttoRSsinceerrorsshouldnotoccur:
ing them to RS using Log Transfer Language (LTL).
The replicated portions in HIGH CDBS should
The responsibilities of RS include storing the update
have the sametable structures andintegrity con-
transactionsinstablestorageforrecoveryandsending
straints as the (primary) tables in LOW CDBS.
them to appropriate destinations (other RSs or repli-
Also, the replicated tables are read-only tables.
cate databases).
Hence in most cases, the transaction that was
WecouldhaveputthePumpineitheroftwoplaces:
successfully executed in the LOW CDBS should
(1) between LTM and RS or (2) between RS and the
execute in the HIGH CDBS without error. If an
High CDBS. We chose the second option ((cid:12)gure 6)
errordoesoccurintheHIGH(replicate)CDBS,it
because the protocolbetween RSandthe HighCDBS
shouldbe handledbythe HIGHdatabase admin-
is an open protocol (SQL). Even though LTL is \o(cid:14)-
istratorortheHIGHwrapper; sendingerror mes-
cially" open, we could not (cid:12)nd su(cid:14)cient documenta-
sagesfromHIGHtoLOWwouldopenupacovert
tion.
channel. In any case, error codes do not usually
LOW HIGH
convey enough information,by themselves, to al-
low LOW to (cid:12)x HIGH’s problems.
Low Log LTL (Primary) SQL Pump SQL High
(Primary) Transfer Replication and (Replicate) (cid:15) tomaintainthelastreplicatedtransactionIDand
CDBS Manager Server Wrappers CDBS to return it to RS when requested.
As far as HIGH CDBS is concerned, RS is a client
that submits SQL transactions. The HIGH wrapper
Figure 6: Secure replication architecture (detailed is an application program based on both the Sybase
view). OpenClientandOpen Serverproducts; itsmainfunc-
tions are
Whenthe Pumpisinserted between RSandHIGH
(cid:15)
CDBS, it will block all acknowledgments and error toreceivetransactionsfromthePumpandsubmit
messages fromHIGH CDBS to RS. When RS sends a them to HIGH CDBS. The HIGH wrapper sends
transactiontoHIGHCDBS,itexpects either anACK anACKtothePumpaftertheHIGHCDBSsends
oranerrormessage. Also,whenHIGHCDBSreceives an ACK. If it receives an error message, it per-
a transaction, it assumes the transaction is from its forms an appropriate action and then sends an
1
client and sends a proper response (e.g., ACK). To ACK.
ful(cid:12)ll the application-speci(cid:12)c expectations of RS and
(cid:15)
to perform appropriate actions in response to
HIGH CDBS, the Pump is accompanied by two ex-
an error message. The HIGH wrapper performs
ternal processes: LOW wrapper and HIGH wrapper
((cid:12)gure 7). 1Actually, RS sends transactions as sequences of packets.
TheLOWandHIGHwrappersareapplicationpro- This requires additional bookkeeping by both the LOW and
grams based on the Sybase Open Server and Open HIGHwrappers.
93
J.N.Froscher,D.M.Goldschlag,M.H.Kang,C.E.Landwehr,A.Moore,I.S.Moskowitz,C.N.Payne. \ImprovingInter-Enclave
InformationFlowforaSecureStrikePlanningApplication,"Proceedingsofthe11’thAnnualComputerSecurityApplicationsConference,
NewOrleans,Louisiana,December,1995,pages89-98.
three classes of actions, retry, ignore, and error- TherateoftheACKsfromthePumptoLOWdoes
log. The HIGH database administrator speci(cid:12)es represent a downward (cid:13)ow of information. However,
errorcodesforeachactionclass. Forexample,the the algorithm controlling the rate at which acknowl-
error code 1205 from the Sybase SQL server is a edgments are returned is parameterized to allow the
deadlock error. Hence, if the HIGH database ad- capacity of this timing channel to be made as small
ministratorspeci(cid:12)es error code1205inretryclass as accreditors may require. Prototype Pump imple-
then the HIGH wrapper will retry the aborted mentations exist in our laboratory[17]. Recently, the
transaction. The HIGH wrapper’s default action concepts behindthePumphavebeenexpanded toad-
to an error is error-logwhich will write the error dressthecomplicationsoffairnessanddenialofservice
message to a log (cid:12)le, notify the database admin- in the network environment[12].
istrator, and then stop. As with any other trusted device, we must provide
evidence to accreditors that the Pumpwillnotunder-
Thesewrappersmimictheresponsesthatthesecure
mine a system’s security. This means that the Pump
store and forward device masks. Implementations of
mustbe analyzed on twolevels: Does its speci(cid:12)cation
this device are described next.
satisfy security requirements? Does the implementa-
5.2 The Pump tion realize the speci(cid:12)cation? The Pump’s speci(cid:12)ca-
The one-way store and forward device mustsatisfy tion has been modeled mathematically and permits
two equally important classes of requirements: secu- us to quantify the theoretical leakage rate of an im-
rity requirements, such as highly restricted informa- plementation.
tion (cid:13)ow from HIGH to LOW, and database repli- There is often a world of di(cid:11)erence between ab-
cation requirements, such as reliability, recoverabil- stract formal models (e.g., [14]) and engineering so-
ity, and performance. Even though communication lutions. Experience with an operational system will
withoutacknowledgments,such as blindwrite-up and showushowrobust ourformalmodelsareand,ifnec-
similar read-down methods may satisfy the security essary, suggest how to modifythese formalmodels to
requirements, they do not satisfy the database repli- deal with issues that are not apparent at the higher
cation requirements[11, 13]. theoretical level[16, 18].
The (NRL) Pump is a device that balances these
5.3 The Interim Solution
requirements[11, 13],which are fundamentallyincon-
Because the accreditation process can be lengthy,
(cid:13)ict [18]. An abstract view of the Pump is as follows
we have designed an interim approach[8] to imple-
((cid:12)gure 8):
menting a one-way device that is straightforward to
Pump accredit, but has unreliable communication because
messages n MA messages no ACKs are returned ((cid:12)gure 9). This means that
Low . . . High HIGH cannot inform LOW that data was corrupted
ACK ACK or lost during transmission. It is secure by inspection
buffer
and has no trusted components.
LOW HIGH
Figure 8: An Abstract view of the Pump.
Low Low Optical High Stable High
Wrapper Router Link Router Buffer Wrapper
The Pump places a non-volatile bu(cid:11)er (size n) be-
tween LOW and HIGH and sends ACKs to LOW at
probabilistic times, based upon a moving average of
the past m HIGH ACK times[11, 13]. A HIGH ACK
time is the time from when the bu(cid:11)er sends a mes- Figure 9: The interimsolution.
sage to HIGH to the timewhen HIGH sends an ACK
back. By passing ACKs to LOW at a rate related to The OPTICAL LINK is a commercially available,
HIGH’s historical response rate, the Pump provides high speed, physically reliable one-way communica-
(cid:13)ow control and reliable delivery without unduly pe- tion medium,which is already in use in many secure
nalizing performance. We emphasize that ACKs are applications. The operation of this implementationis
notpassed throughthePumpfromHIGHtoLOW.In as follows:
fact, the Pump can acknowledge receipt of messages (1) The LOW wrapper sends data to the LOW
from LOW before HIGH receives them (otherwise a Router.
bu(cid:11)er would not be necessary). Each ACK sent to (2) The LOW Router packages data and sends the
LOW is generated internally by the Pumponly in re- packets over the OPTICAL LINK.
sponse to a message from LOW. The average rate at (3)The HIGH Router receives the packets andfor-
which these ACKs are sent from the Pump to LOW wardsthemtotheSTABLEBUFFERforstorageuntil
re(cid:13)ects the average rate atwhichHIGHacknowledges the HIGH wrapper is both ready to receive them and
messages fromthe Pump. acknowledges their receipt to the STABLE BUFFER.
94
J.N.Froscher,D.M.Goldschlag,M.H.Kang,C.E.Landwehr,A.Moore,I.S.Moskowitz,C.N.Payne. \ImprovingInter-Enclave
InformationFlowforaSecureStrikePlanningApplication,"Proceedingsofthe11’thAnnualComputerSecurityApplicationsConference,
NewOrleans,Louisiana,December,1995,pages89-98.
Both the LOW Router and the OPTICAL LINK computer security assertions might include (for the
must be fast enough to process all data on the LOW Pump): Every ACK sent to LOW is delayed by the
LAN.TheHIGHRouterandSTABLEBUFFERmust current value of the movingaverage. Similarly,there
be fastenough never to lose data fromthe OPTICAL might be an assumption (again for the Pump) that
LINK and still be able to forward updates to HIGH. the lowinput/outputports are correctly connected to
HowlargemusttheSTABLEBUFFERbe? Onav- theLOWLAN;thiswouldbearequirementplacedon
erage, the replicate database must be able to process physicalandadministrativesecuritydisciplinesbythe
all updates from the primary database, so it must be computer security discipline. Each assumption about
possible to identify a bu(cid:11)er that can handle the pe- somesecurity disciplineshouldmatchanassertion for
riodic bursts of updates from the primary. In fact, another discipline; a gap in this mapping indicates a
this assumption is re(cid:13)ected in RS itself, which in- vulnerability.
cludesastablebu(cid:11)erwhosesizemustbecarefullycho- To assure that we can answer accreditors’ ques-
sen. The interim solution’s STABLE BUFFER need tions about the risks of our proposed modi(cid:12)cations
not be any bigger than RS’s stable bu(cid:11)er would be to JMCIS installations, we are developing an assur-
in a non-secure use of RS. Therefore, if the STABLE ancestrategy forarangeofJMCISinstallations. This
BUFFER (cid:12)lls, RS’s stable bu(cid:11)er would have (cid:12)lled in generic assurance strategy de(cid:12)nes a con(cid:12)dentiality
a non-secure replication architecture. In fact, since policyandidenti(cid:12)esanarchitecturethatminimizesits
theLOWRouterandthe OPTICALLINKoperate as vulnerability to existing threats. We argue the e(cid:11)ec-
fastastheLOWLAN,RS’sstablebu(cid:11)ermaybemade tiveness of this architecture and rigorously de(cid:12)ne its
much smaller, because RS will never need to wait on critical requirements. The assurance strategy forms
the LOW Router when forwardingan update. the core of the assurance argument that will need to
Datacouldbecorruptedorlostintransmissionover be produced for each JMCIS site.
theLANs oroverthe OPTICALLINK.TheSTABLE The assumptions and assertions approach has a
BUFFER could fail or over(cid:13)ow, especially if HIGH formal basis in the theory of composition, but in-
fails. Sending each packet multiple times might re- stead of composing components, we are composing
duce some of these losses, and any remaining losses speci(cid:12)cations[1],and in thiscase, speci(cid:12)cations about
could in any case be detected and (cid:13)agged when un- security properties[16]. Our approach is to use the
corrupted data (cid:12)nally enters the STABLE BUFFER. logical language and tools for analysis that are ap-
Humanintervention will be necessary to recover. propriate to the level of design: the more critical a
The lack of automaticrecovery is a consequence of property ora componentis, the morerigorous we can
thecompleteisolationofHIGHdatafromLOWinthis be in our analysis[22].
design. Because the physical design ofthe interimso- Theassurancestrategyincludesthreesections. The
lution excludes all downward channels, the accredita- (cid:12)rstmodelsthecon(cid:12)dentialitypolicyintermsofusers
tionprocess isgreatlysimpli(cid:12)ed. Theinterimsolution and the data they can access, identifying the threats
is very much like the Big Bu(cid:11)er[15], except it has no tomissionassetsandde(cid:12)ningthecriticalrequirements
trusted components. that must be satis(cid:12)ed to counter those threats. The
second section decomposes those criticalrequirements
6 Developing an Assurance Argument onto the primary INFOSEC disciplines. It compares
The system architect needs a clear and convincing candidate architectures, assessing their potential to
argument to persuade the accreditor that the risk of satisfythecon(cid:12)dentialitypolicyandotheroperational
compromise is small enough to justify operating the requirements, such as performance and availability.
system. We call this argument the assurance argu- This permits identifying the risk that remains due to
ment. In order to have such an argument at the end vulnerabilitiesofthe architecture. The thirdand(cid:12)nal
of a project, one needs an assurance strategy during section de(cid:12)nes the implementationplan, which when
the developmenttointegrate security engineering and carried out re(cid:12)nes the assurance strategy into an as-
system engineering. Initially, the assurance strategy surance argument.
records the set of assumptions and assertions[21] de- We have begun to de(cid:12)ne the overall functional re-
rived from the requirements. It is elaborated and re- quirements and operation formally in the languages
(cid:12)ned throughout the development,yieldingthe assur- of Statemate[6]. The Statemate tool, based on the
ance argument,delivered with the system. formal theory of Statecharts[7], allows modeling sys-
Assertions are statements about the security that tem behavior and graphically executing this model
a particular INFOSEC discipline (computer security, to test its validity. The Statemate speci(cid:12)cation pro-
communicationsecurity, administrative security, per- vides a formal structure for the assurance strategy
sonnel security, physical security, and emanations se- and argument. Since Statemate has a formal seman-
curity) isrequired toprovide. Assumptions document tics, we can reason formally about the description,
requirements that one discipline places on others (for both within Statemate’s logic, and using other sup-
purposes of its own e(cid:11)ectiveness). For example, the port tools and methodologies (e.g., mechanical proof
95
J.N.Froscher,D.M.Goldschlag,M.H.Kang,C.E.Landwehr,A.Moore,I.S.Moskowitz,C.N.Payne. \ImprovingInter-Enclave
InformationFlowforaSecureStrikePlanningApplication,"Proceedingsofthe11’thAnnualComputerSecurityApplicationsConference,
NewOrleans,Louisiana,December,1995,pages89-98.
checkers[2]). Security assumptions and assertions are but these architectures restrict our ability to main-
de(cid:12)ned in terms of the Statemate primitives and re- taintimelyandconsistent dataatthehighestsecurity
(cid:12)ned according to the Statemate decomposition. By levels. The SINTRA approach, though initially fo-
modeling systems from both a logical and a physical cused on providinga centralized MLS database capa-
perspective, Statemate permits specifying critical re- bility,presents interesting possibilities for distributed
quirements independently ofthe physicalarchitecture databases. For example, the MLS data (cid:13)ow needed
as a basis for comparing alternative physical parti- in JMCIS, which might have seemed an appropriate
tionings for the security they a(cid:11)ord. This is partic- application for a guard device, turns out to be a nat-
ularly important for this application because it relies uralapplicationforasimplerone-waydevice (i.e.,the
on physical distribution for security assurance. Pump) combined with commercial database replica-
Our approach to arguing the e(cid:11)ectiveness of this tion products. This isolation of critical function to
architecture promotesaslightlydi(cid:11)erent structure for small components also makes rigorous analysis, in-
the certi(cid:12)cation documentation than that advocated cluding formaland mathematicalmodeling,tractable
by other certi(cid:12)cation approaches: and signi(cid:12)cantly lowers the extra cost of high assur-
ance.
(cid:15)
It de(cid:12)nes the security requirements and opera- Nowletuswithdrawalittlefromthedetailsofthis
tions independently of the system architecture e(cid:11)ort to consider brie(cid:13)y the larger picture of tacti-
providingabasisforexplicitlycomparingalterna- cal informationprocessing in the Navy and DoD and
tivearchitectures(countermeasurepartitionings). howtheideasthathaveprovene(cid:11)ective heremightbe
Thearchitecture-independent statementofpolicy applied more widely.
is de(cid:12)ned in the Con(cid:12)dentialityPolicy. The fundamentalconcepts behind our design are
(cid:15) It integrates security and system engineering to (cid:15) to provide con(cid:12)dentiality through physical sepa-
permitexplicitlytradingo(cid:11)securityrequirements ration,
with other critical system requirements. This re-
(cid:15)
duces the redundancy (anddocumentationmain- to providedata (cid:13)ow fromless-protected to more-
protected environments through simpleand high
tenance problems) that accompanies separate se-
assurance one-way devices,
curity and development documents.
(cid:15)
(cid:15) to apply database replication concepts to coor-
It traces the residual risk through the (possibly
dinate copies of data stored at di(cid:11)erent security
many) levels of system re(cid:12)nement. At any stage
levels,
of re(cid:12)nement of the system and assurance argu-
ment it is possible to assess the risk of using the (cid:15)
to organize the system to avoid downgrading
system.
((cid:13)ows from more-protected to less-protected en-
(cid:15) vironments),and
Itis morerigorous. In additiontotesting, weuse
formal methods as a static analysis technique to (cid:15) to use commercially available technology wher-
evaluate both designs and critical components. ever possible.
We expect that this approach will simplifythe ac- Wethinkthattheapplicationoftheseconcepts ina
creditation of the system; we will report our experi- broader context of DoD tactical informationprocess-
ences with it and with the accreditation process in ing could be of great bene(cid:12)t. They imply doing as
subsequent papers. much processing as possible at the lowest legitimate
level of classi(cid:12)cation, so data can be made available
7 Concluding Discussion by replication to the largest set of customers. This
This paper reports work in progress, so we cannot will reduce the need for downgrading, which is the
draw strong conclusions yet about the e(cid:11)ect of our most expensive path between enclaves. Also, these
work on actual JMCIS operations. Nevertheless, we conceptscanbeappliedtoheterogeneousdatabasesor
believe that the approach reported here will bene(cid:12)t (cid:12)le-based storage just as well as to the homogeneous
JMCIS substantially and that the same approach will database environment we found in JMCIS.
proveusefultoothers facingtheproblemofimproving But gaining the maximumbene(cid:12)t from these con-
the(cid:13)owandcoordinationofinformationamongsecure cepts depends on having well-structured data. Cur-
enclaves. rently, many militarydatabases simply store military
Our design re(cid:13)ects the con(cid:13)uence of several e(cid:11)orts messages as text, wasting much of a database man-
toimproveinformation(cid:13)owinDoDsystemsinaprac- agement system’s power. Military messages provide
ticaland cost-e(cid:11)ective way withoutreducing security. a rich source of informationfor populatingdatabases;
C4IsystemslikeJMCIShavedevelopedenclave-based they are carefully formatted, so much parsing can be
architectures to support both security and function, done automatically. Furthermore, messages could be
96
J.N.Froscher,D.M.Goldschlag,M.H.Kang,C.E.Landwehr,A.Moore,I.S.Moskowitz,C.N.Payne.\ImprovingInter-Enclave
InformationFlowforaSecureStrikePlanningApplication,"Proceedingsofthe11’thAnnualComputerSecurityApplicationsConference,
NewOrleans,Louisiana,December,1995,pages89-98.
broken apart to separate sources from content, per- [5] J. N. Froscher, M. Kang, J. McDermott, O. Cos-
mittingthe content to be analyzed ata lowersecurity tich,andC.E.Landwehr.\APracticalApproach
level. to High Assurance Multilevel Secure Computing
We look forward to e(cid:11)orts to improve the struc- Service," Proc. 10thComputerSecurity Applica-
ture of DoD databases, separating the functions of tions Conference, Orlando, Florida,Dec. 1994.
dataprocessing fromdatamanagementtoimprovein-
formation(cid:13)ow and simplifyapplicationdevelopment. [6] D. Harel, H. Lachover, A. Naamad, A. Pnueli,
Within this context, data replication will enable low- M. Politi, R. Sherman, A. Shtull-Trauring, and
cost, yet high-assurance MLS data management. M. Trakhtenbrot. Statemate: A Working Envi-
ronment for the Development of Complex Reac-
8 Acknowledgments tiveSystem,IEEE Transactions on Software En-
This project required signi(cid:12)cant e(cid:11)ort by many gineering, 16(4):403-414,Apr 1990.
people. As project leaders, Eather Chapman and
[7] D. Harel, J. Schmidt, R. Sherman. On the For-
Maria Voreh of NRL provided technical coordination
mal Semantics of Statecharts, In Proceedings of
betweentheNRaDJMCISdevelopmentteam,Sybase,
the 2nd IEEE Symposium on Logic in Computer
andtheNRLproject team,anddevelopedthedemon-
Science, pages 54-64, Ithaca, NY, 1987.
stration scenario. Kathie Jesionowski and Michelle
Pagan of NRL are analyzingtradeo(cid:11)s in system engi-
[8] D.M.Goldschlag.\SeveralSecure StoreandFor-
neering. George Kamis of NRL and George Thomas
ward Devices," To appear in Proceedings of the
of Sierra Cybernetics provided importantbackground
3rd ACM Conference on Computer& Communi-
informationon JMCIS and other Navy MLS systems.
cations Security, New Delhi,March 1996.
John McDermottofNRL developed and analyzed the
big bu(cid:11)er approach to blind write-up and is always a
[9] M. Kang, O. Costich, and J.N. Froscher.
good source of general knowledge about Navy oper-
\A Practical Transaction Model and Untrusted
ations. Bruce Montrose of NRL designed and imple-
Transaction Manager for a Multilevel-Secure
mentedthe eventdrivenPumpontheXTS-300. Rod-
Database system" in Database Security VI: Sta-
ney PeytonofEdge ComputerSystems,Inc. designed
tus and Prospects, eds. B. Thuraisinghamand C.
andimplementedthewrappersbetweenthePumpand
Landwehr, IFIP Trans. A-21, ISBN 0 444 89889
the Sybase database products. Mary Rock of Kaman
1, Elsevier, Amsterdam,1993, pp. 285-300.
Sciences focuses on system engineering with a special
concern about accreditation issues. Finally, the in-
[10] M. H. Kang, J. N. Froscher, J. P. McDermott,
sight, encouragement, and cooperation of the JMCIS O. Costich, and R.Peyton. \Achieving Database
CDBS developers at NRaD, including Nate Schatz,
SecuritythroughDataReplication: TheSINTRA
Fran Wright, Tom Miller, Diana Snow, Rich Snow,
Prototype," Proc. 17th National Computer Secu-
Jack Sommer, and Craig Tutz, and of Stan Davis of rity Conference, Baltimore, MD, Oct., 1994, pp.
Del(cid:12)n Systems is greatly appreciated.
77-87.
References
[11] M. H. Kang and I. S. Moskowitz. \A Pump for
[1] M. Abadi and L. Lamport. \Composing Speci- rapid, reliable, secure communication,"Proceed-
(cid:12)cations." ACM Transactions on Programming ings ACM Conf.Computer& Commun.Security
Languages and Systems, 15(1):73-132, January, ’93, pp. 119 - 129,Fairfax,VA, 1993.
1993.
[12] M. H. Kang, I. S. Moskowitz and D. Lee.\A net-
[2] R. S. Boyer and J S. Moore. \A Computational work version of the Pump," Proc. of the IEEE
LogicHandbook."AcademicPress,Boston,1988. SymposiumonResearch inSecurity andPrivacy,
pp. 144 - 154, Oakland, CA, May 1995.
[3] O. Costich, and M. Kang, \Maintaining Mul-
tilevel Transaction Atomicity in MLS Database [13] M. H. Kang and I. S. Moskowitz. \A data Pump
Systems with Replicated Architecture," in forcommunication,"NRLMemoReport5540-95-
Database Security VII:Status and Prospects,eds. 7771.
T. F.Keefe and C.Landwehr, IFIP Transactions
A-47, Elsevier Science B.V., Amsterdam, ISBN: [14] Encyclopedia of Software Engineering, ed. John
0 444 81833 2, pp.329-356. Marciniak,chapteron\SecurityModels"byJohn
McLean, Wiley & Sons, 1994.
[4] Defense Intelligence Agency (DIA). DODIIS De-
2 3
veloper’s Guide for Automated Information Sys- [15] J. McDermott, \The b =c problem: how big
tems Security in DOD Intelligence Information bu(cid:11)ers overcome covert channel cynicism in
Systems, 1993. trusted database systems," in Database Security
97