NCSC-TG-028 Assessing Controlled Access Protection

7/30/2019 NCSC-TG-028 Assessing Controlled Access Protection

1/83

N A T I O N A J .C B W P U T E HE C U R I T Y ? ' - ' .CENTER

NCSC-TG-028 VERSION-1NATIONALCOMPUTERSECURITY CENTER

J>" - . . ;!.:fc'-S ::'.i.\-.i

ASSESSINGCONTROLLED ACCESSPROTECTION

1 9 9 8 0 3 0 9 2 9 4 25 May1992

Approvedfo rPublicRelease:DistributionUnlimited -,;.:;,:;I i


2/83

Accession Number :3738 PublicationDate:M ay 25,1992 Title:AssessingControlled AccessProtectionCorporate AuthorO r Publisher:NationalComputerSecurityCenter,9000SavageRd.,Ft.G G Meade,M D 2Repor tNumber :NCSC-TG-028Descriptors,Keywords:RainbowTechnicalGuideline Controlled AccessComputer EvaluationCriteriaProtectionAIS Pages:00069CatalogedDate:Sep15,1992Document Type:H C N umber of CopiesIn Library:000001Record ID :24734


3/83

N C S C - T G - 0 2 8 LibraryN o.-238,986 Version1

FOREWORDTheNationalComputerSecurityCenterispublishingAssessingControlledAccessProtectionaspartftheRainboweries"fdocumentsourTechnicalGuidelinesProgramproduces.nheRainbowSer ies ,w ediscussndetailthefeatureso ftheDepartmentofDefenseTrustedComputerSystemEvaluationCriteria( D o D 5200.28-STD)ndprovideguidancefo rmeetingeachrequirement.heNationalComputerSecurityCenter,throughitsTrustedProductEvaluationProgram,evaluates thesecu-rityfeatureso fcommercially-producedcomputersystems.Together,theseprogramsensurethatorganizationsarecapableofprotectingtheirimportantdatawithtrustedcomputersystems.AssessingControlledAccessProtectionexplainsthecontrolledaccessprotectionre-quirementsoftheTrustedComputerSystemEvaluationCriteria.Theguide'stargetaudienceisthetechnicalanalyststaskedbytheDepartmentofDefensecomponentstodeterminewhetherasystemmeetstheserequirements.A stheDirector,NationalComputerSecurityCenter,Iinviteyourrecommendationsfo rrevisiontothistechnicalguide l ine .W eplantoreview andupdatethisdocumentperiodicallyin responsetotheneedsofthecommunity.Pleaseaddressanyproposalsfo rrevisionthroughappropriatechannelsto :

NationalComputerSecurityCenter9800avageRoadFt.Geo r g eG .M e a d e ,M D 20755-6000Attention:Chief ,Standards,Criteria,andGuidelinesDivis ion

PatrickR. tetgher4^ ay1992DirectorNationalComputerSecurityCenter


4/83


5/83

i CKNOWLEDGMENTSACKNOWLEDGMENTS

TheNationalComputerSecurityCenterexpressesappreciationtoD r.Dix ieB.Baker,o fTheAerospaceCorporation,sheprincipaluthorfthisdocument,ndM s.CaralynCrescenziasprojectmanager.W els ohankhevaluators,endors,ndsersnheUnitedStatesomputersecuritycommunityw hoontributedtheirtimeandxpertisetoheeview ofthisdocument.


6/83

A S S E S S I N GC O N T R O L L E D A C C E S SP R O T E C T I O N IV


7/83

v XECUTIVES U M M A R Y ExecutiveSummary

AssessingControlledAccessProtectionprovidesguidancetotheDepartmento fD e-fenseomponentshargedwithnsuringhatheutomatednformationystems(AISs )sedo rprocessingensitiveo rlassifiednformationprovideteaston-trolledaccessprotection.Theobjectivesofthisguidelineanditssupportingdocumentationse tare:

1.oprovideamethodologyorperformingaechnicalanalysisoupporthecertificationofcontrolledaccessprotectionin A ISssubmittedfo raccreditation;

2.oprovideaninterimapproachfo rachievingcontrolledaccessprotectionuntilasuitableNSA-evaluatedproductsavailable;and

3.oclarify theintent,securityfunctionality,andlevelofassuredprotectionthatcontrolledaccessprotectionprovides.

Theguidanceprovidedin thisdocumentistargetedtowardmulti-userA ISsdesignedfo rD oDoperationsnsystem-highsecuritymodeandin dedicatedmode,wheredi- rectedbytheD A A .Thisguidancedoesnotpecif ical lyaddressonnectivitywithalocal-areao rwide-areanetwork.N ordoesitaddressrelatedareassuchasphysicalse -curity,TEMPEST,communicationssecurity,o radministrativesecurity(e.g.,trusteddistribution).Thisguidelineiswrittenoerveasheynergisthatntegratesndonsolidatesinformationontainedinhefo l lowingdocumentsintoaunif iedxplanationoftherequirementsfo randintentofcontrolledaccessprotection.

GuidetoUnderstandingAuditinrustedSystems GuidetoUnderstandingConfigurationManagementnTrustedSystems GuidetoUnderstandingDesignDocumentationinrustedSystems

AuidetoUnderstandingDiscretionaryAccessControlinTrustedSystems GuidetoUnderstandingIdentificationandAuthenticationinTrustedSystems GuideoUnderstandingObjectReuseinTrustedSystems

AGuidetoWritingtheSecurityFeaturesUser'sGuideforTrustedSystemsuidelinesforWritingrustedFacilityManuals


8/83

A S S E S S I N G CONTROLLEDA C C E S SPROTECTION irustedProductEvaluationQuestionnaire

TheNationalComputerSecurityCenter( N C S C )publishesanddistributesthesedoc -umentstosupportthecertificationandaccreditationo fA ISsrequiredtoprovidecon-trolledaccessprotection.orequestcopiesofthesedocuments,contacttheNationalTechnicalInformationServ ice(NTIS).


9/83

Contents1ACKGROUND

1.1A T I O N A LPO L I C Y1.2EC UR I T YA C C R E D I T A T I O N1.3R U S T E D P R O D U C TEVALUATION1.4C O P E AN D P U R P O S E

2ONTROLLEDACCESSPROTECTION3RCHITECTURALFOUNDATION 3

3.1R U S T E D C O M P U T I N G BA SE 33.2N F O R C E M E N T 73.3O M A I N SE P A R A T I O N 83.4E F I N E D SUBSET 03.5E S O U R C EISOLATION 0

4ROTECTIONMECHANISMS 2 4.1D E N T I F I C A T I O N &A U T H E N T I C A T I O N 24.2I S C R ET I O N A R Y ACCESSC O N T R O L 44.3B JEC T R EUS E 84.4UDIT 9

5OCUMENTATIONANDLIFE -CYCLEASSURANCE3 vi i


10/83

ASSESSING C O N T R O L L E D A C C E S SP R O T E C T I O N Vlll5.1ESIGN D O C U M E N T A T I O N 35.2YSTEM I N T E G R I T Y 45.3O N F I G U R A T I O NM A N A G E M E N T 55.4R U S T E D F A C I L I T YM A N U A L 7 5.5E C U R I T YF E A T U R E SUSER'SG U I D E 85.6E S T I N G 9

6ECHNICALANALYSIS 16.1EL EC T I O N O FANALYSTS 16.2E C H N I C A L ANALYSISP R O C E S S 27ISKMANAGEMENT 3 7.1R O T E C T I O N L I M I T A T I O N S 47 .2D E N T I F I E D D E F I C I E N C I E S 5

7.2.1YSTEM A R C H I T E C T U R E 57.2.2D E N T I F I C A T I O N A N DA U T H E N T I C A T I O N67.2.3I S C R E T I O N A R YA C C E S SC O N T R O L67.2.4B JEC T R EUS E 67.2.5UDIT 67.2.6YSTEM I N T E G R I T Y 7

8CRONYMS 39LOSSARY 5


11/83

ListofFigures1.1ationalPolicyonControlledAccessProtection1.2oD D200.28Timetablefo rC 23 .1rustHierarchyin anA IS 33 .2elationshipbetweenSystemEngineeringandAssurance63 .3CSECC 2SystemArchitectureCriterion 74 .1CSECC 2IdentificationandAuthenticationCriterion3 4 .2CSECC 2DiscretionaryAccessControlCriterion 4 4 .3C L fo rFilegeorges-data 6 4 .4utputfromDirectoryStudy 7 4 .5nixCommandSeq uence 7 4 .6CSECC 2ObjectReuseCriterion 8 4 .7CSECC 2AuditCriterion 05.1CSECC 2Des ignDocumentationCriterion 3 5. 2CSECC 2SystemIntegrityCriterion 55.3CSECC 2TrustedFacilityManualCriterion7 5. 4CSECC 2SecurityFeaturesUser'sGuideCriterion8 5. 5CSECC 2SystemTestingCriterion 96 .1 ControlledAccessProtectionTechnica lAnalysisProcess3 IX


12/83

A S S E S S I N GC O N T R O L L E D A C C E S SP R O T E C T I O N


13/83

ListofTables2.1 SecurityPolicyControlObjectivesandImplementationRequirements 114 .1 ObjectReuseMechanisms 29

XI


14/83

A S S E S S I N GC O N T R O L L E D A C C E S SP R O T E C T I O N xn


15/83

ChapterBACKGROUND1.1 NATIONALPOLICYInJulyof1987,theFederalgovernmenti s suedtheNationalPolicyonControlledA c- cessProtection[36],establishingthepolicy fo rautomatedinformationsystems(AISs)thatreaccessedb ymultipleuser swithif ferentuthorizationsotheinformationcontainedinthesystem.hePolicy,shownin Figure.1 ,mandatesthathesesys-temsprovideautomatedcontrolledaccessprotectionandhathisminimallevelofprotectionbeprovidedwithinfiveyearsofthePolicy'si s suance .ThePolicygivestheFederalagenc iesresponsibilityfo rensuringthatitsprovisionsarecarriedout.A llautomatedinformationsystemsthatreaccessedbymorethanoneuser,w h e n thoseusersonothavethesameauthorizationosellofthelassifiedo rens i-tiveunclassif ied informationprocessedormaintainedb ytheautomatedinformationsystem,hallprovideautomatedControlledAccessProtectionorlllassifiedndsensitiveunclassif ied information.Thisminimum levelofprotectionshallbeprovidedwithinfiveyearsofthepromulgationofthispolicy.

Figure1.1:NationalPol icy onControlledAccessProtectionTheDepartmentofDefenseD o D )arriesheol icyforwardnDirective5200.28,SecurityRequirementsforAutomatedInformationSystemsAISs)38],which speci- fiesrequirementsfo rA ISsthathandleclassified,sensitiveunclassified,o runclassif ied information.heDirectiveprovides isk-assessmentprocedure,xtractedromC S C - S T D - 0 0 3 - 8 511],whichissedodeterminetheminimumTrustedComputerSystemEvaluationCriteriaTCSEC)[14]evaluationclassrequiredfo ranA IS ,basedonheensitivityoftheinformationstorednorprocessedbytheA ISndnheclearanceso f itsuser s .o rA ISsthatprocesso rhandleclassifiedand/orsensitiveun -

1


16/83

ASSESSINGCONTROLLEDACCESSPROTECTION

classified information,andthat,baseduponthe prescribedrisk-assessmentprocedure,requireateastontrolledaccessprotection,heDirectivemandatesanmplementa-tiontimetableof1992,shownnFigure.2 .AllAISshatprocessorhandlelassifiednd/orensitiveunclassifiednformationandhatequireateastontrolledccessprotectioni.e.,lassC2ecurity),basedontheriskssessmentproceduredescribednenclosure4 ,hallmplementrequiredsecurityfeaturesby992.

Figure.2 :oDD5200.28TimetableforC2TheNationalSecurityAgency(NSA)evaluatescommercialproductsdesignedtomeettheTCSECequirementsndistshemntsEvaluatedProductsListEPL)34]maintainedbytheNationalComputerSecurityCenter(NCSC).TheDirectivetaskstheNSAoserveas focalpointforechnicalmattersrelatingtoheuseoftrustedcomputerproductsndtoprovidetotheDepartmentofDefense(DoD)omponents,asrequested,technical assistanceinevaluatingandcertifyingcomputer-basedsecurityfeaturesofAISsusedinoperationalenvironments.Thisguidelineis responsivetothistasking;itspurposeis toprovidetheDoDomponentstechnicalguidancetosupportthecertificationandccreditationofoperationalystems.

