violet book

7/28/2019 Violet Book

1/61

DEPARTMENT OF

DEFENSE

ASSESSING CONTROLLEDACCESS PROTECTION

NCSC-TG-028

Library No. S-238,986

Version 1


2/61


3/61

pr ocessi ng sensi t i ve or cl assi f i ed i nf or mat i on pr ovi de at l eastcont r ol l ed access pr ot ect i on.

The obj ect i ves of t hi s gui del i ne and i t s suppor t i ng documentat i on setare:

1. To pr ovi de a met hodol ogy f or per f or mi ng a t echni cal anal ysi s t osuppor t t he cer t i f i cat i onof cont r ol l ed access pr ot ect i on i n AI Ss submi t t ed f or accredi t at i on;

2. To pr ovi de an i nt er i m appr oach f or achi evi ng cont r ol l ed accesspr ot ecti on unt i l a sui t abl eNSA- eval uat ed pr oduct i s avai l abl e; and

3. To cl ar i f y t he i nt ent , secur i t y f uncti onal i t y, and l evel ofassur ed pr ot ect i on t hat cont r ol l edaccess prot ect i on pr ovi des.

The gui dance provi ded i n t hi s document i s t ar geted t owar d mul t i - userAI Ss desi gned f or DoDoperat i ons i n syst em- hi gh secur i t y mode and i n dedi cated mode, wheredi r ect ed by t he DAA. Thi sgui dance does not speci f i cal l y addr ess connect i vi t y wi t h a l ocal - ar eaor wi de- area network. Nordoes i t addr ess rel ated ar eas such as physi cal secur i t y, TEMPEST,communi cat i ons secur i t y, oradmi ni str at i ve secur i t y ( e. g. , t r usted di str i but i on) .

Thi s gui del i ne i s wr i t t en t o serve as t he synergi st t hat i nt egrat esand consol i dat es i nf or mat i oncont ai ned i n t he f ol l owi ng document s i nt o a uni f i ed expl anat i on of t her equi r ement s f or and i nt entof cont r ol l ed access pr ot ect i on.

A Gui de t o Underst andi ng Audi t i n Tr ust ed Syst ems

A Gui de t o Underst andi ng Conf i gur at i on Management i n Trust ed

Syst ems

A Gui de t o Underst andi ng Desi gn Document at i on i n Trust ed

Syst ems

A Gui de t o Under st andi ng Di scr et i onar y Access Cont r ol i n

Tr ust ed Syst ems

A Gui de t o Under st andi ng I dent i f i cat i on and Aut hent i cat i on i n

Tr ust ed Syst ems

A Gui de t o Underst andi ng Obj ect Reuse i n Tr ust ed Syst ems

A Gui de t o Wr i t i ng t he Secur i t y Featur es User ' s Gui de f or

Tr ust ed Syst ems

Gui del i nes f or Wr i t i ng Tr ust ed Faci l i t y Manual s

Tr ust ed Pr oduct Eval uat i on Quest i onnai r e


4/61

The Nat i onal Computer Secur i t y Center ( NCSC) publ i shes and di st r i butest hese document s t osuppor t t he cer t i f i cat i on and accr edi t at i on of AI Ss r equi r ed t opr ovi de cont r ol l ed access prot ect i on.To r equest copi es of t hese document s, cont act t he Nat i onal Techni cal

I nf or mat i on Ser vi ce (NTI S) .

Cont ent s

l BACKGROUND 1

1. 1 NATI ONAL POLI CY 1

1. 2 SECURI TY ACCREDI TATI ON 2

1. 3 TRUSTED PRODUCT EVALUATI ON 3

1. 4 SCOPE AND PURPOSE 5

2 CONTROLLED ACCESS PROTECTI ON 9

3 ARCHI TECTURAL FOUNDATI ON 13

3. 1 TRUSTED COMPUTI NG BASE 13

3. 2 ENFORCEMENT 17

3. 3 DOMAI N SEPARATI ON 18

3. 4 DEFI NED SUBSET 20

3. 5 RESOURCE I SOLATI ON 20

4 PROTECTI ON MECHANI SMS 22

4. 1 I DENTI FI CATI ON & AUTHENTI CATI ON 22

4. 2 DI SCRETI ONARY ACCESS CONTROL 24

4. 3 OBJ ECT REUSE 28

4. 4 AUDI T 29

5 DOCUMENTATI ON AND LI FE- CYCLE ASSURANCE 33

5. 1 DESI GN DOCUMENTATI ON 33

5. 2 SYSTEM I NTEGRI TY 34

5. 3 CONFI GURATI ON MANAGEMENT 35

5. 4 TRUSTED FACI LI TY MANUAL 37

5. 5 SECURI TY FEATURES USER' S GUI DE 38

5. 6 TESTI NG 39

6 TECHNI CAL ANALYSI S 41

6. 1 SELECTI ON OF ANALYSTS 41


5/61

6. 2 TECHNI CAL ANALYSI S PROCESS 42

7 RI SK MANAGEMENT 53

7. 1 PROTECTI ON LI MI TATI ONS 54

7. 2 I DENTI FI ED DEFI CI ENCI ES 55

7. 2. 1 SYSTEM ARCHI TECTURE 55

7. 2. 2 I DENTI FI CATI ON AND AUTHENTI CATI ON 56

7. 2. 3 DI SCRETI ONARY ACCESS CONTROL 56

7. 2. 4 OBJ ECT REUSE 56

7. 2. 5 AUDI T 56

7. 2. 6 SYSTEM I NTEGRI TY 57

8 ACRONYMS 63

9 GLOSSARY 65

Li st of Fi gur es

1. 1 Nat i onal Pol i cy on Cont r ol l ed Access Pr ot ect i on 1

1. 2 DoDD 5200. 28 Ti met abl e f or C2 2

3. 1 Tr ust Hi er ar chy i n an AI S 13

3. 2 Rel at i onshi p bet ween Syst em Engi neer i ng and Assur ance 16

3. 3 TCSEC C2 System Ar chi t ect ur e Cr i t er i on 17

4. 1 TCSEC C2 I dent i f i cat i on and Aut hent i cat i on Cr i t er i on 23

4. 2 TCSEC C2 Di scr et i onary Access Cont r ol Cr i t eri on 24

4. 3 ACL f or Fi l e georges_dat a 26

4. 4 Out put f r om Di r ect or y St udy 27

4. 5 Uni x Command Sequence 27

4. 6 TCSEC C2 Obj ect Reuse Cr i t er i on 28

4. 7 TCSEC C2 Audi t Cr i t eri on 30

5. 1 TCSEC C2 Desi gn Document at i on Cr i t er i on 33

5. 2 TCSEC C2 System I nt egr i t y Cr i t er i on 35

5. 3 TCSEC C2 Tr ust ed Faci l i t y Manual Cr i t er i on 37

5. 4 TCSEC C2 Secur i t y Feat ur es User ' s Gui de Cr i t eri on 38

5. 5 TCSEC C2 Syst emTest i ng Cr i t er i on 39


6/61

6. 1 Cont r ol l ed Access Pr ot ect i on Techni cal Anal ysi s Pr ocess 43

Li st of Tabl es

2. 1 Secur i t y Pol i cy Cont r ol Obj ect i ves and I mpl ement at i onRequi r ement s 11

4. 1 Obj ect Reuse Mechani sms 29

Chapter 1

BACKGROUND

1. 1 NATI ONAL POLI CY

I n J ul y of 1987, t he Feder al gover nment i ssued the Nat i onal Pol i cy onCont r ol l ed AccessPr ot ect i on [ 36] , est abl i shi ng t he pol i cy f or aut omat ed i nf or mat i onsyst ems ( AI Ss) t hat ar e accessedby mul t i pl e user s wi t h di f f er ent aut hor i zat i ons t o t he i nf or mat i oncont ai ned i n t he syst em. ThePol i cy, shown i n Fi gur e 1. 1, mandat es t hat t hese systems provi deaut omated cont r ol l ed accesspr ot ect i on and t hat t hi s mi ni mal l evel of pr ot ect i on be pr ovi dedwi t hi n f i ve year s of t he Pol i cy' si ssuance. The Pol i cy gi ves t he Feder al agenci es r esponsi bi l i t y f orensur i ng t hat i t s pr ovi si ons ar ecar r i ed out .

Al l aut omated i nf ormat i on syst ems t hat are accessed by more than oneuser , when t hose user s donot have t he same aut hor i zat i on t o use al l of t he cl assi f i ed orsensi t i ve uncl assi f i ed i nf or mat i onprocessed or mai nt ai ned by t he automated i nf ormat i on syst em, shal lprovi de aut omated Cont r ol l edAccess Pr ot ecti on f or al l cl assi f i ed and sensi t i ve uncl assi f i edi nf or mat i on. Thi s mi ni mum l evel ofpr ot ect i on shal l be pr ovi ded wi t hi n f i ve year s of t he pr omul gat i on oft hi s pol i cy.

Fi gur e 1. 1: Nat i onal Pol i cy on Cont r ol l ed Access Pr ot ect i on

The Depar t ment of Def ense ( DoD) car r i es t he Pol i cy f or war d i nDi r ect i ve 5200. 28, Secur i t yRequi r ement s f or Aut omated I nf ormat i on Syst ems ( AI Ss) [ 38] , whi chspeci f i es r equi r ement s f or

AI Ss that handl e cl assi f i ed, sensi t i ve uncl assi f i ed, or uncl assi f i edi nf or mat i on. The Di r ect i vepr ovi des a r i sk- assessment pr ocedur e, ext r act ed f r om CSC- STD- 003- 85[ 11] , whi ch i s used t odet er mi ne t he mi ni mum Tr ust ed Comput er Syst em Eval uat i on Cr i t eri a( TCSEC) [ 14] eval uat i oncl ass r equi r ed f or an AI S, based on t he sensi t i vi t y of t he i nf or mat i onst ored i n or processed by theAI S and on t he cl ear ances of i t s user s. For AI Ss t hat pr ocess orhandl e cl assi f i ed and/ or sensi t i veuncl assi f i ed i nf or mat i on, and t hat , based upon t he pr escr i bed r i sk-assessment pr ocedure, r equi r e atl east cont r ol l ed access pr ot ect i on, t he Di r ect i ve mandat es an

i mpl ement at i on t i metabl e of 1992, asshown i n Fi gure 1. 2.


7/61

Al l AI Ss t hat pr ocess or handl e cl assi f i ed and/ or sensi t i veuncl assi f i ed i nf or mat i on and t hat r equi r eat l east cont r ol l ed access pr ot ecti on ( i . e. , cl ass C2 secur i t y) , basedon t he r i sk assessment proceduredescr i bed i n encl osur e 4, shal l i mpl ement r equi r ed secur i t y f eat ur es

by 1992.

Fi gur e 1. 2: DoDD 5200. 28 Ti metabl e f or C2

The Nat i onal Secur i t y Agency ( NSA) eval uates commer ci al product sdesi gned t o meet t he TCSECr equi r ement s and l i st s t hem i n i t s Eval uat ed Pr oduct s Li st ( EPL) [ 34]mai ntai ned by t he Nat i onalComputer Secur i t y Cent er ( NCSC) . The Di r ect i ve t asks t he NSA t o ser veas a f ocal poi nt f ort echni cal mat t er s r el at i ng t o t he use of t r ust ed comput er product s andt o pr ovi de t o the Depar t mentof Def ense ( DoD) component s, as requested, t echni cal assi st ance i neval uat i ng and cer t i f yi ngcomput er- based secur i t y f eat ur es of AI Ss used i n operat i onalenvi r onment s. Thi s gui del i ne i sr esponsi ve t o thi s t aski ng; i t s pur pose i s t o pr ovi de the DoDcomponent s t echni cal gui dance t osuppor t t he cer t i f i cat i on and accredi t at i on of oper at i onal syst ems.

1. 2 SECURI TY ACCREDI TATI ON

Pr i or t o al l owi ng an AI S t o handl e any cl assi f i ed or sensi t i vei nf or mat i on, a Desi gnated Appr ovi ngAut hor i t y ( DAA) must accredi t i t t o oper at e i n one of t hr ee secur i t ymodes: dedi cat ed, syst em hi gh,or mul t i l evel . I n dedi cat ed mode, al l user s have t he cl ear ance oraut hori zat i on and a need- t o- knowf or al l dat a handl ed by the AI S. I n system hi gh mode, al l user s have asecur i t y cl ear ance oraut hor i zat i on, but not necessar i l y a need- t o- know, f or al l dat ahandl ed by t he AI S. Mul t i l evel modeal l ows t wo or mor e cl assi f i cat i on l evel s t o be pr ocessedsi mul t aneousl y wi t hi n t he same AI S whennot al l user s have a cl ear ance or f or mal access appr oval f or al l dat ahandl ed by t he AI S.

