Information Technology

Security Evaluation Criteria

(ITSEC)
"Technical Security Measures, Functionality, and Assurance Levels"
 Introduction
1. IT's Rapid Integration: IT has swiftly become crucial in organized societies over the
past four decades.
2. Security Emphasis: The growing IT role necessitates a heightened focus on security
measures.
3. Essential IT Security: IT Security is imperative, covering confidentiality, integrity, and
availability.
4. Unique System Requirements: IT systems/products have distinct requirements for
maintaining security.
5. Security Enforcing Functions: Technical measures include access control, auditing,
and error recovery.
6. Crucial Confidence: Assurance is vital, ensuring confidence in correctness and
effectiveness.
 Introduction
1. User Trust: Users rely on independent assessments for confidence in system
security.
2. Harmonized Criteria: Collaborative efforts produced harmonized IT security
criteria by France, Germany, the Netherlands, and the UK.
3. Objectives of Harmonization: Goals include leveraging collective experience,
ensuring industry alignment, and accommodating diverse applications.
4. Comprehensive Criteria: The document primarily focuses on technical security
measures but encompasses relevant non-technical aspects.
5. International Compatibility: Harmonized criteria aim for compatibility among
national certification bodies, facilitating mutual recognition of evaluation results.
6. Standardized Framework: The document details security functionality,
evaluation criteria, and a glossary, providing a standardized framework for IT
security evaluation.
7. Continuous Improvement: The criteria have undergone extensive international
review, welcoming comments and suggestions for ongoing enhancement.
 Scope
 Technical Security Measures:
 Technical security measures are crucial despite non-technical controls.
 Criteria primarily focus on technical measures but address secure operating procedures.
 Systems and Products:
 IT system: Specific installation with known operational environment.
 IT product: Off-the-shelf hardware/software for various systems.
 The main security difference lies in the certainty of the operational environment.
 Functionality and Assurance, Classes, and Levels:
 Security enforcing functions (e.g., access control) are crucial for meeting security objectives.
 Evaluation levels (E0 to E6) assess correctness and effectiveness.
 Assurance addresses confidence in implementation correctness and effectiveness.
 Assurance Profiles:
 Evaluation levels determine the confidence in security enforcing functions.
 Possibility of multiple security targets for different confidence levels.
 Scope
 The Evaluation Process:
 Objective: Impartial report on TOE's satisfaction of security target at specified
confidence level.
 Close involvement of sponsor; higher levels demand more sponsor involvement.
 Security test and analysis are sponsor responsibilities.
 The Certification Process:
 Practical schemes by national certification bodies for independent evaluation
support.
 Certification bodies maintain uniformity; details beyond the criteria's scope.
 Certified rating maintenance and changes are regulated by certification bodies.
 Relationship to the TCSEC:
 Example functionality classes bridge criteria between the two standards.

 Note: TOE - Target of Evaluation, TCB - Trusted Computing Base.

 Functionality
• Security Objectives (Why):
• Overview of the intended security contributions.
• Defines the desired security outcomes.
• Security Enforcing Functions (What):
• Specifies the functions necessary to achieve security objectives.
• Describes the actual provided functionality.
• Security Mechanisms (How):
• Details the specific mechanisms implementing security functions.
• Explains how the intended functionality is delivered.
• Overall:
• The Security Target (ST) consists of these three levels.
• ST guides the evaluation process, ensuring security features meet desired
objectives.
 The Security Target Overview
• Purpose:
• Serves as a specification for security enforcing functions.
• Describes the TOE and its relationship to the operating environment.

• Audience:
• Targets a broad audience including developers, evaluators, managers,
purchasers, installers, configurators, operators, and users.
 The Security Target Overview
• Contents:
a) System Security Policy or Product Rationale:
• Overview of security policies or rationale for product functionalities.
b) Specification of Security Enforcing Functions:
• Details functions necessary to meet security objectives.
c) Definition of Required Security Mechanisms (Optional):
• Explanation of specific mechanisms implementing security functions.
d) Claimed Rating of Minimum Strength of Mechanisms:
• Minimum strength level claimed for security mechanisms.
e) Target Evaluation Level:
• Specifies the desired evaluation level for the TOE.
 The Security Target Overview

