Ctcpec 1

1 The Canadian
2 Trusted
3 Computer Product
4 Evaluation Criteria
5 Version 3.0e
6 January 1993
7 Canadian System Security Centre
8 Communications Security Establishment
9 Government of Canada
1 Acknowledgments
2 Special recognition is extended to the principal authors of the Criteria Working Group at the Communications
3 Security Establishment: Eugen Mate Ba ci c, CSE (Managing Editor); Aaron Cohen, CSE; Paul Cormier, CSE;
4 Richard Doucette, CSE; Andrew Robison, CSE; and Karin Taylor, CSE. Also due acknowledgment for their input
5 and contributions to this document are William Brierley, CSE; Ken Donaldson, CSE; Milan S. Kuchta, CSE; Gary
6 S. Maxwell, CSE; and Alice Sturgeon, Treasury Board .
7 Further thanks are offered to the numerous reviewers, both internal to the Communications Security Establishment,
8 and those in industry, government, and various institutions, both at home and internationally, who offered useful
9 comments throughout the development of these criteria. The Canadian Criteria, and the Criteria Working Group,
10 owes much to the caring and enthusiasm shown by the reviewers.
11 Copyright 1990, 1991, 1992, 1993 The Government of Canada.
12 Permission is granted to make and distribute verbatim copies of this document
13 provided the copyright notice and this permission are preserved on all copies.
14 This document is available in both ofcial languages.
15 Ce document est disponible en fran cais.
1 Table of Contents
2 Summary Table of Contents
3 Foreword . . . . . . . . . . . . . . . . . . . . . . . . xxi
4 Preface . . . . . . . . . . . . . . . . . . . . . . . . . xxiii
5 Denitions . . . . . . . . . . . . . . . . . . . . . . . . . 1
6 Introduction . . . . . . . . . . . . . . . . . . . . . . . 11
7 Historical Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10 Structure of the Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11 Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
12 Condentiality Criteria . . . . . . . . . . . . . . . . 29
13 Covert Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
14 Discretionary Condentiality . . . . . . . . . . . . . . . . . . . . . . . . . 30
15 Mandatory Condentiality . . . . . . . . . . . . . . . . . . . . . . . . . . 32
16 Object Reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
17 Integrity Criteria . . . . . . . . . . . . . . . . . . . . 35
18 Discretionary Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
19 Mandatory Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
20 Physical Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
21 Rollback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
22 Separation of Duties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
23 Self Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
24 Availability Criteria . . . . . . . . . . . . . . . . . . 45
25 Containment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
26 Fault Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
27 Robustness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
28 Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
29 Accountability Criteria . . . . . . . . . . . . . . . . 51
30 Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
31 Identication and Authentication . . . . . . . . . . . . . . . . . . . . . . 54
32 Trusted Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
33 DRAFT i March 23, 1993
1 Table of Contents
2 Assurance Criteria . . . . . . . . . . . . . . . . . . . 57
3 T-0 Non Compliant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4 Assurance Level T-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
11 Bibliography . . . . . . . . . . . . . . . . . . . . . . 87
12 APPENDICES . . . . . . . . . . . . . . . . . . . . . 89
13 A Rationale for the Criteria, Services and Levels of Service . . . . . . . 91
14 B Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
15 C Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
16 D Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
17 E A Guide to Object Mediation . . . . . . . . . . . . . . . . . . . . . . . 117
18 F A Guide to Condentiality . . . . . . . . . . . . . . . . . . . . . . . . . 121
19 G A Guide to Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
20 H A Guide to Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
21 I A Guide to Accountability . . . . . . . . . . . . . . . . . . . . . . . . . 159
22 J A Guide to Assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
23 K Implementing Services via Cryptography . . . . . . . . . . . . . . . . 179
24 L Government Security Policy and Standards . . . . . . . . . . . . . . 189
25 M Security Functionality Proles . . . . . . . . . . . . . . . . . . . . . . 193
26 DRAFT ii March 23, 1993
1 Table of Contents
2 Table of Contents
3 Foreword . . . . . . . . . . . . . . . . . . . . . . . . xxi
4 Preface . . . . . . . . . . . . . . . . . . . . . . . . . xxiii
5 Denitions . . . . . . . . . . . . . . . . . . . . . . . . . 1
6 Introduction . . . . . . . . . . . . . . . . . . . . . . . 11
7 Historical Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9 Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10 Assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11 Evaluation and Rating . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
12 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
13 Structure of the Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
14 Levels of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
15 Additional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
16 Modications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
17 Letter Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
18 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
19 Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
20 Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
21 Products vs. Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
22 Trusted Computing Bases . . . . . . . . . . . . . . . . . . . . . . . . . . 21
23 Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
24 Isolation, Mediation, & Audit . . . . . . . . . . . . . . . . . . . . . . . . 22
25 Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
26 Object Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
27 Tagged Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
28 TCSEC Subjects in the Canadian Criteria . . . . . . . . . . . . . . 25
29 Continuous Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
30 Security Services & Mechanisms . . . . . . . . . . . . . . . . . . . . 26
31 Inclusion of New Services . . . . . . . . . . . . . . . . . . . . . . . . . . 26
32 Modularity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
33 Composable Evaluations . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
34 DRAFT iii March 23, 1993
1 Table of Contents
2 Condentiality Criteria . . . . . . . . . . . . . . . . 29
3 Covert Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4 CC0 Non-compliant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5 CC1 Covert Channel Analysis . . . . . . . . . . . . . . . . . . . . . . . 29
6 CC2 Auditable Covert Channels . . . . . . . . . . . . . . . . . . . . . . 29
7 CC3 Elimination of Covert Channels . . . . . . . . . . . . . . . . . . . 30
8 Discretionary Condentiality . . . . . . . . . . . . . . . . . . . . . . . . . 30
9 CD0 Non-compliant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10 CD1 Minimal Discretionary Condentiality . . . . . . . . . . . . . . . 30
11 CD2 Basic Discretionary Condentiality . . . . . . . . . . . . . . . . . 31
12 CD3 Controlled Discretionary Condentiality . . . . . . . . . . . . . . 31
13 CD4 Advanced Discretionary Condentiality . . . . . . . . . . . . . . 32
15 CM0 Non-compliant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
16 CM1 Minimal Mandatory Condentiality . . . . . . . . . . . . . . . . 32
17 CM2 Basic Mandatory Condentiality . . . . . . . . . . . . . . . . . . 33
18 CM3 Controlled Mandatory Condentiality . . . . . . . . . . . . . . . 33
19 CM4 Advanced Mandatory Condentiality . . . . . . . . . . . . . . . . 34
20 Object Reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
21 CR0 Non-compliant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
22 CR1 Object Reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
23 Integrity Criteria . . . . . . . . . . . . . . . . . . . . 35
24 Discretionary Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
25 ID0 Non-compliant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
26 ID1 Minimal Discretionary Integrity . . . . . . . . . . . . . . . . . . . 35
27 ID2 Basic Discretionary Integrity . . . . . . . . . . . . . . . . . . . . . 36
28 ID3 Controlled Discretionary Integrity . . . . . . . . . . . . . . . . . . 36
29 ID4 Advanced Discretionary Integrity . . . . . . . . . . . . . . . . . . 37
30 Mandatory Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
31 IM0 Non-compliant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
32 IM1 Minimal Mandatory Integrity . . . . . . . . . . . . . . . . . . . . . 37
33 IM2 Basic Mandatory Integrity . . . . . . . . . . . . . . . . . . . . . . 38
34 IM3 Complete Mandatory Integrity . . . . . . . . . . . . . . . . . . . . 38
35 IM4 Advanced Mandatory Integrity . . . . . . . . . . . . . . . . . . . . 39
36 DRAFT iv March 23, 1993
1 Table of Contents
2 Physical Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3 IP0 Non-compliant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4 IP1 Basic Physical Integrity . . . . . . . . . . . . . . . . . . . . . . . . 39
5 IP2 Intermediate Physical Integrity . . . . . . . . . . . . . . . . . . . . 40
6 IP3 Advanced Physical Integrity . . . . . . . . . . . . . . . . . . . . . . 40
7 IP4 Complete Physical Integrity . . . . . . . . . . . . . . . . . . . . . . 40
8 Rollback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
9 IR0 Non-compliant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
10 IR1 Restricted Rollback . . . . . . . . . . . . . . . . . . . . . . . . . . 41
11 IR2 Advanced Rollback . . . . . . . . . . . . . . . . . . . . . . . . . . 41
12 Separation of Duties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
13 IS0 Non-compliant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
14 IS1 Basic Separation of Duties . . . . . . . . . . . . . . . . . . . . . . 42
15 IS2 Administrative Separation of Duties . . . . . . . . . . . . . . . . . 42
16 IS3 Privilege-based Separation of Duties . . . . . . . . . . . . . . . . . 42
17 Self Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
18 IT0 Non-compliant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
19 IT1 Basic Self Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
20 IT2 Intermediate Self Testing . . . . . . . . . . . . . . . . . . . . . . . 43
21 IT3 Advanced Self Testing . . . . . . . . . . . . . . . . . . . . . . . . . 44
22 Availability Criteria . . . . . . . . . . . . . . . . . . 45
23 Containment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
24 AC0 Non-compliant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
25 AC1 Quotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
26 AC2 Denial of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
27 AC3 Resource Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . 46
28 Fault Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
29 AF0 Non-compliant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
30 AF1 Limited Hot Replacement . . . . . . . . . . . . . . . . . . . . . . 46
31 AF2 Hot Replacement . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
32 Robustness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
33 AR0 Non-compliant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
34 AR1 Reliability under Limited Failure . . . . . . . . . . . . . . . . . . 47
35 AR2 Reliability with Degraded Service . . . . . . . . . . . . . . . . . . 47
36 AR3 Reliability with Full Service . . . . . . . . . . . . . . . . . . . . . 48
37 DRAFT v March 23, 1993
1 Table of Contents
2 Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3 AY0 Non-compliant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4 AY1 Manual Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5 AY2 Automated Recovery . . . . . . . . . . . . . . . . . . . . . . . . . 49
6 AY3 Selective Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7 Accountability Criteria . . . . . . . . . . . . . . . . 51
8 Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
9 WA0 Non-compliant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
10 WA1 External Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
11 WA2 Security Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
12 WA3 Security Audit & Alarm . . . . . . . . . . . . . . . . . . . . . . . 52
13 WA4 Detailed Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
14 WA5 Advanced Detection . . . . . . . . . . . . . . . . . . . . . . . . . 53
15 Identication and Authentication . . . . . . . . . . . . . . . . . . . . . . 54
16 WI0 Non-compliant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
17 WI-1 External I&A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
18 WI2 Individual I&A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
19 WI3 Multiple I&A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
20 Trusted Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
21 WT0 Non-compliant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
22 WT1 Basic Trusted Path . . . . . . . . . . . . . . . . . . . . . . . . . . 55
23 WT2 Advanced Trusted Path . . . . . . . . . . . . . . . . . . . . . . . . 55
24 Assurance Criteria . . . . . . . . . . . . . . . . . . . 57
25 T-0 Non Compliant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
27 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
28 Development Environment . . . . . . . . . . . . . . . . . . . . . . . . . . 59
29 Life Cycle Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
30 Conguration Management. . . . . . . . . . . . . . . . . . . . . . . . 59
31 Development Evidence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
32 Functional Specication. . . . . . . . . . . . . . . . . . . . . . . . . . 59
33 Architectural Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
34 Detailed Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
35 Operational Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
36 Security Manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
37 Security Features Users Guide. . . . . . . . . . . . . . . . . . . . . . 60
38 Trusted Facility Manual. . . . . . . . . . . . . . . . . . . . . . . . . . 60
39 DRAFT vi March 23, 1993
1 Table of Contents
2 Security Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
11 Detailed Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
18 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
25 Detailed Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
32 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
39 Detailed Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
40 DRAFT vii March 23, 1993
1 Table of Contents
8 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
15 Detailed Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
22 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
29 Detailed Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
36 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
40 DRAFT viii March 23, 1993
1 Table of Contents
5 Detailed Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
11 Bibliography . . . . . . . . . . . . . . . . . . . . . . 87
12 APPENDICES . . . . . . . . . . . . . . . . . . . . . 89
13 A Rationale for the Criteria, Services and Levels of Service . . . . . . . 91
14 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
15 Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
16 Location of Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
17 Tagging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
18 Access Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
19 CD-1, CM-1, ID-1, and IM-1 . . . . . . . . . . . . . . . . . . . . . . 94
20 Condentiality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
21 Discretionary Condentiality (CD) . . . . . . . . . . . . . . . . . . . 94
22 Mandatory Condentiality (CM) . . . . . . . . . . . . . . . . . . . . . 94
23 Object Reuse (OR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
24 Covert Channels (CC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
25 Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
26 Discretionary Integrity (CD) . . . . . . . . . . . . . . . . . . . . . . . 95
27 Mandatory Integrity (CM) . . . . . . . . . . . . . . . . . . . . . . . . 95
28 Physical Integrity (IP) . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
29 Rollback (IR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
30 Separation of Duties (IS) . . . . . . . . . . . . . . . . . . . . . . . . . 95
31 Self Testing (IT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
32 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
33 Containment (AC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
34 Fault Tolerance (AF) . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
35 Robustness (AR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
36 Recovery (AY) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
37 DRAFT ix March 23, 1993
1 Table of Contents
2 Accountability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
3 Audit (WA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4 Identication and Authentication (WI) . . . . . . . . . . . . . . . . . 96
5 Trusted Path (WT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6 Assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7 B Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
8 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
9 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
10 Covert Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
11 Discretionary Condentiality . . . . . . . . . . . . . . . . . . . . . . . . 98
13 Discretionary Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
14 Mandatory Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
15 Rollback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
16 Separation of Duties . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
17 Containment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
18 Fault Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
19 Robustness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
20 Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
21 Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
22 Trusted Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
23 C Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
24 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
25 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
26 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
27 Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
28 Control Over Processes . . . . . . . . . . . . . . . . . . . . . . . . . 106
29 The Reference Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
30 Classic View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
31 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
32 D Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
33 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
34 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
35 The Reference Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
36 Encapsulated View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
37 Modularity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
38 The Overall System . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
39 The TCB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
40 Networks & The Like . . . . . . . . . . . . . . . . . . . . . . . . . . 116
41 DRAFT x March 23, 1993
1 Table of Contents
2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
3 E A Guide to Object Mediation . . . . . . . . . . . . . . . . . . . . . . . 117
4 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
5 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
6 Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
7 Discretionary and Mandatory Mediation . . . . . . . . . . . . . . . . . 118
8 Accuracy of Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
9 Creation of New Objects . . . . . . . . . . . . . . . . . . . . . . . . 119
10 Export and Import of Objects . . . . . . . . . . . . . . . . . . . . . 120
11 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
12 F A Guide to Condentiality . . . . . . . . . . . . . . . . . . . . . . . . . 121
13 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
14 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
15 Overview of Condentiality . . . . . . . . . . . . . . . . . . . . . . . . 121
16 Covert Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
17 Covert Channel Bandwidths . . . . . . . . . . . . . . . . . . . . . . 122
18 Storage and Timing Channels . . . . . . . . . . . . . . . . . . . . . 122
19 Aggregate Covert Channels . . . . . . . . . . . . . . . . . . . . . . . 123
20 Meeting the Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
21 Discretionary Condentiality . . . . . . . . . . . . . . . . . . . . . . . 123
22 Discretionary Security Policy . . . . . . . . . . . . . . . . . . . . . 123
24 CD-1: Minimal Discretionary Condentiality . . . . . . . . . . . 124
25 CD2: Basic Discretionary Condentiality . . . . . . . . . . . . 125
26 CD3: Controlled Discretionary Condentiality . . . . . . . . . 125
27 CD4: Advanced Discretionary Condentiality . . . . . . . . . 126
28 Mandatory Condentiality . . . . . . . . . . . . . . . . . . . . . . . . . 126
29 Mandatory Security Policy . . . . . . . . . . . . . . . . . . . . . . . 126
31 CM-1: Minimal Mandatory Condentiality . . . . . . . . . . . . 127
32 CM2: Basic Mandatory Condentiality . . . . . . . . . . . . . 128
33 CM3: Controlled Mandatory Condentiality . . . . . . . . . . 128
34 CM4: Advanced Mandatory Condentiality . . . . . . . . . . . 129
35 Object Reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
37 DRAFT xi March 23, 1993
1 Table of Contents
2 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
3 G A Guide to Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
4 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
5 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
6 Overview of Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
7 Discretionary Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
8 Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
10 ID-1: Minimal Discretionary Integrity . . . . . . . . . . . . . . . 133
11 ID2: Basic Discretionary Integrity . . . . . . . . . . . . . . . . 133
12 ID3: Controlled Discretionary Integrity . . . . . . . . . . . . . 134
13 ID4: Advanced Discretionary Integrity . . . . . . . . . . . . . . 134
14 Mandatory Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
15 Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
17 IM-1: Minimal Mandatory Integrity . . . . . . . . . . . . . . . . 136
18 IM2: Basic Mandatory Integrity . . . . . . . . . . . . . . . . . 136
19 IM3: Complete Mandatory Integrity . . . . . . . . . . . . . . . 136
20 IM4: Advanced Mandatory Integrity . . . . . . . . . . . . . . . 137
21 Physical Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
22 Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
24 IP-1: Basic Physical Integrity . . . . . . . . . . . . . . . . . . . . 139
25 IP-2: Intermediate Physical Integrity . . . . . . . . . . . . . . . . 139
26 IP-3: Advanced Physical Integrity . . . . . . . . . . . . . . . . . 139
27 IP-4: Complete Physical Integrity . . . . . . . . . . . . . . . . . 140
28 Rollback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
29 Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
31 IR-1: Restricted Rollback . . . . . . . . . . . . . . . . . . . . . . 141
32 IR-2: Advanced Rollback . . . . . . . . . . . . . . . . . . . . . . 141
33 Separation of Duties . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
34 Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
36 IS-1: Basic Separation of Duties . . . . . . . . . . . . . . . . . . 143
37 IS-2: Administrative Separation of Duties . . . . . . . . . . . . 143
38 IS-3: Privilege-based Separation of Duties . . . . . . . . . . . . 144
39 DRAFT xii March 23, 1993
1 Table of Contents
2 Self Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
3 Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
5 IT-1: Basic Self Testing . . . . . . . . . . . . . . . . . . . . . . . 145
6 IT-2: Intermediate Self Testing . . . . . . . . . . . . . . . . . . . 145
7 IT-3: Advanced Self Testing . . . . . . . . . . . . . . . . . . . . 145
8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
9 H A Guide to Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
10 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
11 Availability Control Objective . . . . . . . . . . . . . . . . . . . . . 147
12 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
13 Requirements for Availability . . . . . . . . . . . . . . . . . . . . . . . 147
14 Policies & Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
15 Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
16 Amoroso Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
17 Yu-Gligor Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
18 CP-6 Quota System . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
19 Telephone System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
20 Perceived Availability . . . . . . . . . . . . . . . . . . . . . . . . 151
21 Conditioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
22 Testing and Monitoring . . . . . . . . . . . . . . . . . . . . . . . 152
23 Common Elements Of The Models . . . . . . . . . . . . . . . . . . . . 152
24 Availability Reference Monitor . . . . . . . . . . . . . . . . . . . . 153
25 Fault Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
26 Containment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
27 Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
29 AC-1: Quotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
30 AC-2: Denial of Service . . . . . . . . . . . . . . . . . . . . . . . 155
31 AC-3: Resource Restrictions . . . . . . . . . . . . . . . . . . . . 155
32 Fault Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
33 Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
35 AF-1: Limited Hot Replacement . . . . . . . . . . . . . . . . . . 155
36 AF-2: Hot Replacement . . . . . . . . . . . . . . . . . . . . . . . 156
37 DRAFT xiii March 23, 1993
1 Table of Contents
2 Robustness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
3 Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
5 AR-1: Reliability under Limited Failure . . . . . . . . . . . . . . 156
6 AR-2: Reliability with Degraded Service . . . . . . . . . . . . . 156
7 AR-3: Reliability with Full Service . . . . . . . . . . . . . . . . 157
8 Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
9 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
10 I A Guide to Accountability . . . . . . . . . . . . . . . . . . . . . . . . . 159
11 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
12 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
13 Audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
14 General Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
15 Effective Auditing. . . . . . . . . . . . . . . . . . . . . . . . . . . 159
16 Physical Storage of Audit Data. . . . . . . . . . . . . . . . . . . 160
18 Audit Granularity. . . . . . . . . . . . . . . . . . . . . . . . . . . 160
19 Audit File Analysis. . . . . . . . . . . . . . . . . . . . . . . . . . 161
20 Selection of Audit Events. . . . . . . . . . . . . . . . . . . . . . . 161
21 Active Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . 162
22 Auditable Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
23 Identication & Authentication . . . . . . . . . . . . . . . . . . . . . . 164
24 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
25 Something you know. . . . . . . . . . . . . . . . . . . . . . . . 164
26 Something you have. . . . . . . . . . . . . . . . . . . . . . . . 165
27 Something you are. . . . . . . . . . . . . . . . . . . . . . . . . 165
29 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
30 J A Guide to Assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
31 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
32 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
33 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
34 Development Environment . . . . . . . . . . . . . . . . . . . . . . . . . 167
35 Life Cycle Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
36 Conguration Management . . . . . . . . . . . . . . . . . . . . . . . 168
37 Basic Principles. . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
38 Planning A Conguration Management System. . . . . . . . . . 169
39 Meeting the Criteria. . . . . . . . . . . . . . . . . . . . . . . . . . 170
40 DRAFT xiv March 23, 1993
1 Table of Contents
2 Development Evidence . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
4 Specication Style. . . . . . . . . . . . . . . . . . . . . . . . . . . 171
5 Level of Detail. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
6 Mapping Requirements. . . . . . . . . . . . . . . . . . . . . . . . 174
7 Functional Specication . . . . . . . . . . . . . . . . . . . . . . . . . 175
8 Architectural Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
9 Detailed Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
10 Security Manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
11 Security Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
12 Trusted Distribution & Generation . . . . . . . . . . . . . . . . . . . . 177
13 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
14 K Implementing Services via Cryptography . . . . . . . . . . . . . . . . 179
15 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
16 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
17 Export Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
18 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
19 Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
20 Implementing Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
21 Discretionary Condentiality . . . . . . . . . . . . . . . . . . . . . . 182
22 Mandatory Condentiality . . . . . . . . . . . . . . . . . . . . . . . 183
23 Object Reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
24 Identication & Authentication . . . . . . . . . . . . . . . . . . . . 183
25 Trusted Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
26 Discretionary Integrity . . . . . . . . . . . . . . . . . . . . . . . . . 184
27 Mandatory Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
28 Separation of Duties . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
29 DRAFT xv March 23, 1993
1 Table of Contents
2 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
3 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
4 L Government Security Policy and Standards . . . . . . . . . . . . . . 189
5 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
6 Objective & Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
7 Security Policy Considerations . . . . . . . . . . . . . . . . . . . . . . 190
8 Accountability, Risk, and Guidance . . . . . . . . . . . . . . . . . . . 191
9 Applying the Policy (In Brief) . . . . . . . . . . . . . . . . . . . . . . 191
10 M Security Functionality Proles . . . . . . . . . . . . . . . . . . . . . . 193
11 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
12 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
13 Equivalency & Other Criteria . . . . . . . . . . . . . . . . . . . . . . . 194
14 Creation of Proles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
15 Prole Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
16 Predened Proles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
17 The TCSEC Proles . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
18 Subsystem Proles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
19 Service Specic Architectures . . . . . . . . . . . . . . . . . . . . . 199
20 The Innite Nature of Proles . . . . . . . . . . . . . . . . . . . . . . . 201
21 DRAFT xvi March 23, 1993
1 Table of Contents
2 List of Figures
3 Figure 1 Product Development and Evaluation Processes. . . . . 14
4 Figure 2 Generic Page Outline . . . . . . . . . . . . . . . . . . . . . . 16
5 Figure 3 Odd (Right Hand) Page Format . . . . . . . . . . . . . . . 17
6 Figure 4 Even (Left Hand) Page Format . . . . . . . . . . . . . . . . 18
7 Figure 5 State Transitions from an Entity to an Object, User, or
8 Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9 Figure 6 Information Flow Between User, Process, and Object . 23
10 Figure 7 Interaction Between TCB Controlled Objects . . . . . . . 23
11 Figure 8 Objects and Their Counterparts . . . . . . . . . . . . . . . 24
12 Figure 9 Objects in the TCSEC and the Canadian Criteria . . . 26
13 Figure 10 Trusted Objects in the TCSEC vs. Canadian Criteria . 106
14 Figure 11 Classic View of a Reference Monitor . . . . . . . . . . . . 108
15 Figure 12 Reference Monitor As Encapsulator . . . . . . . . . . . . . 112
16 Figure 13 Entity Style (Message Passing) Reference Monitor . . . 113
17 Figure 14 Modularity within A Trusted Environment . . . . . . . . . 115
18 Figure 15 User-Process-Object Interrelationship for Object
19 Mediation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
21 Mediation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
23 Mediation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
25 Mediation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
26 Figure 19 Condentiality-related Auditable Events . . . . . . . . . . 162
27 Figure 20 Integrity-related Auditable Events . . . . . . . . . . . . . . 163
28 Figure 21 Availability-related Auditable Events . . . . . . . . . . . . . 163
29 Figure 22 Accountability-related Auditable Events . . . . . . . . . . 163
30 Figure 23 Miscellaneous Auditable Events . . . . . . . . . . . . . . . 164
31 Figure 24 Stated Evidence . . . . . . . . . . . . . . . . . . . . . . . . 173
32 Figure 25 Described Evidence . . . . . . . . . . . . . . . . . . . . . . 173
33 Figure 26 Explained Evidence . . . . . . . . . . . . . . . . . . . . . . 174
34 Figure 27 Cryptography and Tags in Discretionary Controls. . . . . 183
35 Figure 28 Stand-Alone Cryptographic Modules . . . . . . . . . . . . 186
36 Figure 29 Embedded Cryptographic Modules . . . . . . . . . . . . . 186
37 Figure 30 Prole Header Example. . . . . . . . . . . . . . . . . . . . . 196
38 Figure 31 Prole Examples. . . . . . . . . . . . . . . . . . . . . . . . . 196
39 DRAFT xvii March 23, 1993
1 Table of Contents
2 List of Tables
3 Table 1 Mapping of Document Divisions From Standard
4 Nomenclature to Criteria . . . . . . . . . . . . . . . . . . . . 17
5 Table 2 Criteria Letter Codes. . . . . . . . . . . . . . . . . . . . . . . 20
6 Table 3 Sample Access Matrix of User Tags and Object Tags . 93
7 Table 4 Use of Access Matrixes by Services . . . . . . . . . . . . 93
8 Table 5 Discretionary Condentiality Ratings Summary. . . . . . 124
9 Table 6 Mandatory Condentiality Ratings Summary. . . . . . . . 127
10 Table 7 Discretionary Integrity Ratings Summary. . . . . . . . . . 133
11 Table 8 Mandatory Integrity Ratings Summary. . . . . . . . . . . . 135
12 Table 9 Common Availability Policy Terminology Mapped to the
13 Availability Criteria . . . . . . . . . . . . . . . . . . . . . . . 148
14 Table 10 Front End Quotas . . . . . . . . . . . . . . . . . . . . . . . . 150
15 Table 11 Resource Limit Quotas . . . . . . . . . . . . . . . . . . . . . 150
16 Table 12 User Authorization File Quotas . . . . . . . . . . . . . . . . 151
17 Table 13 Generic Quotas . . . . . . . . . . . . . . . . . . . . . . . . . 153
18 Table 14 Levels Affected by Cryptography . . . . . . . . . . . . . . . 181
19 Table 15 Congurations of Cryptographic Modules within a Host . 185
20 Table 16 C2 Equivalent Prole. . . . . . . . . . . . . . . . . . . . . . 197
21 Table 17 B1 Equivalent Prole. . . . . . . . . . . . . . . . . . . . . . . 197
24 Table 20 Standard Partition Subsystem . . . . . . . . . . . . . . . . 199
25 Table 21 Strong Identication Subsystem . . . . . . . . . . . . . . . 199
26 Table 22 Discretionary Based Subsystem . . . . . . . . . . . . . . . 199
27 Table 23 Audit Architecture . . . . . . . . . . . . . . . . . . . . . . . . 200
28 Table 24 Partitioned Architecture . . . . . . . . . . . . . . . . . . . . 200
29 Table 25 Comparted Mode Workstation Architecture . . . . . . . . 200
30 DRAFT xix March 23, 1993
1 Foreword
2 This document represents the current state of development of the Canadian
3 Trusted Computer Product Evaluation Criteria (CTCPEC or Canadian Crite-
4 ria). The purpose of this document is to present a set of technical hard-
5 ware/rmware/software criteria for trusted products which is consistent with the
6 Security Policy of the Government of Canada, the Information Technology Secu-
7 rity Standards under development by the Government of Canada and takes into
8 account reciprocity issues with technical criteria of other nations strategically al-
9 lied with the Government of Canada. Development of the Canadian Criteria has
10 progressed through workshops and discussions with government and industry.
11 Review, revision and further development, as appropriate, will be on a continuing
12 basis with reissuance of a revised Canadian Criteria on an as needed basis.
13 Comments and recommendations for further development and revision of this
14 document are welcomed and should be directed to:
15 Criteria Coordinator
16 InfoSec Evaluations/S5B
17 Communications Security Establishment
18 P. O. Pox 9703 Terminal
19 Ottawa, Canada
20 K1G 3Z4
21 phone: (613) 991-7331
22 fax: (613) 991-7323
23 net: criteria@manitou.cse.dnd.ca
24 Requests for further hardcopies of this document can be directed at the address
25 above. Electronic copies of the Canadian Trusted Computer Product Evaluation
26 Criteria may be anonymously FTPed from:
27 ftp.cse.dnd.ca
28 Login as anonymous and supply your userName@site as the password.
29 DRAFT xxi March 23, 1993
1 Preface
2 The Canadian Trusted Computer Product Evaluation Criteria, dened in this
3 document, classify products into broad divisions of security protection. The
4 criteria provide a basis for the evaluation of effectiveness of security controls
5 built into automatic data processing products.
6 The criteria were developed with two objectives in mind:
7 1. to provide a comparative scale for the evaluation of commercial
8 products; and
9 2. to provide a basis for the development of specications for trusted
10 computer products.
11 Two types of requirements are delineated for trusted processing:
12 1. specic security service requirements; and
13 2. assurance requirements.
14 Some of the assurance requirements enable evaluation personnel to determine
15 if the required features are present and functioning as intended. These criteria
16 are to be applied to the set of components comprising a trusted product and are
17 not necessarily to be applied to each product component individually. Hence,
18 some components of a product may be completely untrusted, while others may
19 be individually evaluated to a lower or higher evaluation class than the trusted
20 product considered as a whole. In trusted products at the high end of the range,
21 the strength of the isolation and mediation mechanisms is such that many of
22 the product components can be completely untrusted.
23 The assurance requirements can be applied across the entire spectrum of elec-
24 tronic data processing product or application processing environments without
25 special interpretation.
26 DRAFT xxiii March 23, 1993
1 Denitions
2 A
Access
3 The performance of a TCB dened operation on an object.
4 Access Matrix
5 The matrix containing one tag type along each axis and containing the authorized
6 modes of access in each matrix element. For example, the complete user/object
7 matrix contains all current user tags along one axis and all current object tags
8 along the second axis. Each matrix element contains the set of allowed and
9 disallowed modes of access in the matrix elements.
10 Access Mediation
11 TCB determination of authorization and whether access should be granted.
12 Access Mediation Information
13 The data structures and algorithms associated with an enforcement decision by
14 the TCB in support of a security policy.
15 Accountability
16 The process of ensuring that security relevant events in a product are correcly
17 attributable to a user.
18 Accreditation
19 The authorization that is granted for the use of an information technology system
20 to process information in its operational environment.
21 Administrator, Administrative User
22 A user to whom an administrative role has been assigned, dened by the
23 Separation of Duties (IS) Service.
24 Approved
25 A deliverable is considered approved after the evaluation authority has reviewed
26 it and stated that it is acceptable for the purposes of the evaluation.
27 DRAFT 1 March 23, 1993
28 Denitions
1 Denitions
2 Assurance
3 The degree of condence that a product correctly implements the security policy.
4 Assurance Level
5 In evaluation criteria, a specic level on a hierarchical scale representing suc-
6 cessively increasing condence that a product implements the security policy.
7 Authorization
8 The right by a user or process to obtain a specic type of access to a specic
9 object.
10 Availability
11 The property that a products services are accessible when needed and without
12 undue delay.
13 B
14 C
Certication
15 The comprehensive assessment of the technical and non-technical security fea-
16 tures of an information technology system, made in support of accreditation, that
17 establishes the extent to which a system satises a specied security policy.
18 Component
19 An identiable and self-contained portion of a product.
20 Compromise
21 A violation of the products security policy.
22 Condential Export
23 The term used to denote the encapsulation of sensitive data by encryption so
24 that it may be transmitted or stored on electronic media which would otherwise
25 be unsuitable for sensitive data.
26 Condentiality
27 The property that information is not made available or disclosed to an unautho-
28 rized user process or object.
29 Denitions
DRAFT 2 March 23, 1993
1 Criteria
2 A metric used for the evaluation of the effectiveness of security services provided
3 by an information technology product.
4 D
Delegation
5 The passing of authorization from one user or process to another as dened in
6 the products security policy.
7 Disclosure
8 The ow of information from an object to a user or process.
9 Discretionary
10 Non-administratively controlled. Under a discretionary policy, authorization and
11 delegation do not require administrative intervention.
12 E
Entity
13 A generic descriptor used to discuss an object within a product regardless of
14 state.
15 Evaluated Rating
16 The rating which a vendors product has achieved in a completed evaluation.
17 Evaluation
18 The process of achieving assurance given a security policy, a consistent descrip-
19 tion of the security functions and a targeted assurance level.
20 Evaluation Authority
21 The organization responsible for the control and management of the evaluation
22 program.
23 Evaluation Facility
24 The organization responsible for performing evaluations under the direction of
25 the Evaluation Authority. The Evaluation Authority and Evaluation Facility can
26 be the same organization.
28 Denitions
1 Denitions
2 Event
3 Any action which causes a change in the state of the product.
4 Export
5 A ow of information such that the information is no longer under the control
6 of the TCB.
7 External
8 Outside of the control of the TCB.
9 F
Functionality
10 The totality of the functional services of a product that contributes to security.
11 G
12 H
Heterogenous System
13 Any collection of components or products which do not provide a uniform
14 security policy. Also called a system.
15 Homogenous System
16 Any collection of components or products, by a single vendor or a consortium,
17 taken collectively but providing a uniform security policy and uniform look and
18 feel.
19 I
Illegal
20 Unauthorized.
21 Import
22 A ow of information such that the information becomes under the control of
23 the TCB.
24 Individual
25 An individual is a single user with respect to the TCB. See the denition of User.
26 Denitions
1 Information Flow
2 The movement of information between users, processes, or objects.
3 Initialization
4 Setting an object or a product to a known or predened state.
5 Internal
6 Inside of the control of the TCB.
7 Isolation
8 J
9 K
10 L
Level
11 See Level of Service.
12 Level of Service
13 A dened and measurable requirement for granularity or strength that addresses
14 a specic set of threats. Each level of service provides a better defence against
15 the threats as the levels increase. Levels of service are hierarchial in terms of
16 protection but not necessarily proper subsets in all cases.
17 Level 0 is reserved as a placeholder for a product which:
18 was evaluated as providing a service; and
19 failed to meet the requirements of a higher level of service.
20 Limit
21 An authorized restriction, or to enforce an authorized restriction.
22 M
Mandatory
23 Administratively controlled. Under a mandatory policy, authorization and del-
24 egation require administrative intervention.
26 Denitions
1 Denitions
2 Mechanism
3 The logic or the algorithm that implements a particular service.
4 Mediation
5 The enforcement of a security policy.
6 Modication
7 The ow of information from a user or a process to an object.
8 N
9 O
Object
10 An encapsulated resource exported by the TCB. A resource which stores or
11 contains information and upon which the TCB enforces mediation
1
.
12 Object Tag
13 A tag created or associated based upon the identity of an object. An object tag
14 can be attached by the TCB to a user, process or object.
15 P
Policy
16 A statement of scope and mechanism of control.
17 Process
18 An active entity under the control of the TCB.
19 Process Tag
20 A tag created or associated based upon the identity of a process. A process tag
21 can be attached by the TCB to a user, process or object.
22 Product
23 The totality of hardware, rmware, software, and documentation offered by a
24 vendor for evaluation.
25 1
Ideally the TCB is opaque and the set of all visible resources in a product is equal to the set
26 of all objects exported by the TCB.
27 Denitions
1 Protected Object
2 The set of objects which are included within a security policy and considered
3 under the control of the TCB.
4 Protection
5 The enforcement of a security policy.
6 Q
7 R
Rating
8 The totality of the set of service levels and assurance level of a product. See
9 also Target Rating and Evaluated Rating.
10 Reference Monitor
11 An abstract machine concept which mediates accesses to objects by users and
12 processses. A reference monitor embodies three principles: completeness (all ac-
13 cesses are mediated), isolation from interference or tampering, and veriability.
14 Resource
15 A primitive entity exported by or existing in the underlying machine. Anything
16 usable or consumable within a product. See also Object.
17 Responsibility
18 Delegated authorization.
19 Restriction
20 Limits on access or authorization in the enforcement of the products security
21 policy.
22 S
Security
23 The quality or state being protected from uncontrolled losses or effects.
24 Security Functionality Prole
25 See Evaluated Rating.
27 Denitions
1 Denitions
2 Security Policy
3 A set of rules and procedures regulating the use of information including its
4 processing, storage, distribution and presentation.
5 Security Policy Model
6 Security Service
7 A functional grouping rated for its ability to address a dened set of threats.
8 One or more levels of service is dened for each security service.
9 Session
10 A period during which a user interacts with the product.
11 State
12 Refers to one of the three states an object may be in: user, process, or object.
13 Storage
14 An addressable location to which information can be placed and retrieved.
15 Subject
16 The TCSEC term for a process or user. It is used interchangeably in the TCSEC
17 for both.
18 System
19 See Heterogenous System.
20 T
Tag
21 A term used to describe any access mediation information associated with users,
22 processes, or objects. The association of a tag with an entity may be explicit or
23 implicit. The tag of an entity is part of its encapsulation by the TCB.
24 Target Rating
25 The rating which a vendor intends to achieve in an evaluation.
26 Denitions
1 TCB Boundary
2 The scope of control to which the TCB maintains enforcement of the products
3 security policy.
4 Trusted Computing Base (TCB)
5 The elements of a product, including any hardware, rmware and software,
6 involved in enforcing a products security policy; or those elements involved in
7 enforcing a given service policy when used in relation to a specic service.
8 U
Unauthorized
9 Not authorized. See Authorization.
10 User
11 An active entity outside of and not constrained by the products security policy
12 other than in its interactions with the TCB. The TCB will have explicit and
13 implicit assumptions about users and will use these to create an encapsulated
14 abstraction of the actual entity.
15 User Tag
16 A tag created or associated based upon the identity of a user. A user tag can
17 be attached by the TCB to a user, process or object.
18 User Type
19 ????
20 An active entity outside of and not constrained by the products security policy
21 other than in its interactions with the TCB. The TCB will have explicit and
22 implicit assumptions about users and will use these to create an encapsulated
23 abstraction of the actual entity.
24 V
Vendor
25 The organization offering a product for evaluation and representing the products
26 interests to the Evaluation Authority.
27 Violation
28 Contrary to the products security policy.
30 Denitions
1 Denitions
2 W
3 X
4 Y
5 Z
6 Denitions
1 Historical Perspective
2 Introduction
3 Historical
4 Perspective
In the late 1960s and early 1970s, Project MAC
2
of the Massachusetts Institute of
Technology (MIT) was working on the next generation operating system. At the
same time, MITRE was contracted by the National Bureau of Standards (NBS),
5 now the National Institute of Standards and Technology (NIST), to develop a
6 set of criteria against which systems of high trust could be evaluated. Using
7 Project MAC as a base, MITRE, MIT, Bell Laboratories and General Electric
8 (the latter two replaced by Honeywell) set out to design a system which was
9 highly trusted. The project resulted in two products: Multics and the Trusted
10 Computer System Evaluation Criteria.
11 The Multics (Multiplexed Information and Computing Service) Operating Sys-
12 tem was used as the testbed for the security concepts being developed by MITRE.
13 Further, the policy implemented by the Multics operating system was dictated
14 by the Department of Defense (DoD) and formalized by D.E. Bell and L.J.
15 LaPadula; it is commonly known as the Bell-LaPadula Model/Policy. This pol-
16 icy is a condentiality oriented policy which deals with ensuring that sensitive
17 information is not disclosed to unauthorized individuals.
18 The Trusted Computer System Evaluation Criteria (TCSEC) was a direct out-
19 growth of the MITRE/NBS project. Project MAC was tasked with ensuring
20 proof-of-concept as well as the feasibility of the security concepts. The TCSEC
21 was nalized in 1983 and released in the now familiar orange cover as CSC-
22 STD-00183. In 1985, the TCSEC received a minor update and became a DoD
23 standard, DoD 5200.28STD. It has popularly become known as the Orange
24 Book and has remained unchanged to date.
25 In August 1988, the Canadian System Security Centre (CSSC) was formed. Its
26 primary tasks were to develop a criteria which would address issues unique to
27 the Government of Canada and to set up a Canadian evaluation capability.
28 The rst version of the Canadian Criteria was released in May 1989. The basic
29 premise of ve base criteria creating a duality of functionality and assurance was
30 evident. In December of 1990, version 2.0 was released; in July 1991 version
31 2.1
3
. Version 2 was the rst to adopt the breakdown of the functional criteria
32 into services with levels of strength and the rst to be used for evaluations.
33 The experience gained and the aws discovered during evaluations, along with
34 2
Project MAC was a US Government funded research group.
35 3
In order to distinguish between the English and French versions, a letter designator was
36 appended after the version number; an e denotes the English version and an f the French.
37 DRAFT 11 March 23, 1993
38 Introduction
1 Introduction
2 comments received from numerous individuals and organizations, were used by
3 the Criteria Working Group to update and improve the Canadian Criteria.
4 Scope
The U.S. Orange Book, or TCSEC, the baseline of computer security evalu-
ations for years, primarily targets multi-user, monolithic mainframe and mini
5 systems. Databases, networks, subsystems, etc. all are brought in line with the
6 Orange Book by various interpretations such as the Trusted Database Inter-
7 pretation (TDI) or the Trusted Network Interpretation (TNI). To avoid the use of
8 interpretations the Canadian Criteria targets a wider range of products such as
9 monolithic systems, multiprocessor systems, databases, subsystems, distributed
10 systems, networked systems, object-oriented systems, and others.
11 This widened targeting is accomplished by splitting the Criteria into two dis-
12 tinct groups known as the duality of functionality and assurance. Functionality
13 consists of Condentiality, Integrity, Availability, and Accountability Criteria.
14 Assurance consists of the Assurance Criteria. Each of the criteria within the
15 functionality group are more or less independent of one another. The depen-
16 dencies which do occur between the various services found in the functional
17 criteria are known as constraints.
18 A product is dened as a collection of functionality services to which a level
19 of assurance is globally applied. The functionality services selected must be a
20 well-dened set
4
, with each services constraints being adhered to; and with each
21 service selected at a specic level of strength. Note that, with minor exceptions
5
,
22 there are no functionality/assurance constraints.
23 The criteria is a metric used for the evaluation of the effectiveness of the security
24 services provided by a product. Each service is a functional grouping dened for
25 its ability to address a set of threats. For example, the Availability Criteria are
26 divided into Containment, Fault Tolerance, Robustness, and Recovery services.
27 Each of these are components of products which provide availability. However,
28 all of the criteria services need not exist within one product.
29 The Assurance Criteria, on the other hand, reects the degree of condence that
30 a product correctly implements its security policy. Assurance is applied across
31 the entire product under evaluation. A product given a T4 assurance rating
32 has had this level of assurance applied across all the security services within
33 the product.
34 4
A functionality null set is acceptable (e.g., in a compiler).
35 5
Embedded cryptographic devices are handled as special cases and the reader should refer to
36 Appendix K. Covert Channels is a functionality service with a constraint to an assurance level of
T-3.
37 Introduction
1 Scope
2 Functionality
The four functionality criteria dene services which are general abstractions of
the basic building blocks which can be used to dene trusted products.
3 Most products are dened with a specic threat or operating environment in
4 mind. Further, the threats drive the policy that the product will enforce. The
5 policy dened by the product can be abstracted out to one of the four policy-
6 oriented criteria.
7 Condentiality: Threats centred around disclosure of information to
8 unauthorized parties is a condentiality issue. Disclo-
9 sure can range from the release of classied government
10 documents to the movement of banking information be-
11 tween bank loan managers. Whenever there is a re-
12 quirement for limitations on the release of information,
13 the services to control disclosure will be found under
14 the Condentiality Criteria.
15 Integrity: Threats centred around modication of information by
16 unauthorized parties are an integrity issue. Modication
17 can range from the modication of sensitive government
18 documents to the sensitivity of the correctness of patient
19 medicinal dosages in a hospital. Whenever there is
20 a requirement for limitations on the modiability of
21 information, the services to control modication will
22 be found under the Integrity Criteria.
23 Availability: Threats centred around accessibility of host systems is
24 an availability issue. Accessibility can range from pro-
25 tection against denial of service to the requirement that
26 a system have a minimal mean time between failures.
27 Whenever there is a requirement for insuring accessibil-
28 ity of a system, the services to govern the accessibility
29 will be found under the Availability Criteria.
30 Accountability: Threats centred around authorization and audit of access
31 and manipulation of a system or its data is an account-
32 ability issue. Accountability concerns can range from
33 ensuring only authorized individuals access a given sys-
34 tem to tracking of user actions within a system. When-
35 ever there is a requirement for monitoring or insuring
36 valid access to a system, the corresponding services will
37 be found under the Accountability Criteria.
38 Each service contains levels. A level of service is a dened and measurable
39 requirement for granularity or strength that addresses a specic set of threats.
40 As the level of service increases, a better defence against the threats is provided.
41 Levels of service are hierarchial in terms of protection but are not necessarily
42 DRAFT 13 March 23, 1993
43 Introduction
1 Introduction
2 proper subsets in all cases. The levels begin at zero (0) and increase towards
3 an n, where n is unique for each service
6
.
4 Assurance
Assurance is the degree of condence that the products security policy is
correctly implemented. Assurance is gained through the development process
5 and the evaluation process. Development process assurance is gained by Vendor
6 actions to promote correctness. The evaluation process contributes to overall
7 assurance through the analysis of evaluation deliverables and other evaluator
8 actions. The division of vendor and evaluation processes is presented in Figure
9 1.
T-5
Functionality
Services
CD
CM
CR
WI
WA
IS
AY
T-5
Assurance
Level
Development Process Evaluation Process
.
.
.
Configuration
Management
Testing
Design
Manuals
.
.
.
Configuration
Management
Testing
Design
Manuals
Phase 1
Phase 2
Phase n
.
.
.
.
.
.
Product
}
10 Figure 1: Product Development and Evaluation Processes.
11 Each product that enters the evaluation process must have a level of assur-
12 ance associated with it. The levels of assurance are hierarchical, representing
13 successively increasing condence that the product security policy is correctly
14 implemented. Greater development and evaluation effort is required as the lev-
15 els increase.
16 Evaluation and
17 Rating
Evaluation is the process of achieving assurance given a security policy, a
consistent description of the security functions and a targeted assurance level.
The evaluation results in a rating which is the totality of the set of service levels
18 and assurance level of the product. The ratings of two distinct services, even if
19 their numeric level is the same, do not represent any form of equality.
20 The evaluated rating will consist of a series of letter-number combinations.
21 These will be grouped by criteria type in the following order: Condentiality,
22 Integrity, Availability, Accountability and nally Assurance.
23 6
For example, the Containment division under the Availability Criteria ranges from AC0 to
24 AC3, however the Object Reuse division under the Condentiality Criteria ranges from CR0 to
CR1.
25 Introduction
1 Structure of the Criteria
2 If a products target rating indicates a specic service and service level, failure
3 to meet the service level, or any lower than the target but above zero, would
4 result in a zero level rating. A zero rating is an indication of noncompliance
5 for that particular service. If a product does not implement a particular service,
6 then no rating for that service is given. A zero level rating cannot be specied
7 by a vendor as part of a valid target rating.
8 Purpose
The criteria have been developed to provide:
9 1. the Government of Canada with a metric with which to evaluate the
10 degree of assurance that can be placed in computer products used
11 for the processing of sensitive information; and
12 2. a guide to manufacturers as to what security services to build into
13 their commercial products in order to produce widely available
14 products that satisfy requirements for sensitive applications.
15 3. a guide which may be used in trusted procurements.
16 Structure of
17 the Criteria
All Canadian Trusted Computer Product Evaluation Criteria (CTCPEC) releases
are denoted by a version number. Each version number is divided into a major
and minor release number. A version number is of the form X.y, where X is the
major release number and y the minor release number. Whenever substantial
18 changes have occurred to the Criteria
7
, the major number will change. For
19 example, from 2 to 3. However, when minor changes occur, such as with
20 editorial corrections, only the minor number is modied, as from 2.0 to 2.1.
21 The Canadian Trusted Computer Product Evaluation Criteria are organized in a
22 manner allowing for quick reference. Each page of the document is physically
23 divided into four parts: header, footer, subheading column, and text/major
24 headings column (see Figure 2). As Figure 2 indicates, there are also rapid
25 indices at the bottom outside corner of each page. These can be used to quickly
26 nd the major parts of the Criteria, such as Introduction, Condentiality Criteria,
27 or any of the appendices. Further, Figure 2 presents the ow of the document.
28 The grey arrows indicate the order of the various headings, and implicitly the
29 text associated with each, as found within the Criteria.
30 The mapping of the standard terms used in addressing portions of a document
31 with those used in the Criteria proper is presented in Table 1. The primary
32 difference is located in the ve criteria parts, where chapters are actually the
33 various services dened and the sections are the service levels.
34 7
The Criteria is constantly undergoing revision. However, many revisions are minor. On a
35 two year cycle, the Criteria will be reviewed in light of new commentary and changes in industry.
If required, a new major release of the Criteria will take place. Minor revisions of the Criteria are
36 completed as needed.
37 DRAFT 15 March 23, 1993
38 Introduction
1 Introduction
Part
SL-0
Section
Subsection Subsubsection
Page #
Left Page Header Right Page Header
Subheading
Column
Text & Major
Headings Column
Header
Footer
Rapid Index
Location
Left Page Right Page
Flow of
Text
Divider
Chapter
2 Figure 2: Generic Page Outline
3 By placing the heavily referenced headings as side heads (as illustrated under
4 the Subheading Column in Figure 2), they stand out from the rest of the text.
5 This allows the reader to quickly nd these sections when referenced in the
6 various appendices or when referenced for evaluation purposes.
7 Introduction
Availability Criteria
The Availability Criteria represent an attempt to create a set of criteria to
address the availability issue as it is understood today. Although research
into a more fundamental definition of availability are currently underway,
for the Criteria availability is being defined in terms of:
1. User authorisation/allocation to resources
2. Scope of control
3. Recovery
4. Robustness
5. Access restrictions
These terms are a compendium of what various industry and govern-
ment experts believe availability comprises. These five terms are fur-
ther grouped into the following categories: Containment (User autho-
risation/allocation of resources, scope of control, access restrictions --
all of which encompass "denial of service), Recovery, and Robustnes
(which includes redundancy).
These three groups are used as the divisions within the Availability
Criteria
Containment
Levels within this division provide increasing control an objects ability
to interfere with the actions of other objects.
This level, Availability/Containment Level 0 (AC-0), is reserved for those
products which have been evaluated but fail to meet the requirements of
any of the Containment criteria required by Availability
An Availability/Containment Level 1 (AC-1) product nominally satisfies
the containment requirements by providing restrictions on the number of
objects a user may have allocated at any given time. It shall incorporate
some level of control over all system resources such that no one individual
user can deny access to another users object space.
19
Containment
AC-0
Non-compliant
AC-1
Resource Restrictions
Service Header
Criteria
Heading
Service
Heading
Service
Level
Headings
Text
Rapid Index
2 Figure 3: Odd (Right Hand) Page Format
3 Denitions Within CTCPEC Document
4 Divisions
Introduction Criteria Appendices
5 Part Introduction Criteria n/a
6 Chapter Division Service Appendix
7 Section Section Service Level Section
8 Subsection Subsection Subsection Subsection
9 Subsubsection Subsubsection Subsubsection Subsubsection
10 Table 1 Mapping of Document Divisions From Standard Nomenclature to Criteria
11 DRAFT 17 March 23, 1993
12 Introduction
1 Introduction
Robustness
Availability
AR-0
Non-Compliant
AR-1
Reliability under Single
Failure
Service
Heading
Service
Level
Headings
20
A list of "cntained resources" shall be provided to the evaluating
authority to ensure that access to these resources are being properly
controlled.
All "contained" resources would be defined with preset limits and tags
as to allocation rights.
All resources of the system under direct control of the TCB shall be con-
trolled and disseminated in a controlled manner in pre-assigned blocks.
No user may attempt to limit access to system resources by means of
hoarding or otherwise manipulating the system so as to restrict the sys-
tems ability to offer services to other users and objects.
Attempts to hoard or otherwise gain unauthorized resources shall be
audited and continued attempts shall be noted on the system console
and to the security officer.
The TCB shall define and control access rights to all resources within the
system. Each access right shall be granted a priority against which the
TCB shall allocate resources. The TCB shall grant access rights to objects
in such a manner that those requirements of the TCB and privileged users
shall be fulfilled first, in a prioritized manner. No system user or object
may restrict the rights of access of the TCB or any authori zed user which
contravenes the security policy of the TCB.
All resources within the system (hardw are and software) will be con-
trolled and disseminated in a controlled manner in pre-assigned blocks.
No user or object may attempt to hoard resources between sessions thus
depriving other users or objects of system resources.
AC-2
Complete Resource
Control
AC-3
Prioritized Resource
Rightst
This level is reservied for those products that have been evaluated but
that fail to meet the requirements for a higher level.
The system shall include provisions so as to ensure availability of service.
Failure of a single component within the system shall not impede the
performance of the system nor shall such failure be noticed to the average
user of the system.
Notification of failure shall be accomplished by both audible alarms and
textual reports to the system console and system administrator.
Service
Level
Headings
Criteria
Heading
Rapid Index
2 Figure 4: Even (Left Hand) Page Format
3 More detailed examples of the headings and various pieces which comprise a
4 page within the Criteria are illustrated in Figures 3 and 4.
5 Levels of Service
Each service level is given as a letter-number combination. Immediately below
6 the level designator is a textual title for the level.
7 Introduction
2 Additional
3 Requirements
As the levels of service increase, additional requirements for the new level are
bold faced.
4 Modications
Should minor revisions be necessary, the updated portions of the Criteria would
5 have a change bar along the left side of the modied text, as illustrated for this
6 paragraph. A major revision to the Criteria will not contain any change bars.
7 Letter Codes
With many words beginning with the same letters and the limit of 26 letters, some
8 compromises were made. The following list contains all the one and two letter
9 level codes and explanations as to why each letter was chosen. Unfortunately, it
10 was not possible to come up with French equivalents to all the letter level codes.
11 Therefore, to maintain commonality and to minimize confusion, the French and
12 English codes are identical.
13 Criteria
Letter
Codes
Full Rating Title Range
14 Condentiality CC Covert Channels CC-0 CC-3
15 CD Discretionary
16 Condentiality
CD-0 CD-4
17 CM Mandatory Condentiality CM-0 CM-4
18 CR Object Reuse CR-0 CR-1
19 Integrity ID Discretionary Integrity ID-0 ID-4
20 IM Mandatory Integrity IM-0 IM-4
21 IP Physical Integrity IP-0 IP-4
22 IR Rollback IR-0 IR-2
23 IS Separation of Duties IS-0 IS-3
24 IT Self Testing IT-0 IT-3
25 Availability AC Containment AC-0 AC-3
26 AF Fault Tolerance AF-0 AF-2
27 Table 2 Criteria Letter Codes. (Continued . . . )
28 DRAFT 19 March 23, 1993
29 Introduction
1 Introduction
2 AR Robustness AR-0 AR-3
3 AY Recovery AY-0 AY-3
4 Accountability
5 (Who)
WA Audit WA-0 WA-5
6 WI Identication and
7 Authentication
WI-0 WI-3
8 WT Trusted Path WT-0 WT-2
9 Assurance
10 (Trust)
T Levels of Assurance T-0 T-7
11 Table 2 Criteria Letter Codes.
12 An example of a rating would be CD-2, CR-1, AC-1, WI-1, WA-2, T-2.
13 Constraints
In some cases, a specic service is not valid without other services. Whenever
14 this is the case, a constraint indicates the other required services and their
15 corresponding levels. To ensure visibility, the following format is used:
16 CONSTRAINT: CR-1.
17 The constraints listed are the ones directly required for the given service to
18 perform properly. The constraint list is a minimal list, therefore, the services
19 listed may also be constrained by another service which may not be directly
20 required. For the full set of constraints for a given level of service see Appendix
21 B.
22 Appendices
Informative appendices are provided to aid in the understanding of the Criteria.
23 These appendices include discussions of various security policy models and their
24 applicability to the Criteria, guidelines to the ve criteria, and explanations of
25 the ideas and rationale behind the Criteria.
26 Each appendix uses the Criteria as a base of reference and stands on its own.
27 The only cross references within the appendices are to Criteria itself.
28 Introduction
1 Fundamentals
2 Fundamentals
The Criteria is based on three elements: mediation, isolation, and audit. From
these three elements four basic policies can be developed: condentiality, the
3 ability to prevent release of information to unauthorized individuals; integrity,
4 the ability to prevent modication by unauthorized individuals; availability, the
5 ability to indicate, with some level of precision, the ability of a product to
6 withstand a denial of service attack or failure; and accountability, the ability to
7 hold people responsible for their actions. A further requirement is necessary to
8 ensure that the four basic policies are complete and cohesive, that element is
9 assurance. Assurance provides an all encompassing level of trust to which the
10 various policies within the product can be evaluated.
11 A further discussion of these fundamentals, and the method by which the various
12 services can be dened through them, is provided in Appendices C and D.
13 Products vs.
14 Systems
The Canadian Criteria is a product oriented criteria. Products are broadly dened
as any grouping of software, hardware, and/or rmware provided by a vendor,
or vendors acting in a consortium, which provide a uniform security policy
15 and uniform look and feel. Two types of systems exist: non-homogenous (or
16 heterogenous) and homogenous.
17 Non-homogenous systems are dened as groups of products without a uniform
18 security policy, and are not covered by these criteria. The study of computer
19 security in non-homogenous systems remains an open research topic.
20 Any product which consists of more than one component, such as a network,
21 is known as a homogenous system if it abides by the product restrictions above.
22 This denition allows for the inclusion of networks, distributed systems, etc,
23 within the context of the Canadian Criteria without the requirement for additional
24 interpretations.
25 Trusted
26 Computing
27 Bases
A Trusted Computing Base (TCB) is the set of elements of a product, including
any hardware, rmware and software, involved in enforcing a products security
policy; or those elements involved in enforcing a given service policy when used
in relation to a specic service. The TCB does not, and most probably is not,
28 the entire product but rather a specic portion thereof. Any aspect of a product
29 which, if manipulated by an outside entity, would violate the security policy of
30 the product must be considered as part of the TCB.
31 Those aspects which are considered part of the TCB are dened to be within the
32 TCB boundary. The boundary must be dened as the scope of control to which
33 the TCB maintains enforcement of the products security policy. The boundary
34 should include all entities which manipulate or are manipulated by the TCB and
35 that require protection form outside interference.
36 DRAFT 21 March 23, 1993
37 Introduction
1 Introduction
2 Security Policy
There must be an explicit security policy enforced by the product. The security
policy is the set of rules regulating the use of information, including its pro-
3 cessing, storage, distribution and presentation in a product. The security policy
4 must be specied in the manner dened within the targeted assurance level.
5 Isolation,
6 Mediation, &
7 Audit
The purpose of a trusted product is to isolate objects within its control, to
guarantee the mediation of access requests, and to insure a controlled and
noncircumventable audit exists to track information ow within the trusted
product. All security functionality falls within the bounds of one or more of
8 isolation, mediation, or audit.
9 Objects
In the Canadian Criteria everything under the control of the TCB can be termed
an object. Objects can be in one of three states (see Figure 5): user, process, or
10 passive. Entering a given state simply means that the object is viewed by the
11 TCB in a different context. However, an object (be it a user, process or passive
12 object) can be manipulated as an object by other processes.
User
Process
Passive
Object
Manipulate
Activate
Default
13 Figure 5: State Transitions from an Entity to an Object, User, or Process
14 The user state is entered by an object whenever an individual logs into the
15 product. The entity in question is the TCBs image of the user. This is, usually,
16 followed by invocation (or activation) of a process on that users behalf. This
17 process is the true manipulator of the objects within the users domain. Because
18 all entities within a product can be manipulated, and by default are in the passive
19 state, the Criteria sometimes refers to all entities as objects. User objects and
20 process objects are referred to solely as user and process, respectively.
21 Introduction
1 Fundamentals
2 The ow of information between the three types of objects is shown in Figure
3 6 and expanded upon in Appendices E, F, and G.
User Process Object
4 Figure 6: Information Flow Between User, Process, and Object
5 Object Space The object space of a TCB, illustrated in Figures 7 and 8,
6 contains all the objects under the control of the reference monitor. As users
7 log into the product, they are instantiated into a user object within the product.
8 Each user object, user for short, is an object from the viewpoint of the TCB. As
9 users initiate processes, the processes are (possibly) associated with the invoking
10 user. Processes, as do users, remain objects and can be so manipulated within
11 the limits of the security policy.
Object Space
Object Space
User
Instantiations
Process
Instantiations
Non-Instantiated
Objects
Legend:
Reference Monitor
Controlled Accesses
TCB
Boundary
12 Figure 7: Interaction Between TCB Controlled Objects
13 For illustration purposes, Figure 7 presents an active object space. The illus-
14 tration shows two users using a single process, which in turn is manipulating
15 another process as well as a non-instantiated object
8
. But, the gure could be
16 8
A non-instantiated object is simply any other object in the system which has not entered either
17 the user or process states.
18 DRAFT 23 March 23, 1993
19 Introduction
1 Introduction
2 interpreted as the process manipulating other objects in the object space, objects
3 which include the two user objects, the passive object and the other process
4 object.
Object Space
Legend:
Reference Monitor
Controlled Accesses
Object Space
User
Instantiations Process
Instantiations
Non-Instantiated
Objects
jdoe
jqpublic
ruquick
The Real
World
The TCBs
World
Resources
5 Figure 8: Objects and Their Counterparts
6 Figure 8 presents the entire picture. Any given object can be an encapsulator
7 for protected resources. User objects are instantiations within the product of
8 actual users in the real world
9
. And, process objects are those objects which the
9 product is actually executing in some way. Whenever a user logs off or a process
10 terminates execution, they revert to passive objects in the non-instantiated group.
11 The destruction and creation of objects is dened by the vendor and must not
12 contravene any aspects of the security policy. All creation, destruction, and
13 instantiation must be performed by the trusted computing base. All mediation
14 must be performed by the reference monitor
10
.
15 The objects in a product are dened by the vendor and approved by CSE. Objects
16 within a product can range from les to devices to ports to printers. Anything
17 protected under the security policy must be dened as an object. All objects
18 must have unique identifying tags which are to be used by the TCB for isolation,
19 9
These real users can actually be daemons or ghosts, used for autonomous processing.
20 10
If a reference monitor is not used, the vendor must provide sufcient evidence that the chosen
21 method of mediation is capable of enforcing the security policy. The evaluation authority requires
a strong, noncircumventable mechanism capable of providing the mediation services.
22 Introduction
1 Fundamentals
2 mediation, and audit. Objects not protected by the TCB exist outside the TCB
3 boundary are accessible, but are not illustrated in Figures 7 or 8.
4 Tagged Objects The set of rules (in a product) governing the interaction
5 between objects is known as the security policy. Each object is tagged with
6 a unique identier and with further information denoting its access rights and
7 privileges. Tag is a term used to describe any access mediation information
8 associated with users, processes, or objects. The association of a tag with an
9 entity may be explicit or implicit. The tag of an entity is part of its encapsulation
10 by the TCB.
11 The number of tags and identiers associated with an object can be unlimited.
12 As users and processes attempt to access objects, the mediation services
11
can
13 make decisions based on the security policy, by examining the tags, as to the
14 validity of the access requests.
15 With the tags and a security policy, one can design discretionary controls,
16 mandatory controls, integrity controls, and a wide variety of other controls over
17 objects.
18 TCSEC Subjects in the Canadian Criteria The US TCSEC uses the
19 term subjects to dene active objects within a trusted product. In the Canadian
20 Criteria subjects are dened as users, the object invoking the actions, and
21 processes, the object acting on behalf of the user to perform the actions.
22 To a process, everything within the product is an object. A user, for example,
23 is an object that the process reads from and writes to. All processes are owned,
24 have a specic user as initiator, and are controlled by this owner.
25 This splitting of the TCSECs subject into process and user aids in
26 describing exact interactions within the product, especially when describing
27 policy issues at the higher levels of assurance or enhanced accountability and
28 access controls. This division allows for restricted access to passive objects by
29 specic processes, a fundamental requirement of integrity. Modication of an
30 object requires: i) access to the process; and ii) access by the process and the
31 user to passive object.
32 11
One valid implementation of mediation services is a reference monitor (see Appendices C and
33 D.
34 DRAFT 25 March 23, 1993
35 Introduction
1 Introduction
User Process
Object/
Data
Subject
2 Figure 9: Objects in the TCSEC and the Canadian Criteria
3 Figure 9 shows the mapping of the TCSEC denition of a subject to that of the
4 Canadian Criterias user and process. Objects which are to be manipulated are
5 known as objects in both the TCSEC and Canadian Criteria.
6 Continuous
7 Protection
The services that enforce the security policy must be continuously protected
against tampering and/or unauthorized changes. No computer product can be
considered truly secure if the basic software, hardware and rmware mecha-
8 nisms that enforce the security policy are themselves subject to unauthorized
9 modication or subversion.
10 Security Services &
11 Mechanisms
A service is a generic term to dene some form of security functionality that
is offered by a product. Each service can be implemented by one or more
underlying mechanisms, where the mechanisms are product dependent. In
12 other words, a service is an abstraction while the security mechanisms are the
13 implementation of that service within a given product. A given set of security
14 mechanisms can implement more than one service. For example, it is feasible
15 for a vendor to implement both Mandatory, under control of the system, and
16 Discretionary, under control of individual users, Condentiality services with a
17 single set of mechanisms, resulting in ratings for both types of service.
18 The Canadian Criteria list a set of services. The set, although well dened, is
19 not exhaustive. Solutions to security problems not yet envisioned may not be
20 covered by the listed services.
21 Inclusion of
22 New Services
The Canadian Criteria and the associated services described herein are not meant
to be a nal answer to the problems of computer security. Rather, the Canadian
Criteria offer a set of well understood services which can be used to create
23 trusted products which can reect the requirements of the market.
24 The document does not assume to include all possible services that can be
25 foreseen but rather contains those which are known to be good services at time
26 of release. If a given Vendor can show, to the evaluating authoritys satisfaction,
27 that a new or modied form of service provides sufcient protection against a
28 specic type of threat or offers functionality not currently provided in any other
29 Introduction
1 Fundamentals
2 form within the Criteria, then CSE will examine the strength and usefulness
3 of such a service. CSE will indicate to the Vendor whether such a service is
4 appropriate and how the evaluation of the service will be carried out relative
5 to the Criteria.
6 If the service does prove to be generally useful or a general improvement in
7 functionality, then the Criteria Working Group will consider its inclusion in the
8 next revision of the Criteria.
9 Modularity
In dening modularity, one could envision those aspects of the product which
are coded within specic structured programming conventions. However, the
10 Canadian Criteria reference to modularity is in terms of the overall design
11 of the product. The coding or implementation practices (such as structured
12 programming) are assurance issues and are discussed in the Assurance Criteria
13 as well as in Appendix J.
14 For a TCB to be termed modular it would have to be designed into logical
15 groupings of software, hardware, and/or rmware with each grouping perform-
16 ing predened tasks. The strictness of this denition is dependent upon the level
17 of assurance the Vendor is attempting to attain. At the lower levels of assur-
18 ance, modularity can be dened in terms of grouping similar functionality into
19 given source les. At the higher levels, data hiding, encapsulation, and other
20 techniques would be used to ensure that each module performs a single task and
21 that all manipulated objects are either locally dened and accessed or passed via
22 parameters or similar technique.
23 The overall product, which could comprise networks and distributed systems
24 as well as databases, must be modular in the sense that any inter-process
25 communication is only accomplished via known and described channels.
26 Composable
27 Evaluations
With the nature of current products tending towards heavily distributed archi-
tectures, efforts have begun to work out a method of evaluation based on com-
posable products. As research continues, composable evaluations of properly
28 dened composable products will enter the mainstream from the research arena.
29 Composable products and evaluations would allow Vendors to modify existing
30 trusted products and retain or improve their ratings without having the entire
31 product reevaluated.
32 DRAFT 27 March 23, 1993
33 Introduction
1 Covert Channels
2 Condentiality Criteria
3 A product which is rated against the Condentiality Criteria must provide ser-
4 vices capable of protecting resources against unauthorized disclosure. Con-
5 dentiality may be provided in a product through a covert channel analysis, and
6 through the use of discretionary condentiality services, mandatory conden-
7 tiality services, and object reuse services.
8 Covert Channels
9 A covert channel analysis is performed in order to identify those information
10 ows which exist in a product but cannot be controlled through other services.
11 The Covert Channel levels of service rate the services based upon the analysis
12 performed, and on the ability to audit and eliminate covert channels.
13 A general guide to covert channel analysis is found in Appendix F.
14 CC0
15 Non-compliant
This level is reserved for those products which have been evaluated under the
Covert Channel Service and have failed to meet the requirements of a higher
level of service.
16 CC1
17 Covert Channel
18 Analysis
A covert channel analysis shall be conducted. Each identied hardware,
rmware and software covert channel shall be documented.
The maximum bandwidth (determined by actual measurement or by engineering
estimation) of each identied covert channel shall be documented.
19 Identied covert channels which can be used in aggregate shall have their
20 aggregate bandwidth documented.
21 CONSTRAINT: CR-1, T-3
22 CC2
23 Auditable Covert
24 Channels
The maximum bandwidth (determined by actual measurement or by engineering
estimation) of each identied covert channel shall be documented.
25 Identied covert channels which can be used in aggregate shall have their
26 aggregate bandwidth documented.
27 The TCB shall be able to audit an approved subset of the identied covert
28 channels.
29 DRAFT 29 March 23, 1993
2 CONSTRAINT: CR-1, WA-1, T-3
3 CC3
4 Elimination of Covert
5 Channels
Each identied covert channel shall be eliminated from the product.
6 CONSTRAINT: CR-1, T-3
7 Discretionary Condentiality
8 Discretionary condentiality services allow authorized users to control the ow
9 of information within from protected objects to users a product. The Discre-
10 tionary Condentiality levels of service rate these services based on the strength
11 of the mechanism and their granularity of control.
12 Appendix E and Appendix F provide guidance on meeting the discretionary
13 condentiality criteria.
14 CD0
15 Non-compliant
Discretionary Condentiality service and have failed to meet the requirements
of a higher level of service.
16 CD1
17 Minimal Discretionary
18 Condentiality
The TCB shall enforce an approved discretionary condentiality policy to protect
against information disclosure. The approved policy shall dene the set of the
products objects to which it applies.
Access mediation by the TCB shall be based upon the tag of the process and
19 the tag of the protected object.
20 Requests for changes to access mediation information shall be serviced by the
21 TCB based upon the user tag of the requesting user or process.
22 Access mediation information shall be associated with each protected object
23 upon creation or initialization.
24 Rules for preserving the tags of protected objects during their export/import shall
25 be provided as part of the discretionary condentiality policy.
26 CONSTRAINT: CR-1, WI-1
1 Discretionary Condentiality
2 CD2
3 Basic Discretionary
4 Condentiality
5 Access mediation by the TCB shall be based upon the tag of the user and the
6 tag of the protected object.
7 The discretionary condentiality policy shall provide a partial representa-
8 tion of the access matrix of all user tags and protected object tags.
16 CD3
17 Controlled
18 Discretionary
19 Condentiality
Access mediation by the TCB shall be based upon the tag of the user and the
21 The discretionary condentiality policy shall provide a full representation of the
22 access matrix of all user tags and protected object tags.
30 DRAFT 31 March 23, 1993
2 CD4
3 Advanced
4 Discretionary
5 Condentiality
Access mediation by the TCB shall be based upon the tag of the user, the tag
of the process and the tag of the protected object.
6 The discretionary condentiality policy shall provide a full representation of the
7 access matrix of all user tags, process tags and protected object tags.
15 Mandatory Condentiality
16 Mandatory condentiality services allow an authorized administrator or user to
17 control the ow of information from protected objects to users within a product.
18 The Mandatory Condentiality levels of service rate these services based on the
19 extent and strength of control.
20 A general guide to mandatory condentiality is found in Appendix E and
21 Appendix F.
22 CM0
23 Non-compliant
Mandatory Condentiality service and have failed to meet the requirements of
a higher level of service.
24 CM1
25 Minimal Mandatory
26 Condentiality
The TCB shall enforce an approved mandatory condentiality policy to protect
Access mediation by the TCB shall be based upon the tag of the process and
28 Requests for changes to access mediation information shall only be serviced by
29 the TCB for administrators and users to whom the required authority has been
30 delegated.
1 Mandatory Condentiality
3 be provided as part of the mandatory condentiality policy.
4 CONSTRAINT: CR-1, IS-1
5 CM2
6 Basic Mandatory
7 Condentiality
12 delegated.
17 CONSTRAINT: CR-1, IS-1, WI-1
18 CM3
19 Controlled Mandatory
20 Condentiality
against information disclosure. The approved policy shall apply to all of the
products objects.
25 delegated.
31 DRAFT 33 March 23, 1993
2 CM4
3 Advanced Mandatory
4 Condentiality
against information disclosure. The approved policy shall apply to all of
products objects.
Access mediation by the TCB shall be based upon the tag of the user, the tag
5 of the process and the tag of the protected object.
8 delegated.
14 Object Reuse
15 The Object Reuse service provides for the proper reuse of shared storage objects.
16 Object reuse involves ensuring that when a shared object is reassigned or
17 reallocated to a user or process that no information remains in the shared object
18 from a previous user or process.
19 CR0
20 Non-compliant
Object Reuse service and have failed to meet the requirements of a higher level
of service.
21 CR1
22 Object Reuse
The TCB shall enforce an approved object reuse policy. The approved policy
shall apply to all of products shared objects.
23 All previous authorization and access to a protected object shall be revoked
24 prior to reassignment or reallocation.
25 All previous information content of a protected object shall be made unavailable
26 prior to reassignment or reallocation.
27 CONSTRAINT: None.
1 Discretionary Integrity
2 Integrity Criteria
3 A product which is rated against the Integrity Criteria must provide services
4 capable of providing information integrity or product integrity. Integrity may
5 be provided in a product through the use of discretionary integrity services,
6 mandatory integrity services, physical integrity services, rollback services, self
7 test services and separation of duties services.
9 Discretionary integrity services allow authorized users to control the ow of
10 information from users to protected objects within a product. The Discretionary
11 Integrity levels of service rate these services based on the strength of the
12 mechanism and the granularity of control.
13 Appendix E and Appendix G provide guidance on meeting the discretionary
14 integrity criteria.
15 ID0
16 Non-compliant
Discretionary Integrity service and have failed to meet the requirements of a
higher level of service.
17 ID1
18 Minimal Discretionary
19 Integrity
The TCB shall enforce an approved discretionary integrity policy to protect
against information modication. The approved policy shall dene the set of
the products objects to which it applies.
27 be provided as part of the discretionary integrity policy.
29 DRAFT 35 March 23, 1993
2 ID2
3 Basic Discretionary
4 Integrity
5 Access mediation by the TCB shall be based upon the tag of the process and
7 The discretionary integrity policy shall provide a partial representation of
8 the access matrix of all process tags and protected object tags.
16 ID3
17 Controlled
21 The discretionary integrity policy shall provide a full representation of the access
22 matrix of all process tags and protected object tags.
1 Mandatory Integrity
2 ID4
3 Advanced
Access mediation by the TCB shall be based upon the tag of the process, the
5 tag of the user and the tag of the protected object.
6 The discretionary integrity policy shall provide a full representation of the access
7 matrix of all user tags, process tags and protected object tags.
15 Mandatory Integrity
16 Mandatory integrity services allow an administrator or authorized user to control
17 the ow of information from users to protected objects within a product. The
18 Mandatory Integrity levels of service rate these services based on the extent and
19 strength of control over product objects.
20 A general guide to mandatory integrity is found in Appendix E and Appendix G.
21 IM0
22 Non-compliant
Mandatory Integrity service and have failed to meet the requirements of a higher
level of service.
23 IM1
24 Minimal Mandatory
25 Integrity
The TCB shall enforce an approved mandatory integrity policy to protect against
information modication. The approved policy shall dene the set of the
Access mediation by the TCB shall be based upon the tag of the user and the
29 delegated.
32 DRAFT 37 March 23, 1993
3 be provided as part of the mandatory integrity policy.
5 IM2
6 Basic Mandatory
7 Integrity
information modication. The approved policy shall dene the set of the
12 delegated.
18 IM3
19 Complete Mandatory
20 Integrity
information modication. The approved policy shall apply to all of the prod-
ucts objects.
25 delegated.
1 Physical Integrity
2 IM4
3 Advanced Mandatory
4 Integrity
information modication. The approved policy shall apply to all of products
objects.
5 Access mediation by the TCB shall be based upon the tag of the process, the
6 tag of the user and the tag of the protected object.
9 delegated.
15 Physical Integrity
16 Physical integrity denes the physical perimeter of the TCB and provides
17 services for the physical protection of the components within that boundary.
18 These services are used to indicate or restrict unauthorized physical access
19 to the internals of the product and to deter unauthorized use, modication or
20 substitution of the protected components. The Physical Integrity levels of service
21 rate these services based on the type of protection provided, and the degree of
22 effort required to defeat it.
23 IP0
24 Non-compliant
Physical Integrity service and have failed to meet the requirements of a higher
level of service.
25 IP1
26 Basic Physical Integrity
The TCB shall enforce an approved physical integrity policy. The policy shall
include a description of the physical perimeter of the TCB and shall dene the
set of the products components to which it applies.
27 The physical perimeter shall be protected by tamper evident mechanisms such
28 that unauthorized use of, physical access to, or physical modication of the
29 protected components will be detected after the unauthorized attempt.
31 DRAFT 39 March 23, 1993
2 IP2
3 Intermediate Physical
4 Integrity
The physical perimeter shall be protected by tamper resistant mechanisms such
6 protected components will be unsuccessful.
7 Covers and openings through the physical perimeter shall be protected by
8 tamper response mechanisms such that unauthorized use of, physical access
9 to, or physical modication of the protected components will be detected
10 during the unauthorized attempt.
12 IP3
13 Advanced Physical
14 Integrity
The physical perimeter shall be protected by tamper resistant mechanisms such
16 protected components will be unsuccessful.
17 Covers and openings through the physical perimeter shall be protected by tamper
18 response mechanisms such that unauthorized use of, physical access to, or
19 physical modication of the protected components will be detected during the
20 unauthorized attempt.
21 All components within the physical perimeter shall be protected against
22 failure due to extreme environmental conditions.
24 IP4
25 Complete Physical
26 Integrity
All components within the physical perimeter shall be protected by tamper
27 resistant mechanisms such that unauthorized use of, physical access to, or
28 physical modication of the protected components will be unsuccessful.
29 All components within the physical perimeter shall be protected by tamper
30 response mechanisms such that unauthorized use of, physical access to, or
31 physical modication of the protected components will be detected during the
32 unauthorized attempt.
33 All components within the physical perimeter shall be protected against failure
34 due to extreme environmental conditions.
1 Rollback
2 CONSTRAINT: None.
3 Rollback
4 Rollback services provide the ability to undo an action or a series of actions
5 and return a protected object to a previous state. The Rollback levels of service
6 rate these services based on the granularity of objects and operations which can
7 be rolled back.
8 IR0
9 Non-compliant
Rollback service and have failed to meet the requirements of a higher level of
service.
10 IR1
11 Restricted Rollback
The TCB shall enforce an approved rollback policy. The approved policy shall
dene the set of the products objects to which it applies.
12 The policy shall provide an automated means to allow authorized users or
13 processes to rollback, or undo, a dened set of operations on protected objects
14 over a predened period of time.
15 CONSTRAINT: WI-1
16 IR2
17 Advanced Rollback
The TCB shall enforce an approved rollback policy. The approved policy shall
dene the set of the products objects to which it applies.
18 The policy shall an automated means to allow authorized users or processes to
19 rollback, or undo, all operations on protected objects over a predened period
20 of time.
21 CONSTRAINT: WI-1
22 DRAFT 41 March 23, 1993
2 Separation of Duties
3 Separation of duties services provide for the compartmentalization of responsi-
4 bility and reduces the potential damage from a corrupt user or administrator and
5 places limits on the authority of the user or administrator. The Separation of
6 Duties levels of service rate these services based on the granularity of separation
7 between users and administrative responsibilities.
8 IS0
9 Non-compliant
Separation of Duties service and have failed to meet the requirements of a
higher level of service.
10 IS1
11 Basic Separation
12 of Duties
The TCB shall enforce an approved separation of duties policy. The policy
shall identify administrative and nonadministrative user roles and their respective
functions.
The policy shall dene an explicit user action required to be performed before
13 a user can assume a role that they are authorized for.
14 CONSTRAINT: WI-1
15 IS2
16 Administrative
functions.
19 The policy shall dene at least two distinct administrative roles: a security
20 administrator and non-security administrator.
21 The functions assigned to each administrative role shall be minimized to
22 include only those functions required for the performance of that role.
23 CONSTRAINT: WI-1
24 IS3
25 Privilege-based
functions.
28 The policy shall dene at least two distinct administrative roles: a security
29 administrator and non-security administrator.
1 Self Testing
2 The functions assigned to each administrative role shall be minimized to include
3 only those functions required for the performance of that role.
4 The policy shall dene multiple distinct user roles.
5 CONSTRAINT: WI-1
6 Self Testing
7 Self testing services allow the TCB to ensure correct operation and integrity for
8 dened product functions. The Self Testing levels of service rate these services
9 based on the ability of the mechanism to provide timely reports of incorrectly
10 functioning product components.
11 IT0
12 Non-compliant
Self Testing service and have failed to meet the requirements of a higher level
of service.
13 IT1
14 Basic Self Testing
The TCB shall enforce an approved self testing policy. The policy shall describe
the product features that can be used to periodically validate the correct operation
of the TCB.
15 The coverage and use of the tests shall be described in the Trusted Facility
16 Manual.
18 IT2
19 Intermediate Self
20 Testing
of the TCB.
21 The TCB shall run a suite of self tests during initial start-up in order to
22 validate the correct operation of its critical functions.
24 Manual.
26 DRAFT 43 March 23, 1993
2 IT3
3 Advanced Self Testing
of the TCB.
4 The TCB shall run a suite of self tests during initial start-up and during normal
5 product operation in order to validate the correct operation of its critical
6 functions.
8 Manual.
9 CONSTRAINT: None.
1 Containment
2 Availability Criteria
3 A product which is rated against the Availability Criteria must provide services
4 capable of controlling the availability of a product. Availability may be provided
5 in a product through the use of containment services, fault tolerance services,
6 robustness services, and recovery services.
7 Containment
8 Containment services allow the TCB to control the use of services and resources
9 by users. The Containment levels of service are based upon the extent and
10 strength of control exerted over the availability of the product services.
11 AC0
12 Non-compliant
Containment service and have failed to meet the requirements of a higher level
of service.
13 AC1
14 Quotas
The TCB shall enforce an approved containment policy. The policy shall dene
the set of the products objects and the capability to place limits on the allocation
to users of these objects.
15 Requests for changes to assigned limits shall only be serviced by the TCB for
16 administrators and users to whom the required authority has been delegated.
17 CONSTRAINT: IS-1
18 AC2
19 Denial of Service
the capability to place limits on the allocation to users of all of the products
objects.
22 Limits shall be able to be set such that the TCB can prevent any single user
23 from being able to deny other users access to TCB functions or protected
24 objects.
25 CONSTRAINT: IS-1
26 DRAFT 45 March 23, 1993
2 AC3
3 Resource Restrictions
the capability to place limits on the allocation to users and to congurable
groups of users of all of the products objects.
6 Limits shall be able to be set such that the TCB can prevent any single user
7 or congurable group of users from being able to deny other users access to
8 TCB functions or protected objects.
9 CONSTRAINT: IS-1
10 Fault Tolerance
11 Fault Tolerance services allow the TCB to ensure availability of the product after
12 component failures. The Fault Tolerance levels of service rate these services
13 based on the ability to have components replaced without discontinuing serivce.
14 AF0
15 Non-compliant
Fault Tolerance service and have failed to meet the requirements of a higher
level of service.
16 AF1
17 Limited Hot
18 Replacement
The vendor shall conduct a component failure analysis study for the product.
The TCB shall enforce an approved fault tolerance policy. The policy shall
dene the set of the products components which can be replaced without
incurring a service discontinuity.
19 An administrator, or users to whom the required authority has been delegated,
20 shall be able to replace any protected component.
21 CONSTRAINT: IS-1, AR-1
22 AF2
23 Hot Replacement
The TCB shall enforce an approved fault tolerance policy. The policy shall
24 apply to all of the products components and shall allow their replacement
25 without incurring a service discontinuity.
26 An administrator, or users to whom the required authority has been delegated,
27 shall be able to replace any protected component.
28 CONSTRAINT: IS-1, AR-1
1 Robustness
2 Robustness
3 Robustness services allow the TCB to ensure availability of the product after
4 component failures. The Robustness levels of service rate these services based
5 on the ability of the TCB to continue operating based upon the number of failures
6 and the service available after a failure.
7 AR0
8 Non-compliant
Robustness service and have failed to meet the requirements of a higher level
of service.
9 AR1
10 Reliability under
11 Limited Failure
The TCB shall enforce an approved robustness policy. The policy shall dene
the set of the products components and those components modes of failure
12 after which the product can continue operation.
13 Failure of any single protected component shall not result in loss of all service
14 but instead result in, at worst, a degraded mode of operation.
15 Thresholds at which failures will result in degraded service or loss of service
16 shall be clearly identied.
17 The product shall be capable of notifying an administrator of the failure of any
18 protected component.
19 CONSTRAINT: IS-1
20 AR2
21 Reliability with
22 Degraded Service
The TCB shall enforce an approved robustness policy. The policy shall apply
to all of the products components.
23 Failure of any single protected component shall not result in loss of all service
24 but instead result in, at worst, a degraded mode of operation.
29 CONSTRAINT: IS-1
30 DRAFT 47 March 23, 1993
2 AR3
3 Reliability with Full
4 Service
The TCB shall enforce an approved robustness policy. The policy shall apply
to all of the products components.
5 Failure of any single protected component shall not result in a loss of service
6 or service degradation.
11 CONSTRAINT: IS-1
12 Recovery
13 Recovery services allow the TCB to return to a known trusted state after a
14 product failure or service discontinuity. The Recovery levels of service rate
15 these services based on the degree of automation associated with the trusted
16 recovery.
17 AY0
18 Non-compliant
Recovery service and have failed to meet the requirements of a higher level
of service.
19 AY1
20 Manual Recovery
The TCB shall enforce an approved recovery policy. The policy shall dene
the product failures and service discontinuities from which recovery is possible
in a trusted manner.
21 After a product failures or service discontinuity, the TCB shall enter a state
22 where only administrators, and users to whom the required authority has been
23 delegated, are capable of returning the product to normal operation.
24 Manual procedures shall be provided by which the product can be returned to
25 normal operation in a trusted manner.
26 Thresholds at which discontinuities require that the product be re-installed shall
27 be identied.
28 CONSTRAINT: IS-1
1 Recovery
2 AY2
3 Automated Recovery
4 After a product failures or service discontinuity, the TCB shall be able to
5 determine whether its automated procedures can be used to return the
6 product to normal operation in a trusted manner.
7 If the automated means can be used, the TCB shall be able to perform the
8 necessary procedures and return the product to normal operation.
9 If automated recovery is not used, the TCB shall enter a state where only
10 administrators, and users to whom the required authority has been delegated, are
11 capable of returning the product to normal operation.
12 Manual procedures shall be provided by which the product can be returned to
13 normal operation in a trusted manner.
14 Thresholds at which discontinuities require that the product be re-installed shall
15 be identied.
16 CONSTRAINT: IS-1
17 AY3
18 Selective Recovery
19 After any service discontinuity, or product failure not requiring re-
20 installation or component replacement, the TCB shall be able to perform
21 automated recovery in a trusted manner to, at worst, a degraded mode of
22 operation.
23 If automated recovery is not used, the TCB shall enter a state where only
24 administrators, and users to whom the required authority has been delegated,
25 are capable of returning the product to normal operation.
26 Manual procedures shall be provided by which the product can be returned
27 to normal operation from a degraded mode of operation in a trusted
28 manner.
29 Thresholds at which service discontinuities require that the product be re-
30 installed shall be identied.
31 CONSTRAINT: IS-1
32 DRAFT 49 March 23, 1993
1 Audit
2 Accountability Criteria
3 A product which is rated against the Accountability Criteria must provide ser-
4 vices capable of attributing responsibility for an action to a user. Accountability
5 may be provided in a product through the use of audit services, identication &
6 authentication services, and trusted path services.
7 Audit
8 Audit services allow the monitoring of potentially suspicious activity on the
9 product. The Audit levels of service rate the service based on the granularity of
10 auditing, the complexity of audit analysis tools and the ability to detect potential
11 violations.
12 Appendix I provides guidance on audit trail content.
13 WA0
14 Non-compliant
This level is reserved for those product which have been evaluated under the
Audit service and have failed to meet the requirements of a higher level of
service.
15 WA1
16 External Audit
The TCB shall enforce an approved audit policy. The policy shall dene the set
of auditable events that can be included in the audit trail.
17 The TCB shall be able to perform basic auditing of security relevant events and
18 shall be capable of providing the audit trail, via some protected mechanism, to
19 another product or system.
20 The audit trail shall contain information pertaining to the date, time, location,
21 type and success or failure of each audited event.
22 The audit trail shall contain sufcient information to recover the identity of the
23 users, processes and/or objects involved in each audited event.
24 CONSTRAINT: WI-1
25 DRAFT 51 March 23, 1993
2 WA2
3 Security Audit
4 The TCB shall be able to perform basic auditing of security relevant events
5 and shall maintain and protect the audit trail from unauthorized access,
6 modication or destruction.
11 Audit review tools shall be available to administrators, and users to whom
12 the required authority has been delegated, to assist in the inspection of the
13 audit trail.
14 CONSTRAINT: IS-1, WI-1
15 WA3
16 Security Audit & Alarm
17 The TCB shall be able to perform basic auditing of security relevant events and
18 shall maintain and protect the audit trail from unauthorized access, modication
19 or destruction.
24 Audit review tools shall be available to administrators, and users to whom the
25 required authority has been delegated, to assist in the inspection of the audit trail.
26 The TCB shall be able to monitor the occurrence or accumulation of
27 auditable events that may indicate an imminent violation of the products
28 security policy.
29 The TCB shall be able to immediately notify the administrator when thresh-
30 olds are exceeded and, if the occurrence or accumulation of monitored se-
31 curity relevant events continues, the TCB shall be able to take the least
32 disruptive action to terminate the recurrence of these events.
1 Audit
2 WA4
3 Detailed Audit
4 The TCB shall be able to perform detailed auditing of security relevant events
5 and shall maintain and protect the audit trail from unauthorized access, modi-
6 cation or destruction.
11 Audit analysis tools shall be available to administrators, and users to whom the
12 required authority has been delegated, to assist in the analysis of the audit trail.
13 The TCB shall be able to monitor the occurrence or accumulation of auditable
14 events that may indicate an imminent violation of the products security policy.
15 The TCB shall be able to immediately notify the administrator when thresholds
16 are exceeded and, if the occurrence or accumulation of monitored security
17 relevant events continues, the TCB shall be able to take the least disruptive
18 action to terminate the recurrence of these events.
20 WA5
21 Advanced Detection
22 The TCB shall be able to perform detailed auditing of security relevant events
23 and shall maintain and protect the audit trail from unauthorized access, modi-
24 cation or destruction.
29 Audit analysis tools shall be available to administrators, and users to whom the
30 required authority has been delegated, to assist in the analysis of the audit trail.
31 The TCB shall be able to monitor the occurrence or accumulation of auditable
32 events that may indicate an imminent violation of the products security policy.
33 The TCB shall be able to immediately notify the administrator when thresholds
34 are exceeded and, if the occurrence or accumulation of monitored security
35 relevant events continues, the TCB shall be able to take the least disruptive
36 action to terminate the recurrence of these events.
37 DRAFT 53 March 23, 1993
2 The TCB shall be able to perform real-time intrusion detection analysis in
3 support of the products security policy.
5 Identication and Authentication
6 Identication and Authentication services allow the TCB to verify the identity
7 of individuals attempting access to the product. The Identication and Au-
8 thentication levels of service rate these services based the number of approved
9 authentication mechanisms available.
10 Appendix I provides guidance on identication and authentication mechanisms,
11 and distinguishes between acceptable means of authentication.
12 WI0
13 Non-compliant
Identication and Authentication service and have failed to meet the require-
ments of a higher level of service.
14 WI-1
15 External I&A
The TCB shall enforce an approved identication and authentication policy.
The policy shall identify the attributes to be associated with a user and the other
product services to which these attributes will be provided.
16 Each user shall be uniquely identied to the TCB.
17 The TCB shall use a protected mechanism to receive the authenticated user
18 identity from some external source before allowing that user to perform any
19 other TCB-mediated action.
20 CONSTRAINT: None
21 WI2
22 Individual I&A
24 The TCB shall use a protected mechanism to authenticate each user before
25 allowing that user to perform any other TCB-mediated action.
26 The TCB shall protect authentication data from unauthorized users.
1 Trusted Path
2 WI3
3 Multiple I&A
5 The TCB shall use two or more different types of protected mechanisms to
6 authenticate each user before allowing that user to perform any other TCB-
7 mediated action.
8 The TCB shall protect authentication data from unauthorized users.
9 CONSTRAINT: None.
10 Trusted Path
11 Trusted path services provide the ability to ensure users direct communication
12 with the TCB. The Trusted Path levels of service rate these services based on
13 their exibility in allowing the TCB or the user to initiate trusted exchanges.
14 WT0
15 Non-compliant
This level is reserved for those product which have been evaluated under the
Trusted Path service and have failed to meet the requirements of a higher level
of service.
16 WT1
17 Basic Trusted Path
The TCB shall enforce an approved trusted path policy. The policy shall dene
a mechanism for creating a trusted communication path between the user and
the TCB.
18 The trusted path shall be used for initial identication and authentication.
19 Communications via this path shall be initiated exclusively by the user.
20 CONSTRAINT: WI-2
21 WT2
22 Advanced Trusted Path
The TCB shall enforce an approved trusted path policy. The policy shall dene
a mechanism for creating a trusted communication path between the user and
the TCB.
23 The trusted path shall be used for initial identication and authentication, and at
24 other times when direct user-TCB or TCB-user communication is required.
25 Trusted path exchanges originating from the TCB shall be uniquely identi-
26 able as such, and shall require positive conrmation from the user.
27 CONSTRAINT: WI-2
28 DRAFT 55 March 23, 1993
1 T-0 Non Compliant
2 Assurance Criteria
3 Each evaluated product must be rated against the Assurance Criteria to assess
4 the level of trust which may be placed in it. The Assurance Criteria include re-
5 quirements for Architecture, Development Environment, Development Evidence,
6 Operational Enviroment, Security Manuals and Security Testing.
7 Appendix J provides guidance on meeting the Assurance Criteria requirements,
8 and discusses assurance issues involved in the design, implementation, and
9 evaluation of trusted products.
10 T-0 Non Compliant
11 This level is reserved for those products that have been evaluated under the
12 Assurance criteria but have failed to meet the requirements for a higher level.
13 DRAFT 57 March 23, 1993
1 Assurance Level T-1
3 Architecture
All TCB elements shall be identied.
4 The TCB shall enforce the products security policy.
5 The TCB shall maintain a domain for its own execution that protects it from
6 external interference and tampering.
7 Access to any resource under the control of the TCB shall only occur through
8 the TCB interface.
9 Development
10 Environment
Life Cycle Process.
The Vendor shall state the development methodology used during the life cycle
11 of the product.
12 Conguration Management.
13 A conguration management system shall be in place during the entire life cycle
14 of the product, and shall maintain control of changes to all hardware, rmware,
15 source code, object code, test suites, and documentation.
16 The conguration management system shall assure a consistent mapping among
17 all documentation and code associated with the current version of the TCB.
18 Development
19 Evidence
Functional Specication.
The Vendor shall provide a functional specication for the product.
20 The functional specication shall include the informal security policy enforced
21 by the TCB. The security policy shall state the security services provided by
22 the TCB.
23 Architectural Design.
24 The Vendor shall provide an informal architectural design of the product.
25 The architectural design shall state the general structure of the product and shall
26 identify the products security enforcing functions.
27 The TCBs external interfaces shall be stated.
28 Any security services provided by the underlying hardware, rmware, or other
29 software, to the product under evaluation shall be stated.
30 DRAFT 59 March 23, 1993
2 Detailed Design.
3 The Vendor shall provide an informal detailed design of the product.
4 The detailed design shall identify all security mechanisms within the TCB and
5 shall state specically how each security mechanism functions.
6 The interfaces between all TCB modules shall be documented stating their
7 purpose and parameters.
8 The Vendor shall trace the complete mapping between the security policy and
9 the detailed design.
10 Operational
11 Environment
The Vendor shall provide a means for the secure installation, generation and
start-up of the product.
The Vendor shall identify all conguration options which may be used during
12 secure installation, generation and start-up of the product.
13 Security
14 Manuals
Security Features Users Guide.
The Vendor shall provide a Security Features Users Guide in the form of a
15 single summary, chapter, or manual in user documentation which describes the
16 products security services and provides guidelines on their use by nonadmin-
17 istrative users.
18 The Security Features Users Guide shall describe the interaction between
19 security services.
20 Trusted Facility Manual.
21 The Vendor shall provide a Trusted Facility Manual intended for the product
22 administrator which describes the proper administration of the products security
23 services.
24 The Trusted Facility Manual shall describe the administrative interaction between
26 The Trusted Facility Manual shall describe the means for the secure installation,
27 generation and start-up of the product.
28 The Trusted Facility Manual shall describe all conguration options which may
29 be used during secure installation, generation and start-up of the product.
30 The Trusted Facility Manual shall not be included in nonadministrative user
31 documentation.
2 Security Testing
The Vendor shall provide a security test plan to the Evaluation Team. The
security test plan shall describe the philosophy and approach taken by the Vendor
3 to test all of the security services provided and enforced by the TCB. The test
4 coverage shall also be included and justied.
5 The Vendor shall provide evidence of security testing to the Evaluation Team in
6 the form of a detailed set of security test procedures and corresponding security
7 test results. This evidence must be provided in sufcient detail to allow the
8 Vendors security testing to be duplicated by the Evaluation Team.
3 Architecture
9 The TCB shall maintain process isolation.
10 Development
11 Environment
Life Cycle Process.
The Vendor shall describe the development methodology used during the life
cycle of the product.
18 Development
19 Evidence
21 by the TCB. The security policy shall describe the security services provided
22 by the TCB.
23 The functional specication shall also include an informal security policy
24 model.
25 The Vendor shall trace the complete mapping between the security policy
26 model and the security policy. The trace shall show that the security policy
27 model is sufcient to enforce the security policy.
29 The Vendor shall provide an informal architectural design of the product.
30 The architectural design shall describe the general structure of the product and
31 shall identify the products security enforcing functions.
32 The TCBs external interfaces shall be described.
33 DRAFT 63 March 23, 1993
3 software, to the product under evaluation shall be described.
4 The Vendor shall trace the complete mapping between the security policy
5 model and the architectural design.
6 Detailed Design.
7 The Vendor shall provide an informal detailed design of the product.
9 shall describe specically how each security mechanism functions.
12 The Vendor shall trace the complete mapping between the security policy model
13 and the detailed design.
14 Operational
15 Environment
The Vendor shall provide a means for the secure installation, generation and
start-up of the product.
The Vendor shall identify all conguration options which may be used during
17 Security
18 Manuals
single summary, chapter, or manual in user documentation which describes the
20 istrative users.
26 services.
34 documentation.
2 Security Testing
9 The Vendor shall remove or neutralize all identied aws, and the TCB shall
10 be tested again to ensure that the identied aws have been eliminated and
11 that new aws have not been introduced.
12 DRAFT 65 March 23, 1993
3 Architecture
7 The TCB shall use any protection mechanisms available in the under-
8 lying abstract machine to separate protection-critical elements from non
9 protection-critical elements.
13 The TCB shall be internally structured into well-dened largely independent
14 modules. Each module shall be designed such that the principle of least
15 privilege is enforced.
16 Development
17 Environment
Life Cycle Process.
The Vendor shall describe the life cycle process used during the development
18 of the product.
19 The Vendor shall describe coding standards to be followed during the
20 implementation of the product and shall ensure that all source code complies
21 with these standards.
22 Any programming languages used for implementation shall be well-dened.
23 Any implementation dependent options of the programming language or
24 compilers shall be documented.
31 DRAFT 67 March 23, 1993
2 Development
3 Evidence
6 by the TCB.
7 The functional specication shall also include a semiformal security policy
8 model.
10 and the security policy. The trace shall show that the security policy model is
11 sufcient to enforce the security policy.
13 The Vendor shall provide a semiformal architectural design of the product.
16 The TCBs external interfaces shall be described.
20 and the architectural design.
21 Detailed Design.
22 The Vendor shall provide a semiformal detailed design of the product.
28 and the detailed design. The Vendor shall also trace the complete mapping
29 between the detailed design and the TCB implementation.
2 Operational
3 Environment
A combination of technical, procedural or physical safeguards shall exist
for ensuring that the TCB software and rmware distributed to a customer
are exactly as specied by the master copies.
4 The Vendor shall provide a means for the secure installation, generation and
5 start-up of the product.
6 The Vendor shall identify all conguration options which may be used during
8 Security
9 Manuals
11 istrative users.
17 services.
25 documentation.
26 Security Testing
33 The Vendor shall remove or neutralize all identied aws, and the TCB shall
34 be tested again to ensure that the identied aws have been eliminated and that
35 new aws have not been introduced.
36 DRAFT 69 March 23, 1993
3 Architecture
7 Protection mechanisms shall be available in the underlying abstract ma-
8 chine. The TCB shall use these protection mechanisms to separate
9 protection-critical elements from non protection-critical elements.
14 modules. Each module shall be designed such that the principle of least privilege
15 is enforced.
16 Development
17 Environment
Life Cycle Process.
of the product.
18 The Vendor shall describe coding standards to be followed during the imple-
19 mentation of the product and shall ensure that all source code complies with
20 these standards.
21 Any programming languages used for implementation shall be well-dened. Any
22 implementation dependent options of the programming language or compilers
23 shall be documented.
24 Physical, procedural, personnel, and other security measures used by the
25 Vendor to protect the product and its documentation shall be described.
27 A tool based conguration management system shall be in place during the
28 entire life cycle of the product, and shall maintain control of changes to all
29 hardware, rmware, source code, object code, test suites, and documentation.
32 The conguration management system shall provide for the generation of
33 the TCB from source code, and shall provide for the comparison of TCB
34 versions in order to ascertain all changes.
35 DRAFT 71 March 23, 1993
2 The conguration management system shall be capable of tracing problem
3 reports and affected conguration items to problem resolution.
4 Development
5 Evidence
8 by the TCB.
9 The functional specication shall also include a formal security policy model.
10 The Vendor shall demonstrate the complete mapping between the security policy
11 model and the security policy. The demonstration shall show that the security
12 policy model is sufcient to enforce the security policy.
17 The TCBs external interfaces shall be described in terms of exceptions, error
18 messages, and effects.
23 Detailed Design.
29 The Vendor shall trace the complete mapping between the architectural design
2 Operational
3 Environment
A combination of technical, procedural or physical safeguards shall exist for
ensuring that the TCB software and rmware distributed to a customer are
exactly as specied by the master copies.
8 Security
9 Manuals
11 istrative users.
12 The Security Features Users Guide shall the describe interaction between
17 services.
25 documentation.
26 Security Testing
33 The Vendor shall correct all identied aws, and the TCB shall be tested again
34 to ensure that the identied aws have been eliminated and that new aws have
35 not been introduced.
36 DRAFT 73 March 23, 1993
2 The TCB shall be found relatively resistant to penetration by the Vendor.
3 The Vendor shall demonstrate that the TCB implementation is consistent
4 with the Detailed Design.
3 Architecture
7 Protection mechanisms shall be available in the underlying abstract machine.
8 The TCB shall use these protection mechanisms to separate protection-critical
9 elements from non protection-critical elements.
15 is enforced. An effort shall be made by the Vendor to exclude modules from
16 the TCB which are not protection-critical. Rationale for the inclusion of
17 any protection-irrelevant elements in the TCB shall be provided.
18 Signicant software engineering shall be directed toward minimizing the
19 complexity of the TCB. The TCB shall be designed and structured to
20 use a complete, conceptually simple protection mechanism with precisely
21 dened semantics. This mechanism shall play a central role in enforcing the
22 internal structuring of the TCB and the product. The TCB shall incorporate
23 signicant use of layering, abstraction and data hiding.
24 Development
25 Environment
Life Cycle Process.
26 of the product.
29 these standards.
33 Physical, procedural, personnel, and other security measures used by the Vendor
34 to protect the product and its documentation shall be described.
35 DRAFT 75 March 23, 1993
3 A tool based conguration management system shall be in place during the entire
4 life cycle of the product, and shall maintain control of changes to all hardware,
5 rmware, source code, object code, test suites, and documentation.
8 The conguration management system shall provide for the generation of the
9 TCB from source code, and shall provide for the comparison of TCB versions
10 in order to ascertain all changes.
13 Development
14 Evidence
17 by the TCB.
24 The architectural design shall explain the general structure of the product and
26 The TCBs external interfaces shall be explained in terms of exceptions, error
29 software, to the product under evaluation shall be explained.
31 model and the architectural design.
2 Detailed Design.
5 shall explain specically how each security mechanism functions.
8 The Vendor shall trace the complete mapping between the architectural design
11 Operational
12 Environment
A combination of technical, procedural or physical safeguards shall exist for
ensuring that the TCB software and rmware distributed to a customer are
exactly as specied by the master copies.
17 Security
18 Manuals
20 istrative users.
26 services.
34 documentation.
35 DRAFT 77 March 23, 1993
2 Security Testing
12 The TCB shall be found resistant to penetration by the Vendor.
13 No design aws and no more than a few correctable implementation aws
14 may be found during testing.
15 The Vendor shall demonstrate that the TCB implementation is consistent with
16 the Detailed Design.
3 Architecture
16 the TCB which are not protection-critical. Rationale for the inclusion of any
17 protection-irrelevant elements in the TCB shall be provided.
18 Signicant software engineering shall be directed toward minimizing the com-
19 plexity of the TCB. The TCB shall be designed and structured to use a com-
20 plete, conceptually simple protection mechanism with precisely dened seman-
21 tics. This mechanism shall play a central role in enforcing the internal structur-
22 ing of the TCB and the product. The TCB shall incorporate signicant use of
23 layering, abstraction and data hiding.
24 Development
25 Environment
Life Cycle Process.
26 of the product.
29 these standards.
33 Source code of any runtime libraries shall be provided.
34 Physical, procedural, personnel, and other security measures used by the Ven-
35 dor to protect development tools, the product and its documentation shall be
36 described.
37 DRAFT 79 March 23, 1993
5 development tools, hardware, rmware, source code, object code, test suites,
6 and documentation.
14 A combination of technical, physical, and procedural safeguards shall be
15 used to protect from an unauthorized modication or destruction the master
16 copy or copies of all material used to generate the TCB.
17 Development
18 Evidence
21 by the TCB.
27 The Vendor shall provide a formal (and semiformal where necessary) archi-
28 tectural design of the product.
35 The Vendor shall prove the complete mapping between the security policy model
2 Detailed Design.
8 The Vendor shall demonstrate the complete mapping between the architectural
9 design and the detailed design. The Vendor shall also trace the complete mapping
11 Operational
12 Environment
A trusted product control and distribution facility shall be provided for
maintaining the mapping between the TCB distributed to a customer and
the master copies.
13 A combination of technical, procedural or physical safeguards shall exist for
14 ensuring that the TCB software and rmware distributed to a customer are
15 exactly as specied by the master copies.
20 Security
21 Manuals
23 istrative users.
29 services.
36 DRAFT 81 March 23, 1993
3 documentation.
4 Security Testing
15 No design aws and no more than a few correctable implementation aws may
16 be found during testing.
18 the Architectural Design and the Detailed Design.
3 Architecture
16 the TCB which are not protection-critical. Rationale for the inclusion of any
17 protection-irrelevant elements in the TCB shall be provided.
18 Signicant software engineering shall be directed toward minimizing the com-
19 plexity of the TCB. The TCB shall be designed and structured to use a com-
20 plete, conceptually simple protection mechanism with precisely dened seman-
21 tics. This mechanism shall play a central role in enforcing the internal structur-
22 ing of the TCB and the product. The TCB shall incorporate signicant use of
23 layering, abstraction and data hiding.
24 Development
25 Environment
Life Cycle Process.
26 of the product.
29 these standards.
33 Source code of any runtime libraries shall be provided.
34 Physical, procedural, personnel, and other security measures used by the Ven-
35 dor to protect development tools, the product and its documentation shall be
36 described.
37 DRAFT 83 March 23, 1993
5 development tools, hardware, rmware, source code, object code, test suites,
6 and documentation.
14 A combination of technical, physical, and procedural safeguards shall be used
15 to protect from an unauthorized modication or destruction the master copy or
16 copies of all material used to generate the TCB.
17 Development
18 Evidence
21 by the TCB.
27 The Vendor shall provide a formal architectural design of the product.
34 The Vendor shall prove the complete mapping between the security policy model
2 Detailed Design.
3 The Vendor shall provide a formal detailed design of the product.
8 The Vendor shall prove the complete mapping between the architectural design
9 and the detailed design. The Vendor shall also demonstrate the complete
10 mapping between the detailed design and the TCB implementation.
11 Operational
12 Environment
A trusted product control and distribution facility shall be provided for main-
taining the mapping between the TCB distributed to a customer and the master
copies.
13 A combination of technical, procedural or physical safeguards shall exist for
14 ensuring that the TCB software and rmware distributed to a customer are
15 exactly as specied by the master copies.
20 Security
21 Manuals
23 istrative users.
29 services.
36 DRAFT 85 March 23, 1993
3 documentation.
4 Security Testing
15 No design aws and no more than a few correctable implementation aws may
16 be found during testing.
18 the Architectural Design and the Detailed Design.
1 Bibliography
2 Canadian System Security Centre Proceedings from the Canadian
3 Trusted Computer Product Evaluation Criteria Workshop. August 4
4 5, 1988.
5 Canadian System Security Centre Proceedings of the 1990 CTCPEC
6 Availability Workshop. February 6 7, 1990.
7 Computer Systems Research Institute, University of Toronto Com-
8 posability of Trusted Systems. Reports 1 5 [October 16, 1989,
9 January 31, 1990, May 31, 1990, September 31, 1990, January 31,
10 1991]. B. Thompson, R. Soper, P.I.P. Boulton, E.S. Lee, authors.
11 Department of Defense Trusted Computer System Evaluation Crite-
12 ria. DoD 5200.28STD, December 1985.
13 Department of Defense Magnetic Remanence Security Guideline.
14 DoD CSC-STD-00585, November 15, 1985.
15 National Computer Security Center A Guide to Understanding Audit
16 in Trusted Systems. NCSC-TG-001, Version-2, June 1, 1988.
17 National Computer Security Center A Guide to Understanding Dis-
18 cretionary Access Control in Trusted Systems. NCSC-TG-003,
19 Version-1, September 30, 1987.
20 National Computer Security Center Trusted Network Interpretation.
21 NCSC-TG-005, Version-1, July 31, 1987.
22 National Computer Security Center A Guide to Understanding Con-
23 guration Management in Trusted Systems. NCSC-TG-006, Version-
24 1, March 28, 1988.
25 National Computer Security Center A Guide to Understanding De-
26 sign Documentation in Trusted Systems. NCSC-TG-007, Version-1,
27 October 2, 1988.
28 National Computer Security Center Computer Security Subsystem
29 Interpretation. NCSC-TG-009, Version-1, September 16, 1988.
30 National Computer Security Center Rating Maintenance Phase Pro-
31 gram Document. NCSC-TG-013, Version-1, June 23, 1989.
32 National Computer Security Center A Guide to Understanding Ob-
33 ject Reuse in Trusted Systems (Draft). NCSC-TG-018, Version-1,
34 September 15, 1989.
35 DRAFT 87 March 23, 1993
36 Bibliography
1 Bibliography
2 National Computer Security Center Trusted Database Management
3 System Interpretation. NCSC-TG-021, Version-1, April 1991.
4 Information Technology Security Evaluation Criteria. Harmonised
5 Criteria of France Germany the Netherlands the United King-
6 dom. Version 1, May 2, 1990
7 Zentralstelle f ur Sicherheit in der Informationstechnik (ZSI)IT
8 Security Criteria. Criteria for the Evaluation of Trustworthiness of
9 Information Technology (IT) Systems. Version 1, 1989.
10 U.S. Department of Commerce/National Institute of Standards
11 and Technology Security Requirements for Cryptographic Mod-
12 ules (Draft). Federal Information Processing Standards Publication
13 (FIPS) 1401, July 13, 1990.
14 IEEE Proceedings of the Security and Privacy Symposium. Oakland,
15 California. 1980 1991, inclusive.
16 IEEE Proceedings of the Computer Security Applications Conference
17 (original title: Aerospace Computer Security Applications Confer-
18 ence). 1985 1989, inclusive.
19 National Insitute of Standards and Technology National Computer
20 Security Conference. 1984, 1988, 1989.
21 National Institute of Standards and Technology Report on the In-
22 vitational Workshop on Data Integrity. NIST Special Publication
23 500168, September 1989. Zella G. Ruthberg, William T. Polk ed-
24 itors.
25 Bibliography

Ctcpec 1

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ctcpec 1

Uploaded by

Copyright:

Available Formats

1 The Canadian

You might also like