A pr ogr am f or conduct i ng per i odi c r evi ew of t he adequacy of t hesaf eguar ds f or oper at i onal ,accredi t ed AI Ss al so must be est abl i shed. [ 38] The DAA shoul d be

i nvol ved i n al l phases of t hesystem acqui si t i on, begi nni ng wi t h t he devel opment of t he secur i t ypol i cy and oper at i ons concept ,and i ncl udi ng t he speci f i cat i on of t he secur i t y requi r ement s, r evi ewsconducted dur i ng t he desi gnand devel opment phases, and secur i t y t est i ng, t o ensure t hat he or sheunder st ands t he operat i onalneeds, how syst em components work t ogether , how t he syst emi nt er f aceswi t h other syst ems andor gani zat i ons, and the r i sks associ at ed wi t h the system.

The t echni cal eval uat i on of an AI S' s secur i t y f eatures and ot hersaf eguards, made i n suppor t of t he

accredi t at i on pr ocess, i s cal l ed cert i f i cat i on. Cert i f i cat i onest abl i shes t he extent t o whi ch a


8/61

par t i cul ar AI S' s desi gn and i mpl ement at i on meet a set of speci f i edsecur i t y r equi r ement s.Accredi t at i on i s t he DAA' s f or mal decl ar at i on t hat an AI S i s appr ovedt o oper at e i n a par t i cul arsecur i t y mode, usi ng a pr escr i bed set of saf eguar ds. Accredi t at i on i st he of f i ci al management

aut hor i zat i on f or oper at i on of an AI S and i s based on t hecer t i f i cat i on pr ocess as wel l as ot hermanagement consi derat i ons. The accr edi t at i on st at ement af f i xessecur i t y r esponsi bi l i t y wi t h t heDAA and shows t hat due car e has been taken f or secur i t y. [ 38] Al t houghcer t i f i cat i on i nvol ves agr eat deal mor e t han t he t echni cal anal ysi s descr i bed i n t hi sdocument , t he gui dance cont ai nedher ei n can pr ovi de a t echni cal basi s f or t he cer t i f i cat i on por t i on oft he accredi t at i on pr ocess.

1. 3 TRUSTED PRODUCT EVALUATI ON

The DoD pol i cy speci f i ed i n DoDD 5200. 28 st at es t hat :

Computer secur i t y f eat ur es of commerci al l y pr oduced pr oduct s andGover nment -devel oped or - deri ved pr oduct s shal l be eval uat ed ( as request ed) f ordesi gnat i on as t r ust edcomput er pr oduct s f or i ncl usi on on the Eval uat ed Product s Li st ( EPL) .Eval uat ed product sshal l be desi gnat ed as meet i ng secur i t y cri t er i a mai nt ai ned by t heNat i onal Comput erSecur i t y Cent er ( NCSC) at NSA def i ned by the secur i t y di vi si on, cl ass,and f eat ur e ( e. g. ,B, B1, access cont r ol ) descr i bed i n DoD 5200. 28- STD.

The NCSC mai nt ai ns t he EPL and, usi ng t echni cal suppor t f r om NSA,eval uat es, assi gns r at i ngst o, and ent ers ont o the EPL pr oducts desi gned and devel oped i naccor dance wi t h the TCSEC. NSAmai nt ai ns a cadr e of t r ust edpr oduct eval uat or s bot h f r om wi t hi n t heagency and f r om Feder al l yFunded Resear ch and Devel opment Corpor at i ons ( FFRDCs) . The t r ust edpr oduct eval uat i onpr ogr am ( TPEP) , descri bed i n det ai l i n Tr ust ed Pr oduct Eval uat i ons: AGui de f or Vendors [ 41] ,compr i ses t he f ol l owi ng f i ve phases:

1. Proposal Revi ew. When a vendor r equest s t hat i t s product be

eval uat ed f or possi bl ei ncl usi on on t he EPL, NSA pr escr eens t he pr oposed pr oduct r el at i ve t oi t s usef ul ness toDoD component s, i t s t echni cal mer i t ( t hr ough an i nt ensi ve Prel i mi naryTechni cal Revi ew) ,and t he vendor ' s commi t ment t o t he pr oduct .

2. Vendor Assi st ance. I f NSA deci des t hat t he pr oduct haspot ent i al mer i t , i t s i gns aMemorandum of Underst andi ng ( MOU) wi t h the vendor . Thr ough t hi s MOU,t he vendoragr ees ( among other t hi ngs) t o gi ve NSA eval uat ors access t o t hehi ghl y pr opr i et ar y

har dware and sof t ware desi gn document at i on needed t o per f orm aneval uat i on. Once t he


9/61

MOU i s si gned, NSA assi gns a smal l eval uat i on t eam t o t r ack t hepr oduct t hr ough i t sdevel opment and t o pr ovi de assi st ance i n t he i nt er pr et at i on andappl i cat i on of TCSECr equi r ement s f or t he t ar get ed cl ass. Thi s t eam wor ks cl osel y wi t h t hevendor t hroughout t he

devel opment of t he pr oduct t o hel p determi ne t he t ar geted di vi si on andcl ass and t o ensuret hat t he desi gn and devel opment al approach ar e compl i ant wi t h ther equi r ement s of t heTCSEC f or t hat cl ass .