1.2 SECURITYACCREDITATIONPriortoallowinganAISto handleanyclassifiedor sensitiveinformation,aDesignatedApprovingAuthorityDAA)ustccredittooperatenneofhreeecuritymodes:edicated,ystemhigh,rmultilevel.ndedicatedmode,llsershavetheclearanceoruthorizationnd need-to-knoworlldatahandledbytheAIS.Inystemhighmode,llusershave ecuritylearanceoruthorization,butnotnecessarilyaneed-to-know,orlldatahandledbytheAIS.MultilevelmodeallowstwoormoreclassificationlevelstobeprocessedsimultaneouslywithinthesameAISwhennotllusershaveaclearanceorformalaccessapprovalforalldatahandledbvtheAIS.A programforconductingperiodicreviewoftheadequacyofthesafeguardsforoper-ational,ccreditedAISslsomustbeestablished.38 ]TheDAAhouldbeinvolvedinllphasesofheystemcquisition,eginningwithhedevelopmentofhee -curitypolicyndoperationsoncept,ndncludinghespecificationofthesecurityrequirements,reviewsonductedduringthedesignnddevelopmentphases,ndse-curitytesting,toensurethatheorsheunderstandsthe operationalneeds,how systemcomponentsworkogether,howhesystemnterfaceswithotherystemsndorga-nizations,ndherisksssociatedwithhesystem.


17/83

3 ACKGROUNDThetechnicalevaluationofanAIS'ssecurityfeaturesandothersafeguards,madein supportftheaccreditationprocess ,salledertification.ertificationestablishesthextentowh i ch particularAIS'sesignndmplementationmeet etfspecif iedecurityrequirements.ccreditationisheDAA'sformaldeclarationhatanA ISspprovedtooperaten particularecuritymode,using prescribedsetofsafeguards.ccreditationsheofficialmanagementuthorizationoroperationofnA ISndsasednheertificationrocessswel lsothermanagementconsiderations.heccreditationtatementffixesecurityresponsibilitywithheD A A ands ho w sthatduecarehasbeentakenfo rsecurity.[38]Althoughcertificationinvolvesagreatdealmorethanthetechnicalanalysisdescribedin thisdocument,theguidancecontainedhereincanprovideatechnicalbasisfo rthecertificationportionoftheaccreditationprocess .

1.3 TRUSTEDPRODUCTEVALUATIONTheD oDpolicyspecified in D o D D200.28tatesthat:

ComputersecurityfeaturesofcommerciallyproducedproductsandGovernment-developedorderivedproductsha l lbevaluatedasequested)ores igna-tionsrustedomputerproductsornclusionnheEvaluatedProductsListEPL).Evaluatedproductssha l lbedesignatedasmeetingsecuritycriteriamaintainedbytheNationalComputerSecurityCenter(NCSC)atN S A def ined b y thesecuritydiv is ion ,class,andfeature(e.g.,B ,Bl,accesscontrol)describedin D oD2 0 0 .2 8 -STD.

TheN C S CmaintainsheEPLnd,singechnicalupportromN S A ,valuates,assignsatingso,ndentersontotheEPLproductsdesignedanddevelopedin ac-cordancewiththeTCSEC.N S A maintainsacadreo f trusted-productevaluatorsbothfromwithintheagency andfromFederallyFundedResearchandDevelopmentCor-porationsFFRDCs).herustedproductvaluationprogramTPEP),describedindetailnrustedProductEvaluations: uideforendors41],omprisesthefo l lowing fivephases :

1.roposal eview.hen vendorequestshattsproductbevaluatedorpossiblenclusionnheEPL,N SAprescreensheproposedproductelativetoitsusefu lnesstoD oDomponents,itstechnicalmeritthroughanintensivePreliminaryTechnicalReview),andthevendor'scommitmenttotheproduct.

2.endorAssistance.fN SAec ideshatheproducthaspotentialmerit,ts ignsaMemorandumo fUnderstanding(MOU)withthevendor.ThroughthisMOU,thevendoragreesamongotherthings)togiveN S A evaluatorsaccessto


18/83

ASSESSINGCONTROLLEDA C C E S SPROTECTIONthehighlyproprietaryhardwareandsoftwaredesigndocumentationneededtoperformanevaluation.OncetheM O Uiss igned ,N S A assignsasmallevaluationteamtorackheproducthroughtsdevelopmentndoprovideassistanceinheinterpretationandpplicationofTCSECequirementsfo rhetargetedclass.Thisteamworksclose lywiththevendorthroughouthedevelopmentoftheproducttohelpdetermine thetargeteddivision andclassandtoensurethatthedesignanddevelopmentalapproacharecompliantwiththerequirementsoftheTCSECfo rthatlass.

3 .esignAnalysis.Whendevelopmentisomplete,andlloftherequireddoc- umentationisnearingcompletion,theproductentersDes ig nAnalysis.uringthisphase,nexpandedevaluationteamcompletestrainingtothelevelofanapplicationsprogrammer,orystemsargetedorupolassBl,ndohelevelofasystemprogrammer,fo rsystemstargetedfo rthehigherclasses) .TheteamnalyzesheproductelativetoheTCSECequirementsndwritesdetailednitialProductAssessmentReportIPAR).o rproductsargetedtB 2ndbove, preliminaryrchitecturestudysonducted,ndtAl,heteambeginsxaminingtheformalverificationduringhisphase.nformationnecessaryfo rdes ignanalysisisgainedthroughthoroughreview ofthehardwareandsoftwaredes igndocumentation,examinationofdraftsfTCSEC-requireddocumentatione.g. ,SecurityFeaturesUsers'Guide,TrustedFacilityManual,testplansndprocedures),ndnteractionswithhevendor.ecausebothteammembersandvendorpersonnelarelikelytobewide ly dispersedgeograph-ical ly ,electroniccommunicationsrerelieduponheavilyfo rteamandvendorcommunications.ncetheanalysisiscompleted,theeampresentstheIPARtoNSA'sTechnicalReviewBoardTRB),whichservesasneoftheTPEP'sprimaryquality-controlmechanisms.asedponhePARndheeam'spresentation,theTRBprovidestoN S A management recommendationasowhethertheproductisreadytobegintheEvaluationPhase.

4.valuation.Thisphaseistheactualsecurityevaluationoftheproduct.uringthisphase,hevaluationeamompletesheesignnalysis,buildingupontheinformationontainedinhePAR.Priorobeginningfunctionalesting,theteampresentsitsassessmenttotheTRB,witharequestthattheevaluationbel lowedoproceedoesting.heeamhenonductsunctionalesting(alllasses)ndpenetrationestingclass 2ndbove),xaminesheinalversionsofrequireddocumentation,andcompletestheFinalEvaluationReport.AtclassB 2andabove,asystemarchitecturestudyandcovertchannelanalysisareonducted,ndtAl,heormalverificationsvalidated.theendfthisphase,hevaluationeamgainppearseforeheTRBopresenttsfindingsndorecommendaf inalating.uccessfulompletionofthisphaseresultsin placementofthevendor'sproductontheEPL.


19/83

5 ACKGROUND5.atingMaintenance.SA'sRAtingMaintenancePhaseRAMP)provides

mechanismfor ensuring thecontinuingvalidityof aratingextendedtosuccessiveversionsoftheratedproduct.

TheEPL,publishedsemi-annuallyaspartoftheInformationSystemsSecurityProd-uctsndervicesataloguendpdateduarterly,1rovidesystemcquisitionagents oodelectionf2-ratedroductsromhichoelectlatformsortheirpplications.nddition,heEPLontains numberofproductshathavebeenratedBlndabove;allofthesecontainacceptablecontrolledaccessprotectionmechanismsand,fappropriatelyonfigured,ouldbeusedinasystem-highorded-icatedenvironment.nfact,omesystem-highenvironments,particularlythosewithexternalnterfacesoystemstdifferentevels,mightbenefitromhedditionallabelingcapabilitythatDivisionsBndA systemsprovide.Further,moreandmorecomputervendorsarebringingtheirproductsotheNSAwiththerequestthatheybeonsideredforvaluation.2hisbeinghease, reasonablexpectationshattheEPLwillontinuetoexpandsmorevendorsrecognizetheommercialvalueofNSA-ratedproducts.However,anssessmentmethodologyandtrainedanalystsreneededforthoseDoDprogramsorwhich uitableNSA-rated 2orbove)productoesnotxistorthatdonoturrentlyhavetheresourcesnecessarytorehosttheirsoftwareonaratedproduct.hisguidelineaddressesheseneeds.

1.4 SCOPEANDPURPOSEThisdocumentsntendedobeusedbyndividualsaskedoperform echnicalanalysisofanAISnupportofitsertificationndccreditation.hedistinctionbetweenthetermsautomatedinformationsystem"ndtrustedproduct"simpor-tantinthiscontext.AsdefinedintheDirective,anautomatedinformationsystemis anyssemblyofcomputerhardware,oftware,nd/or firmwareonfiguredtoollect,create,ommunicate,ompute,isseminate,rocess,tore,nd/orontrolatarinformation.38]nhisguideline,heermAIS"orsystem")efersonAISthatsonfiguredfor specificpurposeelevanttoheDoDomponentforwhichitis beingaccredited.TheDirectivedefinesarustedproductas productthathasbeenevaluatedndpprovedfornclusionnheEvaluatedProductsListEPL).[38]AnAISmaybebuilton trustedproductorEPLproduct").

xTo obtainacopy ofthecurrentEPL,writetotheNationalTechnicalInformationService(NTIS),5285PortRoyalRoad,Springfield,VA 22161.2SeeotentialroductsistnhenformationystemsecurityroductsndervicesCatalogue.


20/83

ASSESSINGCONTROLLEDACCESSPROTECTION

Thisguidelineervesounify,nterpret,ndpplynformationontainednotherdocumentspublishedbyheNCSC.heollowingdocumentsrencorporatedbyreferencetosupporthetechnicalanalysisofcontrolledaccessprotection.

uideoUnderstandingAuditnrustedSystemsiscussesssuesnvolvedinmplementingndvaluatingnuditmechanism.tprovidesguidanceovendorsonhowtodesignandncorporateeffectiveauditmechanismsintotheirsystems,anditcontainsguidancetoimplementorsonhowtomake effectiveuseoftheauditapabilitieshatrustedystemsprovide.1]

GuideoUnderstandingConfigurationManagementnTrustedSystemspro-videsguidancetodevelopersoftrustedystemsonwhatonfigurationmanage-mentsndhowtmaybemplementednhesystem'sdevelopmentndifecycle.ttresseshemportanceofconfigurationmanagementforllystemsanduggestshowtanbeimplemented.2]

GuideoUnderstandingDesignDocumentationnrustedSystemsprovidesguidanceinunderstandingandmeetingtheTCSEC'sdesigndocumentationre-quirements.ttresseshemportanceofgooddesigndocumentationnmain-tainingecuritythroughout system'sifeyclenddescribeshedesigndoc-umentationnecessaryosupportproducteviewndvaluation.4]

AGuidetoUnderstandingDiscretionary AccessControlinTrustedSystemsdis-cussesissuesinvolvedindesigning,mplementing,andevaluatingdiscretionaryaccessontrolDAC)mechanisms.5]AGuidetoUnderstandingIdentificationandAuthenticationnTrustedSystemsdescribestheidentificationandauthentication(I&A)requirementsandprovidesguidancetovendorsonhowtodesignandincorporateeffectiveI&Amechanismsintotheirsystems.6] AuideoUnderstandingObjectReusenrustedSystemsdescribesheob-jecteuserequirementndprovidesguidancetovendorsonhowodesignndincorporateeffectiveobjecteusemechanismsintotheirsystems.7] AuideoWritingheecurityFeaturesUser'sGuideorrustedSystemsexplainsthemotivationandmeaningoftheTCSECequirementfor SecurityFeaturesUsers'Guide(SFUG)ntermsofaudience,content,andorganization.ItsddressedopotentialSFUGuthors.8] GuidelinesforWritingTrustedFacilityManualspresentsissuesinvolvedinwrit-ingaTrustedFacilityManual(TFM).Itprovidesguidancetovendorsonhowtodocumentfunctionsoftrustedfacilitymanagementandrecommendsstructure,format,ndontenttosatisfyheTCSECequirements.32]


21/83

BACKGROUNDTrustedProductEvaluationQuestionnairecontainsalisto fquestionsthatad -dressthe TCSECcriteriaf rom classClthroughAl.tw asdevelopedtose rve asatoolfo rformalizingthedata-gatheringprocessrequiredduringvariousphases o ftheTPEP.40 ]

Theobjectiveso fthisguidelineanditssupportingdocumentationse tare :oprovideamethodologyfo rperformingaechnicalnalysisoupporthe

certificationofcontrolledaccessprotectionin A ISssubmittedfo raccreditation.oprovideaninterimapproachfo rachiev ingcontrolledaccessprotectionuntil

asuitableNSA-evaluatedproductisava i lab le .T oclarifytheintent,securityfunctionality,andlevelofassuredprotectionthatcontrolledaccessprotectionprovides.