• Requirements:
• Presentation and content requirements vary based on the target evaluation
level.
• Single or multiple documents allowed with clear indication of
relationships.

• Responsibility:
• The sponsor is responsible for accuracy and provision of the security
target.
 Product Rationale and Security Enforcing
Functions
• Product Rationale
• Informs purchasers about the product's use and its alignment with system security
objectives.
• Includes details on intended use, environment, assumed threats, security features,
and dependencies on external factors.
• Specification of Security Enforcing Functions:
• Included in the security target.
• May reference predefined functionality classes or standards defining security
functionality.
• For systems, correlates functions with security objectives.
• For products, correlates functions with intended use and environmental
assumptions.
• Informal style for all; semiformal or formal style for higher evaluation levels.
Mechanisms, Strength Rating, and Evaluation Level
• Definition of Required Security Mechanisms:
• Optional but may specify mechanisms correlating with security functions.
• Developer's task to implement prescribed mechanisms.
• Claimed Rating of Minimum Strength:
• Specifies the minimum strength against direct attack (basic, medium, or high).
• Target Evaluation Level:
• Specifies the desired evaluation level (E1 to E6).
• Examples of Use of Existing Security Policy Documents:
• Allows existing documents as part of the security target.
• Examples include System Security Policy (SSP), System Electronic Information Security
Policy (SEISP), and Security Policy Model (SPM) in the UK.
• Claims Document for product security targets, using a semi-formal style.
• Flexibility in Document Structure:
Accommodates different document structures based on existing styles.
Supplementary documents may be required to complete information for the security target.
Generic Headings

 Identification and Authentication

 Access Control
 Accountability
 Audit
 Object Reuse
 Accuracy
 Reliability of Service
 Data Exchange
 Identification and Authentication
• Objective:
• Determine and control user access to TOE resources.
• Identification (2.34):
• Establish and verify claimed user identity.
• User provides information known by TOE.
• Authentication Functions (2.35):
• Establish and verify claimed identity.
• Include functions for adding/removing user identities.
• Generate, change, or allow inspection of authentication information.
• Ensure integrity and prevent unauthorized use of authentication info.
• Limit repeated attempts to establish a false identity.
• User Identity Management (2.36):
• Enable addition/removal of user identities.
• Manage authentication information generation, change, inspection.
• Assure integrity and prevent unauthorized use of authentication data.
 Access Control
• Objective:
• Control access to information and resources based on authorization.
• Access Control Functions (2.37):
• Prevent unauthorized access to information/resources.
• Restrict creation/amendment of information.
• Controlled Entities (2.38):
• Users, processes, and objects.
• Administer access rights (granting/revocation) and verification.
• Access Management Functions (2.39):
• Set up and maintain lists/rules for access rights.
• Restrict access to maintain consistency.
• Apply default access rules upon creation.
• Control propagation of access rights.
• Manage inference control in data aggregation.
 Accountability

• Objective:
• Record and link user/process actions for accountability.
• Accountability Functions (2.40):
• Record relevant information about user/process actions.
• Enable linking actions to specific users.
• Functional Coverage (2.41):
• Collection, protection, and analysis of accountable information.
• Overlap with Auditability (2.42):
• Functions may satisfy both accountability and auditability.
• Cross-referencing between headings as needed
 Audit
• Objective:
• Record information about routine and exceptional events.
• Enable investigations for security violation detection.
• Auditability Functions (2.44):
• Detect and investigate events posing a threat to security.
• Functional Coverage (2.45):
• Collection, protection, and analysis of event information.
• Trend analysis for potential security violations.
• Overlap with Accountability (2.45):
• Functions may satisfy both auditability and accountability.
• Cross-referencing between headings as needed.
 Object Reuse

• Objective:
• Facilitate resource reuse (main memory, disk storage) while preserving
security.

• Functions:
• Control the reuse of data objects (2.47).
• Initialize or clear unallocated or reallocated data objects (2.48).
• Clear reusable media (e.g., magnetic tapes) and output devices when not in
use.
Data Accuracy and Integrity

