Building Adaptive and Agile Applications Using Intrusion DetectionandResponse

�

JosephP. Loyall, ParthaP. Pal, RichardE. SchantzBBN Technologies10 MoultonStreet

Cambridge,MA 02138�jloyall, ppal,rschantz� @bbn.com

FranklinWebber410WestGreenStreet,#1

Ithaca,NYFranklin.Webber@computer.org

Abstract

Traditional Intrusion Detection Systems (IDSs) mostlywork off-line, without any direct runtime interaction orcoordination with the applications (and with other IDSs)that they aim to protect. Including intrusion detectionand response in the repertoire of an adaptive applica-tion extends its range of adaptivity and increases itschances for survival. In this paper we show how intru-sion detection and response can be used to build agile,intrusion-aware applications under the Quality Objects(QuO) adaptive distributed middleware framework.

1. Intr oduction

Most currentintrusiondetectionresearchfocusesondetectingandrecoveringfrom intrusionsonhostsor net-works,ratherthansurvivability of theapplicationsrun-ning on them. Therehasrecentlybeeneffort to enableintrusiondetectionsystems(IDSs) to interoperate[23],but for the most part, current IDSs work in isolationfrom otherIDSs, the applicationsthat they areprotect-ing, andthesecuritymanagerswhosepoliciesthey caninfluence.

We have developed a framework, Quality Objects(QuO),for building applicationsthatareawareof theirenvironmentandcanadaptto changesin it. QuO ap-plicationscanspecifytheir non-functionalrequirements(e.g., security, performance,or dependabilityrequire-ments),measurewhat is being provided, accessinter-facesfor controlling the desiredlevel of service,andadaptto changesin levelsof service.While thisresearchwasoriginally performedin theareasof network qualityof serviceandopenimplementation,we have alsobeenapplying it to the areasof survivableapplicationsand

�This work is sponsoredby DARPA undercontractsno. F30602-

97-C-0276andF30602-98-C-0187.

security.UsingtheQuOframework, we supportthefollowing

desirablesystemlevel behaviors to improve thesurviv-ability of applications:

� The development of intrusion- and security-awareapplications. These applicationscan aid IDSsandsecuritymanagers,by recognizingapplication-level patternsof usagethat might indicate intru-sionsor securitybreaches.QuO includessupportfor insertingprobesthroughoutanapplication’sim-plementationfor measuringthe level of serviceprovided. Theseprobescan also gatherinforma-tion useful to IDSs andsecuritysystems,both forrecognizingintrusionsand for gatheringinforma-tion abouttheir causesandsources.

� The development of survivable applications. Theseapplicationscan adaptto changingconditionsintheir environment, including reported intrusionsandchangesin securitypolicies.Thisenablesthemto avoid potentialintrusions,continuein thefaceofdegradedservice,andrecover from intrusionsandfaults.

� Integration and interfacing of multiple IDSs at theapplication level. While many IDSsaregoodatde-tectingcertaintypesof intrusions,a 1998DARPAISO evaluationshowedthatmultiple IDSscover alarger spaceof potentialintrusions[5]. However,mostIDSsarenot designedto work in conjunctionwith others. An applicationbuilt within the QuOframework can interfaceto multiple mechanismsandmanagers,includingmultiple IDSs. QuOpro-videsa capability, calledsystemconditionobjects,for providing a commoninterfaceto mechanismsandmanagersthat have proprietaryinterfaces. Inthismanner, QuOapplicationscanaccessinforma-tion from multiple IDSsthatdetectdifferenttypesof intrusions.Let usemphasizethat the idea of in-

1

terfacing uniformly with multiple IDSs at the ap-plication level is not to come up with a better IDS,rather to increase the coverage and security of theapplication. This is complementaryto the Com-monIntrusionDetectionFramework (CIDF) effort[23], which is developinga framework for IDS-to-IDS communicationwith anaim to perfectthe artof intrusiondetection.CIDF doesnot provide anysupportfor application-IDScooperation.

� Integrationof IDSs andother resourcemanagers.IDSs and other managers,such as security pol-icy managersor dependabilitymanagers,performcomplementaryactivities and could cooperatetoprovidehigherlevelsof service.For example,ase-curity policy managercoulduseintrusiondetectioninformationprovidedby anIDS to dynamicallyde-terminewhetherto move to a stricter level of ac-cesscontrol. Likewise,anIDS coulduseinforma-tion from a fault detectionor dependabilityman-ager to determinewhereand what type of intru-sionsto look for. QuOprovidessupportfor build-ing applicationsthataccessmanagersin many dif-ferent complementarydimensions(e.g., security,intrusiondetection,anddependability)to achievehigherlevelsof serviceandadaptability.

This paper describesthe QuO framework and ourinitial experimentsin building adaptive, agile, surviv-able applicationsusing it. We describeour experi-encesto datein integratingIDSs,securitymanagers,andothermechanismsandmanagers.Section2 providesanoverview of the QuO framework. Section3 describesthe integration of an IDS into adaptive QuO applica-tions. Section4 describesthe integrationof a depend-ability managerinto the framework for the purposeofintrusiondetectionandrecovery. Section5 describestheintegrationof a securitymanagerinto the QuO frame-work. Section6 describesexperienceto datefrom theseresearchandintegrationefforts. Section7 describesre-latedresearchprojects.Finally, Section8 presentssomeconcludingremarksandfutureplannedactivities.

2. Overview of QuO

Thedistributedobjectcomputing(DOC) paradigmisthemostadvanced,mature,flexible context availableto-day for the developmentof large-scale,network-basedsystems. In DOC, software is broken up into collec-tions of objectsdispersedthroughoutthe network, andclient objectsinvoke operationson servant objectstoaccomplishthe interactionsandfunctionalityneededtoachievethegoalsof arunningapplication.TheCORBADOC model[18] is illustratedin Figure1. A client ob-jectinvokesamethodcall onaremoteobjectasif it were

a local object. The methodcall is handledby a localstub,or proxy, which marshalsthedatafor delivery to alocalObjectRequestBroker(ORB).TheORBsendsthemethodcall acrossthenetwork usinganInter-ORBPro-tocol,suchastheInternetInter-ORBProtocol(IIOP), toanORB local to theservantobject. ThatORB deliversthemethodcall to askeleton,whichunmarshalsthedataanddeliversthemethodcall to theobject’s implementa-tion. Uponcompletionof themethod’s processing,anyreturnvaluesaredeliveredbackto theclient by the re-verseprocess.

Figure 1. The CORBA Distributed ObjectModel

DOC middlewareeffectively hidesmany of thecom-plexities of distributedcomputingsuchasremoteloca-tion interoperability, heterogeneity, commonservices,andsynchronization,exposingonly thefunctionalinter-facesof components.However, thereare increasinglymoredistributedapplicationsthatmustcontrolor reactto how servicesaredelivered,not just whatservicesaredelivered. Applicationssuchasnationalsecurity, mili-tary, healthcare,medical,multimedia,andfinancialsys-temsoften have critical requirements,suchassecurity,dependability, andrealtimeperformance.DOC middle-warefalls short in providing supportfor theserequire-ments(asdoesall otherforms of middleware)becauseit hidesthe detailsnecessaryto specify, measure,andcontrol quality of service(QoS) and doesnot providesupportfor building systemsthat canadaptto changesthat affect QoS.Becauseof this, developersof criticalapplicationsoftenfind themselvesprogrammingaroundthe distributedobjectinfrastructure,effectively gaininglittle or no advantagefrom the middleware. The prob-lemgetsworsewhenanapplicationis distributedoveraWAN, whichis inherentlymoredynamic,unpredictable,

