The assurance in a CKRS compliant product can be achieved using the Common Criteria Evaluation Assurance Level (EAL). The Common Criteria defines seven hierarchical assurance levels EAL1 through EAL7. The Common Criteria assurance levels may be overkill for the CKRS compliance validation program. Thus, the following is a tailored list of assurance requirements. These requirements are derived from the Common Criteria Part 3 (Assurance Requirements). Specifying assurance requirements in the common criteria language will help in converting the FIPS into a Common Criteria Protection Profile and in validating CKRS compliance products under the Common Criteria (CC) Evaluation Methodology. For the sake of clarity, it should be noted that the CC structure for assurance requirements is hierarchical follows. At the highest level, the requirements are categorized into classes. The classes are further decomposed into families. The families are decomposed into components. Each component has three sets of elements. The first set of elements is the list of developer (vendor) actions to satisfy the component. The second set of elements are a list of contents and presentation for the assurance evidence for that element. The third and last set of elements are what an independent evaluator should do to assess the contents and presentation. A later section of this report also explains why the remaining Common Criteria assurance requirements are not recommended. We have defined three assurance levels. These levels are somewhat related to the Common Criteria assurance levels, but not derived from the Common Criteria assurance levels. We term these assurance levels basic, enhanced, and delux. The components in the assurance levels are listed in Table 1. A later section of the report describes these components and elements. The assurance can be applied commensurate with the CKRS component sensitivity. For example the KRA must have high degree of assurance, where as the client may have a lower degree of assurance. The CKRS components for assurance purposes can be broken down in the following areas: KRA, clients, other trusted components such as CA, and other components such as registration agents. Table 2 contains a matrix of which assurance levels make sense for each environment. For entities such as the CA, if there are assurance and security requirements or standards, these standards may (should) be used in lieu of the recommendations in Table 2. Furthermore, it does not make sense for clients and other components to have higher assurance than the KRA and other trusted components (e.g., CA). Thus, the assurance for the KRA and CA should be equal to or greater than assurance for the clients and other components. Basic assurance is not recommended for the KRA and CA. Table 1: CKRS Assurance Levels Assurance Class Assurance Family Basic Enhanced Delux Configuration Management ACM_CAP CM Capabilities 1 1 ACM_SCP CM Scope 2 Delivery and Operation ADO_DEL Delivery 2 ADO_IGS Installation, Generation and Start-up 1 1 1 ADV_FSP Functional Specification 1 2 2 ADV_HLD High-Level Design 1 2 2 Development ADV_IMP Implementation Representation 1 ADV_LLD Low-Level Design 1 ADV_RCR Representation Correspondence 1 Guidance Documents AGD_ADM Administrator Guidance 1 1 1 AGD_USR User Guidance 1 1 1 Life Cycle Support ALC_FLR Flaw Remediation 2 2 2 ATE_COV Coverage 1 1 1 ATE_DPT Depth 1 1 1 Tests ATE_FUN Functional Tests 1 1 1 ATE_IND Independent Testing 2 2 2 Vulnerability Assessment AVA_VLA Vulnerability Analysis 1 1 Table 2: Assurance for CKRS Components Component Basic Enhanced Delux KRA Yes Yes Other Trusted (e.g., CA) Yes Yes Client Yes Yes Yes Other Yes Yes Yes TABLE OF CONTENTS Configuration Management ACM_CAP - CM Capabilities 5 ACM_CAP.1 Minimal support 5 Configuration Management ACM_SCP - CM Scope 6 ACM_SCP.2 Problem tracking CM coverage 6 Delivery and Operation ADO_DEL - Delivery 7 ADO_DEL.2 Detection of modification 7 Delivery and Operation ADO_IGS - Installation, Generation, and Start-up 8 ADO_IGS.1 Installation, generation, and start-up procedures 8 Development ADV_FSP - Functional Specification 8 ADV_FSP.1 Functional specification and security policy 9 ADV_FSP.2 Informal security policy model 10 Development ADV_HLD - High-Level Design 11 ADV_HLD.1 Descriptive high-level design 12 ADV_HLD.2 Security enforcing high-level design 13 Development ADV_IMP - Implementation Representation 13 ADV_IMP.1 Subset of the implementation 14 Development ADV_LLD - Low-Level Design 15 ADV_LLD.1 Descriptive low-level design 16 Development ADV_RCR - Representation Correspondence 16 ADV_RCR.1 Informal correspondence demonstration 17 Guidance Documents AGD_ADM Administrator Guidance 17 AGD_ADM.1 Administrator guidance 18 Guidance Documents AGD_USR - User Guidance 19 AGD_USR.1 User guidance 20 Life Cycle Support ALC_FLR - Flaw Remediation 20 ALC_FLR.2 Flaw reporting procedures 20 Tests ATE_COV - Coverage 21 ATE_COV.1 Complete coverage - informal 21 Tests ATE_DPT - Depth 22 ATE_DPT.1 Testing - functional specification 22 Tests ATE_FUN - Functional Tests 23 ATE_FUN.1 Functional testing 23 Tests ATE_IND - Independent Testing 24 ATE_IND.2 Independent testing - sample 24 Vulnerability Assessment AVA_VLA - Vulnerability Analysis 25 AVA_VLA.1 Developer vulnerability analysis 26 Configuration Management ACM_CAP - CM Capabilities Objectives Configuration management (CM) is an aspect of establishing that the functional requirements and specifications are realized in the implementation. CM meets these objectives by requiring discipline and control in the processes of refinement and modification of the product/system. CM systems are put in place to ensure the integrity of the configuration items that they control, by providing a method of tracking these configuration items, and by ensuring that only authorized users are capable of changing them. The capabilities of the CM system address the likelihood that accidental or unauthorized modifications of the configuration items will occur. The CM system should ensure the integrity of the product/system from the early design stages through all subsequent maintenance efforts. The objectives of this assurance requirement include the following: 1. ensuring that the product/system is correct and complete before it is sent to the consumer; and 2. ensuring that no configuration items are missed during evaluation. Clear identification of the product/system is required to determine those items under evaluation that are subject to the criteria requirements. Application notes There is a requirement that a configuration list be provided. The configuration list contains all configuration items which are maintained by the CM system. ACM_CAP.1 Minimal support Developer action elements: ACM_CAP.1.1D: The developer shall use a CM system. ACM_CAP.1.2D: The developer shall provide CM documentation. Content and presentation of evidence elements: ACM_CAP.1.1C: The CM documentation shall include a configuration list. ACM_CAP.1.2C: The configuration list shall describe the configuration items that comprise the product. ACM_CAP.1.3C: The CM documentation shall describe the method used to uniquely identify the product configuration items. Evaluator action elements: ACM_CAP.1.1E: The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. Configuration Management ACM_SCP - CM Scope Objectives Configuration management (CM) is an aspect of establishing that the functional requirements and specifications are realized in the implementation. CM meets these objectives by requiring discipline and control in the processes of refinement and modification of the product/system. CM systems are put in place to ensure the integrity of the configuration items that they control, by providing a method of tracking these configuration items, and by ensuring that only authorized users are capable of changing them. The objective is to ensure that all necessary configuration items are tracked by the CM system. This helps to ensure that the integrity of these configuration items is protected through the capabilities of the CM system. The objectives of this assurance requirement include the following: 1. ensuring that the implementation representation (i.e., code) is tracked; and 2. ensuring that all necessary documentation, including problem reports, are tracked during development and operation. A CM system can control changes only to those items that have been placed under CM. The implementation representation, design, tests, user and administrator documentation, security flaws, and CM documentation should be placed under CM. The ability to track security flaws under CM ensures that security flaw reports are not lost or forgotten, and allows a developer to track security flaws to their resolution. Application notes There is a requirement that the implementation representation be tracked by the CM system. The implementation representation refers to all hardware, software, and firmware that comprise the physical product/system. In the case of a software-only product, the implementation representation may consist solely of source and object code, but in other cases, the implementation representation may refer to a combination of software, hardware, and firmware. There is a requirement that security flaws be tracked by the CM system. This requires that information regarding previous security flaws and their resolution be maintained, as well as details regarding current security flaws. ACM_SCP.2 Problem tracking CM coverage Developer action elements: ACM_SCP.2.1D: The developer shall provide CM documentation. Content and presentation of evidence elements: ACM_SCP.2.1C: As a minimum, the following shall be tracked by the CM system: the implementation representation, design documentation, test documentation, user documentation, administrator documentation, CM documentation, and security flaws. ACM_SCP.2.2C: The CM documentation shall describe how configuration items are tracked by the CM system. Evaluator action elements: ACM_SCP.2.1E: The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. Delivery and Operation ADO_DEL - Delivery Objectives The requirements for delivery call for system control and distribution facilities and procedures that provide assurance that the recipient receives the product that the sender intended to send, without any modifications. For a valid delivery, what is received must correspond precisely to the master copy, thus avoiding any tampering with the actual version, or substitution of a false version. Application notes This assurance requirement should be applied to sensitive components whose modification can compromise security. ADO_DEL.2 Detection of modification Developer action elements: ADO_DEL.2.1D: The developer shall provide documentation about the procedures for delivery of the product/system or parts of it to the user. ADO_DEL.2.2D: The developer shall use the delivery procedures. Content and presentation of evidence elements: ADO_DEL.2.1C: The delivery documentation shall describe the procedures to be employed when distributing versions of the product/system to a user's site. ADO_DEL.2.2C: The delivery documentation shall state how the procedures are to be employed to detect modifications. ADO_DEL.2.3C: The delivery documentation shall describe how the various procedures and technical measures provide for the detection of modifications, or any discrepancy between the developer's master copy and the version received at the user site. ADO_DEL.2.4C: The delivery documentation shall describe how the various procedures allow detection of attempted masquerading even in cases in which the developer has sent nothing to the user's site. Evaluator action elements: ADO_DEL.2.1E: The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. Delivery and Operation ADO_IGS - Installation, Generation, and Start-up Objectives Installation, generation, and start-up procedures are useful for ensuring that the product has been installed, generated, and started in a secure manner as intended by the developer. Application notes The generation requirements are applicable only to the products that provide the ability to generate an operational product from source or object code. The installation, generation, and start-up procedures may exist as a separate document, but would typically be grouped with other administrative guidance. ADO_IGS.1 Installation, generation, and start-up procedures Developer action elements: ADO_IGS.1.1D: The developer shall document procedures to be used for the secure installation, generation, and start-up of the product/system. Content and presentation of evidence elements: ADO_IGS.1.1C: The documentation shall describe the steps necessary for secure installation, generation, and start-up of the product/system. Evaluator action elements: ADO_IGS.1.1E: The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. Development ADV_FSP - Functional Specification Objectives The functional specification is a high-level description of the user-visible interface and behavior of the product/system. It is a refinement of the statement of functional requirements for the product/system. The functional specification must show that all defined functional requirements are addressed, and that the product/system security policy is enforced by the system. Application notes In addition to the content indicated in the following requirements, the functional specification shall also include any additional specific detail specified by the documentation notes in the related functional components. For example, it shall contain the specification of the interaction (protocol) among various product/system components. The developer must provide evidence that the product/system is completely represented by the functional specification. While a functional specification for the entire product/system would allow an evaluator to determine the product/system boundary, it is not necessary to require that specification when other evidence could be provided to demonstrate the product/system boundary. The evaluator of the product/system is expected to make determinations regarding the relevance of the functional specification to the functional requirements. In the course of the functional specification evaluation, there are essentially three types of evaluator determination: specific functional requirements are met and no further work (e.g., with a less abstract representation of the product/system) is necessary; specific functional requirements are violated and the product/system fails to meet its requirements; and specific functional requirements have not been addressed and further analysis (of another product/system representation) is necessary. Whenever additional analysis is necessary, the evaluator is expected to carry that information forward to the analysis of other product/system representations. If requirements are not addressed after the analysis of the last provided product/system representation, this also represents a failure of the product/system evaluation. In all cases, it is important that the evaluator evaluate the product/system as a unit since in many cases the security functions must cooperate to meet specific functional requirements and also each security function must not interfere with the operation of any other security function. An informal security policy model can be representation of the security policy in any notation, including a series of statements in the English Language. ADV_FSP.1 Functional specification and security policy Developer action elements: ADV_FSP.1.1D: The developer shall provide a functional specification. ADV_FSP.1.2D: The developer shall provide a product/system security policy. Content and presentation of evidence elements: ADV_FSP.1.1C: The functional specification shall describe the product/system using an informal style. ADV_FSP.1.2C: The functional specification shall include an informal presentation of syntax and semantics of all external product/system interfaces. ADV_FSP.1.3C: The functional specification shall include evidence that demonstrates that the product/system is completely represented. Evaluator action elements: ADV_FSP.1.1E: The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ADV_FSP.1.2E: The evaluator shall determine that the functional specification is consistent with the product/system security policy. ADV_FSP.1.3E: The evaluator shall determine if the functional requirements are addressed by the representation of the product/system, i.e., the functional specification. ADV_FSP.2 Informal security policy model Developer action elements: ADV_FSP.2.1D: The developer shall provide a functional specification. ADV_FSP.2.2D: The developer shall provide a product/system security policy. ADV_FSP.2.3D: The developer shall provide an informal security policy model. ADV_FSP.2.4D: The developer shall provide a demonstration of correspondence between the informal security policy model and the functional specification. Content and presentation of evidence elements: ADV_FSP.2.1C: The functional specification shall describe the product/system using an informal style. ADV_FSP.2.2C: The functional specification shall include an informal presentation of syntax and semantics of all external product/system interfaces. ADV_FSP.2.3C: The functional specification shall include evidence that demonstrates that the product/system is completely represented. ADV_FSP.2.4C: The demonstration of correspondence between the informal security policy model and the functional specification shall describe how the functional specification satisfies the informal security policy model. ADV_FSP.2.5C: The demonstration of correspondence between the informal security policy model and the functional specification shall show that there are no security functions in the functional specification that conflict with the informal security policy model. ADV_FSP.2.6C: The informal security policy model shall describe the rules and characteristics of all policies of the product/system that can be modeled. ADV_FSP.2.7C: The informal security policy model shall include a rationale that demonstrates that policies that are modeled are satisfied by the informal security policy model. ADV_FSP.2.8C: The informal security policy model shall justify that all policies that can be modeled are represented in the informal security policy model. Evaluator action elements: ADV_FSP.2.1E: The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ADV_FSP.2.2E: The evaluator shall determine that the functional specification is consistent with the product/system security policy. ADV_FSP.2.3E: The evaluator shall determine if the functional requirements are addressed by the representation of the product/system, i.e., the functional specification. Development ADV_HLD - High-Level Design Objectives The high-level design of a product/system provides a description of the product/system in terms of major structural units (i.e., subsystems) and relates these units to the functions that they contain. The high-level design provides assurance that the product/system provides an architecture appropriate to implement the claimed functional requirements. The high-level design refines the functional specification into subsystems. For each subsystem of the product/system, the high-level design describes its purpose and function and identifies the security functions enforced by the subsystem. The interrelationships of all subsystems are also defined in the high-level design. These interrelationships will be represented as external interfaces for data flow, control flow, etc., as appropriate. Application notes In addition to the content indicated in the following requirements, the high- level design shall also include any additional specific detail specified by the documentation notes in the related functional components. The developer is expected to describe the design of the product/system in terms of subsystems. The term ``subsystem'' is used here to express the idea of decomposing the product/system into a relatively small number of parts. While the developer is not required to actually have ``subsystems'', the developer is expected to represent a similar level of decomposition. For example, a design may be similarly decomposed using ``layers'', ``domains'', or ``servers''. The evaluator of the product/system is expected to make determinations regarding the functional requirements in the product relevant to the high-level design. In the course of the high-level design evaluation, there are essentially three types of evaluator determination: specific functional requirements are met and no further work (e.g., with a less abstract representation of the product/system) is necessary; specific functional requirements are violated and the product/system fails to meet its requirements; and specific functional requirements have not been addressed and further analysis (of another product/system representation) is necessary. Whenever more analysis is necessary, the evaluator is expected to carry that information forward to the analysis of other product/system representations. If requirements are not addressed after the analysis of the last provided product/system representation, this also represents a failure of the product/system evaluation. In all cases, it is important that the evaluator evaluate the product/system as a unit since in many cases the security functions must cooperate to meet specific functional requirements and also each security function must not interfere with the operation of any other security function. The term ``security functionality'' is used to represent operations that a subsystem performs that have some effect on the security functions implemented by the product. This distinction is made because design constructs, such as subsystems and modules, do not necessarily relate to specific security functions. While a given subsystem may correspond directly to a security function, or even multiple security functions, it is also possible that many subsystems must be combined to implement a single security function. The term ``security policy enforcing subsystems'' refers to a subsystem that contributes to the enforcement of the security policy. ADV_HLD.1 Descriptive high-level design Developer action elements : ADV_HLD.1.1D: The developer shall provide the high-level design of the product/system. Content and presentation of evidence elements: ADV_HLD.1.1C: The presentation of the high-level design shall be informal. ADV_HLD.1.2C: The high-level design shall describe the structure of the product/system in terms of subsystems. ADV_HLD.1.3C: The high-level design shall describe the security functionality provided by each subsystem of the product/system. ADV_HLD.1.4C: The high-level design shall identify the interfaces of the subsystems of the product/system. ADV_HLD.1.5C: The high-level design shall identify any underlying hardware, firmware, and/or software required by the product/system with a presentation of the functions provided by the supporting protection mechanisms implemented in that hardware, firmware, or software. Evaluator action elements: ADV_HLD.1.1E: The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ADV_HLD.1.2E: The evaluator shall determine if the functional requirements in the product/system are addressed by the design. ADV_HLD.2 Security enforcing high-level design Developer action elements : ADV_HLD.2.1D: The developer shall provide the high-level design of the product/system. Content and presentation of evidence elements: ADV_HLD.2.1C: The presentation of the high-level design shall be informal. ADV_HLD.2.2C: The high-level design shall describe the structure of the product/system in terms of subsystems. ADV_HLD.2.3C: The high-level design shall describe the security functionality provided by each subsystem of the product/system. ADV_HLD.2.4C: The high-level design shall identify the interfaces of the subsystems of the product/system. ADV_HLD.2.5C: The high-level design shall identify any underlying hardware, firmware, and/or software required by the product/system with a presentation of the functions provided by the supporting protection mechanisms implemented in that hardware, firmware, or software. ADV_HLD.2.6C: The high-level design shall describe the separation of the product/system into security policy enforcing and other subsystems. Evaluator action elements: ADV_HLD.2.1E: The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ADV_HLD.2.2E: The evaluator shall determine if the functional requirements in the product/system are addressed by the design. Development ADV_IMP - Implementation Representation Objectives The description of the implementation in the form of source code, firmware, hardware drawings, etc. captures the detailed internal workings of the product in support of analysis. Application notes The implementation representation is used to express the notion of the least abstract representation of the product/system, specifically the one that is used to create the product/system itself without further design refinement. Source code which is then compiled or a hardware drawing which is used to build the actual hardware are examples of parts of an implementation representation. The evaluator of the product/system is expected to make determinations regarding the functional requirements in the ST relevant to the implementation. In the course of the implementation evaluation, there are essentially three types of evaluator determination: specific functional requirements are met and no further work (e.g., with a more abstract representation of the product/system) is necessary; specific functional requirements are violated and the product/system fails to meet its requirements; and specific functional requirements have not been addressed and further analysis is necessary. However, since the implementation is the least abstract representation it is likely that further analysis cannot be performed unless the product/system representations have not been evaluated in the usual order (i.e., most abstract to least abstract). If requirements are not addressed after the analysis of all product/system representations, this represents a failure of the product/system evaluation. Note that this more comprehensive failure determination requirement is realized in the Representation correspondence (ADV_RCR) family. In all cases, it is important that the evaluator evaluates the product/system as a unit since, in many cases, the security functions must cooperate to meet specific functional requirements and each security function must not interfere with the operation of any other security function. It is expected that evaluators will use the implementation to directly support other evaluation activities (e.g., vulnerability analysis, test coverage analysis). ADV_IMP.1 Subset of the implementation Application notes The implementation representation needs to be provided for the security relevant functions of the product/system. Any hardware, software, and/or firmware that does not contribute to the security need not be provided, analyzed, or tested. However, an explanation must be provided, and the evaluator must agree that the excluded items are not security relevant. Developer action elements: ADV_IMP.1.1D: The developer shall provide the implementation representations for a selected subset of the product/system. Content and presentation of evidence elements: ADV_IMP.1.1C: The implementation representations shall unambiguously define the product/system to a level of detail such that it can be generated without further design decisions. Evaluator action elements: ADV_IMP.1.1E: The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ADV_IMP.1.2E: The evaluator shall determine if the CKRS functional requirements are addressed by the representation of the product/system. Development ADV_LLD - Low-Level Design Objectives The low-level design of a product/system provides a description of the internal workings of the product/system in terms of modules and their interrelationships and dependencies. The low-level design provides assurance that the subsystems have been correctly and effectively refined. For each module of the product/system, the low-level design describes its purpose, function, interfaces, dependencies, and the implementation of any security policy enforcing functions. Application notes In addition to the content indicated in the following requirements, the low- level design shall also include any additional specific detail specified by the documentation notes in the related functional components. The evaluator of the product/system is expected to make determinations regarding the functional requirements relevant to the low-level design. In the course of the low-level design evaluation, there are essentially three types of evaluator determination: specific functional requirements are met and no further work (e.g., with a less abstract representation of the product/system) is necessary; specific functional requirements are violated and the product/system fails to meet its requirements; and specific functional requirements have not been addressed and further analysis (of another product/system representation) is necessary. Whenever more analysis is necessary, the evaluator is expected to carry that information forward to the analysis of other product/system representations. If requirements are not addressed after the analysis of the last provided product/system representation, this also represents a failure of the product/system evaluation. Note that this more comprehensive failure determination requirement is realised in the Representation correspo! ndence (ADV_RCR) family. In all cases, it is important that the evaluator evaluates the product/system as a unit since, in many cases, the security functions must cooperate to meet specific functional requirements and also each security function must not interfere with the operation of any other security function. ADV_LLD.1 Descriptive low-level design Application notes Only representations for modules in the product/system need to be provided. Developer action elements: ADV_LLD.1.1D: The developer shall provide the low-level design of the product/system. Content and presentation of evidence elements: ADV_LLD.1.1C: The presentation of the low-level design shall be informal. ADV_LLD.1.2C: The low-level design shall describe the product/system in terms of modules. ADV_LLD.1.3C: The low-level design shall describe the purpose of each module. ADV_LLD.1.4C: The low-level design shall define the interrelationships between the modules in terms of provided functionality and dependencies on other modules. ADV_LLD.1.5C: The low-level design shall describe the implementation of all security policy enforcing functions. ADV_LLD.1.6C: The low-level design shall describe the interfaces of each module in terms of their syntax and semantics. ADV_LLD.1.7C: The low-level design shall provide a demonstration that the product/system is completely represented. ADV_LLD.1.8C: The low-level design shall identify the interfaces of the modules of the product/system visible at the external interface of the product/system. Evaluator action elements: ADV_LLD.1.1E: The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ADV_LLD.1.2E: The evaluator shall determine if the functional requirements in the CKRS are addressed by the representation of the product/system. Development ADV_RCR - Representation Correspondence Objectives The correspondence between the various representations (i.e. functional requirements expressed in the CKRS, functional specification, high-level design, low-level design, implementation) addresses the correct and complete instantiation of the requirements to the least abstract representation provided. This conclusion is achieved by step-wise refinement and the cumulative results of correspondence determinations between all adjacent abstractions of representation. Application notes The developer must demonstrate to the evaluator that the most detailed, or least abstract, representation of the product/system is an accurate, consistent, and complete instantiation of the functions expressed as functional requirements in the CKRS. This is accomplished by showing correspondence between adjacent representations at a commensurate level of rigor. The evaluator must analyze each demonstration of correspondence between abstractions, as well as the results of the analysis of each product/system representation, and then make a determination as to whether the functional requirements in the CKRS have been satisfied. This family of requirements is not intended to address correspondence relating to the security policy model. Rather, it is intended to address correspondence between the requirements in the CKRS as well as the product/system, functional specification, high-level design, low-level design, and implementation representation. ADV_RCR.1 Informal correspondence demonstration Developer action elements: ADV_RCR.1.1D: The developer shall provide evidence that the least abstract product/system representation provided is an accurate, consistent, and complete instantiation of the functional requirements expressed in the CKRS. Content and presentation of evidence elements: ADV_RCR.1.1C: For each adjacent pair of product/system representations, the evidence shall demonstrate that all parts of the more abstract representation are refined in the less abstract representation. ADV_RCR.1.2C: For each adjacent pair of product/system representations, the demonstration of correspondence between the representations may be informal. Evaluator action elements: ADV_RCR.1.1E: The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ADV_RCR.1.2E: The evaluator shall analyze the correspondence between the functional requirements expressed in the CKRS and the least abstract representation provided to ensure accuracy, consistency, and completeness. Guidance Documents AGD_ADM Administrator Guidance Objectives Administrator guidance refers to written material that is intended to be used by those persons responsible for configuring, maintaining, and administering the product/system in a correct manner for maximum security. Because the secure operation of the product/system is dependent upon the correct performance of the product/system, persons responsible for performing these functions are trusted by the product/system. Administrator guidance is intended to help administrators understand the security functions provided by the product/system, including both those functions that require the administrator to perform security-critical actions and those functions that provide security-critical information. Application notes The requirements AGD_ADM.1.2C and AGD_ADM.1.11C encompass the aspect that any warnings to the users of a product/system with regard to the product/system security environment and the security objectives described in the CKRS are appropriately covered in the administrator guidance. Those topics that are relevant to administrator guidance for understanding and proper application of the security functions should be considered for inclusion in the administrator guidance requirements. An example of an administrator guidance document is a reference manual. AGD_ADM.1 Administrator guidance Developer action elements: AGD_ADM.1.1D: The developer shall provide administrator guidance addressed to system administrative personnel. Content and presentation of evidence elements: AGD_ADM.1.1C: The administrator guidance shall describe how to administer the product/system in a secure manner. AGD_ADM.1.2C: The administrator guidance shall contain warnings about functions and privileges that should be controlled in a secure processing environment. AGD_ADM.1.3C: The administrator guidance shall contain guidelines on the consistent and effective use of the security functions within the product/system. AGD_ADM.1.4C: The administrator guidance shall describe the difference between two types of functions: those which allow an administrator to control security parameters, and those which allow the administrator to obtain information only. AGD_ADM.1.5C: The administrator guidance shall describe all security parameters under the administrator's control. AGD_ADM.1.6C: The administrator guidance shall describe each type of security- relevant event relative to the administrative functions that need to be performed, including changing the security characteristics of entities under the control of the product/system. AGD_ADM.1.7C: The administrator guidance shall contain guidelines on how the security functions interact. AGD_ADM.1.8C: The administrator guidance shall contain instructions regarding how to configure the product/system. AGD_ADM.1.9C: The administrator guidance shall describe all configuration options that may be used during the secure installation of the product/system. AGD_ADM.1.10C: The administrator guidance shall describe details, sufficient for use, of procedures relevant to the administration of security. AGD_ADM.1.11C: The administrator guidance shall be consistent with all other documents supplied for evaluation. Evaluator action elements: AGD_ADM.1.1E: The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. AGD_ADM.1.2E: The evaluator shall confirm that the installation procedures result in a secure configuration. Guidance Documents AGD_USR - User Guidance Objectives User guidance refers to written material that is intended to be used by non- administrative (human) users of the product/system. User guidance describes the security functions provided by the product/system and provides instructions and guidelines, including warnings, for its secure use. The user guidance provides a basis for assumptions about the use of the product/system and a measure of confidence that non-malicious users and application providers will understand the secure operation of the product/system and will use it as intended. Application notes The requirement AGD_USR.1.3.C and AGD_USR.1.5C encompass the aspect that any warnings to the users of a product/system with regard to the product/system security environment and the security objectives described in the CKRS are appropriately covered in the user guidance. Those topics in CKRS that are relevant to user guidance aimed at the understanding and proper use of the security functions should be considered for inclusion in the user guidance requirements. Examples of user guidance are reference manuals, user guides, and on-line help. AGD_USR.1 User guidance Developer action elements: AGD_USR.1.1D: The developer shall provide user guidance. Content and presentation of evidence elements: AGD_USR.1.1C: The user guidance shall describe the product/system and interfaces available to the user. AGD_USR.1.2C: The user guidance shall contain guidelines on the use of security functions provided by the product/system. AGD_USR.1.3C: The user guidance shall contain warnings about functions and privileges that should be controlled in a secure processing environment. AGD_USR.1.4C: The user guidance shall describe the interaction between user- visible security functions. AGD_USR.1.5C: The user guidance shall be consistent with all other documentation delivered for evaluation. Evaluator action elements: AGD_USR.1.1E: The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. Life Cycle Support ALC_FLR - Flaw Remediation Objectives Flaw remediation requires that discovered flaws be tracked and corrected by the developer. Although future compliance with flaw remediation procedures cannot be determined at the time of the product/system evaluation, it is possible to evaluate the policies and procedures that a developer has in place to track and correct flaws, and to distribute the flaw information and corrections. Application notes None ALC_FLR.2 Flaw reporting procedures Developer action elements: ALC_FLR.2.1D: The developer shall document the flaw remediation procedures. ALC_FLR.2.2D: The developer shall establish a procedure for accepting and acting upon user reports of security flaws and requests for corrections to those flaws. Content and presentation of evidence elements: ALC_FLR.2.1C: The flaw remediation procedures documentation shall describe the procedures used to track all reported security flaws in each release of the product/system. ALC_FLR.2.2C: The flaw remediation procedures shall require that a description of the nature and effect of each security flaw be provided, as well as the status of finding a correction to that flaw. ALC_FLR.2.3C: The flaw remediation procedures shall require that corrective actions be identified for each of the security flaws. ALC_FLR.2.4C: The flaw remediation procedures documentation shall describe the methods used to provide flaw information and corrections to product/system users. ALC_FLR.2.5C: The procedures for processing reported security flaws shall ensure that any reported flaws are corrected and the correction issued to product/system users. Evaluator action elements: ALC_FLR.2.1E: The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. Tests ATE_COV - Coverage Objectives This family addresses those aspects of testing that deal with completeness of testing. That is, it addresses the extent to which the product/system security functions are tested, whether or not the testing is sufficiently extensive to demonstrate that the product/system operates as specified, and whether or not the order in which testing proceeds correctly accounts for functional dependencies between the portions of the product/system being tested. Application notes The specific documentation required by the coverage components will be determined, in most cases, by the documentation stipulated in the level of ATE_FUN that is specified. ATE_COV.1 Complete coverage - informal Objectives In this component, the objective is that testing completely address the security functions. Application notes While the testing objective is to completely cover the product/system, there is no more than informal explanation to support this assertion. Developer action elements: ATE_COV.1.1D: The developer shall provide an analysis of the test coverage. Content and presentation of evidence elements: ATE_COV.1.1C: The analysis of the test coverage shall demonstrate that the tests identified in the test documentation cover the product/system. Evaluator action elements: ATE_COV.1.1E: The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. Tests ATE_DPT - Depth Objectives The components in this family deal with the level of detail to which the product/system is tested. Testing of security functions is based upon an increasing depth of information derived from the analysis of the representations. The objective is to counter the risk of missing an error in the development of the product/system. Additionally, the components of this family, especially as testing is more concerned with the internals of the product/system, are more likely to discover any malicious code that has been inserted. Application notes The specific amount and type of documentation and evidence will, in general, be determined by that required by the level of ATE_FUN selected. ATE_DPT.1 Testing - functional specification Objectives The functional specification of a product/system provides a high level description of the external workings of the product/system. Testing at the level of the functional specification, in order to demonstrate the presence of any flaws, provides assurance that the product/system functional specification has been correctly realized. Application notes The functional specification representation is used to express the notion of the most abstract representation of the product/system. Developer action elements: ATE_DPT.1.1D: The developer shall provide the analysis of the depth of testing. Content and presentation of evidence elements: ATE_DPT.1.1C: The depth analysis shall demonstrate that the tests identified in the test documentation are sufficient to demonstrate that the product/system operates in accordance with the functional specification of the product/system. Evaluator action elements: ATE_DPT.1.1E: The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. Tests ATE_FUN - Functional Tests Objectives Functional testing establishes that the product/system exhibits the properties necessary to satisfy the functional requirements of CKRS. Functional testing provides assurance that the product/system satisfies at least the security functional requirements, although it cannot establish that the product/system does no more than what was specified. The family ``Functional tests'' is focused on the type and amount of documentation or support tools required, and what is to be demonstrated through testing. This family contributes to providing assurance that the likelihood of undiscovered flaws is relatively small. Application notes Procedures for performing tests are expected to provide instructions for using test programs and test suites, including the test environment, test conditions, test data parameters and values. The test procedures should also show how the test results are derived from the test inputs. The developer shall eliminate all security relevant flaws discovered during testing. The developer shall test the product/system to determine that no new security relevant flaws have been introduced as a result of eliminating discovered security relevant flaws. Tests shall include examination of procedures and documents that assist in implementing the product/system security policy. ATE_FUN.1 Functional testing Objectives The objective is for the developer to demonstrate that all security functions perform as specified. The developer is required to perform testing and to provide test documentation. Developer action elements: ATE_FUN.1.1D: The developer shall test the product/system and document the results. ATE_FUN.1.2D: The developer shall provide test documentation. Content and presentation of evidence elements: ATE_FUN.1.1C: The test documentation shall consist of test plans, test procedure descriptions, and test results. ATE_FUN.1.2C: The test plans shall identify the security functions to be tested and describe the goal of the tests to be performed. ATE_FUN.1.3C: The test procedure descriptions shall identify the tests to be performed and describe the scenarios for testing each security function. ATE_FUN.1.4C: The test results in the test documentation shall show the expected results of each test. ATE_FUN.1.5C: The test results from the execution of the tests by the developer shall demonstrate that each security function operates as specified. Evaluator action elements: ATE_FUN.1.1E: The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. Tests ATE_IND - Independent Testing Objectives The objective is to demonstrate that the security functions perform as specified. Additionally, an objective is to counter the risk of an incorrect assessment of the test outcomes on the part of the developer which results in the incorrect implementation of the specifications, or overlooks code that is non-compliant with the specifications. Application notes The testing specified in this family can be performed by a party other than the evaluator (e.g., an independent laboratory, an objective consumer organization). This family deals with the degree to which there is independent functional testing of the product/system. Independent functional testing may take the form of repeating the developer's functional tests in whole or in part. It may also take the form of the augmentation of the developer's functional tests, either to extend the scope or the depth of the developer's tests. ATE_IND.2 Independent testing - sample Objectives The objective is to demonstrate that the security functions perform as specified. In this component, the objective is to select and repeat a sample of the developer testing. Application notes The suitability of the product/system for testing is based on the access to the product/system, and the supporting documentation and information required to run tests. The need for documentation is supported by other assurance families (e.g., ATE_FUN) Additionally, the suitability of the product/system for testing may be based on other considerations (e.g., the version of the product/system submitted by the developer is not the final version). The developer is required to perform testing and to provide test documentation and test results. This is addressed by the ATE_FUN family. Testing may be selective and shall be based upon all available documentation. Developer action elements: ATE_IND.2.1D: The developer shall provide the product/system for testing. Content and presentation of evidence elements: ATE_IND.2.1C: The product/system shall be suitable for testing. Evaluator action elements: ATE_IND.2.1E: The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ATE_IND.2.2E: The evaluator shall test the product/system to confirm that the product/system operates as specified. ATE_IND.2.3E: The evaluator shall execute a sample of tests in the test documentation to verify the developer test results. Vulnerability Assessment AVA_VLA - Vulnerability Analysis Objectives Vulnerability analysis is an assessment to determine whether vulnerabilities could allow malicious users to violate the security policy. These vulnerabilities will be identified during the evaluation by flaw hypotheses, Vulnerability analysis deals with the threats that a malicious user will be able to discover flaws that will allow access to resources (e.g., data), allow the ability to interfere with or alter the product/system, or interfere with the authorized capabilities of other users. Application notes The vulnerability analysis should consider the contents of all the product/system deliverables for the targeted evaluation assurance level. Obvious vulnerabilities are those that allow common attacks or those that might be suggested by the product/system interface description. Obvious vulnerabilities are those in the public domain, details of which should be known to a developer, publicly available, or available from NIST. The evidence identifies all the product/system documentation upon which the search for flaws was based. AVA_VLA.1 Developer vulnerability analysis Objectives A vulnerability analysis is performed by the developer to ascertain the presence of ``obvious'' security vulnerabilities. The objective is to confirm that no identified security vulnerabilities can be exploited in the intended environment for the product/system. Application notes Obvious vulnerabilities are those which are open to exploitations which require a minimum of understanding of the product/system, skill, technical sophistication, and resources. Developer action elements: AVA_VLA.1.1D: The developer shall perform and document an analysis of the product/system deliverables searching for obvious ways in which a user can violate the security policy. AVA_VLA.1.2D: The developer shall document the disposition of identified vulnerabilities. Content and presentation of evidence elements: AVA_VLA.1.1C: The evidence shall show, for each vulnerability, that the vulnerability cannot be exploited in the intended environment for the product/system. Evaluator action elements: AVA_VLA.1.1E: The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. AVA_VLA.1.2E: The evaluator shall conduct penetration testing, based on the developer vulnerability analysis, to ensure that obvious vulnerabilities have been addressed. This section contains the Common Criteria assurance requirements that are recommended for exclusion. ADV_INT family relates to modularity, layering, information hiding, etc. For economic reasons, this family is applied to delux assurance level only. ALC_DVS (Developmental Security), ALC_LCD (Life Cycle Definition), and ALC_TAT (Tools and Techniques) are excluded in order to provide vendors engineering independence, spur commercial product development, and align assurance requirements with the commercial practices. AVA_CCA (Covert Channel Analysis), AVA_SOF (Strength of Function, e.g., work factor for cryptographic operation) are excluded since they are not particularly relevant here. AVA_CCA in non-discretionary policy environments can be implemented using procedural controls such as executing trusted software only. Cryptanalysis work factors will be provided or implied by the FIPS cryptographic algorithms. AVA_MSU (Misuse Analysis) is excluded since obvious flaws and known flaws will come under AVA_VLA (Vulnerability Analysis). Given this is a standard for SBU data, vulnerability analysis may be an overkill.