home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / secpubs / itsec.txt < prev    next >
Text File  |  1995-09-15  |  306KB  |  8,137 lines
  1.  
  2.  
  3.  
  4. Information  Technology
  5. Security  Evaluation  Criteria
  6. ( ITSEC )
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.  
  17.  
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.  
  26.  
  27.  
  28. Harmonised Criteria of
  29. France  -  Germany  -  the Netherlands  -  the United Kingdom
  30.  
  31.  
  32.  
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41. Following extensive international review version 1.2 
  42. of the ITSEC is issued, with the approval of the 
  43. (informal) EC advisory group, SOG-IS (Senior Officials 
  44. Group - Information Systems Security), for operational 
  45. use within evaluation and certification schemes, for a 
  46. provisional period of two years from the date of 
  47. issue.  The practical experience acquired will be used 
  48. to review and further develop the ITSEC at the end of 
  49. this period.  In addition, considerations arising from 
  50. further international harmonisation will also be taken 
  51. into account.
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.  
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83. Printed and published by the Department of Trade and Industry,
  84. London, June 1991
  85.  
  86. _  Controller, HMSO 1991.
  87.  
  88. CONTENTS
  89.  
  90.      Page
  91.  
  92. 0    INTRODUCTION   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  
  93. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .          1
  94.  
  95. 1    SCOPE     .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  . 
  96.  
  97. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .          7
  98. 1.1  Technical Security Measures   .  .  .  .  .  .  .  .  .  .  
  99. .  .  .  .  .  .  .  .  .  .  .  .  .          7
  100. 1.4  Systems and Products     .  .  .  .  .  .  .  .  .  .  .  . 
  101.  
  102. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .          7
  103. 1.9  Functionality and Assurance, Classes and Levels   .  .  .  
  104. .  .  .  .  .  .  .  .  .          8
  105. 1.21 Assurance Profiles  .  .  .  .  .  .  .  .  .  .  .  .  .  
  106. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        10
  107. 1.23 The Evaluation Process   .  .  .  .  .  .  .  .  .  .  .  . 
  108.  
  109. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        11
  110. 1.31 The Certification Process     .  .  .  .  .  .  .  .  .  .  
  111. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        12
  112. 1.35 Relationship to the TCSEC     .  .  .  .  .  .  .  .  .  .  
  113. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        13
  114.  
  115. 2    FUNCTIONALITY  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  
  116. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        19
  117. 2.1  Introduction   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  
  118. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        19
  119. 2.3  The Security Target .  .  .  .  .  .  .  .  .  .  .  .  .  
  120. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        19
  121. 2.31 Generic Headings    .  .  .  .  .  .  .  .  .  .  .  .  .  
  122. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        24
  123. 2.59 Predefined Classes  .  .  .  .  .  .  .  .  .  .  .  .  .  
  124. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        28
  125. 2.65 Specification Style .  .  .  .  .  .  .  .  .  .  .  .  .  
  126. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        30
  127. 2.81 Formal Models of Security Policy   .  .  .  .  .  .  .  .  
  128. .  .  .  .  .  .  .  .  .  .  .  .  .        33
  129.  
  130. 3    ASSURANCE - EFFECTIVENESS     .  .  .  .  .  .  .  .  .  .  
  131. .  .  .  .  .  .  .  .  .  .        35
  132. 3.1  Introduction   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  
  133. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        35
  134. 3.2  Description of the Approach   .  .  .  .  .  .  .  .  .  .  
  135. .  .  .  .  .  .  .  .  .  .  .  .  .        35
  136. 3.11 Systems and Products     .  .  .  .  .  .  .  .  .  .  .  . 
  137.  
  138. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        37
  139. 3.12 Effectiveness Criteria - Construction   .  .  .  .  .  .  . 
  140.  
  141. .  .  .  .  .  .  .  .  .  .  .  .        37
  142. 3.13 Aspect 1 - Suitability of Functionality .  .  .  .  .  .  . 
  143.  
  144. .  .  .  .  .  .  .  .  .  .  .  .        37
  145. 3.17 Aspect 2 - Binding of Functionality     .  .  .  .  .  .  . 
  146.  
  147. .  .  .  .  .  .  .  .  .  .  .  .  .        38
  148. 3.21 Aspect 3 - Strength of Mechanisms  .  .  .  .  .  .  .  .  
  149. .  .  .  .  .  .  .  .  .  .  .  .        39
  150. 3.25 Aspect 4 - Construction Vulnerability Assessment  .  .  .  
  151. .  .  .  .  .  .  .  .        40
  152. 3.29 Effectiveness Criteria - Operation .  .  .  .  .  .  .  .  
  153. .  .  .  .  .  .  .  .  .  .  .  .        41
  154. 3.30 Aspect 1 - Ease of Use   .  .  .  .  .  .  .  .  .  .  .  . 
  155.  
  156. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        41
  157. 3.34 Aspect 2 - Operational Vulnerability Assessment   .  .  .  
  158. .  .  .  .  .  .  .  .  .  .        42
  159.  
  160. 4    ASSURANCE - CORRECTNESS  .  .  .  .  .  .  .  .  .  .  .  . 
  161.  
  162. .  .  .  .  .  .  .  .  .        45
  163. 4.1  Introduction   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  
  164. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        45
  165. 4.2  Characterisation    .  .  .  .  .  .  .  .  .  .  .  .  .  
  166. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        45
  167. 4.11 Summary of Requirements  .  .  .  .  .  .  .  .  .  .  .  . 
  168.  
  169. .  .  .  .  .  .  .  .  .  .  .  .  .        46
  170. 4.12 Approach to Descriptions .  .  .  .  .  .  .  .  .  .  .  . 
  171.  
  172. .  .  .  .  .  .  .  .  .  .  .  .  .        50
  173. 4.17 Layout of Correctness Criteria     .  .  .  .  .  .  .  .  
  174. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        51
  175. E1   Level E1  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  . 
  176.  
  177. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        55
  178. E1.1 Construction - The Development Process  .  .  .  .  .  .  . 
  179.  
  180. .  .  .  .  .  .  .  .  .  .        55
  181. E1.2 Phase 1 - Requirements   .  .  .  .  .  .  .  .  .  .  .  . 
  182.  
  183. .  .  .  .  .  .  .  .  .  .  .  .  .  .        55
  184. E1.5 Phase 2 - Architectural Design     .  .  .  .  .  .  .  .  
  185. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        56
  186. E1.8 Phase 3 - Detailed Design     .  .  .  .  .  .  .  .  .  .  
  187. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        56
  188. E1.11     Phase 4 - Implementation .  .  .  .  .  .  .  .  .  .  
  189. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        56
  190. E1.14     Construction - The Development Environment   .  .  .  
  191. .  .  .  .  .  .  .  .  .  .        57
  192. E1.15     Aspect 1 - Configuration Control   .  .  .  .  .  .  . 
  193.  
  194. .  .  .  .  .  .  .  .  .  .  .  .  .  .        57
  195. E1.18     Aspect 2 - Programming Languages and Compilers    .  . 
  196.  
  197. .  .  .  .  .  .  .  .  .        58
  198. E1.21     Aspect 3 - Developers Security     .  .  .  .  .  .  . 
  199.  
  200. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        58
  201. E1.24     Operation - The Operational Documentation    .  .  .  
  202. .  .  .  .  .  .  .  .  .  .  .        58
  203. E1.25     Aspect 1 - User Documentation .  .  .  .  .  .  .  .  
  204. .  .  .  .  .  .  .  .  .  .  .  .  .  .        59
  205. E1.28     Aspect 2 - Administration Documentation .  .  .  .  .  
  206. .  .  .  .  .  .  .  .  .  .  .        59
  207. E1.31     Operation - The Operational Environment .  .  .  .  .  
  208. .  .  .  .  .  .  .  .  .  .        60
  209. E1.32     Aspect 1 - Delivery and Configuration   .  .  .  .  .  
  210. .  .  .  .  .  .  .  .  .  .  .  .  .        60
  211. E1.35     Aspect 2 - Start-up and Operation  .  .  .  .  .  .  . 
  212.  
  213. .  .  .  .  .  .  .  .  .  .  .  .  .  .        60
  214. E2   Level E2  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  . 
  215.  
  216. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        62
  217. E2.1 Construction - The Development Process  .  .  .  .  .  .  . 
  218.  
  219. .  .  .  .  .  .  .  .  .  .        62
  220. E2.2 Phase 1 - Requirements   .  .  .  .  .  .  .  .  .  .  .  . 
  221.  
  222. .  .  .  .  .  .  .  .  .  .  .  .  .  .        62
  223. E2.5 Phase 2 - Architectural Design     .  .  .  .  .  .  .  .  
  224. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        63
  225. E2.8 Phase 3 - Detailed Design     .  .  .  .  .  .  .  .  .  .  
  226. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        63
  227. E2.11     Phase 4 - Implementation .  .  .  .  .  .  .  .  .  .  
  228. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        64
  229. E2.14     Construction - The Development Environment   .  .  .  
  230. .  .  .  .  .  .  .  .  .  .  .        64
  231. E2.15     Aspect 1 - Configuration Control   .  .  .  .  .  .  . 
  232.  
  233. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        65
  234. E2.18     Aspect 2 - Programming Languages and Compilers    .  . 
  235.  
  236. .  .  .  .  .  .  .  .  .  .        65
  237. E2.21     Aspect 3 - Developers Security     .  .  .  .  .  .  . 
  238.  
  239. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        66
  240. E2.24     Operation - The Operational Documentation    .  .  .  
  241. .  .  .  .  .  .  .  .  .  .  .  .        66
  242. E2.25     Aspect 1 - User Documentation .  .  .  .  .  .  .  .  
  243. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        66
  244. E2.28     Aspect 2 - Administration Documentation .  .  .  .  .  
  245. .  .  .  .  .  .  .  .  .  .  .        67
  246. E2.31     Operation - The Operational Environment .  .  .  .  .  
  247. .  .  .  .  .  .  .  .  .  .        68
  248. E2.32     Aspect 1 - Delivery and Configuration   .  .  .  .  .  
  249. .  .  .  .  .  .  .  .  .  .  .  .  .  .        68
  250. E2.35     Aspect 2 - Start-up and Operation  .  .  .  .  .  .  . 
  251.  
  252. .  .  .  .  .  .  .  .  .  .  .  .  .  .        68
  253. E3   Level E3  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  . 
  254.  
  255. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        70
  256. E3.1 Construction - The Development Process  .  .  .  .  .  .  . 
  257.  
  258. .  .  .  .  .  .  .  .  .  .        70
  259. E3.2 Phase 1 - Requirements   .  .  .  .  .  .  .  .  .  .  .  . 
  260.  
  261. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        70
  262. E3.5 Phase 2 - Architectural Design     .  .  .  .  .  .  .  .  
  263. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        71
  264. E3.8 Phase 3 - Detailed Design     .  .  .  .  .  .  .  .  .  .  
  265. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        71
  266. E3.11     Phase 4 - Implementation .  .  .  .  .  .  .  .  .  .  
  267. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        72
  268. E3.14     Construction - The Development Environment   .  .  .  
  269. .  .  .  .  .  .  .  .  .  .  .        73
  270. E3.15     Aspect 1 - Configuration Control   .  .  .  .  .  .  . 
  271.  
  272. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        73
  273. E3.18     Aspect 2 - Programming Languages and Compilers    .  . 
  274.  
  275. .  .  .  .  .  .  .  .  .  .        74
  276. E3.21     Aspect 3 - Developers Security     .  .  .  .  .  .  . 
  277.  
  278. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        74
  279. E3.24     Operation - The Operational Documentation    .  .  .  
  280. .  .  .  .  .  .  .  .  .  .  .  .        75
  281. E3.25     Aspect 1 - User Documentation .  .  .  .  .  .  .  .  
  282. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        75
  283. E3.28     Aspect 2 - Administration Documentation .  .  .  .  .  
  284. .  .  .  .  .  .  .  .  .  .  .        76
  285. E3.31     Operation - The Operational Environment .  .  .  .  .  
  286. .  .  .  .  .  .  .  .  .  .        76
  287. E3.32     Aspect 1 - Delivery and Configuration   .  .  .  .  .  
  288. .  .  .  .  .  .  .  .  .  .  .  .  .  .        77
  289. E3.35     Aspect 2 - Start-up and Operation  .  .  .  .  .  .  . 
  290.  
  291. .  .  .  .  .  .  .  .  .  .  .  .  .  .        77
  292. E4   Level E4  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  . 
  293.  
  294. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        79
  295. E4.1 Construction - The Development Process  .  .  .  .  .  .  . 
  296.  
  297. .  .  .  .  .  .  .  .  .  .        79
  298. E4.2 Phase 1 - Requirements   .  .  .  .  .  .  .  .  .  .  .  . 
  299.  
  300. .  .  .  .  .  .  .  .  .  .  .  .  .  .        79
  301. E4.5 Phase 2 - Architectural Design     .  .  .  .  .  .  .  .  
  302. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        80
  303. E4.8 Phase 3 - Detailed Design     .  .  .  .  .  .  .  .  .  .  
  304. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        81
  305. E4.11     Phase 4 - Implementation .  .  .  .  .  .  .  .  .  .  
  306. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        82
  307. E4.14     Construction - The Development Environment   .  .  .  
  308. .  .  .  .  .  .  .  .  .  .  .        82
  309. E4.15     Aspect 1 - Configuration Control   .  .  .  .  .  .  . 
  310.  
  311. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        83
  312. E4.18     Aspect 2 - Programming Languages and Compilers    .  . 
  313.  
  314. .  .  .  .  .  .  .  .  .  .        83
  315. E4.21     Aspect 3 - Developers Security     .  .  .  .  .  .  . 
  316.  
  317. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        84
  318. E4.24     Operation - The Operational Documentation    .  .  .  
  319. .  .  .  .  .  .  .  .  .  .  .  .        85
  320. E4.25     Aspect 1 - User Documentation .  .  .  .  .  .  .  .  
  321. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        85
  322. E4.28     Aspect 2 - Administration Documentation .  .  .  .  .  
  323. .  .  .  .  .  .  .  .  .  .  .        85
  324. E4.31     Operation - The Operational Environment .  .  .  .  .  
  325. .  .  .  .  .  .  .  .  .  .        86
  326. E4.32     Aspect 1 - Delivery and Configuration   .  .  .  .  .  
  327. .  .  .  .  .  .  .  .  .  .  .  .  .  .        86
  328. E4.35     Aspect 2 - Start-up and Operation  .  .  .  .  .  .  . 
  329.  
  330. .  .  .  .  .  .  .  .  .  .  .  .  .  .        87
  331. E5   Level E5  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  . 
  332.  
  333. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        88
  334. E5.1 Construction - The Development Process  .  .  .  .  .  .  . 
  335.  
  336. .  .  .  .  .  .  .  .  .  .        88
  337. E5.2 Phase 1 - Requirements   .  .  .  .  .  .  .  .  .  .  .  . 
  338.  
  339. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        88
  340. E5.5 Phase 2 - Architectural Design     .  .  .  .  .  .  .  .  
  341. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        89
  342. E5.8 Phase 3 - Detailed Design     .  .  .  .  .  .  .  .  .  .  
  343. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        90
  344. E5.11     Phase 4 - Implementation .  .  .  .  .  .  .  .  .  .  
  345. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        91
  346. E5.14     Construction - The Development Environment   .  .  .  
  347. .  .  .  .  .  .  .  .  .  .  .        91
  348. E5.15     Aspect 1 - Configuration Control   .  .  .  .  .  .  . 
  349.  
  350. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        92
  351. E5.18     Aspect 2 - Programming Languages and Compilers    .  . 
  352.  
  353. .  .  .  .  .  .  .  .  .  .        93
  354. E5.21     Aspect 3 - Developers Security     .  .  .  .  .  .  . 
  355.  
  356. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        94
  357. E5.24     Operation - The Operational Documentation    .  .  .  
  358. .  .  .  .  .  .  .  .  .  .  .  .        94
  359. E5.25     Aspect 1 - User Documentation .  .  .  .  .  .  .  .  
  360. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        94
  361. E5.28     Aspect 2 - Administration Documentation .  .  .  .  .  
  362. .  .  .  .  .  .  .  .  .  .  .        95
  363. E5.31     Operation - The Operational Environment .  .  .  .  .  
  364. .  .  .  .  .  .  .  .  .  .        96
  365. E5.32     Aspect 1 - Delivery and Configuration   .  .  .  .  .  
  366. .  .  .  .  .  .  .  .  .  .  .  .  .  .        96
  367. E5.35     Aspect 2 - Start-up and Operation  .  .  .  .  .  .  . 
  368.  
  369. .  .  .  .  .  .  .  .  .  .  .  .  .  .        96
  370. E6   Level E6  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  . 
  371.  
  372. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        98
  373. E6.1 Construction - The Development Process  .  .  .  .  .  .  . 
  374.  
  375. .  .  .  .  .  .  .  .  .  .        98
  376. E6.2 Phase 1 - Requirements   .  .  .  .  .  .  .  .  .  .  .  . 
  377.  
  378. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        98
  379. E6.5 Phase 2 - Architectural Design     .  .  .  .  .  .  .  .  
  380. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .        99
  381. E6.8 Phase 3 - Detailed Design     .  .  .  .  .  .  .  .  .  .  
  382. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      100
  383. E6.11     Phase 4 - Implementation .  .  .  .  .  .  .  .  .  .  
  384. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      101
  385. E6.14     Construction - The Development Environment   .  .  .  
  386. .  .  .  .  .  .  .  .  .  .  .      102
  387. E6.15     Aspect 1 - Configuration Control   .  .  .  .  .  .  . 
  388.  
  389. .  .  .  .  .  .  .  .  .  .  .  .  .  .      102
  390. E6.18     Aspect 2 - Programming Languages and Compilers    .  . 
  391.  
  392. .  .  .  .  .  .  .  .  .      103
  393. E6.21     Aspect 3 - Developers Security     .  .  .  .  .  .  . 
  394.  
  395. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      104
  396. E6.24     Operation - The Operational Documentation    .  .  .  
  397. .  .  .  .  .  .  .  .  .  .  .  .      104
  398. E6.25     Aspect 1 - User Documentation .  .  .  .  .  .  .  .  
  399. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      104
  400. E6.28     Aspect 2 - Administration Documentation .  .  .  .  .  
  401. .  .  .  .  .  .  .  .  .  .  .      105
  402. E6.31     Operation - The Operational Environment .  .  .  .  .  
  403. .  .  .  .  .  .  .  .  .  .      106
  404. E6.32     Aspect 1 - Delivery and Configuration   .  .  .  .  .  
  405. .  .  .  .  .  .  .  .  .  .  .  .  .  .      106
  406. E6.35     Aspect 2 - Start-up and Operation  .  .  .  .  .  .  . 
  407.  
  408. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      106
  409.  
  410. 5    RESULTS OF EVALUATION    .  .  .  .  .  .  .  .  .  .  .  . 
  411.  
  412. .  .  .  .  .  .  .  .  .  .  .      109
  413. 5.1  Introduction   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  
  414. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      109
  415. 5.2  Rating    .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  . 
  416.  
  417. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      
  418. 109
  419.  
  420. 6    GLOSSARY AND REFERENCES  .  .  .  .  .  .  .  .  .  .  .  . 
  421.  
  422. .  .  .  .  .  .  .  .  .      111
  423. 6.1  Introduction   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  
  424. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      111
  425. 6.2  Definitions    .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  
  426. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      111
  427. 6.78 References     .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  
  428. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      117
  429.  
  430. Annex A - EXAMPLE FUNCTIONALITY CLASSES .  .  .  .  .  .  .  .  
  431. .  .  .  .  .  .  .      121
  432. A.1  Introduction   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  
  433. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      121
  434. A.7  Example Functionality Class F-C1   .  .  .  .  .  .  .  .  
  435. .  .  .  .  .  .  .  .  .  .  .  .  .  .      122
  436. A.11 Example Functionality Class F-C2   .  .  .  .  .  .  .  .  
  437. .  .  .  .  .  .  .  .  .  .  .  .  .  .      123
  438. A.19 Example Functionality Class F-B1   .  .  .  .  .  .  .  .  
  439. .  .  .  .  .  .  .  .  .  .  .  .  .  .      126
  440. A.36 Example Functionality Class F-B2   .  .  .  .  .  .  .  .  
  441. .  .  .  .  .  .  .  .  .  .  .  .  .  .      130
  442. A.57 Example Functionality Class F-B3   .  .  .  .  .  .  .  .  
  443. .  .  .  .  .  .  .  .  .  .  .  .  .  .      135
  444. A.79 Example Functionality Class F-IN   .  .  .  .  .  .  .  .  
  445. .  .  .  .  .  .  .  .  .  .  .  .  .  .      140
  446. A.87 Example Functionality Class F-AV   .  .  .  .  .  .  .  .  
  447. .  .  .  .  .  .  .  .  .  .  .  .  .  .      143
  448. A.90 Example Functionality Class F-DI   .  .  .  .  .  .  .  .  
  449. .  .  .  .  .  .  .  .  .  .  .  .  .  .      144
  450. A.98 Example Functionality Class F-DC   .  .  .  .  .  .  .  .  
  451. .  .  .  .  .  .  .  .  .  .  .  .  .  .      146
  452. A.100     Example Functionality Class F-DX   .  .  .  .  .  .  . 
  453.  
  454. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .      147
  455.  
  456. Annex B - THE CLAIMS LANGUAGE .  .  .  .  .  .  .  .  .  .  .  . 
  457.  
  458. .  .  .  .  .  .  .  .  .  .  .      151
  459.  
  460.  
  461. FIGURES
  462.  
  463. Fig. 1  IT System   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  
  464. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .       
  465.  
  466. 16
  467. Fig. 2  IT Product  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  
  468. .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .       
  469.  
  470. 16
  471. Fig. 3  Development and Evaluation Process   .  .  .  .  .  .  . 
  472.  
  473. .  .  .  .  .  .  .  .  .  .  .  .        17
  474. Fig. 4  Information used in a Vulnerability Analysis   .  .  .  
  475. .  .  .  .  .  .  .  .  .  .  .  .        44
  476.  
  477.  
  478.  
  479.  
  480. 0    INTRODUCTION
  481.  
  482.  
  483. 0.1  In the course of only four decades, Information Technology 
  484. (IT) has come to play an important, and often vital, role 
  485. in almost all sectors of organised societies.  As a 
  486. consequence, security has become an essential aspect of 
  487. Information Technology.
  488.  
  489. 0.2  In this context, IT security means,
  490.  
  491.      -    confidentiality - prevention of the unauthorised 
  492. disclosure of information;
  493.  
  494.      -    integrity - prevention of the unauthorised 
  495. modification of information;
  496.  
  497.      -    availability - prevention of the unauthorised 
  498. withholding of information or resources.
  499.  
  500. 0.3  An IT system or product will have its own requirements for 
  501. maintenance of confidentiality, integrity and availability.  
  502. In order to meet these requirements it will implement a 
  503. number of technical security measures, in this document 
  504. referred to as security enforcing functions, covering, for 
  505. example, areas such as access control, auditing, and error 
  506. recovery.  Appropriate confidence in these functions will 
  507. be needed:  in this document this is referred to as 
  508. assurance, whether it is confidence in the correctness of 
  509. the security enforcing functions (both from the development 
  510. and the operational points of view) or confidence in the 
  511. effectiveness of those functions.
  512.  
  513. 0.4  Users of systems need confidence in the security of the 
  514. system they are using.  They also need a yardstick to 
  515. compare the security capabilities of IT products they are 
  516. thinking of purchasing.  Although users could rely upon the 
  517. word of the manufacturers or vendors of the systems and 
  518. products in question, or they could test them themselves, 
  519. it is likely that many users will prefer to rely on the 
  520. results of some form of impartial assessment by an 
  521. independent body.  Such an evaluation of a system or 
  522. product requires objective and well-defined security 
  523. evaluation criteria and the existence of a certification 
  524. body that can confirm that the evaluation has been properly 
  525. conducted.  System security targets will be specific to the 
  526. particular needs of the users of the system in question, 
  527. whereas product security targets will be more general so 
  528. that products that meet them can be incorporated into many 
  529. systems with similar but not necessarily identical security 
  530. requirements.
  531.  
  532. 0.5  For a system, an evaluation of its security capabilities 
  533. can be viewed as a part of a more formal procedure for 
  534. accepting an IT system for use within a particular 
  535. environment.  Accreditation is the term often used to 
  536. describe this procedure.  It requires a number of factors 
  537. to be considered before a system can be viewed as fit for 
  538. its intended purpose:  it requires assurance in the 
  539. security provided by the system, a confirmation of 
  540. management responsibilities for security, compliance with 
  541. relevant technical and legal/regulatory requirements, and 
  542. confidence in the adequacy of other non-technical security 
  543. measures provided in the system environment.  The criteria 
  544. contained in this document are primarily concerned with 
  545. technical security measures, but they do address some non-
  546. technical aspects, such as secure operating procedures for 
  547. personnel, physical and procedural security (but only where 
  548. these impinge on the technical security measures).
  549.  
  550. 0.6  Much work has  been done previously on the development of 
  551. IT security evaluation criteria, although for slightly 
  552. different objectives according to the specific requirements 
  553. of the countries or bodies involved.  Most important of 
  554. these, and a precursor to other developments in many 
  555. respects, was the Trusted Computer System Evaluation 
  556. Criteria [TCSEC], commonly known as the TCSEC or "Orange 
  557. Book", published and used for product evaluation by the US 
  558. Department of Defense.  Other countries, mostly European, 
  559. also have significant experience in IT security evaluation 
  560. and have developed their own IT security criteria.  In the 
  561. UK this includes CESG Memorandum Number 3 [CESG3], 
  562. developed for government use, and  proposals of the 
  563. Department of Trade and Industry, the "Green Book" [DTIEC], 
  564. for commercial IT security products.  In Germany, the 
  565. German Information Security Agency published a first 
  566. version of its own criteria in 1989 [ZSIEC], and at the 
  567. same time criteria were being developed in France, the so-
  568. called "Blue-White-Red Book" [SCSSI].
  569.  
  570. 0.7  Seeing that work was going on in this area, and much still 
  571. needed to be done, France, Germany, the Netherlands and the 
  572. United Kingdom recognised that this work needed to be 
  573. approached in a concerted way, and that common, harmonised 
  574. IT security criteria should be put forward.  There were 
  575. three reasons for harmonisation:
  576.  
  577.      a)   much experience had been accumulated in the various 
  578. countries, and there would be much to gain by jointly 
  579. building on that experience;
  580.  
  581.      b)   industry did not want different security criteria in 
  582. the different countries;
  583.  
  584.      c)   the basic concepts and approaches were the same, 
  585. across countries and even across commercial, 
  586. government and defence applications.
  587.  
  588. 0.8  It was therefore decided to build on the various national 
  589. initiatives, taking the best features of what had already 
  590. been done and putting them in a consistent, structured 
  591. perspective.  Maximum applicability and compatibility with 
  592. existing work, most notably the US TCSEC, was a constant 
  593. consideration in this process.  Though it was initially 
  594. felt that the work would be limited to harmonisation of 
  595. existing criteria, it has sometimes been necessary to 
  596. extend what already existed.
  597.  
  598. 0.9  One reason for producing these internationally harmonised 
  599. criteria is to provide a compatible basis for certification 
  600. by the national certification bodies within the four co-
  601. operating countries, with an eventual objective of 
  602. permitting international mutual recognition of evaluation 
  603. results.
  604.  
  605. 0.10 This document sets out the harmonised criteria.  Chapter 1 
  606. contains a short presentation of the scope of the 
  607. harmonised criteria.  Chapter 2 deals with security 
  608. functionality, that is the definition and description of 
  609. security requirements.  Chapter 3 defines criteria for 
  610. evaluating assurance in the effectiveness of a Target of 
  611. Evaluation as a solution to those requirements.  Chapter 4 
  612. extends this to consideration of the correctness of the 
  613. solution.  Chapter 5 describes the permitted results of an 
  614. evaluation, and Chapter 6 contains a glossary of those 
  615. terms that take a more precise or different meaning in the 
  616. book than in normal English (on first use they are printed 
  617. in bold:  whereas italics are used for emphasis).  The 
  618. glossary is intended to help the reader not only with the 
  619. definition of words, but also with ideas and concepts that 
  620. are special to the harmonised criteria.
  621.  
  622. 0.11 The evaluation criteria in Chapters 3 and 4 are set out in 
  623. a standardised way, which specifies what must be provided 
  624. by the sponsor of the evaluation (the person or 
  625. organisation requesting evaluation) and what must be done 
  626. by the evaluator (the independent person or organisation 
  627. performing evaluation).  This categorisation is intended to 
  628. assist in ensuring the consistency and uniformity of 
  629. evaluation results.  For each area of evaluation, 
  630. documentation that must be provided by the sponsor of the 
  631. evaluation is identified.  This is then followed by the 
  632. criteria for each relevant aspect or phase of evaluation of 
  633. that area.  These criteria are broken down into 
  634. requirements for content and presentation of the relevant 
  635. documentation that must be provided by the sponsor, 
  636. requirements for evidence concerning what that 
  637. documentation must show, and the evaluator actions required 
  638. to be performed by the evaluator both to check the 
  639. documentation provided and where necessary to perform 
  640. additional tests or other activities.  In the case of 
  641. criteria concerning how the system or product is to be used 
  642. operationally, the sponsor will not, in general, be able to 
  643. provide evidence from actual use.  Thus the evaluator must 
  644. assume for the purposes of evaluation that the procedures 
  645. specified by the sponsor will be followed in practice.
  646.  
  647. 0.12 Within the criteria certain verbs are also used in a 
  648. special way.  Shall is used to express criteria which must 
  649. be satisfied;  may is used to express criteria which are 
  650. not mandatory;  and will is used to express actions to take 
  651. place in the future.  Similarly, the verbs state, describe 
  652. and explain are used within criteria to require the 
  653. provision of evidence of increasing levels of rigour.  
  654. State means that relevant facts must be provided;  describe 
  655. means that the facts must be provided and their relevant 
  656. characteristics enumerated;  explain means that the facts 
  657. must be provided, their relevant characteristics enumerated 
  658. and justifications given.
  659.  
  660. 0.13 Other than within Chapter 4, paragraphs are numbered 
  661. sequentially within each chapter.  In Chapter 4, criteria 
  662. are set out separately for each evaluation level.  The 
  663. introductory paragraphs of that chapter are numbered as in 
  664. other chapters, but then the criteria paragraphs are 
  665. numbered sequentially for each level, with the same 
  666. paragraph number covering the same topic at each level.  
  667. However, each paragraph within the document is uniquely 
  668. identified by the combination of chapter or level number 
  669. and paragraph number.
  670.  
  671. 0.14 This work draws from documents that have already been 
  672. extensively discussed and used in practice;  moreover, it 
  673. is felt that the ideas and concepts have been carefully 
  674. balanced and that the structure chosen for the ITSEC is the 
  675. right one for maximum consistency and ease of use.  The 
  676. current version of the ITSEC benefits from significant 
  677. revisions arising from widespread international review.  
  678. The review process has been assisted by the Commission for 
  679. the European Communities who organised an international 
  680. conference at which version 1.0 was discussed, and a 
  681. subsequent workshop at which an interim revision, version 
  682. 1.1, was further refined.  These events were supplemented 
  683. by written comments from reviewers, which the authors have 
  684. sought to take into account in preparing version 1.2.
  685.  
  686. 0.15 It is therefore expected that these criteria will receive 
  687. broad acceptance and use by a wide range of potential users 
  688. and market sectors;  however, it is recognised that 
  689. improvements can and will be made.  Comments and 
  690. suggestions are therefore invited, and may be sent to any 
  691. of the following addresses, bearing the marking "ITSEC 
  692. Comments":
  693.  
  694.      Commission of the European Communities
  695.      Directorate XIII/F
  696.      SOG-IS Secretariat
  697.      Rue de la Loi 200
  698.      B-1049 BRUSSELS
  699.      Belgium
  700.  
  701.      Or, for France:
  702.  
  703.      Service Central de la Sécurité des Systèmes d'Information
  704.      Division Information et Systèmes
  705.      18 Rue du Docteur Zamenhof
  706.      F-92131 ISSY LES MOULINEAUX
  707.  
  708.      For Germany:
  709.  
  710.      Bundesamt für Sicherheit in der Informationstechnik
  711.      Am Nippenkreuz 19
  712.      D-5300 BONN 2
  713.  
  714.      For the Netherlands:
  715.  
  716.      Netherlands National Comsec Agency
  717.      Bezuidenhoutseweg 67
  718.      P.O. Box 20061
  719.      NL-2500 EB THE HAGUE
  720.  
  721.      For the United Kingdom:
  722.  
  723.      Head of the Certification Body
  724.      UK IT Security Evaluation and Certification Scheme
  725.      Room 2/0805
  726.      Fiddlers Green Lane
  727.      CHELTENHAM
  728.      Glos  GB-GL52 5AJ
  729.  
  730. 0.16 Copies of the Community publication of ITSEC version 1.2 
  731. may be obtained from the Commission of the European 
  732. Communities at the above address.
  733.  
  734.  
  735.  
  736.  
  737.  
  738.  
  739.  
  740.  
  741.  
  742.  
  743.  
  744.  
  745.  
  746.  
  747.  
  748.  
  749.  
  750.  
  751.  
  752.  
  753.  
  754. This page left blank
  755.  
  756.  
  757.  
  758. 1    SCOPE
  759.  
  760.  
  761. Technical Security Measures
  762.  
  763. 1.1  A major part of the security of an IT system can often be 
  764. achieved through non-technical measures, such as 
  765. organisational, personnel, physical, and administrative 
  766. controls.  However, there is a growing tendency and need to 
  767. employ technical IT security measures.  Although the 
  768. security criteria which follow are primarily concerned with 
  769. technical security measures, they do address some non-
  770. technical aspects, most notably the related secure 
  771. operating procedures for personnel, physical and procedural 
  772. security of the systems or products involved (but only 
  773. where these impinge on the technical security measures).
  774.  
  775. 1.2  These criteria have been designed so as in the main part to 
  776. be equally applicable to technical security measures 
  777. implemented in hardware, software and firmware.  Where 
  778. particular aspects of evaluation are intended only to apply 
  779. to certain methods of implementation, this is indicated as 
  780. part of the relevant criteria.
  781.  
  782. 1.3  These criteria are not intended to cover physical aspects 
  783. of hardware security such as the provision of tamper 
  784. resistant enclosures or the control of electromagnetic 
  785. emanations.
  786.  
  787.  
  788. Systems and Products
  789.  
  790. 1.4  For the purposes of this document, the difference between 
  791. systems and products can be explained as follows.  An IT 
  792. system is a specific IT installation with a particular 
  793. purpose and known operational environment.  An IT product 
  794. is a hardware and/or software package that can be bought 
  795. off the shelf and incorporated into a variety of systems.  
  796. An IT system is generally constructed from a number of 
  797. hardware and software components.  Some components (for 
  798. example, application software) will usually be specially 
  799. constructed;  other components (for example, hardware) will 
  800. usually be standard products.  For certain applications it 
  801. may be possible to buy-in a single product to serve as a 
  802. complete system, but usually at least some customisation 
  803. and integration to meet system specific requirements will 
  804. be necessary.
  805.  
  806. 1.5  From the point of view of security, the main difference 
  807. between systems and products lies in what is certain about 
  808. their operational environment.  A system is designed to 
  809. meet the requirements of a specific group of end-users.  It 
  810. has a real world environment which can be defined and 
  811. observed in every detail;  in particular the 
  812. characteristics and requirements of its end-users will be 
  813. known, and the threats to its security are real threats 
  814. which can be determined.  A product must be suitable for 
  815. incorporation in many systems;  the product designer can 
  816. only make general assumptions about the operational 
  817. environment of a system of which it may become a component.  
  818. It is up to the person buying the product and constructing 
  819. the system to make sure that these assumptions are 
  820. consistent with the actual environment of the system.
  821.  
  822. 1.6  It is important for the sake of consistency that the same 
  823. security criteria are used for both products and systems;  
  824. it will then be both easier and cheaper to evaluate systems 
  825. containing products which have already been successfully 
  826. evaluated.  This is why these criteria deal with the 
  827. security evaluation of both IT products and IT systems.  
  828. Within the rest of this document, the term Target of 
  829. Evaluation (TOE) is used to refer to a product or system to 
  830. be evaluated.
  831.  
  832. 1.7  A TOE can be constructed from several components.  Some 
  833. components will not contribute to satisfying the security 
  834. objectives of the TOE.  Other components will contribute to 
  835. satisfying the security objectives;  these components are 
  836. called security enforcing.  Finally there may be some 
  837. components that are not security enforcing but must 
  838. nonetheless operate correctly for the TOE to enforce 
  839. security;  these are called security relevant.  The 
  840. combination of both the security enforcing components and 
  841. the security relevant components of a TOE is often referred 
  842. to as a Trusted Computing Base (TCB) (see figures 1 and 2).
  843.  
  844. 1.8  Most evaluation work will concentrate on the components of 
  845. the TOE that are stated to be security enforcing and 
  846. security relevant, but all other components within the TOE 
  847. will need to be considered during evaluation and shown to 
  848. be neither security enforcing nor security relevant.
  849.  
  850.  
  851. Functionality and Assurance, Classes and Levels
  852.  
  853. 1.9  In order for a TOE to meet its security objectives, it must 
  854. incorporate appropriate security enforcing functions, 
  855. covering, for example, areas such as access control, 
  856. auditing and error recovery.
  857.  
  858. 1.10 These functions must be defined in a way that is clear and 
  859. understandable to both the sponsor of evaluation and the 
  860. independent evaluator.  They may either be individually 
  861. specified, or they may be defined by reference to a 
  862. predefined functionality class.  These criteria include ten 
  863. example functionality classes.  These example classes are 
  864. based upon classes defined in the German National Criteria 
  865. [ZSIEC], including five classes that correspond closely to 
  866. the functionality requirements of the US Trusted Computer 
  867. System Evaluation Criteria [TCSEC].
  868.  
  869. 1.11 In all cases, the sponsor of an evaluation must define the 
  870. security target for the evaluation.  This must define the 
  871. security enforcing functions to be provided by the TOE, and 
  872. will also contain other relevant information, such as the 
  873. security objectives of the TOE and the envisaged threats to 
  874. those objectives.  Details may also be given of the 
  875. particular security mechanisms that will be used to 
  876. implement the security enforcing functions.
  877.  
  878. 1.12 The security enforcing functions selected to satisfy the 
  879. security objectives of a TOE form but one aspect of the 
  880. security target of a product or system.  No less important 
  881. is assurance that the security objectives are achieved by 
  882. the selected security enforcing functions and mechanisms.
  883.  
  884. 1.13 Assurance needs to be addressed from several different 
  885. points of view and, in these harmonised criteria, it has 
  886. been decided to distinguish confidence in the correctness 
  887. in the implementation of the security enforcing functions 
  888. and mechanisms from confidence in their effectiveness.
  889.  
  890. 1.14 Evaluation of effectiveness assesses whether the security 
  891. enforcing functions and mechanisms that are provided in the 
  892. TOE will actually satisfy the stated security objectives.  
  893. The TOE is assessed for suitability of functionality, 
  894. binding of functionality (whether the chosen functions work 
  895. together synergistically), the consequences of known and 
  896. discovered vulnerabilities (both in the construction of the 
  897. TOE and the way it will be used in live operation), and 
  898. ease of use.
  899.  
  900. 1.15 In addition, evaluation of effectiveness assesses the 
  901. ability of the security mechanisms of the TOE to withstand 
  902. direct attack (strength of mechanisms).  Three strength 
  903. levels are defined - basic, medium, and high - which 
  904. represent ascending levels of confidence in the ability of 
  905. the security mechanisms of the TOE to withstand direct 
  906. attack.
  907.  
  908. 1.16 Evaluation of correctness assesses whether the security 
  909. enforcing functions and mechanisms are implemented 
  910. correctly.  Seven evaluation levels labelled E0 to E6 have 
  911. been defined, representing ascending levels of confidence 
  912. in correctness.  E0 represents inadequate confidence.  E1 
  913. represents an entry point below which no useful confidence 
  914. can be held, and E6 represents the highest level of 
  915. confidence.  The remaining levels represent an 
  916. interpolation in between.  Correctness is addressed from 
  917. the point of view of construction of the TOE, covering both 
  918. the development process and the development environment, 
  919. and also the point of view of operation of the TOE.
  920.  
  921. 1.17 The evaluation levels are defined within the context of the 
  922. correctness criteria.  The requirements for effectiveness 
  923. (including strength of mechanisms) do not change by level, 
  924. but rather build upon the correctness assessment and are 
  925. performed using the documents provided by the sponsor for 
  926. that assessment;  of course, in practice the correctness 
  927. and effectiveness assessment activities will be 
  928. interleaved.
  929.  
  930. 1.18 If a TOE fails any aspect of evaluation at a particular 
  931. level, because of a lack of information or for any other 
  932. reason, the deficiency must be remedied, or the TOE 
  933. withdrawn from evaluation at that level.  Otherwise the TOE 
  934. will be assigned a result of E0.
  935.  
  936. 1.19 The six successful evaluation levels E1 to E6 span a wide 
  937. range of potential confidence.  Not all of these levels 
  938. will necessarily be needed by or appropriate for all market 
  939. sectors that require independent evaluation of technical 
  940. security measures.  Not all combinations of functionality 
  941. and confidence will necessarily be sensible or useful.  For 
  942. example, low confidence in the functionality required to 
  943. support a military multilevel security requirement will not 
  944. normally be appropriate.  In addition, it is unlikely that 
  945. high confidence in the correctness of a TOE will be 
  946. combined with a requirement for a low strength of 
  947. mechanisms.
  948.  
  949. 1.20 These harmonised criteria are not a design guide for secure 
  950. products or systems.  It is up to the sponsor of an 
  951. evaluation to determine the security objectives of his TOE 
  952. and to choose security functions to satisfy them.  However 
  953. for each evaluation level, the assurance part of the 
  954. criteria can be thought of as a compulsory "security 
  955. checklist" to be satisfied.
  956.  
  957.  
  958. Assurance Profiles
  959.  
  960. 1.21 The criteria in this document require the sponsor to state 
  961. the evaluation level as part of the security target.  All 
  962. of the security enforcing functions listed in the security 
  963. target are then assessed to the same level of confidence, 
  964. as required by the stated evaluation level.
  965.  
  966. 1.22 For some TOEs, there may be a requirement to gain higher 
  967. confidence in some security functions and lower confidence 
  968. in others;  for example, some security functions may be 
  969. more important than others.  In these circumstances, the 
  970. sponsor may consider producing more than one security 
  971. target for the TOE.  The details of how this is achieved, 
  972. and under what conditions, is beyond the scope of these 
  973. criteria.
  974.  
  975.  
  976.  
  977.  
  978.  
  979.  
  980. The Evaluation Process
  981.  
  982. 1.23 The objective of the evaluation process is to enable the 
  983. evaluator to prepare an impartial report stating whether or 
  984. not a TOE satisfies its security target at the level of 
  985. confidence indicated by the stated evaluation level.
  986.  
  987. 1.24 The evaluation process is shown in context within figure 3. 
  988.  
  989. It requires the close involvement of the sponsor of the 
  990. evaluation.  The higher the evaluation level, the greater 
  991. will need to be the involvement of the sponsor.  Both users 
  992. and vendors can act as sponsors for evaluation.  It is 
  993. likely that a system evaluation will be sponsored by the 
  994. intended end-users of the system or their technical 
  995. representatives, and that a product evaluation will be 
  996. sponsored by the product manufacturer or a vendor of the 
  997. product, but this need not be so.  Any party that can 
  998. supply the necessary technical information may sponsor an 
  999. evaluation.
  1000.  
  1001. 1.25 First the sponsor must determine the operational 
  1002. requirements and the threats the TOE is to counter.  In the 
  1003. case of a system, there is a need to examine the real world 
  1004. operational environment for the system, in order to 
  1005. determine the relevant  threats  that must be addressed.  
  1006. For a product, there is a need to decide what threats to 
  1007. security the product should address.  It is anticipated 
  1008. that industry organisations and international 
  1009. standardisation bodies will with time define standard 
  1010. functionality classes for use as product security targets.  
  1011. Product developers who have no predetermined specialist 
  1012. market niche or type of user in mind may find that such 
  1013. predefined functionality classes make good security targets 
  1014. to design their products to match.
  1015.  
  1016. 1.26 The security objectives for the TOE can then be determined 
  1017. considering legal and other regulations.  These form the 
  1018. contribution to security (confidentiality, integrity and 
  1019. availability) the TOE is intended to provide.  Given the 
  1020. security objectives, the necessary security enforcing 
  1021. functions can then be established, possibly in an iterative 
  1022. way, together with the evaluation level that the TOE will 
  1023. have to achieve to provide the necessary level of 
  1024. confidence.
  1025.  
  1026. 1.27 The results of this work - the definition of the security 
  1027. enforcing functions, the identified threats, the identified 
  1028. security objectives, any specific security mechanisms to be 
  1029. employed - becomes the security target for the development.
  1030.  
  1031. 1.28 For each evaluation level, the criteria enumerate items to 
  1032. be delivered by the sponsor to the evaluator.  The sponsor 
  1033. must ensure that these items are provided, taking care that 
  1034. any requirements for content and presentation are 
  1035. satisfied, and that the items clearly provide, or support 
  1036. the production of, the evidence that is called for.
  1037.  
  1038. 1.29 In order that evaluation can be performed efficiently, and 
  1039. at minimum cost, the evaluator must work closely with the 
  1040. developer and sponsor of the TOE, ideally from the 
  1041. beginning of development, to build up a good understanding 
  1042. of the security target, and to be able to pinpoint the 
  1043. evaluation implications of decisions as they are made.  
  1044. However, the evaluator must remain independent and must not 
  1045. suggest how to design or implement the TOE.  This is 
  1046. analogous to the role of an external financial auditor, who 
  1047. must likewise build up a good working relationship with a 
  1048. financial department, and in many cases will, after 
  1049. examination, make use of their internal records and 
  1050. controls.  However, he too must remain independent and 
  1051. questioning.
  1052.  
  1053. 1.30 Security test and analysis requirements within the criteria 
  1054. deserve special mention;  in all cases the responsibility 
  1055. for testing and analysis will rest with the sponsor.  For 
  1056. all evaluation levels except E1, the evaluator will 
  1057. primarily check test and analysis results supplied by the 
  1058. sponsor.  The evaluator will perform test and analysis work 
  1059. only to audit the results supplied, to supplement the 
  1060. evidence provided, and to investigate vulnerabilities.  At 
  1061. evaluation level E1 it is optional as to whether testing 
  1062. results are provided.  If not, the evaluator must in 
  1063. addition perform functional testing against the security 
  1064. target.
  1065.  
  1066.  
  1067. The Certification Process
  1068.  
  1069. 1.31 In order for these criteria to be of practical value, they 
  1070. will need to be supported by practical schemes for the 
  1071. provision and control of independent evaluation, run by 
  1072. appropriately qualified and recognised national 
  1073. certification bodies.  These bodies will award certificates 
  1074. to confirm the rating of the security of TOEs, as 
  1075. determined by properly conducted independent evaluations.  
  1076. They will approve procedures, as required by these 
  1077. criteria, for guaranteeing the authenticity of the 
  1078. delivered TOE.  They will also be responsible for the 
  1079. selection and control of approved evaluators.  Details of 
  1080. the procedures to be used by such bodies are beyond the 
  1081. scope of these criteria.
  1082.  
  1083. 1.32 These criteria have been designed to minimise the 
  1084. subjectivity inherent in evaluation results.  It will be 
  1085. the responsibility of national certification bodies to 
  1086. maintain the uniformity of certified evaluation results.  
  1087. How this is achieved is beyond the scope of these criteria.
  1088.  
  1089. 1.33 In order for the results of an evaluation against these 
  1090. criteria to be certified by a national certification body, 
  1091. the evaluator will have to produce a report containing the 
  1092. results of evaluation in a form acceptable for 
  1093. consideration by the certification body.  The precise 
  1094. format and content of such reports are beyond the scope of 
  1095. these criteria.
  1096. 1.34 Most security targets and TOEs will change with time.  The 
  1097. maintenance of a certified rating following changes to a 
  1098. TOE (whether security-related or not) or following changes 
  1099. to the security target (such as new threats or security 
  1100. objectives) will be regulated by the appropriate national 
  1101. certification body.  Re-evaluation will be necessary in 
  1102. some circumstances and not others.  The details of such 
  1103. regulations and procedures are also a matter beyond the 
  1104. scope of these criteria.
  1105.  
  1106.  
  1107. Relationship to the TCSEC
  1108.  
  1109. 1.35 The Trusted Computer System Evaluation Criteria [TCSEC], 
  1110. commonly known as the TCSEC or "Orange Book", is a widely 
  1111. known and accepted basis for the security evaluation of 
  1112. operating systems.  Originally published in 1983, it is 
  1113. used by the US Department of Defense in the US product 
  1114. evaluation scheme operated by the National Computer 
  1115. Security Center (NCSC).  The TCSEC criteria are intended to 
  1116. match the security policy of the US Department of Defense.  
  1117. This policy is primarily concerned with maintaining the 
  1118. confidentiality of nationally classified information.
  1119.  
  1120. 1.36 The TCSEC defines seven sets of evaluation criteria called 
  1121. classes (D, C1, C2, B1, B2, B3 and A1), grouped into four 
  1122. divisions (D, C, B and A).  Each criteria class covers four 
  1123. aspects of evaluation:  Security Policy, Accountability, 
  1124. Assurance and Documentation.  The criteria for these four 
  1125. areas become more detailed from class to class, and form a 
  1126. hierarchy whereby D is the lowest and A1 the highest.  Each 
  1127. class covers both functionality and confidence 
  1128. requirements.
  1129.  
  1130. 1.37 The criteria set out in the ITSEC permit selection of 
  1131. arbitrary security functions, and define seven evaluation 
  1132. levels representing increasing confidence in the ability of 
  1133. a TOE to meet its security target.  Thus these criteria can 
  1134. be applied to cover a wider range of possible systems and 
  1135. products than the TCSEC.  In general, for identical 
  1136. functionality at an equivalent level of confidence, a TOE 
  1137. has more architectural freedom to meet the ITSEC criteria 
  1138. than to meet the TCSEC, but is more constrained in its 
  1139. permissible development practices.
  1140.  
  1141. 1.38 A number of example functionality classes have been defined 
  1142. to correspond closely to the functionality requirements of 
  1143. the TCSEC classes C1 to A1.  They are included, as F-C1 to 
  1144. F-B3, amongst the example functionality classes given in 
  1145. Annex A.  It is not possible, however, to relate the 
  1146. evaluation levels directly to the confidentiality 
  1147. requirements of the TCSEC classes, as the ITSEC levels have 
  1148. been developed by harmonisation of various European IT 
  1149. security criteria schemes which contain a number of 
  1150. requirements which do not appear in the TCSEC explicitly.
  1151. 1.39 The intended correspondence between these criteria and the 
  1152. TCSEC classes is as follows:
  1153.  
  1154.           These Criteria           TCSEC Class
  1155.  
  1156.                E0        <--->                 D
  1157.  
  1158.                  F-C1, E1          <--->                 C1
  1159.  
  1160.                  F-C2, E2          <--->                 C2
  1161.  
  1162.                  F-B1, E3          <--->                 B1
  1163.  
  1164.                  F-B2, E4          <--->                 B2
  1165.  
  1166.                  F-B3, E5          <--->                 B3
  1167.  
  1168.                  F-B3, E6          <--->                 A1
  1169.  
  1170. 1.40 It should be noted that there is no functionality class F-
  1171. A1 as the functionality requirements of TCSEC class A1 are 
  1172. the same as for class B3.  A product which has been 
  1173. designed with the objective of successful evaluation 
  1174. against both the ITSEC and TCSEC, and which has been shown 
  1175. to meet one of the classes or combinations in the table 
  1176. above, should pass evaluation against the other criteria at 
  1177. the equivalent class or combination.  However, at C1 the 
  1178. TCSEC requires evidence to be provided of system developer 
  1179. testing.  Thus an [F-C1, E1] evaluation would only be 
  1180. equivalent to C1 evaluation if the sponsor had chosen to 
  1181. satisfy the optional E1 requirement to provide test 
  1182. documentation as evidence of adequate testing against the 
  1183. security target prior to evaluation.
  1184.  
  1185. 1.41 Throughout the TCSEC, the combination of both the security 
  1186. enforcing and the security relevant portions of a TOE is 
  1187. referred to as a Trusted Computing Base (TCB).  TCSEC TOEs 
  1188. representative of the higher classes in division B and 
  1189. division A derive additional confidence from increasingly 
  1190. rigorous architectural and design requirements placed on 
  1191. the TCB by the TCSEC criteria.  TCSEC classes B2 and higher 
  1192. require that access control is implemented by a reference 
  1193. validation mechanism, a mechanism which implements the 
  1194. concept of a reference monitor [AND].  Such a reference 
  1195. validation mechanism must be tamper proof, it must always 
  1196. be invoked, and it must be small enough to be subject to 
  1197. analysis and tests, the completeness of which can be 
  1198. assured.
  1199.  
  1200.  
  1201. 1.42 For compatibility with the TCSEC, the ITSEC example 
  1202. functionality classes F-B2 and F-B3 mandate that access 
  1203. control is implemented through use of such a mechanism.  In 
  1204. addition, at higher evaluation levels the ITSEC places 
  1205. architectural and design constraints on the implementation 
  1206. of all the security enforcing functions.  Combined with the 
  1207. ITSEC effectiveness requirements that security 
  1208. functionality is suitable and mutually supportive, this 
  1209. means that a TOE capable of meeting the higher ITSEC 
  1210. evaluation levels and which provides functionality matching 
  1211. these TCSEC-equivalent functionality classes, must 
  1212. necessarily satisfy the TCSEC requirements for a TCB and 
  1213. use of the reference monitor concept.
  1214.  
  1215.  
  1216.  
  1217.  
  1218.  
  1219.  
  1220.  
  1221.  
  1222.  
  1223.  
  1224.  
  1225.  
  1226.  
  1227.  
  1228.  
  1229.  
  1230.  
  1231.  
  1232.  
  1233.  
  1234.  
  1235. Fig. 1  IT System
  1236.  
  1237.  
  1238.  
  1239.  
  1240.  
  1241.  
  1242.  
  1243.  
  1244.  
  1245.  
  1246.  
  1247.  
  1248.  
  1249.  
  1250.  
  1251.  
  1252.  
  1253.  
  1254.  
  1255.  
  1256.  
  1257. Fig. 2  IT Product
  1258.  
  1259.  
  1260.  
  1261.  
  1262.  
  1263.  
  1264.  
  1265.  
  1266.  
  1267.  
  1268.  
  1269.  
  1270.  
  1271.  
  1272.  
  1273.  
  1274.  
  1275.  
  1276.  
  1277.  
  1278.  
  1279.  
  1280.  
  1281.  
  1282.  
  1283.  
  1284.  
  1285.  
  1286.  
  1287.  
  1288.  
  1289.  
  1290.  
  1291.  
  1292.  
  1293.  
  1294.  
  1295.  
  1296.  
  1297.  
  1298.  
  1299.  
  1300.  
  1301. Fig. 3  Development and Evaluation Process
  1302.  
  1303.  
  1304.  
  1305.  
  1306.  
  1307.  
  1308.  
  1309.  
  1310.  
  1311.  
  1312.  
  1313.  
  1314.  
  1315.  
  1316.  
  1317.  
  1318.  
  1319.  
  1320.  
  1321.  
  1322.  
  1323. This page left blank
  1324.  
  1325. 2    FUNCTIONALITY
  1326.  
  1327.  
  1328. Introduction
  1329.  
  1330. 2.1  A Target of Evaluation (TOE) which provides security (some 
  1331. combination of confidentiality, integrity and availability) 
  1332. must contain appropriate security features.  Normally, it 
  1333. will be necessary to determine that an appropriate level of 
  1334. confidence can be held in those features.  In order for 
  1335. this to be done, the features themselves must be specified.  
  1336. The document or documents which specify the features, 
  1337. together with the desired evaluation level, make up the 
  1338. security target for the TOE.
  1339.  
  1340. 2.2  In these criteria, security features are viewed at three 
  1341. levels. The most abstract view is of security objectives:  
  1342. the contribution to security which a TOE is intended to 
  1343. achieve.  To achieve these objectives, the TOE must contain 
  1344. certain security enforcing functions.  These security 
  1345. enforcing functions, in turn, must be implemented by 
  1346. specific security mechanisms.  These three levels can be 
  1347. summarised as follows:
  1348.  
  1349.      a)   Security Objectives - Why the functionality is wanted.
  1350.  
  1351.      b)   Security Enforcing Functions - What functionality is 
  1352. actually provided.
  1353.  
  1354.      c)   Security Mechanisms - How the functionality is 
  1355. provided.
  1356.  
  1357.  
  1358. The Security Target
  1359.  
  1360. 2.3  The security target serves as both a specification of the 
  1361. security enforcing functions, against which the TOE will be 
  1362. evaluated, and as a description relating the TOE to the 
  1363. environment in which it will operate.  The audience for the 
  1364. security target is therefore not confined solely to those 
  1365. responsible for the production of the TOE and its 
  1366. evaluation, but also includes those responsible for 
  1367. managing, purchasing, installing, configuring, operating 
  1368. and using the TOE.
  1369.  
  1370. 2.4  The required contents of a security target can be 
  1371. summarised as follows:
  1372.  
  1373. a)   Either    a System Security Policy
  1374.      or   a Product Rationale.
  1375.  
  1376. b)   A specification of the required security enforcing 
  1377. functions.
  1378.  
  1379. c)   A definition of required security mechanisms 
  1380. (optional).
  1381.  
  1382. d)   The claimed rating of the minimum strength of 
  1383. mechanisms.
  1384.  
  1385. e)   The target evaluation level.
  1386.  
  1387.      Each of these is described in greater detail below.
  1388.  
  1389. 2.5  The requirements for the presentation of the security 
  1390. target depend on the target evaluation level.  The 
  1391. evaluation level also determines other TOE documentation 
  1392. that must be supplied for evaluation, together with 
  1393. requirements on its content and presentation, and 
  1394. requirements for the evidence to be provided to show that 
  1395. the TOE satisfies the security target.
  1396.  
  1397. 2.6  The security target may be presented as a single document, 
  1398. or as multiple documents.  Where multiple documents are 
  1399. used, their relationships to one another shall be clearly 
  1400. indicated.
  1401.  
  1402. 2.7  The sponsor of an evaluation is responsible for the 
  1403. provision and accuracy of the security target for the 
  1404. evaluation.
  1405.  
  1406. System Security Policy
  1407.  
  1408. 2.8  The contents of a security target depend on whether the TOE 
  1409. is a system or product.  In the case of a system, the 
  1410. actual environment within which the TOE will be used is 
  1411. known, its actual security objectives can be determined and 
  1412. actual threats and existing countermeasures can be 
  1413. considered.  These details are given in a System Security 
  1414. Policy.
  1415.  
  1416. 2.9  The System Security Policy specifies the set of laws, rules 
  1417. and practices that regulate how sensitive information and 
  1418. other resources are managed, protected and distributed 
  1419. within a specific system.  It shall identify the security 
  1420. objectives of the system and the threats to the system.  
  1421. These security objectives shall be addressed by a 
  1422. combination of system security enforcing functions 
  1423. (implemented within the TOE), and also by physical, 
  1424. personnel, or procedural means associated with the system.  
  1425. The System Security Policy shall cover all aspects of 
  1426. security relating to the system, including these associated 
  1427. physical, procedural and personnel security measures.
  1428.  
  1429. 2.10 All organisations will have general security standards that 
  1430. apply to all systems within the organisation and define the 
  1431. security relationship between the organisation and the 
  1432. outside world.  These standards can be considered to be a 
  1433. Corporate Security Policy:  the set of laws, rules and 
  1434. practices that regulate how assets, including sensitive 
  1435. information, are managed, protected and distributed within 
  1436. the organisation.  Many organisations will have an explicit 
  1437. written Corporate Security Policy, which will specify the 
  1438. rules and practices and applicable national and 
  1439. international laws to which they conform.  Where this is 
  1440. the case, it shall be referenced from the System Security 
  1441. Policy.  Otherwise, all relevant aspects shall be stated 
  1442. within each System Security Policy of the organisation.
  1443.  
  1444. 2.11 The primary responsibility of the Corporate Security Policy 
  1445. is to provide the context for the identification of system 
  1446. security objectives.  Identifying relevant corporate 
  1447. assets, general threats, and the results from risk analysis 
  1448. will assist in the identification of these system security 
  1449. objectives.  Discussion of the process of risk analysis is 
  1450. outside the scope of these criteria.
  1451.  
  1452. 2.12 In the context of an individual system, the System Security 
  1453. Policy shall define the security measures to be used to 
  1454. satisfy the system security objectives in a way which is 
  1455. consistent with the Corporate Security Policy.  The 
  1456. security measures required by the System Security Policy 
  1457. will be implemented by a combination of security enforcing 
  1458. functions implemented by the TOE, and by physical, 
  1459. personnel, and procedural means.  The System Security 
  1460. Policy shall clearly indicate the division of 
  1461. responsibility between the security enforcing functions and 
  1462. the other means.
  1463.  
  1464. 2.13 The IT security measures of a System Security Policy may be 
  1465. separated from the remainder of the System Security Policy, 
  1466. and defined in a separate document:  a Technical Security 
  1467. Policy.  This is the set of laws, rules and practices 
  1468. regulating the processing of sensitive information and the 
  1469. use of resources by the hardware and software of an IT 
  1470. system.
  1471.  
  1472. 2.14 In many cases it may be convenient to include the 
  1473. specification of security enforcing functions as part of 
  1474. the System or Technical Security Policy.
  1475.  
  1476. 2.15 The System or Technical Security Policy may be used as a 
  1477. basis for selecting suitable IT security products for 
  1478. incorporation within the system;  such product selection is 
  1479. outside the scope of these criteria.
  1480.  
  1481. Product Rationale
  1482.  
  1483. 2.16 In the case of a product, the precise environment within 
  1484. which the TOE will be used is not known to its developer, 
  1485. since it may be incorporated into more than one specific 
  1486. system and system environment.  Instead, a rationale 
  1487. statement shall be provided giving the necessary 
  1488. information for a prospective purchaser to decide whether 
  1489. it will help to satisfy his system security objectives, and 
  1490. to define what else must be done for those system security 
  1491. objectives to be fully met.
  1492.  
  1493. 2.17 The product rationale shall identify the intended method of 
  1494. use for the product, the intended environment for use of 
  1495. the product and the assumed threats within that 
  1496. environment.  It shall include a summary of the product's 
  1497. security features, and define all assumptions about the 
  1498. environment and way in which the product will be used.  
  1499. This shall include personnel, physical, procedural and IT 
  1500. security measures required to support the product, and its 
  1501. dependencies on system hardware, software, and/or firmware 
  1502. not supplied as part of the product.
  1503.  
  1504. Specification of Security Enforcing Functions
  1505.  
  1506. 2.18 The security target shall include a specification of the 
  1507. security enforcing functions to be provided by the TOE.  
  1508. These functions may be stated explicitly, or by reference 
  1509. to one or more predefined functionality classes, or by 
  1510. reference to an accepted standard that defines security 
  1511. functionality.  Predefined classes are considered later in 
  1512. this chapter.
  1513.  
  1514. 2.19 One or more standards documents which address security may 
  1515. form part of a security target, by reference or by 
  1516. inclusion within the target.  Where the standard allows 
  1517. options, the selected ones shall be clearly identified.  
  1518. Where a standard does not provide all the information 
  1519. required, the necessary supplementary information shall be 
  1520. provided explicitly within the security target.
  1521.  
  1522. 2.20 In the case of a system, the security enforcing functions 
  1523. shall be correlated to the security objectives, so that it 
  1524. can be seen which functions satisfy which objectives.  (A 
  1525. function may satisfy, or help to satisfy, more than one 
  1526. objective.)  Every function in the specification of 
  1527. security enforcing functions shall at a minimum help to 
  1528. satisfy at least one objective.  The specification of 
  1529. security enforcing functions shall also show why the 
  1530. functions are adequate to counter the identified or stated 
  1531. threats to the security objectives.
  1532.  
  1533. 2.21 In the case of a product, the security enforcing functions 
  1534. shall be correlated to the intended method of use of the 
  1535. product and the assumptions about the environment into 
  1536. which the product will be installed given in the product 
  1537. rationale. This correlation shall include any dependencies 
  1538. on other security enforcing functions and non-IT security 
  1539. measures assumed to be provided by the environment.
  1540.  
  1541. 2.22 From the point of view of evaluation, the specification of 
  1542. security enforcing functions is the most important part of 
  1543. the security target.  These functions shall always be 
  1544. specified in an informal style, using natural language.  In 
  1545. addition, at higher evaluation levels they must also be 
  1546. specified using a semiformal or formal style of 
  1547. presentation.  Details of such presentation styles are 
  1548. given later in this chapter.
  1549.  
  1550. Definition of Required Security Mechanisms
  1551.  
  1552. 2.23 A security target may optionally prescribe or claim the use 
  1553. of particular security mechanisms.  All security mechanisms 
  1554. included in a security target shall be correlated to its 
  1555. security enforcing functions, so that it can be seen which 
  1556. mechanisms implement each function (a mechanism may 
  1557. implement several functions, and a function may be 
  1558. implemented through the combination of several mechanisms).
  1559.  
  1560. 2.24 Where security mechanisms are prescribed by the security 
  1561. target, it is the task of the developer to implement the 
  1562. required mechanisms.  Otherwise, it is the task of the 
  1563. developer of the TOE to develop and produce mechanisms 
  1564. which, when combined, implement the required security 
  1565. enforcing functions.
  1566.  
  1567. Claimed Rating of Minimum Strength of Mechanisms
  1568.  
  1569. 2.25 Every security target shall specify a claimed rating of the 
  1570. minimum strength of the security mechanisms of the TOE 
  1571. against direct attack.  This shall be one of the ratings 
  1572. basic, medium or high as defined in Chapter 3 of these 
  1573. criteria.
  1574.  
  1575. Target Evaluation Level
  1576.  
  1577. 2.26 Every security target shall specify a target evaluation 
  1578. level for evaluation of the TOE.  This shall be one of the 
  1579. ratings E1, E2, E3, E4, E5 or E6 as defined in Chapter 4 of 
  1580. these criteria.
  1581.  
  1582. Examples of the Use of Existing Security Policy Documents
  1583.  
  1584. 2.27 These criteria aim to permit the use of existing security 
  1585. policy documents developed to other criteria or standards 
  1586. as part or all of the security target for a system.  
  1587. Therefore, the precise contents of the documents comprising 
  1588. the security target are not prescribed.  The minimum 
  1589. information required for evaluation against these criteria 
  1590. has been stated above.  Since a security target may consist 
  1591. of more than one document, existing styles of policy 
  1592. document can be accommodated (although supplementary 
  1593. documents may be required to complete the information 
  1594. required for the security target).
  1595.  
  1596. 2.28 Two examples are given below as to how particular types of 
  1597. security policy documents can meet the requirements for a 
  1598. security target.
  1599.  
  1600. 2.29 In the UK it is mandatory to produce a System Security 
  1601. Policy (SSP) for all systems that will process nationally 
  1602. classified information.  If the authorising authority 
  1603. decides that security evaluation is necessary, a System 
  1604. Electronic Information Security Policy (SEISP) must also be 
  1605. produced.  For some target evaluation levels, a Security 
  1606. Policy Model (SPM) must also be produced.  The SSP contains 
  1607. a definition of the scope of the system, the security 
  1608. objectives of the system, the security measures to be 
  1609. enforced and the allocation of responsibilities for 
  1610. enforcing them (i.e. it corresponds closely to a System 
  1611. Security Policy as described in these criteria).  It also 
  1612. contains a derivation of the required target evaluation 
  1613. level based on key characteristics of the system and its 
  1614. environment.  If necessary, an SEISP is developed from the 
  1615. SSP.  It is a more detailed statement of the hardware and 
  1616. software security aspects of the SSP, but still in an 
  1617. informal style:  it corresponds to a Technical Security 
  1618. Policy as described in these criteria.  The SPM is a 
  1619. parallel specification of the security enforcing functions 
  1620. of an SEISP in a formal or semiformal style.  It is 
  1621. produced where such a parallel specification is required 
  1622. for the target evaluation level.
  1623.  
  1624. 2.30 A Claims Document is a list of claims about security 
  1625. enforcing functionality provided by a product, made by the 
  1626. developer of the product, and expressed in a semiformal 
  1627. style using the Claims Language defined in Annex B of this 
  1628. document.  It includes assumptions and constraints about 
  1629. the way the product must be used for these claims to be 
  1630. valid.  It also includes an identification of security 
  1631. objectives, an informal specification of the claims, a 
  1632. correlation of claimed security enforcing functions to 
  1633. security objectives, and the desired evaluation level, in 
  1634. order to complete a product security target as required by 
  1635. these criteria.
  1636.  
  1637.  
  1638. Generic Headings
  1639.  
  1640. 2.31 It will be easier to understand a security target if the 
  1641. specification of its security enforcing functions has been 
  1642. presented in a sensible order.  This will aid the 
  1643. comparison of security targets and simplify the work of 
  1644. evaluators.  There exist natural groupings of security 
  1645. enforcing functions to give such ordering, and a 
  1646. recommended set of eight generic headings for one such 
  1647. grouping is included as part of these criteria.
  1648.  
  1649. 2.32 The recommended headings are:
  1650.  
  1651.           Identification and Authentication
  1652.           Access Control
  1653.           Accountability
  1654.           Audit
  1655.           Object Reuse
  1656.           Accuracy
  1657.           Reliability of Service
  1658.           Data Exchange.
  1659.  
  1660. 2.33 It is recommended that these standard headings are used 
  1661. whenever possible.  Their use will simplify comparison with 
  1662. other security targets and make it easier to determine 
  1663. whether or not a particular security target includes, or 
  1664. precludes, functions of a particular type.
  1665.  
  1666. Identification and Authentication
  1667.  
  1668. 2.34 In many TOEs there will be requirements to determine and 
  1669. control the users who are permitted access to resources 
  1670. controlled by the TOE.  This involves not only establishing 
  1671. the claimed identity of a user, but also verifying that the 
  1672. user is indeed the user claimed.  This is done by the user 
  1673. providing the TOE with some information that is known by 
  1674. the TOE to be associated with the user in question.
  1675.  
  1676. 2.35 This heading shall cover any functions intended to 
  1677. establish and verify a claimed identity.
  1678.  
  1679. 2.36 This heading shall include any functions to enable new user 
  1680. identities to be added, and old user identities to be 
  1681. removed or invalidated.  Similarly, it shall include any 
  1682. functions to generate, change, or allow authorised users to 
  1683. inspect, the authentication information required to verify 
  1684. the identity of particular users.  It shall also include 
  1685. functions to assure the integrity of, or prevent the 
  1686. unauthorised use of, authentication information.  It shall 
  1687. include any functions to limit the opportunity for repeated 
  1688. attempts to establish a false identity.
  1689.  
  1690. Access Control
  1691.  
  1692. 2.37 In many TOEs there will be requirements to ensure that 
  1693. users and processes acting on their behalf are prevented 
  1694. from gaining access to information or resources that they 
  1695. are not authorised to access or have no need to access.  
  1696. Similarly, there will be requirements concerning the 
  1697. unauthorised creation or amendment (including deletion) of 
  1698. information.
  1699.  
  1700. 2.38 This heading shall cover any functions intended to control 
  1701. the flow of information between, and the use of resources 
  1702. by, users, processes and objects.  This includes the 
  1703. administration (i.e. the granting and revocation) of access 
  1704. rights and their verification.
  1705.  
  1706. 2.39 This heading shall include any functions to set up and 
  1707. maintain any lists or rules governing the rights to perform 
  1708. different types of access.  It shall include any functions 
  1709. concerned with temporarily restricting access to objects 
  1710. that are simultaneously accessible by several users or 
  1711. processes and are needed to maintain the consistency and 
  1712. accuracy of such objects.  It shall include any functions 
  1713. to ensure that upon creation, default access lists or 
  1714. access rules apply to objects.  It shall include any 
  1715. functions to control the propagation of access rights to 
  1716. objects.  It shall also include any functions to control 
  1717. the inference of information by the aggregation of data 
  1718. from otherwise legitimate accesses.
  1719.  
  1720. Accountability
  1721.  
  1722. 2.40 In many TOEs there will be requirements to ensure that 
  1723. relevant information is recorded about actions performed by 
  1724. users or processes acting on their behalf so that the 
  1725. consequences of those actions can later be linked to the 
  1726. user in question, and the user held accountable for his 
  1727. actions.
  1728.  
  1729. 2.41 This heading shall cover any functions intended to record 
  1730. the exercising of rights which are relevant to security.
  1731.  
  1732. 2.42 This heading shall include functions related to the 
  1733. collection, protection and analysis of such information.  
  1734. Certain functions may satisfy requirements for both 
  1735. accountability and auditability and so be relevant to both 
  1736. headings.  Such functions may be included under either 
  1737. heading, but shall be cross-referenced to the other 
  1738. heading.
  1739.  
  1740. Audit
  1741.  
  1742. 2.43 In many TOEs there will be requirements to ensure that 
  1743. sufficient information is recorded about both routine and 
  1744. exceptional events that later investigations can determine 
  1745. if security violations have actually occurred, and if so 
  1746. what information or other resources were compromised.
  1747.  
  1748. 2.44 This heading shall cover any functions intended to detect 
  1749. and investigate events that might represent a threat to 
  1750. security.
  1751.  
  1752. 2.45 This heading shall include functions related to the 
  1753. collection, protection and analysis of such information.  
  1754. Such analysis may also include trend analysis used to 
  1755. attempt to detect potential violations of the security 
  1756. target before a violation occurs.  Certain functions may 
  1757. satisfy requirements for both accountability and 
  1758. auditability and so be relevant to both headings.  Such 
  1759. functions may be included under either heading, but shall 
  1760. be cross-referenced to the other heading.
  1761.  
  1762. Object Reuse
  1763.  
  1764. 2.46 In many TOEs there will be requirements to ensure that 
  1765. resources such as main memory and areas of disk storage can 
  1766. be reused while preserving security.
  1767.  
  1768. 2.47 This heading shall cover any functions intended to control 
  1769. the reuse of data objects.
  1770.  
  1771. 2.48 This heading shall include functions to initialise or clear 
  1772. unallocated or reallocated data objects.  It shall include 
  1773. any functions to initialise or clear reusable media such as 
  1774. magnetic tapes, or to clear output devices such as display 
  1775. screens when not in use.
  1776.  
  1777. Accuracy
  1778.  
  1779. 2.49 In many TOEs there will be requirements to ensure specific 
  1780. relationships between different pieces of data are 
  1781. maintained correctly, and that data is passed between 
  1782. processes without alteration.
  1783.  
  1784. 2.50 This heading shall cover any functions intended to ensure 
  1785. that data has not been modified in an unauthorised manner.
  1786.  
  1787. 2.51 This heading shall include functions to determine, 
  1788. establish and maintain the accuracy of the relationships 
  1789. between related data.  It shall also include functions to 
  1790. ensure that when data is passed between processes, users 
  1791. and objects, it is possible to detect or prevent loss, 
  1792. addition or alteration, and that it is not possible to 
  1793. change the claimed or actual source and destination of the 
  1794. data transfer.
  1795.  
  1796. Reliability of Service
  1797.  
  1798. 2.52 In many TOEs there will be requirements to ensure that time 
  1799. critical tasks are performed when they are necessary, and 
  1800. not earlier or later, and that non-time critical tasks 
  1801. cannot be made time critical.  Similarly, in many TOEs 
  1802. there will be requirements to ensure that access to 
  1803. resources is possible when it is needed, and that resources 
  1804. are not requested or retained unnecessarily.
  1805.  
  1806. 2.53 This heading shall cover any functions intended to ensure 
  1807. that resources are accessible and usable on demand by an 
  1808. authorised entity (i.e. a user or a process acting on his 
  1809. behalf) and to prevent or limit interference with time-
  1810. critical operations.
  1811.  
  1812. 2.54 This heading shall include error detection and error 
  1813. recovery functions intended to restrict the impact of 
  1814. errors on the operation of the TOE and so minimise 
  1815. disruption or loss of service.  It shall also include any 
  1816. scheduling functions that ensure that the TOE responds to 
  1817. external events and produces outputs within specified 
  1818. deadlines.
  1819.  
  1820.  
  1821.  
  1822. Data Exchange
  1823.  
  1824. 2.55 In many TOEs there will be requirements for the security of 
  1825. data during transmission over communications channels.  
  1826. This is normally referred to as communications security, as 
  1827. distinct from computer (IT) security.
  1828.  
  1829. 2.56 This heading shall cover any functions intended to ensure 
  1830. the security of data during transmission over 
  1831. communications channels.  It is recommended that such 
  1832. functions are broken down under the following subheadings 
  1833. taken from the OSI Security Architecture:
  1834.  
  1835.           Authentication
  1836.           Access Control
  1837.           Data Confidentiality
  1838.           Data Integrity
  1839.           Non-Repudiation
  1840.  
  1841. 2.57 Functions shall be grouped under these subheadings in a way 
  1842. consistent with their usage and definition in the OSI 
  1843. Security Architecture [OSI].
  1844.  
  1845. 2.58 Certain functions may satisfy requirements for both 
  1846. computer and communications security and so be relevant to 
  1847. other headings.  In this case there shall be a cross-
  1848. reference to the other relevant headings.
  1849.  
  1850.  
  1851. Predefined Classes
  1852.  
  1853. 2.59 Many systems will have similar security objectives;  it 
  1854. will often be possible to identify common sets of security 
  1855. enforcing functions that meet such objectives.  Similarly, 
  1856. many security products will be aimed at satisfying the same 
  1857. market need and thus possess similar functionality.  Such 
  1858. predefined classes of common functions can be used as the 
  1859. basis for individual system and product security targets, 
  1860. or can be used as guidelines, to assist users in selecting 
  1861. appropriate security functionality to meet their particular 
  1862. security objectives, and to help manufacturers select 
  1863. functions to include within products.  To obtain the 
  1864. maximum benefit from such commonality, it is desirable that 
  1865. standards for predefined functionality classes exist.  
  1866. These criteria have therefore been designed to permit 
  1867. reference within security targets to predefined classes of 
  1868. security enforcing functions.  Any security target may 
  1869. reference one or more predefined classes to define part or 
  1870. all of its security enforcing functions.
  1871.  
  1872. 2.60 Organisations for standardisation or representing 
  1873. particular market sectors have already developed some 
  1874. standard definitions.  It is anticipated that the 
  1875. availability of these criteria will encourage the 
  1876. development of predefined classes, in a form consistent for 
  1877. use with these criteria.  However, since IT security will 
  1878. continue to evolve rapidly, it will be necessary to define 
  1879. further predefined classes in the future as new groups of 
  1880. functions become sufficiently common to make such classes 
  1881. worthwhile.
  1882.  
  1883. 2.61 As well as the specification of its security functions, 
  1884. each predefined class shall state the objective of the 
  1885. class, giving its envisaged use, and reasons for the choice 
  1886. of the particular functions included.  Predefined classes 
  1887. may also contain other information necessary for inclusion 
  1888. within a security target, such as the details of any 
  1889. mechanisms which are mandated for a class.  Provided that 
  1890. details of the contents of such classes are publicly 
  1891. available, the details need not be repeated within each 
  1892. security target that references them.
  1893.  
  1894. 2.62 The use of predefined classes is not obligatory.  There 
  1895. will be cases where a sponsor of evaluation will wish not 
  1896. to use them, and cases where they cannot be used, for 
  1897. example because no predefined class describes the desired 
  1898. security features.  As an alternative to the use of 
  1899. predefined classes, the security enforcing functions can 
  1900. always be specified individually.  A statement of 
  1901. individual functions can be used in combination with one or 
  1902. more predefined classes which partially, but not entirely, 
  1903. describe a security target.  However, a predefined class 
  1904. shall only be specified as part of a security target if all 
  1905. aspects of that class form part of the target.
  1906.  
  1907. 2.63 Ten example predefined classes are given in Annex A.  These 
  1908. have been derived from functionality classes given in 
  1909. [ZSIEC].  All are presented in informal style, and in the 
  1910. current version of the ITSEC are in draft form only.  They 
  1911. are:
  1912.  
  1913. a)   Example functionality classes F-C1, F-C2, F-B1, F-B2 
  1914. and F-B3 are hierarchically ordered confidentiality 
  1915. classes which correspond closely to the functionality 
  1916. requirements of the TCSEC classes C1 to A1 [TCSEC].
  1917.  
  1918. b)   Example functionality class F-IN is for TOEs with high 
  1919. integrity requirements for data and programs.  Such 
  1920. requirements may be necessary in database TOEs, for 
  1921. example.
  1922.  
  1923. c)   Example functionality class F-AV sets high 
  1924. requirements for the availability of a complete TOE or 
  1925. special functions of a TOE.  Such requirements are 
  1926. significant for TOEs that control manufacturing 
  1927. processes, for example.
  1928.  
  1929. d)   Example functionality class F-DI sets high 
  1930. requirements with regard to the safeguarding of data 
  1931. integrity during data communication.
  1932.  
  1933. e)   Example functionality Class F-DC is intended for TOEs 
  1934. with high demands on the confidentiality of data 
  1935. during data communication.  An example candidate for 
  1936. this class is a cryptographic device.
  1937.  
  1938. f)   Example functionality class F-DX is intended for 
  1939. networks with high demands on the confidentiality and 
  1940. integrity of the information to be communicated.  For 
  1941. example, this can be the case when sensitive 
  1942. information has to be communicated via insecure (for 
  1943. example:  public) networks.
  1944.  
  1945. 2.64 There is no restriction on the specific functionality which 
  1946. can be claimed or required as a security target.  The 
  1947. security enforcing functions of any security target can be 
  1948. fully described within the available specification formats.  
  1949. The existence of predefined classes will not therefore 
  1950. restrict product manufacturers seeking to advance the state 
  1951. of the art, but will lessen the work involved in specifying 
  1952. products or systems which are similar to the stereotypes 
  1953. described, and will provide a basis for comparison of 
  1954. functionality offered.  Product security targets may, even 
  1955. when claiming conformance to a predefined class, specify 
  1956. additional constraints and details of the required 
  1957. surrounding environment in order to assist potential users 
  1958. to determine if the product would be suitable for their 
  1959. actual real-world environment.
  1960.  
  1961.  
  1962. Specification Style
  1963.  
  1964. 2.65 These criteria do not prescribe the use of particular 
  1965. proprietary or standardised methods or styles for the 
  1966. specification of security functions.  Nor are any methods 
  1967. or styles precluded, so long as the requirements for 
  1968. presentation and evidence of the target evaluation level 
  1969. are met.  For the purpose of categorising possible 
  1970. approaches to specification, three types of style have been 
  1971. identified within these criteria:  informal, semiformal, 
  1972. and formal.  Each type of style is further described below.
  1973.  
  1974. 2.66 Not all people who will need to use a security target will 
  1975. be familiar with specifications written in a semiformal or 
  1976. formal style.  Thus all security targets shall contain a 
  1977. specification of the security enforcing functions using an 
  1978. informal style.  Although informal specifications do not 
  1979. require special training to understand, they are prone to 
  1980. ambiguity and imprecision.  Semiformal and formal 
  1981. specifications reduce that possibility of ambiguity and 
  1982. imprecision.  Thus at the higher evaluation levels, the 
  1983. informal specification of the security enforcing functions 
  1984. shall be supported by a parallel semiformal or formal 
  1985. specification.
  1986.  
  1987. 2.67 The specification technique or style used within a security 
  1988. target for defining the security objectives, and for 
  1989. defining any prescribed or claimed security mechanisms, is 
  1990. outside the scope of these criteria.
  1991.  
  1992. 2.68 If a security target is required to contain a specification 
  1993. of the security enforcing functions in a particular type of 
  1994. style, that specification may be wholly or partially 
  1995. replaced by a reference to one or more predefined classes 
  1996. written in such a style.
  1997.  
  1998. 2.69 Whenever a specification in any style is required, it may 
  1999. be presented as a single document, or multiple documents.  
  2000. Where multiple documents are used, their relationships 
  2001. shall be clearly indicated.
  2002.  
  2003. Informal Specification
  2004.  
  2005. 2.70 An informal specification is written in natural language, 
  2006. rather than a notation requiring special restrictions or 
  2007. conventions.  Natural language is the term for 
  2008. communication in any commonly spoken tongue (for example:  
  2009. Dutch, English, French, German).  Specifications written in 
  2010. natural language are not subject to any special 
  2011. restrictions, but do need to conform to the ordinary 
  2012. conventions for that language (for example:  grammar and 
  2013. syntax).
  2014.  
  2015. 2.71 A natural language specification shall be written with the 
  2016. aim of minimising ambiguity, by (as a minimum) ensuring 
  2017. that all terms are used consistently, and by ensuring that 
  2018. any terms with a specialised meaning (a meaning not defined 
  2019. in a widely used dictionary) are defined in one or more 
  2020. glossaries, which is included or referenced.  It is 
  2021. unlikely that ambiguity can be completely eliminated.  
  2022. Evaluation will seek to identify and resolve any 
  2023. ambiguities that remain.
  2024.  
  2025. Semiformal Specification
  2026.  
  2027. 2.72 A semiformal style of specification requires the use of 
  2028. some restricted notation (or notations), in accordance with 
  2029. a set of conventions which are included in or referenced by 
  2030. the specification.  The conventions are specified 
  2031. informally.  Such a notation shall allow the specification 
  2032. of both the effect of a function and all exceptional or 
  2033. error conditions associated with that function.
  2034.  
  2035. 2.73 A semiformal style may either be graphical in presentation, 
  2036. or based on restricted use of natural language (for 
  2037. instance, restricted sentence structure and keywords with 
  2038. special meanings).  Examples of semiformal styles include 
  2039. data-flow diagrams, state transition diagrams, entity-
  2040. relationship diagrams, data structure diagrams, process or 
  2041. program structure diagrams, and the CCITT recommended 
  2042. specification notation SDL.
  2043.  
  2044. 2.74 Structured design and development methods normally 
  2045. incorporate at least one such semiformal notation for 
  2046. requirements capture, together with prescriptive guidance 
  2047. (for instance, measures of complexity and management 
  2048. methods) on how to use the notation.  Examples of 
  2049. structured design methods including such notations are:  
  2050. the Yourdon Structured Method [YSM], Structured Analysis 
  2051. and Design Technique [SADT], Structured Systems Analysis 
  2052. and Design Method [SSADM], and the Jackson Structured 
  2053. Design [JSD] and Jackson Structured Programming [JSP] 
  2054. methods.
  2055.  
  2056. 2.75 A particular example of a semiformal notation that has been 
  2057. successfully used in the definition of security targets is 
  2058. the Claims Language.  The Claims Language is a subset of 
  2059. English;  both the vocabulary and the syntactic form of 
  2060. claim sentences are restricted.  It was designed (as the 
  2061. name suggests) to provide a structured way in which claims 
  2062. could be made about the security features of IT products.  
  2063. The Claims Language provides for the use of natural 
  2064. language to express those parts of the definition of a 
  2065. security target which support the definition of the claimed 
  2066. security enforcing functions.  A full definition of the 
  2067. Claims Language, consistent with these criteria, can be 
  2068. found in Annex B.
  2069.  
  2070. Formal Specification
  2071.  
  2072. 2.76 A formal style of specification is written in a formal 
  2073. notation based upon well-established mathematical concepts.  
  2074. The concepts are used to define the syntax and semantics of 
  2075. the notation, and the proof rules supporting logical 
  2076. reasoning.  Formal specifications must be capable of being 
  2077. shown to be derivable from a set of stated axioms, and must 
  2078. be capable of showing the validity of key properties such 
  2079. as the delivery of a valid output for all possible inputs.  
  2080. Where hierarchical levels of specification exist, it must 
  2081. be possible to demonstrate that each level maintains the 
  2082. properties established for the previous level.
  2083.  
  2084. 2.77 The syntactic and semantic rules supporting a formal 
  2085. notation used in a security target shall define how to 
  2086. recognise constructs unambiguously and determine their 
  2087. meaning.  Where proof rules are used to support logical 
  2088. reasoning, there shall be evidence that it is impossible to 
  2089. derive contradictions.  All rules supporting the notation 
  2090. shall be defined or referenced.  All constructs used in a 
  2091. formal specification shall be completely described by the 
  2092. supporting rules.  The formal notation shall allow the 
  2093. specification of both the effect of a function and all 
  2094. exceptional or error conditions associated with that 
  2095. function.
  2096.  
  2097. 2.78 Example formal notations are VDM, described in [SSVDM], Z, 
  2098. described in [ZRM], the RAISE Specification Language, 
  2099. described in [RSL], Ina Jo, described in [IJRM], the Gypsy 
  2100. Specification Language, described in [GYPSY], and the ISO 
  2101. protocol specification language [LOTOS].  The use of 
  2102. constructs from predicate (or other) logic and set theory 
  2103. as a formal notation is acceptable, provided that the 
  2104. conventions (supporting rules) are documented or referenced 
  2105. (as set out above).
  2106.  
  2107. Consistency of Parallel Specifications in Different Styles
  2108.  
  2109. 2.79 Parallel specifications shall be presented in such a way 
  2110. that the relationships between the specifications are 
  2111. clear, and that where each specification addresses the same 
  2112. point, that point is addressed consistently.  Parallel 
  2113. specifications may be presented as separate documents, or 
  2114. may be interleaved in a single document.
  2115.  
  2116. 2.80 Where ambiguity exists in an informal specification, the 
  2117. corresponding formal or semiformal specification shall 
  2118. resolve the ambiguity.  However, it shall be an error for 
  2119. parallel specifications to be inconsistent.  Any such error 
  2120. must be resolved by reference to further information 
  2121. outside the security target and one or both specifications 
  2122. amended.
  2123.  
  2124.  
  2125. Formal Models of Security Policy
  2126.  
  2127. 2.81 At evaluation levels E4 and above, a TOE must implement an 
  2128. underlying model of security policy, i.e. there must be an 
  2129. abstract statement of the important principles of security 
  2130. that the TOE will enforce.  This shall be expressed in a 
  2131. formal style, as a formal model of security policy.  All or 
  2132. part of a suitable published model can be referenced, 
  2133. otherwise a model shall be provided as part of the security 
  2134. target.  Any of the formal specification styles identified 
  2135. above may be used to define such a model.
  2136.  
  2137. 2.82 The formal model need not cover all the security enforcing 
  2138. functions specified within the security target.  However, 
  2139. an informal interpretation of the model in terms of the 
  2140. security target shall be provided, and shall show that the 
  2141. security target implements the underlying security policy 
  2142. and contains no functions that conflict with that 
  2143. underlying policy.
  2144.  
  2145. 2.83 Examples of published formal models of security policy are:
  2146.  
  2147. a)   The Bell-La Padula model [BLP] - modelling access 
  2148. control requirements typical of a national security 
  2149. policy for confidentiality.
  2150.  
  2151. b)   The Clark and Wilson model [CWM] - modelling the 
  2152. integrity requirements of commercial transaction 
  2153. processing systems.
  2154.  
  2155. c)   The Brewer-Nash model [BNM] - modelling access control 
  2156. requirements for client confidentiality, typical of a 
  2157. financial services institution.
  2158.  
  2159. d)   The Eizenberg model [EZBM] - modelling access control 
  2160. rights that vary with time.
  2161.  
  2162. e)   The Landwehr model [LWM] - modelling the data exchange 
  2163. requirements of a message processing network.
  2164.  
  2165.  
  2166. 3    ASSURANCE - EFFECTIVENESS
  2167.  
  2168.  
  2169. Introduction
  2170.  
  2171. 3.1  This chapter sets out evaluation criteria addressing the 
  2172. effectiveness aspect of assurance for a Target of 
  2173. Evaluation (TOE).  The baseline for evaluation is the 
  2174. security target, as defined in Chapter 2, which is 
  2175. simultaneously evaluated for effectiveness, in accordance 
  2176. with the criteria set out in this chapter, and correctness, 
  2177. in accordance with the criteria set out in Chapter 4 
  2178. following.
  2179.  
  2180.  
  2181. Description of the Approach
  2182.  
  2183. 3.2  Assessment of effectiveness involves consideration of the 
  2184. following aspects of the TOE:
  2185.  
  2186.      a)   the suitability of the TOE's security enforcing 
  2187. functions to counter the threats to the security of 
  2188. the TOE identified in the security target;
  2189.  
  2190.      b)   the ability of the TOE's security enforcing functions 
  2191. and mechanisms to bind together in a way that is 
  2192. mutually supportive and provides an integrated and 
  2193. effective whole;
  2194.  
  2195.      c)   the ability of the TOE's security mechanisms to 
  2196. withstand direct attack;
  2197.  
  2198.      d)   whether known security vulnerabilities in the 
  2199. construction of the TOE could in practice compromise 
  2200. the security of the TOE;
  2201.  
  2202.      e)   that the TOE cannot be configured or used in a manner 
  2203. which is insecure but which an administrator or end-
  2204. user of the TOE would reasonably believe to be secure;
  2205.  
  2206.      f)   whether known security vulnerabilities in the 
  2207. operation of the TOE could in practice compromise the 
  2208. security of the TOE.
  2209.  
  2210. 3.3  The assessment of each of the aspects of effectiveness 
  2211. identified above is performed using documentation supplied 
  2212. by the sponsor and also documentation and evaluation 
  2213. results from the evaluation of correctness of the TOE.  
  2214. This means that although evaluation of effectiveness can 
  2215. proceed in parallel with the evaluation of correctness, it 
  2216. cannot be completed until after the final results of the 
  2217. assessment of correctness are available.
  2218.  
  2219. 3.4  Specifically, the assessment of  effectiveness is based on 
  2220. a vulnerability analysis of the TOE.  This analysis has the 
  2221. objective of searching for all the ways in which it is 
  2222. possible for a user of the TOE to deactivate, bypass, 
  2223. corrupt, circumvent, directly attack, or otherwise defeat 
  2224. the security enforcing functions and mechanisms of the TOE.  
  2225. As a minimum, the sponsor's vulnerability analysis must 
  2226. consider all the information specified in figure 4 for the 
  2227. evaluation level in question (i.e.  a search for 
  2228. vulnerabilities is to be performed using part of the total 
  2229. information provided by the sponsor for that evaluation 
  2230. level).  As the evaluation level increases, the correctness 
  2231. criteria of Chapter 4 requires the information specified in 
  2232. figure 4 to be provided at increasing levels of rigour, as 
  2233. indicated by the use of the verbs state, describe, and 
  2234. explain.
  2235.  
  2236. 3.5  All critical security mechanisms (i.e. those mechanisms 
  2237. whose failure would create a security weakness) are 
  2238. assessed for their ability to withstand direct attack.  The 
  2239. minimum strength of each critical mechanism shall be rated 
  2240. either basic, medium or high.
  2241.  
  2242. 3.6  For the minimum strength of a critical mechanism to be 
  2243. rated basic it shall be evident that it provides protection 
  2244. against random accidental subversion, although it may be 
  2245. capable of being defeated by knowledgeable attackers.
  2246.  
  2247. 3.7  For the minimum strength of a critical mechanism to be 
  2248. rated medium it shall be evident that it provides 
  2249. protection against attackers with limited opportunities or 
  2250. resources.
  2251.  
  2252. 3.8  For the minimum strength of a critical mechanism to be 
  2253. rated high it shall be evident that it could only be 
  2254. defeated by attackers possessing a high level of expertise, 
  2255. opportunity and resources, successful attack being judged 
  2256. to be beyond normal practicality.
  2257.  
  2258. 3.9  A TOE will only fail evaluation on effectiveness grounds if 
  2259. an exploitable vulnerability, which is found during 
  2260. evaluation of effectiveness, has not been eliminated before 
  2261. the end of evaluation.  This includes methods of successful 
  2262. direct attack found during the assessment of minimum 
  2263. strength of mechanisms which invalidates the claimed 
  2264. rating.  If any such vulnerability exists the TOE will be 
  2265. awarded an overall evaluation level of E0, indicating that 
  2266. it would be unsuitable for use as proposed.
  2267.  
  2268. 3.10 Effectiveness of a TOE is always assessed in the context of 
  2269. the given security target.  For example, a security product 
  2270. sold for incorporation within systems may contain known 
  2271. covert channels.  If, however, the system security target 
  2272. has no access control requirements for confidentiality, 
  2273. then the presence of covert channels in the product is 
  2274. irrelevant and will not effect the ability of the TOE to 
  2275. meet its security target, and will not cause the TOE to 
  2276. fail evaluation.  If there are system access control 
  2277. requirements for confidentiality, then the system security 
  2278. target may specify acceptable maximum covert channel 
  2279. bandwidths.  If covert channels are identified which exceed 
  2280. these bandwidths, or if no bandwidth is actually specified, 
  2281. then the evaluator must determine if the identified covert 
  2282. channels will cause the TOE to fail evaluation on the 
  2283. grounds of unsuitable functionality.
  2284.  
  2285.  
  2286. Systems and Products
  2287.  
  2288. 3.11 There are different requirements and options for the 
  2289. content of a security target for a TOE, depending on 
  2290. whether the TOE is being evaluated as a system or product.  
  2291. These differences are set out under Construction - Phase 1 
  2292. - Requirements in Chapter 4, and further explained in 
  2293. Chapter 2.
  2294.  
  2295.  
  2296. Effectiveness Criteria - Construction
  2297.  
  2298. Documentation
  2299.  
  2300. 3.12 The sponsor shall provide the following documentation in 
  2301. addition to that required for evaluation of correctness:
  2302.  
  2303.      -    Suitability Analysis
  2304.      -    Binding Analysis
  2305.      -    Strength of Mechanisms Analysis
  2306.      -    List of Known Vulnerabilities in Construction.
  2307.  
  2308.  
  2309. Aspect 1 - Suitability of Functionality
  2310.  
  2311. Definition
  2312.  
  2313. 3.13 As part of the documentation required for the evaluation of 
  2314. correctness, the sponsor will provide a security target.  
  2315. As part of the assessment of correctness, that target is 
  2316. examined for coverage and consistency.  For this aspect of 
  2317. effectiveness the security target is used to determine 
  2318. whether the security enforcing functions and mechanisms of 
  2319. the TOE will in fact counter the threats to the security of 
  2320. the TOE identified in the security target.
  2321.  
  2322.  
  2323.  
  2324.  
  2325. Requirements for Content and Presentation
  2326.  
  2327. 3.14 The suitability analysis shall link security enforcing 
  2328. functions and mechanisms to the threats, enumerated in the 
  2329. security target, that they are designed to counter.
  2330.  
  2331. Requirements for Evidence
  2332.  
  2333. 3.15 The suitability analysis shall show how the threats are 
  2334. countered by the security enforcing functions and 
  2335. mechanisms.  It shall show that there are no threats that 
  2336. are not adequately countered by one or more of the stated 
  2337. security enforcing functions.  The analysis shall be 
  2338. performed using, at minimum, all the information given in 
  2339. figure 4 for the evaluation level in question.
  2340.  
  2341. Evaluator Actions
  2342.  
  2343. 3.16 Check that the suitability analysis provided meets all 
  2344. requirements for content and presentation and evidence.  
  2345. Check that the analysis has considered all of the 
  2346. information given in figure 4 for the evaluation level in 
  2347. question.
  2348.  
  2349.  
  2350. Aspect 2 - Binding of Functionality
  2351.  
  2352. Definition
  2353.  
  2354. 3.17 This aspect of effectiveness investigates the ability of 
  2355. the security enforcing functions and mechanisms of the TOE 
  2356. to work together in a way that is mutually supportive and 
  2357. provides an integrated and effective whole.
  2358.  
  2359. Requirements for Content and Presentation
  2360.  
  2361. 3.18 The binding analysis shall provide an analysis of all 
  2362. potential interrelationships between security enforcing 
  2363. functions and mechanisms.
  2364.  
  2365. Requirements for Evidence
  2366.  
  2367. 3.19 The binding analysis shall show that it is not possible to 
  2368. cause any security enforcing function or mechanism to 
  2369. conflict with or contradict the intent of other security 
  2370. enforcing functions or mechanisms.  The analysis shall be 
  2371. performed using, at minimum, all the information given in 
  2372. figure 4 for the evaluation level in question.
  2373.  
  2374.  
  2375.  
  2376. Evaluator Actions
  2377.  
  2378. 3.20 Check that the binding analysis provided meets all 
  2379. requirements for content and presentation and evidence.  
  2380. Check that the analysis has considered all of the 
  2381. information given in figure 4 for the evaluation level in 
  2382. question.
  2383.  
  2384.  
  2385. Aspect 3  - Strength of Mechanisms
  2386.  
  2387. Definition
  2388.  
  2389. 3.21 Even if a security enforcing mechanism cannot be bypassed, 
  2390. deactivated, corrupted, or circumvented, it may still be 
  2391. possible to defeat it by a direct attack based on 
  2392. deficiencies in its underlying algorithms, principles or 
  2393. properties.  For this aspect of effectiveness the ability 
  2394. of these mechanisms to withstand such direct attack is 
  2395. assessed.  This aspect of effectiveness is distinguished 
  2396. from other aspects in that it requires consideration of the 
  2397. level of resources that would be needed for an attacker to 
  2398. execute a successful attack.
  2399.  
  2400. Requirements for Content and Presentation
  2401.  
  2402. 3.22 The strength of mechanisms analysis shall list all security 
  2403. enforcing mechanisms that have been identified as critical 
  2404. within the TOE.  It shall include or reference analyses of 
  2405. the underlying algorithms, principles and properties of 
  2406. those mechanisms.
  2407.  
  2408. Requirements for Evidence
  2409.  
  2410. 3.23 The strength of mechanisms analysis shall show that all 
  2411. critical mechanisms satisfy the claimed minimum strength of 
  2412. mechanisms rating, as defined in paragraphs 3.6 to 3.8:  in 
  2413. the case of cryptographic mechanisms, this shall take the 
  2414. form of a statement of confirmation from the appropriate 
  2415. national body.  Other analyses shall be performed using, at 
  2416. minimum, all the information given in figure 4 for the 
  2417. evaluation level in question.
  2418.  
  2419. Evaluator Actions
  2420.  
  2421. 3.24 Check that all mechanisms that are critical have been 
  2422. identified as such.  Check that the strength of mechanisms 
  2423. analysis provided meets all requirements for content and 
  2424. presentation and evidence.  Check that the analysis has 
  2425. considered all of the information given in figure 4 for the 
  2426. evaluation level in question.  Check that the 
  2427. specifications/definitions of all critical mechanisms 
  2428. support the claimed minimum strength rating.  Perform 
  2429. penetration testing where necessary to confirm or disprove 
  2430. the claimed minimum strength of mechanisms.
  2431.  
  2432.  
  2433. Aspect 4  - Construction Vulnerability Assessment
  2434.  
  2435. Definition
  2436.  
  2437. 3.25 Before and during the other aspects of evaluation of the 
  2438. TOE, various vulnerabilities in the construction of the TOE 
  2439. (such as ways of deactivating, bypassing, corrupting, or 
  2440. circumventing security enforcing functions and mechanisms) 
  2441. will have been identified by both sponsor and evaluator.  
  2442. For this aspect of effectiveness these known 
  2443. vulnerabilities are assessed to determine whether they 
  2444. could in practice compromise the security of the TOE as 
  2445. specified by the security target.
  2446.  
  2447. Requirements for Content and Presentation
  2448.  
  2449. 3.26 The list of known vulnerabilities provided by the sponsor 
  2450. shall identify all vulnerabilities in the construction of 
  2451. the TOE known to him.  It shall identify each known 
  2452. vulnerability, provide an analysis of its potential impact, 
  2453. and identify the measures proposed or provided to counter 
  2454. its effect.
  2455.  
  2456. Requirements for Evidence
  2457.  
  2458. 3.27 The analysis of the potential impact of each known 
  2459. vulnerability shall show that the vulnerability in question 
  2460. cannot be exploited in the intended environment for the 
  2461. TOE, because either:
  2462.  
  2463.      -    the vulnerability is adequately covered by other, 
  2464. uncompromised, security mechanisms, or
  2465.  
  2466.      -    it can be shown that the vulnerability is irrelevant 
  2467. to the security target, will not exist in practice, or 
  2468. can be countered adequately by documented technical, 
  2469. personnel, procedural or physical security measures 
  2470. outside the TOE.  These external security measures 
  2471. shall have been defined within (or shall have been 
  2472. added to) the appropriate documentation.
  2473.  
  2474.      The analysis shall be performed using, at minimum, all the 
  2475. information given in figure 4 for the evaluation level in 
  2476. question.
  2477.  
  2478.  
  2479.  
  2480. Evaluator Actions
  2481.  
  2482. 3.28 Check that the list of known vulnerabilities in 
  2483. construction meets all requirements for content and 
  2484. presentation and evidence given above.  Check that the 
  2485. analysis of the potential impact of each vulnerability has 
  2486. considered all of the information given in figure 4 for the 
  2487. evaluation level in question.  Perform an independent 
  2488. vulnerability analysis, taking into account both the listed 
  2489. and any other known construction vulnerabilities found 
  2490. during evaluation.  Check that all combinations of known 
  2491. vulnerabilities have been addressed.  Check that the 
  2492. analyses of the potential impact of vulnerabilities contain 
  2493. no undocumented or unreasonable assumptions about the 
  2494. intended environment.  Check that all assumptions and 
  2495. requirements for external security measures have been 
  2496. appropriately documented.  Perform penetration testing to 
  2497. confirm or disprove whether the known vulnerabilities are 
  2498. actually exploitable in practice.
  2499.  
  2500.  
  2501. Effectiveness Criteria - Operation
  2502.  
  2503. Documentation
  2504.  
  2505. 3.29 The sponsor shall provide the following documentation in 
  2506. addition to that required for evaluation of correctness:
  2507.  
  2508.      -    Ease of Use Analysis
  2509.      -    List of Known Vulnerabilities in Operational Use.
  2510.  
  2511.  
  2512. Aspect 1 - Ease of Use
  2513.  
  2514. Definition
  2515.  
  2516. 3.30 This aspect of effectiveness investigates whether the TOE 
  2517. can be configured or used in a manner which is insecure but 
  2518. which an administrator or end-user of the TOE would 
  2519. reasonably believe to be secure.
  2520.  
  2521. Requirements for Content and Presentation
  2522.  
  2523. 3.31 The ease of use analysis shall identify possible modes of 
  2524. operation of the TOE, including operation following failure 
  2525. or operational error, their consequences and implications 
  2526. for maintaining secure operation.
  2527.  
  2528.  
  2529.  
  2530. Requirements for Evidence
  2531.  
  2532. 3.32 The ease of use analysis shall show that any human or other 
  2533. error in operation that deactivates or disables security 
  2534. enforcing functions or mechanisms will be easily 
  2535. detectable.  It shall show that if it is possible to 
  2536. configure or cause the TOE to be used in a way which is 
  2537. insecure (i.e. the security enforcing functions and 
  2538. mechanisms of the TOE do not satisfy the security target), 
  2539. when an end-user or administrator of the TOE would 
  2540. reasonably believe it to be secure, then this fact will 
  2541. also be detectable.  The analysis shall be performed using, 
  2542. at minimum, all the information given in figure 4 for the 
  2543. evaluation level in question.
  2544.  
  2545. Evaluator Actions
  2546.  
  2547. 3.33 Check that the ease of use analysis provided meets all 
  2548. requirements for content and presentation and evidence.  
  2549. Check that the analysis has considered all of the 
  2550. information given in figure 4 for the evaluation level in 
  2551. question.  Check the analysis for undocumented or 
  2552. unreasonable assumptions about the intended environment.  
  2553. Check that all assumptions and requirements for external 
  2554. security measures (such as external procedural, physical 
  2555. and personnel controls) have been appropriately documented.  
  2556. Repeat any configuration and installation procedure to 
  2557. check that the TOE can be configured and used securely, 
  2558. using only the user and administration documentation for 
  2559. guidance.  Perform other testing where necessary to confirm 
  2560. or disprove the ease of use analysis.
  2561.  
  2562.  
  2563. Aspect 2  - Operational Vulnerability Assessment
  2564.  
  2565. Definition
  2566.  
  2567. 3.34 Before and during the other aspects of evaluation of the 
  2568. TOE, various vulnerabilities in operation of the TOE will 
  2569. have been identified by both sponsor and evaluator.  For 
  2570. this aspect of effectiveness these known vulnerabilities 
  2571. are assessed to determine whether they could in practice 
  2572. compromise the security of the TOE as specified by the 
  2573. security target.
  2574.  
  2575. Requirements for Content and Presentation
  2576.  
  2577. 3.35 The list of known vulnerabilities provided by the sponsor 
  2578. shall identify all vulnerabilities in operation of the TOE 
  2579. known to him.  It shall identify each known vulnerability, 
  2580. provide an analysis of its potential impact, and identify 
  2581. the measures proposed or provided to counter its effect.
  2582.  
  2583.  
  2584. Requirements for Evidence
  2585.  
  2586. 3.36 The analysis of the potential impact of each known 
  2587. vulnerability shall show that the vulnerability in question 
  2588. cannot be exploited in the intended environment for the 
  2589. TOE, because either:
  2590.  
  2591.      -    the vulnerability is adequately covered by other, 
  2592. uncompromised, external security measures, or
  2593.  
  2594.      -    It can be shown that the vulnerability is irrelevant 
  2595. to the security target or will not be exploitable in 
  2596. practice.
  2597.  
  2598.      The analysis shall be performed using, at minimum, all the 
  2599. information given in figure 4 for the evaluation level in 
  2600. question.  Any required external security measures shall 
  2601. have been defined within (or shall have been added to) the 
  2602. appropriate documentation.
  2603.  
  2604. Evaluator Actions
  2605.  
  2606. 3.37 Check that the list of known vulnerabilities in operation 
  2607. meets all requirements for content and presentation and 
  2608. evidence given above.  Check that the analysis of the 
  2609. potential impact of each vulnerability has considered all 
  2610. of the information given in figure 4 for the evaluation 
  2611. level in question.  Perform an independent vulnerability 
  2612. analysis, taking into account both the listed and any other 
  2613. known operational vulnerabilities found during evaluation.  
  2614. Check that all combinations of known vulnerabilities have 
  2615. been addressed.  Check that the analyses of the potential 
  2616. impact of vulnerabilities contain no undocumented or 
  2617. unreasonable assumptions about the intended environment.  
  2618. Check that all assumptions and requirements for external 
  2619. security measures have been appropriately documented.  
  2620. Perform penetration testing to confirm or disprove whether 
  2621. the known vulnerabilities are actually exploitable in 
  2622. practice.
  2623.  
  2624.  
  2625. INFORMATION OBTAINED FROM A CORRECTNESS ASSESSMENT
  2626. WHICH IS USED TO PERFORM A VULNERABILITY ANALYSIS
  2627.  
  2628.  
  2629.  
  2630.  
  2631.  
  2632.  
  2633.  
  2634.  
  2635.  
  2636.  
  2637.  
  2638.  
  2639.  
  2640.  
  2641.  
  2642.  
  2643.  
  2644.  
  2645.  
  2646.  
  2647.  
  2648.  
  2649.  
  2650.  
  2651.  
  2652.  
  2653.  
  2654.  
  2655.  
  2656.  
  2657.  
  2658.  
  2659.  
  2660.  
  2661.  
  2662.  
  2663.  
  2664.  
  2665.  
  2666.  
  2667. Fig. 4  Information used in a Vulnerability Analysis
  2668.  
  2669. 4    ASSURANCE - CORRECTNESS
  2670.  
  2671.  
  2672. Introduction
  2673.  
  2674. 4.1  This chapter sets out evaluation criteria addressing the 
  2675. correctness aspect of assurance for a Target of Evaluation 
  2676. (TOE).  The baseline for evaluation is a security target 
  2677. defined in accordance with Chapter 2. The security target 
  2678. shall contain the necessary elements specified in Chapter 2 
  2679. for a system or product as appropriate.  This shall include 
  2680. the target evaluation level and the claimed rating for 
  2681. minimum strength of mechanisms.  The effectiveness aspect 
  2682. of assurance is covered by the criteria detailed in Chapter 
  2683. 3.
  2684.  
  2685.  
  2686. Characterisation
  2687.  
  2688. 4.2  Seven evaluation levels are defined in respect of the 
  2689. confidence in the correctness of a TOE.  E0 designates the 
  2690. lowest level and E6 the highest.
  2691.  
  2692. 4.3  The seven evaluation levels can be characterised as 
  2693. follows:
  2694.  
  2695. Level E0
  2696.  
  2697. 4.4  This level represents inadequate assurance.
  2698.  
  2699. Level E1
  2700.  
  2701. 4.5  At this level there shall be a security target and an 
  2702. informal description of the architectural design of the 
  2703. TOE.  Functional testing shall indicate that the TOE 
  2704. satisfies its security target.
  2705.  
  2706. Level E2
  2707.  
  2708. 4.6  In addition to the requirements for level E1, there shall 
  2709. be an informal description of the detailed design.  
  2710. Evidence of functional testing shall be evaluated.  There 
  2711. shall be a configuration control system and an approved 
  2712. distribution procedure.
  2713.  
  2714. Level E3
  2715.  
  2716. 4.7  In addition to the requirements for level E2, the source 
  2717. code and/or hardware drawings corresponding to the security 
  2718. mechanisms shall be evaluated.  Evidence of testing of 
  2719. those mechanisms shall be evaluated.
  2720.  
  2721. Level E4
  2722.  
  2723. 4.8  In addition to the requirements for level E3, there shall 
  2724. be an underlying formal model of security policy supporting 
  2725. the security target.  The security enforcing functions, the 
  2726. architectural design and the detailed design shall be 
  2727. specified in a semiformal style.
  2728.  
  2729. Level E5
  2730.  
  2731. 4.9  In addition to the requirements for level E4, there shall 
  2732. be a close correspondence between the detailed design and 
  2733. the source code and/or hardware drawings.
  2734.  
  2735. Level E6
  2736.  
  2737. 4.10 In addition to the requirements for level E5, the security 
  2738. enforcing functions and the architectural design shall be 
  2739. specified in a formal style, consistent with the specified 
  2740. underlying formal model of security policy.
  2741.  
  2742.  
  2743. Summary of Requirements
  2744.  
  2745. 4.11 Remaining sections of this chapter contain the detailed 
  2746. criteria to be satisfied at each correctness evaluation 
  2747. level, under detailed headings, repeated for each of the 
  2748. levels E1 to E6.  The major differences between levels 
  2749. follow from additional requirements in the investigation of 
  2750. the Development Process.  To assist understanding of these 
  2751. differences, the following diagrams show the relationship 
  2752. between key items to be supplied by the sponsor and the 
  2753. evaluation level at which they are first required by the 
  2754. evaluator.
  2755.  
  2756.  
  2757.  
  2758.  
  2759. CORRECTNESS  CRITERIA  BY  LEVEL  -  DEVELOPMENT  PROCESS
  2760.  
  2761.  
  2762.  
  2763. CORRECTNESS  CRITERIA  BY  LEVEL  -  DEVELOPMENT  ENVIRONMENT
  2764.  
  2765.  
  2766.  
  2767. CORRECTNESS  CRITERIA  BY  LEVEL  -  OPERATION
  2768.  
  2769.  
  2770.  
  2771. Approach to Descriptions
  2772.  
  2773. 4.12 The evaluation criteria for assessment of correctness 
  2774. distinguish between criteria concerning the way the TOE is 
  2775. developed (construction) and criteria concerning the way it 
  2776. will be used (operation).  For each evaluation level, these 
  2777. evaluation criteria are further broken down under various 
  2778. phases and aspects.
  2779.  
  2780. 4.13 For each aspect or phase, documentation that must be 
  2781. provided for examination is identified, followed by 
  2782. requirements for its content and presentation or for the 
  2783. procedures and standards it must define, followed by the 
  2784. evidence required to show that the criteria in question 
  2785. have been met and finally the actions to be performed by 
  2786. the evaluator are stated.
  2787.  
  2788. 4.14 For clarity, since there are significantly different 
  2789. requirements for each evaluation level, the criteria for 
  2790. each level are set out separately.  New or changed criteria 
  2791. at each level are printed in bold.  There is a general need 
  2792. for greater rigour and depth in the evidence provided at 
  2793. higher evaluation levels. This is reflected in the 
  2794. progressive use of the verbs state, describe and explain at 
  2795. different levels in many criteria for content and 
  2796. presentation which do not otherwise change.
  2797.  
  2798. 4.15 Except at E1, the burden for the provision of  evidence is 
  2799. on the sponsor.  This is then checked or audited by the 
  2800. evaluator. An additional requirement to produce evidence is 
  2801. only placed on the evaluator when independent action is 
  2802. required to provide the necessary confidence.  For example, 
  2803. there are requirements to provide evidence of dynamic 
  2804. testing placed on both sponsor and evaluator.  The major 
  2805. requirement is for the sponsor to provide evidence, in 
  2806. particular test plans and test results, produced as part of 
  2807. the normal development process for the system or product in 
  2808. question.  The requirement placed on the evaluator is to 
  2809. show that he has examined the results provided by the 
  2810. sponsor but has also performed his own tests to check the 
  2811. completeness, comprehensiveness and accuracy of sponsor 
  2812. supplied testing, and also to address any points of 
  2813. apparent inconsistency or error found in the results of 
  2814. those tests.
  2815.  
  2816. 4.16 Testing is seen as just one aspect of quality assurance.  
  2817. Throughout the criteria it is assumed that a Quality 
  2818. Assurance Programme has been introduced and is active 
  2819. throughout the whole lifecycle of the TOE.  This Quality 
  2820. Assurance Programme has to encompass the creation, 
  2821. maintenance and destruction of all documents, programs and 
  2822. hardware with respect to the TOE.  The criteria laid down 
  2823. in this document can guide quality assurance assessors as 
  2824. to whether the programme is adequate for the evaluation 
  2825. level at which the TOE is targeted.
  2826.  
  2827.  
  2828.  
  2829. Layout of Correctness Criteria
  2830.  
  2831. 4.17 The following paragraphs describe the layout and content of 
  2832. criteria which will be used for each evaluation level from 
  2833. E1 to E6.  They are relevant to each level and will not be 
  2834. repeated for each of them.  The individual paragraphs 
  2835. within each evaluation level are numbered as follows:
  2836.  
  2837.           <level designator>.<paragraph number within level>
  2838.  
  2839.      so, for example, the 3rd paragraph of level E2 is numbered 
  2840. E2.3.  Null paragraphs are inserted where necessary at each 
  2841. level so that the same numbered paragraph within each level 
  2842. refers to the same topic.
  2843.  
  2844. Construction - The Development Process
  2845.  
  2846. 4.18 A major source of confidence in the correctness of the 
  2847. security aspects of a TOE is understanding the way it was 
  2848. developed.  For the purposes of these criteria, four phases 
  2849. are identified in the development process.  Factors 
  2850. contributing to the development of confidence are 
  2851. identified in the criteria for each of these phases in 
  2852. turn.  Regardless of how a TOE is actually produced the 
  2853. evidence shall be presented to match these phases.
  2854.  
  2855. Phase 1 - Requirements
  2856.  
  2857. 4.19 This first phase of the development process covers the 
  2858. production of a security target for the system or product.  
  2859. The security target is the baseline for evaluation.  It 
  2860. will include the target evaluation level and the claimed 
  2861. rating for minimum strength of mechanisms.
  2862.  
  2863. Phase 2 - Architectural Design
  2864.  
  2865. 4.20 This phase of the development process covers the overall 
  2866. top level definition and design of the TOE.  This takes the 
  2867. form of a descriptive high level specification, identifying 
  2868. the basic structure of the TOE, its external interfaces and 
  2869. its separation into major hardware and software components.  
  2870. The specification will distinguish between what the TOE 
  2871. will do (the top level description) and how it will do it 
  2872. (the top level design).  It is particularly important that 
  2873. the architectural design provides for a clear and effective 
  2874. separation between security-enforcing and other components.  
  2875. Separation may be achieved physically, or by supporting 
  2876. protection mechanisms provided by hardware or firmware, or 
  2877. by other means.  A good design permits evaluation effort to 
  2878. be concentrated on limited areas of the TOE that contribute 
  2879. to security, and enables the implementation of the security 
  2880. target to be easily followed, as the design is refined into 
  2881. greater and greater detail. 
  2882. Phase 3 - Detailed Design
  2883.  
  2884. 4.21 This phase of the development process covers the refinement 
  2885. of the architectural design of the TOE to a level of detail 
  2886. that can be used as a basis for programming and/or hardware 
  2887. construction, i.e. all stages of design and specification 
  2888. below the initial top level specification.  Components 
  2889. identified at the lowest level of specification are called 
  2890. basic components;  it is from the basic component 
  2891. specifications that the actual software and/or hardware 
  2892. will be produced.  At this level, security enforcing 
  2893. components will be identified.  Also at this level, some 
  2894. non-security-enforcing components may be identified whose 
  2895. failure or misuse could compromise security.  These 
  2896. components are security relevant, as their correct 
  2897. operation is relied upon for the TOE to enforce security.  
  2898. Intermediate levels of specification may exist, depending 
  2899. on the development method employed and the complexity of 
  2900. the TOE.  It is important that as the specifications of the 
  2901. TOE become more detailed and less abstract, the 
  2902. transformation is performed in a way that correctly 
  2903. preserves the intent of the top level description.
  2904.  
  2905. Phase 4 - Implementation
  2906.  
  2907. 4.22 This phase of the development process covers the 
  2908. implementation of the detailed design of the TOE in 
  2909. hardware and/or software.  Each basic component is first 
  2910. programmed or built from the basic component 
  2911. specifications.  These individual basic components are then 
  2912. to be checked and tested against their specifications.  
  2913. Individual basic components are then integrated together in 
  2914. a controlled manner until the complete TOE exists.  The 
  2915. complete TOE is then to be checked and tested as a whole 
  2916. against the security target.  It is to be recognized that 
  2917. testing a basic component or larger unit against its 
  2918. specification can only show errors or deviations from the 
  2919. specification, never the absence of errors.  Therefore it 
  2920. will be necessary at higher evaluation levels to supplement 
  2921. testing by analysis.
  2922.  
  2923. Construction - The Development Environment
  2924.  
  2925. 4.23 The development environment comprises the measures, 
  2926. procedures and standards used by the developer whilst 
  2927. developing, producing and maintaining the TOE.
  2928.  
  2929. Aspect 1 - Configuration Control
  2930.  
  2931. 4.24 Configuration control covers the controls imposed by the 
  2932. developer on his development, production and maintenance 
  2933. processes;  for example, to ensure that each representation 
  2934. of the design or its implementation is produced and changed 
  2935. in a controlled manner, and can be shown to correspond 
  2936. correctly to the previous representations on which it is 
  2937. based.  Assessment of configuration control will include 
  2938. understanding the developer's quality management 
  2939. procedures.  Following delivery of the first version of a 
  2940. TOE, it is almost inevitable that correction of flaws, or 
  2941. modification to meet changed objectives, will mean that 
  2942. further versions of the TOE will need to be developed and 
  2943. issued.  It is therefore necessary that configuration 
  2944. control of the TOE and its documentation is maintained 
  2945. following initial release and delivery.  Configuration 
  2946. control is important as a way for the developer to ensure 
  2947. that the TOE is not modified in such a way as to invalidate 
  2948. the results of evaluation.
  2949.  
  2950. Aspect 2 - Programming Languages and Compilers
  2951.  
  2952. 4.25 This aspect applies to basic components implemented in 
  2953. software and firmware only.  It includes requirements 
  2954. concerning the programming languages, the compiling tools 
  2955. and the runtime supporting libraries used to develop the 
  2956. TOE.
  2957.  
  2958. Aspect 3 - Developers Security
  2959.  
  2960. 4.26 Developer Security covers the physical, procedural, 
  2961. technical and personnel measures used in the development 
  2962. environment.  It includes the physical security of the 
  2963. development location(s), and controls on the selection and 
  2964. vetting of development staff.  Its objective is to protect 
  2965. development from deliberate attack and to maintain the 
  2966. confidentiality of information as appropriate.
  2967.  
  2968. Operation - The Operational Documentation
  2969.  
  2970. 4.27 Operational Documentation provides the major means by which 
  2971. the developer of a TOE and his customers communicate.  Its 
  2972. understandability, coverage and correctness are therefore 
  2973. important factors in secure operation of the TOE.  It can 
  2974. be considered to fall into two classes: information for 
  2975. end-users (user documentation) and information for 
  2976. administrators (administration documentation).
  2977.  
  2978. Aspect 1 - User Documentation
  2979.  
  2980. 4.28 User documentation is the information about the TOE 
  2981. supplied by the developer for use by end-users.  This 
  2982. documentation should help the end-user understand the 
  2983. security capabilities of the TOE, and the end-user's 
  2984. contribution to maintaining security during use.
  2985.  
  2986. Aspect 2 - Administration Documentation
  2987.  
  2988. 4.29 Administration documentation is the information about the 
  2989. TOE supplied by the developer for use by the administrator.  
  2990. This information may include information not relevant or 
  2991. appropriate to end-users.  This documentation should help 
  2992. the administrator set up and operate the TOE in a way which 
  2993. is secure.
  2994.  
  2995. Operation - The Operational Environment
  2996.  
  2997. 4.30 The operational environment comprises the measures, 
  2998. procedures and standards concerned with secure delivery, 
  2999. installation and operational use of a TOE.  In the case of 
  3000. a system which is already in use, it is possible to assess 
  3001. the actual operational procedures.  In other circumstances, 
  3002. it is only possible to evaluate proposed procedures.
  3003.  
  3004. Aspect 1 - Delivery and Configuration
  3005.  
  3006. 4.31 This section covers the procedures used to maintain 
  3007. security during transfer of the TOE or its component parts 
  3008. to the user, both on initial delivery and as part of 
  3009. subsequent modification.  It includes any special 
  3010. procedures or operations required to configure the TOE 
  3011. during installation, or to demonstrate the authenticity of 
  3012. the delivered TOE.  Such procedures and measures are the 
  3013. basis for ensuring that the security protection offered by 
  3014. the TOE is not compromised during transfer or by 
  3015. interference with the security features during installation 
  3016. and configuration at the user's site.
  3017.  
  3018. Aspect 2 - Start-up and Operation
  3019.  
  3020. 4.32 This covers the procedures used by the administrator in 
  3021. order to operate the TOE in a secure manner on a daily 
  3022. basis.  It shall cover not only day-to-day operation 
  3023. (matters such as starting the system up) but also other 
  3024. routine activities such as necessary backups and 
  3025. maintenance, and exceptional activities such as start-up 
  3026. and recovery following a failure. Almost all TOEs require 
  3027. maintenance, either to meet changed objectives, or to 
  3028. address failures. Thus these procedures shall provide for 
  3029. authorised modifications, replacements or additions to the 
  3030. TOE.
  3031.  
  3032.  
  3033. LEVEL E1
  3034.  
  3035.  
  3036. Construction - The Development Process
  3037.  
  3038. E1.1 The sponsor shall provide the TOE, and the following 
  3039. documentation:
  3040.  
  3041.      -    The security target for the TOE
  3042.  
  3043.      -    Informal description of the architecture of the TOE
  3044.  
  3045.      -    Test documentation (optional)
  3046.  
  3047.      -    Library of test programs and tools used for testing 
  3048. the TOE (optional)
  3049.  
  3050.  
  3051. Phase 1 - Requirements
  3052.  
  3053. Requirements for Content and Presentation
  3054.  
  3055. E1.2 The security target shall state the security enforcing 
  3056. functions to be provided by the TOE.  In the case of a 
  3057. system, in addition the security target shall include a 
  3058. System Security Policy (SSP) identifying the security 
  3059. objectives and the threats to the system.  In the case of a 
  3060. product, in addition the security target shall include a 
  3061. rationale, identifying the method of use for the product, 
  3062. the intended environment and the assumed threats within 
  3063. that environment.  The security enforcing functions within 
  3064. the security target shall be specified using an informal 
  3065. style as categorised in Chapter 2.
  3066.  
  3067. Requirements for Evidence
  3068.  
  3069. E1.3 In the case of a system the security target shall state how 
  3070. the proposed functionality fulfils the security objectives 
  3071. and is adequate to counter the identified threats.  In the 
  3072. case of a product the security target shall state how the 
  3073. functionality is appropriate for that method of use and is 
  3074. adequate to counter the assumed threats.
  3075.  
  3076. Evaluator Actions
  3077.  
  3078. E1.4 Check that the information provided meets all requirements 
  3079. for content and presentation and evidence.  Check that 
  3080. there are no inconsistencies in the security target.
  3081.  
  3082. Phase 2 - Architectural Design
  3083.  
  3084. Requirements for Content and Presentation
  3085.  
  3086. E1.5 The description of the architecture shall state the general 
  3087. structure of the TOE.  It shall state the external 
  3088. interfaces of the TOE.  It shall state any hardware and 
  3089. firmware required by the TOE with a statement of the 
  3090. functionality of supporting protection mechanisms 
  3091. implemented in that hardware or firmware.
  3092.  
  3093. Requirements for Evidence
  3094.  
  3095. E1.6 The description of the architecture shall state how the 
  3096. security enforcing functions of the security target will be 
  3097. provided.
  3098.  
  3099. Evaluator Actions
  3100.  
  3101. E1.7 Check that the information provided meets all requirements 
  3102. for content and presentation and evidence.
  3103.  
  3104.  
  3105. Phase 3 - Detailed Design
  3106.  
  3107. Requirements for Content and Presentation
  3108.  
  3109. E1.8 No Requirement.
  3110.  
  3111. Requirements for Evidence
  3112.  
  3113. E1.9 No Requirement.
  3114.  
  3115. Evaluator Actions
  3116.  
  3117. E1.10     No Action.
  3118.  
  3119.  
  3120. Phase 4 - Implementation
  3121.  
  3122. Requirements for Content and Presentation
  3123.  
  3124. E1.11     Test documentation may be provided that shall contain 
  3125. plan, purpose, procedures and results of the tests.  A 
  3126. library of test programs may be provided that shall contain 
  3127. test programs and tools to enable tests covered by the test 
  3128. documentation to be repeated.
  3129. Requirements for Evidence
  3130.  
  3131. E1.12     Test documentation may be provided that shall state 
  3132. the correspondence between tests and the security enforcing 
  3133. functions defined in the security target.
  3134.  
  3135. Evaluator Actions
  3136.  
  3137. E1.13     Check that the TOE satisfies the security target by 
  3138. performing tests covering all security enforcing functions 
  3139. identified in the security target.  Perform additional 
  3140. tests to search for errors.  The evaluator need not 
  3141. duplicate testing performed by or for the sponsor where 
  3142. adequate evidence of that testing is provided, but shall 
  3143. check by sampling the results of such tests.
  3144.  
  3145.  
  3146. Construction - The Development Environment
  3147.  
  3148. E1.14     The sponsor shall provide the following documentation:
  3149.  
  3150.      -    Configuration list identifying the version of the TOE 
  3151. for evaluation
  3152.  
  3153.  
  3154. Aspect 1 - Configuration Control
  3155.  
  3156. Requirements for Content and Presentation
  3157.  
  3158. E1.15     The configuration list shall state where the TOE is 
  3159. uniquely identified (version number).
  3160.  
  3161. Requirements for Evidence
  3162.  
  3163. E1.16     The configuration list shall state how the TOE is 
  3164. uniquely identified.
  3165.  
  3166. Evaluator Actions
  3167.  
  3168. E1.17     Check that the information provided meets all 
  3169. requirements for content and presentation and evidence.
  3170.  
  3171.  
  3172.  
  3173.  
  3174.  
  3175.  
  3176.  
  3177. Aspect 2 - Programming Languages and Compilers
  3178.  
  3179. Requirements for Content and Presentation
  3180.  
  3181. E1.18     No Requirement.
  3182.  
  3183. Requirements for Evidence
  3184.  
  3185. E1.19     No Requirement.
  3186.  
  3187. Evaluator Actions
  3188.  
  3189. E1.20     No Action.
  3190.  
  3191.  
  3192. Aspect 3 - Developers Security
  3193.  
  3194. Requirements for Content and Presentation
  3195.  
  3196. E1.21     No Requirement.
  3197.  
  3198. Requirements for Evidence
  3199.  
  3200. E1.22     No Requirement.
  3201.  
  3202. Evaluator Actions
  3203.  
  3204. E1.23     No Action.
  3205.  
  3206.  
  3207. Operation - The Operational Documentation
  3208.  
  3209. E1.24     The sponsor shall provide the following documentation:
  3210.  
  3211.      -    User documentation
  3212.  
  3213.      -    Administration documentation
  3214.  
  3215.  
  3216.  
  3217.  
  3218.  
  3219.  
  3220. Aspect 1 - User Documentation
  3221.  
  3222. Requirements for Content and Presentation
  3223.  
  3224. E1.25     The user documentation shall state the security 
  3225. enforcing functions relevant to the end-user.  It shall 
  3226. also give guidelines covering their secure operation. The 
  3227. user documentation e.g. Reference Manuals, User Guides, 
  3228. shall be structured, internally consistent, and consistent 
  3229. with all other documents supplied for this level.
  3230.  
  3231. Requirements for Evidence
  3232.  
  3233. E1.26     The user documentation shall state how an end-user 
  3234. uses the TOE in a secure manner.
  3235.  
  3236. Evaluator Actions
  3237.  
  3238. E1.27     Check that the information provided meets all 
  3239. requirements for content and presentation and evidence.
  3240.  
  3241.  
  3242. Aspect 2 - Administration Documentation
  3243.  
  3244. Requirements for Content and Presentation
  3245.  
  3246. E1.28     The administration documentation shall state the 
  3247. security enforcing functions relevant to an administrator.  
  3248. It shall distinguish two types of functions:  those which 
  3249. allow an administrator to control security parameters, and 
  3250. those which only allow him to obtain information.  If an 
  3251. administrator is required, it shall state all security 
  3252. parameters which are under his control.  It shall state 
  3253. each type of security-relevant event, relevant to the 
  3254. administrative functions.  It shall state details, 
  3255. sufficient for use, of procedures relevant to the 
  3256. administration of security.  It shall give guidelines on 
  3257. the consistent and effective use of the security features 
  3258. of the TOE and how those features interact.  It shall state 
  3259. instructions on how the system/product shall be installed 
  3260. and how, if appropriate, it shall be configured.  The 
  3261. administration documentation, e.g. Reference Manuals, 
  3262. Administrator Guides, shall be structured, internally 
  3263. consistent, and consistent with all other documents 
  3264. supplied for this level.
  3265.  
  3266. Requirements for Evidence
  3267.  
  3268. E1.29     The administration documentation shall state how the 
  3269. TOE is administered in a secure manner.
  3270. Evaluator Actions
  3271.  
  3272. E1.30     Check that the information provided meets all 
  3273. requirements for content and presentation and evidence.
  3274.  
  3275.  
  3276. Operation - The Operational Environment
  3277.  
  3278. E1.31     The sponsor shall provide the following documentation:
  3279.  
  3280.      -    Delivery and Configuration Documentation
  3281.  
  3282.      -    Start-up and Operation Documentation
  3283.  
  3284.  
  3285. Aspect 1 - Delivery and Configuration
  3286.  
  3287. Requirements for Procedures and Standards
  3288.  
  3289. E1.32     If different configurations are possible, the impact 
  3290. of the configurations on security shall be stated.  The 
  3291. procedures for delivery and system generation shall be 
  3292. stated.
  3293.  
  3294. Requirements for Evidence
  3295.  
  3296. E1.33     The information supplied shall state how the 
  3297. procedures maintain security.
  3298.  
  3299. Evaluator Actions
  3300.  
  3301. E1.34     Check that the information provided meets all 
  3302. requirements for content and presentation and evidence.
  3303.  
  3304.  
  3305. Aspect 2 - Start-up and Operation
  3306.  
  3307. Requirements for Procedures and Standards
  3308.  
  3309. E1.35     The procedures for secure start-up and operation shall 
  3310. be stated.
  3311.  
  3312. Requirements for Evidence
  3313.  
  3314. E1.36     The information supplied shall state how the 
  3315. procedures maintain security.
  3316.  
  3317. Evaluator Actions
  3318.  
  3319. E1.37     Check that the information provided meets all 
  3320. requirements for content and presentation and evidence.
  3321.  
  3322.  
  3323.  
  3324.  
  3325.  
  3326. LEVEL E2
  3327.  
  3328.  
  3329. Construction - The Development Process
  3330.  
  3331. E2.1 The sponsor shall provide the TOE, and the following 
  3332. documentation:
  3333.  
  3334.      -    The security target for the TOE
  3335.  
  3336.      -    Informal description of the architecture of the TOE
  3337.  
  3338.      -    Informal description of the detailed design
  3339.  
  3340.      -    Test documentation
  3341.  
  3342.      -    Library of test programs and tools used for testing 
  3343. the TOE
  3344.  
  3345.  
  3346. Phase 1 - Requirements
  3347.  
  3348. Requirements for Content and Presentation
  3349.  
  3350. E2.2 The security target shall state the security enforcing 
  3351. functions to be provided by the TOE.  In the case of a 
  3352. system, in addition the security target shall include a 
  3353. System Security Policy (SSP) identifying the security 
  3354. objectives and the threats to the system.  In the case of a 
  3355. product, in addition the security target shall include a 
  3356. rationale, identifying the method of use for the product, 
  3357. the intended environment and the assumed threats within 
  3358. that environment.  The security enforcing functions within 
  3359. the security target shall be specified using an informal 
  3360. style as categorised in Chapter 2.
  3361.  
  3362. Requirements for Evidence
  3363.  
  3364. E2.3 In the case of a system the security target shall state how 
  3365. the proposed functionality fulfils the security objectives 
  3366. and is adequate to counter the identified threats.  In the 
  3367. case of a product the security target shall state how the 
  3368. functionality is appropriate for that method of use and is 
  3369. adequate to counter the assumed threats.
  3370.  
  3371. Evaluator Actions
  3372.  
  3373. E2.4 Check that the information provided meets all requirements 
  3374. for content and presentation and evidence.  Check that 
  3375. there are no inconsistencies in the security target.
  3376. Phase 2 - Architectural Design
  3377.  
  3378. Requirements for Content and Presentation
  3379.  
  3380. E2.5 The description of the architecture shall state the general 
  3381. structure of the TOE.  It shall state the external 
  3382. interfaces of the TOE.  It shall state any hardware and 
  3383. firmware required by the TOE with a statement of the 
  3384. functionality of supporting protection mechanisms 
  3385. implemented in that hardware or firmware.  It shall state 
  3386. the separation of the TOE into security enforcing and other 
  3387. components.
  3388.  
  3389. Requirements for Evidence
  3390.  
  3391. E2.6 The description of the architecture shall state how the 
  3392. security enforcing functions of the security target will be 
  3393. provided.  It shall state how the separation into security 
  3394. enforcing and other components is achieved.
  3395.  
  3396. Evaluator Actions
  3397.  
  3398. E2.7 Check that the information provided meets all requirements 
  3399. for content and presentation and evidence.  Check that the 
  3400. separation of security enforcing and other components is 
  3401. valid.
  3402.  
  3403.  
  3404. Phase 3 - Detailed Design
  3405.  
  3406. Requirements for Content and Presentation
  3407.  
  3408. E2.8 The detailed design shall state the realisation of all 
  3409. security enforcing and security relevant functions.  It 
  3410. shall identify all security mechanisms.  It shall map 
  3411. security enforcing functions to mechanisms and components.  
  3412. All interfaces of security enforcing and security relevant 
  3413. components shall be documented stating their purpose and 
  3414. parameters.  Specifications/definitions for mechanisms 
  3415. shall be provided.  These specifications shall be suitable 
  3416. for the analysis of interrelationships between the 
  3417. mechanisms employed.  Specifications need not be provided 
  3418. for components that are neither security enforcing nor 
  3419. security relevant.  Where more than one level of 
  3420. specification is provided, there shall be a clear and 
  3421. hierarchical relationship between levels.
  3422.  
  3423. Requirements for Evidence
  3424.  
  3425. E2.9 The detailed design shall state how the security mechanisms 
  3426. provide the security enforcing functions specified in the 
  3427. security target.  It shall state why components for which 
  3428. no design information is provided cannot be either security 
  3429. enforcing or security relevant.
  3430.  
  3431. Evaluator Actions
  3432.  
  3433. E2.10     Check that the information provided meets all 
  3434. requirements for content and presentation and evidence.
  3435.  
  3436.  
  3437. Phase 4 - Implementation
  3438.  
  3439. Requirements for Content and Presentation
  3440.  
  3441. E2.11     The test documentation shall contain plan, purpose, 
  3442. procedures and results of the tests.  The library of test 
  3443. programs shall contain test programs and tools to enable 
  3444. all tests covered by the test documentation to be repeated.
  3445.  
  3446. Requirements for Evidence
  3447.  
  3448. E2.12     The test documentation shall state the correspondence 
  3449. between tests and the security enforcing functions defined 
  3450. in the security target.
  3451.  
  3452. Evaluator Actions
  3453.  
  3454. E2.13     Check that the information provided meets all 
  3455. requirements for content and presentation and evidence.  
  3456. Use the library of test programs to check by sampling the 
  3457. results of tests. Check that tests cover all security 
  3458. enforcing functions identified in the security target.  
  3459. Perform additional tests to search for errors.
  3460.  
  3461.  
  3462. Construction - The Development Environment
  3463.  
  3464. E2.14     The sponsor shall provide the following documentation:
  3465.  
  3466.      -    Configuration list identifying the version of the TOE 
  3467. for evaluation
  3468.  
  3469.      -    Information on the configuration control system
  3470.  
  3471.      -    Information on the security of the development 
  3472. environment
  3473.  
  3474.  
  3475.  
  3476.  
  3477. Aspect 1 - Configuration Control
  3478.  
  3479. Requirements for Content and Presentation
  3480.  
  3481. E2.15     The development process shall be supported by a 
  3482. configuration control system.  The configuration list 
  3483. provided shall enumerate all basic components out of which 
  3484. the TOE is built.  The TOE, its basic components and all 
  3485. documents provided including the manuals shall possess a 
  3486. unique identifier.  The use of this unique identifier is 
  3487. obligatory in references.  The configuration control system 
  3488. shall ensure that the TOE under evaluation matches the 
  3489. documentation provided and that only authorised changes are 
  3490. possible.
  3491.  
  3492. Requirements for Evidence
  3493.  
  3494. E2.16     The information on the configuration control system 
  3495. shall state how it is used in practice and applied in the 
  3496. manufacturing process in accordance with the developer's 
  3497. quality management procedures.
  3498.  
  3499. Evaluator Actions
  3500.  
  3501. E2.17     Check that the documented procedures are being 
  3502. applied.  Check that the information provided meets all 
  3503. requirements for content and presentation and evidence.
  3504.  
  3505.  
  3506. Aspect 2 - Programming Languages and Compilers
  3507.  
  3508. Requirements for Content and Presentation
  3509.  
  3510. E2.18     No Requirement.
  3511.  
  3512. Requirements for Evidence
  3513.  
  3514. E2.19     No Requirement.
  3515.  
  3516. Evaluator Actions
  3517.  
  3518. E2.20     No Action.
  3519.  
  3520.  
  3521.  
  3522.  
  3523.  
  3524. Aspect 3 - Developers Security
  3525.  
  3526. Requirements for Content and Presentation
  3527.  
  3528. E2.21     The document on the security of the development 
  3529. environment shall state the intended protection for the 
  3530. integrity of the TOE and the confidentiality of the 
  3531. associated documents.  Physical, procedural, personnel and 
  3532. other security measures used by the developer shall be 
  3533. stated.
  3534.  
  3535. Requirements for Evidence
  3536.  
  3537. E2.22     The information on the security of the development 
  3538. environment shall state how the integrity of the TOE and 
  3539. the confidentiality of the associated documentation are 
  3540. maintained.
  3541.  
  3542. Evaluator Actions
  3543.  
  3544. E2.23     Check that the documented procedures are being 
  3545. applied.  Check that the information provided meets all 
  3546. requirements for content and presentation and evidence.  
  3547. Search for errors in the procedures.
  3548.  
  3549.  
  3550. Operation - The Operational Documentation
  3551.  
  3552. E2.24     The sponsor shall provide the following documentation:
  3553.  
  3554.      -    User documentation
  3555.  
  3556.      -    Administration documentation
  3557.  
  3558.  
  3559. Aspect 1 - User Documentation
  3560.  
  3561. Requirements for Content and Presentation
  3562.  
  3563. E2.25     The user documentation shall state the security 
  3564. enforcing functions relevant to the end-user.  It shall 
  3565. also give guidelines covering their secure operation.  The 
  3566. user documentation e.g. Reference Manuals, User Guides, 
  3567. shall be structured, internally consistent, and consistent 
  3568. with all other documents supplied for this level.
  3569.  
  3570.  
  3571.  
  3572.  
  3573. Requirements for Evidence
  3574.  
  3575. E2.26     The user documentation shall state how an end-user 
  3576. uses the TOE in a secure manner.
  3577.  
  3578. Evaluator Actions
  3579.  
  3580. E2.27     Check that the information provided meets all 
  3581. requirements for content and presentation and evidence.
  3582.  
  3583.  
  3584. Aspect 2 - Administration Documentation
  3585.  
  3586. Requirements for Content and Presentation
  3587.  
  3588. E2.28     The administration documentation shall state the 
  3589. security enforcing functions relevant to an administrator.  
  3590. It shall distinguish two types of functions:  those which 
  3591. allow an administrator to control security parameters, and 
  3592. those which only allow him to obtain information.  If an 
  3593. administrator is required, it shall state all security 
  3594. parameters which are under his control.  It shall state 
  3595. each type of security-relevant event, relevant to the 
  3596. administrative functions.  It shall state details, 
  3597. sufficient for use, of procedures relevant to the 
  3598. administration of security.  It shall give guidelines on 
  3599. the consistent and effective use of the security features 
  3600. of the TOE and how those features interact.  It shall state 
  3601. instructions on how the system/product shall be installed 
  3602. and how, if appropriate, it shall be configured.  The 
  3603. administration documentation, e.g. Reference Manuals, 
  3604. Administrator Guides, shall be structured, internally 
  3605. consistent, and consistent with all other documents 
  3606. supplied for this level.
  3607.  
  3608. Requirements for Evidence
  3609.  
  3610. E2.29     The administration documentation shall state how the 
  3611. TOE is administered in a secure manner.
  3612.  
  3613. Evaluator Actions
  3614.  
  3615. E2.30     Check that the information provided meets all 
  3616. requirements for content and presentation and evidence.
  3617.  
  3618.  
  3619.  
  3620.  
  3621.  
  3622. Operation - The Operational Environment
  3623.  
  3624. E2.31     The sponsor shall provide the following documentation:
  3625.  
  3626.      -    Delivery and Configuration Documentation
  3627.  
  3628.      -    Start-up and Operation Documentation
  3629.  
  3630.  
  3631. Aspect 1 - Delivery and Configuration
  3632.  
  3633. Requirements for Procedures and Standards
  3634.  
  3635. E2.32     If different configurations are possible, the impact 
  3636. of the configurations on security shall be stated.  The 
  3637. procedures for delivery and system generation shall be 
  3638. stated.  A procedure approved by the national certification 
  3639. body for this evaluation level shall be followed, which 
  3640. guarantees the authenticity of the delivered TOE.  While 
  3641. generating the TOE, any generation options and/or changes 
  3642. shall be audited in such a way that it is subsequently 
  3643. possible to reconstruct exactly how and when the TOE was 
  3644. generated.
  3645.  
  3646. Requirements for Evidence
  3647.  
  3648. E2.33     The information supplied shall state how the 
  3649. procedures maintain security.
  3650.  
  3651. Evaluator Actions
  3652.  
  3653. E2.34     Check that the information provided meets all 
  3654. requirements for content and presentation and evidence.  
  3655. Check the correct application of the delivery procedures.  
  3656. Search for errors in the system generation procedures.
  3657.  
  3658.  
  3659. Aspect 2 - Start-up and Operation
  3660.  
  3661. Requirements for Procedures and Standards
  3662.  
  3663. E2.35     The procedures for secure start-up and operation shall 
  3664. be stated.  If any security enforcing functions can be 
  3665. deactivated or modified during start-up, normal operation 
  3666. or maintenance, this shall be stated.  If the TOE contains 
  3667. hardware which contains security enforcing hardware 
  3668. components, then administrator, end-user, or self initiated 
  3669. diagnostic tests shall exist that can be performed on the 
  3670. TOE in its operational environment.
  3671.  
  3672. Requirements for Evidence
  3673.  
  3674. E2.36     The information supplied shall state how the 
  3675. procedures maintain security.  The sponsor shall provide 
  3676. example results from all diagnostic test procedures for 
  3677. security enforcing hardware components.  The sponsor shall 
  3678. provide examples of any audit trail output created during 
  3679. start-up and operation.
  3680.  
  3681. Evaluator Actions
  3682.  
  3683. E2.37     Check that the information provided meets all 
  3684. requirements for content and presentation and evidence.  
  3685. Check the example evidence required for start-up and 
  3686. operation.  Search for errors in the procedures.
  3687.  
  3688.  
  3689.  
  3690.  
  3691.  
  3692. LEVEL E3
  3693.  
  3694.  
  3695. Construction - The Development Process
  3696.  
  3697. E3.1 The sponsor shall provide the TOE, and the following 
  3698. documentation:
  3699.  
  3700.      -    The security target for the TOE
  3701.  
  3702.      -    Informal description of the architecture of the TOE
  3703.  
  3704.      -    Informal description of the detailed design
  3705.  
  3706.      -    Test documentation
  3707.  
  3708.      -    Library of test programs and tools used for testing 
  3709. the TOE
  3710.  
  3711.      -    Source code or hardware drawings for all security 
  3712. enforcing and security relevant components
  3713.  
  3714.      -    Informal description of correspondence between source 
  3715. code or hardware drawings and the detailed design
  3716.  
  3717.  
  3718. Phase 1 - Requirements
  3719.  
  3720. Requirements for Content and Presentation
  3721.  
  3722. E3.2 The security target shall describe the security enforcing 
  3723. functions to be provided by the TOE.  In the case of a 
  3724. system, in addition the security target shall include a 
  3725. System Security Policy (SSP) identifying the security 
  3726. objectives and the threats to the system.  In the case of a 
  3727. product, in addition the security target shall include a 
  3728. rationale, identifying the method of use for the product, 
  3729. the intended environment and the assumed threats within 
  3730. that environment.  The security enforcing functions within 
  3731. the security target shall be specified using an informal 
  3732. style as categorised in Chapter 2.
  3733.  
  3734. Requirements for Evidence
  3735.  
  3736. E3.3 In the case of a system the security target shall describe 
  3737. how the proposed functionality fulfils the security 
  3738. objectives and is adequate to counter the identified 
  3739. threats.  In the case of a product the security target 
  3740. shall describe how the functionality is appropriate for 
  3741. that method of use and is adequate to counter the assumed 
  3742. threats.
  3743.  
  3744. Evaluator Actions
  3745.  
  3746. E3.4 Check that the information provided meets all requirements 
  3747. for content and presentation and evidence.  Check that 
  3748. there are no inconsistencies in the security target.
  3749.  
  3750.  
  3751. Phase 2 - Architectural Design
  3752.  
  3753. Requirements for Content and Presentation
  3754.  
  3755. E3.5 The description of the architecture shall describe the 
  3756. general structure of the TOE.  It shall describe the 
  3757. external interfaces of the TOE.  It shall describe any 
  3758. hardware and firmware required by the TOE with a statement 
  3759. of the functionality of supporting protection mechanisms 
  3760. implemented in that hardware or firmware.  It shall 
  3761. describe the separation of the TOE into security enforcing 
  3762. and other components.
  3763.  
  3764. Requirements for Evidence
  3765.  
  3766. E3.6 The description of the architecture shall describe how the 
  3767. security enforcing functions of the security target will be 
  3768. provided.  It shall describe how the separation into 
  3769. security enforcing and other components is achieved.
  3770.  
  3771. Evaluator Actions
  3772.  
  3773. E3.7 Check that the information provided meets all requirements 
  3774. for content and presentation and evidence.  Check that the 
  3775. separation of security enforcing and other components is 
  3776. valid.
  3777.  
  3778.  
  3779. Phase 3 - Detailed Design
  3780.  
  3781. Requirements for Content and Presentation
  3782.  
  3783. E3.8 The detailed design shall specify all basic components.  It 
  3784. shall describe the realisation of all security enforcing 
  3785. and security relevant functions.  It shall identify all 
  3786. security mechanisms.  It shall map security enforcing 
  3787. functions to mechanisms and components.  All interfaces of 
  3788. security enforcing and security relevant components shall 
  3789. be documented stating their purpose and parameters.  
  3790. Specifications/definitions for mechanisms shall be 
  3791. provided.  These specifications shall be suitable for the 
  3792. analysis of interrelationships between the mechanisms 
  3793. employed.  Specifications need not be provided for 
  3794. components that are neither security enforcing nor security 
  3795. relevant.  Where more than one level of specification is 
  3796. provided, there shall be a clear and hierarchical 
  3797. relationship between levels.
  3798.  
  3799. Requirements for Evidence
  3800.  
  3801. E3.9 The detailed design shall describe how the security 
  3802. mechanisms provide the security enforcing functions 
  3803. specified in the security target.  It shall describe why 
  3804. components for which no design information is provided 
  3805. cannot be either security enforcing or security relevant.
  3806.  
  3807. Evaluator Actions
  3808.  
  3809. E3.10     Check that the information provided meets all 
  3810. requirements for content and presentation and evidence.
  3811.  
  3812.  
  3813. Phase 4 - Implementation
  3814.  
  3815. Requirements for Content and Presentation
  3816.  
  3817. E3.11     The description of correspondence shall describe the 
  3818. correspondence between source code or hardware drawings and 
  3819. basic components of the detailed design.  The test 
  3820. documentation shall contain plan, purpose, procedures and 
  3821. results of the tests.  The library of test programs shall 
  3822. contain test programs and tools to enable all tests covered 
  3823. by the test documentation to be repeated.
  3824.  
  3825. Requirements for Evidence
  3826.  
  3827. E3.12     The test documentation shall describe the 
  3828. correspondence between tests and the security enforcing 
  3829. functions defined in the security target.  It shall 
  3830. describe the correspondence between tests and the security 
  3831. enforcing and security relevant functions defined in the 
  3832. detailed design.  It shall describe the correspondence 
  3833. between tests and the security mechanisms as represented in 
  3834. the source code or hardware drawings.  Evidence of retests 
  3835. after the discovery and correction of errors relevant to 
  3836. security is obligatory to demonstrate that the errors have 
  3837. been eliminated and no new errors have been introduced.
  3838.  
  3839.  
  3840.  
  3841. Evaluator Actions
  3842.  
  3843. E3.13     Check that the information provided meets all 
  3844. requirements for content and presentation and evidence.  
  3845. Use the library of test programs to check by sampling the 
  3846. results of tests.  Check that tests cover all security 
  3847. enforcing functions identified in the security target.  
  3848. Check that the tests cover all security enforcing and 
  3849. security relevant functions identified in the detailed 
  3850. design and all security mechanisms identifiable in the 
  3851. source code or hardware drawings.  Check all retesting 
  3852. following the correction of errors.  Perform additional 
  3853. tests to search for errors.
  3854.  
  3855.  
  3856. Construction - The Development Environment
  3857.  
  3858. E3.14     The sponsor shall provide the following documentation:
  3859.  
  3860.      -    Configuration list identifying the version of the TOE 
  3861. for evaluation
  3862.  
  3863.      -    Information on the configuration control system
  3864.  
  3865.      -    Information on the acceptance procedure
  3866.  
  3867.      -    Information on the security of the development 
  3868. environment
  3869.  
  3870.      -    Description of all implementation languages used
  3871.  
  3872.  
  3873. Aspect 1 - Configuration Control
  3874.  
  3875. Requirements for Content and Presentation
  3876.  
  3877. E3.15     The development process shall be supported by a 
  3878. configuration control system and an acceptance procedure.  
  3879. The configuration list provided shall enumerate all basic 
  3880. components out of which the TOE is built.  The TOE, its 
  3881. basic components and all documents provided including the 
  3882. manuals and the source code or hardware drawings shall 
  3883. possess a unique identifier.  The use of this unique 
  3884. identifier is obligatory in references.  The configuration 
  3885. control system shall ensure that the TOE under evaluation 
  3886. matches the documentation provided and that only authorised 
  3887. changes are possible.
  3888.  
  3889.  
  3890.  
  3891.  
  3892.  
  3893. Requirements for Evidence
  3894.  
  3895. E3.16     The information on the configuration control system 
  3896. shall describe how it is used in practice and applied in 
  3897. the manufacturing process in accordance with the 
  3898. developer's quality management procedures.
  3899.  
  3900. Evaluator Actions
  3901.  
  3902. E3.17     Check that the documented procedures are being 
  3903. applied.  Check that the information provided meets all 
  3904. requirements for content and presentation and evidence.
  3905.  
  3906.  
  3907. Aspect 2 - Programming Languages and Compilers
  3908.  
  3909. Requirements for Content and Presentation
  3910.  
  3911. E3.18     Any programming languages used for implementation 
  3912. shall be well-defined, e.g. as in an ISO standard.  Any 
  3913. implementation dependent options of the programming 
  3914. language shall be documented.
  3915.  
  3916. Requirements for Evidence
  3917.  
  3918. E3.19     The definition of the programming languages shall 
  3919. define unambiguously the meaning of all statements used in 
  3920. the source code.
  3921.  
  3922. Evaluator Actions
  3923.  
  3924. E3.20     Check that the information provided meets all 
  3925. requirements for content and presentation and evidence.
  3926.  
  3927.  
  3928. Aspect 3 - Developers Security
  3929.  
  3930. Requirements for Content and Presentation
  3931.  
  3932. E3.21     The document on the security of the development 
  3933. environment shall describe the intended protection for the 
  3934. integrity of the TOE and the confidentiality of the 
  3935. associated documents.  Physical, procedural, personnel and 
  3936. other security measures used by the developer shall be 
  3937. described.
  3938.  
  3939.  
  3940.  
  3941. Requirements for Evidence
  3942.  
  3943. E3.22     The information on the security of the development 
  3944. environment shall describe how the integrity of the TOE and 
  3945. the confidentiality of the associated documentation are 
  3946. maintained.
  3947.  
  3948. Evaluator Actions
  3949.  
  3950. E3.23     Check that the documented procedures are being 
  3951. applied.  Check that the information provided meets all 
  3952. requirements for content and presentation and evidence.  
  3953. Search for errors in the procedures.
  3954.  
  3955.  
  3956. Operation - The Operational Documentation
  3957.  
  3958. E3.24     The sponsor shall provide the following documentation:
  3959.  
  3960.      -    User documentation
  3961.  
  3962.      -    Administration documentation
  3963.  
  3964.  
  3965. Aspect 1 - User Documentation
  3966.  
  3967. Requirements for Content and Presentation
  3968.  
  3969. E3.25     The user documentation shall describe the security 
  3970. enforcing functions relevant to the end-user.  It shall 
  3971. also give guidelines covering their secure operation.  The 
  3972. user documentation e.g. Reference Manuals, User Guides, 
  3973. shall be structured, internally consistent, and consistent 
  3974. with all other documents supplied for this level.
  3975.  
  3976. Requirements for Evidence
  3977.  
  3978. E3.26     The user documentation shall describe how an end-user 
  3979. uses the TOE in a secure manner.
  3980.  
  3981. Evaluator Actions
  3982.  
  3983. E3.27     Check that the information provided meets all 
  3984. requirements for content and presentation and evidence.
  3985.  
  3986.  
  3987.  
  3988. Aspect 2 - Administration Documentation
  3989.  
  3990. Requirements for Content and Presentation
  3991.  
  3992. E3.28     The administration documentation shall describe the 
  3993. security enforcing functions relevant to an administrator.  
  3994. It shall distinguish two types of functions:  those which 
  3995. allow an administrator to control security parameters, and 
  3996. those which only allow him to obtain information.  If an 
  3997. administrator is required, it shall describe all security 
  3998. parameters which are under his control.  It shall describe 
  3999. each type of security-relevant event, relevant to the 
  4000. administrative functions.  It shall describe details, 
  4001. sufficient for use, of procedures relevant to the 
  4002. administration of security.  It shall give guidelines on 
  4003. the consistent and effective use of the security features 
  4004. of the TOE and how those features interact.  It shall 
  4005. describe instructions on how the system/product shall be 
  4006. installed and how, if appropriate, it shall be configured.  
  4007. The administration documentation, e.g. Reference Manuals, 
  4008. Administrator Guides, shall be structured, internally 
  4009. consistent, and consistent with all other documents 
  4010. supplied for this level.
  4011.  
  4012. Requirements for Evidence
  4013.  
  4014. E3.29     The administration documentation shall describe how 
  4015. the TOE is administered in a secure manner.
  4016.  
  4017. Evaluator Actions
  4018.  
  4019. E3.30     Check that the information provided meets all 
  4020. requirements for content and presentation and evidence.
  4021.  
  4022.  
  4023. Operation - The Operational Environment
  4024.  
  4025. E3.31     The sponsor shall provide the following documentation:
  4026.  
  4027.      -    Delivery and Configuration Documentation
  4028.  
  4029.      -    Start-up and Operation Documentation
  4030.  
  4031.  
  4032.  
  4033.  
  4034.  
  4035.  
  4036.  
  4037. Aspect 1 - Delivery and Configuration
  4038.  
  4039. Requirements for Procedures and Standards
  4040.  
  4041. E3.32     If different configurations are possible, the impact 
  4042. of the configurations on security shall be described.  The 
  4043. procedures for delivery and system generation shall be 
  4044. described.  A procedure approved by the national 
  4045. certification body for this evaluation level shall be 
  4046. followed, which guarantees the authenticity of the 
  4047. delivered TOE.  While generating the TOE, any generation 
  4048. options and/or changes shall be audited in such a way that 
  4049. it is subsequently possible to reconstruct exactly how and 
  4050. when the TOE was generated.
  4051.  
  4052. Requirements for Evidence
  4053.  
  4054. E3.33     The information supplied shall describe how the 
  4055. procedures maintain security.
  4056.  
  4057. Evaluator Actions
  4058.  
  4059. E3.34     Check that the information provided meets all 
  4060. requirements for content and presentation and evidence.  
  4061. Check the correct application of the delivery procedures.  
  4062. Search for errors in the system generation procedures.
  4063.  
  4064.  
  4065. Aspect 2 - Start-up and Operation
  4066.  
  4067. Requirements for Procedures and Standards
  4068.  
  4069. E3.35     The procedures for secure start-up and operation shall 
  4070. be described.  If any security enforcing functions can be 
  4071. deactivated or modified during start-up, normal operation 
  4072. or maintenance, this shall be described.  If the TOE 
  4073. contains hardware which contains security enforcing 
  4074. hardware components, then administrator, end-user, or self 
  4075. initiated diagnostic tests shall exist that can be 
  4076. performed on the TOE in its operational environment.
  4077.  
  4078. Requirements for Evidence
  4079.  
  4080. E3.36     The information supplied shall describe how the 
  4081. procedures maintain security.  The sponsor shall provide 
  4082. example results from all diagnostic test procedures for 
  4083. security enforcing hardware components.  The sponsor shall 
  4084. provide examples of any audit trail output created during 
  4085. start-up and operation.
  4086.  
  4087.  
  4088.  
  4089. Evaluator Actions
  4090.  
  4091. E3.37     Check that the information provided meets all 
  4092. requirements for content and presentation and evidence.  
  4093. Check the example evidence required for start-up and 
  4094. operation.  Search for errors in the procedures.
  4095.  
  4096.  
  4097.  
  4098.  
  4099.  
  4100. LEVEL E4
  4101.  
  4102.  
  4103. Construction - The Development Process
  4104.  
  4105. E4.1 The sponsor shall provide the TOE, and the following 
  4106. documentation:
  4107.  
  4108.      -    The security target for the TOE
  4109.  
  4110.      -    Definition or reference to an underlying formally 
  4111. specified model of security
  4112.  
  4113.      -    Informal interpretation of the underlying model in 
  4114. terms of the security target
  4115.  
  4116.      -    Semiformal description of the architecture of the TOE
  4117.  
  4118.      -    Semiformal description of the detailed design
  4119.  
  4120.      -    Test documentation
  4121.  
  4122.      -    Library of test programs and tools used for testing 
  4123. the TOE
  4124.  
  4125.      -    Source code or hardware drawings for all security 
  4126. enforcing and security relevant components
  4127.  
  4128.      -    Informal description of correspondence between source 
  4129. code or hardware drawings and the detailed design
  4130.  
  4131.  
  4132. Phase 1 - Requirements
  4133.  
  4134. Requirements for Content and Presentation
  4135.  
  4136. E4.2 The security target shall describe the security enforcing 
  4137. functions to be provided by the TOE.  In the case of a 
  4138. system, in addition the security target shall include a 
  4139. System Security Policy (SSP) identifying the security 
  4140. objectives and the threats to the system.  In the case of a 
  4141. product, in addition the security target shall include a 
  4142. rationale, identifying the method of use for the product, 
  4143. the intended environment and the assumed threats within 
  4144. that environment.  A formal model of security policy shall 
  4145. be provided or referenced to define the underlying security 
  4146. policy to be enforced by the TOE.  An informal 
  4147. interpretation of this model in terms of the security 
  4148. target shall be provided.  The security enforcing functions 
  4149. within the security target shall be specified using both an 
  4150. informal and semiformal style as categorised in Chapter 2.
  4151.  
  4152. Requirements for Evidence
  4153.  
  4154. E4.3 In the case of a system the security target shall describe 
  4155. how the proposed functionality fulfils the security 
  4156. objectives and is adequate to counter the identified 
  4157. threats.  In the case of a product the security target 
  4158. shall describe how the functionality is appropriate for 
  4159. that method of use and is adequate to counter the assumed 
  4160. threats.  The informal interpretation of the formal 
  4161. security policy model shall describe how the security 
  4162. target satisfies the underlying security policy.
  4163.  
  4164. Evaluator Actions
  4165.  
  4166. E4.4 Check that the information provided meets all requirements 
  4167. for content and presentation and evidence.  Check that 
  4168. there are no inconsistencies in the security target.  Check 
  4169. that there are no security features in the security target 
  4170. that conflict with the underlying security policy.
  4171.  
  4172.  
  4173. Phase 2 - Architectural Design
  4174.  
  4175. Requirements for Content and Presentation
  4176.  
  4177. E4.5 A semiformal notation shall be used in the architectural 
  4178. design to produce a semiformal description.  It shall 
  4179. describe the general structure of the TOE.  It shall 
  4180. describe the external interfaces of the TOE.  It shall 
  4181. describe any hardware and firmware required by the TOE with 
  4182. a statement of the functionality of supporting protection 
  4183. mechanisms implemented in that hardware or firmware.  It 
  4184. shall describe the separation of the TOE into security 
  4185. enforcing and other components.
  4186.  
  4187. Requirements for Evidence
  4188.  
  4189. E4.6 The description of the architecture shall describe how the 
  4190. security enforcing functions of the security target will be 
  4191. provided.  It shall describe how the separation into 
  4192. security enforcing and other components is achieved.  It 
  4193. shall describe how the chosen structure provides for 
  4194. largely independent security enforcing components.
  4195.  
  4196.  
  4197.  
  4198.  
  4199.  
  4200. Evaluator Actions
  4201.  
  4202. E4.7 Check that the information provided meets all requirements 
  4203. for content and presentation and evidence.  Check that the 
  4204. separation of security enforcing and other components is 
  4205. valid.
  4206.  
  4207.  
  4208. Phase 3 - Detailed Design
  4209.  
  4210. Requirements for Content and Presentation
  4211.  
  4212. E4.8 A semiformal notation shall be used to develop a semiformal 
  4213. detailed design.  The detailed design shall specify all 
  4214. basic components.  It shall describe, through all levels of 
  4215. the design hierarchy, the realisation of all security 
  4216. enforcing and security relevant functions.  It shall 
  4217. describe the separation of the TOE into security enforcing, 
  4218. security relevant and other components.  It shall be 
  4219. structured into well-defined, largely independent basic 
  4220. components that facilitate testing and minimise the 
  4221. potential for violations of security.  It shall identify 
  4222. all security mechanisms.  It shall map security enforcing 
  4223. functions to mechanisms and components.  All interfaces of 
  4224. security enforcing and security relevant components shall 
  4225. be documented stating their purpose and parameters.  
  4226. Specifications/definitions for mechanisms shall be 
  4227. provided.  These specifications shall be suitable for the 
  4228. analysis of interrelationships between the mechanisms 
  4229. employed.  Specifications need not be provided for 
  4230. components that are neither security enforcing nor security 
  4231. relevant.  Where more than one level of specification is 
  4232. provided, there shall be a clear and hierarchical 
  4233. relationship between levels.
  4234.  
  4235. Requirements for Evidence
  4236.  
  4237. E4.9 The detailed design shall describe how the security 
  4238. mechanisms provide the security enforcing functions 
  4239. specified in the security target.  It shall describe why 
  4240. components for which no design information is provided 
  4241. cannot be either security enforcing or security relevant.
  4242.  
  4243. Evaluator Actions
  4244.  
  4245. E4.10     Check that the information provided meets all 
  4246. requirements for content and presentation and evidence.
  4247.  
  4248.  
  4249.  
  4250.  
  4251.  
  4252. Phase 4 - Implementation
  4253.  
  4254. Requirements for Content and Presentation
  4255.  
  4256. E4.11     The description of correspondence shall describe the 
  4257. correspondence between source code or hardware drawings and 
  4258. basic components of the detailed design.  The test 
  4259. documentation shall contain plan, purpose, procedures and 
  4260. results of the tests and a justification why the extent of 
  4261. test coverage is sufficient.  The library of test programs 
  4262. shall contain test programs and tools to enable all tests 
  4263. covered by the test documentation to be repeated.
  4264.  
  4265. Requirements for Evidence
  4266.  
  4267. E4.12     The test documentation shall describe the 
  4268. correspondence between tests and the security enforcing 
  4269. functions defined in the security target.  It shall 
  4270. describe the correspondence between tests and the security 
  4271. enforcing and security relevant functions defined in the 
  4272. detailed design.  It shall describe the correspondence 
  4273. between tests and the security mechanisms as represented in 
  4274. the source code or hardware drawings.  Evidence of retests 
  4275. after the discovery and correction of errors relevant to 
  4276. security is obligatory to demonstrate that the errors have 
  4277. been eliminated and no new errors have been introduced.
  4278.  
  4279. Evaluator Actions
  4280.  
  4281. E4.13     Check that the information provided meets all 
  4282. requirements for content and presentation and evidence.  
  4283. Use the library of test programs to check by sampling the 
  4284. results of tests.  Check that tests cover all security 
  4285. enforcing functions identified in the security target.  
  4286. Check that the tests cover all security enforcing and 
  4287. security relevant functions identified in the detailed 
  4288. design and all security mechanisms identifiable in the 
  4289. source code or hardware drawings.  Check all retesting 
  4290. following the correction of errors.  Perform additional 
  4291. tests to search for errors.
  4292.  
  4293.  
  4294. Construction - The Development Environment
  4295.  
  4296. E4.14     The sponsor shall provide the following documentation:
  4297.  
  4298.      -    Configuration list identifying the version of the TOE 
  4299. for evaluation
  4300.  
  4301.      -    Information on the configuration control system and 
  4302. its tools
  4303.  
  4304.      -    Audit information on modifications of all parts of the 
  4305. TOE subject to configuration control
  4306.      -    Information on the acceptance procedure
  4307.  
  4308.      -    Information on the security of the development 
  4309. environment
  4310.  
  4311.      -    Description of all implementation languages and 
  4312. compilers used
  4313.  
  4314.  
  4315. Aspect 1 - Configuration Control
  4316.  
  4317. Requirements for Content and Presentation
  4318.  
  4319. E4.15     The development process shall be supported by a tool 
  4320. based configuration control system and an acceptance 
  4321. procedure.  The configuration list provided shall enumerate 
  4322. all basic components out of which the TOE is built.  The 
  4323. TOE, its basic components and all documents provided 
  4324. including the manuals and the source code or hardware 
  4325. drawings shall possess a unique identifier.  The use of 
  4326. this unique identifier is obligatory in references.  The 
  4327. configuration control system shall ensure that the TOE 
  4328. under evaluation matches the documentation provided and 
  4329. that only authorised changes by authorised persons are 
  4330. possible.  The configuration control tools shall be able to 
  4331. control and audit changes between different versions of 
  4332. objects subject to configuration control.
  4333.  
  4334. Requirements for Evidence
  4335.  
  4336. E4.16     The information on the configuration control system 
  4337. shall describe how it is used in practice and applied in 
  4338. the manufacturing process in accordance with the 
  4339. developer's quality management procedures.
  4340.  
  4341. Evaluator Actions
  4342.  
  4343. E4.17     Check that the documented procedures are being 
  4344. applied.  Check that the information provided meets all 
  4345. requirements for content and presentation and evidence.  
  4346. Use the developers tools to rebuild selected parts of the 
  4347. TOE and compare with the submitted version of the TOE.
  4348.  
  4349.  
  4350. Aspect 2 - Programming Languages and Compilers
  4351.  
  4352. Requirements for Content and Presentation
  4353.  
  4354. E4.18     Any programming languages used for implementation 
  4355. shall be well-defined, e.g. as in an ISO standard.  Any 
  4356. implementation dependent options of the programming 
  4357. language shall be documented. For all compilers used, the 
  4358. implementation options selected shall be documented.
  4359.  
  4360.  
  4361. Requirements for Evidence
  4362.  
  4363. E4.19     The definition of the programming languages shall 
  4364. define unambiguously the meaning of all statements used in 
  4365. the source code.
  4366.  
  4367. Evaluator Actions
  4368.  
  4369. E4.20     Check that the information provided meets all 
  4370. requirements for content and presentation and evidence.
  4371.  
  4372.  
  4373. Aspect 3 - Developers Security
  4374.  
  4375. Requirements for Content and Presentation
  4376.  
  4377. E4.21     The document on the security of the development 
  4378. environment shall describe the intended protection for the 
  4379. integrity of the TOE and the confidentiality of the 
  4380. associated documents.  Physical, procedural, personnel and 
  4381. other security measures used by the developer shall be 
  4382. described.
  4383.  
  4384. Requirements for Evidence
  4385.  
  4386. E4.22     The information on the security of the development 
  4387. environment shall describe how the integrity of the TOE and 
  4388. the confidentiality of the associated documentation are 
  4389. maintained.
  4390.  
  4391. Evaluator Actions
  4392.  
  4393. E4.23     Check that the documented procedures are being 
  4394. applied.  Check that the information provided meets all 
  4395. requirements for content and presentation and evidence.  
  4396. Search for errors in the procedures.
  4397.  
  4398.  
  4399.  
  4400.  
  4401.  
  4402.  
  4403.  
  4404.  
  4405. Operation - The Operational Documentation
  4406.  
  4407. E4.24     The sponsor shall provide the following documentation:
  4408.  
  4409.      -    User documentation
  4410.  
  4411.      -    Administration documentation
  4412.  
  4413.  
  4414. Aspect 1 - User Documentation
  4415.  
  4416. Requirements for Content and Presentation
  4417.  
  4418. E4.25     The user documentation shall describe the security 
  4419. enforcing functions relevant to the end-user.  It shall 
  4420. also give guidelines covering their secure operation.  The 
  4421. user documentation e.g. Reference Manuals, User Guides, 
  4422. shall be structured, internally consistent, and consistent 
  4423. with all other documents supplied for this level.
  4424.  
  4425. Requirements for Evidence
  4426.  
  4427. E4.26     The user documentation shall describe how an end-user 
  4428. uses the TOE in a secure manner.
  4429.  
  4430. Evaluator Actions
  4431.  
  4432. E4.27     Check that the information provided meets all 
  4433. requirements for content and presentation and evidence.
  4434.  
  4435.  
  4436. Aspect 2 - Administration Documentation
  4437.  
  4438. Requirements for Content and Presentation
  4439.  
  4440. E4.28     The administration documentation shall describe the 
  4441. security enforcing functions relevant to an administrator.  
  4442. It shall distinguish two types of functions:  those which 
  4443. allow an administrator to control security parameters, and 
  4444. those which only allow him to obtain information.  If an 
  4445. administrator is required, it shall describe all security 
  4446. parameters which are under his control.  It shall describe 
  4447. each type of security-relevant event, relevant to the 
  4448. administrative functions.  It shall describe details, 
  4449. sufficient for use, of procedures relevant to the 
  4450. administration of security.  It shall give guidelines on 
  4451. the consistent and effective use of the security features 
  4452. of the TOE and how those features interact.  It shall 
  4453. describe instructions on how the system/product shall be 
  4454. installed and how, if appropriate, it shall be configured.  
  4455. The administration documentation, e.g. Reference Manuals, 
  4456. Administrator Guides, shall be structured, internally 
  4457. consistent, and consistent with all other documents 
  4458. supplied for this level.
  4459.  
  4460. Requirements for Evidence
  4461.  
  4462. E4.29     The administration documentation shall describe how 
  4463. the TOE is administered in a secure manner. 
  4464.  
  4465. Evaluator Actions
  4466.  
  4467. E4.30     Check that the information provided meets all 
  4468. requirements for content and presentation and evidence.
  4469.  
  4470.  
  4471. Operation - The Operational Environment
  4472.  
  4473. E4.31     The sponsor shall provide the following documentation:
  4474.  
  4475.      -    Delivery and Configuration Documentation
  4476.  
  4477.      -    Start-up and Operation Documentation
  4478.  
  4479.  
  4480. Aspect 1 - Delivery and Configuration
  4481.  
  4482. Requirements for Procedures and Standards
  4483.  
  4484. E4.32     If different configurations are possible, the impact 
  4485. of the configurations on security shall be described.  The 
  4486. procedures for delivery and system generation shall be 
  4487. described.  A procedure approved by the national 
  4488. certification body for this evaluation level shall be 
  4489. followed, which guarantees the authenticity of the 
  4490. delivered TOE.  While generating the TOE, any generation 
  4491. options and/or changes shall be audited in such a way that 
  4492. it is subsequently possible to reconstruct exactly how and 
  4493. when the TOE was generated.
  4494.  
  4495. Requirements for Evidence
  4496.  
  4497. E4.33     The information supplied shall describe how the 
  4498. procedures maintain security.
  4499.  
  4500.  
  4501.  
  4502.  
  4503. Evaluator Actions
  4504.  
  4505. E4.34     Check that the information provided meets all 
  4506. requirements for content and presentation and evidence.  
  4507. Check the correct application of the delivery procedures.  
  4508. Search for errors in the system generation procedures.
  4509.  
  4510.  
  4511. Aspect 2 - Start-up and Operation
  4512.  
  4513. Requirements for Procedures and Standards
  4514.  
  4515. E4.35     The procedures for secure start-up and operation shall 
  4516. be described.  If any security enforcing functions can be 
  4517. deactivated or modified during start-up, normal operation 
  4518. or maintenance, this shall be described.  Procedures shall 
  4519. exist which can restore the TOE to a secure state after a 
  4520. failure, or a hardware or software error.  If the TOE 
  4521. contains hardware which contains security enforcing 
  4522. hardware components, then administrator, end-user, or self 
  4523. initiated diagnostic tests shall exist that can be 
  4524. performed on the TOE in its operational environment.
  4525.  
  4526. Requirements for Evidence
  4527.  
  4528. E4.36     The information supplied shall describe how the 
  4529. procedures maintain security.  The sponsor shall provide 
  4530. example results from all diagnostic test procedures for 
  4531. security enforcing hardware components.  The sponsor shall 
  4532. provide examples of any audit trail output created during 
  4533. start-up and operation.
  4534.  
  4535. Evaluator Actions
  4536.  
  4537. E4.37     Check that the information provided meets all 
  4538. requirements for content and presentation and evidence.  
  4539. Check the example evidence required for start-up and 
  4540. operation.  Search for errors in the procedures.
  4541.  
  4542.  
  4543.  
  4544.  
  4545.  
  4546. LEVEL E5
  4547.  
  4548.  
  4549. Construction - The Development Process
  4550.  
  4551. E5.1 The sponsor shall provide the TOE, and the following 
  4552. documentation:
  4553.  
  4554.      -    The security target for the TOE
  4555.  
  4556.      -    Definition or reference to an underlying formally 
  4557. specified model of security
  4558.  
  4559.      -    Informal interpretation of the underlying model in 
  4560. terms of the security target
  4561.  
  4562.      -    Semiformal description of the architecture of the TOE
  4563.  
  4564.      -    Semiformal description of the detailed design
  4565.  
  4566.      -    Test documentation
  4567.  
  4568.      -    Library of test programs and tools used for testing 
  4569. the TOE
  4570.  
  4571.      -    Source code or hardware drawings for all security 
  4572. enforcing and security relevant components
  4573.  
  4574.      -    Informal description of correspondence between source 
  4575. code or hardware drawings and the detailed design
  4576.  
  4577.  
  4578. Phase 1 - Requirements
  4579.  
  4580. Requirements for Content and Presentation
  4581.  
  4582. E5.2 The security target shall explain the security enforcing 
  4583. functions to be provided by the TOE.  In the case of a 
  4584. system, in addition the security target shall include a 
  4585. System Security Policy (SSP) identifying the security 
  4586. objectives and the threats to the system.  In the case of a 
  4587. product, in addition the security target shall include a 
  4588. rationale, identifying the method of use for the product, 
  4589. the intended environment and the assumed threats within 
  4590. that environment.  A formal model of security policy shall 
  4591. be provided or referenced to define the underlying security 
  4592. policy to be enforced by the TOE.  An informal 
  4593. interpretation of this model in terms of the security 
  4594. target shall be provided.  The security enforcing functions 
  4595. within the security target shall be specified using both an 
  4596. informal and semiformal style as categorised in Chapter 2.
  4597.  
  4598. Requirements for Evidence
  4599.  
  4600. E5.3 In the case of a system the security target shall explain 
  4601. how the proposed functionality fulfils the security 
  4602. objectives and is adequate to counter the identified 
  4603. threats.  In the case of a product the security target 
  4604. shall explain how the functionality is appropriate for that 
  4605. method of use and is adequate to counter the assumed 
  4606. threats.  The informal interpretation of the formal 
  4607. security policy model shall explain how the security target 
  4608. satisfies the underlying security policy.
  4609.  
  4610. Evaluator Actions
  4611.  
  4612. E5.4 Check that the information provided meets all requirements 
  4613. for content and presentation and evidence.  Check that 
  4614. there are no inconsistencies in the security target.  Check 
  4615. that there are no security features in the security target 
  4616. that conflict with the underlying security policy.
  4617.  
  4618.  
  4619. Phase 2 - Architectural Design
  4620.  
  4621. Requirements for Content and Presentation
  4622.  
  4623. E5.5 A semiformal notation shall be used in the architectural 
  4624. design to produce a semiformal description.  It shall 
  4625. explain the general structure of the TOE.  It shall explain 
  4626. the external interfaces of the TOE.  It shall explain any 
  4627. hardware and firmware required by the TOE with a statement 
  4628. of the functionality of supporting protection mechanisms 
  4629. implemented in that hardware or firmware.  It shall explain 
  4630. the separation of the TOE into security enforcing and other 
  4631. components.  It shall explain the interrelationships 
  4632. between the security enforcing components.
  4633.  
  4634. Requirements for Evidence
  4635.  
  4636. E5.6 The description of the architecture shall explain how the 
  4637. security enforcing functions of the security target will be 
  4638. provided.  It shall explain how the separation into 
  4639. security enforcing and other components is achieved.  It 
  4640. shall explain how the chosen structure provides for largely 
  4641. independent security enforcing components.  It shall 
  4642. explain why the interrelationships between the security 
  4643. enforcing components are necessary.
  4644.  
  4645.  
  4646.  
  4647. Evaluator Actions
  4648.  
  4649. E5.7 Check that the information provided meets all requirements 
  4650. for content and presentation and evidence.  Check that the 
  4651. separation of security enforcing and other components is 
  4652. valid.
  4653.  
  4654.  
  4655. Phase 3 - Detailed Design
  4656.  
  4657. Requirements for Content and Presentation
  4658.  
  4659. E5.8 A semiformal notation shall be used to develop a semiformal 
  4660. detailed design.  The detailed design shall specify all 
  4661. basic components.  It shall explain, through all levels of 
  4662. the design hierarchy, the realisation of all security 
  4663. enforcing and security relevant functions.  It shall 
  4664. explain the separation of the TOE into security enforcing, 
  4665. security relevant and other components.  It shall be 
  4666. structured into well-defined, largely independent basic 
  4667. components that facilitate testing and minimise the 
  4668. potential for violations of security.  It shall incorporate 
  4669. significant use of layering, abstraction and data hiding.  
  4670. It shall identify all security mechanisms.  It shall map 
  4671. security enforcing functions to mechanisms and functional 
  4672. units.  Unnecessary functionality shall be excluded from 
  4673. security enforcing and security relevant components.  All 
  4674. interfaces of security enforcing and security relevant 
  4675. components shall be documented stating their purpose and 
  4676. parameters and effects.  The purpose of all variables used 
  4677. by more than one functional unit shall be explained.  
  4678. Specifications/definitions for mechanisms shall be 
  4679. provided.  These specifications shall be suitable for the 
  4680. analysis of interrelationships between the mechanisms 
  4681. employed.  Specifications need not be provided for 
  4682. components that are neither security enforcing nor security 
  4683. relevant.  Where more than one level of specification is 
  4684. provided, there shall be a clear and hierarchical 
  4685. relationship between levels.
  4686.  
  4687. Requirements for Evidence
  4688.  
  4689. E5.9 The detailed design shall explain how the security 
  4690. mechanisms provide the security enforcing functions 
  4691. specified in the security target.  It shall explain why the 
  4692. remaining functionality cannot be excluded from the 
  4693. security enforcing and security relevant components.  It 
  4694. shall explain why components for which no design 
  4695. information is provided cannot be either security enforcing 
  4696. or security relevant.
  4697.  
  4698. Evaluator Actions
  4699.  
  4700. E5.10     Check that the information provided meets all 
  4701. requirements for content and presentation and evidence.
  4702. Phase 4 - Implementation
  4703.  
  4704. Requirements for Content and Presentation
  4705.  
  4706. E5.11     The source code and hardware drawings shall be 
  4707. completely structured into small, comprehensible, separate 
  4708. sections.  The description of correspondence shall explain 
  4709. the correspondence between source code or hardware drawings 
  4710. and functional units of the detailed design.  The test 
  4711. documentation shall contain plan, purpose, procedures and 
  4712. results of the tests and a justification why the extent of 
  4713. test coverage is sufficient.  The library of test programs 
  4714. shall contain test programs and tools to enable all tests 
  4715. covered by the test documentation to be repeated.
  4716.  
  4717. Requirements for Evidence
  4718.  
  4719. E5.12     The test documentation shall explain the 
  4720. correspondence between tests and the security enforcing 
  4721. functions defined in the security target.  It shall explain 
  4722. the correspondence between tests and the security enforcing 
  4723. and security relevant functions defined in the detailed 
  4724. design.  It shall explain the correspondence between tests 
  4725. and the security mechanisms as represented in the source 
  4726. code or hardware drawings.  Evidence of retests after the 
  4727. discovery and correction of errors relevant to security is 
  4728. obligatory to demonstrate that the errors have been 
  4729. eliminated and no new errors have been introduced.
  4730.  
  4731. Evaluator Actions
  4732.  
  4733. E5.13     Check that the information provided meets all 
  4734. requirements for content and presentation and evidence.  
  4735. Use the library of test programs to check by sampling the 
  4736. results of tests.  Check that tests cover all security 
  4737. enforcing functions identified in the security target.  
  4738. Check that the tests cover all security enforcing and 
  4739. security relevant functions identified in the detailed 
  4740. design and all security mechanisms identifiable in the 
  4741. source code or hardware drawings.  Check all retesting 
  4742. following the correction of errors.  Perform additional 
  4743. tests to search for errors.
  4744.  
  4745.  
  4746. Construction - The Development Environment
  4747.  
  4748. E5.14     The sponsor shall provide the following documentation:
  4749.  
  4750.      -    Configuration list identifying the version of the TOE 
  4751. for evaluation
  4752.  
  4753.      -    Information on the configuration control system and 
  4754. its tools
  4755.  
  4756.      -    Audit information on modifications of all objects of 
  4757. the TOE subject to configuration control
  4758.  
  4759.      -    Information on the acceptance procedure
  4760.  
  4761.      -    Information on the integration procedure
  4762.  
  4763.      -    Information on the security of the development 
  4764. environment
  4765.  
  4766.      -    Description of all implementation languages and 
  4767. compilers used
  4768.  
  4769.      -    Source code of all runtime libraries used
  4770.  
  4771.  
  4772. Aspect 1 - Configuration Control
  4773.  
  4774. Requirements for Content and Presentation
  4775.  
  4776. E5.15     The development process shall be supported by a tool 
  4777. based configuration control system and an acceptance 
  4778. procedure.  The configuration control tools shall ensure 
  4779. that the person responsible for acceptance of an object 
  4780. into configuration control was not one of its designers or 
  4781. developers.  The configuration list provided shall 
  4782. enumerate all basic components out of which the TOE is 
  4783. built.  The TOE, its basic components and all documents 
  4784. provided including the manuals and the source code or 
  4785. hardware drawings shall possess a unique identifier.  The 
  4786. use of this unique identifier is obligatory in references.  
  4787. The configuration control system shall ensure that the TOE 
  4788. under evaluation matches the documentation provided and 
  4789. that only authorised changes by authorised persons are 
  4790. possible.  All objects created during the development 
  4791. process which pass through the acceptance procedure shall 
  4792. be subject to configuration control.  All security 
  4793. enforcing and security relevant objects under configuration 
  4794. control shall be identified as such.  The configuration 
  4795. control tools shall be able to control and audit changes 
  4796. between different versions of objects subject to 
  4797. configuration control.  All modifications of these objects 
  4798. shall be audited with originator, date and time.  The 
  4799. configuration control tools shall be able to support the 
  4800. creation and handling of variable relationships between 
  4801. objects under configuration control.  In the event of a 
  4802. change to any of these objects, the tools shall be able to 
  4803. identify all other objects under configuration control 
  4804. affected by this change together with an indication of 
  4805. whether they are security enforcing or security relevant 
  4806. objects.
  4807.  
  4808.  
  4809.  
  4810.  
  4811. Requirements for Evidence
  4812.  
  4813. E5.16     The information on the configuration control system 
  4814. and the integration procedure shall explain how they are 
  4815. used in practice and applied in the manufacturing process 
  4816. in accordance with the developer's quality management 
  4817. procedures.  The information on the configuration control 
  4818. system shall explain how the tools ensure that the person 
  4819. responsible for acceptance of an object was not one of its 
  4820. designers or developers.  Example audit trail output from 
  4821. the configuration control system shall be provided.
  4822.  
  4823. Evaluator Actions
  4824.  
  4825. E5.17     Check that the documented procedures are being 
  4826. applied.  Check that the information provided meets all 
  4827. requirements for content and presentation and evidence.  
  4828. Check the example audit trail output.  Use the developers 
  4829. tools to create selected parts of the TOE and compare with 
  4830. the submitted version of the TOE.
  4831.  
  4832.  
  4833. Aspect 2 - Programming Languages and Compilers
  4834.  
  4835. Requirements for Content and Presentation
  4836.  
  4837. E5.18     Any programming languages used for implementation 
  4838. shall be well-defined, e.g. as in an ISO standard.  Any 
  4839. implementation dependent options of the programming 
  4840. language shall be documented.  For all compilers used, the 
  4841. implementation options selected shall be documented.  The 
  4842. source code of any runtime libraries shall be provided.
  4843.  
  4844. Requirements for Evidence
  4845.  
  4846. E5.19     The definition of the programming languages shall 
  4847. define unambiguously the meaning of all statements used in 
  4848. the source code.
  4849.  
  4850. Evaluator Actions
  4851.  
  4852. E5.20     Check that the information provided meets all 
  4853. requirements for content and presentation and evidence.
  4854.  
  4855.  
  4856.  
  4857.  
  4858.  
  4859. Aspect 3 - Developers Security
  4860.  
  4861. Requirements for Content and Presentation
  4862.  
  4863. E5.21     The document on the security of the development 
  4864. environment shall explain the intended protection for the 
  4865. integrity of the TOE and the confidentiality of the 
  4866. associated documents.  Physical, procedural, personnel and 
  4867. other security measures used by the developer shall be 
  4868. explained.
  4869.  
  4870. Requirements for Evidence
  4871.  
  4872. E5.22     The information on the security of the development 
  4873. environment shall explain how the integrity of the TOE and 
  4874. the confidentiality of the associated documentation are 
  4875. maintained.
  4876.  
  4877. Evaluator Actions
  4878.  
  4879. E5.23     Check that the documented procedures are being 
  4880. applied.  Check that the information provided meets all 
  4881. requirements for content and presentation and evidence.  
  4882. Search for errors in the procedures.
  4883.  
  4884.  
  4885. Operation - The Operational Documentation
  4886.  
  4887. E5.24     The sponsor shall provide the following documentation:
  4888.  
  4889.      -    User documentation
  4890.  
  4891.      -    Administration documentation
  4892.  
  4893.  
  4894. Aspect 1 - User Documentation
  4895.  
  4896. Requirements for Content and Presentation
  4897.  
  4898. E5.25     The user documentation shall explain the security 
  4899. enforcing functions relevant to the end-user.  It shall 
  4900. also give guidelines covering their secure operation.  The 
  4901. user documentation e.g. Reference Manuals, User Guides, 
  4902. shall be structured, internally consistent, and consistent 
  4903. with all other documents supplied for this level.
  4904.  
  4905.  
  4906.  
  4907.  
  4908. Requirements for Evidence
  4909.  
  4910. E5.26     The user documentation shall explain how an end-user 
  4911. uses the TOE in a secure manner.
  4912.  
  4913. Evaluator Actions
  4914.  
  4915. E5.27     Check that the information provided meets all 
  4916. requirements for content and presentation and evidence.
  4917.  
  4918.  
  4919. Aspect 2 - Administration Documentation
  4920.  
  4921. Requirements for Content and Presentation
  4922.  
  4923. E5.28     The administration documentation shall explain the 
  4924. security enforcing functions relevant to an administrator.  
  4925. It shall distinguish two types of functions:  those which 
  4926. allow an administrator to control security parameters, and 
  4927. those which only allow him to obtain information.  If an 
  4928. administrator is required, it shall explain all security 
  4929. parameters which are under his control.  It shall explain 
  4930. each type of security-relevant event, relevant to the 
  4931. administrative functions.  It shall explain details, 
  4932. sufficient for use, of procedures relevant to the 
  4933. administration of security.  It shall give guidelines on 
  4934. the consistent and effective use of the security features 
  4935. of the TOE and how those features interact.  It shall 
  4936. explain instructions on how the system/product shall be 
  4937. installed and how, if appropriate, it shall be configured.  
  4938. The administration documentation, e.g. Reference Manuals, 
  4939. Administrator Guides, shall be structured, internally 
  4940. consistent, and consistent with all other documents 
  4941. supplied for this level.
  4942.  
  4943. Requirements for Evidence
  4944.  
  4945. E5.29     The administration documentation shall explain how the 
  4946. TOE is administered in a secure manner.
  4947.  
  4948. Evaluator Actions
  4949.  
  4950. E5.30     Check that the information provided meets all 
  4951. requirements for content and presentation and evidence.
  4952.  
  4953.  
  4954.  
  4955.  
  4956.  
  4957. Operation - The Operational Environment
  4958.  
  4959. E5.31     The sponsor shall provide the following documentation:
  4960.  
  4961.      -    Delivery and Configuration Documentation
  4962.  
  4963.      -    Start-up and Operation Documentation
  4964.  
  4965.  
  4966. Aspect 1 - Delivery and Configuration
  4967.  
  4968. Requirements for Procedures and Standards
  4969.  
  4970. E5.32     If different configurations are possible, the impact 
  4971. of the configurations on security shall be explained.  The 
  4972. procedures for delivery and system generation shall be 
  4973. explained.  A procedure approved by the national 
  4974. certification body for this evaluation level shall be 
  4975. followed, which guarantees the authenticity of the 
  4976. delivered TOE.  While generating the TOE, any generation 
  4977. options and/or changes shall be audited in such a way that 
  4978. it is subsequently possible to reconstruct exactly how and 
  4979. when the TOE was generated.
  4980.  
  4981. Requirements for Evidence
  4982.  
  4983. E5.33     The information supplied shall explain how the 
  4984. procedures maintain security.
  4985.  
  4986. Evaluator Actions
  4987.  
  4988. E5.34     Check that the information provided meets all 
  4989. requirements for content and presentation and evidence.  
  4990. Check the correct application of the delivery procedures.  
  4991. Search for errors in the system generation procedures.
  4992.  
  4993.  
  4994. Aspect 2 - Start-up and Operation
  4995.  
  4996. Requirements for Procedures and Standards
  4997.  
  4998. E5.35     The procedures for secure start-up and operation shall 
  4999. be explained.  If any security enforcing functions can be 
  5000. deactivated or modified during start-up, normal operation 
  5001. or maintenance, this shall be explained.  Procedures shall 
  5002. exist which can restore the TOE to a secure state after a 
  5003. failure, or a hardware or software error.  If the TOE 
  5004. contains hardware which contains security enforcing 
  5005. hardware components, then administrator, end-user, or self 
  5006. initiated diagnostic tests shall exist that can be 
  5007. performed on the TOE in its operational environment.
  5008. Requirements for Evidence
  5009.  
  5010. E5.36     The information supplied shall explain how the 
  5011. procedures maintain security.  The sponsor shall provide 
  5012. example results from all diagnostic test procedures for 
  5013. security enforcing hardware components.  The sponsor shall 
  5014. provide examples of any audit trail output created during 
  5015. start-up and operation.
  5016.  
  5017. Evaluator Actions
  5018.  
  5019. E5.37     Check that the information provided meets all 
  5020. requirements for content and presentation and evidence.  
  5021. Check the example evidence required for start-up and 
  5022. operation.  Search for errors in the procedures.
  5023.  
  5024.  
  5025.  
  5026.  
  5027.  
  5028. LEVEL E6
  5029.  
  5030.  
  5031. Construction - The Development Process
  5032.  
  5033. E6.1 The sponsor shall provide the TOE, and the following 
  5034. documentation:
  5035.  
  5036.      -    The security target for the TOE
  5037.  
  5038.      -    Definition or reference to an underlying formally 
  5039. specified model of security
  5040.  
  5041.      -    Informal interpretation of the underlying model in 
  5042. terms of the security target
  5043.  
  5044.      -    Formal description of the architecture of the TOE
  5045.  
  5046.      -    Semiformal description of the detailed design
  5047.  
  5048.      -    Test documentation
  5049.  
  5050.      -    Library of test programs and tools used for testing 
  5051. the TOE, including tools which can be used to detect 
  5052. inconsistencies between source code and executable 
  5053. code if there are any security enforcing or security 
  5054. relevant source code components (e.g. a disassembler 
  5055. and/or a debugger)
  5056.  
  5057.      -    Source code or hardware drawings for all security 
  5058. enforcing and security relevant components
  5059.  
  5060.      -    Informal description of correspondence between source 
  5061. code or hardware drawings and the detailed design and 
  5062. the formal specification of security enforcing 
  5063. functions
  5064.  
  5065.  
  5066. Phase 1 - Requirements
  5067.  
  5068. Requirements for Content and Presentation
  5069.  
  5070. E6.2 The security target shall explain the security enforcing 
  5071. functions to be provided by the TOE.  In the case of a 
  5072. system, in addition the security target shall include a 
  5073. System Security Policy (SSP) identifying the security 
  5074. objectives and the threats to the system.  In the case of a 
  5075. product, in addition the security target shall include a 
  5076. rationale, identifying the method of use for the product, 
  5077. the intended environment and the assumed threats within 
  5078. that environment.  A formal model of security policy shall 
  5079. be provided or referenced to define the underlying security 
  5080. policy to be enforced by the TOE.  An informal 
  5081. interpretation of this model in terms of the security 
  5082. target shall be provided.  The security enforcing functions 
  5083. within the security target shall be specified using both an 
  5084. informal and formal style as categorised in Chapter 2.
  5085.  
  5086. Requirements for Evidence
  5087.  
  5088. E6.3 In the case of a system the security target shall explain 
  5089. how the proposed functionality fulfils the security 
  5090. objectives and is adequate to counter the identified 
  5091. threats.  In the case of a product the security target 
  5092. shall explain how the functionality is appropriate for that 
  5093. method of use and is adequate to counter the assumed 
  5094. threats.  The informal interpretation of the formal 
  5095. security policy model shall explain how the security target 
  5096. satisfies the underlying security policy.
  5097.  
  5098. Evaluator Actions
  5099.  
  5100. E6.4 Check that the information provided meets all requirements 
  5101. for content and presentation and evidence.  Check that 
  5102. there are no inconsistencies in the security target.  Check 
  5103. that there are no security features in the security target 
  5104. that conflict with the underlying security policy.
  5105.  
  5106.  
  5107. Phase 2 - Architectural Design
  5108.  
  5109. Requirements for Content and Presentation
  5110.  
  5111. E6.5 A formal notation shall be used in the architectural design 
  5112. to produce a formal description.  It shall explain the 
  5113. general structure of the TOE.  It shall explain the 
  5114. external interfaces of the TOE.  It shall explain any 
  5115. hardware and firmware required by the TOE with a statement 
  5116. of the functionality of supporting protection mechanisms 
  5117. implemented in that hardware or firmware.  It shall explain 
  5118. the separation of the TOE into security enforcing and other 
  5119. components.  It shall explain the interrelationships 
  5120. between the security enforcing components.
  5121.  
  5122. Requirements for Evidence
  5123.  
  5124. E6.6 The description of the architecture shall explain how the 
  5125. security enforcing functions of the security target will be 
  5126. provided.  It shall explain how the separation into 
  5127. security enforcing and other components is achieved.  It 
  5128. shall explain how the chosen structure provides for largely 
  5129. independent security enforcing components.  It shall 
  5130. explain why the interrelationships between the security 
  5131. enforcing components are necessary.  It shall explain, 
  5132. using a combination of formal and informal techniques, how 
  5133. it is consistent with the formal security policy model of 
  5134. the underlying security policy.
  5135.  
  5136. Evaluator Actions
  5137.  
  5138. E6.7 Check that the information provided meets all requirements 
  5139. for content and presentation and evidence.  Check that the 
  5140. separation of security enforcing and other components is 
  5141. valid.  Check that formal arguments are valid.
  5142.  
  5143.  
  5144. Phase 3 - Detailed Design
  5145.  
  5146. Requirements for Content and Presentation
  5147.  
  5148. E6.8 A semiformal notation shall be used to develop a semiformal 
  5149. detailed design.  The detailed design shall specify all 
  5150. basic components.  It shall explain, through all levels of 
  5151. the design hierarchy, the realisation of all security 
  5152. enforcing and security relevant functions.  It shall 
  5153. explain the separation of the TOE into security enforcing, 
  5154. security relevant and other components.  It shall be 
  5155. structured into well-defined, largely independent basic 
  5156. components that facilitate testing and minimise the 
  5157. potential for violations of security.  It shall incorporate 
  5158. significant use of layering, abstraction and data hiding.  
  5159. It shall identify all security mechanisms.  It shall map 
  5160. security enforcing functions to mechanisms and functional 
  5161. units.  Unnecessary functionality shall be excluded from 
  5162. security enforcing and security relevant components.  All 
  5163. interfaces of security enforcing and security relevant 
  5164. components shall be documented stating their purpose and 
  5165. parameters and effects.  The purpose of all variables used 
  5166. by more than one functional unit shall be explained.  
  5167. Specifications/definitions for mechanisms shall be 
  5168. provided.  These specifications shall be suitable for the 
  5169. analysis of interrelationships between the mechanisms 
  5170. employed.  Specifications need not be provided for 
  5171. components that are neither security enforcing nor security 
  5172. relevant.  Where more than one level of specification is 
  5173. provided, there shall be a clear and hierarchical 
  5174. relationship between levels.
  5175.  
  5176. Requirements for Evidence
  5177.  
  5178. E6.9 The detailed design shall explain how the security 
  5179. mechanisms provide the security enforcing functions 
  5180. specified in the security target.  It shall explain why the 
  5181. remaining functionality cannot be excluded from the 
  5182. security enforcing and security relevant components.  It 
  5183. shall explain why components for which no design 
  5184. information is provided cannot be either security enforcing 
  5185. or security relevant.
  5186.  
  5187.  
  5188. Evaluator Actions
  5189.  
  5190. E6.10     Check that the information provided meets all 
  5191. requirements for content and presentation and evidence.
  5192.  
  5193.  
  5194. Phase 4 - Implementation
  5195.  
  5196. Requirements for Content and Presentation
  5197.  
  5198. E6.11     The source code and hardware drawings shall be 
  5199. completely structured into small, comprehensible, separate 
  5200. sections.  The description of correspondence shall explain 
  5201. the correspondence between source code or hardware drawings 
  5202. and functional units of the detailed design.  It shall 
  5203. explain the correspondence between the security mechanisms 
  5204. as represented in the source code or hardware drawings and 
  5205. the formal specification of security enforcing functions in 
  5206. the security target.  The test documentation shall contain 
  5207. plan, purpose, procedures and results of the tests and a 
  5208. justification why the extent of test coverage is 
  5209. sufficient.  The library of test programs shall contain 
  5210. test programs and tools to enable all tests covered by the 
  5211. test documentation to be repeated.
  5212.  
  5213. Requirements for Evidence
  5214.  
  5215. E6.12     The test documentation shall explain the 
  5216. correspondence between tests and the formal specification 
  5217. of security enforcing functions defined in the security 
  5218. target.  It shall explain the correspondence between tests 
  5219. and the security enforcing and security relevant functions 
  5220. defined in the detailed design.  It shall explain the 
  5221. correspondence between tests and the security mechanisms as 
  5222. represented in the source code or hardware drawings.  
  5223. Evidence of retests after the discovery and correction of 
  5224. errors relevant to security is obligatory to demonstrate 
  5225. that the errors have been eliminated and no new errors have 
  5226. been introduced.
  5227.  
  5228. Evaluator Actions
  5229.  
  5230. E6.13     Check that the information provided meets all 
  5231. requirements for content and presentation and evidence.  
  5232. Use the library of test programs to check by sampling the 
  5233. results of tests.  Check that tests cover all security 
  5234. enforcing functions identified in the security target.  
  5235. Check that the tests cover all security enforcing and 
  5236. security relevant functions identified in the detailed 
  5237. design and all security mechanisms identifiable in the 
  5238. source code or hardware drawings.  Check all retesting 
  5239. following the correction of errors.  Perform additional 
  5240. tests to search for errors.  Investigate any suspected 
  5241. inconsistencies between source code and executable code 
  5242. found during testing using the sponsor supplied tools.
  5243. Construction - The Development Environment
  5244.  
  5245. E6.14     The sponsor shall provide the following documentation:
  5246.  
  5247.      -    Configuration list identifying the version of the TOE 
  5248. for evaluation
  5249.  
  5250.      -    Information on the configuration control system and 
  5251. its tools
  5252.  
  5253.      -    Audit information on modifications of all objects of 
  5254. the TOE subject to configuration control
  5255.  
  5256.      -    Information on the acceptance procedure
  5257.  
  5258.      -    Information on the integration procedure
  5259.  
  5260.      -    Information on the security of the development 
  5261. environment
  5262.  
  5263.      -    Description of all implementation languages and 
  5264. compilers used
  5265.  
  5266.      -    Source code of all runtime libraries used
  5267.  
  5268.  
  5269. Aspect 1 - Configuration Control
  5270.  
  5271. Requirements for Content and Presentation
  5272.  
  5273. E6.15     The development process shall be supported by a tool 
  5274. based configuration control system and an acceptance 
  5275. procedure.  The configuration control tools shall ensure 
  5276. that the person responsible for acceptance of an object 
  5277. into configuration control was not one of its designers or 
  5278. developers.  The configuration list provided shall 
  5279. enumerate all basic components out of which the TOE is 
  5280. built.  The TOE, its basic components and all documents 
  5281. provided including the manuals and the source code or 
  5282. hardware drawings shall possess a unique identifier.  The 
  5283. use of this unique identifier is obligatory in references.  
  5284. The configuration control system shall ensure that the TOE 
  5285. under evaluation matches the documentation provided and 
  5286. that only authorised changes by authorised persons are 
  5287. possible.  All tools used in the development process shall 
  5288. be subject to configuration control.  All objects created 
  5289. during the development process which pass through the 
  5290. acceptance procedure shall be subject to configuration 
  5291. control.  All security enforcing and security relevant 
  5292. objects under configuration control shall be identified as 
  5293. such.  The configuration control tools shall be able to 
  5294. control and audit changes between different versions of 
  5295. objects subject to configuration control.  All 
  5296. modifications of these objects shall be audited with 
  5297. originator, date and time.  The configuration control tools 
  5298. shall be able to support the creation and handling of 
  5299. variable relationships between objects under configuration 
  5300. control.  In the event of a change to any of these objects, 
  5301. the tools shall be able to identify all other objects under 
  5302. configuration control affected by this change together with 
  5303. an indication of whether they are security enforcing or 
  5304. security relevant objects.
  5305.  
  5306. Requirements for Evidence
  5307.  
  5308. E6.16     The information on the configuration control system 
  5309. and the integration procedure shall explain how they are 
  5310. used in practice and applied in the manufacturing process 
  5311. in accordance with the developer's quality management 
  5312. procedures.  The information on the configuration control 
  5313. system shall explain how the tools ensure that the person 
  5314. responsible for acceptance of an object was not one of its 
  5315. designers or developers.  Example audit trail output from 
  5316. the configuration control system shall be provided.
  5317.  
  5318. Evaluator Actions
  5319.  
  5320. E6.17     Check that the documented procedures are being 
  5321. applied.  Check that the information provided meets all 
  5322. requirements for content and presentation and evidence.  
  5323. Check the example audit trail output.  Use the developers 
  5324. tools to create selected parts of the TOE and compare with 
  5325. the submitted version of the TOE.
  5326.  
  5327.  
  5328. Aspect 2 - Programming Languages and Compilers
  5329.  
  5330. Requirements for Content and Presentation
  5331.  
  5332. E6.18     Any programming languages used for implementation 
  5333. shall be well-defined, e.g. as in an ISO standard.  Any 
  5334. implementation dependent options of the programming 
  5335. language shall be documented.  For all compilers used, the 
  5336. implementation options selected shall be documented.  The 
  5337. source code of any runtime libraries shall be provided.
  5338.  
  5339. Requirements for Evidence
  5340.  
  5341. E6.19     The definition of the programming languages shall 
  5342. define unambiguously the meaning of all statements used in 
  5343. the source code.
  5344.  
  5345.  
  5346.  
  5347.  
  5348.  
  5349. Evaluator Actions
  5350.  
  5351. E6.20     Check that the information provided meets all 
  5352. requirements for content and presentation and evidence.
  5353.  
  5354.  
  5355. Aspect 3 - Developers Security
  5356.  
  5357. Requirements for Content and Presentation
  5358.  
  5359. E6.21     The document on the security of the development 
  5360. environment shall explain the intended protection for the 
  5361. integrity of the TOE and the confidentiality of the 
  5362. associated documents.  Physical, procedural, personnel and 
  5363. other security measures used by the developer shall be 
  5364. explained.
  5365.  
  5366. Requirements for Evidence
  5367.  
  5368. E6.22     The information on the security of the development 
  5369. environment shall explain how the integrity of the TOE and 
  5370. the confidentiality of the associated documentation are 
  5371. maintained.
  5372.  
  5373. Evaluator Actions
  5374.  
  5375. E6.23     Check that the documented procedures are being 
  5376. applied.  Check that the information provided meets all 
  5377. requirements for content and presentation and evidence.  
  5378. Search for errors in the procedures.
  5379.  
  5380.  
  5381. Operation - The Operational Documentation
  5382.  
  5383. E6.24     The sponsor shall provide the following documentation:
  5384.  
  5385.      -    User documentation
  5386.  
  5387.      -    Administration documentation
  5388.  
  5389.  
  5390. Aspect 1 - User Documentation
  5391.  
  5392. Requirements for Content and Presentation
  5393.  
  5394. E6.25     The user documentation shall explain the security 
  5395. enforcing functions relevant to the end-user.  It shall 
  5396. also give guidelines covering their secure operation.  The 
  5397. user documentation e.g. Reference Manuals, User Guides, 
  5398. shall be structured, internally consistent, and consistent 
  5399. with all other documents supplied for this level.
  5400.  
  5401. Requirements for Evidence
  5402.  
  5403. E6.26     The user documentation shall explain how an end-user 
  5404. uses the TOE in a secure manner.
  5405.  
  5406. Evaluator Actions
  5407.  
  5408. E6.27     Check that the information provided meets all 
  5409. requirements for content and presentation and evidence.
  5410.  
  5411.  
  5412. Aspect 2 - Administration Documentation
  5413.  
  5414. Requirements for Content and Presentation
  5415.  
  5416. E6.28     The administration documentation shall explain the 
  5417. security enforcing functions relevant to an administrator.  
  5418. It shall distinguish two types of functions:  those which 
  5419. allow an administrator to control security parameters, and 
  5420. those which only allow him to obtain information.  If an 
  5421. administrator is required, it shall explain all security 
  5422. parameters which are under his control.  It shall explain 
  5423. each type of security-relevant event, relevant to the 
  5424. administrative functions.  It shall explain details, 
  5425. sufficient for use, of procedures relevant to the 
  5426. administration of security.  It shall give guidelines on 
  5427. the consistent and effective use of the security features 
  5428. of the TOE and how those features interact.  It shall 
  5429. explain instructions on how the system/product shall be 
  5430. installed and how, if appropriate, it shall be configured.  
  5431. The administration documentation, e.g. Reference Manuals, 
  5432. Administrator Guides, shall be structured, internally 
  5433. consistent, and consistent with all other documents 
  5434. supplied for this level.
  5435.  
  5436. Requirements for Evidence
  5437.  
  5438. E6.29     The administration documentation shall explain how the 
  5439. TOE is administered in a secure manner.
  5440.  
  5441. Evaluator Actions
  5442.  
  5443. E6.30     Check that the information provided meets all 
  5444. requirements for content and presentation and evidence.
  5445.  
  5446.  
  5447. Operation - The Operational Environment
  5448.  
  5449. E6.31     The sponsor shall provide the following documentation:
  5450.  
  5451.      -    Delivery and Configuration Documentation
  5452.  
  5453.      -    Start-up and Operation Documentation
  5454.  
  5455.  
  5456. Aspect 1 - Delivery and Configuration
  5457.  
  5458. Requirements for Procedures and Standards
  5459.  
  5460. E6.32     If different configurations are possible, they shall 
  5461. be defined in terms of the formal architectural design, and 
  5462. the impact of the configurations on security shall be 
  5463. explained.  The procedures for delivery and system 
  5464. generation shall be explained.  A procedure approved by the 
  5465. national certification body for this evaluation level shall 
  5466. be followed, which guarantees the authenticity of the 
  5467. delivered TOE.  While generating the TOE, any generation 
  5468. options and/or changes shall be audited in such a way that 
  5469. it is subsequently possible to reconstruct exactly how and 
  5470. when the TOE was generated.
  5471.  
  5472. Requirements for Evidence
  5473.  
  5474. E6.33     The information supplied shall explain how the 
  5475. procedures maintain security.
  5476.  
  5477. Evaluator Actions
  5478.  
  5479. E6.34     Check that the information provided meets all 
  5480. requirements for content and presentation and evidence.  
  5481. Check the correct application of the delivery procedures.  
  5482. Search for errors in the system generation procedures.
  5483.  
  5484.  
  5485. Aspect 2 - Start-up and Operation
  5486.  
  5487. Requirements for Procedures and Standards
  5488.  
  5489. E6.35     The procedures for secure start-up and operation shall 
  5490. be explained.  If any security enforcing functions can be 
  5491. deactivated or modified during start-up, normal operation 
  5492. or maintenance, this shall be explained.  Procedures shall 
  5493. exist which can restore the TOE to a secure state after a 
  5494. failure, or a hardware or software error.  If the TOE 
  5495. contains hardware which contains security enforcing 
  5496. hardware components, then administrator, end-user, or self 
  5497. initiated diagnostic tests shall exist that can be 
  5498. performed on the TOE in its operational environment.
  5499.  
  5500. Requirements for Evidence
  5501.  
  5502. E6.36     The information supplied shall explain how the 
  5503. procedures maintain security.  The sponsor shall provide 
  5504. example results from all diagnostic test procedures for 
  5505. security enforcing hardware components.  The sponsor shall 
  5506. provide examples of any audit trail output created during 
  5507. start-up and operation.
  5508.  
  5509. Evaluator Actions
  5510.  
  5511. E6.37     Check that the information provided meets all 
  5512. requirements for content and presentation and evidence.  
  5513. Check the example evidence required for start-up and 
  5514. operation.  Search for errors in the procedures.
  5515.  
  5516.  
  5517.  
  5518.  
  5519.  
  5520.  
  5521.  
  5522.  
  5523.  
  5524.  
  5525.  
  5526.  
  5527.  
  5528.  
  5529.  
  5530.  
  5531.  
  5532.  
  5533.  
  5534.  
  5535.  
  5536.  
  5537. This page left blank
  5538.  
  5539. 5    RESULTS OF EVALUATION
  5540.  
  5541.  
  5542. Introduction
  5543.  
  5544. 5.1  Evaluation of a TOE in accordance with the correctness and 
  5545. effectiveness criteria set out in this document provides a 
  5546. measure of the assurance that the TOE will meet its 
  5547. security target.  This is indicated by the evaluation level 
  5548. achieved and a rating for the minimum strength of the 
  5549. security mechanisms of the TOE.
  5550.  
  5551.  
  5552. Rating
  5553.  
  5554. 5.2  The rating awarded to a TOE as the results of evaluation 
  5555. shall consist of the following:
  5556.  
  5557.      -    a reference to the security target for the TOE used as 
  5558. the baseline for evaluation;
  5559.  
  5560.      -    the evaluation level achieved by assessment of 
  5561. correctness and consideration of effectiveness;
  5562.  
  5563.      -    the confirmed rating of the minimum strength of the 
  5564. security mechanisms of the TOE.
  5565.  
  5566. 5.3  The security target shall be specified in a manner that is 
  5567. suitable for evaluation by an independent body and which is 
  5568. in accordance with the criteria for the stated evaluation 
  5569. level and type of TOE.
  5570.  
  5571. 5.4  The evaluation level awarded shall only be E0, E1, E2, E3, 
  5572. E4, E5 or E6.
  5573.  
  5574. 5.5  The confirmed rating of minimum strength shall only be 
  5575. awarded if the TOE has been successfully evaluated, ie. it 
  5576. is not awarded E0.  The rating awarded shall only be basic, 
  5577. medium or high.
  5578.  
  5579. 5.6  A TOE that satisfies all the correctness criteria for its 
  5580. targeted evaluation level and passes all aspects of 
  5581. consideration of effectiveness at that level, including the 
  5582. claimed minimum strength of mechanisms, shall be awarded 
  5583. the rating of that evaluation level and minimum strength of 
  5584. mechanisms.
  5585.  
  5586. 5.7  A TOE that is found to contain an exploitable vulnerability 
  5587. that has not been eliminated during the course of 
  5588. evaluation shall be withdrawn from evaluation or awarded 
  5589. E0.
  5590. 5.8  A TOE that fails to provide satisfactory evidence to 
  5591. satisfy the criteria for its targeted evaluation level but 
  5592. where no exploitable vulnerability has been found may be 
  5593. awarded a lower evaluation level where the evidence in 
  5594. question is not required to satisfy the criteria for that 
  5595. level.  If there is insufficient time or resources to 
  5596. consider the TOE against that lower level, or if unanswered 
  5597. questions exist, it shall either be withdrawn from 
  5598. evaluation or awarded E0.
  5599.  
  5600. 5.9  A TOE will only fail evaluation on grounds of effectiveness 
  5601. if an exploitable vulnerability is found and not 
  5602. eliminated.  In this case it must be withdrawn from 
  5603. evaluation or awarded E0.
  5604.  
  5605. 5.10 A TOE assigned a rating of E0 will have no rating for the 
  5606. minimum strength of mechanisms since it has been 
  5607. demonstrated that there is inadequate assurance in the TOE.
  5608.  
  5609. 5.11 The report produced by the evaluator containing and 
  5610. supporting the evaluation results shall be presented in a 
  5611. form acceptable for consideration by the appropriate 
  5612. national certification body.
  5613.  
  5614.  
  5615. 6    GLOSSARY AND REFERENCES
  5616.  
  5617.  
  5618. Introduction
  5619.  
  5620. 6.1  This chapter contains definitions of technical terms that 
  5621. are used with a meaning specific to this document.  
  5622. Technical terms used within this document that are not 
  5623. defined here are used throughout the document in a manner 
  5624. consistent with their generally accepted meaning.
  5625.  
  5626.  
  5627. Definitions
  5628.  
  5629. 6.2  Acceptance Procedure:  a procedure which takes objects 
  5630. produced during the development, production and maintenance 
  5631. processes for a Target of Evaluation and, as a positive 
  5632. act, places them under the controls of a Configuration 
  5633. Control system.
  5634.  
  5635. 6.3  Accreditation:  has two definitions according to 
  5636. circumstances:
  5637.  
  5638. a)   the procedure for accepting an IT system for use 
  5639. within a particular environment;
  5640.  
  5641. b)   the procedure for recognising both the technical 
  5642. competence and the impartiality of a test laboratory 
  5643. to carry out its associated tasks.
  5644.  
  5645. 6.4  Administration Documentation:  the information about a 
  5646. Target of Evaluation supplied by the developer for use by 
  5647. an administrator.
  5648.  
  5649. 6.5  Administrator:  a person in contact with the Target of 
  5650. Evaluation who is responsible for maintaining its 
  5651. operational capability.
  5652.  
  5653. 6.6  Architectural Design:  a phase of the Development Process 
  5654. wherein the top level definition and design of a Target of 
  5655. Evaluation is specified.
  5656.  
  5657. 6.7  Assurance:  the confidence that may be held in the security 
  5658. provided by a Target of Evaluation.
  5659.  
  5660. 6.8  Assurance Profile:  an assurance requirement for a TOE 
  5661. whereby different levels of confidence are required in 
  5662. different security enforcing functions.
  5663.  
  5664. 6.9  Availability:  the prevention of the unauthorised 
  5665. withholding of information or resources.
  5666. 6.10 Basic Component:  a component that is identifiable at the 
  5667. lowest hierarchical level of specification produced during 
  5668. Detailed Design.
  5669.  
  5670. 6.11 Binding of Functionality:  an aspect of the assessment of 
  5671. the effectiveness of a Target of Evaluation, namely the 
  5672. ability of its security enforcing functions and mechanisms 
  5673. to work together in a way which is mutually supportive and 
  5674. provides an integrated and effective whole.
  5675.  
  5676. 6.12 Certification:  the issue of a formal statement confirming 
  5677. the results of an evaluation, and that the evaluation 
  5678. criteria used were correctly applied.
  5679.  
  5680. 6.13 Certification Body:  an independent and impartial national 
  5681. organisation that performs certification.
  5682.  
  5683. 6.14 Component:  an identifiable and self-contained portion of a 
  5684. Target of Evaluation.
  5685.  
  5686. 6.15 Confidentiality:  the prevention of the unauthorised 
  5687. disclosure of information.
  5688.  
  5689. 6.16 Configuration:  the selection of one of the sets of 
  5690. possible combinations of features of a Target of 
  5691. Evaluation.
  5692.  
  5693. 6.17 Configuration Control:  a system of controls imposed on 
  5694. changing controlled objects produced during the 
  5695. development, production and maintenance processes for a 
  5696. Target of Evaluation.
  5697.  
  5698. 6.18 Construction:  the process of creating a Target of 
  5699. Evaluation.
  5700.  
  5701. 6.19 Corporate Security Policy:  the set of laws, rules and 
  5702. practices that regulate how assets including sensitive 
  5703. information are managed, protected and distributed within a 
  5704. user organisation.
  5705.  
  5706. 6.20 Correctness:  a property of a representation of a Target of 
  5707. Evaluation such that it accurately reflects the stated 
  5708. security target for that system or product.
  5709.  
  5710. 6.21 Covert Channel:  the use of a mechanism not intended for 
  5711. communication to transfer information in a way which 
  5712. violates security.
  5713.  
  5714. 6.22 Critical Mechanism:  a mechanism within a Target of 
  5715. Evaluation whose failure would create a security weakness.
  5716.  
  5717. 6.23 Customer:  the person or organisation that purchases a 
  5718. Target of Evaluation.
  5719.  
  5720. 6.24 Delivery:  the process whereby a copy of the Target of 
  5721. Evaluation is transferred from the developer to a customer.
  5722.  
  5723. 6.25 Detailed Design:  a phase of the Development Process 
  5724. wherein the top level definition and design of a Target of 
  5725. Evaluation is refined and expanded to a level of detail 
  5726. that can be used as a basis for implementation.
  5727.  
  5728. 6.26 Developer:  the person or organisation that manufactures a 
  5729. Target of Evaluation.
  5730.  
  5731. 6.27 Developer Security:  the physical, procedural and personnel 
  5732. security controls imposed by a developer on his Development 
  5733. Environment.
  5734.  
  5735. 6.28 Development Environment:  the organisational measures, 
  5736. procedures and standards used whilst constructing a Target 
  5737. of Evaluation.
  5738.  
  5739. 6.29 Development Process:  The set of phases and tasks whereby a 
  5740. Target of Evaluation is constructed, translating 
  5741. requirements into actual hardware and software.
  5742.  
  5743. 6.30 Documentation:  the written (or otherwise recorded) 
  5744. information about a Target of Evaluation required for an 
  5745. evaluation.  This information may, but need not, be 
  5746. contained within a single document produced for the 
  5747. specified purpose.
  5748.  
  5749. 6.31 Ease of Use:  an aspect of the assessment of the 
  5750. effectiveness of a Target of Evaluation, namely that it 
  5751. cannot be configured or used in a manner which is insecure 
  5752. but which an administrator or end-user would reasonably 
  5753. believe to be secure.
  5754.  
  5755. 6.32 Effectiveness:  a property of a Target of Evaluation 
  5756. representing how well it provides security in the context 
  5757. of its actual or proposed operational use.
  5758.  
  5759. 6.33 End-user:  a person in contact with a Target of Evaluation 
  5760. who makes use only of its operational capability.
  5761.  
  5762. 6.34 Evaluation:  the assessment of an IT system or product 
  5763. against defined evaluation criteria.
  5764.  
  5765. 6.35 Evaluator:  the independent person or organisation that 
  5766. performs an evaluation.
  5767.  
  5768. 6.36 Evaluator Actions:  a component of the evaluation criteria 
  5769. for a particular phase or aspect of evaluation, identifying 
  5770. what the evaluator must do to check the information 
  5771. supplied by the sponsor of the evaluator, and the 
  5772. additional activities he must perform.
  5773.  
  5774. 6.37 Formal Model of Security Policy:  an underlying model of 
  5775. security policy expressed in a formal style, i.e. an 
  5776. abstract statement of the important principles of security 
  5777. that a TOE will enforce.
  5778.  
  5779. 6.38 Functional Unit:  a functionally distinct part of a basic 
  5780. component.
  5781.  
  5782. 6.39 Functionality Class:  a predefined set of complementary 
  5783. security enforcing functions capable of being implemented 
  5784. in a Target of Evaluation.
  5785.  
  5786. 6.40 Implementation:  a phase of the Development Process wherein 
  5787. the detailed specification of a Target of Evaluation is 
  5788. translated into actual hardware and software.
  5789.  
  5790. 6.41 Integrity:  the prevention of the unauthorised modification 
  5791. of information.
  5792.  
  5793. 6.42 Object:  a passive entity that contains or receives 
  5794. information.
  5795.  
  5796. 6.43 Operating Procedure:  a set of rules defining correct use 
  5797. of a Target of Evaluation.
  5798.  
  5799. 6.44 Operation:  the process of using a Target of Evaluation.
  5800.  
  5801. 6.45 Operational Documentation:  the information produced by the 
  5802. developer of a Target of Evaluation to specify and explain 
  5803. how customers should use it.
  5804.  
  5805. 6.46 Operational Environment:  the organisational measures, 
  5806. procedures and standards to be used whilst operating a 
  5807. Target of Evaluation.
  5808.  
  5809. 6.47 Penetration Testing:  tests performed by an evaluator on 
  5810. the Target of Evaluation in order to confirm whether or not 
  5811. known vulnerabilities are actually exploitable in practice.
  5812.  
  5813. 6.48 Product:  a package of IT software and/or hardware, 
  5814. providing functionality designed for use or incorporation 
  5815. within a multiplicity of systems.
  5816.  
  5817. 6.49 Product Rationale:  a description of the security 
  5818. capabilities of a product, giving the necessary information 
  5819. for a prospective purchaser to decide whether it will help 
  5820. to satisfy his system security objectives.
  5821.  
  5822. 6.50 Production:  the process whereby copies of the Target of 
  5823. Evaluation are generated for distribution to customers.
  5824.  
  5825. 6.51 Programming Languages and Compilers:  the tools used within 
  5826. the Development Environment in the construction of the 
  5827. software and/or firmware of a Target of Evaluation.
  5828.  
  5829. 6.52 Rating:  a measure for the assurance that may be held in a 
  5830. Target of Evaluation, consisting of a reference to its 
  5831. security target, an evaluation level established by 
  5832. assessment of the correctness of its implementation and 
  5833. consideration of its effectiveness in the context of actual 
  5834. or proposed operational use, and a confirmed rating of the 
  5835. minimum strength of its security mechanisms.
  5836.  
  5837. 6.53 Requirements:  a phase of the Development Process wherein 
  5838. the security target of a Target of Evaluation is produced.
  5839.  
  5840. 6.54 Requirements for Content and Presentation:  a component of 
  5841. the evaluation criteria for a particular phase or aspect of 
  5842. evaluation identifying what each item of documentation 
  5843. identified as relevant to that phase or aspect of 
  5844. evaluation shall contain and how its information is to be 
  5845. presented.
  5846.  
  5847. 6.55 Requirements for Evidence:  a component of the evaluation 
  5848. criteria for a particular phase or aspect of evaluation 
  5849. defining the nature of the evidence to show that the 
  5850. criteria for that phase or aspect have been satisfied.
  5851.  
  5852. 6.56 Requirements for Procedures and Standards:  a component of 
  5853. the evaluation criteria for a particular phase or aspect of 
  5854. evaluation identifying the nature and/or content of 
  5855. procedures or standard approaches that shall be adopted or 
  5856. utilised when the TOE is placed into live operation.
  5857.  
  5858. 6.57 Security:  the combination of confidentiality, integrity 
  5859. and availability.
  5860.  
  5861. 6.58 Security Enforcing:  that which directly contributes to 
  5862. satisfying the security objectives of the Target of 
  5863. Evaluation.
  5864.  
  5865. 6.59 Security Mechanism:  the logic or algorithm that implements 
  5866. a particular security enforcing or security relevant 
  5867. function in hardware and software.
  5868.  
  5869. 6.60 Security Objectives:  the contribution to security which a 
  5870. Target of Evaluation is intended to achieve.
  5871.  
  5872. 6.61 Security Policy:  see Corporate Security Policy, System 
  5873. Security Policy, Technical Security Policy.
  5874.  
  5875. 6.62 Security Relevant:  that which is not security enforcing, 
  5876. but must function correctly for the Target of Evaluation to 
  5877. enforce security.
  5878. 6.63 Security Target:  a specification of the security required 
  5879. of a Target of Evaluation, used as a baseline for 
  5880. evaluation.  The security target will specify the security 
  5881. enforcing functions of the Target of Evaluation.  It will 
  5882. also specify the security objectives, the threats to those 
  5883. objectives, and any specific security mechanisms that will 
  5884. be employed.
  5885.  
  5886. 6.64 Sponsor:  the person or organisation that requests an 
  5887. evaluation.
  5888.  
  5889. 6.65 Storage Object:  an object that supports both read and 
  5890. write accesses [TCSEC].
  5891.  
  5892. 6.66 Strength of Mechanisms:  an aspect of the assessment of the 
  5893. effectiveness of a Target of Evaluation, namely the ability 
  5894. of its security mechanisms to withstand direct attack 
  5895. against deficiencies in their underlying algorithms, 
  5896. principles and properties.
  5897.  
  5898. 6.67 Subject:  an active entity, generally in the form of a 
  5899. person, process, or device [TCSEC].
  5900.  
  5901. 6.68 Suitability of Functionality:  an aspect of the assessment 
  5902. of the effectiveness of a Target of Evaluation, namely the 
  5903. suitability of its security enforcing functions and 
  5904. mechanisms to in fact counter the threats to the security 
  5905. of the Target of Evaluation identified in its security 
  5906. target.
  5907.  
  5908. 6.69 System:  a specific IT installation, with a particular 
  5909. purpose and operational environment.
  5910.  
  5911. 6.70 System Security Policy:  the set of laws, rules and 
  5912. practices that regulate how sensitive information and other 
  5913. resources are managed, protected and distributed within a 
  5914. specific system.
  5915.  
  5916. 6.71 Target of Evaluation:  an IT system or product which is 
  5917. subjected to security evaluation.
  5918.  
  5919. 6.72 Technical Security Policy:  the set of laws, rules and 
  5920. practices regulating the processing of sensitive 
  5921. information and the use of resources by the hardware and 
  5922. software of an IT system or product.
  5923.  
  5924. 6.73 Threat:  an action or event that might prejudice security.
  5925.  
  5926. 6.74 Tool:  a product used in the construction and/or 
  5927. documentation of a Target of Evaluation.
  5928.  
  5929. 6.75 User Documentation:  the information about a Target of 
  5930. Evaluation supplied by the developer for use by its end-
  5931. users.
  5932.  
  5933. 6.76 Vulnerability:  a security weakness in a Target Of 
  5934. Evaluation (for example, due to failures in analysis, 
  5935. design, implementation or operation).
  5936.  
  5937. 6.77 Vulnerability Assessment:  an aspect of the assessment of 
  5938. the effectiveness of a Target of Evaluation, namely whether 
  5939. known vulnerabilities in that Target of Evaluation could in 
  5940. practice compromise its security as specified in the 
  5941. security target.
  5942.  
  5943.  
  5944. References
  5945.  
  5946. 6.78 The following books and papers are referenced in the text:
  5947.  
  5948. AND       Computer Security Technology Planning Study
  5949.           J. P. Anderson
  5950.           ESD-TR-73-51, ESD/AFSC, US Air Force, Bedford, Mass., 
  5951. October 1972.
  5952.  
  5953. BLP       Secure Computer Systems:  Unified Exposition and 
  5954. Multics Interpretation
  5955.           D.E. Bell and L.J. LaPadula
  5956.           Report MTR-2997 Rev. 1, MITRE Corporation, Bedford, 
  5957. Mass, 1976.
  5958.  
  5959. BNM       The Chinese Wall Security Policy
  5960.           D.F.C. Brewer and M.J. Nash
  5961.           Proceedings of the IEEE Symposium on Security and 
  5962. Privacy, Oakland, May 1989, pp. 206-214.
  5963.  
  5964. CESG3     UK Systems Security Confidence Levels, CESG Memorandum 
  5965. No. 3,
  5966.           Communications-Electronics Security Group, United 
  5967. Kingdom, January 1989.
  5968.  
  5969. CWM       A Comparison of Commercial and Military Computer 
  5970. Security Policies
  5971.           D. D. Clark and  D. R. Wilson
  5972.           Proceedings of the IEEE Symposium on Security and 
  5973. Privacy, Oakland, April 1987, pp. 184-194.
  5974.  
  5975. DTIEC     DTI Commercial Computer Security Centre Evaluation 
  5976. Levels Manual, V22
  5977.           Department of Trade and Industry, United Kingdom, 
  5978. February 1989.
  5979.  
  5980. DTIFN     DTI Commercial Computer Security Centre Security 
  5981. Functionality Manual, V21
  5982.           Department of Trade and Industry, United Kingdom, 
  5983. February 1989.
  5984. EZBM Mandatory Policy: Secure Systems Model
  5985.           G. Eizenberg
  5986.           ONERA/CERT/DERI, Toulouse, France, undated.
  5987.  
  5988. GYPSY     Report on Gypsy 2.05
  5989.           D.I. Good, R.L. Akers and L.M. Smith
  5990.           Report ICSCA-CMP-48, University of Texas at Austin, 
  5991. February 1986.
  5992.  
  5993. IJRM      The Ina Jo Specification Language Reference Manual
  5994.           Unisys Corporation
  5995.           Culver City, California, United States of America, 
  5996. 1989.
  5997.  
  5998. JSD       System Development
  5999.           M.A. Jackson
  6000.           Prentice-Hall International, 1983.
  6001.  
  6002. JSP       Principles of Program Design
  6003.           M.A. Jackson
  6004.           Academic Press, New York, 1975
  6005.  
  6006. LOTOS     Information Processing Systems - Open Systems 
  6007. Interconnection - LOTOS - A Formal Description 
  6008. Technique Based on the Temporal Ordering of 
  6009. Observational Behaviour
  6010.           International Standard ISO 8807
  6011.           International Organization for Standardization, 1989.
  6012.  
  6013. LWM       A Security Model for Military Message Systems
  6014.           C.E. Landwehr, C.L. Heitmeyer and J. McLean
  6015.           ACM Transactions on Computer Systems, Vol. 2 No. 3, 
  6016. August 1984, pp. 198-222.
  6017.  
  6018. OSI       Information Processing Systems - Open Systems 
  6019. Interconnection - Basic Reference Model - Part 2:  
  6020. Security Architecture
  6021.           International Standard ISO 7498-2
  6022.           International Organization for Standardization, 1988.
  6023.  
  6024. RSL       RAISE Specification Language Reference Manual,
  6025.           RAISE/CRI/DOC/2/V1
  6026.           Computer Resources International A/S
  6027.           Birkerod, Denmark, 1990.
  6028.  
  6029.  
  6030.  
  6031. SADT      An Introduction to SADT
  6032.           Structured Analysis and Design Technique
  6033.           Report 9022-78R
  6034.           SofTech Inc, 460 Totten Pond Road
  6035.           Waltham, MA 02154, USA, November 1976.
  6036.  
  6037. SCSSI          Catalogue de Critères Destinés à évaluer le Degré 
  6038. de Confiance des Systèmes d'Information, 
  6039. 692/SGDN/DISSI/SCSSI
  6040.           Service Central de la Sécurité des Systèmes 
  6041. d'Information, Juillet 1989.
  6042.  
  6043. SSADM     The SSADM Manual, ISBN 085-012-527-X
  6044.           National Computing Centre Limited
  6045.           Manchester, United Kingdom, 1989.
  6046.  
  6047. SSVDM     Systematic Software Development Using VDM
  6048.           C.B. Jones
  6049.           Prentice Hall International, 1990.
  6050.  
  6051. TCSEC     Trusted Computer Systems Evaluation Criteria, DOD 
  6052. 5200.28-STD,
  6053.           Department of Defense, United States of America, 
  6054. December 1985.
  6055.  
  6056. YSM       A Note on the Yourdon Structured Method
  6057.           A.J. Bowles
  6058.           Yourdon Inc
  6059.           ACM SIGSOFT Software Engineering Notes
  6060.           Vol. 15 No. 2 April 1990, p. 27.
  6061.  
  6062. ZRM       The Z Notation:  A Reference Manual, ISBN-0-13-983768-
  6063. X
  6064.           J.M. Spivey
  6065.           Prentice Hall International, 1988.
  6066.  
  6067. ZSIEC     Criteria for the Evaluation of Trustworthiness of 
  6068. Information Technology (IT) Systems, ISBN 3-88784-200-
  6069. 6
  6070.           German Information Security Agency (Bundesamt für 
  6071. Sicherheit in der Informationstechnik), Federal 
  6072. Republic of Germany, January 1989.
  6073.  
  6074.  
  6075.  
  6076.  
  6077.  
  6078.  
  6079.  
  6080.  
  6081.  
  6082.  
  6083.  
  6084.  
  6085.  
  6086.  
  6087.  
  6088.  
  6089.  
  6090.  
  6091.  
  6092.  
  6093.  
  6094.  
  6095.  
  6096. This page left blank
  6097.  
  6098. Annex A - EXAMPLE FUNCTIONALITY CLASSES
  6099.  
  6100.  
  6101. Introduction
  6102.  
  6103. A.1  This annex sets out example predefined functionality 
  6104. classes, as defined in Chapter 2.  These classes form an 
  6105. annex to the criteria since they are intended as examples, 
  6106. not definitive classes to be used in real evaluations.  It 
  6107. is hoped that they will stimulate debate on actual security 
  6108. functionality requirements.  Indeed, the need to create 
  6109. definitive predefined functionality classes attracted 
  6110. widespread agreement during the consultative process 
  6111. preceding the publication of this version of the criteria.
  6112.  
  6113. A.2  Work is already underway in standardisation bodies and 
  6114. other industry organisations to develop standards for 
  6115. security functionality in specific contexts.  It is 
  6116. anticipated that such work will produce authoritative 
  6117. definitions of security functionality that can be adapted 
  6118. for use with these criteria and included in or referenced 
  6119. by the next definitive version of this document.
  6120.  
  6121. A.3  The present examples provide a basic point of reference and 
  6122. show how predefined functionality classes can be evolved 
  6123. from existing criteria:  indeed, these classes have been 
  6124. adapted with minimal alteration from [ZSIEC].
  6125.  
  6126. A.4  Each class consists of a statement of objectives, followed 
  6127. by the requirements presented under appropriate generic 
  6128. headings.  Absence of a generic heading within the 
  6129. description of a class means that no requirements exist for 
  6130. that heading.  The classes F-B2 and F-B3 also contain other 
  6131. information necessary for inclusion as part of a security 
  6132. target;  this specifies the mandatory mechanisms required 
  6133. for compatibility with the TCSEC.
  6134.  
  6135. A.5  The five example functionality classes F-C1, F-C2, F-B1, F-
  6136. B2, and F-B3 form a hierarchy, since they have been derived 
  6137. from the functionality requirements of the hierarchical 
  6138. TCSEC classes.  In the description of these classes, those 
  6139. parts of each class which are new or have changed from the 
  6140. preceding class are printed in bold.
  6141.  
  6142. A.6  Other hierarchy-based functionality classes may be created 
  6143. in the future, by standardisation bodies and industry 
  6144. organisations, to address other types of security 
  6145. objectives (e.g. for integrity and availability).  In the 
  6146. interim, the example classes F-IN, F-AV, F-DI, F-DC, and F-
  6147. DX have been included to illustrate the broad range of 
  6148. security requirements that can be expressed in the form of 
  6149. a predefined functionality class.
  6150.  
  6151.  
  6152. Example Functionality Class F-C1
  6153.  
  6154.  
  6155. Objective
  6156.  
  6157. A.7  Example class F-C1 is derived from the functionality 
  6158. requirements of the US TCSEC class C1.  It provides 
  6159. discretionary (need-to-know) access control.
  6160.  
  6161.  
  6162. Identification and Authentication
  6163.  
  6164. A.8  The TOE shall identify and authenticate users.  This 
  6165. identification and authentication shall take place prior to 
  6166. all other interactions between the TOE and the user.  Other 
  6167. interactions shall only be possible after successful 
  6168. identification and authentication.  The authentication 
  6169. information shall be stored in such a way that it can only 
  6170. be accessed by authorised users.
  6171.  
  6172.  
  6173. Access Control
  6174.  
  6175. A.9  The TOE shall be able to distinguish and administer access 
  6176. rights between each user and the objects which are subject 
  6177. to the administration of rights, on the basis of an 
  6178. individual user, or on the basis of membership of a group 
  6179. of users, or both.  It shall be possible to completely deny 
  6180. users or user groups access to an object.  It shall not be 
  6181. possible for anyone who is not an authorised user to grant 
  6182. or revoke access rights to an object.
  6183.  
  6184. A.10 With each attempt by users or user groups to access objects 
  6185. which are subject to the administration of rights, the TOE 
  6186. shall verify the validity of the request.  Unauthorised 
  6187. access attempts shall be rejected. 
  6188.  
  6189.  
  6190.  
  6191.  
  6192. Example Functionality Class F-C2
  6193.  
  6194.  
  6195. Objective
  6196.  
  6197. A.11 Example class F-C2 is derived from the functionality 
  6198. requirements of the US TCSEC class C2.  It provides a more 
  6199. finely grained discretionary access control than class C1, 
  6200. making users individually accountable for their actions 
  6201. through identification procedures, auditing of security 
  6202. relevant events, and resource isolation.
  6203.  
  6204.  
  6205. Identification and Authentication
  6206.  
  6207. A.12 The TOE shall uniquely identify and authenticate users.  
  6208. This identification and authentication shall take place 
  6209. prior to all other interactions between the TOE and the 
  6210. user.  Other interactions shall only be possible after 
  6211. successful identification and authentication.  The 
  6212. authentication information shall be stored in such a way 
  6213. that it can only be accessed by authorised users.  For 
  6214. every interaction the TOE shall be able to establish the 
  6215. identity of the user.
  6216.  
  6217.  
  6218. Access Control
  6219.  
  6220. A.13 The TOE shall be able to distinguish and administer access 
  6221. rights between each user and the objects which are subject 
  6222. to the administration of rights, on the basis of an 
  6223. individual user, or on the basis of membership of a group 
  6224. of users, or both.  It shall be possible to completely deny 
  6225. users or user groups access to an object.  It shall also be 
  6226. possible to restrict a user's access to an object to those 
  6227. operations which do not modify it.  It shall be possible to 
  6228. grant the access rights to an object down to the 
  6229. granularity of an individual user.  It shall not be 
  6230. possible for anyone who is not an authorised user to grant 
  6231. or revoke access rights to an object.  The administration 
  6232. of rights shall provide controls to limit propagation of 
  6233. access rights.  In the same way, only authorised users 
  6234. shall be able to introduce new users or delete or suspend 
  6235. existing users.
  6236.  
  6237. A.14 With each attempt by users or user groups to access objects 
  6238. which are subject to the administration of rights, the TOE 
  6239. shall verify the validity of the request.  Unauthorised 
  6240. access attempts shall be rejected.
  6241.  
  6242.  
  6243.  
  6244.  
  6245. Accountability
  6246.  
  6247. A.15 The TOE shall contain an accountability component which is 
  6248. able, for each of the following events, to log that event 
  6249. together with the required data:
  6250.  
  6251.      a)   Use of the identification and authentication 
  6252. mechanism:
  6253.  
  6254. Required data:  Date;  time;  user identity supplied;  
  6255. identification of the equipment on which the 
  6256. identification and authentication mechanism was used 
  6257. (e.g. terminal-id);  success or failure of the 
  6258. attempt.
  6259.  
  6260. b)   Actions that attempt to exercise access rights to an 
  6261. object which is subject to the administration of 
  6262. rights:
  6263.  
  6264. Required data:  Date;  time;  user identity;  name of 
  6265. the object;  type of access attempt;  success or 
  6266. failure of the attempt.
  6267.  
  6268. c)   Creation or deletion of an object which is subject to 
  6269. the administration of rights:
  6270.  
  6271. Required data:  Date;  time;  user identity;  name of 
  6272. the object;  type of action.
  6273.  
  6274.      d)   Actions by authorised users affecting the security of 
  6275. the TOE:
  6276.  
  6277. Required data:  Date;  time;  user identity;  type of 
  6278. action;  name of the object to which the action 
  6279. relates (such actions are introduction or deletion 
  6280. (suspension) of users;  introduction or removal of 
  6281. storage media;  start up or shut down of the TOE).
  6282.  
  6283. A.16 Unauthorised users shall not be permitted to access 
  6284. accountability data.  It shall be possible to selectively 
  6285. account for the actions of one or more users.  Tools to 
  6286. examine and to maintain the accountability files shall 
  6287. exist and be documented.  These tools shall allow the 
  6288. actions of one or  more users to be identified selectively.
  6289.  
  6290.  
  6291. Audit
  6292.  
  6293. A.17 Tools to examine the accountability files for the purpose 
  6294. of audit shall exist and be documented.  These tools shall 
  6295. allow the actions of one or  more users to be identified 
  6296. selectively. 
  6297.  
  6298.  
  6299. Object Reuse
  6300.  
  6301. A.18 All storage objects returned to the TOE shall be treated 
  6302. before reuse by other subjects, in such a way that no 
  6303. conclusions can be drawn regarding the preceding content.
  6304.  
  6305.  
  6306. Example Functionality Class F-B1
  6307.  
  6308.  
  6309. Objective
  6310.  
  6311. A.19 Example class F-B1 is derived from the functionality 
  6312. requirements of the US TCSEC class B1.  In addition to 
  6313. discretionary access control it introduces functions to 
  6314. maintain sensitivity labels and uses them to enforce a set 
  6315. of mandatory access control rules over all subjects and 
  6316. storage objects under its control.  It is possible to 
  6317. accurately label exported information.
  6318.  
  6319.  
  6320. Identification and Authentication
  6321.  
  6322. A.20 The TOE shall uniquely identify and authenticate users.  
  6323. This identification and authentication shall take place 
  6324. prior to all other interactions between the TOE and the 
  6325. user.  Other interactions shall only be possible after 
  6326. successful identification and authentication.  The 
  6327. authentication information shall be stored in such a way 
  6328. that it can only be accessed by authorised users.  For 
  6329. every interaction the TOE shall be able to establish the 
  6330. identity of the user.
  6331.  
  6332.  
  6333. Access Control
  6334.  
  6335. A.21 The TOE shall be able to distinguish and administer access 
  6336. rights between each user and the objects which are subject 
  6337. to the administration of rights, on the basis of an 
  6338. individual user, or on the basis of membership of a group 
  6339. of users, or both.  It shall be possible to completely deny 
  6340. users or user groups access to an object.  It shall also be 
  6341. possible to restrict a user's access to an object to those 
  6342. operations which do not modify it.  It shall be possible to 
  6343. grant the access rights to an object down to the 
  6344. granularity of an individual user.  It shall not be 
  6345. possible for anyone who is not an authorised user to grant 
  6346. or revoke access rights to an object.  The administration 
  6347. of rights shall provide controls to limit propagation of 
  6348. access rights.  The actions for adding and deleting user 
  6349. identities known to the TOE, and the action to temporarily 
  6350. suspend all of a user's access rights, shall be restricted 
  6351. to authorised users.
  6352.  
  6353. A.22 In addition the TOE shall provide all subjects and storage 
  6354. objects (e.g. processes, files, storage segments, devices) 
  6355. under its control with attributes.  The values of these 
  6356. attributes shall serve as a basis for mandatory access 
  6357. rights.  Rules shall specify which combinations of 
  6358. attribute values of subject and object are necessary for a 
  6359. subject to be granted access to that object.
  6360.  
  6361. A.23 When exporting an object its attributes shall be exported 
  6362. in such a way that the recipient can reconstruct their 
  6363. value unambiguously.
  6364.  
  6365. A.24 The mandatory access rights shall be designed in such a 
  6366. manner that the following special case can be realised:
  6367.  
  6368.      The attribute consists of two parts.  Part one has 
  6369. hierarchically ordered values, part two represents a set.  
  6370. (In the official world part one contains classifications 
  6371. e.g. unclassified, confidential, secret, top secret.  Part 
  6372. two contains categories.)
  6373.  
  6374.      An attribute A is said to dominate an attribute B if:
  6375.  
  6376.      Part one of A is hierarchically greater than, or equal to, 
  6377. part one of B and part two of B is a proper subset of, or 
  6378. equal to, part two of A.
  6379.  
  6380. A.25 The following rules shall be enforced:
  6381.  
  6382. a)   Read access by a subject to an object is only 
  6383. permitted if the attribute of the subject dominates 
  6384. that of the object.
  6385.  
  6386. b)   Write access by a subject to an object is only 
  6387. permitted if the attribute of the object dominates 
  6388. that of the subject.
  6389.  
  6390. A.26 The attributes of a subject created to act on behalf of a 
  6391. user shall be dominated by that user's clearance and 
  6392. authorisation as determined at identification and 
  6393. authentication time.  If imported data does not have 
  6394. attributes, an authorised user shall be able to assign 
  6395. attributes to the data.
  6396.  
  6397. A.27 Each export channel shall be identifiable as either single-
  6398. level or multi-level.  It shall be impossible to transmit 
  6399. or receive data via channels designated as single-level, 
  6400. unless the attributes of that data match a fixed 
  6401. prespecified attribute.  Data transmitted to or received 
  6402. from a single-level channel shall be communicated with a 
  6403. corresponding attribute, unless it is possible for an 
  6404. authorised user to specify the attribute of the channel in 
  6405. a way that cannot be imitated.  In this case, the attribute 
  6406. of the data is implicitly specified by the attribute of the 
  6407. channel.
  6408.  
  6409. A.28 For multi-level channels it shall be ensured by the 
  6410. communication protocol that the recipient can completely 
  6411. and unambiguously reconstruct and pair the received data 
  6412. and attributes.
  6413.  
  6414. A.29 Unauthorised users shall not be able to change the security 
  6415. relevant attributes of a channel.  It shall not be possible 
  6416. to change these attributes without the change being 
  6417. performed explicitly.
  6418. A.30 The TOE shall mark human readable output with attribute 
  6419. values.  The values of the attributes shall be determined 
  6420. according to the rules laid down in the TOE.  Authorised 
  6421. users shall be able to specify the printable name of each 
  6422. attribute value.
  6423.  
  6424. A.31 With each attempt by users or user groups to access objects 
  6425. which are subject to the administration of rights, the TOE 
  6426. shall verify the validity of the request.  Unauthorised 
  6427. access attempts shall be rejected.  The values of the 
  6428. attributes shall serve as the basis for decisions 
  6429. concerning mandatory access control.  The rules shall 
  6430. unambiguously specify when a subject is allowed access to 
  6431. such a protected object.  If discretionary access rights 
  6432. are also assigned for an object, access shall only be 
  6433. permitted provided that both the discretionary and the 
  6434. mandatory access rights allow such access.
  6435.  
  6436.  
  6437. Accountability
  6438.  
  6439. A.32 The TOE shall contain an accountability component which is 
  6440. able, for each of the following events, to log that event 
  6441. together with the required data:
  6442.  
  6443.      a)   Use of the identification and authentication 
  6444. mechanism:
  6445.  
  6446. Required data:  Date;  time;  user identity supplied;  
  6447. identification of the equipment on which the 
  6448. identification and authentication mechanism was used 
  6449. (e.g. terminal-id);  success or failure of the 
  6450. attempt;  authorisation of the user.
  6451.  
  6452. b)   Actions that attempt to exercise access rights to an 
  6453. object which is subject to the administration of 
  6454. rights:
  6455.  
  6456. Required data:  Date;  time;  user identity;  name of 
  6457. the object;  type of access attempt;  success or 
  6458. failure of the attempt;  attribute of the object.
  6459.  
  6460. c)   Creation or deletion of an object which is subject to 
  6461. the administration of rights:
  6462.  
  6463. Required data:  Date;  time;  user identity;  name of 
  6464. the object;  type of action;  attribute of the object.
  6465.  
  6466.      d)   Actions by authorised users affecting the security of 
  6467. the TOE:
  6468.  
  6469. Required data:  Date;  time;  user identity;  type of 
  6470. action;  name and attribute of the object to which the 
  6471. action relates (such actions are introduction or 
  6472. deletion (suspension) of users;  introduction or 
  6473. removal of storage media;  start up or shut down of 
  6474. the TOE;  assignation of an attribute;  change of 
  6475. attributes, markings or classification of a channel).
  6476.  
  6477. A.33 Unauthorised users shall not be permitted to access 
  6478. accountability data.  It shall be possible to selectively 
  6479. account for the actions of one or more users.  Tools to 
  6480. examine and to maintain the accountability files shall 
  6481. exist and be documented.  These tools shall allow the 
  6482. actions of one or  more users to be identified selectively.  
  6483.  
  6484.  
  6485. Audit
  6486.  
  6487. A.34 Tools to examine the accountability files for the purpose 
  6488. of audit shall exist and be documented.  These tools shall 
  6489. allow the actions of one or  more users to be identified 
  6490. selectively.  
  6491.  
  6492.  
  6493. Object Reuse
  6494.  
  6495. A.35 All storage objects returned to the TOE shall be treated 
  6496. before reuse by other subjects, in such a way that no 
  6497. conclusions can be drawn regarding the preceding content.
  6498.  
  6499.  
  6500.  
  6501.  
  6502. Example Functionality Class F-B2
  6503.  
  6504.  
  6505. Objective
  6506.  
  6507. A.36 Example class F-B2 is derived from the functionality 
  6508. requirements of the US TCSEC class B2.  It extends 
  6509. mandatory access control to all subjects and objects and 
  6510. strengthens the authentication requirements of class B1.  
  6511.  
  6512.  
  6513. Mandatory Mechanisms
  6514.  
  6515. A.37 This class requires access control to be implemented by a 
  6516. single reference validation mechanism that implements the 
  6517. reference monitor concept, i.e. that the mechanism is 
  6518. tamperproof, always invoked, and small enough (of 
  6519. sufficiently simple organisation and complexity) to be 
  6520. subjected to analysis and tests, the completeness of which 
  6521. can be assured.
  6522.  
  6523.  
  6524. Identification and Authentication
  6525.  
  6526. A.38 The TOE shall uniquely identify and authenticate users.  
  6527. This identification and authentication shall take place 
  6528. prior to all other interactions between the TOE and the 
  6529. user.  Other interactions shall only be possible after 
  6530. successful identification and authentication.  The 
  6531. authentication information shall be stored in such a way 
  6532. that it can only be accessed by authorised users.  
  6533. Identification and authentication shall be handled via a 
  6534. trusted path between user and TOE initialised by the user.  
  6535. For every interaction the TOE shall be able to establish 
  6536. the identity of the user.
  6537.  
  6538.  
  6539. Access Control
  6540.  
  6541. A.39 The TOE shall be able to distinguish and administer access 
  6542. rights between each user and the objects which are subject 
  6543. to the administration of rights, on the basis of an 
  6544. individual user, or on the basis of membership of a group 
  6545. of users, or both.  It shall be possible to group access 
  6546. rights to support roles.  As a minimum the roles of TOE 
  6547. operator and administrator shall be definable.  It shall be 
  6548. possible to completely deny users or user groups access to 
  6549. an object.  It shall also be possible to restrict a user's 
  6550. access to an object to those operations which do not modify 
  6551. it.  It shall be possible to grant the access rights to an 
  6552. object down to the granularity of an individual user.
  6553.  
  6554. A.40 It shall not be possible for anyone who is not an 
  6555. authorised user to grant or revoke access rights to an 
  6556. object.  The administration of rights shall provide 
  6557. controls to limit propagation of access rights.  The 
  6558. actions for adding and deleting user identities known to 
  6559. the TOE, and the action to temporarily suspend all of a 
  6560. user's access rights, shall be restricted to authorised 
  6561. users.
  6562.  
  6563. A.41 In addition the TOE shall provide all subjects and objects 
  6564. (e.g. processes, files, storage segments, devices) with 
  6565. attributes.  The values of these attributes shall serve as 
  6566. a basis for mandatory access rights.  Rules shall specify 
  6567. which combinations of attribute values of subject and 
  6568. object are necessary for a subject to be granted access to 
  6569. that object.
  6570.  
  6571. A.42 When exporting an object its attributes shall be exported 
  6572. in such a way that the recipient can reconstruct their 
  6573. value unambiguously.
  6574.  
  6575. A.43 The mandatory access rights shall be designed in such a 
  6576. manner that the following special case can be realised:
  6577.  
  6578.      The attribute consists of two parts.  Part one has 
  6579. hierarchically ordered values, part two represents a set.  
  6580. (In the official world part one contains classifications 
  6581. e.g. unclassified, confidential, secret, top secret.  Part 
  6582. two contains categories.)
  6583.  
  6584.      An attribute A is said to dominate an attribute B if:
  6585.  
  6586.      Part one of A is hierarchically greater than, or equal to, 
  6587. part one of B and part two of B is a proper subset of, or 
  6588. equal to, part two of A.
  6589.  
  6590. A.44 The following rules shall be enforced:
  6591.  
  6592. a)   Read access by a subject to an object is only 
  6593. permitted if the attribute of the subject dominates 
  6594. that of the object.
  6595.  
  6596. b)   Write access by a subject to an object is only 
  6597. permitted if the attribute of the object dominates 
  6598. that of the subject.
  6599.  
  6600. A.45 The attributes of a subject created to act on behalf of a 
  6601. user shall be dominated by that user's clearance and 
  6602. authorisation as determined at identification and 
  6603. authentication time.  If imported data does not have 
  6604. attributes, an authorised user shall be able to assign 
  6605. attributes to the data.
  6606.  
  6607. A.46 Each export channel shall be identifiable as either single-
  6608. level or multi-level.  It shall be impossible to transmit 
  6609. or receive data via channels designated as single-level, 
  6610. unless the attributes of that data match a fixed 
  6611. prespecified attribute.  Data transmitted to or received 
  6612. from a single-level channel shall be communicated with a 
  6613. corresponding attribute, unless it is possible for an 
  6614. authorised user to specify the attribute of the channel in 
  6615. a way that cannot be imitated.  In this case, the attribute 
  6616. of the data is implicitly specified by the attribute of the 
  6617. channel.
  6618.  
  6619. A.47 For multi-level channels it shall be ensured by the 
  6620. communication protocol that the recipient can completely 
  6621. and unambiguously reconstruct and pair the received data 
  6622. and attributes.  For multi-level channels it shall be 
  6623. possible to state the maximum and minimum attributes.  No 
  6624. data shall be transmitted to a multi-level channel unless 
  6625. the attribute of the data dominates the minimum attribute 
  6626. of the channel and is dominated by the maximum attribute of 
  6627. the channel.
  6628.  
  6629. A.48 Unauthorised users shall not be able to change the security 
  6630. relevant attributes of a channel.  It shall not be possible 
  6631. to change these attributes without the change being 
  6632. performed explicitly.
  6633.  
  6634. A.49 The TOE shall mark human readable output with attribute 
  6635. values.  The values of the attributes shall be determined 
  6636. according to the rules laid down in the TOE.  Authorised 
  6637. users shall be able to specify the printable name of each 
  6638. attribute value.
  6639.  
  6640. A.50 A user shall be notified immediately of any change in the 
  6641. security level associated with that user during an 
  6642. interactive session.  The user shall be able at all times 
  6643. to review all the subject's attributes.
  6644.  
  6645. A.51 With each attempt by users or user groups to access objects 
  6646. which are subject to the administration of rights, the TOE 
  6647. shall verify the validity of the request.  Unauthorised 
  6648. access attempts shall be rejected.  The values of the 
  6649. attributes shall serve as the basis for decisions 
  6650. concerning mandatory access control.  The rules shall 
  6651. unambiguously specify when a subject is allowed access to 
  6652. such a protected object.  If discretionary access rights 
  6653. are also assigned for an object, access shall only be 
  6654. permitted provided that both the discretionary and the 
  6655. mandatory access rights allow such access.
  6656.  
  6657. A.52 There shall be no known storage channels that can transfer 
  6658. information between processes without verification of 
  6659. access rights (i.e. covertly) that have a maximum bandwidth 
  6660. (determined by actual measurement or engineering 
  6661. estimation) that is unacceptably high.  (See the Covert 
  6662. Channel Guideline section of the TCSEC [TCSEC] for guidance 
  6663. on acceptability.)
  6664.  
  6665.  
  6666.  
  6667.  
  6668.  
  6669. Accountability
  6670.  
  6671. A.53 The TOE shall contain an accountability component which is 
  6672. able, for each of the following events, to log that event 
  6673. together with the required data:
  6674.  
  6675.      a)   Use of the identification and authentication 
  6676. mechanism:
  6677.  
  6678. Required data:  Date;  time;  user identity supplied;  
  6679. identification of the equipment on which the 
  6680. identification and authentication mechanism was used 
  6681. (e.g. terminal-id);  success or failure of the 
  6682. attempt;  authorisation of the user.
  6683.  
  6684. b)   Actions that attempt to exercise access rights to an 
  6685. object which is subject to the administration of 
  6686. rights:
  6687.  
  6688. Required data:  Date;  time;  user identity;  name of 
  6689. the object;  type of access attempt;  success or 
  6690. failure of the attempt;  attribute of the object.
  6691.  
  6692. c)   Creation or deletion of an object which is subject to 
  6693. the administration of rights:
  6694.  
  6695. Required data:  Date;  time;  user identity;  name of 
  6696. the object;  type of action;  attribute of the object.
  6697.  
  6698. d)   Actions by authorised users affecting the security of 
  6699. the TOE:
  6700.  
  6701. Required data:  Date;  time;  user identity;  type of 
  6702. action;  name and attribute of the object to which the 
  6703. action relates (such actions are introduction or 
  6704. deletion (suspension) of users;  introduction or 
  6705. removal of storage media;  start up or shut down of 
  6706. the TOE;  assignation of an attribute;  change of 
  6707. attributes, markings or classification of a channel).
  6708.  
  6709. A.54 Unauthorised users shall not be permitted to access 
  6710. accountability data.  It shall be possible to selectively 
  6711. account for the actions of one or more users.  Tools to 
  6712. examine and to maintain the accountability files shall 
  6713. exist and be documented.  These tools shall allow the 
  6714. actions of one or more users to be identified selectively.  
  6715.  
  6716.  
  6717. Audit
  6718.  
  6719. A.55 Tools to examine the accountability files for the purpose 
  6720. of audit shall exist and be documented.  These tools shall 
  6721. allow the actions of one or  more users to be identified 
  6722. selectively.  In addition the TOE shall be able to audit 
  6723. known events which could be misused to allow an 
  6724. unauthorised flow of information by exploiting covert 
  6725. channels.
  6726.  
  6727.  
  6728. Object Reuse
  6729.  
  6730. A.56 All storage objects returned to the TOE shall be treated 
  6731. before reuse by other subjects, in such a way that no 
  6732. conclusions can be drawn regarding the preceding content.
  6733.  
  6734.  
  6735.  
  6736.  
  6737. Example Functionality Class F-B3
  6738.  
  6739.  
  6740. Objective
  6741.  
  6742. A.57 Example class F-B3 is derived from the functionality 
  6743. requirements of the US TCSEC classes B3 and A1.  In 
  6744. addition to the functions of class B2, it provides 
  6745. functions to support distinct security administration 
  6746. roles, and audit is expanded to signal security relevant 
  6747. events.
  6748.  
  6749.  
  6750. Mandatory Mechanisms
  6751.  
  6752. A.58 This class requires access control to be implemented by a 
  6753. single reference validation mechanism that implements the 
  6754. reference monitor concept, i.e. that the mechanism is 
  6755. tamperproof, always invoked, and small enough (of 
  6756. sufficiently simple organisation and complexity) to be 
  6757. subjected to analysis and tests, the completeness of which 
  6758. can be assured.
  6759.  
  6760.  
  6761. Identification and Authentication
  6762.  
  6763. A.59 The TOE shall uniquely identify and authenticate users.  
  6764. This identification and authentication shall take place 
  6765. prior to all other interactions between the TOE and the 
  6766. user.  Other interactions shall only be possible after 
  6767. successful identification and authentication.  The 
  6768. authentication information shall be stored in such a way 
  6769. that it can only be accessed by authorised users.  
  6770. Identification and authentication shall be handled via a 
  6771. trusted path between user and TOE initialised by the user 
  6772. or by the TOE.  For every interaction the TOE shall be able 
  6773. to establish the identity of the user.
  6774.  
  6775.  
  6776. Access Control
  6777.  
  6778. A.60 The TOE shall be able to distinguish and administer access 
  6779. rights between each user and the objects which are subject 
  6780. to the administration of rights, on the basis of an 
  6781. individual user, or on the basis of membership of a group 
  6782. of users, or both.  It shall be possible to group access 
  6783. rights to support roles.  As a minimum the roles of TOE 
  6784. operator and administrator shall be definable.  The roles 
  6785. of the TOE operator, TOE administrator and TOE security 
  6786. officer shall be separated.  It shall be possible to 
  6787. completely deny users or user groups access to an object.  
  6788. It shall also be possible to restrict a user's access to an 
  6789. object to those operations which do not modify it.  It 
  6790. shall be possible to grant the access rights to an object 
  6791. down to the granularity of an individual user.  It shall 
  6792. not be possible for anyone who is not an authorised user to 
  6793. grant or revoke access rights to an object.
  6794.  
  6795. A.61 For each object which is subject to the administration of 
  6796. rights, it shall be possible to supply a list of users and 
  6797. a list of user groups with their associated rights to this 
  6798. object.  In addition, for each such object it shall also be 
  6799. possible to supply a list of users and a list of user 
  6800. groups who are denied access to this object.  The 
  6801. administration of rights shall provide controls to limit 
  6802. propagation of access rights.  The actions for adding and 
  6803. deleting user identities known to the TOE, and the action 
  6804. to temporarily suspend all of a user's access rights, shall 
  6805. be restricted to authorised users.
  6806.  
  6807. A.62 In addition the TOE shall provide all subjects and objects 
  6808. (e.g. processes, files, storage segments, devices) with 
  6809. attributes.  The values of these attributes shall serve as 
  6810. a basis for mandatory access rights.  Rules shall specify 
  6811. which combinations of attribute values of subject and 
  6812. object are necessary for a subject to be granted access to 
  6813. that object.
  6814.  
  6815. A.63 When exporting an object its attributes shall be exported 
  6816. in such a way that the recipient can reconstruct their 
  6817. value unambiguously.
  6818.  
  6819. A.64 The mandatory access rights shall be designed in such a 
  6820. manner that the following special case can be realised:
  6821.  
  6822.      The attribute consists of two parts.  Part one has 
  6823. hierarchically ordered values, part two represents a set.  
  6824. (In the official world part one contains classifications 
  6825. e.g. unclassified, confidential, secret, top secret.  Part 
  6826. two contains categories.)
  6827.  
  6828.      An attribute A is said to dominate an attribute B if:
  6829.  
  6830.      Part one of A is hierarchically greater than, or equal to, 
  6831. part one of B and part two of B is a proper subset of, or 
  6832. equal to, part two of A.
  6833.  
  6834. A.65 The following rules shall be enforced:
  6835.  
  6836. a)   Read access by a subject to an object is only 
  6837. permitted if the attribute of the subject dominates 
  6838. that of the object.
  6839.  
  6840. b)   Write access by a subject to an object is only 
  6841. permitted if the attribute of the object dominates 
  6842. that of the subject.
  6843.  
  6844. A.66 The attributes of a subject created to act on behalf of a 
  6845. user shall be dominated by that user's clearance and 
  6846. authorisation as determined at identification and 
  6847. authentication time.  If imported data does not have 
  6848. attributes, an authorised user shall be able to assign 
  6849. attributes to the data.
  6850.  
  6851. A.67 Each export channel shall be identifiable as either single-
  6852. level or multi-level.  It shall be impossible to transmit 
  6853. or receive data via channels designated as single-level, 
  6854. unless the attributes of that data match a fixed 
  6855. prespecified attribute. Data transmitted to or received 
  6856. from a single-level channel shall be communicated with a 
  6857. corresponding attribute, unless it is possible for an 
  6858. authorised user to specify the attribute of the channel in 
  6859. a way that cannot be imitated.  In this case, the attribute 
  6860. of the data is implicitly specified by the attribute of the 
  6861. channel.
  6862.  
  6863. A.68 For multi-level channels it shall be ensured by the 
  6864. communication protocol that the recipient can completely 
  6865. and unambiguously reconstruct and pair the received data 
  6866. and attributes.  For multi-level channels it shall be 
  6867. possible to state the maximum and minimum attributes.  No 
  6868. data shall be transmitted to a multi-level channel unless 
  6869. the attribute of the data dominates the minimum attribute 
  6870. of the channel and is dominated by the maximum attribute of 
  6871. the channel.
  6872.  
  6873. A.69 Unauthorised users shall not be able to change the security 
  6874. relevant attributes of a channel.  It shall not be possible 
  6875. to change these attributes without the change being 
  6876. performed explicitly.
  6877.  
  6878. A.70 The TOE shall mark human readable output with attribute 
  6879. values.  The values of the attributes shall be determined 
  6880. according to the rules laid down in the TOE.  Authorised 
  6881. users shall be able to specify the printable name of each 
  6882. attribute value.
  6883.  
  6884. A.71 A user shall be notified immediately of any change in the 
  6885. security level associated with that user during an 
  6886. interactive session.  The user shall be able at all times 
  6887. to review all the subject's attributes.
  6888.  
  6889. A.72 With each attempt by users or user groups to access objects 
  6890. which are subject to the administration of rights, the TOE 
  6891. shall verify the validity of the request.  Unauthorised 
  6892. access attempts shall be rejected.  The values of the 
  6893. attributes shall serve as the basis for decisions 
  6894. concerning mandatory access control.  The rules shall 
  6895. unambiguously specify when a subject is allowed access to 
  6896. such a protected object.  If discretionary access rights 
  6897. are also assigned for an object, access shall only be 
  6898. permitted provided that both the discretionary and the 
  6899. mandatory access rights allow such access.
  6900.  
  6901. A.73 There shall be no known storage or timing channels that can 
  6902. transfer information between processes without verification 
  6903. of access rights (i.e. covertly) that have a maximum 
  6904. bandwidth (determined by actual measurement or engineering 
  6905. estimation) that is unacceptably high.  (See the Covert 
  6906. Channel Guideline section of the TCSEC [TCSEC] for guidance 
  6907. on acceptability.)
  6908.  
  6909.  
  6910. Accountability
  6911.  
  6912. A.74 The TOE shall contain an accountability component which is 
  6913. able, for each of the following events, to log that event 
  6914. together with the required data:
  6915.  
  6916. a)   Use of the identification and authentication 
  6917. mechanism:
  6918.  
  6919. Required data:  Date;  time;  user identity supplied;  
  6920. identification of the equipment on which the 
  6921. identification and authentication mechanism was used 
  6922. (e.g. terminal-id);  success or failure of the 
  6923. attempt;  authorisation of the user.
  6924.  
  6925. b)   Actions that attempt to exercise access rights to an 
  6926. object which is subject to the administration of 
  6927. rights:
  6928.  
  6929. Required data:  Date;  time;  user identity;  name of 
  6930. the object;  type of access attempt;  success or 
  6931. failure of the attempt;  attribute of the object.
  6932.  
  6933. c)   Creation or deletion of an object which is subject to 
  6934. the administration of rights:
  6935.  
  6936. Required data:  Date;  time;  user identity;  name of 
  6937. the object;  type of action;  attribute of the object.
  6938.  
  6939. d)   Actions by authorised users affecting the security of 
  6940. the TOE:
  6941.  
  6942. Required data: Date;  time;  user identity;  type of 
  6943. action;  name and attribute of the object to which the 
  6944. action relates (such actions are introduction or 
  6945. deletion (suspension) of users;  introduction or 
  6946. removal of storage media;  start up or shut down of 
  6947. the TOE;  assignation of an attribute;  change of 
  6948. attributes, markings or classification of a channel).
  6949.  
  6950. A.75 Unauthorised users shall not be permitted to access 
  6951. accountability data.  It shall be possible to selectively 
  6952. account for the actions of one or more users.  Tools to 
  6953. examine and to maintain the accountability files shall 
  6954. exist and be documented.  These tools shall allow the 
  6955. actions of one or more users to be identified selectively.  
  6956.  
  6957.  
  6958.  
  6959. Audit
  6960.  
  6961. A.76 Tools to examine the accountability files for the purpose 
  6962. of audit shall exist and be documented.  These tools shall 
  6963. allow the actions of one or  more users to be identified 
  6964. selectively.  In addition the TOE shall be able to audit 
  6965. known events which could be misused to allow an 
  6966. unauthorised flow of information by exploiting covert 
  6967. channels.
  6968.  
  6969. A.77 Additionally, there shall be a mechanism to monitor the 
  6970. occurrence of events which are either particularly security 
  6971. relevant or which, due to the frequency of their 
  6972. occurrence, can become a critical threat to the security of 
  6973. the TOE.  This mechanism shall be able without delay to 
  6974. notify a special user, or a user with a special role, of 
  6975. the occurrence of such events.  The mechanism shall take 
  6976. the least disruptive action to terminate such events.
  6977.  
  6978.  
  6979. Object Reuse
  6980.  
  6981. A.78 All storage objects returned to the TOE shall be treated 
  6982. before reuse by other subjects, in such a way that no 
  6983. conclusions can be drawn regarding the preceding content.
  6984.  
  6985.  
  6986.  
  6987.  
  6988. Example Functionality Class F-IN
  6989.  
  6990.  
  6991. Objective
  6992.  
  6993. A.79 Example functionality class F-IN is for TOEs with high 
  6994. integrity requirements for data and programs.  Such 
  6995. requirements may be necessary in database TOEs, for 
  6996. example.
  6997.  
  6998.  
  6999. Identification and Authentication
  7000.  
  7001. A.80 The TOE shall uniquely identify and authenticate users.  
  7002. This identification and authentication shall take place 
  7003. prior to all other interactions between the TOE and the 
  7004. user.  Other interactions shall only be possible after 
  7005. successful identification and authentication.  The 
  7006. authentication information shall be stored in such a way 
  7007. that it can only be accessed for review or modification by 
  7008. authorised users.  For every interaction the TOE shall be 
  7009. able to establish the identity of the user.
  7010.  
  7011.  
  7012. Access Control
  7013.  
  7014. A.81 The TOE shall be able to distinguish and administer access 
  7015. rights of users, roles and processes to explicitly 
  7016. designated objects.  (Roles denote users with special 
  7017. attributes).  It shall be possible to restrict access by 
  7018. users to these objects in such a manner that this access is 
  7019. only possible via specially established processes.  In 
  7020. addition, it shall be possible to allocate objects to a 
  7021. predefined type.  It shall be possible to specify for each 
  7022. type of object which users, roles or processes can possess 
  7023. certain access types to these objects.  This should make it 
  7024. possible to restrict user access to objects of a certain 
  7025. type in such a manner that this access is only possible via 
  7026. fixed established processes.  It should only be possible 
  7027. for authorised users to define new types or to grant or 
  7028. revoke access rights to types.  These actions shall be 
  7029. initiated explicitly by this user.  For these actions all 
  7030. communication between the TOE and the user shall be via a 
  7031. trusted path.
  7032.  
  7033. A.82 The following minimum access rights shall exist:  read, 
  7034. write, add, delete, rename (for all objects), execute, 
  7035. delete, rename (for executable objects), creation of 
  7036. objects of a certain type, deletion of objects of a certain 
  7037. type.
  7038.  
  7039. A.83 With each attempt by users or user groups to access objects 
  7040. which are subject to the administration of rights, the TOE 
  7041. shall verify the validity of this access attempt.  
  7042. Unauthorised access attempts shall be rejected.
  7043.  
  7044. Accountability
  7045.  
  7046. A.84 The TOE shall contain an accountability component which is 
  7047. able, for each of the following events, to log that event 
  7048. together with the required data:
  7049.  
  7050. a)   Use of the identification and authentication 
  7051. mechanism:
  7052.  
  7053. Required data:  Date;  time;  user identity supplied;  
  7054. identification of the equipment on which the 
  7055. identification and authentication mechanism was used 
  7056. (e.g. terminal-id);  success or failure of the 
  7057. attempt.
  7058.  
  7059. b)   Actions that attempt to exercise access rights to an 
  7060. object which is subject to the administration of 
  7061. rights:
  7062.  
  7063. Required data:  Date;  time;  user identity;  name of 
  7064. the object;  type of access attempt;  success or 
  7065. failure of the attempt.
  7066.  
  7067. c)   Creation or deletion of an object which is subject to 
  7068. the administration of rights:
  7069.  
  7070. Required data:  Date;  time;  user identity;  name of 
  7071. the object;  type of action.
  7072.  
  7073. d)   Actions by authorised users affecting the security of 
  7074. the TOE:
  7075.  
  7076. Required data:  Date;  time;  user identity;  type of 
  7077. action;  name and attribute of the object to which the 
  7078. action relates (such actions are introduction or 
  7079. deletion (suspension) of users;  introduction or 
  7080. removal of storage media;  start up or shut down of 
  7081. the TOE).
  7082.  
  7083. e)   Definition or deletion of types:
  7084.  
  7085. Required data:  Date;  time;  user identity;  type of 
  7086. action;  name of the type.
  7087.  
  7088. f)   Assignation of a type to an object:
  7089.  
  7090. Required data:  Date;  time;  user identity;  name of 
  7091. the object;  name of the type.
  7092.  
  7093. g)   Granting or revocation of access rights for an object 
  7094. or an object type:
  7095.  
  7096. Required data:  Date;  time;  user identity;  type of 
  7097. action;  type of access right;  name of the subject;  
  7098. name of the object or name of the object type.
  7099. A.85 Unauthorised users shall not be permitted to access 
  7100. accountability data.  It shall be possible to selectively 
  7101. account for the actions of one or more users.  Tools to 
  7102. examine and to maintain the accountability files shall 
  7103. exist and be documented.  These tools shall allow the 
  7104. actions of one or more users to be identified selectively.  
  7105. The structure of the accountability records shall be 
  7106. described completely.
  7107.  
  7108.  
  7109. Audit
  7110.  
  7111. A.86 Tools to examine the accountability files for the purpose 
  7112. of audit shall exist and be documented.  These tools shall 
  7113. allow the actions of one or  more users to be identified 
  7114. selectively.
  7115.  
  7116.  
  7117.  
  7118.  
  7119. Example Functionality Class F-AV
  7120.  
  7121.  
  7122. Objective
  7123.  
  7124. A.87 Functionality class F-AV sets high requirements for the 
  7125. availability of a complete TOE or special functions of a 
  7126. TOE.  Such requirements are significant for TOEs that 
  7127. control manufacturing processes, for example.
  7128.  
  7129.  
  7130. Reliability of Service
  7131.  
  7132. A.88 The TOE shall be able to recover from a failure of certain 
  7133. individual hardware components (e.g. a board of an 
  7134. individual processor in a multiprocessor TOE) in such a 
  7135. manner that all constantly required functions remain 
  7136. continuously available in the remaining TOE.  After the 
  7137. failed component has been repaired, it shall be possible to 
  7138. reintegrate it into the TOE in such a way that the 
  7139. continuous operation of constantly required functions is 
  7140. assured.  Following the integration the TOE shall achieve 
  7141. its original degree of tolerance against TOE failures.  
  7142. Maximum times shall be stated for the duration of such a 
  7143. reintegration process.
  7144.  
  7145. A.89 Irrespective of its load at any time, the TOE shall be able 
  7146. to guarantee a maximum response time for certain specified 
  7147. actions.  In addition, for certain specified actions, it 
  7148. shall be guaranteed that the TOE will not be subject to 
  7149. deadlock.
  7150.  
  7151.  
  7152.  
  7153.  
  7154. Example Functionality Class F-DI
  7155.  
  7156.  
  7157. Objective
  7158.  
  7159. A.90 Example functionality class F-DI sets high requirements 
  7160. with regard to the safeguarding of data integrity during 
  7161. data exchange.
  7162.  
  7163.  
  7164. Identification and Authentication
  7165.  
  7166. A.91 The TOE shall uniquely identify and authenticate users.  
  7167. This identification and authentication shall take place 
  7168. prior to all other interactions between the TOE and the 
  7169. user.  Other interactions shall only be possible after 
  7170. successful identification and authentication.  The 
  7171. authentication information shall be stored in such a way 
  7172. that it can only be accessed for review or modification by 
  7173. authorised users.  For every interaction the TOE shall be 
  7174. able to establish the identity of the user.
  7175.  
  7176. A.92 Prior to the establishment of a connection the peer entity 
  7177. (computer, process or user) shall be uniquely identified 
  7178. and authenticated.  User data shall only be exchanged after 
  7179. identification and authentication have been successfully 
  7180. completed.  On receipt of data it shall be possible to 
  7181. uniquely identify and authenticate the sender of the data.  
  7182. All authentication information shall be protected against 
  7183. unauthorised access and forgery.
  7184.  
  7185.  
  7186. Accountability
  7187.  
  7188. A.93 The TOE shall contain an accountability component which is 
  7189. able, for each of the following events, to log that event 
  7190. together with the required data:
  7191.  
  7192. a)   Use of the identification and authentication 
  7193. mechanism:
  7194.  
  7195. Required data:  Date;  time;  initiator of the 
  7196. identification and authentication;  name of the 
  7197. subject to be identified;  success or failure of the 
  7198. action.
  7199.  
  7200. b)   Identified errors in the data exchange:
  7201.  
  7202. Required data:  Date;  time;  peer entity in the data 
  7203. exchange;  nature of the error;  success or failure of 
  7204. the attempted correction.
  7205.  
  7206.  
  7207.  
  7208. c)   Data Exchange:
  7209.  
  7210. Required data:  Date;  time;  user identity of the 
  7211. initiator;  name of the peer entity (computer, process 
  7212. or user);  parameters of the establishment of the 
  7213. connection (if these vary).
  7214.  
  7215. A.94 Unauthorised users shall not be permitted to access 
  7216. accountability data.  It shall be possible to selectively 
  7217. account for the actions of one or more users.  Tools to 
  7218. examine and to maintain the accountability files shall 
  7219. exist and be documented.  These tools shall allow the 
  7220. actions of one or more users to be identified selectively.  
  7221. The structure of the accountability records shall be 
  7222. described completely.
  7223.  
  7224.  
  7225. Audit
  7226.  
  7227. A.95 Tools to examine the accountability files for the purpose 
  7228. of audit shall exist and be documented.  These tools shall 
  7229. allow the actions of one or  more users to be identified 
  7230. selectively.
  7231.  
  7232.  
  7233. Data Exchange
  7234.  
  7235. Data Integrity
  7236.  
  7237. A.96 Methods for error detection and error correction shall be 
  7238. applied in the case of data exchange.  These mechanisms 
  7239. shall be designed in such a way that intentional 
  7240. manipulations of the address fields and user data can be 
  7241. identified.  Knowledge only of the algorithms applied in 
  7242. the mechanisms without any special additional knowledge 
  7243. shall not enable unrecognised manipulations of the 
  7244. aforementioned data.  The additional knowledge required for 
  7245. this shall be protected in such a manner that it can only 
  7246. be accessed by a few authorised users. 
  7247.  
  7248. A.97 Moreover, mechanisms shall be used which reliably uniquely 
  7249. identify as an error the unauthorised replay of data.
  7250.  
  7251.  
  7252.  
  7253.  
  7254. Example Functionality Class F-DC
  7255.  
  7256.  
  7257. Objective
  7258.  
  7259. A.98 Example functionality Class F-DC is intended for TOEs with 
  7260. high demands on the confidentiality of data during data 
  7261. exchange.  An example candidate for this class is a 
  7262. cryptographic device.
  7263.  
  7264.  
  7265. Data Exchange
  7266.  
  7267. Data Confidentiality
  7268.  
  7269. A.99 The TOE shall have a facility to encrypt user information 
  7270. prior to exchange and (at the receiving end) to decrypt it 
  7271. automatically.  An algorithm officially approved by a 
  7272. certification authority shall be applied.  It shall be 
  7273. assured that the parameter values (e.g. keys) required for 
  7274. decrypting are protected in such a manner that no 
  7275. unauthorised person can access this data.
  7276.  
  7277.  
  7278.  
  7279.  
  7280. Example Functionality Class F-DX
  7281.  
  7282.  
  7283. Objective
  7284.  
  7285. A.100     Example functionality class F-DX is intended for 
  7286. networks with high demands on the confidentiality and 
  7287. integrity of the information to be exchanged.  For example, 
  7288. this can be the case when sensitive information has to be 
  7289. exchanged via insecure (for example: public) networks.
  7290.  
  7291.  
  7292. Identification and Authentication
  7293.  
  7294. A.101     The TOE shall uniquely identify and authenticate 
  7295. users.  This identification and authentication shall take 
  7296. place prior to all other interactions between the TOE and 
  7297. the user.  Other interactions shall only be possible after 
  7298. successful identification and authentication.  The 
  7299. authentication information shall be stored in such a way 
  7300. that it can only be accessed for review or modification by 
  7301. authorised users.  For every interaction the TOE shall be 
  7302. able to establish the identity of the user.
  7303.  
  7304. A.102     Prior to the exchange of user data the peer entity 
  7305. (computer, process or user) shall be uniquely identified 
  7306. and authenticated.  User data shall only be exchanged after 
  7307. identification and authentication have been successfully 
  7308. completed.  On receipt of data it shall be possible to 
  7309. uniquely identify and authenticate the sender of the data.  
  7310. All authentication information shall be protected against 
  7311. unauthorised access and forgery.
  7312.  
  7313.  
  7314. Accountability
  7315.  
  7316. A.103     The TOE shall contain an accountability component 
  7317. which is able, for each of the following events, to log 
  7318. that event together with the required data:
  7319.  
  7320. a)   Use of the identification and authentication 
  7321. mechanism:
  7322.  
  7323. Required data:  Date;  time;  initiator of the 
  7324. identification and authentication;  name of the 
  7325. subject to be identified;  success or failure of the 
  7326. action.
  7327.  
  7328. b)   Identified errors in the data exchange:
  7329.  
  7330. Required data:  Date;  time;  peers in the data 
  7331. exchange;  type of the error;  success or failure of 
  7332. the attempted correction.
  7333. c)   Connection establishment:
  7334.  
  7335. Required data:  Date;  time;  user identity of the 
  7336. initiator;  name of the peer entity (computer, process 
  7337. or user);  establishment parameters (if these vary).
  7338.  
  7339. d)   Special data exchange transactions:
  7340.  
  7341. Required data:  Date;  time;  user identity of the 
  7342. transmitter;  user identity of the recipient;  user 
  7343. information communicated;  date and time of the 
  7344. receipt of the data.
  7345.  
  7346. A.104     Unauthorised users shall not be permitted to access 
  7347. accountability data.  It shall be possible to selectively 
  7348. account for the actions of one or more users.  Tools to 
  7349. examine and to maintain the accountability files shall 
  7350. exist and be documented.  These tools shall allow the 
  7351. actions of one or more users to be identified selectively.  
  7352. The structure of the accountability records shall be 
  7353. described completely.
  7354.  
  7355.  
  7356. Audit
  7357.  
  7358. A.105     Tools to examine the accountability files for the 
  7359. purpose of audit shall exist and be documented.  These 
  7360. tools shall allow the actions of one or  more users to be 
  7361. identified selectively.
  7362.  
  7363.  
  7364. Data Exchange
  7365.  
  7366. Access Control
  7367.  
  7368. A.106     All information previously transmitted which can be 
  7369. used for unauthorised decryption shall be protected in such 
  7370. a way that only such persons who positively need such 
  7371. access in order to be able to perform their duties can 
  7372. access this data.
  7373.  
  7374. Data Confidentiality
  7375.  
  7376. A.107     The TOE shall offer the possibility of end-to-end 
  7377. encryption which ensures confidentiality regarding the 
  7378. recipient over large sections of the communication channel.  
  7379. In addition, traffic flow confidentiality shall also be 
  7380. guaranteed on designated data communication links.  
  7381.  
  7382.  
  7383.  
  7384.  
  7385. Data Integrity
  7386.  
  7387. A.108     The TOE shall be designed in such a way that 
  7388. unauthorised manipulation of user data and accountability 
  7389. data and unauthorised replay of data are reliably 
  7390. identified as errors.  
  7391.  
  7392.  
  7393.  
  7394.  
  7395.  
  7396.  
  7397.  
  7398.  
  7399.  
  7400.  
  7401.  
  7402.  
  7403.  
  7404.  
  7405.  
  7406.  
  7407.  
  7408.  
  7409.  
  7410.  
  7411.  
  7412.  
  7413.  
  7414. This page left blank
  7415.  
  7416. Annex B  -  THE CLAIMS LANGUAGE
  7417.  
  7418.  
  7419. Introduction
  7420.  
  7421. B.1  Within the context of the IT security evaluation criteria 
  7422. it is helpful to have a means of describing the claimed 
  7423. security functions provided by an IT security product in 
  7424. semiformal style, but still expressed using natural 
  7425. language.  The Claims Language defined in this Annex was 
  7426. developed to meet that requirement.
  7427.  
  7428. B.2  The benefits of using the Claims Language to specify 
  7429. security functionality are that:
  7430.  
  7431. a)   it provides a semiformal style of specification, but 
  7432. because it is based on natural language, it can be 
  7433. read and understood without special knowledge of a 
  7434. notation or set of rules;
  7435.  
  7436. b)   it indicates the necessary linking and grouping of 
  7437. claims;
  7438.  
  7439. c)   it reduces the scope for ambiguity in the 
  7440. interpretation of the claims;
  7441.  
  7442. d)   it enables the claims for a TOE to be expressed in a 
  7443. way that is suited to the process of evaluation.
  7444.  
  7445. B.3  The Claims Language facilitates controlled extension of the 
  7446. predefined notation to handle concepts for which no 
  7447. suitable elements exist.  Within a Claims Document, normal 
  7448. natural language can be used to describe mechanisms and 
  7449. assumptions if a more formal approach is not necessary.  
  7450. The Claims Language is sufficiently flexible to allow any 
  7451. set of claims peculiar to a specialised TOE to be defined 
  7452. without any departure from the rules of the language;  thus 
  7453. sponsors of an evaluation are not in any way constrained to 
  7454. make their claims fit the language.
  7455.  
  7456.  
  7457. Overview
  7458.  
  7459. B.4  Using the Claims Language, security functions are expressed 
  7460. using a set of rules for generating Action Phrase 
  7461. Templates, each of which provides the framework for a 
  7462. particular type of claim.  Each Action Phrase Template is 
  7463. then combined with one of a set of Target Phrases to create 
  7464. an outline claim.  Nouns and phrases specific to the 
  7465. product, the function and/or the vendor are then 
  7466. substituted into the outline claim to create a real claim.  
  7467. An example of the generation of a claim will be found in 
  7468. paragraphs B.30 to B.34 of this Annex.
  7469.  
  7470. B.5  As part of the statement of a claim it is possible to 
  7471. include a reference to the mechanism that implements the 
  7472. claim.
  7473.  
  7474. B.6  It is permissible to omit or modify the linking words used 
  7475. in outline claims in order to improve the readability or 
  7476. grammatical accuracy of claims.
  7477.  
  7478. B.7  Examples of permissible changes are:
  7479.  
  7480. a)   substituting the plural for the singular, or vice 
  7481. versa;
  7482.  
  7483. b)   inserting or removing the definite and indefinite 
  7484. articles;
  7485.  
  7486. c)   changing prepositions.
  7487.  
  7488. B.8  It is permissible to introduce new action or target phrases 
  7489. where no existing phrases are appropriate, provided that 
  7490. such phrases have been discussed with and approved by the 
  7491. Certification Body.
  7492.  
  7493. B.9  A standard layout shall be used for Claims Documents 
  7494. containing Claims Language claims, as set out in paragraphs 
  7495. B.38 to B.44 of this Annex.  Claims shall be grouped under 
  7496. a standardised headings based on the Generic Headings for 
  7497. Functionality. This aids understanding and facilitates 
  7498. comparison with other TOEs.
  7499.  
  7500.  
  7501. Warnings
  7502.  
  7503. B.10 Care should be taken when formulating claims which are 
  7504. configuration dependent.  It may be possible to configure a 
  7505. TOE in ways which are insecure (i.e. some of the claims are 
  7506. invalidated).  If this is the case, restrictions to exclude 
  7507. such insecure options or combinations of options should be 
  7508. stated as environmental constraints (see paragraph B.41 of 
  7509. this Annex onwards).
  7510.  
  7511. B.11 Care should also be take to formulate claims at an 
  7512. appropriate level of granularity.  If a proposed claim 
  7513. seems to encompass several Generic Headings, or requires 
  7514. more substitutions than are possible using the appropriate 
  7515. template, then the claim is at too high a level and needs 
  7516. to be broken down into a series of simpler claims.
  7517.  
  7518.  
  7519.  
  7520.  
  7521. Action Phrase Templates
  7522.  
  7523. B.12 Action Phrase Templates shall be generated from the 
  7524. framework below, with italics indicating words or phrases 
  7525. in the template to be replaced by specific claim-related 
  7526. substitutions in an actual claim, with [] indicating 
  7527. optional parts, and <> indicating selection of an option 
  7528. from the relevant list of options following:
  7529.  
  7530.      This  TOE  [<qualifier>]  <verb>  <action>  ...  [ <time> ] 
  7531.  
  7532. [ using the mechanism defined in paragraph n].
  7533.  
  7534.      Where <qualifier> may be:
  7535.  
  7536.           contains a function that
  7537.      or   must be used in an environment that
  7538.  
  7539.      and <verb> may be:
  7540.  
  7541.           will
  7542.      or   will not
  7543.      or   can be configured to
  7544.      or   can be configured to not
  7545.      or   cannot be configured to
  7546.  
  7547.      and <action> may be:
  7548.  
  7549.           establish
  7550.      or   detect
  7551.      or   control
  7552.      or   permit
  7553.      or   prevent
  7554.      or   ensure
  7555.      or   record in object
  7556.  
  7557.      and <time> may be:
  7558.  
  7559.           before security-relevant-event
  7560.      or   after security-relevant-event.
  7561.  
  7562. B.13 The environment option of <qualifier> is only used in 
  7563. defining environmental constraints where great precision is 
  7564. required.
  7565.  
  7566. B.14 Where details of specific mechanisms form part of the 
  7567. security target, they shall be defined as part of the 
  7568. Claims Document through a linked mechanism specification 
  7569. paragraph.  If no such link is included, details of the 
  7570. mechanism do not form part of the security target and will 
  7571. be treated as proprietary information.  The function option 
  7572. of <qualifier> is optional.  It is used to name the 
  7573. particular product mechanism that implements a particular 
  7574. claim.  This name is included purely for explanatory 
  7575. purposes.
  7576.  
  7577. B.15 Some example Action Phrase templates are:
  7578.  
  7579.      This product will ensure ...
  7580.  
  7581.      This product contains an audit utility that will establish 
  7582. ...
  7583.  
  7584.      This product can be configured to permit ...
  7585.  
  7586.      This product must be used in an environment that will 
  7587. prevent ...
  7588.  
  7589.      This add-in board will record in its audit trail ...
  7590.  
  7591.      This product will prevent ... before completion of secure 
  7592. startup.
  7593.  
  7594.  
  7595. Target Phrases
  7596.  
  7597. B.16 The permitted set of Target Phrases is as follows, with [] 
  7598. indicating optional parts of the phrase:
  7599.  
  7600. 1    ... audit-information concerning security-relevant-
  7601. events
  7602.  
  7603. 2    ... the identity of a process requested
  7604.  
  7605. 3    ... the identity of the {user,process} requesting a 
  7606. process
  7607.  
  7608. 4    ... the identity of the {user,process} requesting 
  7609. access-type to an object
  7610.  
  7611. 5    ... the identity of a process executed
  7612.  
  7613. 6    ... the rejection of a process request
  7614.  
  7615. 7    ... the identity of an object to which access-type was 
  7616. requested
  7617.  
  7618. 8    ... the identity of an object to which access-type was 
  7619. granted
  7620.  
  7621. 9    ... the identity of an object to which access-type was 
  7622. refused
  7623.  
  7624.  
  7625. 10   ... the access-set of a user
  7626.  
  7627. 11   ... the access-set of a process
  7628.  
  7629. 12   ... the access-set of a {user,process}
  7630.  
  7631. 13   ... the access-set of an object
  7632.  
  7633. 14   ... the access-type granted to a {user,process} in 
  7634. respect of an object
  7635.  
  7636. 15   ... access-type by {user,process} in respect of an 
  7637. object
  7638.  
  7639. 16   ... the actions performed by a {user,process} in 
  7640. respect of an object
  7641.  
  7642. 17   ... the factors affecting the access-set of a user
  7643.  
  7644. 18   ... the factors affecting the access-set of a process
  7645.  
  7646. 19   ... the factors affecting the access-set of a 
  7647. {user,process}
  7648.  
  7649. 20   ... the factors affecting the access-set of an object
  7650.  
  7651. 21   ... clearing of information from an object
  7652.  
  7653. 22   ... the security-attributes of an object
  7654.  
  7655. 23   ... the correctness of the security-attributes of an 
  7656. object
  7657.  
  7658. 24   ... the security-attributes of an object formed by 
  7659. combining a number of objects
  7660.  
  7661. 25   ... the security-attributes of a set of objects formed 
  7662. by partitioning a single object
  7663.  
  7664. 26   ... the granting of access-type to an object cannot 
  7665. cause deadlock through {user,process}es using access-
  7666. type to objects
  7667.  
  7668. 27   ... the {user,process}es using access-type to an 
  7669. object which has caused deadlock
  7670.  
  7671. 28   ... the granting of access-type to an object cannot 
  7672. cause livelock through {user,process}es using access-
  7673. type to objects
  7674.  
  7675. 29   ... the {user,process}es using access-type to an 
  7676. object which has caused livelock
  7677.  
  7678. 30   ... security-attribute of object is identical to that 
  7679. of object
  7680.  
  7681. 31   ... claim [not] to become time-critical
  7682.  
  7683. 32   ... claim [not] to become accelerated or delayed
  7684.  
  7685. 33   ... claim [not] to become time-dependent
  7686.  
  7687. 34   ... claim [not] to be by-passed
  7688.  
  7689. 35   ... claim [not] to be deactivated
  7690.  
  7691. 36   ... claim [not] to be corrupted
  7692.  
  7693.  
  7694. Substitutions
  7695.  
  7696. B.17 Substitutions shall be made for the following nouns/phrases 
  7697. (italicised in the Action Phrase Templates and Target 
  7698. Phrases above):-
  7699.  
  7700.      access-set;  access-type;  audit-information;  claim;  
  7701. factors;  function;  n;  object;  product;  process;  
  7702. security-attribute;  security-relevant-event;  user;  
  7703. {user,process}
  7704.  
  7705. B.18 All substitutions shall be explained using natural 
  7706. language, either in a separate section of the Claims 
  7707. Document (see paragraph B.39 of this Annex), or immediately 
  7708. following the claim where the substitution is used.
  7709.  
  7710. B.19 Some examples of possible substitutions are:-
  7711.  
  7712. access-set               replaced by    read/write access 
  7713. to I/O ports
  7714. access-type              replaced by    read permission
  7715. access-type              replaced by    read/write/delete 
  7716. permission
  7717. audit-information        replaced by    date and time
  7718. audit-information        replaced by    terminal number
  7719. claim                    replaced by    (a cross-reference 
  7720. to another claim)
  7721. factors                  replaced by    number of incorrect 
  7722. responses
  7723. function            replaced by    password system
  7724. n                   replaced by    (a paragraph number)
  7725. object                   replaced by    file
  7726. object                   replaced by    resource control 
  7727. block
  7728. object                   replaced by    hard disc storage 
  7729. (i.e. a type of object)
  7730. TOE                 replaced by    operating system
  7731. TOE                 replaced by    PC security board
  7732. process             replaced by    unprivileged task
  7733. security-attribute       replaced by    integrity of data
  7734. security-attribute       replaced by    actual destination
  7735. security-attribute       replaced by    apparent source
  7736. security-relevant-event  replaced by    attempted privilege 
  7737. violations
  7738. security-relevant-event  replaced by    user logoff
  7739. security-relevant-event  replaced by    change of security 
  7740. level
  7741. user                replaced by    data entry clerk
  7742. user                replaced by    security administrator
  7743. {user,process}      replaced by    job (i.e. implying any 
  7744. user)
  7745.  
  7746. B.20 There are parts of the Action Phrases and Target Phrases 
  7747. which are in square brackets [];  these are optional words 
  7748. or phrases which may be included or omitted as appropriate 
  7749. to the vendor's claim.
  7750.  
  7751. B.21 Most noun and phrase substitutions are straightforward.  
  7752. However, some particular conventions exist and are 
  7753. explained below.
  7754.  
  7755. B.22 The definition of an access-set depends on whether it is 
  7756. related to:-
  7757.  
  7758. a)   an object;  in which case it represents the list of 
  7759. users, processes and {user,process}es, each with an 
  7760. associated access-type, able to use an object.
  7761.  
  7762. b)   a process or a user or a {user,process};  in which 
  7763. case it represents the list of objects, each with an 
  7764. associated access-type, available to a user, a process 
  7765. or a {user,process}.
  7766.  
  7767. B.23 Thus, access-set is a (notional) list of all the objects a 
  7768. user can access, together with what he can do to each one 
  7769. and via which processes, or a (notional) list of all the 
  7770. users who can access an object, via which processes and 
  7771. what they can do to it.
  7772.  
  7773. B.24 Access-type is the series of ways of using an object and is 
  7774. vendor-defined.  Typical examples of these are create, 
  7775. read, write, delete, execute or a combination of these or 
  7776. none.
  7777.  
  7778.  
  7779.  
  7780. B.25 As a specific example the set could be defined as:
  7781.  
  7782. a)   "Amend" allows a record to be updated but does not 
  7783. allow new records to be added to the file.
  7784.  
  7785. b)   "Create" allows new records to be added to the file 
  7786. but does not allow existing ones to be changed.
  7787.  
  7788. d)   "Delete" allows records to be removed from the file.
  7789.  
  7790. e)   "Execute" allows the file to be loaded into memory and 
  7791. then scheduled for running as a program.
  7792.  
  7793. f)   "Read" allows data in records to be copied to working 
  7794. storage.
  7795.  
  7796. B.26 Many objects will possess identical security attributes.  
  7797. Thus if a claim will apply to all objects of a particular 
  7798. type the substitution will usually be best expressed in 
  7799. terms of the type of object, rather than by listing all 
  7800. possible objects of that type.
  7801.  
  7802.  
  7803. Mechanisms
  7804.  
  7805. B.27 As part of a claim it is possible to include a description 
  7806. of the mechanism used to implement that claim.  This is 
  7807. done through the "using" option of the claim's Action 
  7808. Phrase Template, by giving a reference to a paragraph in 
  7809. the Claims Document that specifies and/or explains the 
  7810. mechanism employed.  Evaluation will then include 
  7811. confirmation that the stated mechanism is the mechanism 
  7812. used.
  7813.  
  7814. B.28 Any appropriate method may be used to define or describe 
  7815. the mechanism, provided that the explanation is sufficient 
  7816. for evaluation to determine at the level of confidence 
  7817. corresponding to the targeted Evaluation Level:
  7818.  
  7819. a)   the claimed mechanism is present in the product;
  7820.  
  7821. b)   its operation matches the claimed specification;
  7822.  
  7823. c)   it is the mechanism actually used to implement the 
  7824. claim.
  7825.  
  7826. B.29 In many cases it may be easier and clearer to define a 
  7827. mechanism by reference to a published standard, or give a 
  7828. table of types of inputs and the corresponding results, 
  7829. rather than providing details of the algorithm employed 
  7830. using either natural language or a specification or 
  7831. programming language.
  7832.  
  7833.  
  7834.  
  7835. Example
  7836.  
  7837. B.30 As an example, the following Action Phrase Template may be 
  7838. generated using the rules specified:
  7839.  
  7840.      This TOE will establish ...
  7841.  
  7842.      where the word in italics can be replaced by a specific 
  7843. term.
  7844.  
  7845. B.31 Similarly, a Target Phrase may be selected such as:
  7846.  
  7847.      ... the identity of an object to which access-type was 
  7848. requested.
  7849.  
  7850. B.32 Putting these together gives:
  7851.  
  7852.      This TOE will establish the identity of an object to which 
  7853. access-type was requested.
  7854.  
  7855.      into which some possible substitutions are:
  7856.  
  7857.      add-in security board         for       TOE
  7858.      any file                 for       object
  7859.      write or delete permission         for       access-type
  7860.  
  7861. B.33 Thus a complete claim could be:
  7862.  
  7863.      This add-in security board will establish the identity of 
  7864. any file to which write or delete permission was requested.
  7865.  
  7866. B.34 Obviously this example is extremely artificial.  In 
  7867. practice for real TOEs highly specific claims are made, 
  7868. often related to a particular real or assumed environment.
  7869.  
  7870.  
  7871. Claims Document Structure
  7872.  
  7873. Use of Generic Headings for Functionality
  7874.  
  7875. B.35 Claims shall be grouped under the Generic Headings set out 
  7876. in Chapter 2 of these criteria.  Not all TOEs will make 
  7877. claims under all headings;  where there are no claims made 
  7878. for a particular heading this shall be stated.  Claims 
  7879. shall be included for any events or actions that are to be 
  7880. prevented.
  7881.  
  7882. B.36 Table B.1 identifies Target Phrases which will often appear 
  7883. under particular Generic Headings.  The table is intended 
  7884. for use as a general guide only;  the flexibility of the 
  7885. Claims Language means that often other Target Phrases will 
  7886. also be appropriate.
  7887.  
  7888. B.37 Table B.2 cross-references Target Phrases to the possible 
  7889. substitutions they contain.
  7890.  
  7891. Layout of Claims Documents
  7892.  
  7893. B.38 A security target using the Claims Language shall be set 
  7894. out using the following structure:
  7895.  
  7896. a)   the security objectives of the target including any 
  7897. constraints or assumptions concerning the real or 
  7898. assumed environment of the TOE, set out as a Product 
  7899. Rationale (or in the case of a system, a System 
  7900. Security Policy);
  7901.  
  7902. b)   an informal specification of the claims in natural 
  7903. language, or a reference to another document 
  7904. containing that informal specification (this may be a 
  7905. reference to a functionality class defined in informal 
  7906. style), and a correlation of these informal claims to 
  7907. the security objectives;
  7908.  
  7909. c)   global substitutions;
  7910.  
  7911. d)   claims under each Generic Heading in turn;
  7912.  
  7913. e)   details of security mechanisms;
  7914.  
  7915. f)   the claimed rating of the minimum strength of 
  7916. mechanisms;
  7917.  
  7918. g)   the target evaluation level.
  7919.  
  7920. B.39 Under the Global Substitutions heading any general 
  7921. substitutions used in the Action or Target Phrases of more 
  7922. than one claim shall be defined and explained.
  7923.  
  7924. B.40 These substitutions shall be overridden where different 
  7925. (usually more specific) substitutions are given as part of 
  7926. particular claims.
  7927.  
  7928. B.41 If the TOE relies upon properties of its real or assumed 
  7929. environment in order for it to function correctly, these 
  7930. shall be specified in the rationale or policy section of 
  7931. the Claims Document.  Evaluation will assume that these 
  7932. constraints/assumptions will hold in actual use.
  7933.  
  7934. B.42 Each such constraint/assumption shall be expressed either 
  7935. in natural language or in the Claims Language (using the 
  7936. Action Phrase environment qualifier).  Where ambiguity 
  7937. exists (because natural language has been used) the 
  7938. evaluators will interpret such constraints/assumptions in a 
  7939. way that is consistent with other assumptions or claims.
  7940.  
  7941. B.43 Some claims may remain valid even if a particular assertion 
  7942. is not true.  Where this is the case, natural language 
  7943. shall be used to indicate which claims remain true when 
  7944. that assertion fails.
  7945.  
  7946. B.44 An example of an assertion (expressed in natural language) 
  7947. is:
  7948.  
  7949.      The RAM backup battery must not be removed from the 
  7950. security board or allowed to discharge below its minimum 
  7951. operating voltage.
  7952.  
  7953. Format of Individual Claims
  7954.  
  7955. B.45 Each substitution in the Action or Target phrases used to 
  7956. form a claim which is not identified and defined in the 
  7957. global substitutions section of the Claims Document must be 
  7958. defined and expressed in natural language immediately 
  7959. following the claim where it appears.
  7960.  
  7961.  
  7962.  
  7963. Table B.1 Claims Target Phrases and Generic Headings
  7964.  
  7965.  
  7966.                Identification and 
  7967. Authentication
  7968.                |    Access Control
  7969.                |    |    Accountability
  7970.                |    |    |    Audit
  7971.                |    |    |    |    Object Reuse
  7972.                |    |    |    |    |    Accuracy
  7973.                |    |    |    |    |    |    Reliability of 
  7974. Service
  7975.                |    |    |    |    |    |    |    Data Exchange
  7976.                |    |    |    |    |    |    |    |
  7977. 1    Audit information   X    X    X    X    X    X    X    X
  7978. 2    Identity of process requested X    X    X    X              
  7979. X    X
  7980. 3    Identity of {u,p} requesting a process  X    X    X    X    
  7981.           X    X
  7982. 4    Identity of {u,p} requesting an object  X    X    X    X    
  7983.           X    X
  7984. 5    Identity of process executed  X    X    X    X              
  7985. X    X
  7986. 6    Rejection of process request  X    X    X    X              
  7987. X    X
  7988. 7    Identity of object requested  X    X    X    X              
  7989. X    X
  7990. 8    Identity of object granted    X    X    X    X         X    
  7991. X    X
  7992. 9    Identity of object refused    X    X    X    X              
  7993. X    X
  7994. 10   Access-set of user       X                             X
  7995. 11   Access-set of process         X                             X
  7996. 12   Access-set of {u,p}      X                             X
  7997. 13   Access-set of object          X                             X
  7998. 14   Object access granted to {u,p}     X    X    X    X         
  7999.           X
  8000. 15   Object access by {u,p}   X    X    X    X                   X
  8001. 16   Object actions performed by {u,p}       X    X    X         
  8002.           X
  8003. 17   Factors affecting user access-set       X                   
  8004.           X
  8005. 18   Factors affecting process access-set         X              
  8006.                X
  8007. 19   Factors affecting {u,p} access-set      X                   
  8008.           X
  8009. 20   Factors affecting object access-set          X              
  8010.                X
  8011. 21   Clearing information from object                       X    
  8012.           X
  8013. 22   Security-attributes of object X    X    X    X    X    X    
  8014. X    X
  8015. 23   Correctness of security-attributes of object                
  8016.      
  8017.      X         X
  8018. 24   Security-attributes of combination object         X         
  8019.           X    
  8020.      X
  8021. 25   Security-attributes of partitioned object         X         
  8022.           X    
  8023.      X
  8024. 26   Granting access causes no deadlock                          
  8025.      X    X
  8026. 27   Deadlock can be detected                               X    X
  8027. 28   Granting access causes no livelock                          
  8028.      X    X
  8029. 29   Livelock can be detected                               X    X
  8030. 30   Objects have identical security-attributes        X         
  8031.           X
  8032.           X
  8033. 31   Time-critical claim                               X
  8034. 32   Accelerated or delayed claim                                X
  8035. 33   Time-dependent claim                                   X
  8036. 34   By-pass claim  X    X    X    X    X    X    X    X
  8037. 35   Deactivate claim    X    X    X    X    X    X    X    X
  8038. 36   Corrupt claim  X    X    X    X    X    X    X    X
  8039.  
  8040.  
  8041. Table B.2 Claims Target Phrases and Permitted Substitutions
  8042.  
  8043.  
  8044.                access-set
  8045.                |    access-type
  8046.                |    |    audit-information
  8047.                |    |    |    claim
  8048.                |    |    |    |    object
  8049.                |    |    |    |    |    process
  8050.                |    |    |    |    |    |    security-attribute
  8051.                |    |    |    |    |    |    |    security-
  8052. relevant-event
  8053.                |    |    |    |    |    |    |    |    user
  8054.                |    |    |    |    |    |    |    |    |
  8055.      {user,process}
  8056.                |    |    |    |    |    |    |    |    |    |
  8057. 1    Audit information             X                        X
  8058. 2    Identity of process requested                          X
  8059. 3    Identity of {u,p} requesting a process                      
  8060.      X         
  8061.           X
  8062. 4    Identity of {u,p} requesting an object       X              
  8063. X              
  8064.           X
  8065. 5    Identity of process executed                           X
  8066. 6    Rejection of process request                           X
  8067. 7    Identity of object requested       X              X
  8068. 8    Identity of object granted         X              X
  8069. 9    Identity of object refused         X              X
  8070. 10   Access-set of user  X                                       X
  8071. 11   Access-set of process    X                        X
  8072. 12   Access-set of {u,p} X                                       
  8073.      X
  8074. 13   Access-set of object     X                   X
  8075. 14   Object access granted to {u,p}          X              X    
  8076.                     X
  8077. 15   Object access by {u,p}        X              X              
  8078.           X
  8079. 16   Object actions performed by {u,p}                      X    
  8080.                     X
  8081. 17   Factors affecting user access-set  X                        
  8082.                X
  8083. 18   Factors affecting process access-set    X                   
  8084.      X
  8085. 19   Factors affecting {u,p} access-set X                        
  8086.                     X
  8087. 20   Factors affecting object access-set     X                   X
  8088. 21   Clearing information from object                       X
  8089. 22   Security-attributes of object                     X         X
  8090. 23   Correctness of security-attributes of object                
  8091.      X
  8092.           X
  8093. 24   Security-attributes of combination object                   
  8094.      X         X
  8095. 25   Security-attributes of partitioned object                   
  8096.      X         X
  8097. 26   Granting access causes no deadlock      X              X    
  8098.                     X
  8099. 27   Deadlock can be detected      X              X              
  8100.           X
  8101. 28   Granting access causes no livelock      X              X    
  8102.                     X
  8103. 29   Livelock can be detected      X              X              
  8104.           X
  8105. 30   Objects have identical security-attributes                  
  8106.      X    
  8107.      X
  8108. 31   Time-critical claim                X
  8109. 32   Accelerated or delayed claim                 X
  8110. 33   Time-dependent claim                    X
  8111. 34   By-pass claim                 X
  8112. 35   Deactivate claim                   X
  8113. 36   Corrupt claim                 X
  8114.  
  8115.  
  8116.  
  8117.  
  8118.  
  8119.  
  8120.  
  8121.  
  8122.  
  8123.  
  8124.  
  8125.  
  8126.  
  8127.  
  8128.  
  8129.  
  8130.  
  8131.  
  8132.  
  8133.  
  8134.  
  8135. This page left blank
  8136.  
  8137.