3. Desi gn Anal ysi s. When devel opment i s compl ete, and al l of t her equi r ed document at i on i snear i ng compl et i on, t he pr oduct ent er s Desi gn Anal ysi s. Dur i ng t hi sphase, an expandedeval uat i on t eam compl et es t r ai ni ng ( t o t he l evel of an appl i cat i onsprogr ammer , f or syst emst ar geted f or up t o cl ass B1, and t o the l evel of a syst empr ogr ammer,f or syst ems t ar get edf or t he hi gher cl asses) . The t eam anal yzes t he pr oduct r el at i ve t o t heTCSEC r equi r ementsand wr i t es a det ai l ed I ni t i al Pr oduct Assessment Repor t ( I PAR) . Forpr oduct s t arget ed atB2 and above, a pr el i mi nar y ar chi t ect ur e st udy i s conduct ed, and atAl , t he t eam begi nsexami ni ng the f or mal ver i f i cat i on dur i ng thi s phase. I nf or mat i onnecessary f or desi gnanal ysi s i s gai ned t hr ough t horough revi ew of t he hardware andsof t war e desi gndocument at i on, exami nat i on of dr af t s of TCSEC- r equi r ed document at i on( e. g. , Secur i tyFeat ur es User s' Gui de, Tr ust ed Faci l i t y Manual , t est pl ans andpr ocedur es) , andi nteract i ons wi t h t he vendor . Because bot h t eam member s and vendorper sonnel ar e l i kel yt o be wi del y di sper sed geogr aphi cal l y, el ect r oni c communi cat i ons ar er el i ed upon heavi l yf or t eam and vendor communi cat i ons. Once the anal ysi s i s compl eted,t he team pr esent st he I PAR t o NSA' s Techni cal Revi ew Boar d (TRB) , whi ch serves as one oft he TPEP' spri mary qual i t y- cont r ol mechani sms. Based upon t he I PAR and the t eam' spr esent at i on, t heTRB provi des t o NSA management a r ecommendat i on as t o whether t hepr oduct i s r eady

t o begi n the Eval uat i on Phase.

4. Eval uat i on. Thi s phase i s t he act ual secur i t y eval uat i on of t hepr oduct . Dur i ng thi s phase,t he eval uat i on t eam compl et es t he desi gn anal ysi s, bui l di ng upon t hei nf or mat i on cont ai nedi n t he I PAR. Pr i or t o begi nni ng f uncti onal t est i ng, t he team pr esent si t s assessment t o t heTRB, wi t h a r equest t hat t he eval uat i on be al l owed t o proceed t ot est i ng. The t eam t henconducts f uncti onal t est i ng ( al l cl asses) and penet r at i on t est i ng( cl ass B2 and above) ,exami nes t he f i nal ver si ons of r equi r ed document at i on, and compl et es

t he Fi nal Eval uat i on


10/61

Repor t . At cl ass B2 and above, a syst em archi t ect ur e study and cover tchannel anal ysi s areconduct ed, and at Al , t he f or mal ver i f i cat i on i s val i dat ed. At t he endof t hi s phase, t heeval uat i on t eam agai n appear s bef or e the TRB t o pr esent i t s f i ndi ngsand t o r ecommend a

f i nal r at i ng. Successf ul compl et i on of t hi s phase r esul t s i n pl acementof t he vendor ' sproduct on t he EPL.

5. Rat i ng Mai ntenance. NSA' s RAt i ng Mai ntenance Phase ( RAMP)provi des a mechani smf or ensur i ng t he cont i nui ng val i di t y of a r at i ng ext ended t osuccessi ve ver si ons of t he r at edpr oduct .

The EPL, publ i shed semi - annual l y as par t of t he I nf or mat i on Syst emsSecur i t y Product s andSer vi ces Cat al ogue and updat ed quar t er l y, pr ovi des system acqui si t i onagent s a good sel ect i on ofC2- r at ed pr oduct s f r om whi ch t o sel ect pl at f or ms f or t hei rappl i cat i ons. I n addi t i on, t he EPLcont ai ns a number of product s t hat have been r ated B1 and above; al lof t hese cont ai n accept abl econt r ol l ed access prot ect i on mechani sms and, i f appr opr i at el yconf i gur ed, coul d be used i n asyst em- hi gh or dedi cat ed envi r onment . I n f act , some syst em- hi ghenvi r onment s, par t i cul ar l y t hosewi t h external i nt er f aces t o syst ems at di f f er ent l evel s, mi ght benef i tf r om t he addi t i onal l abel i ngcapabi l i t y t hat Di vi si ons B and A syst ems pr ovi de. Fur t her , more andmor e computer vendor s ar ebr i ngi ng t hei r pr oduct s t o t he NSA wi t h t he r equest t hat t hey beconsi der ed f or eval uat i on. Thi sbei ng t he case, a r easonabl e expect at i on i s t hat t he EPL wi l l cont i nuet o expand as mor e vendor sr ecogni ze t he commerci al val ue of NSA- r ated product s.

However , an assessment methodol ogy and t r ai ned anal yst s are needed f ort hose DoD programs f orwhi ch a sui t abl e NSA- r at ed C2 (or above) pr oduct does not exi st ort hat do not cur r ent l y have t her esour ces necessar y t o rehost t hei r sof t war e on a r at ed pr oduct . Thi sgui del i ne addr esses t heseneeds.

1. 4 SCOPE AND PURPOSE

Thi s document i s i nt ended t o be used by i ndi vi dual s t asked t o per f or ma t echni cal anal ysi s of anAI S i n suppor t of i t s cer t i f i cat i on and accr edi t at i on. The di st i ncti onbetween t he t erms "automat edi nf or mat i on system" and "t r ust ed pr oduct " i s i mpor t ant i n t hi scont ext . As def i ned i n t he Di r ect i ve,an aut omated i nf ormat i on syst em i s any assembl y of comput er har dware,sof t war e, and/ orf i r mwar e conf i gur ed t o col l ect , cr eat e, communi cat e, comput e,di ssemi nat e, pr ocess, st or e, and/ orcont r ol dat a or i nf or mat i on. [ 38] I n t hi s gui del i ne, t he t er m "AI S"

( or "syst em") r ef er s t o an AI S


11/61

t hat i s conf i gur ed f or a speci f i c pur pose r el evant t o the DoDcomponent f or whi ch i t i s bei ngaccredi t ed. The Di r ect i ve def i nes a t r ust ed pr oduct as a pr oduct t hathas been eval uat ed andappr oved f or i ncl usi on on t he Eval uat ed Product s Li st ( EPL) . [ 38] AnAI S may be bui l t on a

t r ust ed pr oduct ( or "EPL pr oduct " ) .

Thi s gui del i ne ser ves t o uni f y, i nt er pret , and appl y i nf or mat i oncont ai ned i n other document spubl i shed by t he NCSC. The f ol l owi ng document s ar e i ncorporated byr ef er ence t o suppor t t het echni cal anal ysi s of cont r ol l ed access pr ot ect i on.

A Gui de t o Underst andi ng Audi t i n Tr ust ed Syst ems di scusses

i ssues i nvol ved i ni mpl ement i ng and eval uat i ng an audi t mechani sm. I t provi des gui dancet o vendors on howt o desi gn and i ncor por at e ef f ect i ve audi t mechani sms i nt o t hei r

systems, and i t cont ai nsgui dance t o i mpl ement ors on how t o make ef f ect i ve use of t he audi tcapabi l i t i es t hat t r ustedsyst ems provi de. [ 1]

A Gui de t o Underst andi ng Conf i gur at i on Management i n Trust ed

Syst ems provi desgui dance to devel opers of t r ust ed syst ems on what conf i gur at i onmanagement i s and howi t may be i mpl ement ed i n t he syst em' s devel opment and l i f e cycl e. I tstresses thei mpor t ance of conf i gur at i on management f or al l syst ems and suggest show i t can bei mpl ement ed. [ 2]

A Gui de t o Underst andi ng Desi gn Document at i on i n Trust ed

Syst ems provi des gui dance i nunder st andi ng and meet i ng t he TCSEC' s desi gn document at i onr equi r ement s. I t st r essest he i mpor t ance of good desi gn document at i on i n mai nt ai ni ng secur i t yt hr oughout asyst em' s l i f e cycl e and descr i bes t he desi gn document at i on necessaryt o suppor t pr oductr evi ew and eval uat i on. [ 4]

A Gui de t o Under st andi ng Di scr et i onar y Access Cont r ol i nTr ust ed Syst ems di scussesi ssues i nvol ved i n desi gni ng, i mpl ement i ng, and eval uat i ngdi scr et i onar y access cont r ol( DAC) mechani sms. [ 5]

A Gui de t o Under st andi ng I dent i f i cat i on and Aut hent i cat i on i n

Tr ust ed Syst ems descr i best he i dent i f i cat i on and aut hent i cat i on ( I &A) r equi r ement s and pr ovi desgui dance t o vendor son how t o desi gn and i ncorporate ef f ect i ve I &A mechani sms i nto t hei rsyst ems. [ 6]


12/61

A Gui de t o Underst andi ng Obj ect Reuse i n Tr ust ed Syst ems

descr i bes t he obj ect r euser equi r ement and pr ovi des gui dance t o vendors on how t o desi gn andi ncor por at e ef f ecti veobj ect r euse mechani sms i nt o t hei r syst ems. [ 7]

A Gui de t o Wr i t i ng t he Secur i t y Featur es User ' s Gui de f or

Tr ust ed Syst ems expl ai ns t hemot i vat i on and meani ng of t he TCSEC r equi r ement f or a Secur i t yFeatur es Users' Gui de( SFUG) i n t er ms of audi ence, cont ent , and or gani zat i on. I t i saddr essed t o pot ent i al SFUGaut hor s. [ 8]

Gui del i nes f or Wr i t i ng Tr ust ed Faci l i t y Manual s pr esent s i ssues

i nvol ved i n wr i t i ng aTr ust ed Faci l i t y Manual ( TFM) . I t provi des gui dance t o vendor s on howt o document

f unct i ons of t r ust ed f aci l i t y management and r ecommends st r uctur e,f or mat , and cont ent t osat i sf y t he TCSEC r equi r ement s. [ 32]

Tr ust ed Product Eval uat i on Quest i onnai r e cont ai ns a l i st of

quest i ons t hat addr ess t heTCSEC cr i t er i a f r om cl ass C1 t hrough Al . I t was devel oped t o ser ve asa t ool f orf or mal i zi ng t he dat a- gat her i ng pr ocess r equi r ed dur i ng var i ous phasesof t he TPEP. [ 40]

The obj ect i ves of t hi s gui del i ne and i t s suppor t i ng documentat i on set

are:

To pr ovi de a met hodol ogy f or per f or mi ng a t echni cal anal ysi s t o

suppor t t he cer t i f i cat i onof cont r ol l ed access pr ot ect i on i n AI Ss submi t t ed f or accredi t at i on.

To pr ovi de an i nt er i m appr oach f or achi evi ng cont r ol l ed access

pr ot ecti on unt i l a sui t abl eNSA- eval uat ed pr oduct i s avai l abl e.

To cl ar i f y t he i nt ent , secur i t y f uncti onal i t y, and l evel of

assur ed pr ot ect i on t hat cont r ol l ed

access prot ect i on pr ovi des.

The r esul t s of t hi s anal ysi s al so can provi de val uabl e i nf or mat i on t osyst emdevel oper s andi nt egr ators at t empt i ng t o compose component s i nto compl ex syst ems. I ncomposed syst ems ( e. g. ,net wor ks) , t hi s assessment wi l l pr ovi de assur ance t hat each i ndi vi dualAI S pr ovi des t he r equi r edl evel of cont r ol l ed access pr ot ecti on. Thus t hi s anal ysi s wi l l beusef ul i n conduct i ng an eval uat i onby par t s [ 39] of t he tot al system.

The gui dance provi ded i n t hi s document i s t ar geted t owar d mul t i - user

AI Ss desi gned f or DoDoperat i ons i n syst em- hi gh secur i t y mode and i n dedi cated mode, wheredi r ect ed by t he DAA. Thi s


13/61

gui dance does not speci f i cal l y addr ess connect i vi t y wi t h a l ocal - ar eaor wi de- area network. Nordoes i t addr ess rel ated ar eas such as physi cal secur i t y, TEMPEST,communi cat i ons secur i t y, oradmi ni str at i ve secur i t y ( e. g. , t r usted di str i but i on) .

Thi s gui de' s pr i mar y audi ence i s t he anal yst s t asked t o per f or m at echni cal assessment of an AI S' scont r ol l ed access pr ot ect i on f eat ur es and assur ances. The anal ystshoul d begi n by r eadi ng Chapter2, whi ch def i nes t he secur i t y pol i ci es enf or ced by cont r ol l ed accesspr otect i on and expl ai ns howt he r equi r ement s ar e der i ved f r om t hese pol i ci es. The anal yst t henshoul d r evi ew Chapter 3, whi chdi scusses t he ar chi t ect ur al f oundat i on necessar y f or cont r ol l ed accesspr otect i on, and Chapt er 4,whi ch descr i bes t he secur i t y mechani sms t hat ar e bui l t upon i t . A goodunder st andi ng of t hei nf or mat i on cont ai ned i n Chapt er s 3 and 4 i s cr i t i cal t o the t echni calanal ysi s pr ocess.

To gai n an under st andi ng of t he documentat i on r equi r ed as evi dencet hat t he syst em was bui l tsecur el y and t hat i t can be operated and mai ntai ned wi t houtj eopar di zi ng i t s i nher ent secur i t y, t heanal yst shoul d next r evi ew Chapt er 5, whi ch addr esses l i f e- cycl eassur ances. Bui l di ng upon t hei nf or mat i on cont ai ned i n t hese chapt ers , Chapt er 6 descr i bes a pr ocessf or per f or mi ng a t echni calanal ysi s t o det ermi ne whet her an AI S pr ovi des adequate cont r ol l edaccess pr ot ect i on. Thi s anal ysi si s i nt ended t o ser ve as t he t echni cal basi s f or cer t i f i cat i on t osuppor t syst em accredi t at i on. Anysecur i t y anal ysi s i nvol ves a t r ade- of f bet ween pr ovi ded pr ot ect i on andassumed r i sk. Fi nal l y,Chapt er 7 di scusses r i sk management and i dent i f i es r i sks t hatcont r ol l ed access pr ot ecti on i si ncapabl e of count er i ng and r i sks resul t i ng f r om def i ci enci es whi chmay be i dent i f i ed dur i ng thet echni cal anal ysi s. I mpor t ant t er ms ar e i t al i ci zed i n t he text anddef i ned i n t he Gl ossar y (Appendi x9) .

Chapter 2

CONTROLLED ACCESS PROTECTI ON

AI S secur i t y i s concer ned wi t h cont r ol l i ng the way i n whi ch an AI S canbe used; t hat i s, cont r ol l i nghow user s can access and mani pul ate the i nf ormat i on i t processes.Der i vi ng t he secur i t yr equi r ement s f or a gi ven AI S r equi r es pr eci se def i ni t i on of t heobj ect i ves of t he desi r ed cont r ol ;i . e. , t he syst em' s secur i t y pol i cy. These cont r ol obj ecti ves wi l l var ydependi ng upon t he per cei vedt hr eat s, r i sks, and goal s of t he or gani zat i on f or whi ch t he AI S i sbei ng accredi t ed. Cont r ol l ed accesspr ot ect i on ( as def i ned i n t he TCSEC) i s f ounded on obj ect i ves r el at i ngt o three basi c t ypes of

cont r ol : secur i t y pol i cy enf or cement , account abi l i t y, and assur ance.Al l of t he requi r ement s f or


14/61

AI Ss pr ovi di ng cont r ol l ed access pr ot ect i on ar e der i ved f r om t heseobj ect i ves [ 14] , as shown i nTabl e 2. 1 on page 11.

Cont r ol l ed access pr ot ect i on pol i ci es ar e based upon a f undament alassumpt i on t hat t he AI S

pr ocessi ng envi r onment i s one of mut ual l y t r ust i ng and cooperat i nguser s. Recogni t i on of t hi s f acti s cri t i cal t o under st andi ng t he obj ecti ves of cont r ol l ed accesspr ot ect i on. The f eat ur es, assur ances,and most i mpor t ant l y t he under l yi ng syst em ar chi t ect ur e of an AI S thatpr ovi des cont r ol l ed accesspr otect i on ar e not i nt ended and do not pur por t t o pr event mal i ci ous orconcert ed act i ons ai med atci r cumvent i ng t he pr ot ect i on pr ovi ded.

Cont r ol l ed access pr ot ect i on asser t s t hat t he AI S pr ovi des:

Protect i on and cont r ol over who can l ogon t o the syst em.

Mechani sms t hat wi l l enabl e t he AI S t o make deci si ons r egardi ng

access t o resour ces basedupon t he expr essed wi shes of i t s user s ( wi t h no assurance t hatconcer t ed, mal i ci ous act i onscannot ci r cumvent t hi s mechani sm) .

The capabi l i t y t o gener at e a r el i abl e l og of user act i ons and

t o guar ant ee i t s cor r ect ness.

Cont r ol l ed access pr ot ecti on i s suf f i ci ent f or AI Ss oper at i ng i nsystem- hi gh or dedi cat ed secur i t y

modes. However , i f t he AI S expor t s cl assi f i ed i nf or mat i on t hatr equi r es assur ed cl assi f i cat i onl abel i ng or i nf or mat i on t hat i s sent t o a dedi cat ed or syst em hi gh AI Sat a l ower cl assi f i cat i on l evel ,cont r ol l ed access pr ot ect i on i s not suf f i ci ent . Adequat e t r eat ment oft hese cases i s beyond t he scopeof t hi s gui dance.

Cont r ol Obj ect i ves

Der i ved Requi r ement s

Secur i t y Pol i cy: A st at ement of i nt ent wi t hr egar d t o cont r ol over access t o and di ssemi nat i onof i nf or mat i on, t o be known as t he secur i t y pol i cy,must be preci sel y def i ned and i mpl ement ed f oreach syst em t hat i s used to pr ocess sensi t i vei nf or mat i on. The secur i t y pol i cy must accur at el yr ef l ect t he l aws, r egul at i ons, and gener al pol i ci esf r om whi ch i t i s der i ved.

Syst em Secur i t y Pol i cy

Di scret i onar y Secur i t y: Secur i t y pol i ci es

def i ned f or syst ems t hat are used to pr ocesscl assi f i ed or ot her sensi t i ve i nf or mat i on musti ncl ude pr ovi si ons f or t he enf or cement of


15/61

di scret i onar y access cont r ol r ul es. That i s, t heymust i ncl ude a consi st ent set of r ul es f orcont r ol l i ng and l i mi t i ng access based on i dent i f i edi ndi vi dual s who have been det ermi ned to have aneed- t o- know f or t he i nf or mat i on.

Di scr et i onary Access Cont r ol

Obj ect Reuse

Account abi l i t y: Syst ems t hat are used t o pr ocessor handl e cl assi f i ed or ot her sensi t i ve i nf or mat i onmust assure i ndi vi dual account abi l i t y whenever adi scret i onar y secur i t y pol i cy i n i nvoked.Fur t her mor e, t o assur e account abi l i t y t hecapabi l i t y must exi st f or an aut hor i zed andcompet ent agent t o access and eval uat eaccount abi l i t y i nf or mat i on by a secur e means,wi t hi n a r easonabl e amount of t i me, and wi t houtundue di f f i cul t y.

I dent i f i cat i on and Aut hent i cat i on

Audi t

Assur ance: Syst ems t hat are used to pr ocess orhandl e cl assi f i ed or ot her sensi t i ve i nf or mat i onmust be desi gned t o guar ant ee cor r ect andaccur at e i nt er pr et at i on of t he secur i t y pol i cy andmust not di st or t t he i nt ent of t hat pol i cy.Assur ance must be pr ovi ded t hat cor r ecti mpl ement at i on and oper at i on of t he pol i cy exi st st hr oughout t he syst em' s l i f e- cycl e.

Syst em Ar chi t ecture

System I nt egr i t y

Secur i t y Test i ng

Conf i gur at i on Management

Desi gn Document at i on

Tr ust ed Faci l i t y Manual

Secur i t y Feat ur es User ' s Gui de

Tabl e 2. 1: Secur i t y Pol i cy Cont r ol Obj ect i ves and I mpl ementat i onRequi r ement s

Chapter 3

ARCHI TECTURAL FOUNDATI ON

Comput er system ar chi t ect ur e i s t he f oundat i on upon whi ch al l AI St r ustwor t hi ness i s bui l t . Thi schapt er di scusses syst em ar chi t ect ur e as i t r el at es t o t r ust and t heconcept of a Tr ust ed Comput i ng

Base.


16/61

3. 1 TRUSTED COMPUTI NG BASE

I nher ent i n t he concept of t r ust i s some assur ance t hat t he tr ust edper son or ent i t y possesses t her equi r ed str engt h, capabi l i t y, and i nt egr i t y t o mer i t t hat t r ust. I nt he case of AI Ss, t r ust i s bui l t f r om

t he bot t om ( i . e. , har dwar e) up, wi t h each l ayer "t r ust i ng" i t sunder l yi ng l ayer t o per f or m t heexpect ed servi ces i n a rel i abl e and t r ust wort hy manner , as shown i nFi gur e 3. 1.

Fi gur e 3. 1: Tr ust Hi er ar chy i n an AI S

Each l ayer t r ust s al l of i t s under l yi ng l ayer s to rel i abl y pr ovi de t heexpect ed servi ces and behavi or .The user s t r ust t he appl i cat i ons t hey r un t o behave i n t he manner t heyexpect; t he appl i cat i on t r ust st he system cal l s i t makes t o t he oper at i ng system t o pr oduce t hedocument ed r esul t s; and theoperat i ng syst em t r ust s t he hardwar e t o behave i n a consi st ent andsaf e manner . Not e that t r ust i smeani ngf ul onl y r el at i ve t o t he behavi or s and st r engt hs expect ed; f orexampl e, t he appl i cat i onl ayer cannot expect t he oper at i ng system t o det ect al l bugs i n userpr ogr ams. Thi s i s par t i cul ar l yi mpor t ant r el at i ve t o t he t r ust i mpl i ed f or cont r ol l ed accesspr ot ect i on.

Thi s t r ust hi erar chy i s t he basi s f or t he concept of a Tr ust edComput i ng Base ( TCB) t hat cannot becompr omi sed f r omabove and that i s al ways i nvoked to enf orce asecur i t y pol i cy wi t h some degr eeof assur ance. For any AI S, t he TCB i ncl udes al l of t he sof t war e,f i r mware, and har dwarecomponent s r esponsi bl e f or enf or ci ng t he secur i t y pol i cy and al lcomponent s capabl e of af f ect i ngt he cor r ect oper at i on of t he secur i t y mechani sms ( see Chapt er 4) . Thust he TCB i ncl udescomponent s whose j ob i s t o per f or m some f unct i on r equi r ed t o enf or cet he secur i t y pol i cy ( e. g. ,pr ogr ams t hat check accesscont r ol set t i ngs on f i l es) and component st hat have no di r ectf uncti onal i t y r el at i ve t o t he secur i t y pol i cy, but r equi r e t hecapabi l i t y t o vi ol at e some par t of t hesecur i t y pol i cy of t he system( i . e. , pr i vi l ege) i n or der t o oper at eand t heref ore must be t r ust ed ( e. g. ,

an I / O dr i ver ) .

The TCSEC asser t s t hat a t r ust ed syst em ar chi t ect ure must exhi bi tpr ot ecti on pr oper t i es t hat wi l lenf or ce t hi s t r ust hi er ar chy. Thus t he concept of a ref er ence moni t or( or r ef er ence val i dat i onmechani sm) i s i nt r oduced. The ter m r ef erence moni t or r epr esent s anabst r act i on of t he por t i on oft he TCB t hat act ual l y val i dat es r ef er ences t o obj ect s and gr ant s ( ordeni es) access t o them. Amongt he pr oper t i es t hat t he ref er ence moni t or shoul d exhi bi t ar e that i tbe nonci r cumvent abl e ( i . e. ,al ways i nvoked) , t amperproof , and smal l enough t o be anal yzed and

t est ed. The TCSEC i mposes


17/61

i ncreasi ngl y st r i ct ar chi t ect ur al and syst em engi neer i ng r equi r ement son t he TCB at hi gher andhi gher cl asses of t r ust wor t hi ness. As shown i n Fi gur e 3. 2, t he mor esystem engi neer i ng goes i nt odesi gni ng t he TCB, t he mor e assur ed i s t he tr ust t hat i t pr ovi des. I nt hi s f i gur e, t he i ncreasi ng

system engi neer i ng requi r ement s are shown i n i t al i cs besi de eachconcept ual machi ne cl ass. Forcl asses C2 and B1, t he ref er ence moni t or need not be di f f erent i atedf r om t he rest of t he TCB ( whi chcompr i ses the ent i r e operat i ng syst em) , so t hat appl i cat i ons mustt rust essent i al l y al l of t heoperat i ng syst em and har dwar e. Cl ass B2 requi r es mor e syst emengi neeri ng t o ensure t hat t he TCBcompr i ses l argel y i ndependent modul es, t hus pr oduci ng an addi t i onall ayer of t r ust , as t he TCB i si sol at ed f r om non- secur i t y- r el evant oper at i ng- syst em ser vi ces. Cl assesB3 and A1 syst emar chi t ectures pr ovi de l ayer ed pr ot ecti on, wi t h al l l ayer s ul t i mat el yr el i ant upon a smal l ,concept ual l y si mpl e, t amperproof , and noncompromi sabl e r ef erencemoni t or t hat pl ays a cent r alr ol e i n enf or ci ng t he i nt er nal st r uct ur i ng of t he TCB and t he system.As t he i l l ust r at i on shows,appl i cat i ons r unni ng on a cl ass- C2 AI S ( i . e. , one desi gned t o pr ovi deonl y cont r ol l ed accesspr ot ect i on) must t r ust t he ent i r e oper at i ng syst em and al l of t hehar dwar e ( i . e. , al l physi calr esources) and f i r mware upon whi ch i t depends.

Fi gur e 3. 2: Rel at i onshi p bet ween Syst em Engi neeri ng and Assurance

The obj ect i ve and r esul t of t he TCSEC' s concept ual hi er ar chy of t r ustare t hat demonst r at i ngassur ance i n the t r ust wort hi ness of t he TCB becomes i ncr easi ngl yt r actabl e and assured as oneprogr esses up t he TCSEC hi erarchy of t r ust . At cl ass C2, t he TCB maybe l ar ge, di sper sed, andgener al l y unst r uct ur ed; as a r esul t , i t pr esent s a gr eat chal l enge t obot h eval uators and personsr esponsi bl e f or mai nt ai ni ng t he syst em' s secur i t y. At cl ass B2, t heTCB st i l l may be l ar ge, but t hef act t hat i t i s modul ar and t he r esul t of sound sof t war e engi neer i ngpr act i ces makes i t easi er t o

under st and, eval uate, and mai nt ai n t han l ower - r at ed pr oduct s; t hus,added assur ance i n i t st r ust wor t hi ness r esul t s. At cl asses B3 and A1, t he TCB i s smal l ,l ayer ed, and hi ghl y st r uct ur ed,t hus l endi ng i t sel f t o r i gor ous anal ysi s and t est i ng, and t o f or malver i f i cat i on ( A1) .

3. 2 ENFORCEMENT

Assur ance of t r ust r equi r es enf or cement of t he AI S' s secur i t y pol i cy."Enf orcement " i mpl i esconsi st ency, r el i abi l i t y, and ef f ecti veness. I n or der f or a TCB t oenf or ce t he secur i t y pol i cy, i t must

be both t amperpr oof and noncompr omi sabl e. The Syst emAr chi t ectur ecr i t er i on shown i n Fi gur e


18/61


19/61

Tamper i ng general l y r ef er s t o i mproper al t er at i ons; i n t hi s cont ext ,i t i nvol ves changi ng t he systemi n such a way that t he i nt ended behavi or of t he TCB i t sel f i s modi f i edwi t h r espect t o t heenf or cement of i t s secur i t y pr oper t i es. Thi s coul d happen, f orexampl e, i f TCB code, data

st r uct ur es, or cont r ol par amet er s wer e modi f i ed. The domai n of t he TCBal so must be sel f -protect i ng so t hat processes i n t he user domai n cannot t amper wi t h TCBcode, dat a st r uct ur es,cont r ol par amet ers , hardware, or f i r mware.

Compromi se can be exami ned f r om t hree per spect i ves: compromi se f r omabove, compromi sef r om wi t hi n, and compr omi se f r ombel ow. Compr omi se f r om above occur swhen an unpri vi l egeduser i s abl e t o wr i t e unt r ust ed code t hat expl oi t s a vul ner abi l i t y;e. g. , f i ndi ng an escape f r om ahi ghl y- r est r i cted menu i nt er f ace, i nst al l i ng or modi f yi ng a r ul e i n anunt r ust ed r ul e base thatsubver t s a t r ust ed r ul e base, or causi ng a deni al of ser vi ce. Thecompr omi se resul t i ng f r om t heexecut i on of a Tr oj an hor se ( see sect i on 4. 2) t hat mi suses t hedi scr et i onar y access cont r olmechani sm i s anot her exampl e of compromi se f r om above. Compromi se f r omwi t hi n occurs whena pr i vi l eged user or pr ocess mi suses t he al l ocat ed pr i vi l eges, or whena progr ammi ng er r or i s madei n t he i mpl ement at i on of a t r usted pr ogr am. For exampl e, compr omi sef r om wi t hi n coul d r esul tf r om a systemadmi ni str at or ' s acci dent al l y or i nt ent i onal l yconf i gur i ng t he access t abl esi ncor r ect l y. Compr omi se f r om bel ow occur s as a r esul t of mal i ci ous oracci dent al f ai l ur e of anunder l yi ng component t hat i s t r ust ed and can r esul t f r om f aul t s i n t hecompi l er or modi f i cat i ons t ot he hardware. [ 37]

Al t hough t he TCSEC cr i t eri on r equi r es onl y that t he TCB "mai nt ai n adomai n f or i t s ownexecut i on, " compr omi se f r omwi t hi n must be consi dered even f or t hesi ngl el ayer ed TCB. Toenabl e a TCB t o enf or ce t he secur i t y pol i cy, some subj ect s i nt er nal t ot he TCB must be "t r ust ed; "i . e. , t hey must r un wi t h pr i vi l eges t hat al l ow t hem t o bypass one ormor e of t he secur i t y

mechani sms. For exampl e, t he l ogi n pr ogr ammust r un wi t h pr i vi l ege,si nce unt i l i t compl et es i t sf unct i on, t he user on whose behal f i t i s r unni ng i s not yet known ( orat l east has not beenaut hent i cated) . Trust ed pr ogr ams must be anal yzed and t est ed j ust ast horoughl y as t hemechani sms t hat enf orce t he secur i t y pol i cy, t o ensure t hat t heybehave as speci f i ed and do notcompr omi se t he i nt egr i t y of t he TCB f r om wi t hi n.

An i mport ant aspect of domai n separ at i on wi t hi n the CPU i s " execut i onst ate" or "mode ofoperat i ons. " Most mul t i - user comput er syst ems have at l east t wo

execut i on st ates or modes of


20/61

oper at i on: pr i vi l eged and unpr i vi l eged. The TCSEC r equi r es t hat t heTCB mai nt ai n f or i t sel f adi st i nct execut i on st at e t hat pr ot ects i t f r om t he acti ons ofunt r ust ed user s. Some commonpr i vi l eged domai ns are t hose r ef er r ed t o as "execut i ve, " "mast er , ""syst em, " " ker nel , " or

"supervi sor" modes; unpr i vi l eged domai ns ar e somet i mes cal l ed "user , ""appl i cat i on, " or"pr obl em" s t ates. I n a t wo- st ate machi ne, pr ocesses r unni ng i n apr i vi l eged domai n may execut eany machi ne i nst r uct i on and access any l ocat i on i n memory. Processesr unni ng i n t he unpr i vi l egeddomai n ar e pr event ed f r omexecut i ng cer t ai n machi ne i nst r uct i ons andaccessi ng cer t ai n ar eas ofmemor y.

Probabl y t he most st r ai ght f orward approach f or i mpl ement i ng domai nsepar at i on i s t o desi gn aTCB t hat t akes advant age of mul t i - st at e hardwar e; i . e. , a CPU t hatprovi des t wo or more hardwarest at es ( r i ngs, modes, domai ns) . I BM' s Mul t i pl e Vi r t ual St or age/ Syst emProduct ( MVS/ SP) ,Di gi t al Equi pment Corpor at i on' s VAX/ VMS, and Data GeneralCor por at i on' s AOS/ VS i l l ust r at et he di ver si t y i n har dwar e- based domai n separat i on. MVS/ SP pr ovi des t woexecut i on st at es:pr obl em st at e f or user pr ogr ams and super vi sor st at e f or systemprogr ams. [ 21] VAX/ VMSprovi des f our pr ocessor access modes, whi ch are used t o pr ovi der ead/ wr i t e pr ot ect i on bet weenuser sof t ware and syst em sof t war e. [ 18] The MV/ ECLI PSE archi t ect ur e ofAOS/ VS provi des ei ghtexecut i on "r i ngs, " r angi ng f r om r i ng 0 ( most pr i vi l eged) t o r i ng 7( l east pr i vi l eged) , wi t h t he AOS/VS ker nel r unni ng i n r i ng 0 and user pr ogr ams i n r i ng 7, and wi t hf i r mware- i mpl ement ed gat espr ot ect i ng ri ng boundar i es. [ 17]

For most hardware pl at f orms, t he domai n separat i on r equi r ement wi l lmean that at l east t wohar dware st ates ar e pr ovi ded, where one st ate permi t s access ofpr i vi l eged i nst r ucti ons necessar yt o mani pul at e memory- mappi ng r egi st er s. Memory mappi ng al one i s notsuf f i ci ent t o meet t hi sr equi r ement , but may be used to enhance har dware i sol at i on. Forexampl e, Uni sys' OS 1100

Secur i t y Rel ease I pr ovi des domai n i sol at i on t hr ough t he use ofhar dware and sof t waremechani sms t hat i ncl ude per- pr ocess vi r t ual addr ess spaces, per-process st acks, and hardware-based st ate changes. [ 27]

However , t he mul t i - st ate mechani sm need not be t ot al l y i mpl ement ed i nhardwar e.

The Uni sys A Ser i es MCP/ AS wi t h I nf oGuard successf ul l y achi eved a C2r at i ng by i mpl ement i ngt he t wo- st at e concept wi t h a combi nat i on of "capabi l i t y- l i ke" har dwar emechani sms and TCB

sof t war e, i ncl udi ng the compi l er s. [ 26] I n capabi l i t y- based syst ems,t he TCB can be pr ot ect ed by


21/61

havi ng TCB and user domai ns cr eat ed when t he syst emi s i ni t i al i zed.Si nce par t of t he domai ndef i ni t i on i s t he abi l i t y t o access and modi f y t he dat a st r uct ur esneeded f or domai n t r ansi t i on,mul t i pl e st at es can be cr eat ed on si ngl e- st at e har dwar e.

Another appr oach f or meet i ng t hi s r equi r ement i s t o have al l useract i ons i nt er pr et ed by t he TCBbef or e i t act s upon t hem. Obvi ousl y, t hi s ent ai l s assur i ng t hat nomeans exi st f or an unt r ust ed usert o modi f y t he TCB. To pr ot ect agai nst compr omi se f r ombel ow, t her equi r ement f or domai nsepar at i on i mpl i es physi cal pr ot ect i on of t he har dware ( even t hought he exampl e ci t ed i n t heTCSEC r equi r ement i s sof t war e or i ented) . [ 9]

3. 4 DEFI NED SUBSET

The wr i t er s of t he TCSEC i nt ended t he second sent ence of t he Syst emAr chi t ect ur e r equi r ement t obe a "gr andf ather cl ause" t o enabl e syst ems desi gned bef ore t he TCSECexi st ed and add- onpackages such as RACF [ 23] and ACF2 [15] t o meet t he C2 cr i t er i on event hough t hey were notcapabl e of cont r ol l i ng al l subj ect s and obj ect s i n t he syst em.

The eval uat i on communi t y has i nter pret ed t hi s r equi r ement t o meanthat:

1. Onl y TCB- cont r ol l ed subj ect s can access al l obj ect s.

2. Subj ect s not under TCB cont r ol can access onl y obj ect s t hat ar enot under TCB cont r ol .

These const r ai nt s prevent uncont r ol l ed subj ect s f r om per f or mi ng r awi nput - out put ( I / O) t o( cont r ol l ed and uncont r ol l ed) devi ces and f r om accessi ng ( cont r ol l edand uncont r ol l ed) memory.I f uncont r ol l ed subj ect s wer e al l owed t o per f or m such oper at i ons, t heTCB woul d be unabl e t oenf or ce t he syst em secur i t y pol i cy wi t h r espect t o cont r ol l edr esour ces. [ 9]

3. 5 RESOURCE I SOLATI ON

The t hi r d sentence of t he Syst em Ar chi t ect ure r equi r ement r el at es t o

subj ect and obj ect subset t i ngdi scussed i n sect i on 3. 4 and si mpl y assures t hat t he TCB i mposes i t sdi scret i onar y access cont r ol sand audi t i ng on al l of t he subj ect s and obj ect s under i t s cont r ol .

Chapter 4

PROTECTI ON MECHANI SMS

The r equi r ements f or cont r ol l ed access prot ect i on compr i se bothmechani sms and assurances. Themechani sms are f unct i onal f eat ur es desi gned t o enf or ce t he secur i t ypol i cy and account abi l i t y

obj ect i ves di scussed i n Chapt er 2 and i ncl ude: i dent i f i cat i on andaut hent i cat i on, di scret i onar y


22/61

access cont r ol , obj ect r euse, and audi t ( see Tabl e 2. 1 on page 11) .

4. 1 I DENTI FI CATI ON & AUTHENTI CATI ON

Cont r ol l ed access prot ect i on mechani sms ul t i mat el y ar e t i ed to t het r ust wor t hi ness of t he AI S' s

i dent i f i cat i on and aut hent i cat i on mechani sms. One must be abl e t ot r ust t he system' s abi l i t y t oaccur at el y, consi st ent l y, and posi t i vel y i dent i f y each user , and t omai nt ai n t hat posi t i vei dent i f i cat i on t hr oughout t he user ' s l ogi n sessi on. Ot her wi se,cont r ol l ed access prot ect i on cannotbe assured, and any audi t data col l ect ed ar e rendered usel ess. Fort hi s reason, i f t he systeml acksaccept abl e i dent i f i cat i on and aut hent i cat i on mechani sms, i t cannot ber ecommended f oraccr edi t at i on.

The I dent i f i cat i on and Aut hent i cat i on cr i t er i on i s shown i n Fi gure4. 1. A Gui de t o Underst andi ngI dent i f i cat i on and Aut hent i cat i on i n Tr ust ed Syst ems [ 6] di scusses t hei dent i f i cat i on andaut hent i cat i on ( I &A) r equi r ement at l engt h and pr ovi des gui dance onhow t o desi gn and i mpl ementef f ect i ve I &A mechani sms.

Cont r ol l ed access pr ot ect i on seeks t o cont r ol user s' access t oi nf or mat i on i n t he AI S; speci f i cal l y,i nf or mat i on cont ai ned i n obj ect s t o whi ch users can r ef er by name. Al lf or ms of access cont r ol( di scret i onar y and mandat or y) r el y on t he syst em' s abi l i t y to i dent i f yuser s and to "pr ove" t hei ri dent i t y when t hey l og ont o t he syst em, and t o mai nt ai n a posi t i veassoci at i on bet ween eachi ndi vi dual user and t he act i ons f or whi ch he or she i s r esponsi bl e.

The TCB shal l r equi r e user s t o i dent i f y t hemsel ves t o i t bef or ebegi nni ng t o per f orm any otheract i ons t hat t he TCB i s expect ed to medi ate. Fur t her more, t he TCBshal l use a pr ot ect edmechani sms ( e. g. , passwor ds) t o aut hent i cat e the user ' s i dent i t y. TheTCB shal l prot ectaut hent i cat i on dat a so t hat i t cannot be accessed by any unaut hori zeduser . The TCB shal l be abl et o enf or ce i ndi vi dual account abi l i t y by pr ovi di ng t he capabi l i t y touni quel y i dent i f y each

i ndi vi dual APP syst em user . The TCB shal l al so pr ovi de t he capabi l i t yof associ at i ng t hi s i dent i t ywi t h al l audi t abl e acti ons t aken by t hat i ndi vi dual .

Fi gur e 4. 1: TCSEC C2 I dent i f i cat i on and Aut hent i cat i on Cr i t er i on

I dent i f i cat i on i s gener al l y i mpl ement ed by si mpl y aski ng f or a l ogi nname, usual l y associ at ed i nsome way wi t h t he person' s i dent i t y. The syst emchecks t hi s nameagai nst i t s l i s t of aut hor i zedusers. Then, t o pr ot ect agai nst an unaut hor i zed user ' s masquer adi ng ast he aut hor i zed user , t hesystem asks f or some "pr oof " ( aut hent i cat i on) t hat t he user i s whom he

or she cl ai ms t o be.


23/61

Aut hent i cat i on gener al l y i nvol ves one or more of t hr ee t ypes of"pr oof : " ( 1) somet hi ng t he userknows ( e. g. , a passwor d) , ( 2) somet hi ng the user has ( e. g. , anaut hent i cat i on devi ce) , or ( 3)somet hi ng t he user i s ( e. g. , a r et i nal scan) .

Most EPL product s i mpl ement I &A usi ng t he si mpl e l ogi n name andpassword, and thi s approachi s accept abl e. Some product s st r engthen t hei r password mechani sms byenf or ci ng r ul es such asagi ng and l engt h r equi r ement s ( e. g. , Hewl et t Packar d' s MPE V/ E [ 19] )or case r est r i cti ons andr equi r ement s f or speci al charact ers ( e. g. , I BM' s MVS/ XA wi t h RACF[ 22] ) , or by pr ovi di ngr andom- password gener ators ( e. g. , AT&T' s Syst em V/ MLS and Wang' sSVS/ OS [ 16] [ 28] ) .However , as wi t h any mechani sm, t he i nt egr i t y of password pr otect i oni s onl y as st r ong as t hei nt egr i t y and r esponsi bi l i t y of i t s user s. Regar dl ess of whet her anAI S i s bui l t on an EPL pr oduct ,t he Tr ust ed Faci l i t i es Manual ( see sect i on 5. 4) , t he Secur i t y Feat ur esUsers Gui de ( see sect i on 5. 5) ,t he syst em admi ni st r at or , and user t r ai ni ng shoul d al l st r ess user s'r esponsi bi l i t i es i n ensur i ng t hatt hei r passwor ds ar e di f f i cul t t o guess, pr ot ect ed, and changedr egul ar l y. The Depart ment ofDef ense Password Management Gui del i ne [13] di scusses i ssues rel at i ngt o the use of passwordsf or user aut hent i cat i on, and t he I nf or mat i on Syst em Secur i t y Of f i cerGui del i ne [ 33] di scusses usert r ai ni ng and passwor d management .

NSA has exami ned a number of subsyst ems desi gned t o provi de I &A,i ncl udi ng password devi ces,chal l enge- r esponse per sonal aut hent i cat i on devi ces, and bi omet r i cdevi ces. The I nf or mat i onSyst ems Secur i t y Product s and Ser vi ces Catal ogue [ 34] cont ai nsi nf or mat i on r egar di ng t hesedevi ces. These pr oduct s may of f er an i nt er i m sol ut i on f or a systemt hat i s not bui l t on an EPLproduct and t hat l acks I &A mechani sms. However , t he use of one or moresepar at el y- r at edsubsyst ems such as t hese does not i mpl y an overal l product r at i ng asdef i ned i n t he TCSEC.Mechani sms, i nt er f aces, and the extent of r equi r ed suppor t i ngf unct i ons f or each subsyst em may

di f f er subst ant i al l y and may i nt r oduce si gni f i cant vul ner abi l i t i est hat ar e not pr esent i n pr oduct swhose secur i t y f eatur es ar e desi gned wi t h f ul l knowl edge ofi nt er f aces, and hardware and sof t waresupport . Ther ef ore, i ncor por at i on of one or mor e eval uat ed subsyst emsi nt o an AI S i s notequi val ent t o bui l di ng an AI S on an EPL pr oduct .

4. 2. DI SCRETI ONARY ACCESS CONTROL

Cont r ol l ed access prot ect i on enf or ces a secur i t y pol i cy known asdi scr et i onar y access cont r ol( DAC) , whi ch i s a means of r est r i ct i ng access t o named obj ects based

upon t he i dent i t y of subj ect s


24/61

and/ or gr oups t o whi ch t hey bel ong. Syst ems t hat provi de DAC assuret hat access t o obj ect s t hatar e avai l abl e to user s ( i . e. , "named" obj ects) ar e cont r ol l ed at t he"di scret i on" of t he user ( or gr oup)wi t h whom t he obj ect i s associ at ed ( somet i mes cal l ed the "owner" oft he obj ect ) . The DAC

cr i t er i on i s shown i n Fi gur e 4. 2.

The TCB shal l def i ne and cont r ol access between named user s and namedobj ects (e. g. , f i l es andprogr ams) i n t he ADP syst em. The enf orcement mechani sms ( e. g. ,sel f / gr oup/ publ i c cont r ol s,access cont r ol l i st s) shal l al l ow user s t o speci f y and cont r ol shar i ngof t hose obj ect s by namedi ndi vi dual s or def i ned gr oups of i ndi vi dual s, or by bot h, and shal lpr ovi de cont r ol s t o l i mi tpr opagat i on of access r i ght s. The di scr et i onar y access cont r olmechani sm shal l , ei t her by expl i ci tuser act i on or by def aul t , pr ovi de t hat obj ect s ar e pr ot ect ed f r omunaut hor i zed access. These accesscont r ol s shal l be capabl e of i ncl udi ng or excl udi ng access t o thegr anul ar i t y of a si ngl e user . Accessper mi ssi on t o an obj ect by users not al r eady possessi ng accessper mi ssi on shal l onl y be assi gnedby aut hor i zed users.

Fi gur e 4. 2: TCSEC C2 Di scr et i onar y Access Cont r ol Cr i t er i on

Fi ve basi c mechani sms have been used t o i mpl ement DAC.

1. Access Cont r ol Li st s ( ACLs) i mpl ement an access cont r ol matr i x( wher ei n the col umnsr epr esent user s, t he r ows pr ot ect ed obj ect s, and each cel l i ndi cat est he t ype of access t o begr ant ed f or t he subj ect / obj ect pai r ) by repr esent i ng t he col umns asl i st s of user s at t ached t ot he pr ot ect ed obj ect .

2. Pr ot ect i on Bi t s use a bi t vect or , wi t h each bi t r epr esent i ng at ype of access. The most

common exampl e i s t he Uni x i mpl ement at i on of a ni ne- bi t vect or

r epr esent i ng r ead,wr i t e, and execut e accesses t o be gr ant ed to the obj ect ' s owner , i t sgroup, and ever yone el se.

3. Capabi l i t i es al l ow access t o a pr ot ected obj ect i f t her equester possesses the appr opr i atepr ot ected "capabi l i t y, " whi ch bot h i dent i f i es t he obj ect and speci f i est he access r i ght s t o beal l owed t o t he user who possesses t hat capabi l i t y.

4. Pr of i l es associ at e wi t h each user a l i st of pr ot ected obj ectst hat t he user may access.

5. Passwor ds associ at e one ( al l t ypes of access) or mor e( di f f er ent t ypes of access) passwor dswi t h each obj ect .

A Gui de t o Under st andi ng Di scr et i onar y Access Cont r ol i n Trust edSystems [ 5] descr i bes i n


25/61

great er depth each of t hese mechani sms and di scusses i ssues i nvol vedi n desi gni ng, i mpl ement i ng,and eval uat i ng t hem. Most of t he pr oduct s eval uat ed t o dat e, i ncl udi ngHoneywel l ' s Mul t i cs [20] ,DEC' s VAX/ VMS [18] , Hewl et t Packar d' s MPE/ VE [19] , Data General ' sAOS/ VS [ 17] , Uni sys'

OS 1100 [ 27] , and I BM' s MVS/ SP [21] , have i mpl ement ed DAC t hrough t heuse of ACLs.

AT&T' s Syst em V/ MLS [ 16] uses t he t r adi t i onal Uni x pr ot ecti on bi t s,

and Trust ed I nf ormat i onSyst ems' Tr ust ed XENI X [ 25] i mpl ement s bot h pr otect i on bi t s ( bydef aul t ) and ACLs ( at t heuser ' s di scr et i on) .