2

andunreliablethana LAN.

Figure 2. The QuO Remote Method CallModel

We have developedQuality Objects(QuO), a DOCframework for developingdistributedapplicationsthatcanspecifytheirQoSrequirements,thesystemelementsthat needto be monitoredand controlled to measureandprovide QoS,andbehavior for adaptingto changesin QoS. In this way, QuO opensup distributed ob-ject implementations[10], providing controlof boththefunctionalaspectsof a programandits implementationstrategies,which areoftenhiddenbehindthefunctionalinterfaces.QuOprovidesthecapabilitiesfor developingDOC applicationsthatcando the following in additionto their functionalbehavior:

� Specify operating regions and service require-ments.Thiscanincludespecifyingthelevelsof de-siredsecurityor intrusionawareness(which mightchangedynamicallybaseduponchangesin theen-vironment), operatingmodes,normal and abnor-mal operatingregions, and known attack signa-tures.

� Measure environmental and system conditions.Theapplicationcaninsertandutilize probesin thesystemin orderto measureresources,characteris-tics,andbehavior. Theapplicationcanalsoreceiveinformationfrom IDSs, securitypolicy managers,andotherpropertymanagers.

� Accessto control interfaces. The applicationcanpass information to IDSs, security policy man-agers,andotherpropertymanagersto requestlev-

elsof serviceandto notify of eventsthatmight in-dicateintrusionsor otherproblems. The applica-tion canalsoaccesssystemresourcemanagementcontrolinterfacesto achieveits desiredlevel of ser-vice.

� Adapt and reconfigure. The systemcan adaptto changingconditionsat all levels, coordinatedthroughtheQuOmiddleware. For example,in re-sponseto an intrusionalert from an IDS, a secu-rity policy managermight respondby tighteningits accesscontrol. Meanwhile, the QuO middle-warecanreconfigureso that the applicationis us-ing servant objectsonly on trustedhosts. If thiscausesoverloadingof the trustedhosts,the appli-cationcanadaptby changingto amodein which itis only performingcritical operationsor is accept-ing thedegradedperformance.

The QuO functional path, illustratedin Figure 2, isa supersetof the CORBA functionalpathillustratedinFigure1.

Theoperatingregionsandservicerequirementsof theapplicationareencodedin contracts, whichdescribethepossiblestatesthesystemmightbein andactionsto takewhenthestatechanges.

QuOinsertsdelegates in theCORBA functionalpath.The delegatesproject the sameinterfacesas the stub(client-sidedelegate)andthe skeleton(server-sidedel-egate),but supportadaptive behavior uponmethodcallandreturn. That is, thedelegatechecksthestateof thesystem,asrecordedby a setof contracts,andchoosesabehavior baseduponit.

System condition objects provide interfacesto systemresources,mechanisms,andmanagers.They areusedtomeasurethestatesof particularresources,mechanisms,or managersthatarerelevant to contractsin thesystemandto passinformationto control interfacesto achievethelevelsof desiredservices.Systemconditionobjectsprovidetheability to accessdifferentIDS or securityin-terfacesin a consistentmanner. They alsoplay a role intranslatingbetweenapplication-level concepts,suchascritical operatingmodes,to resourceand mechanism-level concepts,such as encryptionmethodsor accessdescriptions.Higher-level systemconditionobjectscaninterfaceto other, lower-level systemconditionobjects,forminga treeof systemconditionobjectsthattranslatemechanismdatainto applicationdata.

QuO provides a suite of Quality Description Lan-guages(QDL), similar to CORBA’s InterfaceDescrip-tion Language(IDL), and codegenerators,similar tothe stubandskeletongeneratorsof IDL compilers,fordescribingandgeneratingthe componentsof QuO ap-plications[13], [14]. In addition,QuO providesa run-

3

time kernel,which coordinatescontractevaluationandprovides other runtime QuO services[26]. QuO alsoprovidesanextensive library of instrumentationprobes,as well as the support to insert them throughouttheremotemethodinvocation path, for gatheringperfor-mance,statistic,andvalidationinformation.

Figure 3. The QuO Gateway

QuO also provides a generalobject gateway com-ponent,which supportsinterfacing to below-the-ORBmechanismsandspecial-purposetransports,aswell asproviding a lower level point for object level decisionmaking.Theobjectgateway, illustratedin Figure3 anddescribedin more detail in [20], interceptsIIOP mes-sagesfrom theclient sideORB anddeliversIIOP mes-sagesto theserver sideORB (on themessagesend;onthemessagereturntheprocessis reversed).In themid-dle, it translatestheIIOP into thespecialpurposetrans-port protocol(e.g.,groupmulticastin a replicated,de-pendablesystem)or performsappropriateadaptationorcontrol(e.g.,in anaccesscontrolsystem,authenticatingthesenderandverifying accessrightsto thedestinationobject).

3. Integration of IDS with QuO

By integratingIDSswith QuOweaddintrusiondetec-tion andresponseto therepertoireof QuOapplications’adaptivity. As a result,agility andsurvivability of QuOapplicationsareenhanced.In this section,we describeanexperimentdemonstratinghow a commercialIDS, a

simplecustomdevelopedIDS, andapplication-specifiedintrusiondetectionareall integratedto provideintrusionawarenessand adaptive behavior in responseto intru-siondetectionat theapplicationlevel. This applicationis fairly simple,but illustratesanumberof importantca-pabilities,includingthefollowing:

� Integration of commercial and non-commercialIDSsusingtheQuOframework.

� An applicationseamlesslyinterfacing to multipleIDSs, enablingthe IDSs to cooperatethroughtheapplication layer and increasingintrusion cover-age.

� An applicationparticipatingin theintrusiondetec-tion process,by recognizingconditionsthatcanin-dicate intrusionsbut that are not detectedby theIDSs.

� An applicationadaptingto survive potentialintru-sions,triggeredby outputsof theIDSs.

In contrast,theapplicationcanusethe IDSsasmecha-nismsto turn on, turn off, or changethe level of intru-sion detectionprovidedbaseduponits operatingmodeandsecurityneeds.

3.1. Overview of the Experimental SurvivableApplication