Theesultsfthisnalysisls oanprovidevaluablenformationoystemevel-opersndintegratorsattemptingtoc o m p o s ecomponentsintocomplexsystems.n composedsystems(e.g.,networks),thisassessmentwil lprovideassurancethateach individualA ISprovidestherequiredlevelo fcontrolledaccessprotection.husthisanalysiswil lbeusefulin conductinganevaluationb yparts39]ofthetotalsystem.Theguidanceprovidedin thisdocumentistargetedtowardmulti-userA ISsdes igned fo rD oDoperationsnsystem-highsecuritymodeandndedicatedmode,w h e r edi- rectedbytheD A A .Thisguidancedoesnotpecifically addressonnectivitywithalocal-areaorwide-areanetwork.N ordoesitaddressrelatedareassuchasphysicalse -curity,TEMPEST,communicationssecurity,o radministrativesecurity(e.g.,trusteddistribution).Thisguide'sprimaryaudienceistheanalyststaskedtoperforma technical assessmentofanAIS'scontrolledaccessprotectionfeaturesandssurances.Theanalystshouldbeginb yreadingChapter2,whichdefinesthesecuritypolic iesenforcedb ycontrolledaccessprotectionandexplainshow therequirementsarederivedfrom thesepolic ies .Theanalystthenshouldreview Chapter3 ,whichdiscussesthearchitecturalfounda- tionnecessaryorontrolledaccessprotection,ndChapter,whichdescribeshesecuritymechanismsthatarebuiltuponit.Agoodunderstandingoftheinformationcontainedin Chapters3and 4iscriticaltothetechnicalanalysisprocess .T ogainanunderstandingofthedocumentationrequiredasevidencethatthesystemw asbuiltsecurely andthatitcan beoperatedandmaintained withoutjeopardizingitsinherentsecurity,theanalystshouldnextreview Chapter5,whichaddressesl ife-cycleassurances.uildinguponhenformationontainednhesehapters,Chapterdescribesaprocessfo rperformingatechnicalanalysistodeterminewhetheranA IS providesadequatecontrolledaccessprotection.hisanalysisisintendedtose rveas


22/83

A S S E S S I N G CONTROLLEDACCESSPROTECTIONthetechnicalbasisorertificationoupportystemccreditation.nysecurityanalysisinvolvesatrade-offbetweenprovidedprotectionandassumedrisk.inally,Chapter7discussesriskmanagementandidentif iesrisksthatcontrolledaccesspro- tectionisincapableo fcounteringandrisksresultingf rom def iciencieswhichmaybeidentifiedduringthetechnicalanalysis.mportanttermsareitalicizedin thetextanddef inedin theGlossaryAppendix9) .


23/83

ChapterCONTROLLEDACCESSPROTECTIONA ISecuritysoncernedwithontrollinghew aynwhichnA ISanbesed ;thatis ,controllinghow user scanaccessandmanipulatetheinformationitprocesses . Derivingthesecurityrequirementsfo rag ivenA IS requiresprecisedefinitiono ftheobjectivesfheesiredontrol;.e.,heystem'securityolicy.heseontrolobjectiveswil lvarydependinguponheperceivedhreats,isks,ndoalsftheorganizationfo rwhichtheA ISisbeingaccredited.ontrolledaccessprotection(a sdef ined inthe TCSEC)is foundedon objectives relatingtothreebasictypeso fcontrol:securitypolicyenforcement,ccountability,andssurance.lloftherequirementsfo rA I S sprovidingcontrolledaccessprotectionarederivedfromtheseobjectives[14],ass h o w ninTable2.1onpage11.Controlledaccessprotectionpolic iesarebaseduponafundamentalassumptionthattheA ISprocessingnvironmentsoneofmutuallytrustingndooperatingsers .Recognitiono f thisfactiscriticaltounderstandingtheobjectivesofcontrolledaccessprotection.hefeatures,ssurances,ndmostmportantlytheunderlyingsystemarchitectureo fanA IS thatprovidescontrolledaccessprotectionarenotintendedanddonotpurporttopreventmaliciouso rconcertedactionsaimedatcircumventingtheprotectionprovided.ControlledaccessprotectionassertsthattheA ISprov ides :

rotectionandcontrolove rw hocanlogontothesystem.echanismshatil lnableheA ISomakeecis ionsegardingccessor esourcesbasedupontheexpressedwishesofitsuser s(withnoassurancethat

concerted,mal ic iousactionscannotcircumventthismechanism).Theapabilitytogenerate eliablelo gofuserctionsndoguaranteeits

9


24/83

A S S E S S I N G CONTROLLEDA C C E S S PROTECTION 0correctness.

Controlledaccessprotectionsuff ic ientfo rA ISsoperatingin system-higho redi-catedsecuritymodes.Ho w e v e r ,if theA ISexportsclassifiedinformationthatrequiresassuredclassificationabelingornformationhatsentoadedicatedrsystem-highA ISatalowerclassif icat ionlevel,controlledaccessprotectionisnotsufficient.1Adequatetreatmentofthesecasesisbeyondthescopeofthisguidance.

'SomeA IS environmentswithintegrityconcernsmayenforceapolicythatprohibitsexportationtohigherleve lsaswell .


25/83

11 CONTROLLED ACCESS PROTECTIONControlObjectives

SecurityPolicy:A statementofintentwithregardtocontroloveraccesstoanddisseminationof information,tobeknownasthesecuritypolicy,mustbeprecisely definedandimplementedforeachsystemthatisusedtoprocesssensitiveinformation.Thesecuritypolicymustaccuratelyreflecthelaws,regulations,andgeneralpoliciesfromwhichitisderived.DiscretionarySecurity:Securitypoliciesefinedforsystemsthatareusedtoprocessclassifiedorothersensitiveinformationmustincludeprovisionsfortheenforcementofdiscretionaryaccesscontrolrules.Thatis ,theymustinclude consistentsetofrulesforcontrollingandlimitingaccessbasedonidentifiedindividualswhohavebeendeterminedohaveaneed-to-knowfortheinformation.

DerivedRequirementsSystemSecurityPolicy

Accountability:Systemsthatareusedtoprocessorhandleclassif iedorothersensitiveinformationmustassureindividualaccountabilitywheneveradiscretionarysecuritypolicyisinvoked.Furthermore,toassureaccountabilitythecapabilitymustexistforanauthorizedandcompetentagenttoaccessandevaluateaccountabilityinformationb yasecuremeans,withinareasonableamountoftime,andwithoutunduedifficulty.

DiscretionaryAcces sControlObjectReuse

Assurance:Systemsthatareusedtoprocessorhandleclassif iedorothersensitiveinformationmustbedesignedtoguaranteecorrectandaccurateinterpretationofthesecuritypolicyndmustnotdistorttheintentofthatpol icy.Assurancemustbeprovidedthatcorrectimplementationandoperationofthepolicyexiststhroughoutthesystem'sl ife-cycle.

IdentificationandAuthenticationAudit

SystemArchitectureSystemIntegritySecurityTestingConfigurationManagementDes ignDocumentationTrustedFacilityManualSecurityFeaturesUser'sGuide

Table2.1:ecurityPolicyControlObjectivesandmplementationRequirements


26/83

A S S E S S I N GC O N T R O L L E D A C C E S SP R O T E C T I O N 2


27/83

Chapter3ARCHITECTURALFOUNDATIONComputersystemarchitectureisthefoundationuponw h i c ha llA IStrustworthinessisbuilt.hishapteriscussesystemrchitectureastelatesorustndheconcepto faTrustedComputingBase .

3.1 TRUSTEDCOMPUTINGBASEInherentin theconceptoftrustss o m eassurancethathetrustedpersonorentitypossessesherequiredstrength,apability,andintegritytomeritthatrust.nthecasefA I S s ,rustsbuiltromhebottomi.e.,hardware)p,ithachayer"trusting"tsunderlyingayeroperformhexpectedervicesn eliablendtrustworthymanner,asshownin Figure3.1.

User I trust

ApplicationI trust

OperatingSystemI trustHardware

Figure3.1:TrustHierarchyinanA IS Eachlayertrustsallofitsunderlyinglayerstoreliablyprovidetheexpectedservices

13


28/83

A S S E S S I N G CONTROLLEDA C C E S SPROTECTION 4andbehavior.hesersrusthepplicationsheyunobehaveinhemannertheyexpect;theapplicationtruststhesystemcallsitm a k e stotheoperatingsystemtoproducethedocumentedresults;andtheoperatingsystemtruststhehardwaretobehavein aconsistentandsafemanner.otethatrustsmeaningfulonlyrelativetohebehaviorsndtrengthsxpected;orexample,heapplicationlayercannotexpecttheoperatingsystemtodetectallbug sin userprograms.Thisisparticularlyimportantrelativetothetrustimpliedfo rcontrolledaccessprotection.Thistrusthierarchyisthebas isfo rtheconceptofaTrustedComputingBase(TCB)thatcannotbecompromisedf rom aboveandthatisa lway sinvokedtoenforceasecu- ritypolicywiths o m edegreeofassurance.oranyA IS ,theTCBincludesallo fthesof tware ,firmware,andhardwarecomponentsresponsiblefo renforcingthesecuritypol icyandllcomponentscapableofaffectingthecorrectoperationofthesecuritymechanismsseeChapter).husheTCBncludesomponentsw ho s ejobsoperformom efunctionequiredonforceheecuritypolicye.g . ,programshatcheckaccess-controlsettingsonfiles)ndomponentsthathavenodirectfunction-alityrelativetoheecuritypolicy,butequiretheapabilitytoviolates o m epartofthesecuritypolicyofthesystem(i.e.,privilege)in ordertooperateandthereforemustbetrustede.g . ,anI/Odriver).TheTCSECassertsthatatrustedsystemarchitecturemustexhibitprotectionprop-ertiesthatwil lenforcethistrusti e ra rchy .Thustheconcepto fareferencemonitor(o rreferencevalidationmechanism)isintroduced.hetermeferencemonitorr ep-resentsanbstractionftheportionftheTCBhatctuallyvalidatesreferencestoobjectsndgrantso ren ies)ccessohem. Amonghepropertieshathereferencemonitorhouldxhibitrehattbenoncircumventablei.e.,l w a y sn-voked) ,amperproof,ndmallnoughoenalyzedndested. TheTCSECimpose sincreasinglystrictarchitecturalandsystemengineeringrequirementsontheTCBthigherndhigherlassesftrustworthiness. A sh o w nnFigure.2 ,hemoresystemengineeringgoesintodes ign ingtheTCB,hemoreassuredisthetrustthattprovides. Inhisigure ,hencreasingsystemengineeringrequirementsareshownntalicsbesideachonceptualmachineclass. F o rclasses 2ndBl,hereferencemonitorneednotbedifferentiatedfromtherestftheTCBw h i c hc o m -priseshentireoperatingystem),ohatpplicationsmustrustssentiallyll oftheoperatingystemandhardware. ClassB2equiresmoresystemengineeringtoensurethatheTCBompriseslargelyindependentmodules,thusproducinganadditionallayeroftrust,astheTCBisisolatedf rom non-security-relevantoperating-systemservices .lassesB3andAlystemarchitecturesprovidelayeredprotection,withllayersultimatelyeliantupon mall,onceptuallyimple,amperproof,andnoncompromisablereferencemonitorhatlaysaentralolennforcingheinternalstructuringoftheTCBndhesystem.stheillustrationshows ,applica-tionsrunningonaclass-C2A ISi .e.,onedes ignedtoprovideonlycontrolledaccessprotection)musttrustheentireoperatingystemandllo fthehardware(i.e.,all


29/83

15 R C H I T E C T U R A L F O U N D A T I O N physicalresources)andfirmwareuponwhichitdepends .


30/83

A S S E S S I N G CONTROLLEDA C C E S SPROTECTION 16

L J J o z w ;::;;

ttx" osjSVQS J L

B3-A1HBVMRBx:sssMi3ia

,,",,

Layering AbstractionDataHiding TC B Minimization ReferenceMonitorm OS svfcsAPPUCATION

APPUCATION ModularityReferenceValidation Mechanism

TC B DomainIsolationLOW MEDIUM

SYSTEM ENGINEER ING HIGH

Key:3TCB

Figure3.2:RelationshipbetweenSystemEngineeringandAssurance


31/83

17 RCHITECTURALFOUNDATIONTheobjectiveandresultoftheTCSEC'sconceptual hierarchyoftrustarethatd e m o n -stratingassurancein thetrustworthinesso ftheTCBbecomesincreasinglytractableandassuredasoneprogressesuptheTCSEChierarchyoftrust.AtclassC 2,theTCBmaybelarge,dispersed,ndgenerallyunstructured;s result,itpresentsagreatchallengetobothevaluatorsandpersonsresponsiblefo rmaintainingthesystem'sse -curity.AtclassB 2,theTCBstill maybelarge,butthe factthatitismodularandtheresultofsoundsoftwareengineering practicesm a k e siteasiertounderstand,evaluate,andmaintainthanlower-ratedproducts;thus,addedassurancein itstrustworthinessresults.AtclassesB3andAl,theTCBissmall,layered,andhighlystructured,thuslendingitselftor igo rousnalysisandtesting,andtoformalverification(Al).