DAC pr ovi des t o i ndi vi dual user s and gr oups t he capabi l i t y t o speci f yf or each of t hei r obj ects ( e. g. ,f i l es and di r ectori es) t he ki nds of access the syst em wi l l gr ant t oother users and gr oups. Thi scapabi l i t y i s ver y usef ul f or bot h or di nar y user s and syst em

admi ni st r at or s. I t al l ows each user t odeci de f or hi msel f or her sel f what i ndi vi dual s and gr oups ofi ndi vi dual s t he syst em shoul d al l owt o r ead, wr i t e, or execut e t he di r ect or i es and f i l es he or shecreat es. Syst em admi ni st r at or scommonl y use DAC t o pr ot ect syst emdi r ect or i es and f i l es so t hatordi nar y users can r ead orexecut e ( or sear ch, i n t he case of di r ect or i es) t hem, but onl y systemadmi ni st r at or s can modi f yt hem. For exampl e, DAC enabl es or di nary user s t o spool pr i nt j obs( i . e. , wr i t e i nt o t he pr i nt queue)but does not al l ow t hemt o r ead, r eor der, modi f y, or r emove ot herusers' queued j obs. Onl y a

pr ogr am act i ng on behal f of a user or gr oup wi t h syst em pr i vi l eges( i . e. , i ndi vi dual or group t owhi ch t he pr i nt queue bel ongs) can perf or m t hese act i ons.