We developedanexampleapplicationto demonstrateIDS integrationwith QuO. This experimentalapplica-tion implementsa simple inventorywith a fixed setofinventoryitems,as illustratedin Figure4. The inven-tory data is storedas files in a designateddatadirec-tory. Two serversmanagethe inventory: onemorese-cure than the other. The client program,representingthe inventorycontrol system,providesa userinterfacethroughwhich userscan identify themselves (i.e., login), addor consumeitemsin theinventory, andlog out.Both servers can respondto requestsfrom the clients,but the more secureoneauthenticates(using a simpleauthenticationscheme)eachrequestandgrantsaccessonly to certainclients. This is an exampleof the alter-nativebehaviorsthattheQuOmiddlewareis intendedtomediate.In normalmode,all clientrequestsareservicedby the non-authenticating(andthereforefaster)server.As conditionsindicatethat intrusionsare more likely,the inventorycontrolsystemadaptsto usetheauthenti-catingserverandthen,eventually, maycutoff all accessto non-privilegedusers.Theclient andserver programsaresimpleCORBA objects. No intrusiondetectionoradaptationis programmedinto them. For this example,all adaptationis built into the QuO middleware layer.We utilize threeintrusiondetectioninstrumentsin thisexample:

4

Figure 4. Storage and Runtime View of theInventory Application

� Tripwire, a commercial file system integritychecker [11];

� FileCounter, a simple,customdevelopeddirectoryaccesschecker;and

� Specifications,encodedinto the QuO contractre-gions,indicatingthe expectedroundtrip responsetime rangeand recognizingwhen client requestsare being abnormally delayed(possibly becausethey are being intercepted,or becauseof host ornetwork attacks).Note thatsucha delay, by itself,is not a good indicator for an intrusion: a benignnetwork congestioncould causea false positive.This merelyservesasan exampleof an indicatorof potentialproblemsfor anintrusionawareappli-cation.

We useTripwire to monitor the file systemsectionthat storesthe sourceand executablecodeof this ap-plicationandFileCounterto monitor thedatadirectory.Weusesystemconditionobjectsto interfaceto Tripwireand FileCounter, eachof which normally provides itsown custominterface. Thesesystemconditionobjectsprojectvaluesfrom theIDSsto theQuOlayerandpro-vide commonaccessto the control interfacesprovidedby theIDSs. Tripwire’s systemconditionobject(calledIDSValue) projectsa value to the QuO contractindi-catingwhetherthe integrity of the codestorehasbeenviolated(in Tripwire’s view). Similarly, FileCounter’ssystemcondition object (called FileAddedOrDeleted)

projectsa valueindicatingto theQuOcontractindicat-ing whetheradatafile hasbeenlost or added.

Deviation from normal operating behavior oftenpoints toward potential problems. For instance,if aserver returnsa valuethat doesnot make any senseinthe currentcontext, the client may becomesuspiciousthat the server hasbeencompromised.Similarly, if ittakes an abnormalamountof time to fulfill a requestto the inventory server, the client may becomesuspi-ciousthat thereis a problemin the network, a host,orin the server. It is straightforward to encodesuchnor-mal operatingrangesin QuO’s contractregionsandtospecify adaptive behavior to trigger when the applica-tion falls outsidenormal ranges. In this example,weusethe contractand a simple systemcondition object(called TimeTaken) to measurethe averageround triptime of methodcallsandwatchwhetherit falls outsideof the expectedrange. As we statedearlier, theremaybe a variety of causesof this abnormalbehavior, onlysomeof which aretheresultof intrusions.Determiningthe actualcausefalls somewherebetweensystemtrou-bleshootingandintrusiondetection.

3.2. BasicIntegration Ar chitecture

The example application includes the three systemcondition objectsdescribedin Section3.1: IDSValue,FileAddedOrDeleted,and TimeTaken. IDSValue, il-lustratedin Figure 5, provides the QuO interface toTripwire. Tripwire can be initialized to monitor spe-cific sectionsof a file systemfor particularattributes,suchaspermissionsor modificationtimes,of the filesand directoriesin that section. Tripwire computesadatabaseuponinitialization. At runtime,it recomputesthe database,comparesthe newly computeddatabaseagainstthe initial one,andpresentsa resultsetthat in-dicateswhatoccurredin thefile systemsectionbetweentheruns.

In ourexample,wewrapTripwire with aCORBA ob-ject interfacethat runs Tripwire periodically and ana-lyzesits output.If thereis any changein thefile systemsectionthis CORBA objectreturnsa value1, otherwiseit projectsavalue0. TheIDSValuesystemconditionob-ject is hookedto this CORBA object.Oneof its threadspollsTripwire’sCORBA wrapperto getthelatestvalue.The other threadrespondsto requestsfrom QuO con-tractsfor thelatestvalue.

Of course,if theIDS systemwereaCORBA objectal-ready, thenno CORBA wrapperis necessary. TheotherIDS componentis a CORBA object that monitorsfilesin a directory. FileCounterproducesa value1 if a fileis addedor deletedin that directory, 0 otherwise. Wehave usedthis asa simplecustomdevelopedIDS andintegratedit with QuOalongwith Tripwire, in orderto

5

Figure 5. Interfacing a System Condition Ob-ject with a COTS IDS

experimentwith multiple IDS inputs.TheQuOcontractusedin thisexampledefinesthefol-

lowing operatingregions,eachdefinedin termsof thesystemconditionobjectsdescribedabove:

� NORMAL : ����� ����������� � ���������� and��� �"!$#%�'&)(*�%+,� � and ��-.�/&���0�1212��1'3546�7��&���89��1"+�2�

� TIME SUSPECT : �)���:������������ ;<+������=��� and ��� �"!$#%�'&)(*�6!?> + �2� and��-.��&���0�121 ��1'354��"��&���89��1@+A� �

� ACCESSSUSPECT: ��� �"!$#%�'&)(*�6!?>B+DC�� xor��-.��&���0�121 ��1'354��"��&���89��1@+,C��

� INTRUSIONLIKELY : ���2�"!?#%�'&�(E�6!?>F+GC�� and��-.��&���0�121 ��1'354��"��&���89��1@+,C��

Theapplicationadaptsits behavior basedon thecur-rentregionasfollows:

� NORMAL region: client requestsareforwardedtothenon-authenticatingserver.

� TIME SUSPECTregion: A warning messageisdisplayedto the usernotifying of the unusualde-lay andurging cautionin usingthe inventorysys-tem.Theclient’s requestsarestill forwardedto thenon-authenticatingserver.

� ACCESSSUSPECTregion: A warning messageis displayedto the userstatingthata potentialac-cessviolation is detectedandthat requestsmayor

maynot begranted.Clients’ requestsarenow for-wardedto the authenticatingserver, which grantsaccessonly to privilegedusers.

� INTRUSIONLIKELY region: A warningmessageis displayedstatingthatit is highly likely thattherewasan intrusionthatcouldhave compromisedthecodeanddatastoreof theapplication,andall clientrequestsare returnedwithout making any remotecall. This implies that only someinventoryoper-ations(i.e. that could be handledlocally, for ex-ampleaqueryaboutaninventoryitemcouldbean-swered,with somedegreeof accuracy, basedonthevaluelastseen)areavailableatthisregion. Onecanextendthe rangeof availableoperationsby usingvarioustechnologiessuchasobjectcaching[27] ormaintaininga local replicaof theinventoryserver.

Figure 6. Intrusion Aware Inventory Applica-tion and Its Runtime Behavior

In addition,if at any time thereturnvalueis negative(undernormalcircumstances,theservershouldneverre-turn a negative value)that valueis reportedto the userand the contractregion is switchedto ACCESSSUS-PECT. All of theseadaptive behaviors arespecifiedinQuO’s specificationlanguages.Figure6 presentsa pic-torial representationof thefull IDS awareinventoryap-plicationaftertheQuO-IDSintegration.