3.2 ENFORCEMENTAssuranceo ftrustrequiresenforcementoftheAIS'ssecuritypolicy.Enforcement"impliesconsistency,reliability,andeffec t iveness .norderfo raTCBoenforcethesecurityolicy,tmustbebothamperproofndnoncompromisible.heSystemArchitecturecriterionshownin Figure3 .3addressestheseattributes.TCBha l laintain omainortsw nxecutionhatrotectstromexternalnterferenceoramperinge.g . ,bymodificationofitsoderdatastructures).esourcesontrolledyheTCBmaybe ef inedubsetfthesubjectsndobjectsinheADPystem.heTCBha l lsolatethere -sourcestobeprotectedsotheyaresubjecttotheaccesscontrolandauditingrequirements.

Figure3.3:CSECC 2SystemArchitectureCriterionThetermobjectreferstoanypassiveentitythatcontains o rreceivesinformation(e.g.,files,directories,records,blocks,pages ,segments,programs,video displays,printers),andaccesstoanobjectimpl iesaccesstotheinformationitcontains.Asubjectisanyactiveentityin thesystem(e.g.,person,rocess ,evice)thatausesinformationtoflow amongobjectso rchang e sthesystemstate(e.g.,fromoperatingonbehalfofthesystemtooperatingonbehalfoftheuser).TheSystemArchitecturecriterionaddressesthemostcriticalaspectoftrustedc o m -puting:hebilityoftheTCBoprotecttselff romuntrustedrocesses .heC 2SystemArchitecturecriterionembodiesthreerequirements:

1.heTCBmustmaintainfo ritsow nexecutionadomain(seesection3 .3 b e lo w )thatprotectsitf rom externalinterferenceandtampering.

2.esourcescontrolledbytheTCBmaybeadef inedsubsetofsubjectsandob -jects.


32/83

A S S E S S I N G CONTROLLEDA C C E S SPROTECTION 83.heTCBmustisolatether esourcestobeprotectedsothattheyaresubjecttoaccesscontrolandauditing.

3.3 DOMAINSEPARATIONA susedin theTCSEC,thetermdomainreferstothese tofobjectsthatasubjectis abletoaccess .14]Domainseparationrelatestothemechanismsthatprotectobjectsinthesystem.o raddressranslationpurposes,hedomainseparationmechanismmightbeexecutionrings,baseaddressregisters,o rsegmentationdescriptors.nanA IShatopiesilesntomemory,evera ldomain-separationc h e m e sanpreventdatatransfersfrombeyondtheendfthefileorccessesorbitraryocationson thedisk.Therequirementfo rTCBdomaineparationsbasednhefacthatfuntrustedsubjectsareabletochangetheTCB,henanysecuritymechanismsthatTCBpro-videsareuseless!Therefore,thisrequirementaddressestwoessentialattributes:on-tamperabilityandnoncompromisibility.37 ]Tamperinggenerallyreferstoimproperalterations;nhisontext,tnvolveshanginghesysteminu ch w aythatheintendedbehavioroftheTCBtselfismodif iedwithespectoheenforcementofitsecurityproperties.hisouldhappen,orxample,fTCBode ,datatruc-tures,rontrolparameterswer emodif ied .hedomainoftheTCBls omustbeself-protectingso thatrocessesin theuserdomaincannotamperwithTCBcode ,datastructures,controlparameters,hardware,orf i r mwar e .Compromisecanbeexamined f rom threeperspectives:ompromisefromabove,c o m -promisefromwithin,ndompromisef rom be low.ompromisefromaboveoccursw h e nanunprivilegeduserisabletowriteuntrustedcodethatexploitsavulnerability;e.g.,findinganescapefromahighly-restrictedmenuinterface,installingormodifyingaruleinanuntrustedrulebasethatsubvertsatrustedrulebase,o rcausingadenialofserv ice .hecompromiseresultingfromtheexecutionofaTrojanhorseseesec-tion4.2)thatmisusesthediscretionaryaccesscontrolmechanismisanotherexampleofcompromisefromabove .ompromisef rom withinoccursw h e n privilegedusero rprocessmisuseshellocatedprivileges,rw h e n programmingerrorsmadeintheimplementationofatrustedprogram.orexample,compromisef rom withincouldesultrom systemdministrator'sccidentallyorntentionallyconf igur ingtheaccesstablesincorrectly.Compromisefrom below occursasaresulto fmaliciousoraccidentalfailureo fanunderlyingcomponentthatistrustedandcanresultfromfaultsin thecompilerormodificationstothehardware.37 ]AlthoughtheTCSECriterionrequiresonlythatheTCBmaintainadomainfo ritsow nexecution,"ompromisefromwithinmustbeconsideredeven fo rthes ingle-layeredTCB.T oenableaTCBtoenforcethesecuritypolicy,s o m esubjectsinternal


33/83

19 RCHITECTURALFOUNDATIONtotheTCBmustbe"trusted;".e.,theymustrunwithprivileges thatallow themtobypassoneo rmoreofthesecuritymechanisms.orexample,theloginprogrammustrunwithprivilege,sinceuntilitcompletesitsfunction,theuseronw ho s ebehalfitis runningisnotyetk n o w n(o ratleasthasnotbeenauthenticated).Trustedprogramsmustbeanalyzedandtestedjuststhoroughlysthemechanismsthatenforcethesecuritypolicy,toensurethatheybehaveaspecified andonotompromisetheintegrityo ftheTCBf rom within.1A nimportantspectfdomaineparationwithinheCPUsexecutionstate"r"modeo foperations."ostmulti-usercomputersystemshaveatleasttwo executionstateso rmodeso foperation:privilegedandunprivileged.TheTCSECrequiresthattheTCBmaintainfo ritselfadistinctexecutionstatethatprotectsitf rom theactionsofuntrustedusers .om ecommonprivilegeddomainsarethosereferredtoas"execu-tive,"master,"system,"kernel ,"or"supervisor"modes ;unprivilegeddomainsaresometimescalled"user,"application,"rproblem"states.natwo-statemachine,processesunningin aprivilegeddomainmayexecuteanymachineinstructionandaccessnyocationnm e m o r y .rocessesunningnheunprivilegeddomainrepreventedfromexecutingcertainmachineinstructionsandaccess ingcertainareasofm e m o r y .Probablythemoststraightforwardapproachfo rimplementingdomainseparationis todes ignaTCBthattakesadvantageofmulti-statehardware;i.e.,aCPUthatpro- videstwoo rmorehardwarestatesr ings,modes,domains).BM'sMultipleVirtualStorage/SystemProductMVS/SP),DigitalEquipmentCorporation'sVAX/VMS,andDataGeneralCorporation'sAOS/VSillustratethediversityinhardware-baseddomainseparation.VS/SPprovidestw oexecutionstates:roblemstatefo ruse rprogramsndupervisortateorystemprograms.21]VAX/VMSprovidesou rprocessorccessmodes,hichresedoprovideead/writeprotectionbetweenusersoftwareandsystemsof tware .18]TheMV/ECLIPSEarchitectureofAOS/VSprovides eightexecution"rings,"rangingf rom ring0(mostprivileged)toring7(leastprivileged),withtheAOS/VSkernelrunningin ring0nduserprogramsin ring7,andwithfirmware-implementedgatesprotectingringboundaries.17] F o rmosthardwareplatforms,thedomainseparationrequirementwil lmeanthattleastwohardwarestatesareprovided,w h e r eonestatepermitsaccesso fprivilegedinstructionsnecessaryomanipulatememory-mappingregisters.emorymappingaloneisnotsuff ic ienttomeetthisrequirement,butmaybeusedtoenhancehardwareisolation.o rexample,Unisys'O S1100SecurityReleaseIprovidesdomainisolationthroughtheuseofhardwareandsoftwaremechanismsthatincludeper-processvirtualaddressspaces ,per-processstacks,andhardware-basedstatechanges .27]Ho w e v e r ,themulti-statemechanismneednotbetotallymplementedinhardware.

xNotethata"trustedproces s"strustedtobehavecorrectlyonlywithrespecttotheprivilege(s)itrequires,ndnotinthegeneralsense .


34/83

A S S E S S I N G CONTROLLEDA C C E S SPROTECTION 0 TheUnisysASer iesMCP/ASwithInfoGuarduccessfullyachievedaC 2ratingbyimplementingthetwo-stateconceptwithacombinationof"capability-like"hardwaremechanismsandTCBsoftware,includingthecompi le r s .26]Incapability-basedsys-tems,heTCBanbeprotectedyhavingTCBnduserdomainsreatedw h e n thesystemisinitialized.incepartfthedomaindefinitionistheabilitytoaccessandmodifythedatastructuresneededfo rdomaintransition,multiplestatescanbecreatedonsingle-statehardware.Anotherapproachfo rmeetingthisrequirementistohavealluseractionsinterpretedby theTCBbeforeitactsuponthem.Obvious ly ,thisentailsassuringthatnomeansexistfo ranuntrustedusertomodifytheTCB.T oprotectagainstompromisefromb e lo w ,therequirementfo rdomainseparationimpl iesphysicalprotectionofthehard-w a r eevenhoughhexampleitednheTCSECequirementsoftwareri -ented).9 ]

3.4 DEFINEDSUBSETThewritersoftheTCSECintendedthesecondsentenceoftheSystemArchitecturerequirementtobeagrandfatherc lause"oenablesystemsdesignedbeforetheTC-SE C existedandadd-onpackagessuchasRACF[23]ndACF2[15]omeettheC 2criterioneventhoughtheywer enotcapableofcontrollingallsubjectsandobjectsin thesystem.Theevaluationcommunityhasinterpretedthisrequirementtomeanthat:

1.nlyTCB-controlledsubjectscanaccessallobjects.2.ubjectsnotnderTCBontrolanccessn lyobjectshatrenotunder

TCBcontrol.Theseonstraintspreventuncontrolledubjectsromperformingrawnput-output(I/O)ocontrollednduncontrolled)evicesndromccessingcontrollednduncontrolled)m e m o r y .funcontrolledsubjectswer ea l lowedtoperformsuchopera-tions,theTCBw o u l dbeunabletoenforce thesystemsecuritypol icywithrespecttocontrolledr esources .9 ]

3.5 RESOURCEISOLATIONThehirdentenceo ftheSystemArchitecturerequirementelatesoubjectndobjectsubsettingdiscussedin section3 .4 andimplyassureshatheTCBm p o s e s


35/83

21 R C H I T E C T U R A LF O U N D A T I O N its discret ionaryaccesscontrolsandaudit ingonallofthesubjectsandobjectsunde r it scontrol.


36/83

Chapter4PROTECTIONMECHANISMSTheequirementsorontrolledccessrotectionomprisebothechanismsndassurances.hemechanismsarefunctionalfeaturesdesignedoenforcethesecuritypolicy andaccountabilityobjectivesdiscussedinChapter2andinclude:dentificationanduthentication,discretionaryccessontrol,objecteuse,nduditseeTable2. 1onpage11).

4.1 IDENTIFICATION&AUTHENTICATIONControlledaccessprotectionmechanismsultimatelyaretiedtothetrustworthinessoftheAIS'sdentificationnduthenticationmechanisms.nemustbebleorustthesystem'sabilitytoaccurately,consistently,andpositivelyidentifyeachuser,ndtomaintainhatpositivedentificationhroughoutheuser'soginession.ther-wise,controlledaccessprotectioncannotbeassured,andanyauditdatacollectedarerendereduseless.orhiseason,ftheystemackscceptabledentificationndauthenticationmechanisms,itcannotberecommendedforaccreditation.1ThedentificationndAuthenticationriterionshownnFigure4.1.GuideoUnderstandingIdentificationndAuthenticationnrustedSystems[6 ]discussestheidentificationandauthentication(I&A)requirementatlengthandprovidesguidanceonhowtodesignndmplementeffectiveI&Amechanisms.Controlledaccessprotectionseekstoontrolusers'ccessoinformationintheAIS;specifically,nformationontainednobjectsowhichusersaneferbyname.llformsofccessontroldiscretionaryndandatory)elyonheystem'sbilitytodentifyusersndoprove"heirdentitywhenheyogontoheystem,ndtomaintain positivessociationbetweenachndividualuserndhectionsor

1SeeReference38],D .7 ,fo rexceptiononditions.22


37/83