However , most DAC i mpl ement at i ons contai n a f l aw t hat r ender s t hemsuscept i bl e to Tr oj anhor ses. Thi s i s due to the f act t hat when a user execut es a pr ogr am,i t r uns wi t h t he DAC accessesof t hat user . Thi s enabl es t he f ol l owi ng scenar i o to occur .

1. Dan Devi ous wr i t es a progr amt hat per f orms a ver y usef ulf unct i on, say t r avel expenseaccount i ng, and at t aches some l i nes of code t hat copy al l of t he f i l es

i n t he mai l di r ectoryof t he user who execut es i t i nt o a di r ect or y t hat Dan owns.

2. Dan gi ves everyone execut e access t o hi s pr ogr amand t el l sever yone about i t s ut i l i t y. ( Heal so gi ves ever yone wr i t e access t o hi s di r ect or y, but does notment i on thi s. )

3. Ni ck Nai ve execut es Dan' s pr ogr am t o cal cul at e hi s t r avelexpenses. The progr am worksj ust as Dan descr i bed i t , and Ni ck i s el at ed. However , unknown t o hi m,t he pr ogr am hasal so copi ed al l of Ni ck' s mai l f i l es i nt o Dan' s di r ector y!

Because of t hi s vul ner abi l i t y and t he "di scr et i onar y" nat ur e of DAC,t hi s access cont r ol