• Objective:
• Maintain accurate relationships between data, ensuring data integrity during
transfers.

• Functions:
• Ensure data remains unmodified in an unauthorized manner (2.50).
• Establish and maintain accuracy of relationships between related data (2.51).
• Detect or prevent loss, addition, or alteration during data transfer
 Reliability of Service
• Objective:
• Ensure time-critical tasks are performed as needed, prevent unnecessary
resource requests.

• Functions:
• Ensure resources are accessible on demand by authorized entities (2.53).
• Implement error detection and recovery functions (2.54).
• Incorporate scheduling functions to optimize TOE operation and minimize
disruption.
 Predefined Classes
• Objective:
• Utilize common sets of security functions through predefined classes for system
and product security targets.
• Functions:
• Reference predefined classes to define part or all of security enforcing functions
(2.59).
• Standards for predefined functionality classes are desirable for consistency (2.59).
• Each predefined class specifies objectives, envisaged use, reasons for function
choice (2.61).
• Use of Predefined Classes:
• Not obligatory; sponsors may choose not to use or may not be applicable (2.62).
• Can be used individually or in combination with one or more predefined classes
(2.62).
• Ten example predefined classes provided in Annex A, derived from [ZSIEC]
(2.63).
 Example Predefined Classes
• Hierarchically Ordered Confidentiality Classes:
• F-C1, F-C2, F-B1, F-B2, F-B3, corresponding to TCSEC classes C1 to A1 [TCSEC].
• High Integrity Requirements for Data and Programs:
• F-IN, suitable for TOEs with high integrity requirements, e.g., database systems.
• High Availability Requirements:
• F-AV, sets high availability requirements, significant for TOEs controlling
manufacturing processes.
• Safeguarding Data Integrity during Data Communication:
• F-DI, sets high requirements for data integrity during data communication.
• High Demands on Confidentiality of Data during Data Communication:
• F-DC, intended for TOEs with high demands on data confidentiality during
communication.
• Networks with High Demands on Confidentiality and Integrity:
• F-DX, for networks with high demands on confidentiality and integrity of
communicated information.
 Specification Style
• Objective:
• Provide flexibility in specifying security functions using three types of styles: informal,
semiformal, and formal.
• Styles Identified:
• Informal Specification:
• Written in natural language.
• Prone to ambiguity.
• Supported by parallel semiformal or formal specification at higher evaluation
levels (2.70-2.71).
• Semiformal Specification:
• Requires restricted notation.
• Allows specification of function effects and exceptional conditions.
• Examples include data-flow diagrams, state transition diagrams, and structured
design methods (2.72-2.74).
 Specification Style

• Formal Specification:
• Written in formal notation based on mathematical concepts.
• Requires precise syntactic and semantic rules.
• Examples include VDM, Z, and ISO protocol specification language (2.76-
2.78).
Consistency of Parallel Specifications
• Consistency Requirement:
• Parallel specifications must be clear, consistent, and address the same points (2.79).
• Error Resolution:
• Ambiguities in informal specifications resolved by corresponding semiformal or
formal specifications (2.80).
• Errors in consistency between parallel specifications must be resolved through
external information and amendments (2.80).
• Presentation:
• Parallel specifications may be separate documents or interleaved in a single
document (2.79).
Note:
• Specification technique or style for security objectives and prescribed mechanisms
is outside the scope (2.67).
• Predefined classes may replace or complement style-specific specifications (2.68)
Overview of Formal Models of Security
Policy
• E4 and Above Requirement:
• TOE must implement an underlying model of security policy.
• Abstract statement of key security principles.
• Expressed in a Formal Style:
• Formal model of security policy.
• Styles include informal, semiformal, or formal (2.81).
• Implementation/Reference:
• Reference published models or provide one in the security target.
 Scope and Examples of Formal Models

• Scope of the Formal Model:

• Doesn't need to cover all security enforcing functions.
• Informal interpretation in the security target to show implementation consistency
(2.82).
 Examples