23 ROTECTIONMECHANISMSTheTCBshallrequireuser stoidentifythemselvestoitbeforebeginningtoperformanyotherctionshatheTCBsxpectedomediate.urthermore,heTCBshallu seaprotectedmechanisms(e.g.,pas swo r d s )toauthenticatetheuser'sidentity.TheTCBhallprotectuthenticationdataohattannoteccessedbynyunauthorizedser .heTCBha l lbebleonforceindividualccountabilityb y providingthecapabilitytouniquelyidentifyeachindividualADPsystemuser.TheTCBhallls oprovidethecapabilityofassociatinghisidentitywitha llauditableactionstakenbythatindividual.

Figure4.1:TCSEC 2IdentificationandAuthenticationCriterion

w h i c hheo rsheisresponsible.Identificationsgenerallymplementedyimplyskingor oginname,usuallyassociatednom ew aywithheperson'sdentity.heystemheckshisnameagainsttslistofauthorizeduser s .hen,toprotectgainstnunauthorizeduser'smasqueradingastheauthorizeduser,thesystemasksfo rs o m e"proof"authentica-tion)thattheuserisw h o m heo rsheclaimstob e .Authenticationgenerallyinvolvesoneo rmoreofthreetypesofproof:"1)omethingheuserknowse.g . , pass-word),2)omethingtheuse rhase .g. ,anauthenticationdevice),o r(3 )omethingtheuseris(e.g.,aretinalscan).M o s tEPLproductsimplementI& Aus ingthesimpleloginnameandpassword,andthispproachscceptable.om eproductstrengthenheirpasswordmechanismsb ynforcingulesu chsgingndengthequirementse.g . ,HewlettPackard'sMPEV/E19])raseestrictionsndequirementsorpecialharacterse.g . ,IBM'sMVS/XAwithRACF[22]),orb y providingrandom-passwordgenerators(e.g.,AT&T'sSystemV/MLSandWang'sSVS/OS[16]28]).Ho w e v e r ,aswithanym e c h -anism,theintegrityofpas swo r dprotectionisonlyastrongastheintegrityandre-sponsibilityofitssers .egard lessofwhetheranA ISsbuiltonnEPLproduct,theTrustedFacilitiesManualse eect ion.4),heSecurityFeaturesUsersGuide(seesection5.5),thesystemadministrator,anduse rtrainingshoulda llstressusers'responsibilitiesin ensuringthattheirpas swo r d saredifficulttoguess ,protected,andchangedregularly.TheDepartmentofDefensePasswordManagementGuideline[13]discussesissuesrelatingtotheu seofpas swo r d sfo ruserauthentication,andtheIn-formationSystemSecurityOfficerGuideline[33]discusses usertrainingandpasswordmanagement.N S Aasxamined numberfubsystemses ignedorovide& A ,ncludingpasswordevices,hallenge-responsepersonaluthenticationev ices ,ndbiomet-ricdevices.henformationSystemsSecurityProductsndServicesCatalogue[34]containsnformationegardingheseevices .heseproductsmayoffernnterimsolutionfo rasystemthatisnotbuiltonanEPLproductandthatlacksI& A m e c h -


38/83

A S S E S S I N G CONTROLLEDA C C E S SPROTECTION 4 anisms.oweve r ,theu seofoneo rmoreseparately-ratedsubsystemssuchasthesedoesnotmplyanoverallproductatingsef inednheTCSEC.2Mechanisms,interfaces,andtheextentofrequiredsupportingfunctionsoreachsubsystemmaydiffersubstantiallyandmayintroducesignificantvulnerabilitiesthatarenotpresentin productsw h o s esecurityfeaturesaredes ignedwithfullknowledg eo f interfaces,andhardwareandoftwaresupport.herefore,ncorporationfonermoreevaluatedsubsystemsintoanA ISisnotequivalenttobuildinganA ISonanEPLproduct.

4.2 DISCRETIONARYACCESSCONTROLControlledaccessprotectionenforcesasecuritypolicy k n o w nasdiscretionaryaccesscontrol(DAC),whichisameanso frestrictingaccesstonamedobjectsbasedupontheidentityofsubjectsnd/orgroupsow h i c htheye long .ystemsthatprovideD A C assurethataccesstoobjectsthatareavailabletouser si.e.,named"objects)areontrolledthediscretion"fhese rorgroup)ithw h o mheobjectsassociated(sometimescalledthe"owner"o ftheobject).TheD A C criterioniss h o w ninFigure4.2.TheTCBhallefinendontrolccessbetweennamedsersndnamedobjects(e.g.,filesndprograms)nheADPystem.henforcementmechanismse.g . ,self/group/publiccontrols,ccessontrollists)ha l lllow user sospecifyandon-trolsharingo f thoseobjectsbynamedindividualso rdef inedgroupsof individuals,o rbyboth,andshallprovidecontrolstolimitpropagationofaccessrights.Thediscre-tionaryaccesscontrolmechanismshal l ,itherb yexplicituseractiono rydefault,providethatobjectsreprotectedrom unauthorizedccess .heseccesscontrolsshallbeapableo fincludingo rexcludingaccessothegranularityofasingleuser .Accesspermissiontoanobjectb y user snotalreadypossessing accesspermissionsha l lonlybeassignedbyauthorizeduser s .

Figure4.2:TCSECC 2DiscretionaryAccessControlCriterionFivebasicmechanismshavebeenusedtoimplementD A C .3

1.ccessControlListsACLs)implementanccesscontrolmatrix(whereinthecolumnsrepresentusers,therowsprotectedobjects,andeachcellindicatesthetypeo faccessobegrantedorheubject/objectpair)yepresentingthecolumnsaslistsofuser sattachedtotheprotectedobject.

2Further,ugment ing oreplacingnvaluatedroduct 's& Amechanismwith subsystem invalidates therat ing. 3S o m eAISsm ayusem orethanoneD A Cmechanism;however,m oreisno tnecessarily better.


39/83

25 ROTECTIONMECHANISMS2.rotectionBitsse bitvector,withachbitepresenting ypeofccess.

ThemostommonexampleisheUnixmplementationofanine-bitvectorrepresentingead,rite,ndxecuteccessesoegrantedoheobject'sowner,itsgroup,ndeveryoneelse.

3 .apabilitiesllowccesso protectedobjectfheequesterpossessesheappropriateprotected"capability,"whichbothidentifiestheobjectandspecifiestheaccessrightstobeallowedtotheuserwhopossesseshatapability.

4 .rofilesassociatewithachuser istofprotectedobjectshatheusermayaccess.

5.asswordsassociateonealltypesofaccess)ormoredifferenttypesofaccess)passwordswitheachobject.4

AGuideoUnderstandingDiscretionaryAccessControlinrustedSystems5]e-scribesngreaterdepthachofhesemechanismsndiscussesssuesnvolvedndesigning,mplementing,ndvaluatinghem.ostofheproductsvaluatedodate,ncludingHoneywell'sMultics20],DEC'sVAX/VMS18],HewlettPackard'sMPE/VE[19],DataGeneral'sAOS/VS[17],Unisys'O S1100[27],andIBM'sMVS/SP[21],haveimplementedDACthroughheuseofACLs.T&T'sSystemV/MLS16 ]usestheraditionalUnixrotectionbits,ndTrustednformationSystems'TrustedXENIX25]mplementsbothprotectionbitsbydefault)ndACLsatheuser'sdiscretion).DACprovidestoindividualusersandgroupsthecapability tospecifyforeachoftheirobjectse.g.,ilesnddirectories)hekindsofaccessheystemwillgrantootherusersndgroups.hisapabilitysveryusefulorbothordinaryusersndystemadministrators.tllowseachuserodecideforhimselforherselfwhatndividualsandroupsfndividualsheystemhouldllowoead,rite,rxecutehedirectoriesndilesheorhereates.ystemdministratorsommonlyuseDACtoprotectystemdirectoriesandfilessothatordinaryusersanreadorexecute(orsearch,nheaseofdirectories)hem,butonlyystemdministratorsanmodifythem.orexample,DACenablesordinaryusersopoolprintjobsi.e.,writeintotheprintqueue)butdoesnotllowhemtoead,eorder,modify,oremoveotherusers'queuedjobs.nly programctingonbehalfofauserorgroupwithsystemprivilegesi.e.,ndividualorgroupowhichheprintqueuebelongs)anperformtheseactions.However,mostDACimplementationscontainaflawthatrendersthemsusceptibletoTrojanhorses.Thisisduetothefactthatwhenaauserexecutesaprogram,itrunswiththeDACccessesofthatuser.hisnableshefollowingscenariotooccur.

UnixisatrademarkofUnixSystemLaboratories,nc .4PasswordsgenerallyarenotonsideredncceptablemplementationofD A C .


40/83

A S S E S S I N G CONTROLLEDA C C E S SPROTECTION 6 1.anDev iouswritesaprogramthatperformsaveryusefulfunction,saytravel

expenseaccounting,andattachess o m el ineso fcodethatcopy all o f thefilesin themaildirectoryoftheuserw hoexecutesitintoadirectorythatDano w n s .

2.anivesveryonexecuteccessoisprogramndellsveryoneboutitsutility.H ealsoiveseveryonewriteaccessohisdirectory,butoesnotmentionthis.)

3.ic kNaiveexecutesDan'sprogramtocalculatehisravelexpenses.hepro-gramwor ksjustasDandescribedit,andNickiselated.Ho w e v e r ,unknowntohim,theprogramhasalsocopiedallofNick'smailfilesintoDan'sdirectory!

Becausefhisulnerabilityndhediscretionary"aturefD A C ,hisccesscontrolmechanismisnotsefuloregregatingobjectswithdifferentlassificationlevelso rategories.andatoryccessontrolmechanismsarenecessarytoprovideclassif icat ion-levelseparation.S o m eoperationalsystemshaveattemptedtouseD A C toenforcestrictneed-to-knowseparationbyassigningdifferentneed-to-knowategoriesodifferentgroups.A C isneitherintendedtob e ,noreffectiveas , mechanismfo rtrictlyenforcingneed -to-knoweparation.nderD A C ,nyuserw hoasranusurpheppropriatepermissionsbleoransferccessightsonotheruserow h o mdirectccess w o u l dotherwisebeforbidden.hefo l lowingtwoexamplesillustrateho w thismightoccur.

1.eorgeputstheresultsofhis latestprojectexperiment into georges-data.o en -surethatZeldaandFran,w hoareworking onthesameprojectandassignedtogroupproject,canreadtheresults,heassignsittheA C L s h o w ninFigure4 .3 .

project readothers noccess

Figure4.3 :C L fo rFilegeorges-data ZeldawantstoshareGeorge'sresultswithherfriendNeil ,w hoisnotworkingontheproject.oshecopiesgeorges-dataintoafilenamedzeldas-dataandsetsitsA C Lol lowbothherselfandNei loeadt.hehenellsNei lwhereheanin dhefile,ndeontinuesopreadccessoothersn similarmanner.WhilethisA C Lmaylookik eitwou ldprovidetheneededprotection,read"accessalso enablesanyuserin groupprojecttocopygeorges-dataintoanother


41/83

27 ROTECTIONM E C H A N I S M S filewithitsow nA C Lndossignotwhateveraccessesthatuserwishes .Thusafilew ho s econtentsareintendedtobeprotectedfromdisclosurecanbedisclosed tosupposedlyunauthorized"sers .

2.nmostUnixystems,typing"Is-g la"listallentriesin longformat,giving mode,numberoflinks,owne r ,group,size in bytes,andtimeoflastmodification)indirectorystudyproducestheoutputh o w nin Figure4.4.

drwxrwx2ally hackers 512ug2220:44 . /drwxx4ally users 3584pr2411:57 ../-rw-r2ally hackers 514ep1913:33 progress

Figure4.4:utputfrom DirectoryStudyGrouphackersncludes ed ,ally,ndOllie.edwantsomodifySally'sprogressfile,butshehasgivenhim(i.e.,g r ouphackers)onlyreadpermission.AlthoughTeddoesnothavewriteccessorogress,eknowsthatincehehaswriteaccesstoitscontainingdirectorystudyandreadaccesstothefile,hecangive himselfwriteaccessbyexecutingthesequenceofcommandsshownin Figure4 .5tovirtuallychangethefile'spermissionbits.

catrogress ewprogress #Copyheontentsfileprogresso#filenewprogressrmprogressRemovefileprogressmvnewprogressprogressRename ''newprogress" ''progress''chmod6 0rogressC hang eccessesorogressollow#ownerndgroupoeadndwritetFigure4.5:UnixCommandSequence

Inhisase,allyelievesheasufficientlyprotectedheril erogressso thatonlysheisabletowritetoit.oweve r ,becausegrouphackershasreadaccesstothecontainingdirectory,anyuserin g r ouphackersisabletose ethatafilenamedrogressexists.urther,writeccessodirectorytudyenablesanyuserofgrouphackerstomod i f ythedirectory'scontents.oanyuserin grouphackersisabletoaddfilestoanddeletefilesfromstudy andtovirtuallychangeheD A Cpermissiononnyfitsilesowhichheyhavereadi .e.,copy )access .Thus,anyuserin g r ouphackerscanmodifySally'sprogressfile.