6

4. Integration of QuO and Other PropertyManagers

Therearenumeroustoolsandmechanisms,whichwegenerically refer to as property managers,that man-agelow level systemresources.Thesepropertyman-agersprovide the capabilities that QuO applicationsmustmeasureandcontrol in orderto achieve andadaptto levels of servicein the system. For example, wehave developeda bandwidthmanagementsystemthatusesRSVPto reservenetwork bandwidth,providing im-provednetwork responsefor the application[1]. Simi-larly, we have built an availability examplearoundtheProteusdependabilitymanagementsystem[3], whichusesgroupcommunication,replication,andfault recov-ery to provide higherlevelsof availability to theappli-cation.Theseintegratedpropertymanagerscanbeusedto developadaptable,survivableapplicationsin thefol-lowing ways:

� They can provide information indicating anoma-lous behavior and its causes. In general,morepreciseinformation meansimproved adaptive re-sponse. For example, unusualdelay (which wehave usedasan indicatorof a potentialproblem)couldbecausedby thenetwork, by acompromisedobject,a crashedobject,a compromisedhostor acrashedhost.Givenadditionalinformation,theap-plicationcouldadaptintelligently.

� They could provide the applicationmore adapta-tion opportunities.For example,if it is thenetworkthatis thesourceof anabnormaldelay, theQuOap-plicationcanattemptto reservebandwidth,if sucha manageris available.

We have begun integratingthe Proteusdependabilitymanager[19] into the QuO-IDS exampledescribedinSection3, in orderto illustratehow otherpropertyman-agersworking in concertwith IDSs andadaptableap-plicationscanproducemoreflexible, survivableappli-cations.

The QuO-IDS integration example as describedinSection3, althoughsurvivablein thefaceof sometypesof intrusions,is hardlydependable.If oneof theserverobjectsdies,thewholeapplicationdies. UsingthePro-teusdependabilitymanager, it is possibleto make theapplicationmore dependablein the sensethat it cantoleratea certainnumberand type of faults. Proteusachievesthat by replicatingthe server objectson mul-tiple hosts.However, in thecourseof its fault recovery,Proteususuallyhidesfaultsfrom the application. Thatis, when an object crashes,Proteusrestartsit and up-datesits state,to maintaina level of dependabilitytrans-parentto theapplication.In thecontext of a survivable,

intrusion-awareapplication,faultmaskingmayhidepo-tentialcluesfor intrusion.

In conjunctionwith our research,the University ofIllinois hasdevelopeda fault notification interfaceforProteus. Using this interface we have developed aCORBA object,calledFaultObserver, that receivesno-tification from Proteusaboutfaultssuchas the unsuc-cessfulstart of a replica, crashof a replica,andcrashof a host. Eachnotificationconsistsof a setof fault in-formationwhich canbe storedandanalyzedto recog-nizepatternsof failuresthatmight indicateanintrusion.Thefollowing aretwo examplesconditionsthatFaultO-bservercurrentlyrecognizes:

� POTENTIAL INTRUSIONOFHOSTx: this indi-catesthateitherthehostnamedx crashedor replicastartattemptson this hostwereunsuccessful.

� POTENTIAL COMPROMISE OF OBJECT o:this indicatesthat eithera replicaof objecto hascrashedor attemptsto start a replica of objectohavebeenunsuccessful.

Figure 7. Integrating Proteus in the Context ofIntrusion Detection and Response

Figure7 shows threeSystemConditionsthatwehavehooked up to the FaultObserver object. Each of thetop two projectsthevalueof thePOTENTIAL INTRU-SIONconditionsfor oneof thetwo replicationhostsandthe bottomoneprojectsthe valueof the POTENTIALCOMPROMISEconditionfor a serverobject.

7

Let usconsidera simpleclient-serverapplicationthatusesProteusto replicatetheserverandin addition,alsomaintainsa non-replicatedserver. Replicationprovidesthe fault toleranceanddependability, whereasthe non-replicatedservermakesit possiblefor theapplicationtobypassthe replicationmechanismif it choosesto. Acontractfor this applicationmay includethe followingregionspredicatedon the systemconditionobjectsde-scribedabove:

� HOST SUSPECT: the HOST INTRUDED condi-tion is truefor oneor bothreplicationhosts.

� SERVER SUSPECT: the OBJECT COMPRO-MISED conditionis truefor thenon-authenticatingserver.

Theapplication’sadaptivebehavior mayinclude:

� If theapplicationis in theSERVER SUSPECTre-gion, the client’s requestswill be redirectedto thedifferentnon-replicatedserverobject.

� If the applicationis in HOST SUSPECTregion,Proteuswill be asked not to placereplicasin theintrudedhost(s).

In addition to the notificationof crashfaults,whichProteuscurrentlyprovides,the University of Illinois isalsoworkingonproviding notificationfor othertypesoffaults,suchastiming andvaluefaults,thatcouldproveusefulfor a survivableapplication.

5. Integration of QuO and Security

The survival of a QuO applicationdependson morethanjust QuO.Attackson QuO’s environment,includ-ing operatingsystems,networks, and the CORBA im-plementation,all have the potentialto completelydis-ableQuO andany applicationit supports.We assumethattheenvironmenthassomeresistancetosuchattacks.We do not assume,however, that the environmentof-fersuncircumventablesecurity, becausesuchsecurityisnot commonlyavailable. We rely on the environmentto slow down attackers and make their attacksvisibleto IDSs. QuO applicationscan then respondto manyattacksby adaptingand reconfiguring,asdescribedinprevioussections.

To enhancethedefensesof aQuOapplicationwealsooffer accesscontrol. The applicationdesignercanuseaccesscontrol at the CORBA level to ensurethat onlyauthorizedusersandprogramsmayinvoke theapplica-tion and that unauthorizedinterferencewith the appli-cation’s internalmechanismsis not possible.QuOinte-gratesaccesscontroltechnology, in theform of NetworkAssociates’OO-DTE,for this purpose.

5.1. Object-Oriented DomainTypeEnforcement(OO-DTE)

OO-DTE [24] is an object-oriented,policy-drivenmechanismfor fine-grainedaccesscontrolin distributedsystems.It is policy-drivenbecauseit basesaccesscon-trol decisionson a single,explicit, written policy gov-erninganentiredistributedapplication.Theapplicationdeveloperdescribesthe accesscontrolsonce,andOO-DTE enforcesthesecontrolsconsistentlyatall locationswherethe applicationruns. This approacheliminatestheneedfor a developerto setoperatingsystemaccesscontrolsmanuallyoneveryhost.

OO-DTEis object-orientedbecauseit controlsaccessin terms of objectsand the clients that use them. Itis fine-grainedbecauseit allows control over accesstoeachobjectandeachobjectmethodindividually. Theprotectionit offers is thereforemoreflexible than thatofferedby firewalls, for example.

OO-DTEdoesnot assumethatanapplication’s com-ponentsare all trusted to the samedegree. Instead,eachclient andobjectmustauthenticateeachotherus-ing cryptographicmeans(currentlySSL[16]).