• Examples of Published Models:
• Bell-La Padula Model [BLP]:
• Confidentiality-focused for national security policies.
• Clark and Wilson Model [CWM]:
• Focus on integrity for commercial transactions.
• Brewer-Nash Model [BNM]:
• Access control for client confidentiality in financial services.
• Eizenberg Model [EZBM]:
• Models time-varying access control rights.
• Landwehr Model [LWM]:
• Models data exchange requirements in message processing networks (2.83).
• Interpretation and Alignment:
• Informal interpretation in the security target to showcase alignment with the
underlying policy and avoid conflicts (2.82).
Assurance – Effectiveness Overview

• Objective:
• Evaluate the effectiveness aspect of assurance for a Target of Evaluation (TOE).
• Baseline:
• Security target defined in Chapter 2.
• Simultaneous Evaluation:
• Evaluation for effectiveness and correctness concurrently.
• Chapters:
• Effectiveness criteria outlined in this chapter.
• Correctness criteria addressed in Chapter 4.
Approach Description
Assessment of effectiveness involves consideration of the following aspects of the TOE:

 a) the suitability of the TOE's security enforcing functions to counter the threats to the
security of the TOE identified in the security target;
 b) the ability of the TOE's security enforcing functions and mechanisms to bind
together in a way that is mutually supportive and provides an integrated and effective
whole;
 c) the ability of the TOE's security mechanisms to withstand direct attack;
 d) whether known security vulnerabilities in the construction of the TOE could in
practice compromise the security of the TOE;
 e) that the TOE cannot be configured or used in a manner which is insecure but which
an administrator or end-user of the TOE would reasonably believe to be secure;
 f) whether known security vulnerabilities in the operation of the TOE could in practice
compromise the security of the TOE.
Systems and Products

 There are different requirements and options for the content of a security target for a
TOE, depending on whether the TOE is being evaluated as a system or product.
These differences are set out under Construction –

Phase 1 - Requirements in Chapter 4, and further explained in Chapter 2.

Effectiveness Criteria – Construction

The sponsor shall provide the following documentation in addition to that required for
evaluation of correctness:

 - Suitability Analysis
 - Binding Analysis
 - Strength of Mechanisms Analysis
 - List of Known Vulnerabilities in Construction.
Aspect 1 - Suitability of Functionality:
• Definition:
• Security Target provided by the sponsor for correctness evaluation.
• Assessment Focus:
• Determine if TOE's functions and mechanisms effectively counter identified
threats.
• Content and Presentation Requirements:
• Linkage: Relate security functions and mechanisms to enumerated threats in the
security target.
• Evidence Requirements:
• Demonstration: Illustrate how each threat is countered by specific security
functions.
Aspect 1 - Suitability of Functionality:

• Evaluator Actions:
• Verification: Confirm compliance with content, presentation, and evidence
standards.
• Information Utilization: Ensure consideration of all relevant details specified for
the evaluation level.
• Purpose:
• Evaluate the adequacy of security enforcing functions in addressing identified
threats.
 Note: This assessment ensures the suitability of functionality against specified threats in
the security target.
 Aspect 2 - Binding of Functionality:
• Definition:
• Investigates how security enforcing functions and mechanisms work together for
mutual support and an integrated, effective whole.
• Content and Presentation Requirements:
• Analysis Scope: Examine potential interrelationships among all security enforcing
functions.
• Evidence Requirements:
• Conflict Avoidance: Demonstrate that no function or mechanism conflicts with
others.
Aspect 2 - Binding of Functionality:

• Evaluator Actions:
• Verification: Confirm compliance with content, presentation, and evidence
standards.
• Comprehensive Analysis: Ensure consideration of all relevant details specified for
the evaluation level.
• Purpose:
• Evaluate the coherence and synergy of security functions and mechanisms within
the TOE.
 Note: This assessment ensures that all security enforcing functions and mechanisms