42/83

A S S E S S I N G CONTROLLEDA C C E S SPROTECTION 8 A sisapparent,relianceonD A C controlcou ldveryquicklyresultinabreakdownofneed-to-knowprotection.WhileanA IS withmandatoryaccesscontrolscouldcontainthesameD A C vulnerability,thosecontrolsw o u ldconfinethepropagationtoasingle classif icat ionlevelandca tegory .D A C shouldotbeusedfo rseparationthatrequiresstrongenforcementandassurance.

4.3 OBJECTREUSEO necouldview theObjectReusecriterions ho w ninFigure4.6s negative"e-quirementinhattequireshatomethingbenotpresent."omeetheobjectreusecriterion,theA ISmustensurethatnoinformationgeneratedby oneuser'spro-cessisavailabletothe nextuser'sprocessw h e ntheobjectcontaining thatinformationisreallocated.A llauthorizationsotheinformationontainedwithinastorageobjectshallbere-vokedprioronitialssignment,llocationreallocationo ubjectromheTCB'spoo lo funusedstorageobjects.N oinformation,includingencryptedrepresen-tationsofinformation,producedb yapriorsubject'sactionsistobeavailabletoanysubjectthatobtainsaccesstoanobjectthathasbeenreleasedbacktothesystem.

Figure4.6:CSEC 2ObjectR e u s eCriterionNotethatheobjecteusecriterionefersostorage"bjects,sontrastedwiththenamedobjects"owhichheD A Criterionppl ies .toragebjectsnobjectthatsupportsbothreadandwriteaccessesandmayo rmaynotbenamed."AuideoUnderstandingObjectReusenrustedSystems7 ]xplainsheobjectreuseriterionndrovidesuidancenowoesignndncorporateffective objectreusemechanismsintoanAI S .Theobjectivebehindheobjecteuseequirementsopreventnformationrombeinginadvertently(andb yextension,deliberately)disclosedtouser snotauthorizedtoseeit.ncontrastwiththeD A C mechanism,whichseekstoprotectthecontainerso finformation(i.e.,namedobjects),theobjectreuserequirementseekstoprotecttheinformationcontainedinheAIS'sstorageobjects.husobjectreuserequiresthateachcontainerbeinitializedbeforeitisallocatedtoasubject.Ho w e v e r ,lthoughhelevelofabstractiontwhichtheobjecteusemechanismis implementedisthatofstorageobjects,ensuringcompleteandeffectiveimplementa-tionrequiresconsiderationfhow namedobjectsremappedntophysicalstorageobjects.Theobjectreuseguidelinedescribesamethodologyfo rdoingthis.Anumberofapproachesfo rmeeting theobjectr euserequirementexistandarespecific tothestorageobjectsbeingconsidered.Whethertheobjectreusemechanismoperates


43/83

29 PROTECTIONMECHANISMS atallocationo rdeallocationislefttothediscretionoftheimplementedThesystemmayinitializeastorageobjectanytimebetweenw h e nitreleasestheobjectw h e nitreallocatest.oweve r ,ifthesystemdoesnotnitializetheobjectmmediately,itmustprotects systemresourceanyinformationitcontains.able4.1dentifiess o m e examplesofpossibleobjectreusemechanisms.Notethatag iven typeofstorageobjectmayrequireonermoremechanisms.heobjecteuseguidelinediscusses thesemechanismsmorefully.

StorageObject ImplementationPrimaryStorage(e.g.,andomaccessmemory,ache,translationbuffer)

Overwritingmemorypagewithfixedorrandompatternand/orfo refficiency)new data

FixedMedia(e.g.,fixeddisk,erminal,peratorconsole)

Overwritingphysicaldatablocks Purgingassociatedentriesinpag e managementtablePurgingdirectoryinformationresidingonmedia

RemovableMedia On-lineoverwritingwithapprovedfixed o rrandompatternDeg aus s ing0Off-lineoverwriting

Table4.1:ObjectReuseMechanisms"Forur thernformat ionegardingataemanenceroducts ,ee Guideo UnderstandingDataRemanenceinAutomatedInformationSystems.3 ]4.4 AUDITTheAuditriterionrequiresheapabilitytoollectnformationregardingsystemevents,thussupportingthemonitoringofsystemu seandtheinvestigationo fposs ib leattemptsobreachsecur i ty .mportantly,heAuditriterion,h o w nnFigure4 .7


44/83

ASSESSINGCONTROLLEDACCESSPROTECTION 30 onpage0equireshatheAISbeapableofauditing,ndnothatheystemactuallyperformauditing.heaccreditorisresponsiblefordeterminingwhateventsthesystemmustuditndnydditionalmission-specificauditequirements.heInformationSystemSecurityOfficerISSO)ordesignateduditorsesponsibleforconfiguringanddministeringaudit.5

TheTCBhallbebleoreate,maintain,ndprotectrommodificationorunau-thorizedaccessordestructionanuditrailofaccesstotheobjectsitprotects.heauditdatashallbeprotectedbytheTCBsothatreadaccesstoitislimitedtothosewhoreuthorizedoruditdata.heTCBhallbebleoecordheollowingtypesofevents:seofidentificationnduthenticationmechanisms,ntroductionofobjectsintotheuser'sddresspacee.g.,ileopen,programnitiation),deletionofobjects,ctionsakenbyomputeroperatorsndystemdministratorsnd/orsystemsecurityofficers,ndothersecurityrelevantevents.oreachrecordedevent,theauditecordhalldentify:atandimeofthevent,user,ypeofevent,andsuccessorailureoftheevent.oridentification/authenticationeventstheoriginofrequeste.g.,erminalD)hallbencludedinheauditecord.oreventsthatn-troduceanobjectintoauser'saddressspaceandforobjectdeletioneventstheauditrecordhallncludehenameofheobject.heADPystemdministratorhallbeabletoelectivelyauditheactionsofanyoneormoreusersbasedonndividualidentity.

Figure4.7:CSECC2AuditCriterionAudit featuresprovide thecapabilitytorecord,examine,andreviewsecurity-relevantactivities onthesystemeitherastheyareoccurringorretrospectively.Thecapabilitytoperformreal-timeauditingsnotmongheminimalrequirementsforontrolledaccessprotection.6ather,hesystemmustprovidetheapabilityoonfigurehesystemtoudithesetofeventstheISSOpecifies,opresenthisnformationinmannerthatisusefulininvestigatingsecurityincidentsaftertheyhave occurred,andtomonitorusers'ctionsinordertonticipateandpotentiallyneutralizeimpendingsecurityattacks.AGuideoUnderstandingAuditnrustedSystems1]iscussesiveobjectivesoftheauditmechanism:

1.olloweviewofpatternsofaccessondividualobjects,ccesshistoriesofspecificprocessesandusers,ndheuseofvariousprotectionmechanismsandtheireffectiveness.

5ThenformationystemecurityOfficerGuideline33 ]providesguidanceoSSOsnonfig-uringauditmechanismstoaudittherequiredevents,andin reviewingandmaintainingaudittrails.6However,omeproducts,uchsDEC'sVAX/VMS18],oprovidesomeeal-timemonitor-ing/alarmingcapability.


45/83

31 ROTECTIONMECHANISMS

2.odetectrepeatedttemptstobypassprotectionmechanisms.3 .omonitoruseofprivileges.4 .odeterhabitualattemptstobypassthesystemprotectionmechanisms(whichrequiresthatusersknowhatheiractionsrebeingaudited).5.oprovideadditionalssurancehatheprotectionmechanismsareworking.

Aspointedoutinsection4.1,theintegrityoftheauditmechanismis highlydependentuponhentegrityofthe&Amechanisms.nlessheystempositivelydentifiesusers,itannotorrectlyassociatetheiractionswiththem,andnoauditmechanismcanbeeffective.swithallcontrolledaccessprotectionmechanisms,theTCBmustimplementheudit-collectionunction,ndonlySSOsorheirdesigneeshouldbebleonableordisableuditing,ndoonfigureheuditechanismi.e.,toetheventsobeecorded,heusersorwhichdatareobeollected,tc.)inccordancewithheecuritypolicy.heTCBmustprotecthedataheuditmechanismcollects;onlyauditpersonnelshouldbeabletoreadauditdata.urther,theTCBmustprotectheuditrailfromunauthorizedmodificationndfromlossdueooverwritingsuchsightoccurf ircularilewereusedotoreuditdata),exhaustionofphysicalmemoryreservedforstorageofauditdata,orasystemcrash.Thesystemmustbeabletoecordhefollowingtypesofevents:

seofidentificationanduthenticationmechanisms(i.e.,login).ntroductionofobjectsintoauser'saddresspacee.g.,fileopen,filecreation,

programexecution,filecopy).Deletionofobjectsrom user'sddresspacee.g.,ilelose,ompletionofprogramexecution,filedeletion).Actionstakenbycomputeroperatorsandsystemadministratorsand/orsystemsecurityadministratorse.g.,addingauser).

llsecurity-relevant events(e.g.,useof privileges,changestoDACparameters).roductionofprintedoutput.

Foreachauditableevent,theTCBmustbeabletorecordthefollowinginformation:ateandimeoftheevent.niqueidentifieroftheuseronwhosebehalftheubjectgeneratinghevent

wasoperating.


46/83

A S S E S S I N G CONTROLLEDA C C E S S PROTECTION 2 Typeo fevent(oneoftheabove).uccesso rfailureoftheevent.riginoftherequeste.g . ,erminalidentifier)fo ridentificationanduthenti-cationevents.ameoftheobjectthatw asintroducedintoo rdeletedfromtheuser'saddressspace .escriptionofactionstakenbythesystemadministrator(e.g.,modificationstothesecuritydatabases).

TheISSOo rdes igneemustbeabletoauditbasedonindividualidentityandonob -jectidentity.Whetherthesystemal lowstheISSOtopre-specifyindividualsand/orobjects,rprovides post-processoroxtractdatassociatedwithpecifiedn-dividualsnd/orobjects,s esignecis ion.rom ecurityperspective,itherapproachouldbedeemedcceptable.7ataompressionndeductionoolsrealsodesirablebutnotequired)eatures.numberofvendorshaveimplementedextensiveaudit-processingapabilitiesin theirproducts.o rexample,PrimeC o m - puter,nc.'sPrimos24]ndUnisysCorporation'sO S10 0SecurityRelease 27] provideauditingfacilitieswhichincludecollection,reduction/reporting,backup,andcrash-recoverycapabilities.

7Note,however,thatthepost-processingoptionmayresultin anaudit-collectionmechanism thatoverlyburdenshesystem,resultingin atendencyoturnuditingoff entirely.


47/83

ChapterDOCUMENTATIONANDLIFE-CYCLEASSURANCEAnumberofrequirementsarederivednotf rom thesecuritypolicy perse,butf rom thessuranceontrolobjectiveseeTable2.1npage1)ndromheeedsorevaluationvidencenddocumentationoupportontinuingmaintenanceftheevaluatedtrust.hishapterdiscusseshesedocumentationndife-cyclesupportrequirements.

5.1 DESIGNDOCUMENTATIONTheDes ig nDocumentationriterion,h o w nnFigure.1 ,ocusesnheneedodocumentcoverageoftheprotectionphi losophy .hilethisinformationisusefu lin understandinghow thesystemprovidestrust,itisnotsuff ic ienttoenableananalysttounderstandhedesignoftheA IS .M o r edetaileddes igndocumentationisneededtoensurethatthesystemcanb eunderstoodandmaintainedsecurely . Documentationshallbeavailablethatprovides descriptionofthemanufacturer'sphilosophyofprotectionandanexplanationofhow thisphilosophyistranslatedintotheTCB.ftheTCBiscomposedofdistinctmodules,theinterfacesbetweenthesemodulesshallbedescribed.

Figure5.1:TCSECC 2DesignDocumentationCriterionTheprimarypurposesofdesign documentationare:

T ohelpevaluators(e.g.,N S A productevaluators,technicalanalysts)chieveasuff ic ientunderstandingofthesystemtoenablehemtossesshecomplete-33


48/83

ASSESSINGCONTROLLEDACCESSPROTECTION 4 nessndorrectnessofthedesign,ndogivethemenoughonfidenceinhedeveloper'sunderstandingndapabilitiesowarrant ecommendationhat thesystembeapproved(e.g.,fornNSAatingorDAAaccreditation).

onableevelopersndaintainersonderstandheesignfheISwellenoughohatheyanmakeanynecessaryhangesoheAISwithoutadverselyaffectingthesystem'strustworthiness.