5.2. ProtectingQuO Applications

QuO applicationsusethe OO-DTE mechanismsdi-rectly for protection. The developerwrites a securitypolicy that controlsboth the accessof usersto the ap-plicationandaccessof applicationcomponentsto eachother. The securitypolicy refersto methodsdeclaredin CORBA IDL, andin this way, it is like QuO’s otherspecificationlanguages.Thesecuritypolicy mustcoverall of the interfacesusedin the application,includingthoseusedby QuOcallbacksandby QuOdelegatesforadaptivebehaviors.

5.3. ProtectingQuO Infrastructur e

TheQuOinfrastructure,consistingof QoScontracts,systemconditionobjects,anda kernel,is built from thesameCORBA mechanismsas QuO applications. JustasapplicationclientsuseCORBA to invokemethodsonapplicationobjects,so QuO delegatesuseCORBA toinvoke methodsfor accessingsystemconditionobjects,for initializing contracts,and for causingthe kernel toevaluatecontracts.

The QuO infrastructureis thereforesubject to thesamekinds of attackas is every application. For ex-ample,a maliciousprogramcould try to trigger QuO’sadaptationmechanismsat the wrong time by changingthevalueof a systemcondition,or to disableQuOalto-getherby changingQoScontracts.We protecttheQuOinfrastructureusingOO-DTE accesscontrol just asforapplications.TheQuOinfrastructurecodemustusean

8

ORB or ORBs with OO-DTE enabled(in fact, if thiswerenot so, OO-DTE would not work becausethe in-frastructureandthedelegatescouldnotestablishmutualauthentication)andthesecuritypolicy mustdescribeac-cesscontrolfor infrastructuremethods.Thepolicy mustprohibit thedelegatesfrom damagingthe infrastructurebut still give themtheaccessthey needfor adaptation.

Theneedto protecttheQuOinfrastructurehasimpli-cationsfor the designof QuO. We assumethat threatsto QuO comefrom applicationsoftware andnot fromcodewithin the QuO infrastructurewe supply. ThenQuO mustnot allow applicationsoftwareto run in thesameprocessaddressspaceas the QuO infrastructure.OO-DTE cannotprotectQuO from maliciouscodeinthe sameaddressspacebecausethat codemay bypassCORBA altogetherand directly accessQuO codeanddatastructures. So the infrastructurewe supply withtheQuOdistribution canbeconsideredpartof a trustedcomputingbase(TCB) [4] andall untrustedextensionsto that infrastructureand applicationsare outsidethisTCB andmustrunin otheraddressspaces.For example,theQuOkernelcannotberun securelyin thesamepro-cessasanapplicationclient,eventhoughto dosowouldenhanceperformance.

5.4. Dynamic AccessControl

Accesscontrol, just like other QoS propertiesman-agedby QuO,mayneedto bechangedat runtime. Forexample,if anIDS notifiesQuOof a possibleintrusion,it maybedesirableto go into analertmodethatallowsthe intruder to be moreeasily identified. Nonessentialprocessesmay be stopped,accesscontrols tightened,andotherQoSattributessetto preestablishedvalues.Inthis exampleand others,the securitypolicy is simplyoneaspectof QoS.

Therearecurrently two waysto changeaccesscon-trolsdynamicallyin QuO:

1. usingOO-DTE’spolicy distribution tools;

2. usingQuO’sQDL languages.

For thefirst approach,a new policy is pushedfrom acentralsecuritypolicy managercomponentto all OO-DTE interceptors,which then begin implementingit.For thesecondapproach,QuO’sspecificationlanguagesareusedto specifyanalternatebehavior in whichaccessto somemethodis denied,asillustratedin theadaptable,survivableexamplein Section3.

The approachof changingaccesscontrolsis prefer-able. It appliesglobally, whereasthe secondapproachis purelylocal to thedelegatesaffectedby thespecifica-tion. Thefirstapproachisalsomoretrustworthythanthesecond,wherethe codeimplementingthe accesscon-

trol runsin a delegatein theclient’s addressspace,andthereforemaybecircumventedif theclient is malicious.

6. Experienceto DateAlthough this paperreportson work in progress,we

have to this point developedsomeexperienceaboutthenatureof applicationassistedintrusion detection,andthefeasibility of theapproachto survivability which in-tegratestogethera numberof morelocalizedprotectionandsecuritymechanismsto achievemoreeffectivecov-erage. In this sectionwe discussfour of theseareas:usingmultiple complementaryIDSs,integratingoff theshelf IDSs, integrating securitypropertymanagement,andapplicationstrategies that can complementinfras-tructurebaseddetectionandprotectionmechanisms.

6.1. Multiple, Complementary IDSs and Man-agers

It hasbeenshown from an experimentconductedbyMIT Lincoln Laboratoryfor DARPA thatmultiple IDSsystemscanbemoreeffectivein identifyingrealattacks.MIT LL evaluateda numberof IDSs,testingthemon anumberof different typesof attacks,andscoringeachaccordingto the numberof attacksthat it detectedandthe numberof falsealarmsit raised. The resultsindi-catedthat while noneof the IDSs overwhelminglyde-tectedmostof the attacks,the (hypothetical)combina-tion of thebestdetectorsfor eachattackresultedin morethan two ordersof magnitudereductionin falsealarmrateswhile improving detectionaccuracy overcommer-cial andGovernmentkeyword-basedsystems[5]. Thisprovidesthemotivationfor amodelwheretherearemul-tiple IDSs operatingconcurrently, and the needto or-ganizeandintegratetheir operationto achieve intendedapplicationorientedimprovementsin survivability.

Oneof the strengthsof theQuOframework is that itprovidessimplified supportfor interfacing to multiplemanagersandmechanisms.Partof ourcurrentdevelop-mentandexperimentationinvolvesintegratingmultiplemanagersandmechanisms.Thefirst examplewedevel-oped,describedin Section3, combineda commercialoff the shelf IDS with a customdeveloped(but simpli-fied) onetailoredfor the specificneed. We arenow inthe processof developinga demonstrationapplicationthat usesthe Proteusdependabilitymanagerin combi-nation with the Tripwire IDS. This has two potentialapplicationsurvivability benefits. First, fault detectioninformationcollectedroutinelyaspartof dependabilitysupportcanbe usedto aid the intrusiondetectionsys-tem,andsecond,thereconfigurabilityof replicationas-setscanbeusedto helprecoverfromdetectedintrusions.

Theexamplesthatwehavedeveloped,despitehavinglimited interactionbetweenmanagers,have delivered

9

theexpectedbenefits.Somemanagers,suchasmultipleIDSs,securitypolicy managers,anddependabilityman-agersarecomplementaryandcanproducehigherlevelsof servicewhenusedtogether.

6.2. Integrating COTS IDSs

If the conceptof usingmultiple specialpurposeIDSsystemsin concertis to be viable andextensible,thenweneedto beableto takeoff theshelfIDS systemsandeasilyinserttheminto variousapplicationcontexts. Totest our approachto this type of integration, we usedthe exampledescribedin section3. The collection ofintrusiondetectionsystemsavailableto uswaslimited,largely to thosesufficiently matureunderdevelopmentas part of the DARPA Information Survivability pro-gram,andthoseinexpensively availablecommercially.Fromthesewechosetwo to work with: Tripwire,acom-mercially available ID discussedearlier (and success-fully integratedwith ourconceptexample),andJAM, anexperimentalID underdevelopmentwithin theDARPAprogram.