complement each other, avoiding conflicts and contradictions.
Aspect 3 - Strength of Mechanisms:
• Definition:
• Evaluates the ability of security enforcing mechanisms to resist direct attacks,
considering the underlying algorithms, principles, and properties.
• Content and Presentation Requirements:
• Critical Mechanisms Identification: List all critical security enforcing
mechanisms.
• Algorithm Analysis: Include or reference analyses of underlying algorithms,
principles, and properties.
• Evidence Requirements:
• Minimum Strength Confirmation: Confirm critical mechanisms meet the
claimed minimum strength rating (basic, medium, high).
• Cryptographic Mechanisms: Provide a statement from the appropriate national
body for cryptographic mechanisms.
Aspect 3 - Strength of Mechanisms:

• Evaluator Actions:
• Verification: Confirm critical mechanisms identification and compliance with
content, presentation, and evidence standards.
• Analysis Review: Ensure consideration of all relevant details specified for the
evaluation level.
• Penetration Testing: Conduct where necessary to validate claimed minimum
strength.
• Purpose:
• Assess the robustness of critical mechanisms against direct attacks, factoring in
resource requirements.
 Note: This analysis aims to ensure that critical mechanisms can withstand direct
attacks, considering the level of resources needed for a successful attack
Aspect 4 - Construction Vulnerability
Assessment
• Definition:
• Assesses known vulnerabilities in the construction of the TOE to determine their
potential impact on TOE security, considering deactivation, bypassing, corruption,
or circumvention of security functions.
• Content and Presentation Requirements:
• Sponsor's List: Identify and analyze all known vulnerabilities in the TOE's
construction.
• Impact Analysis: Provide potential impact analysis for each vulnerability and
countermeasure details.
• Evidence Requirements:
• Exploitation Prevention: Demonstrate that known vulnerabilities cannot be
exploited in the intended TOE environment.
• External Measures: Show how vulnerabilities are covered by uncompromised
Aspect 4 - Construction Vulnerability
Assessment
• Evaluator Actions:
• Verification: Confirm compliance with content, presentation, and evidence standards for the list of
known vulnerabilities.
• Independent Analysis: Conduct an independent vulnerability analysis, considering listed and
additional construction vulnerabilities.
• Comprehensive Coverage: Verify addressing all combinations of known vulnerabilities.
• Assumption Review: Ensure no undocumented or unreasonable assumptions about the intended
environment.
• Penetration Testing: Confirm practical exploitability of known vulnerabilities.
• Purpose:
• Assess the impact and exploitability of known construction vulnerabilities to ensure they do not
compromise TOE security, considering both listed vulnerabilities and additional findings.
 Note: This analysis aims to confirm that known vulnerabilities, including potential impacts and
countermeasures, do not compromise the intended security of the TOE.
Effectiveness Criteria – Operation

The sponsor shall provide the following documentation in addition to that required for
evaluation of correctness:

 Ease of Use Analysis

 List of Known Vulnerabilities in Operational Use.
Aspect 1 - Ease of Use:

• Definition:
• Investigates whether the TOE can be insecurely configured or used in a manner that
an administrator or end-user might reasonably believe to be secure.
• Content and Presentation Requirements:
• Operation Modes: Identify possible TOE operation modes, including post-failure
or operational error scenarios and implications for secure operation.
• Evidence Requirements:
• Detectability: Show that any human or operational error deactivating or disabling
security functions is easily detectable.
• Configuration Security: Confirm that insecure TOE configuration or usage,
contrary to the security target, is easily detectable by end-users or administrators.
Aspect 1 - Ease of Use:
• Evaluator Actions:
• Analysis Verification: Ensure ease of use analysis meets all content, presentation,
and evidence requirements.
• Assumption Review: Check for undocumented or unreasonable assumptions about
the intended environment.
• External Measures: Verify documentation of external security measures
(procedural, physical, personnel controls).
• Operational Testing: Repeat configuration and installation procedures to confirm
secure TOE usage. Perform additional testing as needed.
• Purpose:
• Assess whether the TOE is prone to insecure configuration or usage that could be
perceived as secure by users or administrators, ensuring detectability of errors and
vulnerabilities.
 Note: This analysis aims to confirm that potential insecure configurations or operations