Inordertoervethesepurposes,hedesigndocumentationmustdescribelloftheprotectionmechanismsoftheTCB.notherwords,hedesigndocumentationmustaccuratelyandompletelydescribeallofthesoftware,firmware,andhardwarecom-ponentsandhowtheyworktogether.Thesedescriptionsshouldbeinsufficientdetailtonablenvaluator,ystemprogrammer,orertifierounderstandheecuritydesignandimplementationsuchhatheorshecanpredicthesecurityimpactsofahypothesizedorproposedmodification.AsdiscussedinChapter,achconceptuallayer"oftheTCBmustbetrustworthyfromtheperspectiveofitsoverlyinglayers.hehardwareandoftwaredesigndocu-mentationneedstoclearlydescribehowthistrustworthinessis assured.orexample,thehardwaredesigndocumentationshoulddescribethenterfacebetweenthehard-wareandheoperatingystemnufficientdetailonableomeonenalyzinghesystemtofeelassuredthattheTCBcannotbecircumvented(i.e.,compromisedfrombelow),nablingnunprivilegeduserogaindirectccessoheystem'sphysicalresourcese.g.,diskblocks,physical/O).imilarly,heoftwaredesigndocumen-tationmustdescribehowheTCBprovideself-protectionndsolationromuserprocessesi.e.,preventscompromisefromwithinandromabove).Gooddesigndocumentationdescribeshowheprotectionmechanismselateoheoverallarchitectureofthesystem.GuideoUnderstandingDesignDocumentationinTrustedSystems[4 ]providesguidancethatdeveloperscanuseinassuringthattheirdesigndocumentationisacceptable,ndthatnalystsanuseintheirevaluation.

5.2 SYSTEMINTEGRITYTheSystemIntegritycriterion,showninFigure5.2,slevieduponthehardwareandfirmwarecomponentsoftheTCB."Integrity"mplieshatomethingsaintainednnnimpairedondition,ndsystemntegrityimplieshatnAISndheystemdatauponwhichtsoperationdependsremaintainedn ufficientlyorrectndonsistentondition.37]heintentofthesystemintegrityrequirementis toensurethatsomemechanism existstovalidatethecorrectoperationofallTCBhardware andfirmware(includingperipheraldevices).


49/83

35 OCUMENTATIONA N D LIFE-CYCLEASSURANCEHardwareand/orsoftwarefeaturessha l lbeprovidedthatcanbeusedtoperiodicallyvalidatethecorrectoperationoftheon-sitehardwareandfirmwareelementsoftheTCB.

Figure5.2:TCSECC 2SystemIntegrityCriterionTypically,thefirsttimethisrequirementc o m e sintoplayis atsystemboottime.Thesystemshouldprovides o m emechanismfo rassuringthattheTCBi.e.,allsecurity-relevanthardwareandfirmware,includingperipheraldevices)isinitializedcorrect ly .Thisshouldnotimposeaproblemfo rmostsystems,since mostcommerciallyavailablecomputersystemsprovideamechanismandproceduresfo rperformingacomprehen-sivediagnosticroutinew h e ntheyarepoweredon .Theystemls ohouldprovidemechanismsfo rperiodicallyvalidatingtheorrectoperationofitshardwareandf i r mwar e .o rexample,toolsfo rperformingcompr e - hensivediagnosticsollowingpreventivemaintenancectionsndonsureecuresystemshut-downshouldbeavailable.ocumentationdescribingthefunctionalityandoperationsofallintegritymechanismsshouldbeprovided.

5.3 CONFIGURATIONMANAGEMENTChangestoanexistingA ISareinevitable,andthepurposeofconfigurationmanage-ment( C M )istoensurethatthesechangestakeplacein acontrolled environmentandthatheyonotdverselyaffectnyrustpropertiesoftheystem.Mprovidesassurancehatdditions,deletions,ndhangesoheA ISonotompromiseitsinherenttrust.M thereforeisofcriticalimportancewithregardtol ife-cycle assurance .uringdevelopmentandin operation,heAIS'ssoftwareandhardwaremustnotbechangedimproperlyo rwithoutauthorization,control,andaccountability.TheTCSECdoesnotspecifyaConfigurationManagementcriterionfo rclasseslower thanB 2.oweve r ,heA ISorganizationhou ldecogn izehemportanto lehatC Mplaysbothnperformingheechnicalanalysisndnssuringheontinuedsecureoperationftheystem.lthoughC Msnot controlled-access-protectionrequirement,equiringoundMolicyndrocedures,ndubjectinghemotechnicalassessment,arestronglyrecommended.A ISsbeinganalyzedfo rcertificationandaccreditationshouldprovidedocumentationandcomplianceevidencedemonstratingthataneffective C M programexistsandthatconfigurationcontrolisenforced .AuideonderstandingonfigurationManagementnrustedSystems2 ]is -cussesheConfigurationManagementriterionmposedonproducesubmittedfo r


50/83

ASSESSINGCONTROLLEDACCESSPROTECTION 6 aB2oraboveratingndprovidesagoodoverviewoftheCMprocessndhefunc-tionsnvolved:onfigurationdentification,onfigurationontrol,onfigurationta-tusccounting,ndonfigurationudit.IL-STD-483,onfigurationManagementPracticesforSystems,Equipment,Munitions,ndComputerPrograms[12],providesCMstandardsobeappliedtoDoDystems.SuggesteditemstooverintheAIS'sCMplanre:

nifieddiscussionofonfigurationontrolsmplementedbyhedeveloper;descriptionofheprocessorhandling hangeromntryntoheprocessthroughfinalpprovalandimplementation.-escriptionofthepproachusedodetermineconfigurationtemsCIs),

includingarationaleforhechosengranularity.-amingconventionsforCIs.-oliciesforcreatingnewCIsorhangingCIs.-ecompositionofthefollowingsystemomponentsntoCIs,withunique

identifiersforeach:1.heTCB.2.nyhardwarend/oroftwarefeatureshatreusedoperiodically

validatethecorrectoperationoftheTCB.3 .heSecurityFeaturesUser'sGuide.4 .heTrustedFacilityManual.5.hetestplan,hetestprocedureshathowhowthesecuritymecha-

nismsweretested,andtheexpectedresultsofthesecuritymechanisms'functionaltesting.

6 .hedesigndocumentation.7 .heCMPlan.

ExplanationoftheresultsofthepreliminaryscreeningofproposedchangesandadiscussionofanyidentifiedpotentialeffectsonheTCB.

escriptionofsafeguardsgainstheincorrectategorizationofchanges.etaileddiscussionofsecurityanalysisorchangesffectingtheTCB.escription ofhowtheConfigurationControlBoard(CCB)coordinatessecurity

anddesignnalysesndeviewsystemhanges,ncludingCCBomposition,linesofauthority,anddentificationofsecurityspecialistsandheirroles.

escriptionofthecontentofengineeringchangeordersandadiscussionofhowtheyaregeneratedndhandledwithinheCMsystem.


51/83

37 OCUMENTATIONA N D LIFE-CYCLEASSURANCEescriptionfproceduresorssuringhatllpprovedhangesremple -

mentedcorrectlyandthatonlyapprovedchang e saremade,includingthestruc-tureandnteractionsoftheimplementationandestgroupsndhemanage-mentofsystemcode .

escriptionfhenaturendoperationfheConfiguration ev iewBoard(CRB).

iscussion ofthefinalreview process .dentificationo fanylimitationso rconstraintsontheC M process .

5.4 TRUSTEDFACILITYMANUALN omatterhow strongthesecurityarchitectureandmechanismsare,andhow trust-worthytheusersre,nAIS'sweakes tink"stsdministrationandoperations.EveniftheA ISisbuiltonanEPLproduct,theprotectiontheproductiscapableofdeliveringisactuallyprovidedonlyif thesystemisconfigured in oneoftheevaluatedconfigurationsndicatedin theproduct'sEPLentryandisoperatedasdescribedin theTrustedFacilityManual(TFM).TheTFMcriterionshown in Figure 5.3addressesthiscriticalneed.AmanualaddressedotheADPystemadministratorsha l lpresentcautionsboutfunctionsandprivileges thatshouldbecontrolledw h e nrunningasecurefacility.Theproceduresfo rexaminingandmaintainingtheauditfilesaswel lasthedetailedauditrecordstructurefo reachtypeofauditeventshallbeg iven .

Figure5.3:TCSECC 2TrustedFacilityManualCriterionTheTFMiswrittenfo rA ISadministrators(e.g.,ISSO s )responsiblefo rconfigur ing,operating,ndmonitoringheystemndornvestigatingpotentialviolationsftheecurityolicy.o rom eystemsinparticular,productsated 3ndAl),thedministrativeroleisbrokenow nntouniqueprivilegeclassese.g . ,operator,securityadministrator,uditor).oweve r ,fo rontrolledaccessprotection, single privilegedroleisacceptable.ThisfactrenderstheTFMevenmoreimportant.GuidelinesforWritingTrustedFacilityManuals[32]providesadetaileddiscuss ionoftheTFMcriterionandtheimportantroletheTFMplaysin ensuringthetrustworthi-nessofthesystem,andnformationSystemSecurityOfficerGuideline33 ]iscussestheovera l lroleoftheISSO .TheTFMgenerallyisnotintendedtobepartoftheD A A accreditationpackage ,butsrequiredfo rcontrolledaccessprotectionandshouldb e examinedduringthetechnicalana lys is .heTFMspreparedoupportife-cycle


52/83

A S S E S S I N G CONTROLLEDA C C E S SPROTECTION 8 trustedsystemoperations,ndtsgoa lsoprovidedetailed,ccurateinformationonhow to :

1.onfigure andinstallthesystemtoasecurestate.2.peratethesystemin asecuremanner.3.akeeffective useof thesystem privileges andprotectionmechanismstocontrolaccesstoadministrativefunctionsanddatabases.4.void pitfallsandimproperuseofadministrativefunctionsthatw o u l dc o m p r o -

misetheTCBndusersecurity.

TFMsdistributedwithEPLproductsontainnformationddressingheseoals ,andftheA ISsbuiltnnEPLproduct,hisdocumenthouldepartfthesystem'sTFM.naddition,thesystem'sTFMshouldcontaininformationregardingsi te-specif icoperations,ncludingheecurityolicyoenforcednonf igur ingandoperatingtheA ISin itsuniqueenvironmentunderbothroutineandemergencysituations.

5.5 SECURITYFEATURESUSER'SGUIDEWhereastheTFMiswrittenfo rsystemadministrators,theSecurityFeaturesUsersGuide(SFUG)swrittenfo rthegeneral,unprivilegeduser softheA IS .TheSFUGcriterioniss h o w nin Figure5.4.singterminologyauserunfamiliarwiththeoper - atingsystemcanunderstand,theS F U G shoulddescribethesecuritymechanismsthesystem providestothegeneraluser.o rexample,theS F U G shouldexplainhow login works ,provideguidanceandwarningsregardingtheselectionandu seofpasswords,explainhow tose theD A C permissionsonfilesanddirectories,andbr ief lydiscusstheroleauditingplaysintheoperationo ftheA IS .TheobjectiveoftheSFUGistoprovideinformationandwarningstohelpassurethatthesystem'sprotectivefeaturesareusedappropriatelyandconsistently.Asinglesummary,chapter,o rmanualin use rdocumentationsha l ldescribethepro-tectionmechanismsprovidedyheTCB,uidelinesnheirse ,ndowheyinteractwithoneanother.

Figure5.4:TCSECC 2SecurityFeaturesUser'sGuideCriterionAGuideoWritingtheSecurityFeaturesUser'sGuideforTrustedSystems8 ]ro -videsguidancefo rpotentialauthorsofSFUGsndncludess o m eillustrativeanno -


53/83

39 OCUMENTATIONA N D LIFE-CYCLEASSURANCETheecuritymechanismsoftheADPystemshallbetestedndfoundowor kasclaimedinthesystemdocumentation.Testingshallbedonetoassurethattherearenoobviousw a y sfo ranunauthorizedusertobypasso rotherwisedefeatthesecurityprotectionmechanismsoftheTCB.Testingsha l lls oncludeaearchfo rbv iousf lawsthatw o u l dallow violationofresourceisolation,o rthatw o u l dpermitunautho-rizedaccesstotheauditorauthenticationdata.

Figure5.5:TCSECC 2SystemTestingCriteriontatedoutlines.1