JAM [25] is essentiallya classifiersystemthat em-ployslearningandmeta-learningtechniquesto build andrefinetheclassifier. JAM hasbeenusedsuccessfullytolearnintrusionpatternsin systemtraces[5].

Oneof themajorproblemswe encounteredin tryingto integrateJAM with QuO is a mismatchof modesofoperation.JAM currentlyoperatesin a batchmode.Al-thoughit is possibleto askit to classifya datasetin aninteractivemanner, thecurrentversiondoesnot provideany easyway to do it. Off-line usageprovidesonly asmallexperimentalfootprint to complementthecurrentruntimeadaptationin QuO,eitherasa sourceof inputsfor contractevaluationor asa mechanismto provide itsservice.BecauseJAM is gearedtowardsstandaloneus-agewith a GUI andnot embeddedusageasenvisionedin integratinginto aQuOenvironment,it did nothaveanappropriateAPI which couldeasilybeusedto integrateinto QuO’ssystemconditionconstructs.Additionally, itturnsout to be a complex job to createthe datadefini-tion anddatasetsthat JAM would needin the contextof and training for a new applicationsuchas integrat-ing with QuO.Becauseof theseissues,the experimentto integrateJAM asoneof the ID systemsin our adap-tiveapplicationcontext hasbeenpostponed,pendingtheadditionof onlineusageinterfacesto JAM.

In general,the issueswe encounteredin integratingwith Tripwire and in trying to useJAM fall into twobroadcategories:

� InterfaceRequirements:How doesan applicationinterfacewith a COTS IDS? The bestpossibilitywould bea runtimeserviceprovidedby theCOTSIDS. A programmableAPI would bethenext best

choice. The minimal requirementis that it shouldbe possibleto run the IDS from a CORBA objectandcommunicateresultsin andout. A runtimeser-viceor aprogrammableAPIsmakethis taskeasier,but humanorientedinterfaceshave beenencapsu-latedsuccessfullyaswell, mostoftenwith lessflex-ibility .

� Integration Architecture: What is an appropriatelevel of integration?Wethink thatthewaywehavearchitectedthe integrationby meansof a CORBAwrapperthat actsas a peerof a QuO componentis a generalpatternof usagethat will be repeatedwith otherCOTS systems.Dependingon thelayerin which the QuO componentoperates,the COTSsystemmayprovideinputsto contractevaluationormayprovide someservice.If theCOTS systemisalreadya CORBA objectitself, no CORBA wrap-perwill beneeded.

6.3. Integrating Security Property Management

Basedonourexperiencethusfarwith usingOO-DTEin QuO,wecanmakeseveralobservations.

First, we learnedthat incorporatingOO-DTE accesscontrol into QuO was straightforward. BecauseOO-DTE is implementedasCORBA interceptors,integrat-ing it requiredonly minimal changesto QuOcode.Us-ing OO-DTEsuccessfullywaslargelyamatterof settingupthepolicy andcryptographiccertificatescorrectlyforeachapplication.

Second,weexpectthatusingOO-DTEwill no longerbe straightforward in the presenceof mechanismsthatsupportotherproperties.For example:

� Althoughaccesscontrolin thepresenceof faulttol-erantreplicationis conceptuallysimple (just giveeach replica the sameaccessrights), the actualimplementationappearsharder. In addition tohandlingapplication-level invocations,thereplicasmustrun somereplicacoordinationprotocol. It isnot yet clearwhataccessrightsarerequiredin thisprotocol.

� Using accesscontrol in the presenceof a realtimeORB [21] will mean porting the accesscontrolmechanismsto analternativeORBandensuringin-teroperabilitybetweenORBs.

Third, building security-awareQuOapplicationswillmeanallowing applicationsto have directaccessto thesecuritypolicy to inspectit andpossiblyto modify it.Currentlythisaccessis notpossible.To makeit possiblewe mustencapsulatethe OO-DTE policy in a CORBAobjectanddefineaccessmethodsfor the policy. Once

10

thatis done,theaccessrightsthemselvesmustbeaccesscontrolledaccordingto somemeta-level securitypolicy.

6.4. Applications Participating in Intrusion De-tection

Our work with theQuOframework, variouspropertymanagers,and the integration of ID and securityhasshown that many of the QoSpropertieswith which anapplicationis concernedare the sameQoS propertiesthatcanindicateanintrusionor attack.For example,bydefinition denialof serviceattackswill manifestthem-selvesby anapplicationlosingsomeserviceuponwhichit is dependent.Likewise, flooding attacks,attacksonparticular hosts, networks, or processescan manifestthemselvesaschangesin the systemconditionsmoni-toredby QuOapplications.

We illustrated in our exampleapplicationdescribedin Section3 that QuO applicationscanspecifynormalandabnormalpatternsof behaviors in their regionsandrecognizewhenthesystemis operatingoutsidethesere-gions.Many of these,especiallyif codedcarefully, canindicatepatternsof attack. Slow service,loss of net-work resources,abnormalresponsesby server objects,etc. canall indicatepotentialattacks. The applicationcan aid IDSs by alerting them toward potential intru-sionsthatshouldbeanalyzedor by indicatingconditionsin which multiple IDSsshouldbedeployed.

In addition,QuO’s systemconditionobjectsand in-strumentationnormally usedfor bottleneckidentifica-tion and to drive resourcemanagementdecisions,canalso be usedto collect systeminformation over timethatmight recognizeintrusionsthataredifficult to rec-ognizefrom smallwindowsor groupsof events,suchasslow degradationsin service.This informationcanfeedinto off-line analysiscapability, suchas that currentlyprovidedby JAM. Oneweaknessof anomalydetectionIDSs is that they canbe trainedby intrudersover timeto recognizeanomalousbehavior asnormal. An appli-cationcouldaid in detectingthesetypesof intrusionsbycollectinginformationindicatingslow, deliberatedegra-dationsof serviceor changesin behavior patterns.

Finally, we have also shown, in the exampleappli-cationdescribedin Section4, that otherpropertyman-agersandmechanismscanbeusefulin intrusiondetec-tion. We have concentratedour initial efforts on usingtheProteusdependabilitymanager, which in normalus-age would attemptto mask faults that could indicateintrusions,to collect information about fault patterns,asa meansof helpingrecognizeintrusions. However,other mechanisms,such as resourcemanagement,re-altime scheduling,and instrumentation,could also befocusedon the job of intrusion detection. We intendto continuetheseexperiments,by using Proteus,OO-

DTE, and combinationsof IDSs in concert to createmoreintrusion-aware,adaptive,survivableapplications.

7. RelatedWork

7.1. OO-DTE

Section 5.1 describesthe OO-DTE accesscontroltechnologythatweareusingin QuO.Otherrelatedtech-nologies,however, arealsounderdevelopmentat Net-work Associates:

� an alternateimplementationof OO-DTE that de-pendson a modifiedUnix kernelfor greatersecu-rity assurance;