26/61

mechani sm i s not usef ul f or segr egat i ng obj ect s wi t h di f f er entcl assi f i cat i on l evel s or cat egor i es.Mandat ory access cont r ol mechani sms are necessar y to provi decl assi f i cat i on- l evel separ at i on.

Some oper at i onal syst ems have at t empted t o use DAC t o enf orce st r i ct

need- t o- know separat i onby assi gni ng di f f er ent need- t o- know cat egor i es t o di f f er ent gr oups.DAC i s nei t her i nt ended t o be,nor ef f ect i ve as, a mechani sm f or st r i ct l y enf or ci ng need- t o- knowseparat i on. Under DAC, anyuser who has or can usurp the appr opr i ate per mi ssi on i s abl e t ot r ansf er access r i ght s t o anot heruser t o whomdi r ect access woul d ot herwi se be f or bi dden. The f ol l owi ngt wo exampl es i l l ust r at ehow t hi s mi ght occur .

1. Geor ge put s t he r esul t s of hi s l at est pr oj ect exper i ment i nt ogeorges_dat a. To ensure t hatZel da and Fran, who are worki ng on t he same pr oj ect and ass i gned t ogr oup pr oj ect , canr ead t he resul t s, he assi gns i t t he ACL shown i n Fi gur e 4. 3.

Fi gur e 4. 3: ACL f or Fi l e geor ges_dat a

Zel da want s t o shar e Geor ge' s r esul t s wi t h her f r i end Nei l , who i s notworki ng on t hepr oj ect . So she copi es georges_dat a i nt o a f i l e named zel das_dat a andset s i t s ACL t o al l owbot h her sel f and Nei l t o r ead i t . She t hen t el l s Nei l wher e he canf i nd t he f i l e, and hecont i nues t o spr ead access t o ot her s i n a si mi l ar manner .

Whi l e thi s ACL may l ook l i ke i t woul d pr ovi de the needed pr otect i on," r ead" access al soenabl es any user i n gr oup pr oj ect t o copy georqes_dat a i nt o anot herf i l e wi t h i t s own ACLand t o assi gn t o i t what ever accesses t hat user wi shes. Thus a f i l ewhose content s ar ei nt ended t o be pr ot ect ed f r om di scl osur e can be di scl osed t osupposedl y "unaut hor i zed"users.

2. On most Uni x systems, t ypi ng " i s -gl a" ( l i s t al l ent r i es i n

l ong f ormat , gi vi ng mode,

number of l i nks, owner , gr oup, si ze i n bytes, and t i me of l astmodi f i cat i on) i n di r ector yst udy pr oduces t he out put shown i n Fi gure 4. 4.

Fi gur e 4. 4: Out put f r om Di r ect or y St udy

Gr oup hacker s i ncl udes Ted, Sal l y, and Ol l i e. Ted want s t o modi f ySal l y' s progr ess f i l e,but she has gi ven hi m ( i . e. , gr oup hacker s) onl y r ead per mi ssi on.Al t hough Ted does nothave wr i t e access t o progr ess, he knows t hat si nce he has wr i t e access

t o i t s cont ai ni ngdi r ect or y st udy and r ead access t o t he f i l e, he can gi ve hi msel f wr i t eaccess by execut i ng


27/61

t he sequence of commands shown i n Fi gur e 4. 5 to vi r t ual l y change t hef i l e' s permi ssi onbi t s .

Fi gure 4. 5: Uni x Command Sequence

I n t hi s case, Sal l y bel i eves she has suf f i ci ent l y pr ot ected her f i l epr ogr ess so t hat onl y shei s abl e to wr i t e to i t . However, because gr oup hacker s has r ead accesst o t he cont ai ni ngdi r ect or y, any user i n gr oup hacker s i s abl e t o see t hat a f i l e namedpr ogr ess exi st s. Fur t her ,wr i t e access t o di r ect or y st udy enabl es any user of gr oup hacker s t omodi f y the di r ect or y' scont ent s. So any user i n gr oup hacker s i s abl e to add f i l es t o anddel et e f i l es f r om st udy andt o vi r t ual l y change t he DAC per mi ssi on on any of i t s f i l es t o whi cht hey have r ead ( i . e. ,copy) access. Thus, any user i n gr oup hacker s can modi f y Sal l y' spr ogr ess f i l e.

As i s appar ent , r el i ance on DAC cont r ol coul d ver y qui ckl y r esul t i n abreakdown of need- t o- knowpr otect i on. Whi l e an AI S wi t h mandatory access cont r ol s coul d cont ai nt he same DACvul ner abi l i t y, t hose cont r ol s woul d conf i ne the pr opagat i on t o as i ngl e cl assi f i cat i on l evel andcat egor y. DAC shoul d not be used f or separat i on t hat r equi r es st r ongenf orcement and assurance.

4. 3 OBJ ECT REUSE

One coul d vi ew t he Obj ect Reuse cr i t eri on shown i n Fi gur e 4. 6 as a"negat i ve" r equi r ement i n t hati t r equi r es t hat somet hi ng be "not pr esent . " To meet t he obj ect r eusecr i t er i on, t he AI S must ensur et hat no i nf or mat i on gener at ed by one user ' s process i s avai l abl e tot he next user s pr ocess when theobj ect cont ai ni ng t hat i nf or mat i on i s r eal l ocat ed.

Al l aut hor i zat i ons t o t he i nf or mat i on cont ai ned wi t hi n a st or ageobj ect shal l be r evoked pr i or t oi ni t i al assi gnment , al l ocat i on or r eal l ocat i on t o a subj ect f r om t heTCB' s pool of unused st or ageobj ect s. No i nf or mat i on, i ncl udi ng encr ypt ed r epr esent at i ons ofi nf or mat i on, pr oduced by a pr i or