of the TOE, contrary to the security target, are easily detectable by end-users or
administrators.
Aspect 2 - Operational Vulnerability
Assessment:
• Definition:
• Assesses known vulnerabilities in the operation of the TOE to determine if they could
compromise TOE security as specified in the security target.
• Content and Presentation Requirements:
• Known Vulnerabilities List: Sponsor provides a list of known operational vulnerabilities, each
with an impact analysis and proposed countermeasures.
• Evidence Requirements:
• Exploitation Prevention: Analysis must demonstrate that known vulnerabilities can't be
exploited in the intended TOE environment.
• Coverage by External Measures: Vulnerabilities should be covered by uncompromised
external security measures or proven irrelevant to the security target.
Aspect 2 - Operational Vulnerability Assessment:
• Evaluator Actions:
• Comprehensive Review: Check the list of known vulnerabilities, ensuring it meets
content, presentation, and evidence requirements.
• Impact Analysis Verification: Ensure the analysis of potential impacts considers
all information for the evaluation level.
• Independent Vulnerability Analysis: Perform an independent analysis,
considering listed and any additional known operational vulnerabilities.
• Coverage Confirmation: Check that all combinations of known vulnerabilities are
addressed and external security measures are appropriately documented.
• Testing: Conduct penetration testing to confirm or disprove the actual
exploitability of known vulnerabilities in practice.
• Purpose:
• Verify that known operational vulnerabilities, identified during TOE evaluation,
cannot be exploited in the intended environment and are adequately addressed by
external security measures.
 Note: This assessment aims to confirm that identified vulnerabilities in the operation of
the TOE, known to the sponsor and evaluator, do not pose practical risks to TOE
security, considering external security measures.
INFORMATION
OBTAINED FROM A
CORRECTNESS
ASSESSMENT
WHICH IS USED
TO PERFORM A
VULNERABILITY
ANALYSIS
Correctness Assurance Overview

 Objective:
 Address the correctness aspect of assurance for a TOE.
 Baseline for Evaluation:
 Security target defined in Chapter 2.
 Elements include target evaluation level and claimed rating for minimum strength
of mechanisms.
 Differentiation:
 Effectiveness aspect covered in Chapter 3.
 Conclusion:
 Correctness assurance focuses on TOE evaluation based on the specified security
target.
Evaluation Levels Overview

1. Evaluation Levels:
1. Seven levels denoted from E0 to E6.
2. Represent confidence in the correctness of a TOE.
2. Characterization:
1. E0: Inadequate assurance.
2. E1: Security target, informal architectural design, functional testing.
3. E2: Adds informal detailed design, evaluated functional testing, config control, distribution.
4. E3: Adds evaluation of source code/hardware drawings, testing evidence.
5. E4: Adds formal model of security policy, semiformal spec for functions/design.
Evaluation Levels Overview

3. Characterization (Contd.):
3. E5: Adds close correspondence between detailed design and source code/hardware.
4. E6: Adds formal style for security functions/architectural design, consistent with
the formal model.
4. Conclusion:
3. Evaluation levels progress from basic assurance (E0) to the highest (E6) with
formal security policy models and specifications.
5. Note:
3. Each level builds on the requirements of the previous level.
4. Criteria include security target, design descriptions, testing evidence, and formality
of specifications
Approach to Descriptions Overview
 Construction vs. Operation:
 Criteria distinguish between construction and operation phases.
 Criteria are categorized under various phases and aspects for each evaluation level.
 Documentation Breakdown:
 For each aspect or phase, criteria breakdown includes:
 Identification of required documentation.
 Requirements for content, presentation, procedures, and standards.
 Evidence needed to demonstrate criteria fulfillment.
 Actions to be taken by the evaluator.
 Level-specific Criteria:
 Criteria for each evaluation level are presented separately.
 New or modified criteria at each level are highlighted in bold.
 Rigor and depth of evidence increase with higher evaluation levels.
Sponsor and Evaluator Responsibilities
 Responsibilities:
 Burden for evidence provision is on the sponsor, except at E1.
 Independent action by the evaluator is required for confidence.
 Testing is part of quality assurance; a Quality Assurance Programme is assumed
throughout the TOE lifecycle.
 Testing Emphasis:
 Testing is one aspect of quality assurance.
 Sponsor provides evidence of normal development process testing.
 Evaluator verifies completeness, comprehensiveness, and accuracy of sponsor-