� analternateimplementationof OO-DTEthatofferscoarsergranularityaccesscontrolbut dependsonafirewall for enforcement.

Enhancementsto OO-DTEthatwouldsupportmulticas-ting are also underconsideration.Eachof theseOO-DTE technologiesofferspossibleimprovementsto QuOsecurity.

7.2. Intrusion DetectionSystemResearch

Therearenumerousresearcheffortsdevelopingintru-sion detectionsystems.Most of theseareanomalyde-tectionsystems,misusedetectionsystems,or a combi-nationof the two. Anomaly detectionsystemsidentifythenormalbehavior of asystem,oftenthroughtraining,anddetectbehavior thatdeviatesfrom normal. Misusedetectionsystemsdetectknown patternsof attack,suchasexploitation of known securityholesor recognitionof virussignatures.For example,Columbia’sJAM is anagent-basedmisusedetectionsystemthat usesknownpatternsof fraudulentuse of transactionsystemsandmodelsof anomalousor erranttransactionbehaviors toprotectfinancialinformationsystems[25]. MCNC’s Ji-Nao is ananomalydetectionsystemthat identifiesnor-mal profilesof network routingandmanagementproto-cols andmonitorsthe executionof protocolsin routersand switchesto recognizedeviations from the normalprofile [9]. SRI’s Emerald systemis a combinationanomalyandmisusedetectionsystem[17]. UC DavishasdevelopedaprototypecalledGrIDS [22] thatusesagraphbasedapproachto detectanomalousactivities onhostcomputersandnetwork traffic betweenthem.

Most of theseIDSs work by examining patternsofsystemcallsor network traffic. In almosteverycase,theIDS is working on behalf but completelyindependentof the applications,with no interactionor involvementfrom the applications. In contrast,we are examiningthe ways in which the interactionandcooperationbe-tweenIDSs,applications,andotherpropertymanagers

11

canimproveboththedetectionby theIDSsandthesur-vivability of the applications.In a slightly relatedwayresearchersatRSTCorp.areusingapplicationprogrambehavior profilesfor intrusiondetection[8].

Computational immunology is a special case ofanomalydetectionbasedon an analogywith biologi-cal immunesystems.In this approach,an IDS createsa knowledgeof “self” throughtraining, with the intentof distinguishingthat “self” from “other”, i.e., systemattackers. Work in this areais beingdoneat the Uni-versity of New Mexico [7] and ORA. The latter havedevelopedaCORBA immunesystemthatdefines“self”in termsof correlationsbetweenmethodinvocations.

7.3. QoS/Quorum

Therearea numberof othercomplementaryresearchefforts in QoSfor distributedsystems,many beingper-formed under the auspicesof DARPA’s Quorumpro-gram. Similar to the Universityof Illinois’ andBBN’swork in dependability[3], the Eternalproject is exam-ining the useof replicationand group communicationin CORBA applications[15]. The DIRM [1] projectcreateda capability for distributed applicationsto re-serve network bandwidthin wide-areanetworks, andadaptduring runtimeto changingnetwork resourcere-quirementand availability. The Darwin [2] projectconcentrateson network resourcemanagementandtheQoSME[6] projectdevelopeda Quality of Service(inthenetwork context) managementenvironment.Finally,the TAO [21] andTime-triggeredMethodObjects[12]projectsare examining the realtimeaspectsof QoS indistributedsystems.

7.4. CIDF

TheCommonIntrusionDetectionFramework (CIDF)effort [23], sponsoredby DARPA, is developinga com-mon data format and encodingschemefor communi-catingintrusionevent, analysis,andresponseinforma-tion betweenIDSs and IDS components. CIDF’s IDdataformat,calledGeneralizedIntrusionDetectionOb-jects(GIDOs),canrepresentsystemevents(suchassys-tem log entries),the resultsof event analysisby IDSs(suchas the recognitionof a potential intrusion), andresponsesto events in a standardformat that can betransportedcompactlyandunderstoodby otherCIDF-compliantcomponents.An InternetEngineeringTaskForce (IETF) working group, the IETF Intrusion De-tectionWorking Group(IDWG), hasgrown out of theCIDF effort. CIDF concentrateson the interactionandcooperationbetweenIDS components.Our researchiscomplementaryto this,by examiningtheinteractionbe-tweenIDSs andapplicationsandIDSs andotherprop-erty managers.

8. Conclusionsand Further Work

This work is at the intersectionof threedistinct butrelatedthemes. First, is the integratedresourceman-agementtheme,underthe organizingparadigmof im-proved Quality of Service,onedimensionof which isconcernedwith securityattributes.Thesecondis adapt-ableapplicationbehavior, motivatedprominentlyby thechangingoperatingenvironmentsandQoSrequirementsfrequentlyfoundin modern,highly internetworkeddis-tributedapplications.Third is the advancementof im-proved infrastructurefor identifying, isolating and re-spondingto informationattacksleadingto moresurviv-ableapplications.We describedexperimentalresultsinconceptdemonstrationslinking thesethree ideasas ameansof describingthe technicalconceptsunderlyingeach.

Our interim conclusionsto date are along eachofthesethreads,andhave reinforcedthe original notionsthatled to this work:

1. Securityissuescanindeedbe developedandcon-trolled within a commonQoS umbrella, makingit both more feasibleand practical to coordinatesecuritystrategy alongwith resourcemanagementstrategiesfor othercommonattributessuchasde-pendabilityandrealtimeperformance.

2. Adaptive behavior, along with infrastructuretosupportit, is bothfeasibleandpractical,asameansof providing more usersatisfyingapplicationbe-havior underchangingcircumstancesandrequire-ments.

3. An environmentwhereapplicationswork in a co-hesive and complementaryway to the infrastruc-turecomponentsthatareservicingthemis bothde-sirableandfeasible,andopensup a widespacefortradeoff studiesregardingthe mosteffective com-plementarycoverageof multiple objectives andperformanceandcostconstraints.

At amoredetailedtechnicallevel, ourconclusionsin-cludethat theQuOenvironmentcanbeeffectively usedto supportadaptivesecuritypolicy, interoperationof offtheshelf ID systemsfor improvedcoverage,andrecon-figurableapplicationbehavior, whichcanleadto amuchmoresurvivablesetof applicationservices.

Thereareavarietyof next stepsbeingpursued.Chiefamongtheseare:

1. Trial usageof the experimentalmiddleware andpropertymanagersavailablecurrently, to refineandevaluateboththesoftwareengineeringandperfor-manceissuesof QuO and the integratedmecha-nisms.

12

2. Enablingthe technologyfor developingandpack-aginguseful, reusableadaptive behaviors, so thatthey maybeexportedfrom oneenvironmentto an-other.

3. Largerscaleexperimentswith multiple,morepow-erful ID systemsprovidingvaryingdegreesof com-plementaryandoverlappingcoverage,andthe in-tegrationwith morepowerful andflexible responsemechanismsto controladaptivereconfiguration.

4. Methodsfor coordinatingapplicationlevel infor-mation collection and behavior with systemlevelresourcemanagementpolicies and strategies forthevariousQoSdimensionsunderinvestigation.