subj ect ' s act i ons i s t o be avai l abl e t o any subj ect t hat obt ai nsaccess t o an obj ect t hat has beenr el eased back t o t he syst em.

Fi gur e 4. 6: TCSEC C2 Obj ect Reuse Cr i t eri on

Not e t hat t he obj ect r euse cr i t er i on r ef er s t o "st or age" obj ect s, ascont r ast ed wi t h t he "namedobj ect s" t o whi ch t he DAC cr i t er i on appl i es. A st or age obj ect i s anobj ect t hat suppor t s bot h readand wr i t e accesses and may or may not be "named. " A Gui de toUnder st andi ng Obj ect Reuse i nTr ust ed Syst ems [ 7] expl ai ns t he obj ect r euse cr i t er i on and provi des

gui dance on how t o desi gn andi ncor porat e ef f ect i ve obj ect r euse mechani sms i nt o an AI S.


28/61

The obj ect i ve behi nd t he obj ect r euse r equi r ement i s t o preventi nf or mat i on f r om bei ngi nadver t ent l y ( and by extensi on, del i ber at el y) di scl osed t o user s notaut hor i zed t o see i t . I n cont r astwi t h t he DAC mechani sm, whi ch seeks t o protect t he cont ai ner s of

i nf or mat i on ( i . e. , namedobj ect s) , t he obj ect r euse r equi r ement seeks t o pr ot ect t hei nf or mat i on cont ai ned i n the AI S' sst or age obj ect s. Thus obj ect r euse requi r es t hat each cont ai ner bei ni t i al i zed bef ore i t i s al l ocatedt o a subj ect .

However , al t hough the l evel of abst r act i on at whi ch t he obj ect r eusemechani sm i s i mpl ement ed i st hat of st or age obj ect s, ensur i ng compl et e and ef f ect i vei mpl ement at i on r equi r es consi der at i on ofhow named obj ects ar e mapped i nt o physi cal st orage obj ects. The obj ectr euse gui del i ne descr i besa met hodol ogy f or doi ng thi s.

A number of appr oaches f or meet i ng t he obj ect r euse r equi r ement exi stand ar e speci f i c t o t hest orage obj ects bei ng consi der ed. Whether t he obj ect r euse mechani smoper at es at al l ocat i on ordeal l ocat i on i s l ef t t o t he di scret i on of t he i mpl ement er . The syst emmay i ni t i al i ze a st or age obj ectany t i me between when i t r el eases t he obj ect when i t r eal l ocat es i t .However , i f t he syst em doesnot i ni t i al i ze t he obj ect i mmedi at el y, i t must pr ot ect as a syst emr esour ce any i nf or mat i on i tcont ai ns. Tabl e 4. 1 i dent i f i es some exampl es of possi bl e obj ect r eusemechani sms. Note t hat agi ven t ype of st orage obj ect may requi r e one or more mechani sms. Theobj ect r euse gui del i nedi scusses t hese mechani sms more f ul l y.

Storage Obj ect

I mpl ement at i on

Pr i mary St orage

( e. g. , r andom access memory, cache,

t r ansl at i on buf f er )

Overwr i t i ng memory page wi t h f i xed or

r andom pat t er n and/ or ( f or ef f i ci ency) newdat a

Fi xed Medi a

( e. g. , f i xed di sk, t er mi nal , oper at or consol e)

Over wr i t i ng physi cal dat a bl ocks

Pur gi ng associ at ed ent r i es i n page

management t abl e


29/61

Pur gi ng di r ect or y i nf or mat i on r esi di ng on

medi a

Removabl e Medi a

On- l i ne over wr i t i ng wi t h appr oved f i xed or

r andompatt er

Degauss i ng

Of f - l i ne over wr i t i ng

Tabl e 4. 1: Obj ect Reuse Mechani sms

4. 4 AUDI T

The Audi t cr i t er i on r equi r es t he capabi l i t y t o col l ect i nf or mat i onr egar di ng system event s, t hussuppor t i ng t he moni t or i ng of system use and t he i nvest i gat i on ofpossi bl e at t empt s t o br eachsecur i t y. I mpor t ant l y, t he Audi t cri t er i on, shown i n Fi gur e 4. 7 onpage 30 r equi r es t hat t he AI S becapabl e of audi t i ng, and not t hat t he syst em act ual l y per f or maudi t i ng. The accr edi t or i sr esponsi bl e f or determi ni ng what event s t he syst em must audi t and anyaddi t i onal mi ssi on- speci f i caudi t r equi r ement s. The I nf or mat i on System Secur i t y Of f i cer ( I SSO) ordesi gnat ed audi t or i sr esponsi bl e f or conf i gur i ng and admi ni st er i ng audi t .

The TCB shal l be abl e t o cr eat e, mai nt ai n, and prot ect f r ommodi f i cat i on or unaut hor i zed accessor dest r ucti on an audi t t r ai l of access t o t he obj ects i t pr ot ects.The audi t data shal l be prot ect ed byt he TCB so t hat r ead access t o i t i s l i mi t ed to t hose who ar eaut hor i zed f or audi t dat a. The TCBshal l be abl e t o r ecor d t he f ol l owi ng t ypes of event s: use ofi dent i f i cat i on and aut hent i cat i onmechani sms, i nt r oduct i on of obj ect s i nt o t he user ' s addr ess space( e. g. , f i l e open, pr ogr ami ni t i at i on) , del et i on of obj ect s, act i ons t aken by comput er oper at or sand syst emadmi ni st r at or s and/or syst em secur i t y of f i cer s, and ot her secur i t y rel evant event s. Foreach r ecor ded event , t he audi tr ecor d shal l i dent i f y: dat a and t i me of t he event , user , t ype ofevent , and success or f ai l ur e of t heevent . For i dent i f i cat i on/ aut hent i cat i on event s t he or i gi n of r equest( e. g. , t er mi nal I D) shal l bei ncl uded i n t he audi t r ecor d. For event s t hat i nt r oduce an obj ect i nt oa user ' s addr ess space and f orobj ect del et i on event s t he audi t r ecor d shal l i ncl ude t he name of t heobj ect . The APP syst emadmi ni st r at or shal l be abl e t o sel ect i vel y audi t t he act i ons of anyone or mor e user s based oni ndi vi dual i dent i t y.

Fi gur e 4. 7: TCSEC C2 Audi t Cr i t er i on


30/61

Audi t f eat ur es pr ovi de t he capabi l i t y t o r ecor d, exami ne, and r evi ewsecur i t y- r el evant acti vi t i es ont he syst em ei t her as t hey ar e occur r i ng or r et r ospect i vel y. Thecapabi l i t y t o per f or m r eal - t i meaudi t i ng i s not among t he mi ni mal r equi r ement s f or cont r ol l ed accesspr ot ecti on. Rat her , t he

syst em must pr ovi de the capabi l i t y t o conf i gur e the syst em t o audi tt he set of event s t he I SSOspeci f i es, t o pr esent t hi s i nf or mat i on i n a manner t hat i s usef ul i ni nvest i gat i ng secur i t y i nci dent saf t er t hey have occur r ed, and t o moni t or user s' act i ons i n or der t oant i ci pat e and pot ent i al l yneut r al i ze i mpendi ng secur i t y at t acks.

A Gui de to Under st andi ng Audi t i n Trust ed Syst ems [ 1] di scusses f i veobj ect i ves of t he audi tmechani sm:

1. To al l ow r evi ew of pat t er ns of access t o i ndi vi dual obj ect s,access hi stori es of speci f i cprocesses and user s, and the use of var i ous pr otect i on mechani sms andt hei r ef f ecti veness.

2. To detect r epeat ed at t empt s t o bypass protect i on mechani sms.

3. To moni t or use of pr i vi l eges.

4. To det er habi t ual at t empt s t o bypass t he system pr ot ect i onmechani sms ( whi ch requi r es t hatuser s know t hat t hei r act i ons are bei ng audi t ed) .

5. To pr ovi de addi t i onal assurance t hat t he pr ot ect i on mechani smsare worki ng.

As poi nt ed out i n sect i on 4. 1, t he i nt egr i t y of t he audi t mechani sm i shi ghl y dependent upon t hei nt egr i t y of t he I &A mechani sms. Unl ess t he system posi t i vel yi dent i f i es user s, i t cannot cor r ectl yassoci ate t hei r act i ons wi t h them, and no audi t mechani sm can beef f ect i ve. As wi t h al l cont r ol l edaccess pr otect i on mechani sms, t he TCB must i mpl ement t he audi t -col l ecti on f uncti on, and onl yI SSOs or t hei r desi gnees shoul d be abl e t o enabl e or di sabl e audi t i ng,and t o conf i gur e t he audi tmechani sm ( i . e. , t o set t he event s t o be r ecor ded, t he user s f or whi chdat a ar e t o be col l ect ed, et c. )

i n accor dance wi t h t he secur i t y pol i cy. The TCB must pr otect t he datat he audi t mechani smcol l ect s; onl y audi t per sonnel shoul d be abl e t o r ead audi t dat a.Fur t her , t he TCB must pr ot ect t heaudi t t r ai l f r om unaut hor i zed modi f i cat i on and f r om l oss due t ooverwr i t i ng ( such as mi ght occuri f a ci r cul ar f i l e wer e used t o st or e audi t dat a) , exhaust i on ofphysi cal memory reser ved f or st orageof audi t dat a, or a syst em crash.

The syst em must be abl e t o r ecor d t he f ol l owi ng t ypes of events:

Use of i dent i f i cat i on and aut hent i cat i on mechani sms ( i . e. ,l ogi n) .


31/61

I nt r oducti on of obj ects i nt o a user ' s addr ess space ( e. g. , f i l e

open, f i l e creat i on, pr ogr amexecut i on, f i l e copy) .

Del et i on of obj ects f r om a user ' s addr ess space ( e. g. , f i l e

cl ose, compl et i on of pr ogr amexecut i on, f i l e del et i on) .

Act i ons t aken by comput er oper at ors and syst emadmi ni st r at or s

and/ or syst em secur i t yadmi ni st r at or s ( e. g. , addi ng a user ) .

Al l secur i t y- r el evant event s ( e. g. , use of pr i vi l eges, changes

t o DAC par amet er s) .

Product i on of pr i nt ed out put .

For each audi t abl e event , t he TCB must be abl e to record t he f ol l owi ngi nf or mat i on:

Date and t i me of t he event .

Uni que i dent i f i er of t he user on whose behal f t he subj ect

gener at i ng t he event wasoper at i ng.

Type of event ( one of t he above) .

Success or f ai l ur e of t he event .

Or i gi n of t he r equest ( e. g. , t er mi nal i dent i f i er ) f or

i dent i f i cat i on and aut hent i cat i on event s.

Name of t he obj ect t hat was i nt r oduced i nt o or del et ed f r omt he

user ' s addr ess space.

Descr i pt i on of act i ons t aken by t he syst em admi ni st r at or ( e. g. ,

modi f i cat i ons t o the secur i t ydat abases) .

The I SSO or desi gnee must be abl e t o audi t based on i ndi vi duali dent i t y and on obj ect i dent i t y.Whet her t he system al l ows t he I SSO t o pr e- speci f y i ndi vi dual s and/ orobj ect s, or pr ovi des a post -pr ocessor t o ext r act dat a associ at ed wi t h speci f i ed i ndi vi dual s and/ orobj ects, i s a desi gn deci si on.Froma secur i t y perspect i ve, ei t her appr oach coul d be deemedaccept abl e. Data compressi on andr educt i on t ool s ar e al so desi r abl e ( but not r equi r ed) f eat ur es. Anumber of vendor s havei mpl ement ed extensi ve audi t - pr ocessi ng capabi l i t i es i n t hei r product s.For exampl e, Pr i me

Comput er, I nc. ' s Pr i mos [ 24] and Uni sys Cor porat i on' s OS 1100 Secur i t yRel ease I [ 27] pr ovi de


32/61

audi t i ng f aci l i t i es whi ch i ncl ude col l ecti on, r educti on/ r epor t i ng,backup, and cr ash- r ecover ycapabi l i t i es .

Chapter 5

DOCUMENTATI ON AND LI FE- CYCLE ASSURANCE

A number of r equi r ement s are der i ved not f r om t he secur i t y pol i cy perse, but f r om t he assur ancecont r ol obj ect i ve ( see Tabl e 2. 1 on page 11) and f r omt he needs f oreval uat i on evi dence anddocument at i on t o support cont i nui ng mai nt enance of t he eval uat edt r ust . Thi s chapt er di scussest hese document at i on and l i f e- cycl e suppor t r equi r ement s.

5. 1 DESI GN DOCUMENTATI ON