supplied testing through independent tests.
 Quality Assurance Programme:
 Assumed to be active throughout the TOE lifecycle.
 Criteria guide assessors in evaluating the adequacy of the Quality Assurance
Programme for the targeted evaluation level.
Construction - Development Process
Overview Phases of Development:
1.

 Four phases in the development process contribute to confidence in the TOE's

correctness.
 Criteria for understanding the development process apply to each evaluation level
(E1 to E6).
2. Phases Breakdown:
 Phase 1 (Requirements):
 Involves producing a security target as the baseline for evaluation.
 Phase 2 (Architectural Design):
 Encompasses top-level definition, emphasizing the separation of security-
enforcing components.
 Phase 3 (Detailed Design):
 Refinement of architectural design to a level suitable for
programming/hardware construction.
 Phase 4 (Implementation):
 Involves implementing the detailed design, testing individual components, and
integrating them into the complete TOE.
Development Process Phases Detail
 Phase 1 - Requirements (E<level>.19):
 Focuses on producing a security target, including the target evaluation level and
claimed minimum strength of mechanisms.
 Phase 2 - Architectural Design (E<level>.20):
 Includes high-level specification defining the TOE's structure, interfaces, and
separation of components.
 Emphasizes effective separation between security and non-security components.
 Phase 3 - Detailed Design (E<level>.21):
 Covers refinement to a detailed level suitable for programming/hardware
construction.
 Identifies basic components, security-enforcing components, and security-relevant
non-security components.
 Phase 4 - Implementation (E<level>.22):
 Involves building basic components, testing against specifications, integrating
components, and testing the complete TOE.
 Acknowledges testing limitations and the need for analysis at higher evaluation
levels.
 Construction - Development Environment &
Aspects (Overview)
• Development Environment (E<level>.23):
• Measures, procedures, and standards during TOE development, production, and
maintenance.
• Ensures integrity and correctness throughout the TOE lifecycle.
• Aspect 1 - Configuration Control (E<level>.24):
• Controls on development processes for maintaining representation correspondence.
• Post-release control for flaw correction and modification validation.
• Aspect 2 - Programming Languages (E<level>.25):
• Addresses software and firmware components.
• Specifies requirements for programming languages, compiling tools, and runtime
libraries.
• Aspect 3 - Developers Security (E<level>.26):
• Covers physical, procedural, technical, and personnel measures.
• Aims to protect development from attacks and maintain information confidentiality.
Operation - Operational Documentation &
Aspects
• Operational Documentation (E<level>.27):
• Key communication means between TOE developer and users.
• Importance of understandability, coverage, and correctness for secure TOE
operation.
• Aspect 1 - User Documentation (E<level>.28):
• Information for end-users about TOE, emphasizing security capabilities and user
contributions to security.
• Aspect 2 - Administration Documentation (E<level>.29):
• Information for administrators, covers setup and secure operation of the TOE
Operation - Operational Environment &
Aspects
Operational Environment (E<level>.30):
• Concerns secure delivery, installation, and operational use of the TOE.
• Assessment of actual operational procedures or evaluation of proposed procedures.
• Aspect 1 - Delivery and Configuration (E<level>.31):
• Procedures for secure transfer and configuration during installation.
• Measures to ensure security protection during transfer and configuration at the
user's site.
• Aspect 2 - Start-up and Operation (E<level>.32):
• Administrator procedures for daily secure TOE operation.
• Covers routine and exceptional activities, including backups, maintenance, and
recovery after failures.
Level E1
Construction - The Development Process

Construction - The Development Process

❑ E1.1 The sponsor shall provide the TOE, and the following documentation:
❑ - The security target for the TOE
❑ - Informal description of the architecture of the TOE
❑ - Test documentation (optional)
❑ - Library of test programs and tools used for testing the TOE (optional)
Correctness - Level E1 - Phase 1 -
Requirements
• Requirements for Content and Presentation (E1.2):
• Security target to state security enforcing functions.
• For a system: Include System Security Policy (SSP) with security objectives and
threats.
• For a product: Include rationale with method of use, intended environment, and
assumed threats.
• Specify security enforcing functions informally (Chapter 2 categorization).
• Requirements for Evidence (E1.3):
• For a system: Demonstrate how proposed functionality fulfills security objectives
and counters threats.
• For a product: Show how functionality is appropriate for the method of use and
counters assumed threats.
• Evaluator Actions (E1.4):
• Verify content and presentation compliance.
• Ensure no inconsistencies in the security target.
Correctness - Level E1 - Phase 2 - Architectural
Design