5. Integratingtheindividualviewpointsof thesystemcomponentsinto a more cohesive overall systembehavior.

9. Acknowledgements

The authorswould like to acknowledge the othermembersof theQuOteam:JohnZinky, Mark Berman,David Karr, JamesMegquier, RichardShapiro,DavidBakken, and Rodrigo Vanegas; membersof the Uni-versity of Illinois Proteusand AQuA teams: WilliamSanders,Michele Cukier, andJenniferRen; andmem-bersof theOO-DTEdevelopmentteamat NAI LabsatNetwork Associates:DurwardMcDonell,David Sames,andGregg Tally - all of whom contributedto the workdescribedin this paper.

References

[1] BBN Distributed Systems ResearchGroup, DIRMproject team. DIRM technical overview. InternetURL http://www.dist-systems.bbn.com/projects/DIRM,1998.

[2] P. Chandra,A. Fisher, C. Kosak,T. S.Ng, P. Steenkiste,E. Takahasi,andH. Zhang.Darwin: Resourcemanage-mentfor value-addedcustomizablenetwork service. InProceedings of the Sixth IEEE International Conferenceon Network Protocols (ICNP’98), Austin,October1998.

[3] M. Cukier, J. Ren, C. Sabnis,D. Henke, J. Pistole,W. Sanders,D. Bakken,M. Berman,D. Karr, andR. E.Schantz.AQuA: An adaptive architecturethatprovidesdependabledistributed objects. In Proceedings of the17th IEEE Symposium on Reliable Distributed Systems,pages245–253,October1998.

[4] DOD. Trusted Computer System Evaluation Criteria.UnitedStateDepartmentof Defense,WashingtonD.C.,December1985.

[5] Dynacorp IS. Results of the DARPAevaluation of intrusion detection sys-tems. Internet URL http://www.dyncorp-is.com/darpa/meetings/id98dec/Files/MIT-LL1999.

[6] P. Florissi. QoSME: Quality of servicemanagement environment. Internet URLhttp://www.cs.columbia.edu/dcc/quosockets/,1998.

[7] S. Forrest,S. A. Hofmeyr, andA. Somayaji.Computerimmunology. Communications of the ACM, 40(10),Oc-tober1997.

[8] A. K. Ghosh,A. Schwartzbard,andM. Schatz. Usingprogrambehavior profiles for intrusion detection. InProceedings of the Workshop on the State of the Art andFuture Directions of Intrusion Detection and Response,,February1999.

[9] J. F. Jou, S. F. Wu, F. Gong, W. R. Cleaveland, andC. Sargor. Architecturedesignof a scalableintrusiondetectionsystemfor the emerging network infrastruc-ture. Technicalreport,MCNC, Dep. of ComputerSC.North CarolinaStateUniversity, April 1997. availablefrom http://www.anr.mcnc.org/JiNao.html.

[10] G. Kiczales. Beyondtheblackbox: Openimplementa-tion. IEEE Software, January1996.

[11] G. Kim andE. Spafford. The designandimplementa-tion of Tripwire: A filesystemintegrity checker. In Pro-ceedings of the 2nd ACM Conference on Computer andCommunications Security, 1994.

[12] K. Kim. Realtimeobject-orienteddistributedsoftwareengineeringand TMO. International Journal of Soft-ware Engineering and Knowledge Engineering, July1999. to appear.

[13] J. P. Loyall, D. E. Bakken, R. E. Schantz,J. A. Zinky,D. Karr, R. Vanegas,andK. R. Anderson.QuOaspectlanguagesand their runtime integration. Proceedingsof the Fourth Workshop on Languages, Compilers andRuntime Systems for Scalable Components, May 1998.

[14] J. P. Loyall, R. E. Schantz,J. A. Zinky, and D. E.Bakken. Specifyingand measuringquality of servicein distributed object systems. In Proceedings of The1st IEEE International Symposium on Object-orientedReal-time distributed Computing (ISORC 98), April1998.

[15] L. Moser, M. Melliar-Smith,andP. Narasimhan.Con-sistentobjectreplicationin theEternalsystem.Theoryand Practice of Object Systems, 4(2):81–92,1998.

[16] Netscape Corporation. Securedsocket layer. Internet URLhttp://home.netscape.com/security/techbriefs/ssl.html,1999.

[17] P. G. Neumannand P. A. Porras. ExperiencewithEMERALD to date. In Proceedings of the 1st UsenixWorkshop on Intrusion Detection and Network Monitor-ing, April 1999.

[18] OMG. CORBA/IIOP 2.3, OMG Technical Document 98-12-01. ObjectManagementGroup,Framingham.MA,December1999.

[19] C. Sabnis,M. Cukier, J. Ren, P. Rubel, W. Sanders,D. Bakken,andD. Karr. Proteus:A flexible infrastruc-tureto implementfault tolerancein AQuA. In Proceed-ings of the IFIP International Working Conference onDependable Computing for Critical Applications, Jan-uary1999.

13

[20] R. E. Schantz,J. A. Zinky, D. A. Karr, D. E. Bakken,J. Megquier, and J. P. Loyall. An object-level gate-way supportingintegrated-propertyquality of service.In Proceedings of The 2nd IEEE International Sympo-sium on Object-oriented Real-time distributed Comput-ing (ISORC 99), May 1999.

[21] D. Schmidt, D. Levine, and S. Mungee. The designof theTAO realtimeObjectRequestBroker. ComputerCommunications, 21(4),April 1998.

[22] S. Staniford-Chen,S. Cheung,R. Crawford, M. Dil-ger, J. Frank, J. Hoagland,K. Levitt, C. Wee,R. Yip,andD. Zerkle. GrIDS -a graphbasedintrusiondetec-tion systemfor large networks. In Proceedings of the19th National Information Systems Security Conference,September1996.

[23] S.Staniford-Chen,B. Tung,andD. Schnackenberg. Thecommonintrusion detectionframework. In the Infor-mation Survivability Workshop, October1998. PositionPaper.

[24] D. F. Sterne,G. W. Tally, C. D. McDonell, D. L. Sher-man,D. L. Sames,P. X. Pasturel,andE. J.Sebes.Scal-able accesscontrol for distributed object systems. InProceedings of the 8th Usenix Security Symposium, Au-gust1999.

[25] S. Stolfo, A. Prodromidis,S. Tselepis,W. Lee,D. Fan,andP. Chan. JAM: Java agentsfor metalearningoverdistributed databases.In Proceedings of KDD-97 andAAI 97 Workshop on AI Methods in Fraud and RiskManagement, 1997.

[26] R. Vanegas, J. A. Zinky, J. P. Loyall, D. Karr, R. E.Schantz,andD. E. Bakken. QuO’s runtimesupportforquality of servicein distributedobjects.Proceedings ofMiddleware 98, the IFIP International Conference onDistributed Systems Platform and Open Distributed Pro-cessing, September1998.

[27] J.Zinky, D. Bakken,L. O’Brien, V. Krishnamurthy, andM. Ahmed.PASS- aservicefor efficient largescaledis-seminationof time varyingdatausingCORBA. In Pro-ceedings of the 19th International Conference on Dis-tributed Computing, Austin,June1999.

14