  Orange Book Parts I and II: THE CRITERIA and RATIONALE AND
  GUIDELINES
  NCSC/DOD/NIST (SGML by Andrew G. Morgan)
  December 1985 (translation 1996/12/31)

  HHiigghhlliigghhttiinngg is used in Part I to indicate criteria not contained in a
  lower class or changes and additions to already defined criteria.
  Where there is no highlighting, requirements have been carried over
  from lower classes without addition or modification. In Part II, high-
  lighting is used for emphasis.
























































  11..  DDIIVVIISSIIOONN DD::  MMIINNIIMMAALL PPRROOTTEECCTTIIOONN

  This division contains only one class.  It is reserved for those
  systems that have been evaluated but that fail to meet the
  requirements for a higher evaluation class.





























































  22..  DDIIVVIISSIIOONN CC::  DDIISSCCRREETTIIOONNAARRYY PPRROOTTEECCTTIIOONN

  Classes in this division provide for discretionary (need-to-know)
  protection and, through the inclusion of audit capabilities, for
  accountability of subjects and the actions they initiate.


  22..11..  CCLLAASSSS ((CC11))::  DDIISSCCRREETTIIOONNAARRYY SSEECCUURRIITTYY PPRROOTTEECCTTIIOONN

  _T_h_e _T_r_u_s_t_e_d _C_o_m_p_u_t_i_n_g _B_a_s_e _(_T_C_B_) _o_f _a _c_l_a_s_s _(_C_1_) _s_y_s_t_e_m _n_o_m_i_n_a_l_l_y
  _s_a_t_i_s_f_i_e_s _t_h_e _d_i_s_c_r_e_t_i_o_n_a_r_y _s_e_c_u_r_i_t_y _r_e_q_u_i_r_e_m_e_n_t_s _b_y _p_r_o_v_i_d_i_n_g
  _s_e_p_a_r_a_t_i_o_n _o_f _u_s_e_r_s _a_n_d _d_a_t_a_.  _I_t _i_n_c_o_r_p_o_r_a_t_e_s _s_o_m_e _f_o_r_m _o_f _c_r_e_d_i_b_l_e
  _c_o_n_t_r_o_l_s _c_a_p_a_b_l_e _o_f _e_n_f_o_r_c_i_n_g _a_c_c_e_s_s _l_i_m_i_t_a_t_i_o_n_s _o_n _a_n _i_n_d_i_v_i_d_u_a_l
  _b_a_s_i_s_, _i_._e_._, _o_s_t_e_n_s_i_b_l_y _s_u_i_t_a_b_l_e _f_o_r _a_l_l_o_w_i_n_g _u_s_e_r_s _t_o _b_e _a_b_l_e _t_o
  _p_r_o_t_e_c_t _p_r_o_j_e_c_t _o_r _p_r_i_v_a_t_e _i_n_f_o_r_m_a_t_i_o_n _a_n_d _t_o _k_e_e_p _o_t_h_e_r _u_s_e_r_s _f_r_o_m
  _a_c_c_i_d_e_n_t_a_l_l_y _r_e_a_d_i_n_g _o_r _d_e_s_t_r_o_y_i_n_g _t_h_e_i_r _d_a_t_a_.  _T_h_e _c_l_a_s_s _(_C_1_)
  _e_n_v_i_r_o_n_m_e_n_t _i_s _e_x_p_e_c_t_e_d _t_o _b_e _o_n_e _o_f _c_o_o_p_e_r_a_t_i_n_g _u_s_e_r_s _p_r_o_c_e_s_s_i_n_g _d_a_t_a
  _a_t _t_h_e _s_a_m_e _l_e_v_e_l_(_s_) _o_f _s_e_n_s_i_t_i_v_i_t_y_.  _T_h_e _f_o_l_l_o_w_i_n_g _a_r_e _m_i_n_i_m_a_l
  _r_e_q_u_i_r_e_m_e_n_t_s _f_o_r _s_y_s_t_e_m_s _a_s_s_i_g_n_e_d _a _c_l_a_s_s _(_C_1_) _r_a_t_i_n_g_:


  22..11..11..  SSeeccuurriittyy PPoolliiccyy

  22..11..11..11..  DDiissccrreettiioonnaarryy AAcccceessss CCoonnttrrooll

  TThhee TTCCBB sshhaallll ddeeffiinnee aanndd ccoonnttrrooll aacccceessss bbeettwweeeenn nnaammeedd uusseerrss aanndd nnaammeedd
  oobbjjeeccttss ((ee..gg..,, ffiilleess aanndd pprrooggrraammss)) iinn tthhee AADDPP ssyysstteemm..  TThhee eennffoorrcceemmeenntt
  mmeecchhaanniissmm ((ee..gg..,, sseellff//ggrroouupp//ppuubblliicc ccoonnttrroollss,, aacccceessss ccoonnttrrooll lliissttss))
  sshhaallll aallllooww uusseerrss ttoo ssppeecciiffyy aanndd ccoonnttrrooll sshhaarriinngg ooff tthhoossee oobbjjeeccttss bbyy
  nnaammeedd iinnddiivviidduuaallss oorr ddeeffiinneedd ggrroouuppss oorr bbootthh..


  22..11..22..  AAccccoouunnttaabbiilliittyy

  22..11..22..11..  IIddeennttiiffiiccaattiioonn aanndd AAuutthheennttiiccaattiioonn

  TThhee TTCCBB sshhaallll rreeqquuiirree uusseerrss ttoo iiddeennttiiffyy tthheemmsseellvveess ttoo iitt bbeeffoorree
  bbeeggiinnnniinngg ttoo ppeerrffoorrmm aannyy ootthheerr aaccttiioonnss tthhaatt tthhee TTCCBB iiss eexxppeecctteedd ttoo
  mmeeddiiaattee..  FFuurrtthheerrmmoorree,, tthhee TTCCBB sshhaallll uussee aa pprrootteecctteedd mmeecchhaanniissmm ((ee..gg..,,
  ppaasssswwoorrddss)) ttoo aauutthheennttiiccaattee tthhee uusseerr''ss iiddeennttiittyy..  TThhee TTCCBB sshhaallll pprrootteecctt
  aauutthheennttiiccaattiioonn ddaattaa ssoo tthhaatt iitt ccaannnnoott bbee aacccceesssseedd bbyy aannyy uunnaauutthhoorriizzeedd
  uusseerr..


  22..11..33..  AAssssuurraannccee

  22..11..33..11..  OOppeerraattiioonnaall AAssssuurraannccee

  22..11..33..11..11..  SSyysstteemm AArrcchhiitteeccttuurree

  TThhee TTCCBB sshhaallll mmaaiinnttaaiinn aa ddoommaaiinn ffoorr iittss oowwnn eexxeeccuuttiioonn pprrootteeccttss iitt ffrroomm
  eexxtteerrnnaall iinntteerrffeerreennccee oorr ttaammppeerriinngg ((ee..gg..,, bbyy mmooddiiffiiccaattiioonn ooff iittss ccooddee
  oorr ddaattaa ssttrruuccuuttrreess))..  RReessoouurrcceess ccoonnttrroolllleedd bbyy tthhee TTCCBB mmaayy bbee aa ddeeffiinneedd
  ssuubbsseett ooff tthhee ssuubbjjeeccttss aanndd oobbjjeeccttss iinn tthhee AADDPP ssyysstteemm..


  22..11..33..11..22..  SSyysstteemm IInntteeggrriittyy

  HHaarrddwwaarree aanndd//oorr ssooffttwwaarree ffeeaattuurreess sshhaallll bbee pprroovviiddeedd tthhaatt ccaann bbee uusseedd
  ttoo ppeerriiooddiiccaallllyy vvaalliiddaattee tthhee ccoorrrreecctt ooppeerraattiioonn ooff tthhee oonn--ssiittee hhaarrddwwaarree
  aanndd ffiirrmmwwaarree eelleemmeennttss ooff tthhee TTCCBB..





  22..11..33..22..  LLiiffee--CCyyccllee AAssssuurraannccee

  22..11..33..22..11..  SSeeccuurriittyy TTeessttiinngg

  TThhee sseeccuurriittyy mmeecchhaanniissmmss ooff tthhee AADDPP ssyysstteemm sshhaallll bbee tteesstteedd aanndd ffoouunndd ttoo
  wwoorrkk aass ccllaaiimmeedd iinn tthhee ssyysstteemm ddooccuummeennttaattiioonn..  TTeessttiinngg sshhaallll bbee ddoonnee ttoo
  aassssuurree tthhaatt tthheerree aarree nnoo oobbvviioouuss wwaayyss ffoorr aann uunnaauutthhoorriizzeedd uusseerr ttoo
  bbyyppaassss oorr ootthheerrwwiissee ddeeffeeaatt tthhee sseeccuurriittyy pprrootteeccttiioonn mmeecchhaanniissmmss ooff tthhee
  TTCCBB..  ((SSeeee tthhee SSeeccuurriittyy TTeessttiinngg GGuuiiddeelliinneess..))



  22..11..44..  DDooccuummeennttaattiioonn

  22..11..44..11..  SSeeccuurriittyy FFeeaattuurreess UUsseerr''ss GGuuiiddee

  AA ssiinnggllee ssuummmmaarryy,, cchhaapptteerr,, oorr mmaannuuaall iinn uusseerr ddooccuummeennttaattiioonn sshhaallll
  ddeessccrriibbee tthhee pprrootteeccttiioonn mmeecchhaanniissmmss pprroovviiddeedd bbyy tthhee TTCCBB,, gguuiiddeelliinneess oonn
  tthheeiirr uussee,, aanndd hhooww tthheeyy iinntteerraacctt wwiitthh oonnee aannootthheerr..


  22..11..44..22..  TTrruusstteedd FFaacciilliittyy MMaannuuaall

  AA mmaannuuaall aaddddrreesssseedd ttoo tthhee AADDPP SSyysstteemm AAddmmiinniissttrraattoorr sshhaallll pprreesseenntt
  ccaauuttiioonnss aabboouutt ffuunnccttiioonnss aanndd pprriivviilleeggeess tthhaatt sshhoouulldd bbee ccoonnttrroolllleedd wwhheenn
  rruunnnniinngg aa sseeccuurree ffaacciilliittyy..


  22..11..44..33..  TTeesstt DDooccuummeennttaattiioonn

  TThhee ssyysstteemm ddeevveellooppeerr sshhaallll pprroovviiddee ttoo tthhee eevvaalluuaattoorrss aa ddooccuummeenntt tthhaatt
  ddeessccrriibbeess tthhee tteesstt ppllaann,, tteesstt pprroocceedduurreess tthhaatt sshhooww hhooww tthhee tthhee
  sseeccuurriittyy mmeecchhaanniissmmss wweerree tteesstteedd,, aanndd rreessuullttss ooff tthhee sseeccuurriittyy
  mmeecchhaanniissmmss'' ffuunnccttiioonnaall tteessttiinngg..


  22..11..44..44..  DDeessiiggnn DDooccuummeennttaattiioonn

  DDooccuummeennttaattiioonn sshhaallll bbee aavvaaiillaabbllee tthhaatt pprroovviiddeess aa ddeessccrriippttiioonn ooff tthhee
  mmaannuuffaaccttuurreerr''ss pphhiilloossoopphhyy ooff pprrootteeccttiioonn aanndd aann eexxppllaannaattiioonn ooff hhooww tthhiiss
  pphhiilloossoopphhyy iiss ttrraannssllaatteedd iinnttoo tthhee TTCCBB..  IIff tthhee TTCCBB iiss ccoommppoosseedd ooff
  ddiissttiinncctt mmoodduulleess,, tthhee iinntteerrffaacceess bbeettwweeeenn tthheessee mmoodduulleess sshhaallll bbee
  ddeessccrriibbeedd..


  22..22..  CCLLAASSSS ((CC22))::  CCOONNTTRROOLLLLEEDD AACCCCEESSSS PPRROOTTEECCTTIIOONN

  _S_y_s_t_e_m_s _i_n _t_h_i_s _c_l_a_s_s _e_n_f_o_r_c_e _a _m_o_r_e _f_i_n_e_l_y _g_r_a_i_n_e_d _d_i_s_c_r_e_t_i_o_n_a_r_y
  _a_c_c_e_s_s _c_o_n_t_r_o_l _t_h_a_n _(_C_1_) _s_y_s_t_e_m_s_, _m_a_k_i_n_g _u_s_e_r_s _i_n_d_i_v_i_d_u_a_l_l_y
  _a_c_c_o_u_n_t_a_b_l_e _f_o_r _t_h_e_i_r _a_c_t_i_o_n_s _t_h_r_o_u_g_h _l_o_g_i_n _p_r_o_c_e_d_u_r_e_s_, _a_u_d_i_t_i_n_g _o_f
  _s_e_c_u_r_i_t_y_-_r_e_l_e_v_a_n_t _e_v_e_n_t_s_, _a_n_d _r_e_s_o_u_r_c_e _i_s_o_l_a_t_i_o_n_.  _T_h_e _f_o_l_l_o_w_i_n_g _a_r_e
  _m_i_n_i_m_a_l _r_e_q_u_i_r_e_m_e_n_t_s _f_o_r _s_y_s_t_e_m_s _a_s_s_i_g_n_e_d _a _c_l_a_s_s _(_C_2_) _r_a_t_i_n_g_:


  22..22..11..  SSeeccuurriittyy PPoolliiccyy

  22..22..11..11..  DDiissccrreettiioonnaarryy AAcccceessss CCoonnttrrooll

  The TCB shall define and control access between named users and named
  objects (e.g., files and programs) in the ADP system.  The enforcement
  mechanism (e.g., self/group/public controls, access control lists)
  shall allow users to specify and control sharing of those objects by
  named individuals, or defined groups ooff iinnddiivviidduuaallss, or by both, aanndd
  sshhaallll pprroovviiddee ccoonnttrroollss ttoo lliimmiitt pprrooppaaggaattiioonn ooff aacccceessss rriigghhttss..  TThhee
  ddiissccrreettiioonnaarryy aacccceessss ccoonnttrrooll mmeecchhaanniissmm sshhaallll,, eeiitthheerr bbyy eexxpplliicciitt uusseerr
  aaccttiioonn oorr bbyy ddeeffaauulltt,, pprroovviiddee tthhaatt oobbjjeeccttss aarree pprrootteecctteedd ffrroomm
  uunnaauutthhoorriizzeedd aacccceessss..  TThheessee aacccceessss ccoonnttrroollss sshhaallll bbee ccaappaabbllee ooff
  iinncclluuddiinngg oorr eexxcclluuddiinngg aacccceessss ttoo tthhee ggrraannuullaarriittyy ooff aa ssiinnggllee uusseerr..
  AAcccceessss ppeerrmmiissssiioonn ttoo aann oobbjjeecctt bbyy uusseerrss nnoott aallrreeaaddyy ppoosssseessssiinngg aacccceessss
  ppeerrmmiissssiioonn sshhaallll oonnllyy bbee aassssiiggnneedd bbyy aauutthhoorriizzeedd uusseerrss..


  22..22..11..22..  OObbjjeecctt RReeuussee

  AAllll aauutthhoorriizzaattiioonnss ttoo tthhee iinnffoorrmmaattiioonn ccoonnttaaiinneedd wwiitthhiinn aa ssttoorraaggee
  oobbjjeecctt sshhaallll bbee rreevvookkeedd pprriioorr ttoo iinniittiiaall aassssiiggnnmmeenntt,, aallllooccaattiioonn oorr
  rreeaallllooccaattiioonn ttoo aa ssuubbjjeecctt ffrroomm tthhee TTCCBB''ss ppooooll ooff uunnuusseedd ssttoorraaggee
  oobbjjeeccttss..  NNoo iinnffoorrmmaattiioonn,, iinncclluuddiinngg eennccrryypptteedd rreepprreesseennttaattiioonnss ooff
  iinnffoorrmmaattiioonn,, pprroodduucceedd bbyy aa pprriioorr ssuubbjjeecctt''ss aaccttiioonnss iiss ttoo bbee aavvaaiillaabbllee
  ttoo aannyy ssuubbjjeecctt tthhaatt oobbttaaiinnss aacccceessss ttoo aann oobbjjeecctt tthhaatt hhaass bbeeeenn rreelleeaasseedd
  bbaacckk ttoo tthhee ssyysstteemm..


  22..22..22..  AAccccoouunnttaabbiilliittyy

  22..22..22..11..  IIddeennttiiffiiccaattiioonn aanndd AAuutthheennttiiccaattiioonn

  The TCB shall require users to identify themselves to it before
  beginning to perform any other actions that the TCB is expected to
  mediate.  Furthermore, the TCB shall use a protected mechanism (e.g.,
  passwords) to authenticate the user's identity.  The TCB shall protect
  authentication data so that it cannot be accessed by any unauthorized
  user.  TThhee TTCCBB sshhaallll bbee aabbllee ttoo eennffoorrccee iinnddiivviidduuaall aaccccoouunnttaabbiilliittyy bbyy
  pprroovviiddiinngg tthhee ccaappaabbiilliittyy ttoo uunniiqquueellyy iiddeennttiiffyy eeaacchh iinnddiivviidduuaall AADDPP
  ssyysstteemm uusseerr..  TThhee TTCCBB sshhaallll aallssoo pprroovviiddee tthhee ccaappaabbiilliittyy ooff aassssoocciiaattiinngg
  tthhiiss iiddeennttiittyy wwiitthh aallll aauuddiittaabbllee aaccttiioonnss ttaakkeenn bbyy tthhaatt iinnddiivviidduuaall..


  22..22..22..22..  AAuuddiitt

  TThhee TTCCBB sshhaallll bbee aabbllee ttoo ccrreeaattee,, mmaaiinnttaaiinn,, aanndd pprrootteecctt ffrroomm
  mmooddiiffiiccaattiioonn oorr uunnaauutthhoorriizzeedd aacccceessss oorr ddeessttrruuccttiioonn aann aauuddiitt ttrraaiill ooff
  aacccceesssseess ttoo tthhee oobbjjeeccttss iitt pprrootteeccttss..  TThhee aauuddiitt ddaattaa sshhaallll bbee
  pprrootteecctteedd bbyy tthhee TTCCBB ssoo tthhaatt rreeaadd aacccceessss ttoo iitt iiss lliimmiitteedd ttoo tthhoossee wwhhoo
  aarree aauutthhoorriizzeedd ffoorr aauuddiitt ddaattaa..  TThhee TTCCBB sshhaallll bbee aabbllee ttoo rreeccoorrdd tthhee
  ffoolllloowwiinngg ttyyppeess ooff eevveennttss::  uussee ooff iiddeennttiiffiiccaattiioonn aanndd aauutthheennttiiccaattiioonn
  mmeecchhaanniissmmss,, iinnttrroodduuccttiioonn oorr oobbjjeeccttss iinnttoo aa uusseerr''ss aaddddrreessss ssppaaccee ((ee..gg..,,
  ffiillee ooppeenn,, pprrooggrraamm iinniittiiaattiioonn)),, ddeelleettiioonn ooff oobbjjeeccttss,, aanndd aaccttiioonnss ttaakkeenn
  bbyy ccoommppuutteerr ooppeerraattoorrss aanndd ssyysstteemm aaddmmiinniissttrraattoorrss aanndd//oorr ssyysstteemm sseeccuurriittyy
  ooffffiicceerrss,, aanndd ootthheerr sseeccuurriittyy rreelleevvaanntt eevveennttss..  FFoorr eeaacchh rreeccoorrddeedd
  eevveenntt,, tthhee aauuddiitt rreeccoorrdd sshhaallll iiddeennttiiffyy::  ddaattee aanndd ttiimmee ooff tthhee eevveenntt,,
  uusseerr,, ttyyppee ooff eevveenntt,, aanndd ssuucccceessss oorr ffaaiilluurree ooff tthhee eevveenntt..  FFoorr
  iiddeennttiiffiiccaattiioonn//aauutthheennttiiccaattiioonn eevveennttss tthhee oorriiggiinn ooff rreeqquueesstt ((ee..gg..,,
  tteerrmmiinnaall IIDD)) sshhaallll bbee iinncclluuddeedd iinn tthhee aauuddiitt rreeccoorrdd..  FFoorr eevveennttss tthhaatt
  iinnttrroodduuccee aann oobbjjeecctt iinnttoo aa uusseerr''ss aaddddrreessss ssppaaccee aanndd  ffoorr oobbjjeecctt
  ddeelleettiioonn eevveennttss tthhee aauuddiitt rreeccoorrdd sshhaallll iinncclluuddee tthhee nnaammee ooff tthhee oobbjjeecctt..
  TThhee AADDPP ssyysstteemm aaddmmiinniissttrraattoorr sshhaallll bbee aabbllee ttoo sseelleeccttiivveellyy aauuddiitt tthhee
  aaccttiioonnss ooff aannyy oonnee oorr mmoorree uusseerrss bbaasseedd oonn iinnddiivviidduuaall iiddeennttiittyy..


  22..22..33..  AAssssuurraannccee

  22..22..33..11..  OOppeerraattiioonnaall AAssssuurraannccee

  22..22..33..11..11..  SSyysstteemm AArrcchhiitteeccttuurree

  The TCB shall maintain a domain for its own execution that protects it
  from external interference or tampering (e.g., by modification of its
  code or data structures).  Resources controlled by the TCB may be a
  defined subset of the subjects and objects in the ADP system. TThhee TTCCBB
  sshhaallll iissoollaattee tthhee rreessoouurrcceess ttoo bbee pprrootteecctteedd ssoo tthhaatt tthheeyy aarree ssuubbjjeecctt
  ttoo tthhee aacccceessss ccoonnttrrooll aanndd aauuddiittiinngg rreeqquuiirreemmeennttss..
  22..22..33..11..22..  SSyysstteemm IInntteeggrriittyy

  Hardware and/or software features shall be provided that can be used
  to periodically validate the correct operation of the on-site hardware
  and firmware elements of the TCB.


  22..22..33..22..  LLiiffee--CCyyccllee AAssssuurraannccee

  22..22..33..22..11..  SSeeccuurriittyy TTeessttiinngg

  The security mechanisms of the ADP system shall be tested and found to
  work as claimed in the system documentation.  Testing shall be done to
  assure that there are no obvious ways for an unauthorized user to
  bypass or otherwise defeat the security protection mechanisms of the
  TCB.  TTeessttiinngg sshhaallll aallssoo iinncclluuddee aa sseeaarrcchh ffoorr oobbvviioouuss ffllaawwss tthhaatt wwoouulldd
  aallllooww vviioollaattiioonn ooff rreessoouurrccee iissoollaattiioonn,, oorr tthhaatt wwoouulldd ppeerrmmiitt
  uunnaauutthhoorriizzeedd aacccceessss ttoo tthhee aauuddiitt oorr aauutthheennttiiccaattiioonn ddaattaa..  (See the
  Security Testing guidelines.)


  22..22..44..  DDooccuummeennttaattiioonn

  22..22..44..11..  SSeeccuurriittyy FFeeaattuurreess UUsseerr''ss GGuuiiddee

  A single summary, chapter, or manual in user documentation shall
  describe the protection mechanisms provided by the TCB, guidelines on
  their use, and how they interact with one another.


  22..22..44..22..  TTrruusstteedd FFaacciilliittyy MMaannuuaall

  A manual addressed to the ADP system administrator shall present
  cautions about functions and privileges that should be controlled when
  running a secure facility.  TThhee pprroocceedduurreess ffoorr eexxaammiinniinngg aanndd
  mmaaiinnttaaiinniinngg tthhee aauuddiitt ffiilleess aass wweellll aass tthhee ddeettaaiilleedd aauuddiitt rreeccoorrdd
  ssttrruuccttuurree ffoorr eeaacchh ttyyppee ooff aauuddiitt eevveenntt sshhaallll bbee ggiivveenn..



  22..22..44..33..  TTeesstt DDooccuummeennttaattiioonn

  The system developer shall provide to the evaluators a document that
  describes the test plan, test procedures that show how the security
  mechanisms were tested, and results of the security mechanisms'
  functional testing.


  22..22..44..44..  DDeessiiggnn DDooccuummeennttaattiioonn

  Documentation shall be available that provides a description of the
  manufacturer's philosophy of protection and an explanation of how this
  philosophy is translated into the TCB.  If the TCB is composed of
  distinct modules, the interfaces between these modules shall be
  described.











  33..  DDIIVVIISSIIOONN BB::  MMAANNDDAATTOORRYY PPRROOTTEECCTTIIOONN

  The notion of a TCB that preserves the integrity of sensitivity labels
  and uses them to enforce a set of mandatory access control rules is a
  major requirement in this division.  Systems in this division must
  carry the sensitivity labels with major data structures in the system.
  The system developer also provides the security policy model on which
  the TCB is based and furnishes a specification of the TCB.  Evidence
  must be provided to demonstrate that the reference monitor concept has
  been implemented.


  33..11..  CCLLAASSSS ((BB11))::  LLAABBEELLEEDD SSEECCUURRIITTYY PPRROOTTEECCTTIIOONN

  _C_l_a_s_s _(_B_1_) _s_y_s_t_e_m_s _r_e_q_u_i_r_e _a_l_l _t_h_e _f_e_a_t_u_r_e_s _r_e_q_u_i_r_e_d _f_o_r _c_l_a_s_s _(_C_2_)_.
  _I_n _a_d_d_i_t_i_o_n_, _a_n _i_n_f_o_r_m_a_l _s_t_a_t_e_m_e_n_t _o_f _t_h_e _s_e_c_u_r_i_t_y _p_o_l_i_c_y _m_o_d_e_l_, _d_a_t_a
  _l_a_b_e_l_i_n_g_, _a_n_d _m_a_n_d_a_t_o_r_y _a_c_c_e_s_s _c_o_n_t_r_o_l _o_v_e_r _n_a_m_e_d _s_u_b_j_e_c_t_s _a_n_d _o_b_j_e_c_t_s
  _m_u_s_t _b_e _p_r_e_s_e_n_t_.  _T_h_e _c_a_p_a_b_i_l_i_t_y _m_u_s_t _e_x_i_s_t _f_o_r _a_c_c_u_r_a_t_e_l_y _l_a_b_e_l_i_n_g
  _e_x_p_o_r_t_e_d _i_n_f_o_r_m_a_t_i_o_n_.  _A_n_y _f_l_a_w_s _i_d_e_n_t_i_f_i_e_d _b_y _t_e_s_t_i_n_g _m_u_s_t _b_e
  _r_e_m_o_v_e_d_.  _T_h_e _f_o_l_l_o_w_i_n_g _a_r_e _m_i_n_i_m_a_l _r_e_q_u_i_r_e_m_e_n_t_s _f_o_r _s_y_s_t_e_m_s _a_s_s_i_g_n_e_d
  _a _c_l_a_s_s _(_B_1_) _r_a_t_i_n_g_:


  33..11..11..  SSeeccuurriittyy PPoolliiccyy

  33..11..11..11..  DDiissccrreettiioonnaarryy AAcccceessss CCoonnttrrooll

  The TCB shall define and control access between named users and named
  objects (e.g., files and programs) in the ADP system.  The enforcement
  mechanism (e.g., self/group/public controls, access control lists)
  shall allow users to specify and control sharing of those objects by
  named individuals, or defined groups of individuals, or by both, and
  shall provide controls to limit propagation of access rights.  The
  discretionary access control mechanism shall, either by explicit user
  action or by default, provide that objects are protected from
  unauthorized access.  These access controls shall be capable of
  including or excluding access to the granularity of a single user.
  Access permission to an object by users not already possessing access
  permission shall only be assigned by authorized users.


  33..11..11..22..  OObbjjeecctt RReeuussee

  All authorizations to the information contained within a storage
  object shall be revoked prior to initial assignment, allocation or
  reallocation to a subject from the TCB's pool of unused storage
  objects.  No information, including encrypted representations of
  information, produced by a prior subject's actions is to be available
  to any subject that obtains access to an object that has been released
  back to the system.


  33..11..11..33..  LLaabbeellss

  SSeennssiittiivviittyy llaabbeellss aassssoocciiaatteedd wwiitthh eeaacchh ssuubbjjeecctt aanndd ssttoorraaggee oobbjjeecctt
  uunnddeerr iittss ccoonnttrrooll ((ee..gg..,, pprroocceessss,, ffiillee,, sseeggmmeenntt,, ddeevviiccee)) sshhaallll bbee
  mmaaiinnttaaiinneedd bbyy tthhee TTCCBB..  TThheessee llaabbeellss sshhaallll bbee uusseedd aass tthhee bbaassiiss ffoorr
  mmaannddaattoorryy aacccceessss ccoonnttrrooll ddeecciissiioonnss..  IInn oorrddeerr ttoo iimmppoorrtt nnoonn--llaabbeelleedd
  ddaattaa,, tthhee TTCCBB sshhaallll rreeqquueesstt aanndd rreecceeiivvee ffrroomm aann aauutthhoorriizzeedd uusseerr tthhee
  sseeccuurriittyy lleevveell ooff tthhee ddaattaa,, aanndd aallll ssuucchh aaccttiioonnss sshhaallll bbee aauuddiittaabbllee bbyy
  tthhee TTCCBB..





  33..11..11..33..11..  LLaabbeell IInntteeggrriittyy

  SSeennssiittiivviittyy llaabbeellss sshhaallll aaccccuurraatteellyy rreepprreesseenntt sseeccuurriittyy lleevveellss ooff tthhee
  ssppeecciiffiicc ssuubbjjeeccttss oorr oobbjjeeccttss wwiitthh wwhhiicchh tthheeyy aarree aassssoocciiaatteedd..  WWhheenn
  eexxppoorrtteedd bbyy tthhee TTCCBB,, sseennssiittiivviittyy llaabbeellss sshhaallll aaccccuurraatteellyy aanndd
  uunnaammbbiigguuoouussllyy rreepprreesseenntt tthhee iinntteerrnnaall llaabbeellss aanndd sshhaallll bbee aassssoocciiaatteedd
  wwiitthh tthhee iinnffoorrmmaattiioonn bbeeiinngg eexxppoorrtteedd..


  33..11..11..33..22..  EExxppoorrttaattiioonn ooff LLaabbeelleedd IInnffoorrmmaattiioonn

  TThhee TTCCBB sshhaallll ddeessiiggnnaattee eeaacchh ccoommmmuunniiccaattiioonn cchhaannnneell aanndd II//OO ddeevviiccee aass
  eeiitthheerr ssiinnggllee--lleevveell oorr mmiillttiilleevveell..  AAnnyy cchhaannggee iinn tthhiiss ddeessiiggnnaattiioonn
  sshhaallll bbee ddoonnee mmaannuuaallllyy aanndd sshhaallll bbee aauuddiittaabbllee bbyy tthhee TTCCBB..  TThhee TTCCBB
  sshhaallll mmaaiinnttaaiinn aanndd bbee aabbllee ttoo aauuddiitt aannyy cchhaannggee iinn tthhee sseeccuurriittyy lleevveell
  oorr lleevveellss aassssoocciiaatteedd wwiitthh aa ccoommmmuunniiccaattiioonn cchhaannnneell oorr II//OO ddeevviiccee..


  33..11..11..33..33..  EExxppoorrttaattiioonn ttoo MMuullttiilleevveell DDeevviicceess

  WWhheenn tthhee TTCCBB eexxppoorrttss aann oobbjjeecctt ttoo aa mmuullttiilleevveell II//OO ddeevviiccee,, tthhee
  sseennssiittiivviittyy llaabbeell aassssoocciiaatteedd wwiitthh tthhaatt oobbjjeecctt sshhaallll aallssoo bbee eexxppoorrtteedd
  aanndd sshhaallll rreessiiddee oonn tthhee ssaammee pphhyyssiiccaall mmeeddiiuumm aass tthhee eexxppoorrtteedd
  iinnffoorrmmaattiioonn aanndd sshhaallll bbee iinn tthhee ssaammee ffoorrmm ((ii..ee..,, mmaacchhiinnee--rreeaaddaabbllee oorr
  hhuummaann--rreeaaddaabbllee ffoorrmm))..  WWhheenn tthhee TTCCBB eexxppoorrttss oorr iimmppoorrttss aann oobbjjeecctt oovveerr
  aa mmuullttiilleevveell ccoommmmuunniiccaattiioonn cchhaannnneell,, tthhee pprroottooccooll uusseedd oonn tthhaatt cchhaannnneell
  sshhaallll pprroovviiddee ffoorr tthhee uunnaammbbiigguuoouuss ppaaiirriinngg bbeettwweeeenn tthhee sseennssiittiivviittyy
  llaabbeellss aanndd tthhee aassssoocciiaatteedd iinnffoorrmmaattiioonn tthhaatt iiss sseenntt oorr rreecceeiivveedd..


  33..11..11..33..33..11..  EExxppoorrttaattiioonn ttoo SSiinnggllee--LLeevveell DDeevviicceess

  SSiinnggllee--lleevveell II//OO ddeevviicceess aanndd ssiinnggllee--lleevveell ccoommmmuunniiccaattiioonn cchhaannnneellss aarree
  nnoott rreeqquuiirreedd ttoo mmaaiinnttaaiinn tthhee sseennssiittiivviittyy llaabbeellss ooff tthhee iinnffoorrmmaattiioonn
  tthheeyy pprroocceessss..  HHoowweevveerr,, tthhee TTCCBB sshhaallll iinncclluuddee aa mmeecchhaanniissmm bbyy wwhhiicchh tthhee
  TTCCbb aanndd aann aauutthhoorriizzeedd uusseerr rreelliiaabbllyy ccoommmmuunniiccaattee ttoo ddeessiiggnnaattee tthhee
  ssiinnggllee sseeccuurriittyy lleevveell ooff iinnffoorrmmaattiioonn iimmppoorrtteedd oorr eexxppoorrtteedd vviiaa ssiinnggllee--
  lleevveell ccoommmmuunniiccaattiioonn cchhaannnneellss oorr II//OO ddeevviicceess..


  33..11..11..33..33..22..  LLaabbeelliinngg HHuummaann--RReeaaddaabbllee OOuuttppuutt

  TThhee AADDPP ssyysstteemm aaddmmiinniissttrraattoorr sshhaallll bbee aabbllee ttoo ssppeecciiffyy tthhee pprriinnttaabbllee
  llaabbeell nnaammeess aassssoocciiaatteedd wwiitthh eexxppoorrtteedd sseennssiittiivviittyy llaabbeellss..  TThhee TTCCBB
  sshhaallll mmaarrkk tthhee bbeeggiinnnniinngg aanndd eenndd ooff aallll hhuummaann--rreeaaddaabbllee,, ppaaggeedd,,
  hhaarrddccooppyy oouuttppuutt ((ee..gg..,, lliinnee pprriinntteerr oouuttppuutt)) wwiitthh hhuummaann--rreeaaddaabbllee
  sseennssiittiivviittyy llaabbeellss tthhaatt pprrooppeerrllyy ````((sseeee ffoooottnnoottee bbeellooww))'''' rreepprreesseenntt
  tthhee sseennssiittiivviittyy ooff tthhee oouuttppuutt..  TThhee TTCCBB sshhaallll,, bbee ddeeffaauulltt,, mmaarrkk tthhee
  ttoopp aanndd bboottttoomm ooff eeaacchh ppaaggee ooff hhuummaann--rreeaaddaabbllee,, ppaaggeedd,, hhaarrddccooppyy oouuttppuutt
  ((ee..gg..,, lliinnee pprriinntteerr oouuttppuutt)) wwiitthh hhuummaann--rreeaaddaabbllee sseennssiittiivviittyy llaabbeellss
  tthhaatt pprrooppeerrllyy ````((sseeee ffoooottnnoottee bbeellooww))'''' rreepprreesseenntt tthhee oovveerraallll
  sseennssiittiivviittyy ooff tthhee oouuttppuutt oorr tthhaatt pprrooppeerrllyy ````((sseeee ffoooottnnoottee bbeellooww))''''
  rreepprreesseenntt tthhee sseennssiittiivviittyy ooff tthhee iinnffoorrmmaattiioonn oonn tthhee ppaaggee..  TThhee TTCCBB
  sshhaallll,, bbyy ddeeffaauulltt aanndd iinn aann aapppprroopprriiaattee mmaannnneerr,, mmaarrkk ootthheerr ffoorrmmss ooff
  hhuummaann-- rreeaaddaabbllee oouuttppuutt ((ee..gg..,, mmaappss,, ggrraapphhiiccss)) wwiitthh hhuummaann-- rreeaaddaabbllee
  sseennssiittiivviittyy llaabbeellss tthhaatt pprrooppeerrllyy ````((sseeee ffoooottnnoottee bbeellooww))'''' rreepprreesseenntt
  tthhee sseennssiittiivviittyy ooff tthhee oouuppuutt..  AAnnyy oovveerrrriiddee ooff tthheessee mmaarrkkiinngg ddeeffaauullttss
  sshhaallll bbee aauuddiittaabbllee bbyy tthhee TTCCBB..


  33..11..11..33..33..33..  FFoooottnnoottee ffoorr ````pprrooppeerrllyy''''

  The hierarchical classification component in human-readable
  sensitivity labels shall be equal to the greatest hierarchical
  classification or any of the information in the output that the labels
  refer to; the non-hierarchical category component shall include all of
  the non-hierarchical categories of the information in the output the
  labels refer to, but no other non-hierarchical categories.


  33..11..11..44..  MMaannddaattoorryy AAcccceessss CCoonnttrrooll

  TThhee TTCCBB sshhaallll eennffoorrccee aa mmaannddaattoorryy aacccceessss ccoonnttrrooll ppoolliiccyy oovveerr aallll
  ssuubbjjeeccttss aanndd ssttoorraaggee oobbjjeeccttss uunnddeerr iittss ccoonnttrrooll ((ee..gg..,, pprroocceesssseess,,
  ffiilleess,, sseeggmmeennttss,, ddeevviicceess))..  TThheessee ssuubbjjeeccttss aanndd oobbjjeeccttss sshhaallll bbee
  aassssiiggnneedd sseennssiittiivviittyy llaabbeellss tthhaatt aarree aa ccoommbbiinnaattiioonn ooff hhiieerraarrcchhiiccaall
  ccllaassssiiffiiccaattiioonn lleevveellss aanndd nnoonn--hhiieerraarrcchhiiccaall ccaatteeggoorriieess,, aanndd tthhee llaabbeellss
  sshhaallll bbee uusseedd aass tthhee bbaassiiss ffoorr mmaannddaattoorryy aacccceessss ccoonnttrrooll ddeecciissiioonnss..
  TThhee TTCCBB sshhaallll bbee aabbllee ttoo ssuuppppoorrtt ttwwoo oorr mmoorree ssuucchh sseeccuurriittyy lleevveellss..
  ((SSeeee tthhee MMaannddaattoorryy AAcccceessss CCoonnttrrooll GGuuiiddeelliinneess..))  TThhee ffoolllloowwiinngg
  rreeqquuiirreemmeennttss sshhaallll hhoolldd ffoorr aallll aacccceesssseess bbeettwweeeenn ssuubbjjeeccttss aanndd oobbjjeeccttss
  ccoonnttrroolllleedd bbyy tthhee TTCCBB::  aa ssuubbjjeecctt ccaann rreeaadd aann oobbjjeecctt oonnllyy iiff tthhee
  hhiieerraarrcchhiiccaall ccllaassssiiffiiccaattiioonn iinn tthhee ssuubbjjeecctt''ss sseeccuurriittyy lleevveell iiss ggrreeaatteerr
  tthhaann oorr eeqquuaall ttoo tthhee hhiieerraarrcchhiiccaall ccllaassssiiffiiccaattiioonn iinn tthhee oobbjjeecctt''ss
  sseeccuurriittyy lleevveell aanndd tthhee nnoonn-- hhiieerraarrcchhiiccaall ccaatteeggoorriieess iinn tthhee ssuubbjjeecctt''ss
  sseeccuurriittyy lleevveell iinncclluuddee aallll tthhee nnoonn--hhiieerraarrcchhiiccaall ccaatteeggoorriieess iinn tthhee
  oobbjjeecctt''ss sseeccuurriittyy lleevveell..  AA ssuubbjjeecctt ccaann wwrriittee aann oobbjjeecctt oonnllyy iiff tthhee
  hhiieerraarrcchhiiccaall ccllaassssiiffiiccaattiioonn iinn tthhee ssuubbjjeecctt''ss sseeccuurriittyy lleevveell iiss lleessss
  tthhaann oorr eeqquuaall ttoo tthhee hhiieerraarrcchhiiccaall ccllaassssiiffiiccaattiioonn iinn tthhee oobbjjeecctt''ss
  sseeccuurriittyy lleevveell aanndd aallll tthhee nnoonn--hhiieerraarrcchhiiccaall ccaatteeggoorriieess iinn tthhee
  ssuubbjjeecctt''ss sseeccuurriittyy lleevveell aarree iinncclluuddeedd iinn tthhee nnoonn--hhiieerraarrcchhiiccaall
  ccaatteeggoorriieess iinn tthhee oobbjjeecctt''ss sseeccuurriittyy lleevveell..  IIddeennttiiffiiccaattiioonn aanndd
  aauutthheennttiiccaattiioonn ddaattaa sshhaallll bbee uusseedd bbyy tthhee TTCCBB ttoo aauutthheennttii-- ccaattee tthhee
  uusseerr''ss iiddeennttiittyy aanndd ttoo eennssuurree tthhaatt tthhee sseeccuurriittyy lleevveell aanndd
  aauutthhoorriizzaattiioonn ooff ssuubbjjeeccttss eexxtteerrnnaall ttoo tthhee TTCCBB tthhaatt mmaayy bbee ccrreeaatteedd ttoo
  aacctt oonn bbeehhaallff ooff tthhee iinnddiivviidduuaall uusseerr aarree ddoommiinnaatteedd bbyy tthhee cclleeaarraannccee
  aanndd aauutthhoorriizzaattiioonn ooff tthhaatt uusseerr..


  33..11..22..  AAccccoouunnttaabbiilliittyy

  33..11..22..11..  IIddeennttiiffiiccaattiioonn aanndd AAuutthheennttiiccaattiioonn

  The TCB shall require users to identify themselves to it before
  beginning to perform any other actions that the TCB is expected to
  mediate.  Furthermore, the TCB shall mmaaiinnttaaiinn aauutthheennttiiccaattiioonn ddaattaa tthhaatt
  iinncclluuddeess iinnffoorrmmaattiioonn ffoorr vveerriiffyyiinngg tthhee iiddeennttiittyy ooff iinnddiivviidduuaall uusseerrss
  ((ee..gg..,, ppaasssswwoorrddss)) aass wweellll aass iinnffoorrmmaattiioonn ffoorr ddeetteerrmmiinniinngg tthhee cclleeaarraannccee
  aanndd aauutthhoorriizzaattiioonnss oorr iinnddiivviidduuaall uusseerrss..  TThhiiss ddaattaa sshhaallll bbee uusseedd bbyy
  tthhee TTCCBB ttoo aauutthheennttiiccaattee the user's identity aanndd ttoo eennssuurree tthhaatt tthhee
  sseeccuurriittyy lleevveell aanndd aauutthhoorriizzaattiioonnss ooff ssuubbjjeeccttss eexxtteerrnnaall ttoo tthhee TTCCBB tthhaatt
  mmaayy bbee ccrreeaatteedd ttoo aacctt oonn bbeehhaallff ooff tthhee iinnddiivviidduuaall uusseerr aarree ddoommiinnaatteedd
  bbyy tthhee cclleeaarraannccee aanndd aauutthhoorriizzaattiioonn ooff tthhaatt uusseerr..  The TCB shall
  protect authentication data so that it cannot be accessed by any
  unauthorized user.  The TCB shall be able to enforce individual
  accountability by providing the capability to uniquely identify each
  individual ADP system user.  The TCB shall also provide the capability
  of associating this identity with all auditable actions taken by that
  individual.


  33..11..22..22..  AAuuddiitt

  The TCB shall be able to create, maintain, and protect from
  modification or unauthorized access or destruction an audit trail of
  accesses to the objects it protects.  The audit data shall be
  protected by the TCB so that read access to it is limited to those who
  are authorized for audit data.  The TCB shall be able to record the
  following types of events: use of identification and authentication
  mechanisms, introduction of objects into a user's address space (e.g.,
  file open, program initiation), deletion of objects, and actions taken
  by computer operators and system administrators and/or system security
  officers and other security relevant events.  TThhee TTCCBB sshhaallll aallssoo bbee
  aabbllee ttoo aauuddiitt aannyy oovveerrrriiddee ooff hhuummaann--rreeaaddaabbllee oouuttppuutt mmaarrkkiinnggss..  For
  each recorded event, the audit record shall identify: date and time of
  the event, user, type of event, and success or failure of the event.
  For identification/authentication events the origin of request (e.g.,
  terminal ID) shall be included in the audit record.  For events that
  introduce an object into a user's address space and for object
  deletion events the audit record shall include the name of the object
  aanndd tthhee oobbjjeecctt''ss sseeccuurriittyy lleevveell.  The ADP system administrator shall
  be able to selectively audit the actions of any one or more users
  based on individual identity aanndd//oorr oobbjjeecctt sseeccuurriittyy lleevveell.


  33..11..33..  AAssssuurraannccee

  33..11..33..11..  OOppeerraattiioonnaall AAssssuurraannccee

  33..11..33..11..11..  SSyysstteemm AArrcchhiitteeccttuurree

  The TCB shall maintain a domain for its own execution that protects it
  from external interference or tampering (e.g., by modification of its
  code or data structures).  Resources controlled by the TCB may be a
  defined subset of the subjects and objects in the ADP system.  TThhee TTCCBB
  sshhaallll mmaaiinnttaaiinn pprroocceessss iissoollaattiioonn tthhrroouugghh tthhee pprroovviissiioonn ooff ddiissttiinncctt
  aaddddrreessss ssppaacceess uunnddeerr iittss ccoonnttrrooll..  The TCB shall isolate the resources
  to be protected so that they are subject to the access control and
  auditing requirements.


  33..11..33..11..22..  SSyysstteemm IInntteeggrriittyy

  Hardware and/or software features shall be provided that can be used
  to periodically validate the correct operation of the on-site hardware
  and firmware elements of the TCB.


  33..11..33..22..  LLiiffee--CCyyccllee AAssssuurraannccee

  33..11..33..22..11..  SSeeccuurriittyy TTeessttiinngg

  The security mechanisms of the ADP system shall be tested and found to
  work as claimed in the system documentation.  AA tteeaamm ooff iinnddiivviidduuaallss
  wwhhoo tthhoorroouugghhllyy uunnddeerrssttaanndd tthhee ssppeecciiffiicc iimmpplleemmeennttaattiioonn ooff tthhee TTCCBB sshhaallll
  ssuubbjjeecctt iittss ddeessiiggnn ddooccuummeennttaattiioonn,, ssoouurrccee ccooddee,, aanndd oobbjjeecctt ccooddee ttoo
  tthhoorroouugghh aannaallyyssiiss aanndd tteessttiinngg..  TThheeiirr oobbjjeeccttiivveess sshhaallll bbee:: ttoo uunnccoovveerr
  aallll ddeessiiggnn aanndd iimmpplleemmeennttaattiioonn ffllaawwss tthhaatt wwoouulldd ppeerrmmiitt aa ssuubbjjeecctt
  eexxtteerrnnaall ttoo tthhee TTCCBB ttoo rreeaadd,, cchhaannggee,, oorr ddeelleettee ddaattaa nnoorrmmaallllyy ddeenniieedd
  uunnddeerr tthhee mmaannddaattoorryy oorr ddiissccrreettiioonnaarryy sseeccuurriittyy ppoolliiccyy eennffoorrcceedd bbyy tthhee
  TTCCBB;; aass wweellll aass ttoo aassssuurree tthhaatt nnoo ssuubbjjeecctt ((wwiitthhoouutt aauutthhoorriizzaattiioonn ttoo ddoo
  ssoo)) iiss aabbllee ttoo ccaauussee tthhee TTCCBB ttoo eenntteerr aa ssttaattee ssuucchh tthhaatt iitt iiss uunnaabbllee
  ttoo rreessppoonndd ttoo ccoommmmuunniiccaattiioonnss iinniittiiaatteedd bbyy ootthheerr uusseerrss..  AAllll ddiissccoovveerreedd
  ffllaawwss sshhaallll bbee rreemmoovveedd oorr nneeuuttrraalliizzeedd aanndd tthhee TTCCBB rreetteesstteedd ttoo
  ddeemmoonnssttrraattee tthhaatt tthheeyy hhaavvee bbeeeenn eelliimmiinnaatteedd aanndd tthhaatt nneeww ffllaawwss hhaavvee nnoott
  bbeeeenn iinnttrroodduucceedd..  ((SSeeee tthhee SSeeccuurriittyy TTeessttiinngg GGuuiiddeelliinneess..))


  33..11..33..22..22..  DDeessiiggnn SSppeecciiffiiccaattiioonn aanndd VVeerriiffiiccaattiioonn

  AAnn iinnffoorrmmaall oorr ffoorrmmaall mmooddeell ooff tthhee sseeccuurriittyy ppoolliiccyy ssuuppppoorrtteedd bbyy tthhee
  TTCCBB sshhaallll bbee mmaaiinnttaaiinneedd oovveerr tthhee lliiffee ccyyccllee ooff tthhee AADDPP ssyysstteemm aanndd
  ddeemmoonnssttrraatteedd ttoo bbee ccoonnssiisstteenntt wwiitthh iittss aaxxiioommss..





  33..11..44..  DDooccuummeennttaattiioonn

  33..11..44..11..  SSeeccuurriittyy FFeeaattuurreess UUsseerr''ss GGuuiiddee

  A single summary, chapter, or manual in user documentation shall
  describe the protection mechanisms provided by the TCB, guidelines on
  their use, and how they interact with one another.


  33..11..44..22..  TTrruusstteedd FFaacciilliittyy MMaannuuaall

  A manual addressed to the ADP system administrator shall present
  cautions about functions and privileges that should be controlled when
  running a secure facility.  The procedures for examining and
  maintaining the audit files as well as the detailed audit record
  structure for each type of audit event shall be given.  TThhee mmaannuuaall
  sshhaallll ddeessccrriibbee tthhee ooppeerraattoorr aanndd aaddmmiinniissttrraattoorr ffuunnccttiioonnss rreellaatteedd ttoo
  sseeccuurriittyy,, ttoo iinncclluuddee cchhaannggiinngg tthhee sseeccuurriittyy cchhaarraacctteerriissttiiccss ooff aa uusseerr..
  IItt sshhaallll pprroovviiddee gguuiiddeelliinneess oonn tthhee ccoonnssiisstteenntt aanndd eeffffeeccttiivvee uussee ooff tthhee
  pprrootteeccttiioonn ffeeaattuurreess ooff tthhee ssyysstteemm,, hhooww tthheeyy iinntteerraacctt,, hhooww ttoo sseeccuurreellyy
  ggeenneerraattee aa nneeww TTCCBB,, aanndd ffaacciilliittyy pprroocceedduurreess,, wwaarrnniinnggss,, aanndd pprriivviilleeggeess
  tthhaatt nneeeedd ttoo bbee ccoonnttrroolllleedd iinn oorrddeerr ttoo ooppeerraattee tthhee ffaacciilliittyy iinn aa
  sseeccuurree mmaannnneerr..


  33..11..44..33..  TTeesstt DDooccuummeennttaattiioonn

  The system developer shall provide to the evaluators a document that
  describes the test plan, test procedures that show how the security
  mechanisms were tested, and results of the security mechanisms'
  functional testing.


  33..11..44..44..  DDeessiiggnn DDooccuummeennttaattiioonn

  Documentation shall be available that provides a description of the
  manufacturer's philosophy of protection and an explanation of how this
  philosophy is translated into the TCB.  If the TCB is composed of
  distinct modules, the interfaces between these modules shall be
  described.  AAnn iinnffoorrmmaall oorr ffoorrmmaall ddeessccrriippttiioonn ooff tthhee sseeccuurriittyy ppoolliiccyy
  mmooddeell eennffoorrcceedd bbyy tthhee TTCCBB sshhaallll bbee aavvaaiillaabbllee aanndd aann eexxppllaannaattiioonn
  pprroovviiddeedd ttoo sshhooww tthhaatt iitt iiss ssuuffffiicciieenntt ttoo eennffoorrccee tthhee sseeccuurriittyy ppoolliiccyy..
  TThhee ssppeecciiffiicc TTCCBB pprrootteeccttiioonn mmeecchhaanniissmmss sshhaallll bbee iiddeennttiiffiieedd aanndd aann
  eexxppllaannaattiioonn ggiivveenn ttoo sshhooww tthhaatt tthheeyy ssaattiissffyy tthhee mmooddeell..


  33..22..  CCLLAASSSS ((BB22))::  SSTTRRUUCCTTUURREEDD PPRROOTTEECCTTIIOONN

  _I_n _c_l_a_s_s _(_B_2_) _s_y_s_t_e_m_s_, _t_h_e _T_C_B _i_s _b_a_s_e_d _o_n _a _c_l_e_a_r_l_y _d_e_f_i_n_e_d _a_n_d
  _d_o_c_u_m_e_n_t_e_d _f_o_r_m_a_l _s_e_c_u_r_i_t_y _p_o_l_i_c_y _m_o_d_e_l _t_h_a_t _r_e_q_u_i_r_e_s _t_h_e
  _d_i_s_c_r_e_t_i_o_n_a_r_y _a_n_d _m_a_n_d_a_t_o_r_y _a_c_c_e_s_s _c_o_n_t_r_o_l _e_n_f_o_r_c_e_m_e_n_t _f_o_u_n_d _i_n _c_l_a_s_s
  _(_B_1_) _s_y_s_t_e_m_s _b_e _e_x_t_e_n_d_e_d _t_o _a_l_l _s_u_b_j_e_c_t_s _a_n_d _o_b_j_e_c_t_s _i_n _t_h_e _A_D_P
  _s_y_s_t_e_m_.  _I_n _a_d_d_i_t_i_o_n_, _c_o_v_e_r_t _c_h_a_n_n_e_l_s _a_r_e _a_d_d_r_e_s_s_e_d_.  _T_h_e _T_C_B _m_u_s_t _b_e
  _c_a_r_e_f_u_l_l_y _s_t_r_u_c_t_u_r_e_d _i_n_t_o _p_r_o_t_e_c_t_i_o_n_-_c_r_i_t_i_c_a_l _a_n_d _n_o_n_- _p_r_o_t_e_c_t_i_o_n_-
  _c_r_i_t_i_c_a_l _e_l_e_m_e_n_t_s_.  _T_h_e _T_C_B _i_n_t_e_r_f_a_c_e _i_s _w_e_l_l_-_d_e_f_i_n_e_d _a_n_d _t_h_e _T_C_B
  _d_e_s_i_g_n _a_n_d _i_m_p_l_e_m_e_n_t_a_t_i_o_n _e_n_a_b_l_e _i_t _t_o _b_e _s_u_b_j_e_c_t_e_d _t_o _m_o_r_e _t_h_o_r_o_u_g_h
  _t_e_s_t_i_n_g _a_n_d _m_o_r_e _c_o_m_p_l_e_t_e _r_e_v_i_e_w_.  _A_u_t_h_e_n_t_i_c_a_t_i_o_n _m_e_c_h_a_n_i_s_m_s _a_r_e
  _s_t_r_e_n_g_t_h_e_n_e_d_, _t_r_u_s_t_e_d _f_a_c_i_l_i_t_y _m_a_n_a_g_e_m_e_n_t _i_s _p_r_o_v_i_d_e_d _i_n _t_h_e _f_o_r_m _o_f
  _s_u_p_p_o_r_t _f_o_r _s_y_s_t_e_m _a_d_m_i_n_i_s_t_r_a_t_o_r _a_n_d _o_p_e_r_a_t_o_r _f_u_n_c_t_i_o_n_s_, _a_n_d _s_t_r_i_n_g_e_n_t
  _c_o_n_f_i_g_u_r_a_t_i_o_n _m_a_n_a_g_e_m_e_n_t _c_o_n_t_r_o_l_s _a_r_e _i_m_p_o_s_e_d_.  _T_h_e _s_y_s_t_e_m _i_s
  _r_e_l_a_t_i_v_e_l_y _r_e_s_i_s_t_a_n_t _t_o _p_e_n_e_t_r_a_t_i_o_n_.  _T_h_e _f_o_l_l_o_w_i_n_g _a_r_e _m_i_n_i_m_a_l
  _r_e_q_u_i_r_e_m_e_n_t_s _f_o_r _s_y_s_t_e_m_s _a_s_s_i_g_n_e_d _a _c_l_a_s_s _(_B_2_) _r_a_t_i_n_g_:




  33..22..11..  SSeeccuurriittyy PPoolliiccyy

  33..22..11..11..  DDiissccrreettiioonnaarryy AAcccceessss CCoonnttrrooll

  The TCB shall define and control access between named users and named
  objects (e.g., files and programs) in the ADP system.  The enforcement
  mechanism (e.g., self/group/public controls, access control lists)
  shall allow users to specify and control sharing of those objects by
  named individuals, or defined groups of individuals, or by both, and
  shall provide controls to limit propagation of access rights.  The
  discretionary access control mechanism shall, either by explicit user
  action or by default, provide that objects are protected from
  unauthorized access.  These access controls shall be capable of
  including or excluding access to the granularity of a single user.
  Access permission to an object by users not already possessing access
  permission shall only be assigned by authorized users.


  33..22..11..22..  OObbjjeecctt RReeuussee

  All authorizations to the information contained within a storage
  object shall be revoked prior to initial assignment, allocation or
  reallocation to a subject from the TCB's pool of unused storage
  objects.  No information, including encrypted representations of
  information, produced by a prior subject's actions is to be available
  to any subject that obtains access to an object that has been released
  back to the system.


  33..22..11..33..  LLaabbeellss

  Sensitivity labels associated with each AADDPP ssyysstteemm rreessoouurrccee ((ee..gg..,,
  ssuubbjjeecctt,, ssttoorraaggee oobbjjeecctt,, RROOMM)) tthhaatt iiss ddiirreeccttllyy oorr iinnddiirreeccttllyy
  aacccceessssiibbllee bbyy ssuubbjjeeccttss eexxtteerrnnaall ttoo tthhee TTCCBB shall be maintained by the
  TCB.  These labels shall be used as the basis for mandatory access
  control decisions.  In order to import non-labeled data, the TCB shall
  request and receive from an authorized user the security level of the
  data, and all such actions shall be auditable by the TCB.


  33..22..11..33..11..  LLaabbeell IInntteeggrriittyy

  Sensitivity labels shall accurately represent security levels of the
  specific subjects or objects with which they are associated.  When
  exported by the TCB, sensitivity labels shall accurately and
  unambiguously represent the internal labels and shall be associated
  with the information being exported.


  33..22..11..33..22..  EExxppoorrttaattiioonn ooff LLaabbeelleedd IInnffoorrmmaattiioonn

  The TCB shall designate each communication channel and I/O device as
  either single-level or multilevel.  Any change in this designation
  shall be done manually and shall be auditable by the TCB.  The TCB
  shall maintain and be able to audit any change in the security level
  or levels associated with a communication channel or I/O device.


  33..22..11..33..22..11..  EExxppoorrttaattiioonn ttoo MMuullttiilleevveell DDeevviicceess

  When the TCB exports an object to a multilevel I/O device, the
  sensitivity label associated with that object shall also be exported
  and shall reside on the same physical medium as the exported
  information and shall be in the same form (i.e., machine-readable or
  human-readable form).  When the TCB exports or imports an object over
  a multilevel communication channel, the protocol used on that channel
  shall provide for the unambiguous pairing between the sensitivity
  labels and the associated information that is sent or received.


  33..22..11..33..22..22..  EExxppoorrttaattiioonn ttoo SSiinnggllee--LLeevveell DDeevviicceess

  Single-level I/O devices and single-level communication channels are
  not required to maintain the sensitivity labels of the information
  they process.  However, the TCB shall include a mechanism by which the
  TCB and an authorized user reliably communicate to designate the
  single security level of information imported or exported via single-
  level communication channels or I/O devices.


  33..22..11..33..22..33..  LLaabbeelliinngg HHuummaann--RReeaaddaabbllee OOuuttppuutt

  The ADP system administrator shall be able to specify the printable
  label names associated with exported sensitivity labels.  The TCB
  shall mark the beginning and end of all human-readable, paged,
  hardcopy output (e.g., line printer output) with human-readable
  sensitivity labels that properly ``(see footnote above)'' represent
  the sensitivity of the output.  The TCB shall, by default, mark the
  top and bottom of each page of human-readable, paged, hardcopy output
  (e.g., line printer output) with human-readable sensitivity labels
  that properly ``(see footnote above)'' represent the overall
  sensitivity of the output or that properly ``(see footnote above)''
  represent the sensitivity of the information on the page.  The TCB
  shall, by default and in an appropriate manner, mark other forms of
  human-readable output (e.g., maps, graphics) with human-readable
  sensitivity labels that properly ``(see footnote above)'' represent
  the sensitivity of the output.  Any override of these marking defaults
  shall be auditable by the TCB.


  33..22..11..33..33..  SSuubbjjeecctt SSeennssiittiivviittyy LLaabbeellss

  TThhee TTCCBB sshhaallll iimmmmeeddiiaatteellyy nnoottiiffyy aa tteerrmmiinnaall uusseerr ooff eeaacchh cchhaannggee iinn tthhee
  sseeccuurriittyy lleevveell aassssoocciiaatteedd wwiitthh tthhaatt uusseerr dduurriinngg aann iinntteerraaccttiivvee
  sseessssiioonn..  AA tteerrmmiinnaall uusseerr sshhaallll bbee aabbllee ttoo qquueerryy tthhee TTCCBB aass ddeessiirreedd
  ffoorr aa ddiissppllaayy ooff tthhee ssuubbjjeecctt''ss ccoommpplleettee sseennssiittiivviittyy llaabbeell..


  33..22..11..33..44..  DDeevviiccee LLaabbeellss

  TThhee TTCCBB sshhaallll ssuuppppoorrtt tthhee aassssiiggnnmmeenntt ooff mmiinniimmuumm aanndd mmaaxxiimmuumm sseeccuurriittyy
  lleevveellss ttoo aallll aattttaacchheedd pphhyyssiiccaall ddeevviicceess..  TThheessee sseeccuurriittyy lleevveellss sshhaallll
  bbee uusseedd bbyy tthhee TTCCBB ttoo eennffoorrccee ccoonnssttrraaiinnttss iimmppoosseedd bbyy tthhee pphhyyssiiccaall
  eennvviirroonnmmeennttss iinn wwhhiicchh tthhee ddeevviicceess aarree llooccaatteedd..


  33..22..11..44..  MMaannddaattoorryy AAcccceessss CCoonnttrrooll

  The TCB shall enforce a mandatory access control policy over all
  rreessoouurrcceess ((ii..ee..,, ssuubbjjeeccttss,, ssttoorraaggee oobbjjeeccttss,, aanndd II//OO ddeevviicceess tthhaatt aarree
  ddiirreeccttllyy oorr iinnddiirreeccttllyy aacccceessssiibbllee bbyy ssuubbjjeeccttss eexxtteerrnnaall ttoo tthhee TTCCBB.
  These subjects and objects shall be assigned sensitivity labels that
  are a combination of hierarchical classification levels and non-
  hierarchical categories, and the labels shall be used as the basis for
  mandatory access control decisions.  The TCB shall be able to support
  two or more such security levels.  (See the Mandatory Access Control
  guidelines.)  The following requirements shall hold for all accesses
  between aallll ssuubbjjeeccttss eexxtteerrnnaall ttoo tthhee TTCCBB aanndd aallll oobbjjeeccttss ddiirreeccttllyy oorr
  iinnddiirreeccttllyy aacccceessssiibbllee bbyy tthheessee ssuubbjjeeccttss:  A subject can read an object
  only if the hierarchical classification in the subject's security
  level is greater than or equal to the hierarchical classification in
  the object's security level and the non- hierarchical categories in
  the subject's security level include all the non-hierarchical
  categories in the object's security level.  A subject can write an
  object only if the hierarchical classification in the subject's
  security level is less than or equal to the hierarchical
  classification in the object's security level and all the non-
  hierarchical categories in the subject's security level are included
  in the non-hierarchical categories in the object's security level.
  Identification and authentication data shall be used by the TCB to
  authenticate the user's identity and to ensure that the security level
  and authorization of subjects external to the TCB that may be created
  to act on behalf of the individual user are dominated by the clearance
  and authorization of that user.


  33..22..22..  AAccccoouunnttaabbiilliittyy

  33..22..22..11..  IIddeennttiiffiiccaattiioonn aanndd AAuutthheennttiiccaattiioonn

  The TCB shall require users to identify themselves to it before
  beginning to perform any other actions that the TCB is expected to
  mediate.  Furthermore, the TCB shall maintain authentication data that
  includes information for verifying the identity of individual users
  (e.g., passwords) as well as information for determining the clearance
  and authorizations of individual users.  This data shall be used by
  the TCB to authenticate the user's identity and to ensure that the
  security level and authorizations of subjects external to the TCB that
  may be created to act on behalf of the individual user are dominated
  by the clearance and authorization of that user.  The TCB shall
  protect authentication data so that it cannot be accessed by any
  unauthorized user.  The TCB shall be able to enforce individual
  accountability by providing the capability to uniquely identify each
  individual ADP system user.  The TCB shall also provide the capability
  of associating this identity with all auditable actions taken by that
  individual.


  33..22..22..11..11..  TTrruusstteedd PPaatthh

  TThhee TTCCBB sshhaallll ssuuppppoorrtt aa ttrruusstteedd ccoommmmuunniiccaattiioonn ppaatthh bbeettwweeeenn iittsseellff aanndd
  uusseerr ffoorr iinniittiiaall llooggiinn aanndd aauutthheennttiiccaattiioonn..  CCoommmmuunniiccaattiioonnss vviiaa tthhiiss
  ppaatthh sshhaallll bbee iinniittiiaatteedd eexxcclluussiivveellyy bbyy aa uusseerr..


  33..22..22..22..  AAuuddiitt

  The TCB shall be able to create, maintain, and protect from
  modification or unauthorized access or destruction an audit trail of
  accesses to the objects it protects.  The audit data shall be
  protected by the TCB so that read access to it is limited to those who
  are authorized for audit data.  The TCB shall be able to record the
  following types of events: use of identification and authentication
  mechanisms, introduction of objects into a user's address space (e.g.,
  file open, program initiation), deletion of objects, and actions taken
  by computer operators and system administrators and/or system security
  officers, and other security relevant events.  The TCB shall also be
  able to audit any override of human-readable output markings.  For
  each recorded event, the audit record shall identify:  date and time
  of the event, user, type of event, and success or failure of the
  event.  For identification/ authentication events the origin of
  request (e.g., terminal ID) shall be included in the audit record.
  For events that introduce an object into a user's address space and
  for object deletion events the audit record shall include the name of
  the object and the object's security level.  The ADP system
  administrator shall be able to selectively audit the actions of any
  one or more users based on individual identity and/or object security
  level.  TThhee TTCCBB sshhaallll bbee aabbllee ttoo aauuddiitt tthhee iiddeennttiiffiieedd eevveennttss tthhaatt mmaayy
  bbee uusseedd iinn tthhee eexxppllooiittaattiioonn ooff ccoovveerrtt ssttoorraaggee cchhaannnneellss..


  33..22..33..  AAssssuurraannccee

  33..22..33..11..  OOppeerraattiioonnaall AAssssuurraannccee

  33..22..33..11..11..  SSyysstteemm AArrcchhiitteeccttuurree

  TThhee TTCCBB sshhaallll mmaaiinnttaaiinn aa ddoommaaiinn ffoorr iittss oowwnn eexxeeccuuttiioonn tthhaatt pprrootteeccttss iitt
  ffrroomm eexxtteerrnnaall iinntteerrffeerreennccee oorr ttaammppeerriinngg ((ee..gg..,, bbyy mmooddiiffiiccaattiioonn ooff iittss
  ccooddee oorr ddaattaa ssttrruuccttuurreess))..  TThhee TTCCBB sshhaallll mmaaiinnttaaiinn pprroocceessss iissoollaattiioonn
  tthhrroouugghh tthhee pprroovviissiioonn ooff ddiissttiinncctt aaddddrreessss ssppaacceess uunnddeerr iittss ccoonnttrrooll..
  TThhee TTCCBB sshhaallll bbee iinntteerrnnaallllyy ssttrruuccttuurreedd iinnttoo wweellll--ddeeffiinneedd llaarrggeellyy
  iinnddeeppeennddeenntt mmoodduulleess..  IItt sshhaallll mmaakkee eeffffeeccttiivvee uussee ooff aavvaaiillaabbllee
  hhaarrddwwaarree ttoo sseeppaarraattee tthhoossee eelleemmeennttss tthhaatt aarree pprrootteeccttiioonn--ccrriittiiccaall ffrroomm
  tthhoossee tthhaatt aarree nnoott..  TThhee TTCCBB mmoodduulleess sshhaallll bbee ddeessiiggnneedd ssuucchh tthhaatt tthhee
  pprriinncciippllee ooff lleeaasstt pprriivviilleeggee iiss eennffoorrcceedd..  FFeeaattuurreess iinn hhaarrddwwaarree,, ssuucchh
  aass sseeggmmeennttaattiioonn,, sshhaallll bbee uusseedd ttoo ssuuppppoorrtt llooggiiccaallllyy ddiissttiinncctt ssttoorraaggee
  oobbjjeeccttss wwiitthh sseeppaarraattee aattttrriibbuutteess ((nnaammeellyy:: rreeaaddaabbllee,, wwrriitteeaabbllee))..  TThhee
  uusseerr iinntteerrffaaccee ttoo tthhee TTCCBB sshhaallll bbee ccoommpplleetteellyy ddeeffiinneedd aanndd aallll eelleemmeennttss
  ooff tthhee TTCCBB iiddeennttiiffiieedd..


  33..22..33..11..22..  SSyysstteemm IInntteeggrriittyy

  Hardware and/or software features shall be provided that can be used
  to periodically validate the correct operation of the on-site hardware
  and firmware elements of the TCB.


  33..22..33..11..33..  CCoovveerrtt CChhaannnneell AAnnaallyyssiiss

  TThhee ssyysstteemm ddeevveellooppeerr sshhaallll ccoonndduucctt aa tthhoorroouugghh sseeaarrcchh ffoorr ccoovveerrtt
  ssttoorraaggee cchhaannnneellss aanndd mmaakkee aa ddeetteerrmmiinnaattiioonn ((eeiitthheerr bbyy aaccttuuaall
  mmeeaassuurreemmeenntt oorr bbyy eennggiinneeeerriinngg eessttiimmaattiioonn)) ooff tthhee mmaaxxiimmuumm bbaannddwwiiddtthh ooff
  eeaacchh iiddeennttiiffiieedd cchhaannnneell..  ((SSeeee tthhee ccoovveerrtt cchhaannnneellss gguuiiddeelliinnee sseeccttiioonn..))



  33..22..33..11..44..  TTrruusstteedd FFaacciilliittyy MMaannaaggeemmeenntt

  TThhee TTCCBB sshhaallll ssuuppppoorrtt sseeppaarraattee ooppeerraattoorr aanndd aaddmmiinniissttrraattoorr ffuunnccttiioonnss..


  33..22..33..22..  LLiiffee--CCyyccllee AAssssuurraannccee

  33..22..33..22..11..  SSeeccuurriittyy TTeessttiinngg

  The security mechanisms of the ADP system shall be tested and found to
  work as claimed in the system documentation.  A team of individuals
  who thoroughly understand the specific implementation of the TCB shall
  subject its design documentation, source code, and object code to
  thorough analysis and testing.  Their objectives shall be: to uncover
  all design and implementation flaws that would permit a subject
  external to the TCB to read, change, or delete data normally denied
  under the mandatory or discretionary security policy enforced by the
  TCB; as well as to assure that no subject (without authorization to do
  so) is able to cause the TCB to enter a state such that it is unable
  to respond to communications initiated by other users.  TThhee TTCCBB sshhaallll
  bbee ffoouunndd rreellaattiivveellyy rreessiissttaanntt ttoo ppeenneettrraattiioonn.  All discovered flaws
  shall be corrected and the TCB retested to demonstrate that they have
  been eliminated and that new flaws have not been introduced.  TTeessttiinngg
  sshhaallll ddeemmoonnssttrraattee tthhaatt tthhee TTCCBB iimmpplleemmeennttaattiioonn iiss ccoonnssiisstteenntt wwiitthh tthhee
  ddeessccrriippttiivvee ttoopp--lleevveell ssppeecciiffiiccaattiioonn..  (See the Security Testing
  Guidelines.)
  33..22..33..22..22..  DDeessiiggnn SSppeecciiffiiccaattiioonn aanndd VVeerriiffiiccaattiioonn

  AA ffoorrmmaall model of the security policy supported by the TCB shall be
  maintained over the life cycle of the ADP system that is pprroovveenn
  consistent with its axioms.  AA ddeessccrriippttiivvee ttoopp--lleevveell ssppeecciiffiiccaattiioonn
  ((DDTTLLSS)) ooff tthhee TTCCBB sshhaallll bbee mmaaiinnttaaiinneedd tthhaatt ccoommpplleetteellyy aanndd aaccccuurraatteellyy
  ddeessccrriibbeess tthhee TTCCBB iinn tteerrmmss ooff eexxcceeppttiioonnss,, eerrrroorr mmeessssaaggeess,, aanndd eeffffeeccttss..
  IItt sshhaallll bbee sshhoowwnn ttoo bbee aann aaccccuurraattee ddeessccrriippttiioonn ooff tthhee TTCCBB iinntteerrffaaccee..


  33..22..33..22..33..  CCoonnffiigguurraattiioonn MMaannaaggeemmeenntt

  DDuurriinngg ddeevveellooppmmeenntt aanndd mmaaiinntteennaannccee ooff tthhee TTCCBB,, aa ccoonnffiigguurraattiioonn
  mmaannaaggeemmeenntt ssyysstteemm sshhaallll bbee iinn ppllaaccee tthhaatt mmaaiinnttaaiinnss ccoonnttrrooll ooff cchhaannggeess
  ttoo tthhee ddeessccrriippttiivvee ttoopp--lleevveell ssppeecciiffiiccaattiioonn,, ootthheerr ddeessiiggnn ddaattaa,,
  iimmpplleemmeennttaattiioonn ddooccuummeennttaattiioonn,, ssoouurrccee ccooddee,, tthhee rruunnnniinngg vveerrssiioonnooff tthhee
  oobbjjeecctt ccooddee,, aanndd tteesstt ffiixxttuurreess aanndd ddooccuummeennttaattiioonn..  TThhee ccoonnffiigguurraattiioonn
  mmaannaaggeemmeenntt ssyysstteemm sshhaallll aassssuurree aa ccoonnssiisstteenntt mmaappppiinngg aammoonngg aallll
  ddooccuummeennttaattiioonn aanndd ccooddee aassssoocciiaatteedd wwiitthh tthhee ccuurrrreenntt vveerrssiioonn ooff tthhee TTCCBB..
  TToooollss sshhaallll bbee pprroovviiddeedd ffoorr ggeenneerraattiioonn ooff aa nneeww vveerrssiioonn ooff tthhee TTCCBB
  ffrroomm ssoouurrccee ccooddee..  AAllssoo aavvaaiillaabbllee sshhaallll bbee ttoooollss ffoorr ccoommppaarriinngg aa nneewwllyy
  ggeenneerraatteedd vveerrssiioonn wwiitthh tthhee pprreevviioouuss TTCCBB vveerrssiioonn iinn oorrddeerr ttoo aasscceerrttaaiinn
  tthhaatt oonnllyy tthhee iinntteennddeedd cchhaannggeess hhaavvee bbeeeenn mmaaddee iinn tthhee ccooddee tthhaatt wwiillll
  aaccttuuaallllyy bbee uusseedd aass tthhee nneeww vveerrssiioonn ooff tthhee TTCCBB..


  33..22..44..  DDooccuummeennttaattiioonn

  33..22..44..11..  SSeeccuurriittyy FFeeaattuurreess UUsseerr''ss GGuuiiddee

  A single summary, chapter, or manual in user documentation shall
  describe the protection mechanisms provided by the TCB, guidelines on
  their use, and how they interact with one another.


  33..22..44..22..  TTrruusstteedd FFaacciilliittyy MMaannuuaall

  A manual addressed to the ADP system administrator shall present
  cautions about functions and privileges that should be controlled when
  running a secure facility.  The procedures for examining and
  maintaining the audit files as well as the detailed audit record
  structure for each type of audit event shall be given.  The manual
  shall describe the operator and administrator functions related to
  security, to include changing the security characteristics of a user.
  It shall provide guidelines on the consistent and effective use of the
  protection features of the system, how they interact, how to securely
  generate a new TCB, and facility procedures, warnings, and privileges
  that need to be controlled in order to operate the facility in a
  secure manner.  TThhee TTCCBB mmoodduulleess tthhaatt ccoonnttaaiinn tthhee rreeffeerreennccee vvaalliiddaattiioonn
  mmeecchhaanniissmm sshhaallll bbee iiddeennttiiffiieedd..  TThhee pprroocceedduurreess ffoorr sseeccuurree ggeenneerraattiioonn
  ooff aa nneeww TTCCBB ffrroomm ssoouurrccee aafftteerr mmooddiiffiiccaattiioonn ooff aannyy mmoodduulleess iinn tthhee TTCCBB
  sshhaallll bbee ddeessccrriibbeedd..


  33..22..44..33..  TTeesstt DDooccuummeennttaattiioonn

  The system developer shall provide to the evaluators a document that
  describes the test plan, test procedures that show how the security
  mechanisms were tested, and results of the security mechanisms'
  functional testing.  IItt sshhaallll iinncclluuddee rreessuullttss ooff tteessttiinngg tthhee
  eeffffeeccttiivveenneessss ooff tthhee mmeetthhooddss uusseedd ttoo rreedduuccee ccoovveerrtt cchhaannnneell bbaannddwwiiddtthhss..





  33..22..44..44..  DDeessiiggnn DDooccuummeennttaattiioonn

  Documentation shall be available that provides a description of the
  manufacturer's philosophy of protection and an explanation of how this
  philosophy is translated into the TCB.  TThhee interfaces between tthhee TTCCBB
  modules shall be described.  AA ffoorrmmaall description of the security
  policy model enforced by the TCB shall be available and pprroovveenn that it
  is sufficient to enforce the security policy.  The specific TCB
  protection mechanisms shall be identified and an explanation given to
  show that they satisfy the model.  TThhee ddeessccrriippttiivvee ttoopp--lleevveell
  ssppeecciiffiiccaattiioonn ((DDTTLLSS)) sshhaallll bbee sshhoowwnn ttoo bbee aann aaccccuurraattee ddeessccrriippttiioonn ooff
  tthhee TTCCBB iinntteerrffaaccee..  DDooccuummeennttaattiioonn sshhaallll ddeessccrriibbee hhooww tthhee TTCCBB
  iimmpplleemmeennttss tthhee rreeffeerreennccee mmoonniittoorr ccoonncceepptt aanndd ggiivvee aann eexxppllaannaattiioonn wwhhyy
  iitt iiss ttaammppeerr rreessiissttaanntt,, ccaannnnoott bbee bbyyppaasssseedd,, aanndd iiss ccoorrrreeccttllyy
  iimmpplleemmeenntteedd..  DDooccuummeennttaattiioonn sshhaallll ddeessccrriibbee hhooww tthhee TTCCBB iiss ssttrruuccttuurreedd
  ttoo ffaacciilliittaattee tteessttiinngg aanndd ttoo eennffoorrccee lleeaasstt pprriivviilleeggee..  TThhiiss
  ddooccuummeennttaattiioonn sshhaallll aallssoo pprreesseenntt tthhee rreessuullttss ooff tthhee ccoovveerrtt cchhaannnneell
  aannaallyyssiiss aanndd tthhee ttrraaddeeooffffss iinnvvoollvveedd iinn rreessttrriiccttiinngg tthhee cchhaannnneellss..  AAllll
  aauuddiittaabbllee eevveennttss tthhaatt mmaayy bbee uusseedd iinn tthhee eexxppllooiittaattiioonn ooff kknnoowwnn ccoovveerrtt
  ssttoorraaggee cchhaannnneellss sshhaallll bbee iiddeennttiiffiieedd..  TThhee bbaannddwwiiddtthhss ooff kknnoowwnn ccoovveerrtt
  ssttoorraaggee cchhaannnneellss tthhee uussee ooff wwhhiicchh iiss nnoott ddeetteeccttaabbllee bbyy tthhee aauuddiittiinngg
  mmeecchhaanniissmmss,, sshhaallll bbee pprroovviiddeedd..  ((SSeeee tthhee CCoovveerrtt CChhaannnneell GGuuiiddeelliinnee
  sseeccttiioonn..))



  33..33..  CCLLAASSSS ((BB33))::  SSEECCUURRIITTYY DDOOMMAAIINNSS

  _T_h_e _c_l_a_s_s _(_B_3_) _T_C_B _m_u_s_t _s_a_t_i_s_f_y _t_h_e _r_e_f_e_r_e_n_c_e _m_o_n_i_t_o_r _r_e_q_u_i_r_e_m_e_n_t_s
  _t_h_a_t _i_t _m_e_d_i_a_t_e _a_l_l _a_c_c_e_s_s_e_s _o_f _s_u_b_j_e_c_t_s _t_o _o_b_j_e_c_t_s_, _b_e _t_a_m_p_e_r_p_r_o_o_f_,
  _a_n_d _b_e _s_m_a_l_l _e_n_o_u_g_h _t_o _b_e _s_u_b_j_e_c_t_e_d _t_o _a_n_a_l_y_s_i_s _a_n_d _t_e_s_t_s_.  _T_o _t_h_i_s
  _e_n_d_, _t_h_e _T_C_B _i_s _s_t_r_u_c_t_u_r_e_d _t_o _e_x_c_l_u_d_e _c_o_d_e _n_o_t _e_s_s_e_n_t_i_a_l _t_o _s_e_c_u_r_i_t_y
  _p_o_l_i_c_y _e_n_f_o_r_c_e_m_e_n_t_, _w_i_t_h _s_i_g_n_i_f_i_c_a_n_t _s_y_s_t_e_m _e_n_g_i_n_e_e_r_i_n_g _d_u_r_i_n_g _T_C_B
  _d_e_s_i_g_n _a_n_d _i_m_p_l_e_m_e_n_t_a_t_i_o_n _d_i_r_e_c_t_e_d _t_o_w_a_r_d _m_i_n_i_m_i_z_i_n_g _i_t_s _c_o_m_p_l_e_x_i_t_y_.
  _A _s_e_c_u_r_i_t_y _a_d_m_i_n_i_s_t_r_a_t_o_r _i_s _s_u_p_p_o_r_t_e_d_, _a_u_d_i_t _m_e_c_h_a_n_i_s_m_s _a_r_e _e_x_p_a_n_d_e_d
  _t_o _s_i_g_n_a_l _s_e_c_u_r_i_t_y_- _r_e_l_e_v_a_n_t _e_v_e_n_t_s_, _a_n_d _s_y_s_t_e_m _r_e_c_o_v_e_r_y _p_r_o_c_e_d_u_r_e_s
  _a_r_e _r_e_q_u_i_r_e_d_.  _T_h_e _s_y_s_t_e_m _i_s _h_i_g_h_l_y _r_e_s_i_s_t_a_n_t _t_o _p_e_n_e_t_r_a_t_i_o_n_.  _T_h_e
  _f_o_l_l_o_w_i_n_g _a_r_e _m_i_n_i_m_a_l _r_e_q_u_i_r_e_m_e_n_t_s _f_o_r _s_y_s_t_e_m_s _a_s_s_i_g_n_e_d _a _c_l_a_s_s _(_B_3_)
  _r_a_t_i_n_g_:


  33..33..11..  SSeeccuurriittyy PPoolliiccyy

  33..33..11..11..  DDiissccrreettiioonnaarryy AAcccceessss CCoonnttrrooll

  The TCB shall define and control access between named users and named
  objects (e.g., files and programs) in the ADP system.  The enforcement
  mechanism (e.g., access control lists) shall allow users to specify
  and control sharing of those objects, and shall provide controls to
  limit propagation of access rights.  The discretionary access control
  mechanism shall, either by explicit user action or by default, provide
  that objects are protected from unauthorized access.  These access
  controls shall be capable of ssppeecciiffyyiinngg,, ffoorr eeaacchh nnaammeedd oobbjjeecctt,, aa lliisstt
  ooff nnaammeedd iinnddiivviidduuaallss aanndd aa lliisstt ooff ggrroouuppss ooff nnaammeedd iinnddiivviidduuaallss wwiitthh
  tthheeiirr rreessppeeccttiivvee mmooddeess ooff aacccceessss ttoo tthhaatt oobbjjeecctt..  FFuurrtthheerrmmoorree,, ffoorr
  eeaacchh ssuucchh nnaammeedd oobbjjeecctt,, iitt sshhaallll bbee ppoossssiibbllee ttoo ssppeecciiffyy aa lliisstt ooff
  nnaammeedd iinnddiivviidduuaallss aanndd aa lliisstt ooff ggrroouuppss ooff nnaammeedd iinnddiivviidduuaallss ffoorr wwhhiicchh
  nnoo aacccceessss ttoo tthhee oobbjjeecctt iiss ttoo bbee ggiivveenn.  Access permission to an
  object by users not already possessing access permission shall only be
  assigned by authorized users.


  33..33..11..22..  OObbjjeecctt RReeuussee

  All authorizations to the information contained within a storage
  object shall be revoked prior to initial assignment, allocation or
  reallocation to a subject from the TCB's pool of unused storage
  objects.  No information, including encrypted representations of
  information, produced by a prior subjects actions is to be available
  to any subject that obtains access to an object that has been released
  back to the system.


  33..33..11..33..  LLaabbeellss

  Sensitivity labels associated with each ADP system resource (e.g.,
  subject, storage object, ROM) that is directly or indirectly
  accessible by subjects external to the TCB shall be maintained by the
  TCB.  These labels shall be used as the basis for mandatory access
  control decisions.  In order to import non-labeled data, the TCB shall
  request and receive from an authorized user the security level of the
  data, and all such actions shall be auditable by the TCB.


  33..33..11..33..11..  LLaabbeell IInntteeggrriittyy

  Sensitivity labels shall accurately represent security levels of the
  specific subjects or objects with which they are associated.  When
  exported by the TCB, sensitivity labels shall accurately and
  unambiguously represent the internal labels and shall be associated
  with the information being exported.


  33..33..11..33..22..  EExxppoorrttaattiioonn ooff LLaabbeelleedd IInnffoorrmmaattiioonn

  The TCB shall designate each communication channel and I/O device as
  either single-level or multilevel.  Any change in this designation
  shall be done manually and shall be auditable by the TCB.  The TCB
  shall maintain and be able to audit any change in the security level
  or levels associated with a communication channel or I/O device.


  33..33..11..33..22..11..  EExxppoorrttaattiioonn ttoo MMuullttiilleevveell DDeevviicceess

  When the TCB exports an object to a multilevel I/O device, the
  sensitivity label associated with that object shall also be exported
  and shall reside on the same physical medium as the exported
  information and shall be in the same form (i.e., machine-readable or
  human-readable form).  When the TCB exports or imports an object over
  a multilevel communication channel, the protocol used on that channel
  shall provide for the unambiguous pairing between the sensitivity
  labels and the associated information that is sent or received.


  33..33..11..33..22..22..  EExxppoorrttaattiioonn ttoo SSiinnggllee--LLeevveell DDeevviicceess

  Single-level I/O devices and single-level communication channels are
  not required to maintain the sensitivity labels of the information
  they process.  However, the TCB shall include a mechanism by which the
  TCB and an authorized user reliably communicate to designate the
  single security level of information imported or exported via single-
  level communication channels or I/O devices.


  33..33..11..33..22..33..  LLaabbeelliinngg HHuummaann--RReeaaddaabbllee OOuuttppuutt

  The ADP system administrator shall be able to specify the printable
  label names associated with exported sensitivity labels.  The TCB
  shall mark the beginning and end of all human-readable, paged,
  hardcopy output (e.g., line printer output) with human-readable
  sensitivity labels that properly ``(see footnote above)'' represent
  the sensitivity of the output.  The TCB shall, by default, mark the
  top and bottom of each page of human-readable, paged, hardcopy output
  (e.g., line printer output) with human-readable sensitivity labels
  that properly ``(see footnote above)'' represent the overall
  sensitivity of the output or that properly ``(see footnote above)''
  represent the sensitivity of the information on the page.  The TCB
  shall, by default and in an appropriate manner, mark other forms of
  human-readable output (e.g., maps, graphics) with human-readable
  sensitivity labels that properly ``(see footnote above)'' represent
  the sensitivity of the output.  Any override of these marking defaults
  shall be auditable by the TCB.


  33..33..11..33..33..  SSuubbjjeecctt SSeennssiittiivviittyy LLaabbeellss

  The TCB shall immediately notify a terminal user of each change in the
  security level associated with that user during an interactive
  session.  A terminal user shall be able to query the TCB as desired
  for a display of the subject's complete sensitivity label.


  33..33..11..33..44..  DDeevviiccee LLaabbeellss

  The TCB shall support the assignment of minimum and maximum security
  levels to all attached physical devices.  These security levels shall
  be used by the TCB to enforce constraints imposed by the physical
  environments in which the devices are located.


  33..33..11..44..  MMaannddaattoorryy AAcccceessss CCoonnttrrooll

  The TCB shall enforce a mandatory access control policy over all
  resources (i.e., subjects, storage objects, and I/O devices) that are
  directly or indirectly accessible by subjects external to the TCB.
  These subjects and objects shall be assigned sensitivity labels that
  are a combination of hierarchical classification levels and non-
  hierarchical categories, and the labels shall be used as the basis for
  mandatory access control decisions.  The TCB shall be able to support
  two or more such security levels.  (See the Mandatory Access Control
  guidelines.)  The following requirements shall hold for all accesses
  between all subjects external to the TCB and all objects directly or
  indirectly accessible by these subjects: A subject can read an object
  only if the hierarchical classification in the subject's security
  level is greater than or equal to the hierarchical classification in
  the object's security level and the non-hierarchical categories in the
  subject's security level include all the non-hierarchical categories
  in the object's security level.  A subject can write an object only if
  the hierarchical classification in the subject's security level is
  less than or equal to the hierarchical classification in the object's
  security level and all the non-hierarchical categories in the
  subject's security level are included in the non- hierarchical
  categories in the object's security level.  Identification and
  authentication data shall be used by the TCB to authenticate the
  user's identity and to ensure that the security level and authori-
  zation of subjects external to the TCB that may be created to act on
  behalf of the individual user are dominated by the clearance and
  authorization of that user.


  33..33..22..  AAccccoouunnttaabbiilliittyy

  33..33..22..11..  IIddeennttiiffiiccaattiioonn aanndd AAuutthheennttiiccaattiioonn

  The TCB shall require users to identify themselves to it before
  beginning to perform any other actions that the TCB is expected to
  mediate.  Furthermore, the TCB shall maintain authentication data that
  includes information for verifying the identity of individual users
  (e.g., passwords) as well as information for determining the clearance
  and authorizations of individual users.  This data shall be used by
  the TCB to authenticate the user's identity and to ensure that the
  security level and authorizations of subjectsexternal to the TCB that
  may be created to act on behalf of the individual user are dominated
  by the clearance and authorization of that user.  The TCB shall
  protect authentication data so that it cannot be accessed by any
  unauthorized user.  The TCB shall be able to enforce individual
  accountability by providing the capability to uniquely identify each
  individual ADP system user.  The TCB shall also provide the capability
  of associating this identity with all auditable actions taken by that
  individual.


  33..33..22..11..11..  TTrruusstteedd PPaatthh

  The TCB shall support a trusted communication path between itself and
  uusseerrss for uussee wwhheenn aa ppoossiittiivvee TTCCBB--ttoo--uusseerr ccoonnnneeccttiioonn iiss rreeqquuiirreedd
  ((ee..gg..,, llooggiinn,, cchhaannggee ssuubbjjeecctt sseeccuurriittyy lleevveell)).  Communications via this
  ttrruusstteedd path shall be aaccttiivvaatteedd exclusively by a user oorr tthhee TTCCBB aanndd
  sshhaallll bbee llooggiiccaallllyy iissoollaatteedd aanndd uunnmmiissttaakkaabbllyy ddiissttiinngguuiisshhaabbllee ffrroomm
  ootthheerr ppaatthhss.


  33..33..22..22..  AAuuddiitt

  The TCB shall be able to create, maintain, and protect from
  modification or unauthorized access or destruction an audit trail of
  accesses to the objects it protects.  The audit data shall be
  protected by the TCB so that read access to it is limited to those who
  are authorized for audit data.  The TCB shall be able to record the
  following types of events: use of identification and authentication
  mechanisms, introduction of objects into a user's address space (e.g.,
  file open, program initiation), deletion of objects, and actions taken
  by computer operators and system administrators and/or system security
  officers and other security relevant events.  The TCB shall also be
  able to audit any override of human-readable output markings.  For
  each recorded event, the audit record shall identify:  date and time
  of the event, user, type of event, and success or failure of the
  event.  For identification/authentication events the origin of request
  (e.g., terminal ID) shall be included in the audit record.  For events
  that introduce an object into a user's address space and for object
  deletion events the audit record shall include the name of the object
  and the object's security level.  The ADP system administrator shall
  be able to selectively audit the actions of any one or more users
  based on individual identity and/or object security level.  The TCB
  shall be able to audit the identified events that may be used in the
  exploitation of covert storage channels.  TThhee TTCCBB sshhaallll ccoonnttaaiinn aa
  mmeecchhaanniissmm tthhaatt iiss aabbllee ttoo mmoonniittoorr tthhee ooccccuurrrreennccee oorr aaccccuummuullaattiioonn ooff
  sseeccuurriittyy aauuddiittaabbllee eevveennttss tthhaatt mmaayy iinnddiiccaattee aann iimmmmiinneenntt vviioollaattiioonn ooff
  sseeccuurriittyy ppoolliiccyy..  TThhiiss mmeecchhaanniissmm sshhaallll bbee aabbllee ttoo iimmmmeeddiiaatteellyy nnoottiiffyy
  tthhee sseeccuurriittyy aaddmmiinniissttrraattoorr wwhheenn tthhrreesshhoollddss aarree eexxcceeeeddeedd,, aanndd iiff tthhee
  ooccccuurrrreennccee oorr aaccccuummuullaattiioonn ooff tthheessee sseeccuurriittyy rreelleevvaanntt eevveennttss
  ccoonnttiinnuueess,, tthhee ssyysstteemm sshhaallll ttaakkee tthhee lleeaasstt ddiissrruuppttiivvee aaccttiioonn ttoo
  tteerrmmiinnaattee tthhee eevveenntt..


  33..33..33..  AAssssuurraannccee

  33..33..33..11..  OOppeerraattiioonnaall AAssssuurraannccee

  33..33..33..11..11..  SSyysstteemm AArrcchhiitteeccttuurree

  The TCB shall maintain a domain for its own execution that protects it
  from external interference or tampering (e.g., by modification of its
  code or data structures).  The TCB shall maintain process isolation
  through the provision of distinct address spaces under its control.
  The TCB shall be internally structured into well-defined largely
  independent modules.  It shall make effective use of available
  hardware to separate those elements that are protection-critical from
  those that are not.  The TCB modules shall be designed such that the
  principle of least privilege is enforced.  Features in hardware, such
  as segmentation, shall be used to support logically distinct storage
  objects with separate attributes (namely: readable, writeable).  The
  user interface to the TCB shall be completely defined and all elements
  of the TCB identified.  TThhee TTCCBB sshhaallll bbee ddeessiiggnneedd aanndd ssttrruuccttuurreedd ttoo
  uussee aa ccoommpplleettee,, ccoonncceeppttuuaallllyy ssiimmppllee pprrootteeccttiioonn mmeecchhaanniissmm wwiitthh
  pprreecciisseellyy ddeeffiinneedd sseemmaannttiiccss..  TThhiiss mmeecchhaanniissmm sshhaallll ppllaayy aa cceennttrraall rroollee
  iinn eennffoorrcciinngg tthhee iinntteerrnnaall ssttrruuccttuurriinngg ooff tthhee TTCCBB aanndd tthhee ssyysstteemm..  TThhee
  TTCCBB sshhaallll iinnccoorrppoorraattee ssiiggnniiffiiccaanntt uussee ooff llaayyeerriinngg,, aabbssttrraaccttiioonn aanndd
  ddaattaa hhiiddiinngg..  SSiiggnniiffiiccaanntt ssyysstteemm eennggiinneeeerriinngg sshhaallll bbee ddiirreecctteedd ttoowwaarrdd
  mmiinniimmiizziinngg tthhee ccoommpplleexxiittyy ooff tthhee TTCCBB aanndd eexxcclluuddiinngg ffrroomm tthhee TTCCBB
  mmoodduulleess tthhaatt aarree nnoott pprrootteeccttiioonn--ccrriittiiccaall..


  33..33..33..11..22..  SSyysstteemm IInntteeggrriittyy

  Hardware and/or software features shall be provided that can be used
  to periodically validate the correct operation of the on-site hardware
  and firmware elements of the TCB.


  33..33..33..11..33..  CCoovveerrtt CChhaannnneell AAnnaallyyssiiss

  The system developer shall conduct a thorough search for ccoovveerrtt
  cchhaannnneellss and make a determination (either by actual measurement or by
  engineering estimation) of the maximum bandwidth of each identified
  channel.  (See the Covert Channels Guideline section.)


  33..33..33..11..44..  TTrruusstteedd FFaacciilliittyy MMaannaaggeemmeenntt

  The TCB shall support separate operator and administrator functions.
  TThhee ffuunnccttiioonnss ppeerrffoorrmmeedd iinn tthhee rroollee ooff aa sseeccuurriittyy aaddmmiinniissttrraattoorr sshhaallll
  bbee iiddeennttiiffiieedd..  TThhee AADDPP ssyysstteemm aaddmmiinniissttrraattiivvee ppeerrssoonnnneell sshhaallll oonnllyy bbee
  aabbllee ttoo ppeerrffoorrmm sseeccuurriittyy aaddmmiinniissttrraattoorr ffuunnccttiioonnss aafftteerr ttaakkiinngg aa
  ddiissttiinncctt aauuddiittaabbllee aaccttiioonn ttoo aassssuummee tthhee sseeccuurriittyy aaddmmiinniissttrraattoorr rroollee oonn
  tthhee AADDPP ssyysstteemm..  NNoonn--sseeccuurriittyy ffuunnccttiioonnss tthhaatt ccaann bbee ppeerrffoorrmmeedd iinn tthhee
  sseeccuurriittyy aaddmmiinniissttrraattiioonn rroollee sshhaallll bbee lliimmiitteedd ssttrriiccttllyy ttoo tthhoossee
  eesssseennttiiaall ttoo ppeerrffoorrmmiinngg tthhee sseeccuurriittyy rroollee eeffffeeccttiivveellyy..


  33..33..33..11..55..  TTrruusstteedd RReeccoovveerryy

  PPrroocceedduurreess aanndd//oorr mmeecchhaanniissmmss sshhaallll bbee pprroovviiddeedd ttoo aassssuurree tthhaatt,, aafftteerr
  aann AADDPP ssyysstteemm ffaaiilluurree oorr ootthheerr ddiissccoonnttiinnuuiittyy,, rreeccoovveerryy wwiitthhoouutt aa
  pprrootteeccttiioonn ccoommpprroommiissee iiss oobbttaaiinneedd..


  33..33..33..22..  LLiiffee--CCyyccllee AAssssuurraannccee

  33..33..33..22..11..  SSeeccuurriittyy TTeessttiinngg

  The security mechanisms of the ADP system shall be tested and found to
  work as claimed in the system documentation.  A team of individuals
  who thoroughly understand the specific implementation of the TCB shall
  subject its design documentation, source code, and object code to
  thorough analysis and testing.  Their objectives shall be: to uncover
  all design and implementation flaws that would permit a subject
  external to the TCB to read, change, or delete data normally denied
  under the mandatory or discretionary security policy enforced by the
  TCB; as well as to assure that no subject (without authorization to do
  so) is able to cause the TCB to enter a state such that it is unable
  to respond to communications initiated by other users.  The TCB shall
  be ffoouunndd rreessiissttaanntt to penetration.  All discovered flaws shall be
  corrected and the TCB retested to demonstrate that they have been
  eliminated and that new flaws have not been introduced.  Testing shall
  demonstrate that the TCB implementation is consistent with the
  descriptive top-level specification.  (See the Security Testing
  Guidelines.)  NNoo ddeessiiggnn ffllaawwss aanndd nnoo mmoorree tthhaann aa ffeeww ccoorrrreeccttaabbllee
  iimmpplleemmeennttaattiioonn ffllaawwss mmaayy bbee ffoouunndd dduurriinngg tteessttiinngg aanndd tthheerree sshhaallll bbee
  rreeaassoonnaabbllee ccoonnffiiddeennccee tthhaatt ffeeww rreemmaaiinn..


  33..33..33..22..22..  DDeessiiggnn SSppeecciiffiiccaattiioonn aanndd VVeerriiffiiccaattiioonn

  A formal model of the security policy supported by the TCB shall be
  maintained over the life cycle of the ADP system that is proven
  consistent with its axioms.  A descriptive top-level specification
  (DTLS) of the TCB shall be maintained that completely and accurately
  describes the TCB in terms of exceptions, error messages, and effects.
  It shall be shown to be an accurate description of the TCB interface.
  AA ccoonnvviinncciinngg aarrgguummeenntt sshhaallll bbee ggiivveenn tthhaatt tthhee DDTTLLSS iiss ccoonnssiisstteenntt wwiitthh
  tthhee mmooddeell..


  33..33..33..22..33..  CCoonnffiigguurraattiioonn MMaannaaggeemmeenntt

  During development and maintenance of the TCB, a configuration
  management system shall be in place that maintains control of changes
  to the descriptive top-level specification, other design data,
  implementation documentation, source code, the running version of the
  object code, and test fixtures and documentation.  The configuration
  management system shall assure a consistent mapping among all
  documentation and code associated with the current version of the TCB.
  Tools shall be provided for generation of a new version of the TCB
  from source code.  Also available shall be tools for comparing a newly
  generated version with the previous TCB version in order to ascertain
  that only the intended changes have been made in the code that will
  actually be used as the new version of the TCB.


  33..33..44..  DDooccuummeennttaattiioonn

  33..33..44..11..  SSeeccuurriittyy FFeeaattuurreess UUsseerr''ss GGuuiiddee

  A single summary, chapter, or manual in user documentation shall
  describe the protection mechanisms provided by the TCB, guidelines on
  their use, and how they interact with one another.


  33..33..44..22..  TTrruusstteedd FFaacciilliittyy MMaannuuaall

  A manual addressed to the ADP system administrator shall present
  cautions about functions and privileges that should be controlled when
  running a secure facility.  The procedures for examining and
  maintaining the audit files as well as the detailed audit record
  structure for each type of audit event shall be given.  The manual
  shall describe the operator and administrator functions related to
  security, to include changing the security characteristics of a user.
  It shall provide guidelines on the consistent and effective use of the
  protection features of the system, how they interact, how to securely
  generate a new TCB, and facility procedures, warnings, and privileges
  that need to be controlled in order to operate the facility in a
  secure manner.  The TCB modules that contain the reference validation
  mechanism shall be identified.  The procedures for secure generation
  of a new TCB from source after modification of any modules in the TCB
  shall be described.  IItt sshhaallll iinncclluuddee tthhee pprroocceedduurreess ttoo eennssuurree tthhaatt
  tthhee ssyysstteemm iiss iinniittiiaallllyy ssttaarrtteedd iinn aa sseeccuurree mmaannnneerr..  PPrroocceedduurreess sshhaallll
  aallssoo bbee iinncclluuddeedd ttoo rreessuummee sseeccuurree ssyysstteemm ooppeerraattiioonn aafftteerr aannyy llaappssee iinn
  ssyysstteemm ooppeerraattiioonn..


  33..33..44..33..  TTeesstt DDooccuummeennttaattiioonn

  The system developer shall provide to the evaluators a document that
  describes the test plan, test procedures that show how the security
  mechanisms were tested, and results of the security mechanisms'
  functional testing.  It shall include results of testing the
  effectiveness of the methods used to reduce covert channel bandwidths.


  33..33..44..44..  DDeessiiggnn DDooccuummeennttaattiioonn

  Documentation shall be available that provides a description of the
  manufacturer's philosophy of protection and an explanation of how this
  philosophy is translated into the TCB.  The interfaces between the TCB
  modules shall be described.  A formal description of the security
  policy model enforced by the TCB shall be available and proven that it
  is sufficient to enforce the security policy.  The specific TCB
  protection mechanisms shall be identified and an explanation given to
  show that they satisfy the model.  The descriptive top-level
  specification (DTLS) shall be shown to be an accurate description of
  the TCB interface.  Documentation shall describe how the TCB
  implements the reference monitor concept and give an explanation why
  it is tamper resistant, cannot be bypassed, and is correctly
  implemented.  TThhee TTCCBB iimmpplleemmeennttaattiioonn ((ii..ee..,, iinn hhaarrddwwaarree,, ffiirrmmwwaarree,, aanndd
  ssooffttwwaarree)) sshhaallll bbee iinnffoorrmmaallllyy sshhoowwnn ttoo bbee ccoonnssiisstteenntt wwiitthh tthhee DDTTLLSS..
  TThhee eelleemmeennttss ooff tthhee DDTTLLSS sshhaallll bbee sshhoowwnn,, uussiinngg iinnffoorrmmaall tteecchhnniiqquueess,, ttoo
  ccoorrrreessppoonndd ttoo tthhee eelleemmeennttss ooff tthhee TTCCBB..  Documentation shall describe
  how the TCB is structured to facilitate testing and to enforce least
  privilege.  This documentation shall also present the results of the
  covert channel analysis and the tradeoffs involved in restricting the
  channels.  All auditable events that may be used in the exploitation
  of known covert storage channels shall be identified.  The bandwidths
  of known covert storage channels, the use of which is not detectable
  by the auditing mechanisms, shall be provided.  (See the Covert
  Channel Guideline section.)


























  44..  DDIIVVIISSIIOONN AA::  VVEERRIIFFIIEEDD PPRROOTTEECCTTIIOONN

  This division is characterized by the use of formal security
  verification methods to assure that the mandatory and discretionary
  security controls employed in the system can effectively protect
  classified or other sensitive information stored or processed by the
  system.  Extensive documentation is required to demonstrate that the
  TCB meets the security requirements in all aspects of design,
  development and implementation.


  44..11..  CCLLAASSSS ((AA11))::  VVEERRIIFFIIEEDD DDEESSIIGGNN

  _S_y_s_t_e_m_s _i_n _c_l_a_s_s _(_A_1_) _a_r_e _f_u_n_c_t_i_o_n_a_l_l_y _e_q_u_i_v_a_l_e_n_t _t_o _t_h_o_s_e _i_n _c_l_a_s_s
  _(_B_3_) _i_n _t_h_a_t _n_o _a_d_d_i_t_i_o_n_a_l _a_r_c_h_i_t_e_c_t_u_r_a_l _f_e_a_t_u_r_e_s _o_r _p_o_l_i_c_y
  _r_e_q_u_i_r_e_m_e_n_t_s _a_r_e _a_d_d_e_d_.  _T_h_e _d_i_s_t_i_n_g_u_i_s_h_i_n_g _f_e_a_t_u_r_e _o_f _s_y_s_t_e_m_s _i_n _t_h_i_s
  _c_l_a_s_s _i_s _t_h_e _a_n_a_l_y_s_i_s _d_e_r_i_v_e_d _f_r_o_m _f_o_r_m_a_l _d_e_s_i_g_n _s_p_e_c_i_f_i_c_a_t_i_o_n _a_n_d
  _v_e_r_i_f_i_c_a_t_i_o_n _t_e_c_h_n_i_q_u_e_s _a_n_d _t_h_e _r_e_s_u_l_t_i_n_g _h_i_g_h _d_e_g_r_e_e _o_f _a_s_s_u_r_a_n_c_e
  _t_h_a_t _t_h_e _T_C_B _i_s _c_o_r_r_e_c_t_l_y _i_m_p_l_e_m_e_n_t_e_d_.  _T_h_i_s _a_s_s_u_r_a_n_c_e _i_s
  _d_e_v_e_l_o_p_m_e_n_t_a_l _i_n _n_a_t_u_r_e_, _s_t_a_r_t_i_n_g _w_i_t_h _a _f_o_r_m_a_l _m_o_d_e_l _o_f _t_h_e _s_e_c_u_r_i_t_y
  _p_o_l_i_c_y _a_n_d _a _f_o_r_m_a_l _t_o_p_-_l_e_v_e_l _s_p_e_c_i_f_i_c_a_t_i_o_n _(_F_T_L_S_) _o_f _t_h_e _d_e_s_i_g_n_.
  _I_n_d_e_p_e_n_d_e_n_t _o_f _t_h_e _p_a_r_t_i_c_u_l_a_r _s_p_e_c_i_f_i_c_a_t_i_o_n _l_a_n_g_u_a_g_e _o_r _v_e_r_i_f_i_c_a_t_i_o_n
  _s_y_s_t_e_m _u_s_e_d_, _t_h_e_r_e _a_r_e _f_i_v_e _i_m_p_o_r_t_a_n_t _c_r_i_t_e_r_i_a _f_o_r _c_l_a_s_s _(_A_1_) _d_e_s_i_g_n
  _v_e_r_i_f_i_c_a_t_i_o_n_:



  +o  _A _f_o_r_m_a_l _m_o_d_e_l _o_f _t_h_e _s_e_c_u_r_i_t_y _p_o_l_i_c_y _m_u_s_t _b_e _c_l_e_a_r_l_y _i_d_e_n_t_i_f_i_e_d
     _a_n_d _d_o_c_u_m_e_n_t_e_d_, _i_n_c_l_u_d_i_n_g _a _m_a_t_h_e_m_a_t_i_c_a_l _p_r_o_o_f _t_h_a_t _t_h_e _m_o_d_e_l _i_s
     _c_o_n_s_i_s_t_e_n_t _w_i_t_h _i_t_s _a_x_i_o_m_s _a_n_d _i_s _s_u_f_f_i_c_i_e_n_t _t_o _s_u_p_p_o_r_t _t_h_e
     _s_e_c_u_r_i_t_y _p_o_l_i_c_y_.

  +o  _A_n _F_T_L_S _m_u_s_t _b_e _p_r_o_d_u_c_e_d _t_h_a_t _i_n_c_l_u_d_e_s _a_b_s_t_r_a_c_t _d_e_f_i_n_i_t_i_o_n_s _o_f _t_h_e
     _f_u_n_c_t_i_o_n_s _t_h_e _T_C_B _p_e_r_f_o_r_m_s _a_n_d _o_f _t_h_e _h_a_r_d_w_a_r_e _a_n_d_/_o_r _f_i_r_m_w_a_r_e
     _m_e_c_h_a_n_i_s_m_s _t_h_a_t _a_r_e _u_s_e_d _t_o _s_u_p_p_o_r_t _s_e_p_a_r_a_t_e _e_x_e_c_u_t_i_o_n _d_o_m_a_i_n_s_.

  +o  _T_h_e _F_T_L_S _o_f _t_h_e _T_C_B _m_u_s_t _b_e _s_h_o_w_n _t_o _b_e _c_o_n_s_i_s_t_e_n_t _w_i_t_h _t_h_e _m_o_d_e_l
     _b_y _f_o_r_m_a_l _t_e_c_h_n_i_q_u_e_s _w_h_e_r_e _p_o_s_s_i_b_l_e _(_i_._e_._, _w_h_e_r_e _v_e_r_i_f_i_c_a_t_i_o_n _t_o_o_l_s
     _e_x_i_s_t_) _a_n_d _i_n_f_o_r_m_a_l _o_n_e_s _o_t_h_e_r_w_i_s_e_.

  +o  _T_h_e _T_C_B _i_m_p_l_e_m_e_n_t_a_t_i_o_n _(_i_._e_._, _i_n _h_a_r_d_w_a_r_e_, _f_i_r_m_w_a_r_e_, _a_n_d _s_o_f_t_w_a_r_e_)
     _m_u_s_t _b_e _i_n_f_o_r_m_a_l_l_y _s_h_o_w_n _t_o _b_e _c_o_n_s_i_s_t_e_n_t _w_i_t_h _t_h_e _F_T_L_S_.  _T_h_e
     _e_l_e_m_e_n_t_s _o_f _t_h_e _F_T_L_S _m_u_s_t _b_e _s_h_o_w_n_, _u_s_i_n_g _i_n_f_o_r_m_a_l _t_e_c_h_n_i_q_u_e_s_, _t_o
     _c_o_r_r_e_s_p_o_n_d _t_o _t_h_e _e_l_e_m_e_n_t_s _o_f _t_h_e _T_C_B_.  _T_h_e _F_T_L_S _m_u_s_t _e_x_p_r_e_s_s _t_h_e
     _u_n_i_f_i_e_d _p_r_o_t_e_c_t_i_o_n _m_e_c_h_a_n_i_s_m _r_e_q_u_i_r_e_d _t_o _s_a_t_i_s_f_y _t_h_e _s_e_c_u_r_i_t_y
     _p_o_l_i_c_y_, _a_n_d _i_t _i_s _t_h_e _e_l_e_m_e_n_t_s _o_f _t_h_i_s _p_r_o_t_e_c_t_i_o_n _m_e_c_h_a_n_i_s_m _t_h_a_t
     _a_r_e _m_a_p_p_e_d _t_o _t_h_e _e_l_e_m_e_n_t_s _o_f _t_h_e _T_C_B_.

  +o  _F_o_r_m_a_l _a_n_a_l_y_s_i_s _t_e_c_h_n_i_q_u_e_s _m_u_s_t _b_e _u_s_e_d _t_o _i_d_e_n_t_i_f_y _a_n_d _a_n_a_l_y_z_e
     _c_o_v_e_r_t _c_h_a_n_n_e_l_s_.  _I_n_f_o_r_m_a_l _t_e_c_h_n_i_q_u_e_s _m_a_y _b_e _u_s_e_d _t_o _i_d_e_n_t_i_f_y
     _c_o_v_e_r_t _t_i_m_i_n_g _c_h_a_n_n_e_l_s_.  _T_h_e _c_o_n_t_i_n_u_e_d _e_x_i_s_t_e_n_c_e _o_f _i_d_e_n_t_i_f_i_e_d
     _c_o_v_e_r_t _c_h_a_n_n_e_l_s _i_n _t_h_e _s_y_s_t_e_m _m_u_s_t _b_e _j_u_s_t_i_f_i_e_d_.


  _I_n _k_e_e_p_i_n_g _w_i_t_h _t_h_e _e_x_t_e_n_s_i_v_e _d_e_s_i_g_n _a_n_d _d_e_v_e_l_o_p_m_e_n_t _a_n_a_l_y_s_i_s _o_f _t_h_e
  _T_C_B _r_e_q_u_i_r_e_d _o_f _s_y_s_t_e_m_s _i_n _c_l_a_s_s _(_A_1_)_, _m_o_r_e _s_t_r_i_n_g_e_n_t _c_o_n_f_i_g_u_r_a_t_i_o_n
  _m_a_n_a_g_e_m_e_n_t _i_s _r_e_q_u_i_r_e_d _a_n_d _p_r_o_c_e_d_u_r_e_s _a_r_e _e_s_t_a_b_l_i_s_h_e_d _f_o_r _s_e_c_u_r_e_l_y
  _d_i_s_t_r_i_b_u_t_i_n_g _t_h_e _s_y_s_t_e_m _t_o _s_i_t_e_s_.  _A _s_y_s_t_e_m _s_e_c_u_r_i_t_y _a_d_m_i_n_i_s_t_r_a_t_o_r _i_s
  _s_u_p_p_o_r_t_e_d_.


  _T_h_e _f_o_l_l_o_w_i_n_g _a_r_e _m_i_n_i_m_a_l _r_e_q_u_i_r_e_m_e_n_t_s _f_o_r _s_y_s_t_e_m_s _a_s_s_i_g_n_e_d _a _c_l_a_s_s
  _(_A_1_) _r_a_t_i_n_g_:



  44..11..11..  SSeeccuurriittyy PPoolliiccyy

  44..11..11..11..  DDiissccrreettiioonnaarryy AAcccceessss CCoonnttrrooll

  The TCB shall define and control access between named users and named
  objects (e.g., files and programs) in the ADP system.  The enforcement
  mechanism (e.g., access control lists) shall allow users to specify
  and control sharing of those objects, and shall provide controls to
  limit propagation of access rights.  The discretionary access control
  mechanism shall, either by explicit user action or by default, provide
  that objects are protected from unauthorized access.  These access
  controls shall be capable of specifying, for each named object, a list
  of named individuals and a list of groups of named individuals with
  their respective modes of access to that object.  Furthermore, for
  each such named object, it shall be possible to specify a list of
  named individuals and a list of groups of named individuals for which
  no access to the object is to be given.  Access permission to an
  object by users not already possessing access permission shall only be
  assigned by authorized users.


  44..11..11..22..  OObbjjeecctt RReeuussee

  All authorizations to the information contained within a storage
  object shall be revoked prior to initial assignment, allocation or
  reallocation to a subject from the TCB's pool of unused storage
  objects.  No information, including encrypted representations of
  information, produced by a prior subject's actions is to be available
  to any subject that obtains access to an object that has been released
  back to the system.


  44..11..11..33..  LLaabbeellss

  Sensitivity labels associated with each ADP system resource (e.g.,
  subject, storage object, ROM) that is directly or indirectly
  accessible by subjects external to the TCB shall be maintained by the
  TCB.  These labels shall be used as the basis for mandatory access
  control decisions.  In order to import non-labeled data, the TCB shall
  request and receive from an authorized user the security level of the
  data, and all such actions shall be auditable by the TCB.


  44..11..11..33..11..  LLaabbeell IInntteeggrriittyy

  Sensitivity labels shall accurately represent security levels of the
  specific subjects or objects with which they are associated.  When
  exported by the TCB, sensitivity labels shall accurately and
  unambiguously represent the internal labels and shall be associated
  with the information being exported.


  44..11..11..33..22..  EExxppoorrttaattiioonn ooff LLaabbeelleedd IInnffoorrmmaattiioonn

  The TCB shall designate each communication channel and I/O device as
  either single-level or multilevel.  Any change in this designation
  shall be done manually and shall be auditable by the TCB.  The TCB
  shall maintain and be able to audit any change in the security level
  or levels associated with a communication channel or I/O device.


  44..11..11..33..22..11..  EExxppoorrttaattiioonn ttoo MMuullttiilleevveell DDeevviicceess

  When the TCB exports an object to a multilevel I/O device, the
  sensitivity label associated with that object shall also be exported
  and shall reside on the same physical medium as the exported
  information and shall be in the same form (i.e., machine-readable or
  human-readable form).  When the TCB exports or imports an object over
  a multilevel communication channel, the protocol used on that channel
  shall provide for the unambiguous pairing between the sensitivity
  labels and the associated information that is sent or received.


  44..11..11..33..22..22..  EExxppoorrttaattiioonn ttoo SSiinnggllee--LLeevveell DDeevviicceess

  Single-level I/O devices and single-level communication channels are
  not required to maintain the sensitivity labels of the information
  they process.  However, the TCB shall include a mechanism by which the
  TCB and an authorized user reliably communicate to designate the
  single security level of information imported or exported via single-
  level communication channels or I/O devices.


  44..11..11..33..22..33..  LLaabbeelliinngg HHuummaann--RReeaaddaabbllee OOuuttppuutt

  The ADP system administrator shall be able to specify the printable
  label names associated with exported sensitivity labels.  The TCB
  shall mark the beginning and end of all human-readable, paged,
  hardcopy output (e.g., line printer output) with human-readable
  sensitivity labels that properly ``(see footnote above)'' represent
  the sensitivity of the output.  The TCB shall, by default, mark the
  top and bottom of each page of human-readable, paged, hardcopy output
  (e.g., line printer output) with human-readable sensitivity labels
  that properly ``(see footnote above)'' represent the overall
  sensitivity of the output or that properly ``(see footnote above)''
  represent the sensitivity of the information on the page.  The TCB
  shall, by default and in an appropriate manner, mark other forms of
  human-readable output (e.g., maps, graphics) with human-readable
  sensitivity labels that properly ``(see footnote above)'' represent
  the sensitivity of the output.  Any override of these marking defaults
  shall be auditable by the TCB.


  44..11..11..33..33..  SSuubbjjeecctt SSeennssiittiivviittyy LLaabbeellss

  The TCB shall immediately notify a terminal user of each change in the
  security level associated with that user during an interactive
  session.  A terminal user shall be able to query the TCB as desired
  for a display of the subject's complete sensitivity label.


  44..11..11..33..44..  DDeevviiccee LLaabbeellss

  The TCB shall support the assignment of minimum and maximum security
  levels to all attached physical devices.  These security levels shall
  be used by the TCB to enforce constraints imposed by the physical
  environments in which the devices are located.


  44..11..11..44..  MMaannddaattoorryy AAcccceessss CCoonnttrrooll

  The TCB shall enforce a mandatory access control policy over all
  resources (i.e., subjects, storage objects, and I/O devices) that are
  directly or indirectly accessible by subjects external to the TCB.
  These subjects and objects shall be assigned sensitivity labels that
  are a combination of hierarchical classification levels and non-
  hierarchical categories, and the labels shall be used as the basis for
  mandatory access control decisions.  The TCB shall be able to support
  two or more such security levels.  (See the Mandatory Access Control
  guidelines.) The following requirements shall hold for all accesses
  between all subjects external to the TCB and all objects directly or
  indirectly accessible by these subjects: A subject can read an object
  only if the hierarchical classification in the subject's security
  level is greater than or equal to the hierarchical classification in
  the object's security level and the non-hierarchical categories in the
  subject's security level include all the non-hierarchical categories
  in the object's security level.  A subject can write an object only if
  the hierarchical classification in the subject's security level is
  less than or equal to the hierarchical classification in the object's
  security level and all the non-hierarchical categories in the
  subject's security level are included in the non- hierarchical
  categories in the object's security level.  Identification and
  authentication data shall be used by the TCB to authenticate the
  user's identity and to ensure that the security level and authoriza-
  tion of subjects external to the TCB that may be created to act on
  behalf of the individual user are dominated by the clearance and
  authorization of that user.


  44..11..22..  AAccccoouunnttaabbiilliittyy

  44..11..22..11..  IIddeennttiiffiiccaattiioonn aanndd AAuutthheennttiiccaattiioonn

  The TCB shall require users to identify themselves to it before
  beginning to perform any other actions that the TCB is expected to
  mediate.  Furthermore, the TCB shall maintain authentication data that
  includes information for verifying the identity of individual users
  (e.g., passwords) as well as information for determining the clearance
  and authorizations of individual users.  This data shall be used by
  the TCB to authenticate the user's identity and to ensure that the
  security level and authorizations of subjects external to the TCB that
  may be created to act on behalf of the individual user are dominated
  by the clearance and authorization of that user.  The TCB shall
  protect authentication data so that it cannot be accessed by any
  unauthorized user.  The TCB shall be able to enforce individual
  accountability by providing the capability to uniquely identify each
  individual ADP system user.  The TCB shall also provide the capability
  of associating this identity with all auditable actions taken by that
  individual.


  44..11..22..11..11..  TTrruusstteedd PPaatthh

  The TCB shall support a trusted communication path between itself and
  users for use when a positive TCB-to-user connection is required
  (e.g., login, change subject security level).  Communications via this
  trusted path shall be activated exclusively by a user or the TCB and
  shall be logically isolated and unmistakably distinguishable from
  other paths.


  44..11..22..22..  AAuuddiitt

  The TCB shall be able to create, maintain, and protect from
  modification or unauthorized access or destruction an audit trail of
  accesses to the objects it protects.  The audit data shall be
  protected by the TCB so that read access to it is limited to those who
  are authorized for audit data.  The TCB shall be able to record the
  following types of events: use of identification and authentication
  mechanisms, introduction of objects into a user's address space (e.g.,
  file open, program initiation), deletion of objects, and actions taken
  by computer operators and system administrators and/or system security
  officers, and other security relevant events.  The TCB shall also be
  able to audit any override of human-readable output markings.  For
  each recorded event, the audit record shall identify: date and time of
  the event, user, type of event, and success or failure of the event.
  For identification/ authentication events the origin of request (e.g.,
  terminal ID) shall be included in the audit record.  For events that
  introduce an object into a user's address space and for object
  deletion events the audit record shall include the name of the object
  and the object's security level.  The ADP system administrator shall
  be able to selectively audit the actions of any one or more users
  based on individual identity and/or object security level.  The TCB
  shall be able to audit the identified events that may be used in the
  exploitation of covert storage channels.  The TCB shall contain a
  mechanism that is able to monitor the occurrence or accumulation of
  security auditable events that may indicate an imminent violation of
  security policy.  This mechanism shall be able to immediately notify
  the security administrator when thresholds are exceeded, and, if the
  occurrence or accumulation of these security relevant events
  continues, the system shall take the least disruptive action to
  terminate the event.


  44..11..33..  AAssssuurraannccee

  44..11..33..11..  OOppeerraattiioonnaall AAssssuurraannccee

  44..11..33..11..11..  SSyysstteemm AArrcchhiitteeccttuurree

  The TCB shall maintain a domain for its own execution that protects it
  from external interference or tampering (e.g., by modification of its
  code or data structures).  The TCB shall maintain process isolation
  through the provision of distinct address spaces under its control.
  The TCB shall be internally structured into well-defined largely
  independent modules.  It shall make effective use of available
  hardware to separate those elements that are protection-critical from
  those that are not.  The TCB modules shall be designed such that the
  principle of least privilege is enforced.  Features in hardware, such
  as segmentation, shall be used to support logically distinct storage
  objects with separate attributes (namely: readable, writeable).  The
  user interface to the TCB shall be completely defined and all elements
  of the TCB identified.  The TCB shall be designed and structured to
  use a complete, conceptually simple protection mechanism with
  precisely defined semantics.  This mechanism shall play a central role
  in enforcing the internal structuring of the TCB and the system.  The
  TCB shall incorporate significant use of layering, abstraction and
  data hiding.  Significant system engineering shall be directed toward
  minimizing the complexity of the TCB and excluding from the TCB
  modules that are not protection-critical.


  44..11..33..11..22..  SSyysstteemm IInntteeggrriittyy

  Hardware and/or software features shall be provided that can be used
  to periodically validate the correct operation of the on-site hardware
  and firmware elements of the TCB.


  44..11..33..11..33..  CCoovveerrtt CChhaannnneell AAnnaallyyssiiss

  The system developer shall conduct a thorough search for covert
  channels and make a determination (either by actual measurement or by
  engineering estimation) of the maximum bandwidth of each identified
  channel.  (See the Covert Channels Guideline section.)  FFoorrmmaall mmeetthhooddss
  sshhaallll bbee uusseedd iinn tthhee aannaallyyssiiss..


  44..11..33..11..44..  TTrruusstteedd FFaacciilliittyy MMaannaaggeemmeenntt

  The TCB shall support separate operator and administrator functions.
  The functions performed in the role of a security administrator shall
  be identified.  The ADP system administrative personnel shall only be
  able to perform security administrator functions after taking a
  distinct auditable action to assume the security administrator role on
  the ADP system.  Non-security functions that can be performed in the
  security administration role shall be limited strictly to those
  essential to performing the security role effectively.


  44..11..33..11..55..  TTrruusstteedd RReeccoovveerryy

  Procedures and/or mechanisms shall be provided to assure that, after
  an ADP system failure or other discontinuity, recovery without a
  protection compromise is obtained.


  44..11..33..22..  LLiiffee--CCyyccllee AAssssuurraannccee

  44..11..33..22..11..  SSeeccuurriittyy TTeessttiinngg

  The security mechanisms of the ADP system shall be tested and found to
  work as claimed in the system documentation.  A team of individuals
  who thoroughly understand the specific implementation of the TCB shall
  subject its design documentation, source code, and object code to
  thorough analysis and testing.  Their objectives shall be: to uncover
  all design and implementation flaws that would permit a subject
  external to the TCB to read, change, or delete data normally denied
  under the mandatory or discretionary security policy enforced by the
  TCB; as well as to assure that no subject (without authorization to do
  so) is able to cause the TCB to enter a state such that it is unable
  to respond to communications initiated by other users.  The TCB shall
  be found resistant to penetration.  All discovered flaws shall be
  corrected and the TCB retested to demonstrate that they have been
  eliminated and that new flaws have not been introduced.  Testing shall
  demonstrate that the TCB implementation is consistent with the formal
  top- level specification.  (See the Security Testing Guidelines.)  No
  design flaws and no more than a few correctable implementation flaws
  may be found during testing and there shall be reasonable confidence
  that few remain.  MMaannuuaall oorr ootthheerr mmaappppiinngg ooff tthhee FFTTLLSS ttoo tthhee ssoouurrccee
  ccooddee mmaayy ffoorrmm aa bbaassiiss ffoorr ppeenneettrraattiioonn tteessttiinngg..


  44..11..33..22..22..  DDeessiiggnn SSppeecciiffiiccaattiioonn aanndd VVeerriiffiiccaattiioonn

  A formal model of the security policy supported by the TCB shall be
  maintained over the life-cycle of the ADP system that is proven
  consistent with its axioms.  A descriptive top-level specification
  (DTLS) of the TCB shall be maintained that completely and accurately
  describes the TCB in terms of exceptions, error messages, and effects.
  AA ffoorrmmaall ttoopp--lleevveell ssppeecciiffiiccaattiioonn ((FFTTLLSS)) ooff tthhee TTCCBB sshhaallll bbee mmaaiinnttaaiinneedd
  tthhaatt aaccccuurraatteellyy ddeessccrriibbeess tthhee TTCCBB iinn tteerrmmss ooff eexxcceeppttiioonnss,, eerrrroorr
  mmeessssaaggeess,, aanndd eeffffeeccttss..  TThhee DDTTLLSS aanndd FFTTLLSS sshhaallll iinncclluuddee tthhoossee
  ccoommppoonneennttss ooff tthhee TTCCBB tthhaatt aarree iimmpplleemmeenntteedd aass hhaarrddwwaarree aanndd//oorr ffiirrmmwwaarree
  iiff tthheeiirr pprrooppeerrttiieess aarree vviissiibbllee aatt tthhee TTCCBB iinntteerrffaaccee..  TThhee FFTTLLSS shall
  be shown to be an accurate description of the TCB interface.  A
  convincing argument shall be given that the DTLS is consistent with
  the model aanndd aa ccoommbbiinnaattiioonn ooff ffoorrmmaall aanndd iinnffoorrmmaall tteecchhnniiqquueess sshhaallll bbee
  uusseedd ttoo sshhooww tthhaatt tthhee FFTTLLSS iiss ccoonnssiisstteenntt wwiitthh tthhee mmooddeell..  TThhiiss
  vveerriiffiiccaattiioonn eevviiddeennccee sshhaallll bbee ccoonnssiisstteenntt wwiitthh tthhaatt pprroovviiddeedd wwiitthhiinn
  tthhee ssttaattee--ooff--tthhee--aarrtt ooff tthhee ppaarrttiiccuullaarr ccoommppuutteerr sseeccuurriittyy cceenntteerr--
  eennddoorrsseedd ffoorrmmaall ssppeecciiffiiccaattiioonn aanndd vveerriiffiiccaattiioonn ssyysstteemm uusseedd..  MMaannuuaall oorr
  ootthheerr mmaappppiinngg ooff tthhee FFTTLLSS ttoo tthhee TTCCBB ssoouurrccee ccooddee sshhaallll bbee ppeerrffoorrmmeedd ttoo
  pprroovviiddee eevviiddeennccee ooff ccoorrrreecctt iimmpplleemmeennttaattiioonn..


  44..11..33..22..33..  CCoonnffiigguurraattiioonn MMaannaaggeemmeenntt

  During tthhee eennttiirree lliiffee--ccyyccllee,, ii..ee..,, dduurriinngg tthhee ddeessiiggnn,, ddeevveellooppmmeenntt,,
  and maintenance of the TCB, a configuration management system shall be
  in place ffoorr aallll sseeccuurriittyy-- rreelleevvaanntt hhaarrddwwaarree,, ffiirrmmwwaarree,, aanndd ssooffttwwaarree
  that maintains control of changes to tthhee ffoorrmmaall mmooddeell,, the descriptive
  aanndd ffoorrmmaall top-level ssppeecciiffiiccaattiioonnss, other design data, implementation
  documentation, source code, the running version of the object code,
  and test fixtures and documentation.  The configuration management
  system shall assure a consistent mapping among all documentation and
  code associated with the current version of the TCB.  Tools shall be
  provided for generation of a new version of the TCB from source code.
  Also available shall be tools, mmaaiinnttaaiinneedd uunnddeerr ssttrriicctt ccoonnffiigguurraattiioonn
  ccoonnttrrooll,, for comparing a newly generated version with the previous TCB
  version in order to ascertain that only the intended changes have been
  made in the code that will actually be used as the new version of the
  TCB.  AA ccoommbbiinnaattiioonn ooff tteecchhnniiccaall,, pphhyyssiiccaall,, aanndd pprroocceedduurraall ssaaffeegguuaarrddss
  sshhaallll bbee uusseedd ttoo pprrootteecctt ffrroomm uunnaauutthhoorriizzeedd mmooddiiffiiccaattiioonn oorr ddeessttrruuccttiioonn
  tthhee mmaasstteerr ccooppyy oorr ccooppiieess ooff aallll mmaatteerriiaall uusseedd ttoo ggeenneerraattee tthhee TTCCBB..


  44..11..33..22..44..  TTrruusstteedd DDiissttrriibbuuttiioonn

  AA ttrruusstteedd AADDPP ssyysstteemm ccoonnttrrooll aanndd ddiissttrriibbuuttiioonn ffaacciilliittyy sshhaallll bbee
  pprroovviiddeedd ffoorr mmaaiinnttaaiinniinngg tthhee iinntteeggrriittyy ooff tthhee mmaappppiinngg bbeettwweeeenn tthhee
  mmaasstteerr ddaattaa ddeessccrriibbiinngg tthhee ccuurrrreenntt vveerrssiioonn ooff tthhee TTCCBB aanndd tthhee oonn--ssiittee
  mmaasstteerr ccooppyy ooff tthhee ccooddee ffoorr tthhee ccuurrrreenntt vveerrssiioonn..  PPrroocceedduurreess ((ee..gg..,,
  ssiittee sseeccuurriittyy aacccceeppttaannccee tteessttiinngg)) sshhaallll eexxiisstt ffoorr aassssuurriinngg tthhaatt tthhee
  TTCCbb ssooffttwwaarree,, ffiirrmmwwaarree,, aanndd hhaarrddwwaarree uuppddaatteess ddiissttrriibbuutteedd ttoo aa ccuussttoommeerr
  aarree eexxaaccttllyy aass ssppeecciiffiieedd bbyy tthhee mmaasstteerr ccooppiieess..


  44..11..44..  DDooccuummeennttaattiioonn

  44..11..44..11..  SSeeccuurriittyy FFeeaattuurreess UUsseerr''ss GGuuiiddee

  A single summary, chapter, or manual in user documentation shall
  describe the protection mechanisms provided by the TCB, guidelines on
  their use, and how they interact with one another.


  44..11..44..22..  TTrruusstteedd FFaacciilliittyy MMaannuuaall

  A manual addressed to the ADP system administrator shall present
  cautions about functions and privileges that should be controlled when
  running a secure facility.  The procedures for examining and
  maintaining the audit files as well as the detailed audit record
  structure for each type of audit event shall be given.  The manual
  shall describe the operator and administrator functions related to
  security, to include changing the security characteristics of a user.
  It shall provide guidelines on the consistent and effective use of the
  protection features of the system, how they interact, how to securely
  generate a new TCB, and facility procedures, warnings, and privileges
  that need to be controlled in order to operate the facility in a
  secure manner.  The TCB modules that contain the reference validation
  mechanism shall be identified.  The procedures for secure generation
  of a new TCB from source after modification of any modules in the TCB
  shall be described.  It shall include the procedures to ensure that
  the system is initially started in a secure manner.  Procedures shall
  also be included to resume secure system operation after any lapse in
  system operation.


  44..11..44..33..  TTeesstt DDooccuummeennttaattiioonn

  The system developer shall provide to the evaluators a document that
  describes the test plan, test procedures that show how the security
  mechanisms were tested, and results of the security mechanisms'
  functional testing.  It shall include results of testing the
  effectiveness of the methods used to reduce covert channel bandwidths.
  TThhee rreessuullttss ooff tthhee mmaappppiinngg bbeettwweeeenn tthhee ffoorrmmaall ttoopp--lleevveell ssppeecciiffiiccaattiioonn
  aanndd tthhee TTCCBB ssoouurrccee ccooddee sshhaallll bbee ggiivveenn..


  44..11..44..44..  DDeessiiggnn DDooccuummeennttaattiioonn

  Documentation shall be available that provides a description of the
  manufacturer's philosophy of protection and an explanation of how this
  philosophy is translated into the TCB.  The interfaces between the TCB
  modules shall be described.  A formal description of the security
  policy model enforced by the TCB shall be available and proven that it
  is sufficient to enforce the security policy.  The specific TCB
  protection mechanisms shall be identified and an explanation given to
  show that they satisfy the model.  The descriptive top-level speci-
  fication (DTLS) shall be shown to be an accurate description of the
  TCB interface.  Documentation shall describe how the TCB implements
  the reference monitor concept and give an explana- tion why it is
  tamper resistant, cannot be bypassed, and is correctly implemented.
  The TCB implementation (i.e., in hardware, firmware, and software)
  shall be informally shown to be consistent with the ffoorrmmaall ttoopp--lleevveell
  ssppeecciiffiiccaattiioonn ((FFTTLLSS))..  The elements of the FFTTLLSS shall be shown, using
  informal techniques, to correspond to the elements of the TCB.
  Documentation shall describe how the TCB is structured to facilitate
  testing and to enforce least privilege.  This documentation shall also
  present the results of the covert channel analysis and the tradeoffs
  involved in restricting the channels.  All auditable events that may
  be used in the exploitation of known covert storage channels shall be
  identified.  The bandwidths of known covert storage channels, the use
  of which is not detectable by the auditing mechanisms, shall be
  provided.  (See the Covert Channel Guideline section.)  HHaarrddwwaarree,,
  ffiirrmmwwaarree,, aanndd ssooffttwwaarree mmeecchhaanniissmmss nnoott ddeeaalltt wwiitthh iinn tthhee FFTTLLSS bbuutt
  ssttrriiccttllyy iinntteerrnnaall ttoo tthhee TTCCBB ((ee..gg..,, mmaappppiinngg rreeggiisstteerrss,, ddiirreecctt mmeemmoorryy
  aacccceessss II//OO)) sshhaallll bbee cclleeaarrllyy ddeessccrriibbeedd..


  44..22..  BBEEYYOONNDD CCLLAASSSS ((AA11))

  Most of the security enhancements envisioned for systems that will
  provide features and assurance in addition to that already provided by
  class (Al) systems are beyond current technology.  The discussion
  below is intended to guide future work and is derived from research
  and development activities already underway in both the public and
  private sectors.  As more and better analysis techniques are
  developed, the requirements for these systems will become more
  explicit.  In the future, use of formal verification will be extended
  to the source level and covert timing channels will be more fully
  addressed.  At this level the design environment will become important
  and testing will be aided by analysis of the formal top-level
  specification.  Consideration will be given to the correctness of the
  tools used in TCB development (e.g., compilers, assemblers, loaders)
  and to the correct functioning of the hardware/firmware on which the
  TCB will run.  Areas to be addressed by systems beyond class (A1)
  include:



  +o  SSyysstteemm AArrcchhiitteeccttuurree


     A demonstration (formal or otherwise) must be given showing that
     requirements of self-protection and completeness for reference
     monitors have been implemented in the TCB.


  +o  SSeeccuurriittyy TTeessttiinngg

     Although beyond the current state-of-the-art, it is envisioned that
     some test-case generation will be done automatically from the
     formal top-level specification or formal lower-level
     specifications.


  +o  FFoorrmmaall SSppeecciiffiiccaattiioonn aanndd VVeerriiffiiccaattiioonn


     The TCB must be verified down to the source code level, using
     formal verification methods where feasible.  Formal verification of
     the source code of the security-relevant portions of an operating
     system has proven to be a difficult task.  Two important
     considerations are the choice of a high-level language whose
     semantics can be fully and formally expressed, and a careful
     mapping, through successive stages, of the abstract formal design
     to a formalization of the implementation in low-level
     specifications.    Experience has shown that only when the lowest
     level specifications closely correspond to the actual code can code
     proofs be successfully accomplished.


  +o  TTrruusstteedd DDeessiiggnn EEnnvviirroonnmmeenntt


     The TCB must be designed in a trusted facility with only trusted
     (cleared) personnel.







































  55..  CCOONNTTRROOLL OOBBJJEECCTTIIVVEESS FFOORR TTRRUUSSTTEEDD CCOOMMPPUUTTEERR SSYYSSTTEEMMSS

  The criteria are divided within each class into groups of
  requirements.  These groupings were developed to assure that three
  basic control objectives for computer security are satisfied and not
  overlooked.  These control objectives deal with:



  +o  Security Policy

  +o  Accountability

  +o  Assurance


  This section provides a discussion of these general control objectives
  and their implication in terms of designing trusted systems.



  55..11..  AA NNEEEEDD FFOORR CCOONNSSEENNSSUUSS

  A major goal of the DoD Computer Security Center is to encourage the
  Computer Industry to develop trusted computer systems and products,
  making them widely available in the commercial market place.
  Achievement of this goal will require recognition and articulation by
  both the public and private sectors of a need and demand for such
  products.


  As described in the introduction to this document, efforts to define
  the problems and develop solutions associated with processing
  nationally sensitive information, as well as other sensitive data such
  as financial, medical, and personnel information used by the National
  Security Establishment, have been underway for a number of years.  The
  criteria, as described in Part I, represent the culmination of these
  efforts and describe basic requirements for building trusted computer
  systems.  To date, however, these systems have been viewed by many as
  only satisfying National Security needs.  As long as this perception
  continues the consensus needed to motivate manufacture of trusted
  systems will be lacking.


  The purpose of this section is to describe in detail the fundamental
  control objectives.  These objectives lay the foundation for the
  requirements outlined in the criteria.  The goal is to explain the
  foundations so that those outside the National Security Establishment
  can assess their universality and, by extension, the universal
  applicability of the criteria requirements to processing all types of
  sensitive applications whether they be for National Security or the
  private sector.


  55..22..  DDEEFFIINNIITTIIOONN AANNDD UUSSEEFFUULLNNEESSSS

  The term _c_o_n_t_r_o_l _o_b_j_e_c_t_i_v_e refers to a statement of intent with
  respect to control over some aspect of an organization's resources, or
  processes, or both.  In terms of a computer system, control objectives
  provide a framework for developing a strategy for fulfilling a set of
  security requirements for any given system.  Developed in response to
  generic vulnerabilities, such as the need to manage and handle
  sensitive data in order to prevent compromise, or the need to provide
  accountability in order to detect fraud, control objectives have been
  identified as a useful method of expressing security goals.  [3]

  Examples of control objectives include the three basic design
  requirements for implementing the reference monitor concept discussed
  in Section 6.  They are:



  +o  The reference validation mechanism must be tamperproof.

  +o  The reference validation mechanism must _a_l_w_a_y_s be invoked.

  +o  The reference validation mechanism must be small enough to be
     subjected to analysis and tests, the completeness of which can be
     assured.  [1]



  55..33..  CCRRIITTEERRIIAA CCOONNTTRROOLL OOBBJJEECCTTIIVVEESS

  The three basic control objectives of the criteria are concerned with
  security policy, accountability, and assurance.  The remainder of this
  section provides a discussion of these basic requirements.


  55..33..11..  SSeeccuurriittyy PPoolliiccyy

  In the most general sense, computer security is concerned with
  controlling the way in which a computer can be used, i.e., controlling
  how information processed by it can be accessed and manipulated.
  However, at closer examination, computer security can refer to a
  number of areas.  Symptomatic of this, FIPS PUB 39, _G_l_o_s_s_a_r_y _F_o_r
  _C_o_m_p_u_t_e_r _S_y_s_t_e_m_s _S_e_c_u_r_i_t_y, does not have a unique definition for
  computer security.  [20] Instead there are eleven separate definitions
  for security which include: ADP systems security, administrative
  security, data security, etc.  A common thread running through these
  definitions is the word "protection."  Further declarations of
  protection requirements can be found in DoD Directive 5200.28 which
  describes an acceptable level of protection for classified data to be
  one that will "assure that systems which process, store, or use
  classified data and produce classified information will, with
  reasonable dependability, prevent: a. Deliberate or inadvertent access
  to classified material by unauthorized persons, and b.  Unauthorized
  manipulation of the computer and its associated peripheral devices."
  [11]



  In summary, protection requirements must be defined in terms of the
  perceived threats, risks, and goals of an organization.  This is often
  stated in terms of a security policy.  It has been pointed out in the
  literature that it is external laws, rules, regulations, etc.  that
  establish what access to information is to be permitted, independent
  of the use of a computer.  In particular, a given system can only be
  said to be secure with respect to its enforcement of some specific
  policy.  [30] Thus, the control objective for security policy is:


  SSEECCUURRIITTYY PPOOLLIICCYY CCOONNTTRROOLL OOBBJJEECCTTIIVVEE


  AA ssttaatteemmeenntt ooff iinntteenntt wwiitthh rreeggaarrdd ttoo ccoonnttrrooll oovveerr aacccceessss ttoo aanndd
  ddiisssseemmiinnaattiioonn ooff iinnffoorrmmaattiioonn,, ttoo bbee kknnoowwnn aass tthhee sseeccuurriittyy ppoolliiccyy mmuusstt
  bbee pprreecciisseellyy ddeeffiinneedd aanndd iimmpplleemmeenntteedd ffoorr eeaacchh ssyysstteemm tthhaatt iiss uusseedd ttoo
  pprroocceessss sseennssiittiivvee iinnffoorrmmaattiioonn..  TThhee sseeccuurriittyy ppoolliiccyy mmuusstt aaccccuurraatteellyy
  rreefflleecctt tthhee llaawwss,, rreegguullaattiioonnss,, aanndd ggeenneerraall ppoolliicciieess ffrroomm wwhhiicchh iitt iiss
  ddeerriivveedd..

  55..33..11..11..  MMaannddaattoorryy SSeeccuurriittyy PPoolliiccyy

  Where a security policy is developed that is to be applied to control
  of classified or other specifically designated sensitive information,
  the policy must include detailed rules on how to handle that
  information throughout its life-cycle.  These rules are a function of
  the various sensitivity designations that the information can assume
  and the various forms of access supported by the system.  Mandatory
  security refers to the enforcement of a set of access control rules
  that constrains a subject's access to information on the basis of a
  comparison of that individual's clearance/authorization to the
  information, the classification/sensitivity designation of the
  information, and the form of access being mediated.  Mandatory
  policies either require or can be satisfied by systems that can
  enforce a partial ordering of designations, namely, the designations
  must form what is mathematically known as a _l_a_t_t_i_c_e [7]



  A clear implication of the above is that the system must assure that
  the designations associated with sensitive data cannot be arbitrarily
  changed, since this could permit individuals who lack the appropriate
  authorization to access sensitive information.  Also implied is the
  requirement that the system control the flow of information so that
  data cannot be stored with lower sensitivity designations unless its
  "downgrading" has been authorized.  The control objective is:


  MMAANNDDAATTOORRYY SSEECCUURRIITTYY CCOONNTTRROOLL OOBBJJEECCTTIIVVEE


  SSeeccuurriittyy ppoolliicciieess ddeeffiinneedd ffoorr ssyysstteemmss tthhaatt aarree uusseedd ttoo pprroocceessss
  ccllaassssiiffiieedd oorr ootthheerr ssppeecciiffiiccaallllyy ccaatteeggoorriizzeedd sseennssiittiivvee iinnffoorrmmaattiioonn
  mmuusstt iinncclluuddee pprroovviissiioonnss ffoorr tthhee eennffoorrcceemmeenntt ooff mmaannddaattoorryy aacccceessss
  ccoonnttrrooll rruulleess..  TThhaatt iiss,, tthheeyy mmuusstt iinncclluuddee aa sseett ooff rruulleess ffoorr
  ccoonnttrroolllliinngg aacccceessss bbaasseedd ddiirreeccttllyy oonn aa ccoommppaarriissoonn ooff tthhee iinnddiivviidduuaall''ss
  cclleeaarraannccee oorr aauutthhoorriizzaattiioonn ffoorr tthhee iinnffoorrmmaattiioonn aanndd tthhee ccllaassssiiffiiccaattiioonn
  oorr sseennssiittiivviittyy ddeessiiggnnaattiioonn ooff tthhee iinnffoorrmmaattiioonn bbeeiinngg ssoouugghhtt,, aanndd
  iinnddiirreeccttllyy oonn ccoonnssiiddeerraattiioonnss ooff pphhyyssiiccaall aanndd ootthheerr eennvviirroonnmmeennttaall
  ffaaccttoorrss ooff ccoonnttrrooll..  TThhee mmaannddaattoorryy aacccceessss ccoonnttrrooll rruulleess mmuusstt
  aaccccuurraatteellyy rreefflleecctt tthhee llaawwss,, rreegguullaattiioonnss,, aanndd ggeenneerraall ppoolliicciieess ffrroomm
  wwhhiicchh tthheeyy aarree ddeerriivveedd..


  55..33..11..22..  DDiissccrreettiioonnaarryy SSeeccuurriittyy PPoolliiccyy

  Discretionary security is the principal type of access control
  available in computer systems today.  The basis of this kind of
  security is that an individual user, or program operating on his
  behalf, is allowed to specify explicitly the types of access other
  users may have to information under his control.  Discretionary
  security differs from mandatory security in that it implements an
  access control policy on the basis of an individual's need-to-know as
  opposed to mandatory controls which are driven by the classification
  or sensitivity designation of the information.


  Discretionary controls are not a replacement for mandatory controls.
  In an environment in which information is classified (as in the DoD)
  discretionary security provides for a finer granularity of control
  within the overall constraints of the mandatory policy.  Access to
  classified information requires effective implementation of both types
  of controls as precondition to granting that access.  In general, no
  person may have access to classified information unless: (a) that
  person has been determined to be trustworthy, i.e., granted a
  personnel security clearance -- MANDATORY, and (b) access is necessary
  for the performance of official duties, i.e., determined to have a
  need-to-know -- DISCRETIONARY.  In other words, discretionary controls
  give individuals discretion to decide on which of the permissible
  accesses will actually be allowed to which users, consistent with
  overriding mandatory policy restrictions.  The control objective is:


  DDIISSCCRREETTIIOONNAARRYY SSEECCUURRIITTYY CCOONNTTRROOLL OOBBJJEECCTTIIVVEE


  SSeeccuurriittyy ppoolliicciieess ddeeffiinneedd ffoorr ssyysstteemmss tthhaatt aarree uusseedd ttoo pprroocceessss
  ccllaassssiiffiieedd oorr ootthheerr sseennssiittiivvee iinnffoorrmmaattiioonn mmuusstt iinncclluuddee pprroovviissiioonnss ffoorr
  tthhee eennffoorrcceemmeenntt ooff ddiissccrreettiioonnaarryy aacccceessss ccoonnttrrooll rruulleess..  TThhaatt iiss,, tthheeyy
  mmuusstt iinncclluuddee aa ccoonnssiisstteenntt sseett ooff rruulleess ffoorr ccoonnttrroolllliinngg aanndd lliimmiittiinngg
  aacccceessss bbaasseedd oonn iiddeennttiiffiieedd iinnddiivviidduuaallss wwhhoo hhaavvee bbeeeenn ddeetteerrmmiinneedd ttoo
  hhaavvee aa nneeeedd--ttoo--kknnooww ffoorr tthhee iinnffoorrmmaattiioonn..


  55..33..11..33..  MMaarrkkiinngg

  To implement a set of mechanisms that will put into effect a mandatory
  security policy, it is necessary that the system mark information with
  appropriate classification or sensitivity labels and maintain these
  markings as the information moves through the system.  Once
  information is unalterably and accurately marked, comparisons required
  by the mandatory access control rules can be accurately and
  consistently made.  An additional benefit of having the system
  maintain the classification or sensitivity label internally is the
  ability to automatically generate properly "labeled" output.  The
  labels, if accurately and integrally maintained by the system, remain
  accurate when output from the system.  The control objective is:


  MMAARRKKIINNGG CCOONNTTRROOLL OOBBJJEECCTTIIVVEE


  SSyysstteemmss tthhaatt aarree ddeessiiggnneedd ttoo eennffoorrccee aa mmaannddaattoorryy sseeccuurriittyy ppoolliiccyy mmuusstt
  ssttoorree aanndd pprreesseerrvvee tthhee iinntteeggrriittyy ooff ccllaassssiiffiiccaattiioonn oorr ootthheerr
  sseennssiittiivviittyy llaabbeellss ffoorr aallll iinnffoorrmmaattiioonn..  LLaabbeellss eexxppoorrtteedd ffrroomm tthhee
  ssyysstteemm mmuusstt bbee aaccccuurraattee rreepprreesseennttaattiioonnss ooff tthhee ccoorrrreessppoonnddiinngg iinntteerrnnaall
  sseennssiittiivviittyy llaabbeellss bbeeiinngg eexxppoorrtteedd..


  55..33..22..  AAccccoouunnttaabbiilliittyy

  The second basic control objective addresses one of the fundamental
  principles of security, i.e., individual accountability.  Individual
  accountability is the key to securing and controlling any system that
  processes information on behalf of individuals or groups of
  individuals.  A number of requirements must be met in order to satisfy
  this objective.


  The first requirement is for individual user identification.  Second,
  there is a need for authentication of the identification.
  Identification is functionally dependent on authentication.  Without
  authentication, user identification has no credibility.  Without a
  credible identity, neither mandatory nor discretionary security
  policies can be properly invoked because there is no assurance that
  proper authorizations can be made.


  The third requirement is for dependable audit capabilities.  That is,
  a trusted computer system must provide authorized personnel with the
  ability to audit any action that can potentially cause access to,
  generation of, or effect the release of classified or sensitive
  information.  The audit data will be selectively acquired based on the
  auditing needs of a particular installation and/or application.
  However, there must be sufficient granularity in the audit data to
  support tracing the auditable events to a specific individual who has
  taken the actions or on whose behalf the actions were taken.  The
  control objective is:


  AACCCCOOUUNNTTAABBIILLIITTYY CCOONNTTRROOLL OOBBJJEECCTTIIVVEE


  SSyysstteemmss tthhaatt aarree uusseedd ttoo pprroocceessss oorr hhaannddllee ccllaassssiiffiieedd oorr ootthheerr
  sseennssiittiivvee iinnffoorrmmaattiioonn mmuusstt aassssuurree iinnddiivviidduuaall aaccccoouunnttaabbiilliittyy wwhheenneevveerr
  eeiitthheerr aa mmaannddaattoorryy oorr ddiissccrreettiioonnaarryy sseeccuurriittyy ppoolliiccyy iiss iinnvvookkeedd..
  FFuurrtthheerrmmoorree,, ttoo aassssuurree aaccccoouunnttaabbiilliittyy,, tthhee ccaappaabbiilliittyy mmuusstt eexxiisstt ffoorr
  aann aauutthhoorriizzeedd aanndd ccoommppeetteenntt aaggeenntt ttoo aacccceessss aanndd eevvaalluuaattee
  aaccccoouunnttaabbiilliittyy iinnffoorrmmaattiioonn bbyy aa sseeccuurree mmeeaannss,, wwiitthhiinn aa rreeaassoonnaabbllee
  aammoouunntt ooff ttiimmee,, aanndd wwiitthhoouutt uunndduuee ddiiffffiiccuullttyy..


  55..33..33..  AAssssuurraannccee

  The third basic control objective is concerned with guaranteeing or
  providing confidence that the security policy has been implemented
  correctly and that the protection-relevant elements of the system do,
  indeed, accurately mediate and enforce the intent of that policy.  By
  extension, assurance must include a guarantee that the trusted portion
  of the system works only as intended.  To accomplish these objectives,
  two types of assurance are needed.  They are life-cycle assurance and
  operational assurance.


  Life-cycle assurance refers to steps taken by an organization to
  ensure that the system is designed, developed, and maintained using
  formalized and rigorous controls and standards.  [21]

  Computer systems that process and store sensitive or classified
  information depend on the hardware and software to protect that
  information.  It follows that the hardware and software themselves
  must be protected against unauthorized changes that could cause
  protection mechanisms to malfunction or be bypassed completely.  For
  this reason trusted computer systems must be carefully evaluated and
  tested during the design and development phases and reevaluated
  whenever changes are made that could affect the integrity of the
  protection mechanisms.  Only in this way can confidence be provided
  that the hardware and software interpretation of the security policy
  is maintained accurately and without distortion.


  While life-cycle assurance is concerned with procedures for managing
  system design, development, and maintenance; operational assurance
  focuses on features and system architecture used to ensure that the
  security policy is uncircumventably enforced during system operation.
  That is, the security policy must be integrated into the hardware and
  software protection features of the system.  Examples of steps taken
  to provide this kind of confidence include: methods for testing the
  operational hardware and software for correct operation, isolation of
  protection- critical code, and the use of hardware and software to
  provide distinct domains.  The control objective is:


  AASSSSUURRAANNCCEE CCOONNTTRROOLL OOBBJJEECCTTIIVVEE


  SSyysstteemmss tthhaatt aarree uusseedd ttoo pprroocceessss oorr hhaannddllee ccllaassssiiffiieedd oorr ootthheerr
  sseennssiittiivvee iinnffoorrmmaattiioonn mmuusstt bbee ddeessiiggnneedd ttoo gguuaarraanntteeee ccoorrrreecctt aanndd
  aaccccuurraattee iinntteerrpprreettaattiioonn ooff tthhee sseeccuurriittyy ppoolliiccyy aanndd mmuusstt nnoott ddiissttoorrtt
  tthhee iinntteenntt ooff tthhaatt ppoolliiccyy..  AAssssuurraannccee mmuusstt bbee pprroovviiddeedd tthhaatt ccoorrrreecctt
  iimmpplleemmeennttaattiioonn aanndd ooppeerraattiioonn ooff tthhee ppoolliiccyy eexxiissttss tthhrroouugghhoouutt tthhee
  ssyysstteemm''ss lliiffee--ccyyccllee..






























































  66..  RRAATTIIOONNAALLEE BBEEHHIINNDD TTHHEE EEVVAALLUUAATTIIOONN CCLLAASSSSEESS

  66..11..  TTHHEE RREEFFEERREENNCCEE MMOONNIITTOORR CCOONNCCEEPPTT

  In October of 1972, the Computer Security Technology Planning Study,
  conducted by James P.  Anderson & Co., produced a report for the
  Electronic Systems Division (ESD) of the United States Air Force.  [1]

  In that report, the concept of "a rreeffeerreennccee mmoonniittoorr which enforces the
  authorized access relationships between subjects and objects of a
  system" was introduced.  The reference monitor concept was found to be
  an essential element of any system that would provide multilevel
  secure computing facilities and controls.


  The Anderson report went on to define the _r_e_f_e_r_e_n_c_e _v_a_l_i_d_a_t_i_o_n
  _m_e_c_h_a_n_i_s_m as "an implementation of the reference monitor concept .  .
  .  that validates each reference to data or programs by any user
  (program) against a list of authorized types of reference for that
  user." It then listed the three design requirements that must be met
  by a reference validation mechanism: [1]



  +o  a. The reference validation mechanism must be tamper proof.

  +o  b. The reference validation mechanism must always be invoked.

  +o  c. The reference validation mechanism must be small enough to be
     subject to analysis and tests, the completeness of which can be
     assured.


  Extensive peer review and continuing research and development
  activities have sustained the validity of the Anderson Committee's
  findings.  Early examples of the reference validation mechanism were
  known as _s_e_c_u_r_i_t_y _k_e_r_n_e_l_s.  The Anderson Report described the security
  kernel as "that combination of hardware and software which implements
  the reference monitor concept."  [1] In this vein, it will be noted
  that the security kernel must support the three reference monitor
  requirements listed above.


  66..22..  AA FFOORRMMAALL SSEECCUURRIITTYY PPOOLLIICCYY MMOODDEELL

  Following the publication of the Anderson report, considerable
  research was initiated into formal models of security policy
  requirements and of the mechanisms that would implement and enforce
  those policy models as a security kernel.  Prominent among these
  efforts was the ESD-sponsored development of the Bell and LaPadula
  model, an abstract formal treatment of DoD security policy.  [2] Using
  mathematics and set theory, the model precisely defines the notion of
  secure state, fundamental modes of access, and the rules for granting
  subjects specific modes of access to objects.  Finally, a theorem is
  proven to demonstrate that the rules are security-preserving
  operations, so that the application of any sequence of the rules to a
  system that is in a secure state will result in the system entering a
  new state that is also secure.  This theorem is known as the Basic
  Security Theorem.


  A subject can act on behalf of a user or another subject.  The subject
  is created as a surrogate for the cleared user and is assigned a
  formal security level based on their classification.  The state
  transitions and invariants of the formal policy model define the
  invariant relationships that must hold between the clearance of the
  user, the formal security level of any process that can act on the
  user's behalf, and the formal security level of the devices and other
  objects to which any process can obtain specific modes of access.  The
  Bell and LaPadula model, for example, defines a relationship between
  formal security levels of subjects and objects, now referenced as the
  _d_o_m_i_n_a_n_c_e _r_e_l_a_t_i_o_n.  From this definition, accesses permitted between
  subjects and objects are explicitly defined for the fundamental modes
  of access, including read-only access, read/write access, and write-
  only access.  The model defines the Simple Security Condition to
  control granting a subject read access to a specific object, and the
  *-Property (read "Star Property") to control granting a subject write
  access to a specific object.  Both the Simple Security Condition and
  the *-Property include mandatory security provisions based on the
  dominance relation between formal security levels of subjects and
  objects the clearance of the subject and the classification of the
  object.  The Discretionary Security Property is also defined, and
  requires that a specific subject be authorized for the particular mode
  of access required for the state transition.  In its treatment of
  subjects (processes acting on behalf of a user), the model
  distinguishes between trusted subjects (i.e., not constrained within
  the model by the *-Property) and untrusted subjects (those that are
  constrained by the *-Property).


  From the Bell and LaPadula model there evolved a model of the method
  of proof required to formally demonstrate that all arbitrary sequences
  of state transitions are security-preserving.  It was also shown that
  the *- Property is sufficient to prevent the compromise of information
  by Trojan Horse attacks.


  66..33..  TTHHEE TTRRUUSSTTEEDD CCOOMMPPUUTTIINNGG BBAASSEE

  In order to encourage the widespread commercial availability of
  trusted computer systems, these evaluation criteria have been designed
  to address those systems in which a security kernel is specifically
  implemented as well as those in which a security kernel has not been
  implemented.  The latter case includes those systems in which
  objective (c) is not fully supported because of the size or complexity
  of the reference validation mechanism.  For convenience, these
  evaluation criteria use the term _T_r_u_s_t_e_d _C_o_m_p_u_t_i_n_g _B_a_s_e to refer to
  the reference validation mechanism, be it a security kernel, front-end
  security filter, or the entire trusted computer system.


  The heart of a trusted computer system is the Trusted Computing Base
  (TCB) which contains all of the elements of the system responsible for
  supporting the security policy and supporting the isolation of objects
  (code and data) on which the protection is based.  The bounds of the
  TCB equate to the "security perimeter" referenced in some computer
  security literature.  In the interest of understandable and
  maintainable protection, a TCB should be as simple as possible
  consistent with the functions it has to perform.  Thus, the TCB
  includes hardware, firmware, and software critical to protection and
  must be designed and implemented such that system elements excluded
  from it need not be trusted to maintain protection.  Identification of
  the interface and elements of the TCB along with their correct
  functionality therefore forms the basis for evaluation.


  For general-purpose systems, the TCB will include key elements of the
  operating system and may include all of the operating system.  For
  embedded systems, the security policy may deal with objects in a way
  that is meaningful at the application level rather than at the
  operating system level.  Thus, the protection policy may be enforced
  in the application software rather than in the underlying operating
  system.  The TCB will necessarily include all those portions of the
  operating system and application software essential to the support of
  the policy.  Note that, as the amount of code in the TCB increases, it
  becomes harder to be confident that the TCB enforces the reference
  monitor requirements under all circumstances.


  66..44..  AASSSSUURRAANNCCEE

  The third reference monitor design objective is currently interpreted
  as meaning that _t_h_e _T_C_B _m_u_s_t _b_e _o_f _s_u_f_f_i_c_i_e_n_t_l_y _s_i_m_p_l_e _o_r_g_a_n_i_z_a_t_i_o_n
  _a_n_d _c_o_m_p_l_e_x_i_t_y _t_o _b_e _s_u_b_j_e_c_t_e_d _t_o _a_n_a_l_y_s_i_s _a_n_d _t_e_s_t_s_, _t_h_e _c_o_m_p_l_e_t_e_n_e_s_s
  _o_f _w_h_i_c_h _c_a_n _b_e _a_s_s_u_r_e_d.


  Clearly, as the perceived degree of risk increases (e.g., the range of
  sensitivity of the system's protected data, along with the range of
  clearances held by the system's user population) for a particular
  system's operational application and environment, so also must the
  assurances be increased to substantiate the degree of trust that will
  be placed in the system.  The hierarchy of requirements that are
  presented for the evaluation classes in the trusted computer system
  evaluation criteria reflect the need for these assurances.


  As discussed in Section 5.3, the evaluation criteria uniformly require
  a statement of the security policy that is enforced by each trusted
  computer system.  In addition, it is required that a convincing
  argument be presented that explains why the TCB satisfies the first
  two design requirements for a reference monitor.  It is not expected
  that this argument will be entirely formal.  This argument is required
  for each candidate system in order to satisfy the assurance control
  objective.


  The systems to which security enforcement mechanisms have been added,
  rather than built-in as fundamental design objectives, are not readily
  amenable to extensive analysis since they lack the requisite
  conceptual simplicity of a security kernel.  This is because their TCB
  extends to cover much of the entire system.  Hence, their degree of
  trustworthiness can best be ascertained only by obtaining test
  results.  Since no test procedure for something as complex as a
  computer system can be truly exhaustive, there is always the
  possibility that a subsequent penetration attempt could succeed.  It
  is for this reason that such systems must fall into the lower
  evaluation classes.


  On the other hand, those systems that are designed and engineered to
  support the TCB concepts are more amenable to analysis and structured
  testing.  Formal methods can be used to analyze the correctness of
  their reference validation mechanisms in enforcing the system's
  security policy.  Other methods, including less-formal arguments, can
  be used in order to substantiate claims for the completeness of their
  access mediation and their degree of tamper-resistance.  More
  confidence can be placed in the results of this analysis and in the
  thoroughness of the structured testing than can be placed in the
  results for less methodically structured systems.  For these reasons,
  it appears reasonable to conclude that these systems could be used in
  higher-risk environments.  Successful implementations of such systems
  would be placed in the higher evaluation classes.





  66..55..  TTHHEE CCLLAASSSSEESS

  It is highly desirable that there be only a small number of overall
  evaluation classes.  Three major divisions have been identified in the
  evaluation criteria with a fourth division reserved for those systems
  that have been evaluated and found to offer unacceptable security
  protection.  Within each major evaluation division, it was found that
  "intermediate" classes of trusted system design and development could
  meaningfully be defined.  These intermediate classes have been
  designated in the criteria because they identify systems that:



  +o  are viewed to offer significantly better protection and assurance
     than would systems that satisfy the basic requirements for their
     evaluation class; and

  +o  there is reason to believe that systems in the intermediate
     evaluation classes could eventually be evolved such that they would
     satisfy the requirements for the next higher evaluation class.


  Except within division A it is not anticipated that additional
  "intermediate" evaluation classes satisfying the two characteristics
  described above will be identified.


  Distinctions in terms of system architecture, security policy
  enforcement, and evidence of credibility between evaluation classes
  have been defined such that the "jump" between evaluation classes
  would require a considerable investment of effort on the part of
  implementors.  Correspondingly, there are expected to be significant
  differentials of risk to which systems from the higher evaluation
  classes will be exposed.
































  77..  TTHHEE RREELLAATTIIOONNSSHHIIPP BBEETTWWEEEENN PPOOLLIICCYY AANNDD TTHHEE CCRRIITTEERRIIAA

  Section 1 presents fundamental computer security requirements and
  Section 5 presents the control objectives for Trusted Computer
  Systems.  They are general requirements, useful and necessary, for the
  development of all secure systems.  However, when designing systems
  that will be used to process classified or other sensitive
  information, functional requirements for meeting the Control
  Objectives become more specific.  There is a large body of policy laid
  down in the form of Regulations, Directives, Presidential Executive
  Orders, and OMB Circulars that form the basis of the procedures for
  the handling and processing of Federal information in general and
  classified information specifically.  This section presents pertinent
  excerpts from these policy statements and discusses their relationship
  to the Control Objectives.  These excerpts are examples to illustrate
  the relationship of the policies to criteria and may not be complete.


  77..11..  EESSTTAABBLLIISSHHEEDD FFEEDDEERRAALL PPOOLLIICCIIEESS

  A significant number of computer security policies and associated
  requirements have been promulgated by Federal government elements.
  The interested reader is referred to reference [36] which analyzes the
  need for trusted systems in the civilian agencies of the Federal
  government, as well as in state and local governments and in the
  private sector.  This reference also details a number of relevant
  Federal statutes, policies and requirements not treated further below.


  Security guidance for Federal automated information systems is
  provided by the Office of Management and Budget.  Two specifically
  applicable Circulars have been issued.  OMB Circular No.  A-71,
  Transmittal Memorandum No. 1, _S_e_c_u_r_i_t_y _o_f _F_e_d_e_r_a_l _A_u_t_o_m_a_t_e_d
  _I_n_f_o_r_m_a_t_i_o_n _S_y_s_t_e_m_s, [30] directs each executive agency to establish
  and maintain a computer security program.  It makes the head of each
  executive branch, department and agency responsible "for assuring an
  adequate level of security for all agency data whether processed in-
  house or commercially.  This includes responsibility for the
  establishment of physical, administrative and technical safeguards
  required to adequately protect personal, proprietary or other
  sensitive data not subject to national security regulations, as well
  as national security data."  [30, para. 4 p. 2]


  OMB Circular No.  A-123, _I_n_t_e_r_n_a_l _C_o_n_t_r_o_l _S_y_s_t_e_m_s, [31] issued to help
  eliminate fraud, waste, and abuse in government programs requires: (a)
  agency heads to issue internal control directives and assign
  responsibility, (b) managers to review programs for vulnerability, and
  (c) managers to perform periodic reviews to evaluate strengths and
  update controls.  Soon after promulgation of OMB Circular A-123, the
  relationship of its internal control requirements to building secure
  computer systems was recognized.  [4] While not stipulating computer
  controls specifically, the definition of Internal Controls in A-123
  makes it clear that computer systems are to be included: [31, sec.
  4.C]

       IInntteerrnnaall CCoonnttrroollss -- The plan of organization and all of the methods
       and measures adopted within an agency to safeguard its resources,
       assure the accuracy and reliability of its information, assure adher-
       ence to applicable laws, regulations and policies, and promote opera-
       tional economy and efficiency.



  The matter of classified national security information processed by
  ADP systems was one of the first areas given serious and extensive
  concern in computer security.  The computer security policy documents
  promulgated as a result contain generally more specific and structured
  requirements than most, keyed in turn to an authoritative basis that
  itself provides a rather clearly articulated and structured
  information security policy.  This basis, Executive Order 12356,
  _N_a_t_i_o_n_a_l _S_e_c_u_r_i_t_y _I_n_f_o_r_m_a_t_i_o_n, sets forth requirements for the
  classification, declassification and safeguarding of "national
  security information" _p_e_r _s_e.  [18]


  77..22..  DDOODD PPOOLLIICCIIEESS

  Within the Department of Defense, these broad requirements are
  implemented and further specified primarily through two vehicles: 1)
  DoD Regulation 5200.1-R [10], which applies to all components of the
  DoD as such, and 2) DoD 5220.22-M, _I_n_d_u_s_t_r_i_a_l _S_e_c_u_r_i_t_y _M_a_n_u_a_l _f_o_r
  _S_a_f_e_g_u_a_r_d_i_n_g _C_l_a_s_s_i_f_i_e_d _I_n_f_o_r_m_a_t_i_o_n [14] , which applies to
  contractors included within the Defense Industrial Security Program.
  Note that the latter transcends DoD as such, since it applies not only
  to any contractors handling classified information for any DoD
  component, but also to the contractors of eighteen other Federal
  organizations for whom the Secretary of Defense is authorized to act
  in rendering industrial security services. (See ``footnote (*)
  below''.)


  For ADP systems, these information security requirements are further
  amplified and specified in: 1) DoD Directive 5200.28 [11] and DoD
  Manual 5200.28-M [12], for DoD components; and 2) Section XIII of DoD
  5220.22-M [14] for contractors.  DoD Directive 5200.28, _S_e_c_u_r_i_t_y
  _R_e_q_u_i_r_e_m_e_n_t_s _f_o_r _A_u_t_o_m_a_t_i_c _D_a_t_a _P_r_o_c_e_s_s_i_n_g _(_A_D_P_) _S_y_s_t_e_m_s, stipulates:
  "Classified material contained in an ADP system shall be safeguarded
  by the continuous employment of protective features in the system's
  hardware and software design and configuration .  .  .  ."  [11, sec.
  IV] Furthermore, it is required that ADP systems that "process, store,
  or use classified data and produce classified information will, with
  reasonable dependability, prevent:


  a.  Deliberate or inadvertent access to classified material by
  unauthorized persons, and


  b.  Unauthorized manipulation of the computer and its associated
  peripheral devices."  [11, sec. I B.3]


  Requirements equivalent to these appear within DoD 5200.28-M [12] and
  in DoD 5220.22-M [14].


  DoD Directove 5200.28 provides the security requirements for ADP
  systems.  For some types of information, such as Sensitive
  Compartmented Information (SCI), DoD Directive 5200.28 states that
  other minimum security requirements also apply.  These minima are
  found in DCID l/l6 (new reference number 5) which is implemented in
  DIAM 50-4 (new reference number 6) for DoD and DoD contractor ADP
  systems.


  From requirements imposed by these regulations, directives and
  circulars, the three components of the Security Policy Control
  Objective, i.e., Mandatory and Discretionary Security and Marking, as
  well as the Accountability and Assurance Control Objectives, can be
  functionally defined for DoD applications.  The following discussion
  provides further specificity in Policy for these Control Objectives.
  77..22..11..  FFeeddeerraall aaggeenncciieess ffoooottnnoottee

  (*) i.e., NASA, Commerce Department, GSA, State Department, Small
  Business Administration, National Science Foundation, Treasury
  Department, Transportation Department, Interior Department,
  Agriculture Department, U.S.  Information Agency, Labor Department,
  Environmental Protection Agency, Justice Department, U.S. Arms Control
  and Disarmament Agency, Federal Emergency Management Agency, Federal
  Reserve System, and U.S. General Accounting Office.


  77..33..  CCRRIITTEERRIIAA CCOONNTTRROOLL OOBBJJEECCTTIIVVEE FFOORR SSEECCUURRIITTYY PPOOLLIICCYY

  77..33..11..  MMaarrkkiinngg

  The control objective for marking is: _S_y_s_t_e_m_s _t_h_a_t _a_r_e _d_e_s_i_g_n_e_d _t_o
  _e_n_f_o_r_c_e _a _m_a_n_d_a_t_o_r_y _s_e_c_u_r_i_t_y _p_o_l_i_c_y _m_u_s_t _s_t_o_r_e _a_n_d _p_r_e_s_e_r_v_e _t_h_e
  _i_n_t_e_g_r_i_t_y _o_f _c_l_a_s_s_i_f_i_c_a_t_i_o_n _o_r _o_t_h_e_r _s_e_n_s_i_t_i_v_i_t_y _l_a_b_e_l_s _f_o_r _a_l_l
  _i_n_f_o_r_m_a_t_i_o_n_.  _L_a_b_e_l_s _e_x_p_o_r_t_e_d _f_r_o_m _t_h_e _s_y_s_t_e_m _m_u_s_t _b_e _a_c_c_u_r_a_t_e
  _r_e_p_r_e_s_e_n_t_a_t_i_o_n_s _o_f _t_h_e _c_o_r_r_e_s_o_n_d_i_n_g _i_n_t_e_r_n_a_l _s_e_n_s_i_t_i_v_i_t_y _l_a_b_e_l_s _b_e_i_n_g
  _e_x_p_o_r_t_e_d_.


  DoD 5220.22-M, _I_n_d_u_s_t_r_i_a_l _S_e_c_u_r_i_t_y _M_a_n_u_a_l _f_o_r _S_a_f_e_g_u_a_r_d_i_n_g _C_l_a_s_s_i_f_i_e_d
  _I_n_f_o_r_m_a_t_i_o_n, explains in paragraph 11 the reasons for marking
  information: [14]



       "a.  General.  Classification designation by physical marking, nota-
       tion or other means serves to warn and to inform the holder what
       degree of protection against unauthorized disclosure is reqired for
       that information or material."



  Marking requirements are given in a number of policy statements.




     EExxeeccuuttiivvee OOrrddeerr 1122335566
        (Sections 1.5.a and 1.5.a.1) requires that classification
        markings "shall be shown on the face of all classified
        documents, or clearly associated with other forms of classified
        information in a manner appropriate to the medium involved."
        [18]




     DDooDD RReegguullaattiioonn 55220000..11--RR
        (Section 1-500) requires that: ".  .  .  information or material
        that requires protection against unauthorized disclosure in the
        interest of national security shall be classified in one of
        three designations, namely: 'Top Secret,' [10] (By extension,
        for use in computer processing, the unofficial designation
        "Unclassified" is used to indicate information that does not
        fall under one of the other three designations of classified
        information.)


     DDooDD RReegguullaattiioonn 55220000..11--RR
        (Section 4-304b) requires that: "ADP systems and word processing
        systems employing such media shall provide for internal
        classification marking to assure that classified information
        contained therein that is reproduced or generated, will bear
        applicable classification and associated markings." (This
        regulation provides for the exemption of certain existing
        systems where "internal classification and applicable associated
        markings cannot be implemented without extensive system
        modifications."  [10] However, it is clear that future DoD ADP
        systems must be able to provide applicable and accurate labels
        for classified and other sensitive information.)


     DDooDD MMaannuuaall 55220000..2288--MM
        (Section IV, 4-305d) requires the following: "Security Labels -
        All classified material accessible by or within the ADP system
        shall be identified as to its security classification and access
        or dissemination limitations, and all output of the ADP system
        shall be appropriately marked."  [12]




  77..33..22..  MMaannddaattoorryy SSeeccuurriittyy

  The control objective for mandatory security is: _S_e_c_u_r_i_t_y _p_o_l_i_c_i_e_s
  _d_e_f_i_n_e_d _f_o_r _s_y_s_t_e_m_s _t_h_a_t _a_r_e _u_s_e_d _t_o _p_r_o_c_e_s_s _c_l_a_s_s_i_f_i_e_d _o_r _o_t_h_e_r
  _s_p_e_c_i_f_i_c_a_l_l_y _c_a_t_e_g_o_r_i_z_e_d _s_e_n_s_i_t_i_v_e _i_n_f_o_r_m_a_t_i_o_n _m_u_s_t _i_n_c_l_u_d_e _p_r_o_v_i_s_i_o_n_s
  _f_o_r _t_h_e _e_n_f_o_r_c_e_m_e_n_t _o_f _m_a_n_d_a_t_o_r_y _a_c_c_e_s_s _c_o_n_t_r_o_l _r_u_l_e_s_.  _T_h_a_t _i_s_, _t_h_e_y
  _m_u_s_t _i_n_c_l_u_d_e _a _s_e_t _o_f _r_u_l_e_s _f_o_r _c_o_n_t_r_o_l_l_i_n_g _a_c_c_e_s_s _b_a_s_e_d _d_i_r_e_c_t_l_y _o_n _a
  _c_o_m_p_a_r_i_s_o_n _o_f _t_h_e _i_n_d_i_v_i_d_u_a_l_'_s _c_l_e_a_r_a_n_c_e _o_r _a_u_t_h_o_r_i_z_a_t_i_o_n _f_o_r _t_h_e
  _i_n_f_o_r_m_a_t_i_o_n _a_n_d _t_h_e _c_l_a_s_s_i_f_i_c_a_t_i_o_n _o_r _s_e_n_s_i_t_i_v_i_t_y _d_e_s_i_g_n_a_t_i_o_n _o_f _t_h_e
  _i_n_f_o_r_m_a_t_i_o_n _b_e_i_n_g _s_o_u_g_h_t_, _a_n_d _i_n_d_i_r_e_c_t_l_y _o_n _c_o_n_s_i_d_e_r_a_t_i_o_n_s _o_f _p_h_y_s_i_c_a_l
  _a_n_d _o_t_h_e_r _e_n_v_i_r_o_n_m_e_n_t_a_l _f_a_c_t_o_r_s _o_f _c_o_n_t_r_o_l_.  _T_h_e _m_a_n_d_a_t_o_r_y _a_c_c_e_s_s
  _c_o_n_t_r_o_l _r_u_l_e_s _m_u_s_t _a_c_c_u_r_a_t_e_l_y _r_e_f_l_e_c_t _t_h_e _l_a_w_s_, _r_e_g_u_l_a_t_i_o_n_s_, _a_n_d
  _g_e_n_e_r_a_l _p_o_l_i_c_i_e_s _f_r_o_m _w_h_i_c_h _t_h_e_y _a_r_e _d_e_r_i_v_e_d_.


  There are a number of policy statements that are related to mandatory
  security.



     EExxeeccuuttiivvee OOrrddeerr 1122335566
        (Section 4.1.a) states that "a person is eligible for access to
        classified information provided that a determination of
        trustworthiness has been made by agency heads or designated
        officials and provided that such access is essential to the
        accomplishment of lawful and authorized Government purposes."
        [18]



     DDooDD RReegguullaattiioonn 55220000..11--RR
        (Chapter I, Section 3) defines a Special Access Program as "any
        program imposing 'need-to-know' or access controls beyond those
        normally provided for access to Confidential, Secret, or Top
        Secret information.  Such a program includes, but is not limited
        to, special clearance, adjudication, or investigative
        requirements, special designation of officials authorized to
        determine 'need-to-know', or special lists of persons determined
        to have a 'need-to- know.'"  [10, para.  1-328] This passage
        distinguishes between a 'discretionary' determination of need-
        to-know and formal need-to-know which is implemented through
        Special Access Programs.  DoD Regulation 5200.1-R, paragraph
        7-100 describes general requirements for trustworthiness
        (clearance) and need-to-know, and states that the individual
        with possession, knowledge or control of classified information
        has final responsibility for determining if conditions for
        access have been met.  This regulation further stipulates that
        "no one has a right to have access to classified information
        solely by virtue of rank or position."  [10, para. 7-100] )


     DDooDD MMaannuuaall 55220000..2288--MM
        (Section II 2-100) states that, "Personnel who develop, test
        (debug), maintain, or use programs which are classified or which
        will be used to access or develop classified material shall have
        a personnel security clearance and an access authorization
        (need-to-know), as appropriate for the highest classified and
        most restrictive category of classified material which they will
        access under system constraints."  [12]



     DDooDD MMaannuuaall 55222200..2222--MM
        (Paragaph 3a) defines access as "the ability and opportunity to
        obtain knowledge of classified information.  An individual, in
        fact, may have access to classified information by being in a
        place where such information is kept, if the security measures
        which are in force do not prevent him from gaining knowledge of
        the classified information."  [14]



        The above mentioned Executive Order, Manual, Directives and
        Regulations clearly imply that a trusted computer system must
        assure that the classification labels associated with sensitive
        data cannot be arbitrarily changed, since this could permit
        individuals who lack the appropriate clearance to access
        classified information.  Also implied is the requirement that a
        trusted computer system must control the flow of information so
        that data from a higher classification cannot be placed in a
        storage object of lower classification unless its "downgrading"
        has been authorized.



  77..33..33..  DDiissccrreettiioonnaarryy SSeeccuurriittyy

  The term discretionary security refers to a computer system's ability
  to control information on an individual basis.  It stems from the fact
  that even though an individual has all the formal clearances for
  access to specific classified information, each individual's access to
  information must be based on a demonstrated need-to-know.  Because of
  this, it must be made clear that this requirement is not discretionary
  in a "take it or leave it" sense.  The directives and regulations are
  explicit in stating that the need-to-know test must be satisfied
  before access can be granted to the classified information.  The
  control objective for discretionary security is: _S_e_c_u_r_i_t_y _p_o_l_i_c_i_e_s
  _d_e_f_i_n_e_d _f_o_r _s_y_s_t_e_m_s _t_h_a_t _a_r_e _u_s_e_d _t_o _p_r_o_c_e_s_s _c_l_a_s_s_i_f_i_e_d _o_r _o_t_h_e_r
  _s_e_n_s_i_t_i_v_e _i_n_f_o_r_m_a_t_i_o_n _m_u_s_t _i_n_c_l_u_d_e _p_r_o_v_i_s_i_o_n_s _f_o_r _t_h_e _e_n_f_o_r_c_e_m_e_n_t _o_f
  _d_i_s_c_r_e_t_i_o_n_a_r_y _a_c_c_e_s_s _c_o_n_t_r_o_l _r_u_l_e_s_.  _T_h_a_t _i_s_, _t_h_e_y _m_u_s_t _i_n_c_l_u_d_e _a
  _c_o_n_s_i_s_t_e_n_t _s_e_t _o_f _r_u_l_e_s _f_o_r _c_o_n_t_r_o_l_l_i_n_g _a_n_d _l_i_m_i_t_i_n_g _a_c_c_e_s_s _b_a_s_e_d _o_n
  _i_d_e_n_t_i_f_i_e_d _i_n_d_i_v_i_d_u_a_l_s _w_h_o _h_a_v_e _b_e_e_n _d_e_t_e_r_m_i_n_e_d _t_o _h_a_v_e _a _n_e_e_d_-_t_o_-_k_n_o_w
  _f_o_r _t_h_e _i_n_f_o_r_m_a_t_i_o_n_.




     DDooDD RReegguullaattiioonn 55220000..11--RR
        (Paragraph 7-100) In addition to excerpts already provided that
        touch on need-to- know, this section of the regulation stresses
        the need- to-know principle when it states "no person may have
        access to classified information unless .  .  .  access is
        necessary for the performance of official duties."  [10]



     _A_l_s_o_, DDooDD MMaannuuaall 55222200..2222--MM
        (Section III 20.a) states that "an individual shall be permitted
        to have access to classified information only . . . when the
        contractor determines that access is necessary in the
        performance of tasks or services essential to the fulfillment of
        a contract or program, i.e., the individual has a need-to-know."
        [14]




  77..44..  CCRRIITTEERRIIAA CCOONNTTRROOLL OOBBJJEECCTTIIVVEE FFOORR AACCCCOOUUNNTTAABBIILLIITTYY

  _T_h_e _c_o_n_t_r_o_l _o_b_j_e_c_t_i_v_e _f_o_r _a_c_c_o_u_n_t_a_b_i_l_i_t_y _i_s_: _"_S_y_s_t_e_m_s _t_h_a_t _a_r_e _u_s_e_d _t_o
  _p_r_o_c_e_s_s _o_r _h_a_n_d_l_e _c_l_a_s_s_i_f_i_e_d _o_r _o_t_h_e_r _s_e_n_s_i_t_i_v_e _i_n_f_o_r_m_a_t_i_o_n _m_u_s_t
  _a_s_s_u_r_e _i_n_d_i_v_i_d_u_a_l _a_c_c_o_u_n_t_a_b_i_l_i_t_y _w_h_e_n_e_v_e_r _e_i_t_h_e_r _a _m_a_n_d_a_t_o_r_y _o_r
  _d_i_s_c_r_e_t_i_o_n_a_r_y _s_e_c_u_r_i_t_y _p_o_l_i_c_y _i_s _i_n_v_o_k_e_d_.  _F_u_r_t_h_e_r_m_o_r_e_, _t_o _a_s_s_u_r_e
  _a_c_c_o_u_n_t_a_b_i_l_i_t_y _t_h_e _c_a_p_a_b_i_l_i_t_y _m_u_s_t _e_x_i_s_t _f_o_r _a_n _a_u_t_h_o_r_i_z_e_d _a_n_d
  _c_o_m_p_e_t_e_n_t _a_g_e_n_t _t_o _a_c_c_e_s_s _a_n_d _e_v_a_l_u_a_t_e _a_c_c_o_u_n_t_a_b_i_l_i_t_y _i_n_f_o_r_m_a_t_i_o_n _b_y _a
  _s_e_c_u_r_e _m_e_a_n_s_, _w_i_t_h_i_n _a _r_e_a_s_o_n_a_b_l_e _a_m_o_u_n_t _o_f _t_i_m_e_, _a_n_d _w_i_t_h_o_u_t _u_n_d_u_e
  _d_i_f_f_i_c_u_l_t_y_.


  This control objective is supported by the following citations:




     DDooDD DDiirreeccttiivvee 55220000..2288
        (Section VI.A.1) states: "Each user's identity shall be
        positively established, and his access to the system, and his
        activity in the system (including material accessed and actions
        taken) controlled and open to scrutiny."  [11]



     DDooDD MMaannuuaall 55220000..2288--MM
        (Paragraph 5-100) states: "An audit log or file (manual,
        machine, or a combination of both) shall be maintained as a
        history of the use of the ADP System to permit a regular
        security review of system activity.  (e.g., The log should
        record security related transactions, including each access to a
        classified file and the nature of the access, e.g., logins,
        production of accountable classified outputs, and creation of
        new classified files.  Each classified file successfully
        accessed (regardless of the number of individual references)
        during each 'job' or 'interactive session' should also be
        recorded in the audit log.  Much of the material in this log may
        also be required to assure that the system preserves information
        entrusted to it.)"  [12]


     DDooDD MMaannuuaall 55220000..2288--MM
        (Paragraph IV 4-305f) states: "Where needed to assure control of
        access and individual accountability, each user or specific
        group of users shall be identified to the ADP System by
        appropriate administrative or hardware/software measures.  Such
        identification measures must be in sufficient detail to enable
        the ADP System to provide the user only that material which he
        is authorized."  [12]


     DDooDD MMaannuuaall 55220000..2288--MM
        (Section I 1-102b) states: [129]


          Component's Designated Approving Authorities, or their designees
          for this purpose .  .  .  will assure:

                     .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .

               (4) Maintenance of documentation on operating systems (O/S)
               and all modifications thereto, and its retention for a
               sufficient period of time to enable tracing of security-
               related defects to their point of origin or inclusion in the
               system.

                     .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .

               (6) Establishment of procedures to discover, recover,
               handle, and dispose of classified material improperly
               disclosed through system malfunction or personnel action.

               (7) Proper disposition and correction of security
               deficiencies in all approved ADP Systems, and the effective
               use and disposition of system housekeeping or audit records,
               records of security violations or security-related system
               malfunctions, and records of tests of the security features
               of an ADP System."





     DDooDD MMaannuuaall 55222200..2222--MM
        (Paragraph 111) on audit Trails states:

        a. The general security requirement for any ADP system audit
        trail is that it provide a documented history of the use of the
        system.  An approved audit trail will permit review of
        classified system activity and will provide a detailed activity
        record to facilitate reconstruction of events to determine the
        magnitude of compromise (if any) should a security malfunction
        occur.  To fulfill this basic requirement, audit trail systems,
        manual, automated or a combination of both must document
        significant events occurring in the following areas of concern:
        (i) preparation of input data and dissemination of output data
        (i.e., reportable interactivity between users and system support
        personnel), (ii) activity involved within an ADP environment
        (e.g., ADP support personnel modification of security and
        related controls), and (iii) internal machine activity.

        b. The audit trail for an ADP system approved to process
        classified information must be based on the above three areas
        and may be stylized to the particular system.  All systems
        approved for classified processing should contain most if not
        all of the audit trail records listed below. The contractor's
        SPP documentation must identify and describe those applicable:


     +o  1. Personnel access;

     +o  2. Unauthorized and surreptitious entry into the central
        computer facility or remote terminal areas;

     +o  3. Start/stop time of classified processing indicating pertinent
        systems security initiation and termination events (e.g.,
        upgrading/downgrading actions pursuant to paragraph 107);
     +o  4. All functions initiated by ADP system console operators;

     +o  5. Disconnects of remote terminals and peripheral devices
        (paragraph 107c);

     +o  6. Log-on and log-off user activity;

     +o  7. Unauthorized attempts to access files or programs, as well as
        all open, close, create, and file destroy actions;

     +o  8. Program aborts and anomalies including identification
        information (i.e., user/program name, time and location of
        incident, etc.);

     +o  9. System hardware additions, deletions and maintenance actions;

     +o  10. Generations and modifications affecting the security
        features of the system software.

        c. The ADP system security supervisor or designee shall review
        the audit trail logs at least weekly to assure that all
        pertinent activity is properly recorded and that appropriate
        action has been taken to correct any anomaly.  The majority of
        ADP systems in use today can develop audit trail systems in
        accord with the above; however, special systems such as weapons,
        communications, communications security, and tactical data
        exchange and display systems, may not be able to comply with all
        aspects of the above and may require individualized
        consideration by the cognizant security office.

        d. Audit trail records shall be retained for a period of one
        inspection cycle."  [14]



  77..55..  CCRRIITTEERRIIAA CCOONNTTRROOLL OOBBJJEECCTTIIVVEE FFOORR AASSSSUURRAANNCCEE

  The control objective for assurance is: "Systems that are used to
  process or handle classified or other sensitive information must be
  designed to guarantee correct and accurate interpretation of the
  security policy and must not distort the intent of that policy.
  Assurance must be provided that correct implementation and operation
  of the policy exists throughout the system's life-cycle."


  A basis for this objective can be found in the following sections of
  DoD Directive 5200.28:



     DDooDD DDiirreeccttiivvee 55220000..2288
        (IV.B.1) stipulates: "Generally, security of an ADP system is
        most effective and economical if the system is designed
        originally to provide it.  Each Department of Defense Component
        undertaking design of an ADP system which is expected to
        process, store, use, or produce classified material shall:  From
        the beginning of the design process, consider the security
        policies, concepts, and measures prescribed in this Directive."
        [11]



     DDooDD DDiirreeccttiivvee 55220000..2288
        (IV.C.5.a) states: "Provision may be made to permit adjustment
        of ADP system area controls to the level of protection required
        for the classification category and type(s) of material actually
        being handled by the system, provided change procedures are
        developed and implemented which will prevent both the
        unauthorized access to classified material handled by the system
        and the unauthorized manipulation of the system and its
        components.  Particular attention shall be given to the
        continuous protection of automated system security measures,
        techniques and procedures when the personnel security clearance
        level of users having access to the system changes."  [118]


     DDooDD DDiirreeccttiivvee 55220000..2288
        (VI.A.2) states: "_E_n_v_i_r_o_n_m_e_n_t_a_l _C_o_n_t_r_o_l.  The ADP System shall
        be externally protected to minimize the likelihood of
        unauthorized access to system entry points, access to classified
        information in the system, or damage to the system."  [11]


     DDooDD MMaannuuaall 55220000..2288--MM
        (Section I 1-102b) states [12]:




          Component's Designated Approving Authorities, or their
          designees for this purpose .  .  .  will assure:

                       .  .  .  .  .  .  .  .  .  .  .  .  .

                   (5) Supervision, monitoring, and testing, as
               appropriate, of changes in an approved ADP System
               which could affect the security features of the
               system, so that a secure system is maintained.

                       .  .  .  .  .  .  .  .  .  .  .  .  .

                   (7) Proper disposition and correction of security
               deficiencies in all approved ADP Systems, and the
               effective use and disposition of system housekeeping
               or audit records, records of security violations or
               security-related system malfunctions, and records of
               tests of the security features of an ADP System.

                   (8) Conduct of competent system ST&E, timely
               review of system ST&E reports, and correction of
               deficiencies needed to support conditional or final
               approval or disapproval of an ADP System for the
               processing of classified information.

                   (9) Establishment, where appropriate, of a
               central ST&E coordination point for the
               maintenance of records of selected techniques,
               procedures, standards, and tests used in the testing
               and evaluation of security features of ADP Systems
               which may be suitable for validation and use by other
               Department of Defense Components.





     DDooDD MMaannuuaall 55222200..2222--MM
        (Section XIII 103a) requires: "the initial approval, in writing,
        of the cognizant security office prior to processing any
        classified information in an ADP system.  This section requires
        reapproval by the cognizant security office for major system
        modifications made subsequent to initial approval.  Reapprovals
        will be required because of (i) major changes in personnel
        access requirements, (ii) relocation or structural modification
        of the central computer facility, (iii) additions, deletions or
        changes to main frame, storage or input/output devices, (iv)
        system software changes impacting security protection features,
        (v) any change in clearance, declassification, audit trail or
        hardware/software maintenance procedures, and (vi) other system
        changes as determined by the cognizant security office."  [14]


        A major component of assurance, life-cycle assurance, as
        described in DDooDD DDiirreeccttiivvee 77992200..11, is concerned with testing ADP
        systems both in the development phase as well as during
        operation [1710].  DDooDD DDiirreeccttiivvee 55221155..11 (Section F.2.C.(2))
        requires "evaluations of selected industry and government-
        developed trusted computer systems against these criteria."
        [1310]

















































  88..  AA GGUUIIDDEELLIINNEE OONN CCOOVVEERRTT CCHHAANNNNEELLSS

  A covert channel is any communication channel that can be exploited by
  a process to transfer information in a manner that violates the
  system's security policy.  There are two types of covert channels:
  storage channels and timing channels.  Covert storage channels include
  all vehicles that would allow the direct or indirect writing of a
  storage location by one process and the direct or indirect reading of
  it by another.  Covert timing channels include all vehicles that would
  allow one process to signal information to another process by
  modulating its own use of system resources in such a way that the
  change in response time observed by the second process would provide
  information.


  From a security perspective, covert channels with low bandwidths
  represent a lower threat than those with high bandwidths.  However,
  for many types of covert channels, techniques used to reduce the
  bandwidth below a certain rate (which depends on the specific channel
  mechanism and the system architecture) also have the effect of
  degrading the performance provided to legitimate system users.  Hence,
  a trade-off between system performance and covert channel bandwidth
  must be made.  Because of the threat of compromise that would be
  present in any multilevel computer system containing classified or
  sensitive information, such systems should not contain covert channels
  with high bandwidths.  This guideline is intended to provide system
  developers with an idea of just how high a "high" covert channel
  bandwidth is.


  A covert channel bandwidth that exceeds a rate of one hundred (100)
  bits per second is considered "high" because 100 bits per second is
  the approximate rate at which many computer terminals are run.  It
  does not seem appropriate to call a computer system "secure" if
  information can be compromised at a rate equal to the normal output
  rate of some commonly used device.


  In any multilevel computer system there are a number of relatively
  low-bandwidth covert channels whose existence is deeply ingrained in
  the system design.  Faced with the large potential cost of reducing
  the bandwidths of such covert channels, it is felt that those with
  maximum bandwidths of less than one (1) bit per second are acceptable
  in most application environments.  Though maintaining acceptable
  performance in some systems may make it impractical to eliminate all
  covert channels with bandwidths of 1 or more bits per second, it is
  possible to audit their use without adversely affecting system
  performance.  This audit capability provides the system administration
  with a means of detecting -- and procedurally correcting --
  significant compromise.  Therefore, a Trusted Computing Base should
  provide, wherever possible, the capability to audit the use of covert
  channel mechanisms with bandwidths that may exceed a rate of one (1)
  bit in ten (10) seconds.


  The covert channel problem has been addressed by a number of authors.
  The interested reader is referred to references [7], [8], [23], [25],
  [26], [27], and [33].








  99..  AA GGUUIIDDEELLIINNEE OONN CCOONNFFIIGGUURRIINNGG MMAANNDDAATTOORRYY AACCCCEESSSS CCOONNTTRROOLL FFEEAATTUURREESS

  The Mandatory Access Control requirement includes a capability to
  support an unspecified number of hierarchical classifications and an
  unspecified number of non-hierarchical categories at each hierarchical
  level.  To encourage consistency and portability in the design and
  development of the National Security Establishment trusted computer
  systems, it is desirable for all such systems to be able to support a
  minimum number of levels and categories.  The following suggestions
  are provided for this purpose:



  +o  The number of hierarchical classifications should be greater than
     or equal to sixteen (16).

  +o  The number of non-hierarchical categories should be greater than or
     equal to sixty-four (64).
















































  1100..  AA GGUUIIDDEELLIINNEE OONN SSEECCUURRIITTYY TTEESSTTIINNGG

  These guidelines are provided to give an indication of the extent and
  sophistication of testing undertaken by the DoD Computer Security
  Center during the Formal Product Evaluation process.  Organizations
  wishing to use "Department of Defense Trusted Computer System
  Evaluation Criteria" for performing their own evaluations may find
  this section useful for planning purposes.


  As in Part I, highlighting is used to indicate changes in the
  guidelines from the next lower division.



  1100..11..  TTEESSTTIINNGG FFOORR DDIIVVIISSIIOONN CC

  1100..11..11..  PPeerrssoonnnneell

  The security testing team shall consist of at least two individuals
  with bachelor degrees in Computer Science or the equivalent.  Team
  members shall be able to follow test plans prepared by the system
  developer and suggest additions, shall be familiar with the "flaw
  hypothesis" or equivalent security testing methodology, and shall have
  assembly level programming experience.  Before testing begins, the
  team members shall have functional knowledge of, and shall have
  completed the system developer's internals course for, the system
  being evaluated.


  1100..11..22..  TTeessttiinngg

  The team shall have "hands-on" involvement in an independent run of
  the tests used by the system developer.  The team shall independently
  design and implement at least five system-specific tests in an attempt
  to circumvent the security mechanisms of the system.  The elapsed time
  devoted to testing shall be at least one month and need not exceed
  three months.  There shall be no fewer than twenty hands-on hours
  spent carrying out system developer-defined tests and test team-
  defined tests.


  1100..22..  TTEESSTTIINNGG FFOORR DDIIVVIISSIIOONN BB

  1100..22..11..  PPeerrssoonnnneell

  The security testing team shall consist of at least two individuals
  with bachelor degrees in Computer Science or the equivalent aanndd aatt
  lleeaasstt oonnee iinnddiivviidduuaall wwiitthh aa mmaasstteerr''ss ddeeggrreeee iinn CCoommppuutteerr SScciieennccee oorr
  eeqquuiivvaalleenntt.  Team members shall be able to follow test plans prepared
  by the system developer and suggest additions, shall be ccoonnvveerrssaanntt
  with the "flaw hypothesis" or equivalent security testing methodology,
  sshhaallll bbee fflluueenntt iinn tthhee TTCCBB iimmpplleemmeennttaattiioonn llaanngguuaaggee((ss)),, and shall have
  assembly level programming experience.  Before testing begins, the
  team members shall have functional knowledge of, and shall have
  completed the system developer's internals course for, the system
  being evaluated.  AAtt lleeaasstt oonnee tteeaamm mmeemmbbeerr sshhaallll hhaavvee pprreevviioouussllyy
  ccoommpplleetteedd aa sseeccuurriittyy tteesstt oonn aannootthheerr ssyysstteemm..


  1100..22..22..  TTeessttiinngg

  The team shall have "hands-on" involvement in an independent run of
  the tteesstt ppaacckkaaggee used by the system developer ttoo tteesstt sseeccuurriittyy--
  rreelleevvaanntt hhaarrddwwaarree aanndd ssooffttwwaarree.  The team shall independently design
  and implement at least ffiifftteeeenn system-specific tests in an attempt to
  circumvent the security mechanisms of the system.  The elapsed time
  devoted to testing shall be at least ttwwoo mmoonntthhss and need not exceed
  ffoouurr months.  There shall be no fewer than tthhiirrttyy hands-on hours ppeerr
  tteeaamm mmeemmbbeerr spent carrying out system developer-defined tests and test
  team-defined tests.


  1100..33..  TTEESSTTIINNGG FFOORR DDIIVVIISSIIOONN AA

  1100..33..11..  PPeerrssoonnnneell

  The security testing team shall consist of at least oonnee iinnddiivviidduuaall
  with a bbaacchheelloorr''ss ddeeggrreeee in Computer Science or the equivalent and at
  least ttwwoo iinnddiivviidduuaallss with mmaasstteerrss'' ddeeggrreeeess in Computer Science or
  equivalent.  Team members shall be able to follow test plans prepared
  by the system developer and suggest additions, shall be conversant
  with the "flaw hypothesis" or equivalent security testing methodology,
  shall be fluent in the TCB implementation language(s), and shall have
  assembly level programming experience.  Before testing begins, the
  team members shall have functional knowledge of, and shall have
  completed the system developer's internals course for, the system
  being evaluated.  AAtt lleeaasstt oonnee tteeaamm mmeemmbbeerr sshhaallll bbee ffaammiilliiaarr eennoouugghh
  wwiitthh tthhee ssyysstteemm hhaarrddwwaarree ttoo uunnddeerrssttaanndd tthhee mmaaiinntteennaannccee ddiiaaggnnoossttiicc
  pprrooggrraammss aanndd ssuuppppoorrttiinngg hhaarrddwwaarree ddooccuummeennttaattiioonn.. At least ttwwoo team
  mmeemmbbeerrss shall have previously completed a security test on another
  system.  AAtt lleeaasstt oonnee tteeaamm mmeemmbbeerr sshhaallll hhaavvee ddeemmoonnssttrraatteedd ssyysstteemm lleevveell
  pprrooggrraammmmiinngg ccoommppeetteennccee oonn tthhee ssyysstteemm uunnddeerr tteesstt ttoo aa lleevveell ooff
  ccoommpplleexxiittyy eeqquuiivvaalleenntt ttoo aaddddiinngg aa ddeevviiccee ddrriivveerr ttoo tthhee ssyysstteemm..


  1100..33..22..  TTeessttiinngg

  The team shall have "hands-on" involvement in an independent run of
  the test package used by the system developer to test security-
  relevant hardware and software.  The team shall independently design
  and implement at least ttwweennttyy--ffiivvee system-specific tests in an attempt
  to circumvent the security mechanisms of the system.  The elapsed time
  devoted to testing shall be at least tthhrreeee months and need not exceed
  ssiixx mmoonntthhss.  There shall be no fewer than ffiiffttyy hands-on hours per
  team member spent carrying out system developer-defined tests and test
  team-defined tests.

























                            TTaabbllee ooff CCoonntteennttss


  1. DIVISION D:  MINIMAL PROTECTION . . . . . . . . . . . . . . . .   2
  2. DIVISION C:  DISCRETIONARY PROTECTION . . . . . . . . . . . . .   3
  2.1. CLASS (C1):  DISCRETIONARY SECURITY PROTECTION  . . . . . . .   3
  2.1.1. Security Policy . . . . . . . . . . . . . . . . . . . . . .   3
  2.1.1.1. Discretionary Access Control  . . . . . . . . . . . . . .   3
  2.1.2. Accountability  . . . . . . . . . . . . . . . . . . . . . .   3
  2.1.2.1. Identification and Authentication . . . . . . . . . . . .   3
  2.1.3. Assurance . . . . . . . . . . . . . . . . . . . . . . . . .   3
  2.1.3.1. Operational Assurance . . . . . . . . . . . . . . . . . .   3
  2.1.3.1.1. System Architecture . . . . . . . . . . . . . . . . . .   3
  2.1.3.1.2. System Integrity  . . . . . . . . . . . . . . . . . . .   3
  2.1.3.2. Life-Cycle Assurance  . . . . . . . . . . . . . . . . . .   4
  2.1.3.2.1. Security Testing  . . . . . . . . . . . . . . . . . . .   4
  2.1.4. Documentation . . . . . . . . . . . . . . . . . . . . . . .   4
  2.1.4.1. Security Features User's Guide  . . . . . . . . . . . . .   4
  2.1.4.2. Trusted Facility Manual . . . . . . . . . . . . . . . . .   4
  2.1.4.3. Test Documentation  . . . . . . . . . . . . . . . . . . .   4
  2.1.4.4. Design Documentation  . . . . . . . . . . . . . . . . . .   4
  2.2. CLASS (C2):  CONTROLLED ACCESS PROTECTION . . . . . . . . . .   4
  2.2.1. Security Policy . . . . . . . . . . . . . . . . . . . . . .   4
  2.2.1.1. Discretionary Access Control  . . . . . . . . . . . . . .   4
  2.2.1.2. Object Reuse  . . . . . . . . . . . . . . . . . . . . . .   5
  2.2.2. Accountability  . . . . . . . . . . . . . . . . . . . . . .   5
  2.2.2.1. Identification and Authentication . . . . . . . . . . . .   5
  2.2.2.2. Audit . . . . . . . . . . . . . . . . . . . . . . . . . .   5
  2.2.3. Assurance . . . . . . . . . . . . . . . . . . . . . . . . .   5
  2.2.3.1. Operational Assurance . . . . . . . . . . . . . . . . . .   5
  2.2.3.1.1. System Architecture . . . . . . . . . . . . . . . . . .   5
  2.2.3.1.2. System Integrity  . . . . . . . . . . . . . . . . . . .   6
  2.2.3.2. Life-Cycle Assurance  . . . . . . . . . . . . . . . . . .   6
  2.2.3.2.1. Security Testing  . . . . . . . . . . . . . . . . . . .   6
  2.2.4. Documentation . . . . . . . . . . . . . . . . . . . . . . .   6
  2.2.4.1. Security Features User's Guide  . . . . . . . . . . . . .   6
  2.2.4.2. Trusted Facility Manual . . . . . . . . . . . . . . . . .   6
  2.2.4.3. Test Documentation  . . . . . . . . . . . . . . . . . . .   6
  2.2.4.4. Design Documentation  . . . . . . . . . . . . . . . . . .   6
  3. DIVISION B:  MANDATORY PROTECTION . . . . . . . . . . . . . . .   7
  3.1. CLASS (B1):  LABELED SECURITY PROTECTION  . . . . . . . . . .   7
  3.1.1. Security Policy . . . . . . . . . . . . . . . . . . . . . .   7
  3.1.1.1. Discretionary Access Control  . . . . . . . . . . . . . .   7
  3.1.1.2. Object Reuse  . . . . . . . . . . . . . . . . . . . . . .   7
  3.1.1.3. Labels  . . . . . . . . . . . . . . . . . . . . . . . . .   7
  3.1.1.3.1. Label Integrity . . . . . . . . . . . . . . . . . . . .   8
  3.1.1.3.2. Exportation of Labeled Information  . . . . . . . . . .   8
  3.1.1.3.3. Exportation to Multilevel Devices . . . . . . . . . . .   8
  3.1.1.3.3.1. Exportation to Single-Level Devices . . . . . . . . .   8
  3.1.1.3.3.2. Labeling Human-Readable Output  . . . . . . . . . . .   8
  3.1.1.3.3.3. Footnote for ``properly'' . . . . . . . . . . . . . .   8
  3.1.1.4. Mandatory Access Control  . . . . . . . . . . . . . . . .   9
  3.1.2. Accountability  . . . . . . . . . . . . . . . . . . . . . .   9
  3.1.2.1. Identification and Authentication . . . . . . . . . . . .   9
  3.1.2.2. Audit . . . . . . . . . . . . . . . . . . . . . . . . . .   9
  3.1.3. Assurance . . . . . . . . . . . . . . . . . . . . . . . . .  10
  3.1.3.1. Operational Assurance . . . . . . . . . . . . . . . . . .  10
  3.1.3.1.1. System Architecture . . . . . . . . . . . . . . . . . .  10
  3.1.3.1.2. System Integrity  . . . . . . . . . . . . . . . . . . .  10
  3.1.3.2. Life-Cycle Assurance  . . . . . . . . . . . . . . . . . .  10
  3.1.3.2.1. Security Testing  . . . . . . . . . . . . . . . . . . .  10
  3.1.3.2.2. Design Specification and Verification . . . . . . . . .  10
  3.1.4. Documentation . . . . . . . . . . . . . . . . . . . . . . .  11
  3.1.4.1. Security Features User's Guide  . . . . . . . . . . . . .  11
  3.1.4.2. Trusted Facility Manual . . . . . . . . . . . . . . . . .  11
  3.1.4.3. Test Documentation  . . . . . . . . . . . . . . . . . . .  11
  3.1.4.4. Design Documentation  . . . . . . . . . . . . . . . . . .  11
  3.2. CLASS (B2):  STRUCTURED PROTECTION  . . . . . . . . . . . . .  11
  3.2.1. Security Policy . . . . . . . . . . . . . . . . . . . . . .  12
  3.2.1.1. Discretionary Access Control  . . . . . . . . . . . . . .  12
  3.2.1.2. Object Reuse  . . . . . . . . . . . . . . . . . . . . . .  12
  3.2.1.3. Labels  . . . . . . . . . . . . . . . . . . . . . . . . .  12
  3.2.1.3.1. Label Integrity . . . . . . . . . . . . . . . . . . . .  12
  3.2.1.3.2. Exportation of Labeled Information  . . . . . . . . . .  12
  3.2.1.3.2.1. Exportation to Multilevel Devices . . . . . . . . . .  12
  3.2.1.3.2.2. Exportation to Single-Level Devices . . . . . . . . .  13
  3.2.1.3.2.3. Labeling Human-Readable Output  . . . . . . . . . . .  13
  3.2.1.3.3. Subject Sensitivity Labels  . . . . . . . . . . . . . .  13
  3.2.1.3.4. Device Labels . . . . . . . . . . . . . . . . . . . . .  13
  3.2.1.4. Mandatory Access Control  . . . . . . . . . . . . . . . .  13
  3.2.2. Accountability  . . . . . . . . . . . . . . . . . . . . . .  14
  3.2.2.1. Identification and Authentication . . . . . . . . . . . .  14
  3.2.2.1.1. Trusted Path  . . . . . . . . . . . . . . . . . . . . .  14
  3.2.2.2. Audit . . . . . . . . . . . . . . . . . . . . . . . . . .  14
  3.2.3. Assurance . . . . . . . . . . . . . . . . . . . . . . . . .  15
  3.2.3.1. Operational Assurance . . . . . . . . . . . . . . . . . .  15
  3.2.3.1.1. System Architecture . . . . . . . . . . . . . . . . . .  15
  3.2.3.1.2. System Integrity  . . . . . . . . . . . . . . . . . . .  15
  3.2.3.1.3. Covert Channel Analysis . . . . . . . . . . . . . . . .  15
  3.2.3.1.4. Trusted Facility Management . . . . . . . . . . . . . .  15
  3.2.3.2. Life-Cycle Assurance  . . . . . . . . . . . . . . . . . .  15
  3.2.3.2.1. Security Testing  . . . . . . . . . . . . . . . . . . .  15
  3.2.3.2.2. Design Specification and Verification . . . . . . . . .  16
  3.2.3.2.3. Configuration Management  . . . . . . . . . . . . . . .  16
  3.2.4. Documentation . . . . . . . . . . . . . . . . . . . . . . .  16
  3.2.4.1. Security Features User's Guide  . . . . . . . . . . . . .  16
  3.2.4.2. Trusted Facility Manual . . . . . . . . . . . . . . . . .  16
  3.2.4.3. Test Documentation  . . . . . . . . . . . . . . . . . . .  16
  3.2.4.4. Design Documentation  . . . . . . . . . . . . . . . . . .  17
  3.3. CLASS (B3):  SECURITY DOMAINS . . . . . . . . . . . . . . . .  17
  3.3.1. Security Policy . . . . . . . . . . . . . . . . . . . . . .  17
  3.3.1.1. Discretionary Access Control  . . . . . . . . . . . . . .  17
  3.3.1.2. Object Reuse  . . . . . . . . . . . . . . . . . . . . . .  17
  3.3.1.3. Labels  . . . . . . . . . . . . . . . . . . . . . . . . .  18
  3.3.1.3.1. Label Integrity . . . . . . . . . . . . . . . . . . . .  18
  3.3.1.3.2. Exportation of Labeled Information  . . . . . . . . . .  18
  3.3.1.3.2.1. Exportation to Multilevel Devices . . . . . . . . . .  18
  3.3.1.3.2.2. Exportation to Single-Level Devices . . . . . . . . .  18
  3.3.1.3.2.3. Labeling Human-Readable Output  . . . . . . . . . . .  18
  3.3.1.3.3. Subject Sensitivity Labels  . . . . . . . . . . . . . .  19
  3.3.1.3.4. Device Labels . . . . . . . . . . . . . . . . . . . . .  19
  3.3.1.4. Mandatory Access Control  . . . . . . . . . . . . . . . .  19
  3.3.2. Accountability  . . . . . . . . . . . . . . . . . . . . . .  19
  3.3.2.1. Identification and Authentication . . . . . . . . . . . .  19
  3.3.2.1.1. Trusted Path  . . . . . . . . . . . . . . . . . . . . .  20
  3.3.2.2. Audit . . . . . . . . . . . . . . . . . . . . . . . . . .  20
  3.3.3. Assurance . . . . . . . . . . . . . . . . . . . . . . . . .  20
  3.3.3.1. Operational Assurance . . . . . . . . . . . . . . . . . .  20
  3.3.3.1.1. System Architecture . . . . . . . . . . . . . . . . . .  20
  3.3.3.1.2. System Integrity  . . . . . . . . . . . . . . . . . . .  21
  3.3.3.1.3. Covert Channel Analysis . . . . . . . . . . . . . . . .  21
  3.3.3.1.4. Trusted Facility Management . . . . . . . . . . . . . .  21
  3.3.3.1.5. Trusted Recovery  . . . . . . . . . . . . . . . . . . .  21
  3.3.3.2. Life-Cycle Assurance  . . . . . . . . . . . . . . . . . .  21
  3.3.3.2.1. Security Testing  . . . . . . . . . . . . . . . . . . .  21
  3.3.3.2.2. Design Specification and Verification . . . . . . . . .  22
  3.3.3.2.3. Configuration Management  . . . . . . . . . . . . . . .  22
  3.3.4. Documentation . . . . . . . . . . . . . . . . . . . . . . .  22
  3.3.4.1. Security Features User's Guide  . . . . . . . . . . . . .  22
  3.3.4.2. Trusted Facility Manual . . . . . . . . . . . . . . . . .  22
  3.3.4.3. Test Documentation  . . . . . . . . . . . . . . . . . . .  23
  3.3.4.4. Design Documentation  . . . . . . . . . . . . . . . . . .  23
  4. DIVISION A:  VERIFIED PROTECTION  . . . . . . . . . . . . . . .  24
  4.1. CLASS (A1):  VERIFIED DESIGN  . . . . . . . . . . . . . . . .  24
  4.1.1. Security Policy . . . . . . . . . . . . . . . . . . . . . .  25
  4.1.1.1. Discretionary Access Control  . . . . . . . . . . . . . .  25
  4.1.1.2. Object Reuse  . . . . . . . . . . . . . . . . . . . . . .  25
  4.1.1.3. Labels  . . . . . . . . . . . . . . . . . . . . . . . . .  25
  4.1.1.3.1. Label Integrity . . . . . . . . . . . . . . . . . . . .  25
  4.1.1.3.2. Exportation of Labeled Information  . . . . . . . . . .  25
  4.1.1.3.2.1. Exportation to Multilevel Devices . . . . . . . . . .  25
  4.1.1.3.2.2. Exportation to Single-Level Devices . . . . . . . . .  26
  4.1.1.3.2.3. Labeling Human-Readable Output  . . . . . . . . . . .  26
  4.1.1.3.3. Subject Sensitivity Labels  . . . . . . . . . . . . . .  26
  4.1.1.3.4. Device Labels . . . . . . . . . . . . . . . . . . . . .  26
  4.1.1.4. Mandatory Access Control  . . . . . . . . . . . . . . . .  26
  4.1.2. Accountability  . . . . . . . . . . . . . . . . . . . . . .  27
  4.1.2.1. Identification and Authentication . . . . . . . . . . . .  27
  4.1.2.1.1. Trusted Path  . . . . . . . . . . . . . . . . . . . . .  27
  4.1.2.2. Audit . . . . . . . . . . . . . . . . . . . . . . . . . .  27
  4.1.3. Assurance . . . . . . . . . . . . . . . . . . . . . . . . .  28
  4.1.3.1. Operational Assurance . . . . . . . . . . . . . . . . . .  28
  4.1.3.1.1. System Architecture . . . . . . . . . . . . . . . . . .  28
  4.1.3.1.2. System Integrity  . . . . . . . . . . . . . . . . . . .  28
  4.1.3.1.3. Covert Channel Analysis . . . . . . . . . . . . . . . .  28
  4.1.3.1.4. Trusted Facility Management . . . . . . . . . . . . . .  28
  4.1.3.1.5. Trusted Recovery  . . . . . . . . . . . . . . . . . . .  29
  4.1.3.2. Life-Cycle Assurance  . . . . . . . . . . . . . . . . . .  29
  4.1.3.2.1. Security Testing  . . . . . . . . . . . . . . . . . . .  29
  4.1.3.2.2. Design Specification and Verification . . . . . . . . .  29
  4.1.3.2.3. Configuration Management  . . . . . . . . . . . . . . .  29
  4.1.3.2.4. Trusted Distribution  . . . . . . . . . . . . . . . . .  30
  4.1.4. Documentation . . . . . . . . . . . . . . . . . . . . . . .  30
  4.1.4.1. Security Features User's Guide  . . . . . . . . . . . . .  30
  4.1.4.2. Trusted Facility Manual . . . . . . . . . . . . . . . . .  30
  4.1.4.3. Test Documentation  . . . . . . . . . . . . . . . . . . .  30
  4.1.4.4. Design Documentation  . . . . . . . . . . . . . . . . . .  31
  4.2. BEYOND CLASS (A1) . . . . . . . . . . . . . . . . . . . . . .  31
  5. CONTROL OBJECTIVES FOR TRUSTED COMPUTER SYSTEMS . . . . . . . .  33
  5.1. A NEED FOR CONSENSUS  . . . . . . . . . . . . . . . . . . . .  33
  5.2. DEFINITION AND USEFULNESS . . . . . . . . . . . . . . . . . .  33
  5.3. CRITERIA CONTROL OBJECTIVES . . . . . . . . . . . . . . . . .  34
  5.3.1. Security Policy . . . . . . . . . . . . . . . . . . . . . .  34
  5.3.1.1. Mandatory Security Policy . . . . . . . . . . . . . . . .  35
  5.3.1.2. Discretionary Security Policy . . . . . . . . . . . . . .  35
  5.3.1.3. Marking . . . . . . . . . . . . . . . . . . . . . . . . .  36
  5.3.2. Accountability  . . . . . . . . . . . . . . . . . . . . . .  36
  5.3.3. Assurance . . . . . . . . . . . . . . . . . . . . . . . . .  37
  6. RATIONALE BEHIND THE EVALUATION CLASSES . . . . . . . . . . . .  39
  6.1. THE REFERENCE MONITOR CONCEPT . . . . . . . . . . . . . . . .  39
  6.2. A FORMAL SECURITY POLICY MODEL  . . . . . . . . . . . . . . .  39
  6.3. THE TRUSTED COMPUTING BASE  . . . . . . . . . . . . . . . . .  40
  6.4. ASSURANCE . . . . . . . . . . . . . . . . . . . . . . . . . .  41
  6.5. THE CLASSES . . . . . . . . . . . . . . . . . . . . . . . . .  42
  7. THE RELATIONSHIP BETWEEN POLICY AND THE CRITERIA  . . . . . . .  43
  7.1. ESTABLISHED FEDERAL POLICIES  . . . . . . . . . . . . . . . .  43
  7.2. DOD POLICIES  . . . . . . . . . . . . . . . . . . . . . . . .  44
  7.2.1. Federal agencies footnote . . . . . . . . . . . . . . . . .  45
  7.3. CRITERIA CONTROL OBJECTIVE FOR SECURITY POLICY  . . . . . . .  45
  7.3.1. Marking . . . . . . . . . . . . . . . . . . . . . . . . . .  45
  7.3.2. Mandatory Security  . . . . . . . . . . . . . . . . . . . .  46
  7.3.3. Discretionary Security  . . . . . . . . . . . . . . . . . .  47
  7.4. CRITERIA CONTROL OBJECTIVE FOR ACCOUNTABILITY . . . . . . . .  48
  7.5. CRITERIA CONTROL OBJECTIVE FOR ASSURANCE  . . . . . . . . . .  50
  8. A GUIDELINE ON COVERT CHANNELS  . . . . . . . . . . . . . . . .  53
  9. A GUIDELINE ON CONFIGURING MANDATORY ACCESS CONTROL FEA-
  TURES  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  54
  10. A GUIDELINE ON SECURITY TESTING  . . . . . . . . . . . . . . .  55
  10.1. TESTING FOR DIVISION C . . . . . . . . . . . . . . . . . . .  55
  10.1.1. Personnel  . . . . . . . . . . . . . . . . . . . . . . . .  55
  10.1.2. Testing  . . . . . . . . . . . . . . . . . . . . . . . . .  55
  10.2. TESTING FOR DIVISION B . . . . . . . . . . . . . . . . . . .  55
  10.2.1. Personnel  . . . . . . . . . . . . . . . . . . . . . . . .  55
  10.2.2. Testing  . . . . . . . . . . . . . . . . . . . . . . . . .  55
  10.3. TESTING FOR DIVISION A . . . . . . . . . . . . . . . . . . .  56
  10.3.1. Personnel  . . . . . . . . . . . . . . . . . . . . . . . .  56
  10.3.2. Testing  . . . . . . . . . . . . . . . . . . . . . . . . .  56

























