Requirements for Content and Presentation (E1.5):

• Describe TOE's general structure.
• Specify external interfaces.
• Detail required hardware and firmware, including supporting protection mechanisms'
functionality.
• Requirements for Evidence (E1.6):
• Specify how security enforcing functions in the security target will be provided.
• Evaluator Actions (E1.7):
• Verify compliance with content and presentation requirements.
Phase 3 - Detailed Design

 Requirements for Content and Presentation

 E1.8 No Requirement.
 Requirements for Evidence
 E1.9 No Requirement.
 Evaluator Actions
 E1.10 No Action.
Correctness - Level E1 - Phase 4 -
Implementation
• Requirements for Content and Presentation:
• Test documentation including plan, purpose, procedures, and results.
• Library of test programs and tools for test repetition.
• Requirements for Evidence (E1.12):
• Test documentation indicating correspondence between tests and security enforcing
functions.
• Evaluator Actions (E1.13):
• Verify TOE compliance with security target through tests.
• Check for errors through additional tests.
• Sample results of sponsor-performed tests.
Construction - The Development Environment

E1.14 The sponsor shall provide the following documentation:

- Configuration list identifying the version of the TOE for evaluation

Aspect 1 - Configuration Control

Requirements for Content and Presentation
E1.15 The configuration list shall state where the TOE is uniquely identified (version
number).
Requirements for Evidence
E1.16 The configuration list shall state how the TOE is uniquely identified.
Evaluator Actions
E1.17 Check that the information provided meets all requirements for content and
presentation and evidence.
Aspect 2 - Programming Languages and
Compilers

 Requirements for Content and Presentation

 E1.18 No Requirement.
 Requirements for Evidence
 E1.19 No Requirement.
 Evaluator Actions
 E1.20 No Action.
Aspect 3 - Developers Security

 Requirements for Content and Presentation

 E1.21 No Requirement.
 Requirements for Evidence
 E1.22 No Requirement.
 Evaluator Actions
 E1.23 No Action.
Operation - The Operational Documentation

 E1.24 The sponsor shall provide the following documentation:

- User documentation
- Administration documentation
Operation - The Operational Environment

 E1.31 The sponsor shall provide the following documentation:

- Delivery and Configuration Documentation
- Start-up and Operation Documentation
Results of Evaluation - Rating Components
• Introduction (5.1):
• Evaluation measures correctness and effectiveness assurance.
• Rating (5.2):
• Consists of reference to security target, evaluation level, and confirmed rating of
minimum strength.
• Security Target (5.3):
• Specified for independent evaluation, following criteria for the designated level and
TOE type.
• Evaluation Level (5.4):
• E0, E1, E2, E3, E4, E5, or E6.
• Confirmed Rating (5.5):
• Basic, medium, or high, awarded only if successfully evaluated (excluding E0).
Evaluation Outcomes and Decision Points
• Evaluation Outcomes (5.6):
• TOE meeting correctness and effectiveness criteria awarded the rating of its
evaluation level.
• Exploitable Vulnerability (5.7):
• TOE with an exploitable vulnerability, not eliminated, is withdrawn or awarded E0.
• Insufficient Evidence (5.8):
• TOE with insufficient evidence may be awarded a lower level; if time/resources are
lacking, it's withdrawn or awarded E0.
• Effectiveness Failure (5.9):
• TOE failing due to an exploitable vulnerability is withdrawn or awarded E0.
• E0 Rating (5.10):
• TOE with E0 has no minimum strength rating, demonstrating inadequate assurance.
• Evaluator's Report (5.11):
• Report format should be acceptable for consideration by the national certification
body.