The Desi gn Documentat i on cr i t er i on, shown i n Fi gur e 5. 1, f ocuses ont he need t o documentcover age of t he pr ot ect i on phi l osophy. Whi l e thi s i nf or mat i on i susef ul i n under st andi ng how t hesystempr ovi des t r ust, i t i s not suf f i ci ent t o enabl e an anal yst t ounder st and the desi gn of t he AI S.More detai l ed desi gn document at i on i s needed t o ensur e that t he syst emcan be under st ood andmai nt ai ned secur el y.

Document at i on shal l be avai l abl e t hat pr ovi des a descr i pt i on of t hemanuf act ur er' s phi l osophy ofpr ot ect i on and an expl anat i on of how t hi s phi l osophy i s t r ansl at edi nt o t he TCB. I f t he TCB i scomposed of di st i nct modul es, t he i nt er f aces bet ween these modul esshal l be descr i bed.

Fi gur e 5. 1: TCSEC C2 Desi gn Document at i on Cr i t er i on

The pr i mar y purposes of desi gn documentat i on ar e:

To hel p eval uat or s ( e. g. , NSA pr oduct eval uat or s, t echni cal

anal yst s) achi eve a suf f i ci entunder st andi ng of t he syst emt o enabl e t hemt o assess t he compl et enessand cor r ectness oft he desi gn, and t o gi ve t hem enough conf i dence i n t he devel oper' sunder st andi ng and

capabi l i t i es t o warr ant a recommendat i on t hat t he system be appr oved( e. g. , f or an NSAr at i ng or DAA accredi t at i on) .

To enabl e devel opers and mai nt ai ner s t o under st and the desi gn

of t he AI S wel l enough sot hat t hey can make any necessary changes t o the AI S wi t hout adversel yaf f ecti ng t hesystem' s t r ust wor t hi ness.

I n or der t o serve these purposes, t he desi gn document at i on mustdescri be al l of t he pr ot ecti onmechani sms of t he TCB. I n ot her words, t he desi gn document at i on must

accur at el y and compl et el y


33/61

descr i be al l of t he sof t ware, f i r mware, and har dware component s andhow t hey work t oget her .These descr i pt i ons shoul d be i n suf f i ci ent detai l t o enabl e aneval uat or , syst empr ogr ammer , orcer t i f i er t o under st and the secur i t y desi gn and i mpl ement at i on sucht hat he or she can pr edi ct t he

secur i t y i mpact s of a hypothesi zed or pr oposed modi f i cat i on.

As di scussed i n Chapter 3, each concept ual " l ayer" of t he TCB must bet r ust wor t hy f r om t heper spect i ve of i t s over l yi ng l ayer s. The har dwar e and sof t war e desi gndocument at i on needs t ocl ear l y descr i be how t hi s t r ust wor t hi ness i s assur ed. For exampl e, t hehar dware desi gndocument at i on shoul d descr i be t he i nt er f ace between t he hardware andt he oper at i ng syst em i nsuf f i ci ent det ai l t o enabl e someone anal yzi ng t he system t o f eelassur ed t hat t he TCB cannot beci r cumvent ed ( i . e. , compr omi sed f r om bel ow) , enabl i ng an unpr i vi l egeduser t o gai n di r ect accesst o t he syst em' s physi cal r esour ces ( e. g. , di sk bl ocks, physi cal I / O) .Si mi l ar l y, t he sof t war e desi gndocument at i on must descr i be how t he TCB provi des sel f - pr otect i on andi sol at i on fr om userpr ocesses ( i . e. , pr event s compr omi se f r om wi t hi n and f r om above) .

Good desi gn document at i on descr i bes how t he pr otect i on mechani smsr el at e to t he over al larchi t ect ur e of t he system. A Gui de t o Unders t andi ng Desi gnDocument at i on i n Trust ed Syst ems[ 4] pr ovi des gui dance that devel oper s can use i n assur i ng that t hei rdesi gn document at i on i saccept abl e, and t hat anal yst s can use i n t hei r eval uat i on.

5. 2 SYSTEM I NTEGRI TY

The Syst em I nt egr i t y cr i t er i on, shown i n Fi gure 5. 2, i s l evi ed upont he hardware and f i r mwarecomponent s of t he TCB.

" I nt egr i t y" i mpl i es t hat somet hi ng i s mai nt ai ned i n an uni mpai r edcondi t i on, and systemi nt egr i t yi mpl i es t hat an AI S and t he syst emdata upon whi ch i t s operat i ondepends ar e mai ntai ned i n asuf f i ci ent l y cor r ect and consi st ent condi t i on. [ 37] The i nt ent of t hesyst em i nt egr i t y requi r ement i s

t o ensur e t hat some mechani sm exi st s t o val i dat e t he cor r ect oper at i onof al l TCB hardware andf i r mwar e ( i ncl udi ng per i pher al devi ces) .

Hardware and/ or sof t ware f eat ures shal l be pr ovi ded t hat can be usedt o per i odi cal l y val i dat e t hecor r ect operat i on of t he on- si t e hardware and f i r mware el ement s of t heTCB.

Fi gur e 5. 2: TCSEC C2 Syst em I nt egr i t y Cr i t er i on

Typi cal l y, t he f i r st t i me t hi s r equi r ement comes i nt o pl ay i s atsystem boot t i me. The system shoul d

pr ovi de some mechani sm f or assur i ng that t he TCB ( i . e. , al l secur i t y-r el evant hardware and


34/61

f i r mwar e, i ncl udi ng per i pher al devi ces) i s i ni t i al i zed cor r ectl y. Thi sshoul d not i mpose a pr obl emf or most syst ems, si nce most commerci al l y avai l abl e comput er syst emsprovi de a mechani sm andprocedures f or per f ormi ng a compr ehensi ve di agnost i c r out i ne when t heyar e power ed on.

The syst em al so shoul d provi de mechani sms f or per i odi cal l y val i dat i ngt he cor r ect oper at i on of i t shar dware and f i r mware. For exampl e, t ool s f or per f ormi ng compr ehensi vedi agnost i cs f ol l owi ngprevent i ve mai nt enance act i ons and t o ensure secur e syst emshut - downshoul d be avai l abl e.Document at i on descr i bi ng t he f unct i onal i t y and oper at i ons of al li nt egr i t y mechani sms shoul d bepr ovi ded.

5. 3 CONFI GURATI ON MANAGEMENT

Changes t o an exi st i ng AI S are i nevi t abl e, and t he pur pose ofconf i gur at i on management ( CM) i st o ensure t hat t hese changes t ake pl ace i n a cont r ol l ed envi r onmentand t hat t hey do not adver sel yaf f ect any t r ust pr oper t i es of t he system. CM pr ovi des assur ance t hataddi t i ons, del et i ons, andchanges t o the AI S do not compr omi se i t s i nher ent t r ust . CM t her ef or ei s of cri t i cal i mpor t ancewi t h regar d t o l i f e- cycl e assur ance. Dur i ng devel opment and i noper at i on, t he AI S' s sof t war e andhar dware must not be changed i mpr oper l y or wi t hout aut hor i zat i on,cont r ol , and account abi l i t y.

The TCSEC does not speci f y a Conf i gurat i on Management cr i t er i on f orcl asses l ower t han B2.However , t he AI S organi zat i on shoul d r ecogni ze the i mpor t ant r ol e t hatCM pl ays bot h i nper f or mi ng the t echni cal anal ysi s and i n assur i ng the cont i nued secur eoperat i on of t he syst em.Al t hough CM i s not a cont r ol l edaccess- pr ot ect i on r equi r ement ,r equi r i ng sound CM pol i cy andpr ocedur es, and subj ect i ng t hem t o techni cal assessment , ar e st r ongl yr ecommended.

AI Ss bei ng anal yzed f or cer t i f i cat i on and accredi t at i on shoul d pr ovi dedocument at i on andcompl i ance evi dence demonst r at i ng t hat an ef f ect i ve CM pr ogr am exi st s

and t hat conf i gur at i oncont r ol i s enf or ced.

A Gui de t o Underst andi ng Conf i gur at i on Management i n Tr ust ed Syst ems[ 2] di scusses t heConf i gurat i on Management cr i t er i on i mposed on product s submi t t ed f or aB2 or above r at i ng andpr ovi des a good over vi ew of t he CM pr ocess and the f unct i ons i nvol ved:conf i gur at i oni dent i f i cat i on, conf i gur at i on cont r ol , conf i gur at i on statusaccount i ng, and conf i gur at i on audi t .MI L- STD- 483, Conf i gurat i on Management Pract i ces f or Syst ems,Equi pment , Muni t i ons, and

Computer Progr ams [ 12] , pr ovi des CM st andar ds t o be appl i ed t o DoDsyst ems.


35/61

Suggested i t ems t o cover i n t he AI S' s CM pl an are:

Uni f i ed di scussi on of conf i gur at i on cont r ol as i mpl ement ed by

t he devel oper ; descr i pt i onof t he pr ocess f or handl i ng a change f r om ent r y i nt o the pr ocess

t hr ough f i nal appr oval andi mpl ement at i on.

- Descr i pt i on of t he appr oach used t o det er mi ne conf i gur at i on i t ems( CI s) , i ncl udi ng ar at i onal e f or t he chosen gr anul ar i t y.

- Nami ng convent i ons f or CI s.

- Pol i ci es f or creat i ng new CI s or changi ng CI s.

- Decomposi t i on of t he f ol l owi ng syst em component s i nt o CI s, wi t huni que i dent i f i er s

f or each:

1. The TCB.

2. Any har dwar e and/ or sof t ware f eat ur es t hat ar e used t oper i odi cal l y val i dat e t hecor r ect operat i on of t he TCB.

3. The Secur i t y Featur es User ' s Gui de.

4. The Tr ust ed Faci l i t y Manual .

5. The t est pl an, t he t est pr ocedur es t hat show how t he secur i t y

mechani sms wer et est ed, and the expect ed resul t s of t he secur i t y mechani sms'f uncti onal t esti ng.

6. The desi gn document at i on.

7. The CM Pl an.

Expl anat i on of t he resul t s of t he pr el i mi nar y screeni ng of

proposed changes and adi scussi on of any i dent i f i ed pot ent i al ef f ect s on t he TCB.

Descr i pt i on of saf eguar ds agai nst t he i ncor r ect cat egor i zat i onof changes.

Det ai l ed di scussi on of secur i t y anal ysi s f or changes af f ect i ng

t he TCB.

Descr i pt i on of how t he Conf i gur at i on Cont r ol Boar d (CCB)

coor di nat es secur i t y anddesi gn anal yses and r evi ews syst em changes, i ncl udi ng CCB composi t i on,l i nes ofaut hor i t y, and i dent i f i cat i on of secur i t y speci al i sts and t hei r r ol es.

Descr i pt i on of t he cont ent of engi neeri ng change order s and adi scussi on of how t hey ar e


36/61

gener ated and handl ed wi t hi n t he CM syst em.

Descr i pt i on of pr ocedur es f or assur i ng t hat al l appr oved

changes are i mpl ement ed corr ect l yand that onl y appr oved changes ar e made, i ncl udi ng the st r uct ure andi nt er acti ons of t he

i mpl ement at i on and t est groups and t he management of syst em code.

Descr i pt i on of t he nat ur e and oper at i on of t he Conf i gur at i on

Revi ew Board ( CRB) .

Di scussi on of t he f i nal r evi ew pr ocess.

I dent i f i cat i on of any l i mi t at i ons or const r ai nt s on t he CM

process.

5. 4 TRUSTED FACI LI TY MANUAL

No mat t er how st r ong t he secur i t y archi t ectur e and mechani sms ar e, andhow t r ust wort hy t he user sar e, an AI S' s "weakest l i nk" i s i t s admi ni st r at i on and oper at i ons.Even i f t he AI S i s bui l t on an EPLpr oduct , t he pr ot ect i on t he pr oduct i s capabl e of del i ver i ng i sact ual l y pr ovi ded onl y i f t he syst emi s conf i gur ed i n one of t he eval uat ed conf i gur at i ons i ndi cat ed i n t hepr oduct ' s EPL ent r y and i soperat ed as descr i bed i n t he Trust ed Faci l i t y Manual ( TFM) . The TFMcr i t er i on shown i n Fi gur e5. 3 addr esses t hi s cri t i cal need.

A manual addr essed t o t he ADP syst em admi ni st r ator shal l presentcaut i ons about f unct i ons andpr i vi l eges t hat shoul d be cont r ol l ed when r unni ng a secur e f aci l i t y.The procedures f or exami ni ngand mai nt ai ni ng t he audi t f i l es as wel l as t he det a

violet book

Documents