5.6 TESTINGThef inalstepin thetechnicalanalysis(seeChapter6)istesting,which includesbothtestplanningndunningheunctionalests.heestobjectivewithespectocontrolledaccessprotectionsoscertainwhetherthedocumentedsecuritym e c h -anismswor kasheyaredescribed.otethatheTCSECSystemTestingcriterion(seeFigure5.5)equiresassuranceshatoobviousw a ys "xistobypassoroth-erwisedefeathesecurityprotectionmechanisms,and searchfo robvious"laws .Thus,the technicalanalysistosupportcertificationinvolvestestingto ensurethatthedocumentedsecurityfunctionalityexistsndworksaslaimed;hiseveloftestingdoesnotequireanin-depthpenetrationeffort,whichwou ldinvo lvethegenerationofhypothesestoascertainwhethernon-obv ious"penetrationsarepossible . NotethattheTCSECdoesnotprecisely defineobvious ,"ndwhatisobvious"oonenalystmayb eenigmatictoanother.heanalystshouldnterpretobvious"basedontheidentifiedthreatstothesystem.orexample,s o m eUnixulnerabil-itiesthatrewel l -known(i.e.,obvious")withincampuscomputingcentersmaybefarlessthreatening(i.e.,obvious")in aclosedD oD environment.Thenalystshouldonductunctionalestingtheusernterfaceofthesystem.Thats,heyhouldestllftheecurityfunctionalityvailabletohegeneral,unprivilegedser .llfthemechanismsi scussednChapter houldbeestedtoensurethatheyowhatheyareintendedtoondhatheyonotontain"obvious"l awsintheirdesigno rimplementation.fthesystemisbuiltonanEPLproduct,heestuiteprovidedwithheproductmaybesefulorhispurpose.Further,thesystemintegritymechanismsdiscussedin section5.2shouldbetestedtoensurethattheyw o r kasclaimed.

xUserrainingssmportantsserocumentation. InformationystemecurityOfficerGuideline[33]providessomeguidelinesfo ruse rtraining.


54/83

ASSESSING C O N T R O L L E D ACCESSP R O T E C T I O N0


55/83

ChapterTECHNICALANALYSIS6.1 SELECTIONOFANALYSTSA teamo fqualified individualsshouldbeselectedtoanalyzetheA IStoensurethatitprovidestherequiredlevelsofcontrolledaccessprotection.A llmembersoftheteamshouldhavehequivalentfateast bachelor'seg reenComputercienceo r ComputerEngineering.Atleastoneteammembershouldpossesstechnicalexpertiseincomputerhardwarearchitectures,andallmembersshouldpossesstechnicalexper-tisein operatingsystems.A llteammembersshouldbefamiliarwithandunderstandsecurityissuesrelatedtocomputerhardwareandoperatingsystems.naddition,theanalystsshouldunderstandthesystem'smiss ion ,itsenvironment,itssecuritypolicy,anditsidentifiedthreats.Beforebeginningthetechnicalanalysis,allmembersoftheteamshouldhaverece ivedtrainingnhemethodologydescribednhisdocumentndnheoperationsndinternalrchitectureoftheA ISobenalyzed.ftheystemsbuiltnnEPLproduct,heanalystshouldhaveobtainedndbecomefamiliarwiththeproduct'sFinalEvaluationReport.1llteammembersshouldfeelcomfortableonthesystemasbothadministratorsandgeneraluser sandshouldbeabletodes ignandimplementtestprogramsfo rthesystem.

xTheproduct'sEPLentrywil lcontainthetitleanddocumentnumberofthisreport,whichcanberequestedfromtheNTIS.

41


56/83

ASSESSINGCONTROLLEDACCESSPROTECTION 26.2 TECHNICALANALYSISPROCESSFigure 6 .1depictsthesteps(describedbelow)involvedinperforming atechnical anal-ysisofanAISoensurehattprovidestheunctionalityandssurancesnecessaryforcontrolledaccessprotection.lthoughhisprocesssorrectndompletewithrespectotsobjectives,tannotredictndoesnotddressmanyssueshat mayarisewhennalyzing complexsysteme.g.,ssueselatingtohecompositionof networks).Alsonotethatheorderofsomestepsoftheprocessarearbitraryandcouldbeonductedn differentorderornparallele.g.,DACnduditssess-ments).tepsnwhichdependenciesexistndorderismportantreidentified.snotedabove,theanalystshouldhaveaclearunderstandingofthesystem'smissionandpolicy,securityrequirements,conceptofoperations,andoperationalenvironmentbeforebeginningthisprocess.InheprocesslowhownnFigure6.1,achectangleepresentsnctivity,ndeachedgerepresentsapossibleourseofaction,withheconditionsassociatedwiththatctionnotedlongsidehedge.orveryctivity,onlyoneetofentryndexitconditionsappliesinanygiveninstance.fanincomingconditionalarci.e.,oneonheeftideofaectangle)sabeledOR,"henheoccurrenceofoneofheedgesssociatedwithhatonditionalwillesultnheactivity'sbeinginitiated.fanoutgoingconditionalarc(i.e.,oneontherightsideofarectangle)islabeledOR,"thentheactivityeffectsoneoftheactionsdentifiedonheoutgoingdges.2EachFix"asksssumedoncludeheCMprocess,hichwillssurehathecorrectiondoesnotdverselyaffectprecedinganalyses.fafixffects mechanismthathaslreadybeennalyzed,heprocesshouldevertohepointtwhichtheaffectedmechanismisnalyzed.orexample,fafixoorrectnuditdeficiencyaffectshemplementationofI&A,henalysishouldeturnoheAssess&A"task.TherustedProductEvaluationQuestionnaire40 ]seferencedrequentlynhefollowingaskdescriptions.hisquestionnairewasdesignedsnnstrumentorgatheringromvendorspreliminarynformationboutproductsubmittedoNSAforevaluation.However,thereferenceditemsareequallyapplicableinthecontextofthisanalysis.Asthisprocessflowshows,by fartheeasiestandmostdirectwaytoattaincontrolledaccessprotectionistobuildthesystemonaproductthathasbeenevaluatedbyNSAandratedC2orhigher(assumingitiscorrectlyconfigured,includingnomodificationstotheTCB).

2Thisnotationalsowil laccommodateAND"onditions,butbecausenoneoftheseonditionsappearin thediagram,theyrenotdef inedhere.


57/83

43 TECHNICALA N A L Y S I S

A s s e s s Sys tem Architecture

DesignAcceptabto/Non-EPLOR)loRAs s e s s D A C

DesignAcceptable

AnalyzeR isk PerformF ix

Figure6.1:ontrolledAccessProtectionTechnicalAnalysisProcess


58/83

ASSESSING C O N T R O L L E D A C C E S SP R O T E C T I O N 44

- A s s e s s Objec tReus e D e s i g n AcceptableAnalyze R isk Perform F ix

As s e s s Audi tDes ignAcceptable

AnalyzeR isk Fi xOR PerformF ix

As s e s s System Integri tyDesignAcceptable

AnalyzeR isk

> Fi xOR PerformF ix

Figure6.1:cont .)Control ledAccessPro tect ionTechnicalAnalysisProcess


59/83

45 T E C H N I C A LANALYSIS

cceptable/ H A s s e s s TFM Acceptable -HORRevi se

A s s e s s SFUG Acceptable

Rev ise

-WoR Rev i ew Secur i tyTes tPlan Acceptable -HOR

Rev ise

Rev i ewTes tProceduresAcceptab le

Rev ise

OR Conduc tSecur i tyTest ing

Acceptable DocumentRisk -O

Ana lyze R i s k

Develop Alternative

Summar i ze Find ings .(END)

E E


60/83

ASSESSINGCONTROLLEDACCESSPROTECTION 6 Step1.ssessConfigurationManagement.hefirsttepnhessess-

mentsogainssurancehat oundonfigurationmanagementpro-gramsnplace.histephouldbeperformedbeforenynalysisoftheystemtselfbeginsonsurehatllhangeshatremadetohesystemoftwarendocumentationreontrolled.heonfigurationmanagementrequirementisdiscussedinsection5.3.heanalystsreviewthedocumentationdescribingtheplansandproceduresforprovidingCM3andcontrol,andcomplete items1hrough4inSection2.13oftheTrustedProductEvaluationQuestionnaire.ncceptableCMystemwilloveralloftheitemsdiscussedinection5.3.TheanalystsscertainwhethertheCMystemasdocumentedisccept-ableandisenforcedasdocumented;ifnot,hedeveloperchangestheCMprogramasequired.

Step2.ssessDesignDocumentation.heecondtep,whichmustbeperformedbeforeandnparallelwiththesystemarchitecture assessment,isoeviewhedesignocumentation.egardlessofwhethernPLproductsused,henalystsvaluatehehardwarendoftwaredesigndocumentationtogainnunderstandingoftheystemandodeterminewhetheritmeetstheDesignDocumentationcriterionshowninFigure5. 1anddiscussedinection5.1.TheanalystsnsurethathedesigndocumentationforthehardwareandsoftwareaddressesllofthefunctionalityneededoupporthesecuritypolicyenforcedbytheAIS.Toascertainwhetherthisrequirementis met,theanalystsansweritem1inSection2.3,items1and15inSection2.4,anditem nSection2.14oftherustedProductEvaluationQuestionnaire.Ifthedesigndocumentationis incompleteordeficient,itis developedandreviseduntiltccuratelyndompletelydescribesheystem'sdesignandimplementation.

Step3.ssessSystemArchitecture.Thenextstep,whichshouldbeper-formedbeforeandnparallelwithnalyzingheecurityontrolmecha-nisms,sogain horoughnderstandingofheystemrchitecture.Duringhistep,henalystsecomeamiliarithherchitecturalfoundationuponwhichhesecuritymechanismsarebuiltnddeterminewhetherheISeetsheystemrchitectureriterioniscussednChapter ndhownnigure.3.fheecuritypolicyorheAISincludesmorethancontrolledaccessprotection,heanalystsalsoneedtodeterminehowhextensionoheecuritypolicyitsntoheoverallsecurityrchitecture. Forxample,manyDoDystemsredesignedo

3AlthoughhisnalysisddressesMelativeoheTCBnly ,llpplicableprogramsnddocumentationshouldbecontrolledwithinheC Mystem.


61/83

47 ECHNICALA N A L Y S I S providearestricteduserinterfacecomprisingasetofmenusfromwhich anoperatorunprivilegeduser)electsheunctionheorhewishesoperform,responsefieldsorw i n d o w sin which theoperatorentersrequesteddata,andoutputfieldsorwindows ,whereoutputandsystemstatusm e s -sagesmayappear.TheserestrictedinterfacesmaybeimplementedbyanuntrustedpplicationbuiltnopftheTCBi.e.,withoutmodifyingtheoperatingsystem)orasnextensiontotheTCB.Theanalystsmustexaminetheimplementationtodeterminewhichmethodsused.ftherestrictedinterfaceisanunprivilegedprogramresidingin theuserdomain(seediscussioninChapter3 ),thentheanalystsmustensurethattsdis-cretionaryccessontrolseeection.2 )ettingsreorrectndhatitsncludednystemesting,buteedmakeossertionsegardingitsrustworthinesselativetoheverallsystemarchitecture.fthein -terfaceispartoftheTCBnterface,thenitsmechanismsandassurancesshouldbenalyzedlongwithandndditiono)hemechanismsandassurancesdiscussedin thisguideline.4

fthesystemisbuiltonaproductratedC 2oraboveon theEPL,theanalystscanassumethatanN S A evaluationteamhasconductedanin-depthnalysisfthevendor'sproprietaryesigndocumentationandhasdeterminedthattheproductmeetstheSystemArchitecturerequirement.thispoint,henalystsneedonsurethatllofthefo l lowingconditionsaresat isf ied:

1.hesystemisbuiltontheevaluatedconfiguration.2.heTCBa snotbeenmodif iedi.e.,omodificationsoys-

temodehavebeenmade,ndopplicationsseprivilegedsystemcallsintendedonlyfo rinternalTCBuse).Answerques-tions nd nSection2.13oftheTrustedProductEvaluationQuestionnaire.)

3.hemechanismsdiscussedin Chapter4areconf iguredin accor -dancewiththeTrustedFacilityManual(seesection5.4)andtheAIS'ssecuritypolicy.

Ifanyoftheseconditionsdoesnothold ,andthedef iciency cannotbecorrected,heprocessproceedssfanon-EPLproductwer eused.Ifall oftheseconditionsaresat isf ied,theanalysisproceedstostep6.

fthesystemisnotbuiltonnEPLproductorisbuiltonanEPLproductin otherthanitsevaluatedconfiguration,theanalystsbegintherchitectureevaluationbyompletingheClnd 2temsn

4ThisrequiresmodificationoftheTCB,soif aC2-ratedproductisused,itsratingis invalidated,anditmustbeanalyzedasifanunevaluatedproducthadbeenused.H o we ve r ,informationcontainedintheFinalEvaluationReportfo rtheevaluatedproductwil lbeusefulin theevaluationprocess.


62/83

ASSESSINGCONTROLLEDA C C E S SPROTECTION 8 Sections2.1nd2.2anditems5and6in Section2.13oftheTrustedProductEvaluationQuestionnaire40 ]oa in fullunderstandingofa llofthesubjectsandobjectsin thesystem.Theanalystst

Date post:	14-Apr-2018
Category:	Documents
Upload:	robert-vale
View:	220 times
Download:	0 times

NCSC-TG-028 Assessing Controlled Access Protection

Documents