Transition guide for ALC, ACM, ADO and AGD. Version 2.0,

Transcription

1 Transition guide for ALC, ACM, ADO and AGD Version 2.0,

2 Transition guide for ALC, ACM, ADO and AGD Version 2.0, Bundesamt für Sicherheit in der Informationstechnik Postfach Bonn Tel.: Internet: Bundesamt für Sicherheit in der Informationstechnik Bundesamt für Sicherheit in der Informationstechnik

3 Transition guide for ALC, ACM, ADO and AGD Contents Version 2.0, Contents Contents 3 List of Tables 7 List of Figures 9 List of Abbreviations Introduction Overview of the restructuring Graphical representation of the restructuring Effects on evaluation assurance levels New aspects Integration (RI #183) Production Handling of standards in ALC_TAT (RI #71) Refinement of CM access control Delivery (RI #128, RI #210) Developer IGS Discussion on terminology in ACM-ALC-ADO-AGD Overview Configuration Management Life-cycle Life-cycle model Acceptance ALC_DVS ALC_DVS.1 (Identification of security measures) ALC_DVS.2 (Sufficiency of security measures) Overview of element and work unit coverage ALC_FLR ALC_FLR.1 (Identification of security measures) ALC_FLR.2 (Flaw reporting procedures) ALC_FLR.3 (Systematic flaw remediation) ALC_LCD ALC_LCD.1 (Developer defined life-cycle model) ALC_LCD.2 (Standardised life-cycle model) 27 Bundesamt für Sicherheit in der Informationstechnik 3

4 Contents Transition guide for ALC, ACM, ADO and AGD Version 2.0, ALC_LCD.3 (Measurable life-cycle model) Comments on CC 3.0 Revision 2 (July 2005) Discussion Proposed specific changes in CC and CEM Documents ALC_TAT ALC_TAT.1 (Well-defined development tools) ALC_TAT.2/3 (Compliance with implementation standards/ all parts) ACM_SCP Strict separation of CM capability and scope Components Elements Overview Wording and numbering of the new ALC_CMS elements Verification that the ACM_SCP elements are covered in the new structure Work units ACM_CAP Basic considerations Components Elements Preliminary remarks Overview Wording and numbering of the new ALC_CMC elements Verification that the ACM_CAP elements are covered in the new structure Work units ACM_AUT Merging of CM capability and automation Components Elements Overview Verification that the ACM_AUT elements are covered in the new structure Work units AGD Basic considerations Components 53 4 Bundesamt für Sicherheit in der Informationstechnik

5 Transition guide for ALC, ACM, ADO and AGDContents Version 2.0, Contents 11.3 Elements Work units AVA_MSU Basic considerations Components Elements Work units ADO_DEL / developer s procedures Basic considerations Components Elements Work units ADO_DEL / user s procedures Basic considerations Components Elements Work units ADO_IGS / user s procedures Basic considerations Components Elements Work units ADO_IGS / developer s procedures Basic considerations Components Elements Work units Interactions with ADV_IMP Elements The element ADV_IMP.1.3C The element ADV_IMP.2.2E Concept for a Guideline on Site Visits Motivation Reasons for the Need for a Guidance on Site Visits 73 Bundesamt für Sicherheit in der Informationstechnik 5

6 Contents Transition guide for ALC, ACM, ADO and AGD Version 2.0, Proposal for Annex A.4 in CC 3.x (was Annex B.5 in CC 2.x) Introduction General Approach Orientation Guide for the Preparation of the Check List Example of a checklist Further ideas EAL 1 evaluation Redundancy between ALC_FLR and ACM_SCP Redundancy between the ALC families DVS and LCD Processing of RIs Overview Draft interpretation for RI # Draft interpretation for RI # Draft interpretation for RI # Draft interpretation for RI # Draft interpretation for RI # Draft interpretation for RI # Draft interpretation for RI # Bundesamt für Sicherheit in der Informationstechnik

7 Transition guide for ALC, ACM, ADO and AGDList of Tables Version 2.0, List of Tables List of Tables Table 1: Cross reference of EALs and AGD/ALC components Table 2: Development Security: Correspondence of elements and work units Table 3: Comment on ALC_LCD Table 4: Comment 1 on ALC_LCD Table 5: Comment 2 on ALC_LCD Table 6: Comment 3 on ALC_LCD Table 7: CM Scope: Correspondence of components Table 8: CM Scope: Correspondence of elements Table 9: CM Scope: The new elements Table 10: CM Scope: Coverage of elements Table 11: CM Scope: Correspondence of elements and work units Table 12: CM Capability: Correspondence of components Table 13: CM Capability: Correspondence of elements (levels 1 to 4) Table 14: CM Capability: Correspondence of elements (level 5) Table 15: CM Capability: The new elements Table 16: CM Capability: Coverage of elements Table 17: CM Capability: Correspondence of elements and work units Table 18: CM Automation: Mapping of components Table 19: CM Automation: Mapping of elements Table 20: CM Automation: Coverage of elements Table 21: CM Automation: Mapping of work units Table 22: Guidance Documents: Mapping of components Table 23: Guidance Documents: Coverage of elements Table 24: Guidance Documents: Coverage of work units Table 25: Misuse: Mapping of components Table 26: Misuse: Coverage of elements Table 27: Misuse: Coverage of work units Table 28: Delivery (developer s procedures): Mapping of components Table 29: Delivery (developer s procedures): Mapping of elements Table 30: Delivery (user s procedures): Mapping of components Table 31: Delivery (user s procedures): Mapping of elements Table 32: IGS (user s procedures): Mapping of components Table 33: IGS (user s procedures): Coverage of elements Table 34: IGS (developer s procedures): Mapping of components Table 35: IGS (developer s procedures): Coverage of elements Table 36: IGS (developer s procedures): Coverage of work units Table 37: Checklist part A: Examination of the CM system Table 38: Checklist part B: Examination of the delivery procedures Table 39: Checklist part C: Examination of the developer security Table 40: Consideration of RIs Table 41: RI #26: Identifying (and controlling) CIs for ACM_CAP Bundesamt für Sicherheit in der Informationstechnik 7

8 List of Tables Transition guide for ALC, ACM, ADO and AGD Version 2.0, Table 42: RI #71: No quality measures for development tools and implementation standards Table 43: RI #99: Configuration Items in the Absence of Explicit Scope Table 44: RI #179: When to meet ALC_DVS and ALC_LCD Table 45: RI #183: Life-cycle Specification Table 46: RI #196: Splitting CM into separate parts Table 47: RI #210: Security and "Confidentiality" Bundesamt für Sicherheit in der Informationstechnik

9 Transition guide for ALC, ACM, ADO and AGD Version 2.0, List of Figures List of Figures Figure 1: Mapping of the CC 2.3 classes and families considered here to CC 3.1 classes and families 13 Figure 2: Graphical overview of the terminology in CM and in the Product Life Cycle 19 Figure 3: Guidance Documents: Mapping of elements 54 Figure 4: Misuse: Mapping of elements 59 Bundesamt für Sicherheit in der Informationstechnik 9

10 List of Abbreviations Transition guide for ALC, ACM, ADO and AGD Version 2.0, List of Abbreviations Apart from the abbreviations commonly used in the CC and CEM, the following abbreviations are used throughout this document: AIS BSI CCMB CCIMB CI CM ISO ITSEC QM RI URL v WU Application Notes and Interpretation of the Scheme (used in the German Certification Scheme) Bundesamt für Sicherheit in der Informationstechnik (German Certification Overseer) Common Criteria Maintenance Board Common Criteria International Maintenance Board (former denotation of the CCMB) Configuration item Configuration management International Organization for Standardization Information Technology Security Evaluation Criteria Quality management Request for Interpretation Uniform Resource Locator Version Work unit 10 Bundesamt für Sicherheit in der Informationstechnik

11 Transition guide for ALC, ACM, ADO and AGD Version 2.0, Introduction Overview of the restructuring 1. Introduction 1.1 Overview of the restructuring This document describes and justifies the modifications made in the new structure (i.e. version 3.1 of the Common Criteria and CEM) relative to the last official version 2.3 ( previous criteria ) insofar the classes ALC, ACM, ADO, AGD and the component AVA_MSU.1 are concerned. Changes suggested by the version 2.4 and by open RIs are not treated as previous criteria here, though they have also been taken into account and, if incorporated into the new structure, are treated as modifications of the previous criteria. The processing of RIs in the new concept is described in detail in chapter 20. The objectives of the reorganisation have primarily been to eliminate redundancies and to enhance clarification of the evaluation work, not to modify the contents of the concerned classes. (However, minor changes of the contents have been made here and there if sensible and helpful for the objectives.) A graphical representation of the restructuring is given in section 1.2. In order to clarify the structure, we have tried to set up the minimal life-cycle model that is implicitly assumed by the CC (see chapter 3.3.1), and to bring the CC classes and families in line with the life-cycle phases. The main part of this document (chapters 4 to 16) explains how the considered parts of the previous criteria are embedded into the new structure. Most assurance families are treated in one chapter, some families are split up, the two AGD families are treated conjointly in one chapter. The families DVS, FLR, LCD, and TAT of the present ALC class are taken over in the new ALC class retaining their denotations. Their modifications in the new structure are described in the chapters 4 to 7. Configuration management is an essential part of those measures implemented in order to guarantee a welldefined life-cycle process for a product. So it seems reasonable (and is done in the new structure) to deal with the overlapping between ACM and ALC by consolidating these two classes into one new class. Since ALC ( Life-cycle support ) is the more general term, this one is chosen as name of the new class. The ACM families SCP and CAP are transferred into the new ALC class. Since they are reorganised (strict separation of capability and scope), they get the new denotations CMS resp. CMC (cf. chapters 8.1 and 9.1). The ACM family AUT is integrated into CMC (cf. chapter 10.1). The present AGD class deals with the operational phase of the TOE (cf. chapter 11.1). The two families USR and ADM have many similar requirements and belong to the same life-cycle phase, so they are combined to a single new family denoted by AGD_OPE ( Operational user guidance ). The distinction of user types is managed by the introduction of a role concept. The family AVA_MSU overlaps strongly with AGD and is dissolved in the new structure. The nonredundant MSU requirements are moved to AGD and to AVA_VAN (cf. chapter 0; the description of AVA_VAN, which replaces the previous AVA_VLA, is outside of the scope of this document). The ADO class is dissolved in the new structure. Presently it consists of the two families DEL ( Delivery ) and IGS ( Installation, generation and start-up ) which are treated as follows: DEL concerns mainly the developer. The developer delivery activities are shifted into ALC as a new family ALC_DEL (cf. chapter 13). The user delivery activities (i.e. acceptance procedures of the delivered TOE) are merged into the new family AGD_PRE mentioned below (cf. chapter 14), IGS concerns mainly the user. The user IGS activities are shifted into AGD as a new family AGD_PRE ( Preparative procedures ) (cf. chapter 15). The developer IGS activities are essentially covered by CMC requirements (cf. chapter 16). Bundesamt für Sicherheit in der Informationstechnik 11

12 Introduction Transition guide for ALC, ACM, ADO and AGD Overview of the restructuring Version 2.0, Thus the AGD class in the new structure consists of the two families OPE and PRE and assembles all the user procedures. The two AGD families might even be merged into a single one, but because of the correspondence to life-cycle phases, we have preferred the separate treatment. Chapter 17 discusses some interdependencies with ADV_IMP. Chapter 18 contains a concept for a guideline on site visits. A guideline on delivery procedures is in preparation. There are not necessarily impacts on elements and work units. Some new aspects and their consideration in the new criteria are discussed in chapter 2, some further ideas in chapter 19. Note: When the old and new denotation of a family/component/element/work unit differ, they are sometimes indicated both consecutively, the old one crossed out, for instance AVA_VLAVAN or ALC_LCD Bundesamt für Sicherheit in der Informationstechnik

13 Transition guide for ALC, ACM, ADO and AGD Introduction Version 2.0, Graphical representation of the restructuring 1.2 Graphical representation of the restructuring CC 3.1 structure ALC AGD AVA Configuration Management Infrastructural Management Quality & Project Management CMS Scope CMC Capability DVS Developer Security FLR Flaw remediation LCD Life Cycle Def. TAT Tools &Techniques DEL Delivery PRE Preparation OPE Operation VAN Vuln. Analysis Developer Developer User User SCP Scope CAP Capability AUT Automation DVS Developer Security FLR Flaw remediation LCD Life Cycle Def. TAT Tools &Techniques DEL Delivery IGS Install. Gener. Startup ADM Admin. Guidance USR User Guidance MSU.1 Misuse Exam. Guid. MSU.2/3 Misuse Analys. Testing VLA Vuln. Analysis ACM ALC ADO AGD AVA CC 2.3 structure Figure 1: Mapping of the CC 2.3 classes and families considered here to CC 3.1 classes and families Bundesamt für Sicherheit in der Informationstechnik 13

14 Introduction Transition guide for ALC, ACM, ADO and AGD Effects on evaluation assurance levels Version 2.0, Effects on evaluation assurance levels The following table describes the relationship between the evaluation assurance levels and the assurance families and components in the new assurance classes considered here: Assurance Class Assurance Family Assurance Components by Evaluation Assurance Level EAL1 EAL2 EAL3 EAL4 EAL5 EAL6 EAL7 Guidance AGD_OPE documents AGD_PRE Life-cycle support ALC_CMC ALC_CMS ALC_DEL ALC_DVS ALC_FLR ALC_LCD ALC_TAT Table 1: Cross reference of EALs and AGD/ALC components 14 Bundesamt für Sicherheit in der Informationstechnik

15 Transition guide for ALC, ACM, ADO and AGD New aspects Version 2.0, Integration (RI #183) 2. New aspects 2.1 Integration (RI #183) Here integration means the inclusion of parts into the TOE which have been produced by other manufacturers. (The instance joining the parts together is called the integrator.) The question is how these parts have to be taken into account by the evaluation. Two subcases can be distinguished: 1. If all of the integrated parts have already been certified on at least the assurance level of the actual evaluation, this is the situation of a composition evaluation (in the sense of the CC supporting document ETR-lite for composition ). Then the evaluation of the integration procedure consists of verifying the composition requirements. An issue arises when the ETR of an integrated certified part contains proprietary information that cannot be made available to the integrator. For this case it has been suggested to compile the needed information in an additional document, the so-called ETR-lite for composition. This should be a subset of the ETR and must be usable for the specific needs of the composition evaluation. ETR-lite issue : Is it possible to substitute the ETR of a certified integrated part of the TOE by a document that contains less information on the integrated product? The treatment of this issue is left to the UK working group on composition evaluation. 2. If parts are integrated in the TOE which have not yet been evaluated, or have only been evaluated on a lower level, then it arises the Integration issue : Is it possible to substitute lacking or unknown adherence of ALC requirements at subcontractors sites by acceptance procedures? The previous criteria didn t make an explicit statement on this. That meant implicitly, the ALC requirements had to be adhered from the beginning of the life-cycle, in particular at subcontractors sites. So the answer to the issue was No. (However, no additional requirements were imposed for integrated parts that were not securityrelevant.) In order to reduce evaluation work, one might consider two levels to relax this strict requirement: 1. It is sufficient that the integrator gives a statement that ALC has been adhered by the subcontractors. 2. The lowest possible requirement is that the evidence needed for the further evaluation (e.g. the identifiers and the low level design of the integrated parts) has to be present at the integrator s site. However, it should be taken into consideration, that each form of attenuation would influence the competition, since it advantages developers who outsource parts of the production to subcontractors. The ETR-lite issue (see the preceding section) suggests a comparatively marginal weakening (the integrated parts are actually certified, only it is not possible to give the complete ETR to the evaluator of the integrator product), and even that is not generally accepted. So we suggest to continue adhering rigidly to the general validity of the ALC requirements also in the integration situation. 2.2 Production The previous criteria dealt quite extensively with the term development of the TOE, whereas production appeared only marginally. In our understanding develop and derived terms were meant to comprise development and production. The new criteria shall generally keep this practice. Bundesamt für Sicherheit in der Informationstechnik 15

16 New aspects Transition guide for ALC, ACM, ADO and AGD Handling of standards in ALC_TAT (RI #71) Version 2.0, There are some terms in the configuration management requirements ( manufacturing, generation, integration ) specifically related to production. We see it the way that these terms all mean production under a certain aspect. In the new structure, they are all replaced by production, since the particular aspect becomes clear from the context. Thereby we think to enhance comprehensibility of the criteria. This is discussed in more detail in chapter Handling of standards in ALC_TAT (RI #71) ALC_TAT.2 requires the developer to describe the implementation standards to be applied, and the evaluator to confirm that these standards have been applied. However, the component includes no measures of quality or coverage for the implementation standards. This issue is discussed in chapter Refinement of CM access control The present criteria at CAP.3 require the CM system to provide measures such that only authorised changes are made to the configuration items (ACM_CAP.3.10C). It has been annotated that this requirement leaves a wide scope of interpretation and implementation. For instance, user authentication might open access to the complete server, or the other way round only grants access to files that are needed to fulfil a concrete task assigned to a concrete member of the development staff. So minimum preconditions for the granting of access might be required subject to the chosen CAP component, for instance: ACM_CAP.3 Ownership ACM_CAP.4 Ownership and need to change Alternatively this could be managed by security policies defined in the ST. 2.5 Delivery (RI #128, RI #210) The ADO class is dissolved in the new structure. Since the family DEL describes developer procedures, it is located within ALC in the new concept (cf. chapter 13). Indeed, delivery includes also activities to be performed by the user (acceptance of the received TOE on the basis of the identifiers and procedures defined by the developer). These user acceptance procedures were not explicitly articulated in the previous CC version, and are placed within AGD in the new structure. This is presented in more detail in chapter 14. By RI #128, the evaluation methodology shall state explicitly, that the delivery documentation should cover the entire TOE, but may contain different procedures for different parts of the TOE. The indicated change in the guidance text belonging to the first work unit of DEL is adopted in the new structure. From version 2.1 to version 2.2 of the criteria, the scope of ADO_DEL has been broadened beyond integrity to all aspects of security (confidentiality, availability). However (as RI #210 annotates, cf. chapter 20.8), only ADO_DEL.1 actually takes into account all aspects of security, whereas ADO_DEL.2 and ADO_DEL.3 only deal with integrity. Should the higher DEL components 2 and 3 be expanded to confidentiality and availability as well? And should confidentiality be concerned with the act of the delivery and/or with the contents of the delivery? But these security aspects are only to be considered if required by the PP/ST for the actual TOE (whereas integrity is relevant for all kinds of TOEs). Further, the reasonability of the DEL.3 requirement prevention of modification has recently been put into question. To avoid unnecessary regulations in these areas, in the new concept the three DEL components are merged into a single one which requires the developer to take into account all those security aspects required by the PP/ST for the actual TOE, and to commensurate the level of protection with the chosen level of AVA_VLAVAN. 16 Bundesamt für Sicherheit in der Informationstechnik

17 Transition guide for ALC, ACM, ADO and AGD Version 2.0, New aspects Developer IGS 2.6 Developer IGS Whereas IGS mainly deals with user activities, procedures at the development site have also to be taken into account as is pointed out in the CEM. Since developer and user activities belong to different life-cycle phases, they are assigned to different CC families. User IGS procedures, as all user activities, are assembled in families of the AGD class in the new structure (cf. chapter 15). Developer IGS activities are covered by CM capability requirements, cf. the discussion in chapter 16. Bundesamt für Sicherheit in der Informationstechnik 17

18 Discussion on terminology in ACM-ALC-ADO-AGD Transition guide for ALC, ACM, ADO and AGD Overview Version 2.0, Discussion on terminology in ACM-ALC-ADO-AGD 3.1 Overview This chapter discusses definitions for the terms identified as needing a common understanding in CCMB discussions on the ACM, ALC, ADO, AGD classes. These definitions are compiled in a glossary in Part 1 of the new criteria, and are resumed in Part 3 where they are needed. Meanwhile, a general point arises: Many terms and passages of the CC reveal their origin from the software world and are often not suitable when evaluating hardware TOEs or TOEs with hardware components. (For instance: The production phase is dealt with only marginally.) So it would be a useful long-term objective to free the CC from the software specific terms (or to convert these passages into examples) and to find generally applicable formulations. As a first step, some examples relating to hardware TOEs have been introduced into the CEM. On the following page, we present a graphical description of many of the terms used in configuration management and in the product life-cycle with their relations, that is also contained in Part 1 of the new criteria. 18 Bundesamt für Sicherheit in der Informationstechnik

19 Transition guide for ALC, ACM, ADO and AGD Discussion on terminology in ACM-ALC-ADO-AGD Version 2.0, Overview CM System CM Tools CM Output CM Output Doc. CM Plan Product specific CM System Tool-Doc. CM Usage Doc. produce CM System Records produce Config. List cont ains CM items Proc.-Doc. defines CM Procedures Actions manual CM control measures use enforces controls use Developer s Responsibility Development Environment Development Testing Production (e.g. Manufacturing, Integration, Generation, Storage, Labelling) Product Life Cycle Delivery Process Dispatch send Acceptance User s Responsibility Preparation Installation Operational Environment Operation *CM Documentation = CM Usage Doc. + CM Output Doc. Figure 2: Graphical overview of the terminology in CM and in the Product Life Cycle Bundesamt für Sicherheit in der Informationstechnik 19

20 Discussion on terminology in ACM-ALC-ADO-AGD Transition guide for ALC, ACM, ADO and AGD Configuration Management Version 2.0, Configuration Management The following definitions for all CM related terms seem to make most sense (and are compatible to the CC and CEM requirements). These definitions can be found by interpreting a CM system as a specific management system. According to ISO Guide 72 (2001) Guidelines for the justification and development of management system standards the following definition holds: Management system: system to establish policy and objectives and to achieve those objectives. The policy and objectives for a configuration management system are not explicitly stated, but the following is probably consensus: The task of a CM system is to manage certain objects, called configuration items, typically source code files, hardware drawings, documents, hardware parts and so on. The main objective is to manage the configuration items in such a way, that it can be determined, which configuration items belong together in order to contribute to a specific product (e. g. a software built from certain source files or a hardware built from certain parts). One objective (from the security point of view) is to prevent unauthorised modification of configuration items or more generally to prevent unauthorised access. Using these considerations, the following definitions can be given. Note: This interpretation for the CM terms can also be found by replacing the CM with QM in the terms and looking, what the terms would mean in the QM context. CM system is the overall term for the set of all procedures and tools (including their documentation) used by a developer to maintain configurations of his products during their life-cycles. [This fits to the meaning of QM system.] All following objects can be considered to be a part of the system. From this definition, terms like CM procedures are also clear. The CM usage documentation is a part of the CM system, which consists of the documents describing, how the CM system is defined and used (this encloses handbooks, regulations, documentation of tools used for CM, if tools are used, and so on). The CM output are CM related results produced or enforced by the CM system. These CM related results occur as documents (e.g. filled paper forms, CM system records, logging data, hardcopies and electronic output data) as well as actions (e.g. manual measures to fulfil CM instructions). Examples of such CM outputs are configuration lists, CM plans and/or behaviours during the product life-cycle. The CM documentation consists of the CM usage documentation and the CM output documentation. ( Documentation of the CM system is the same as CM documentation.) [ CM documentation corresponds to the meaning of QM documentation.] The CM plan is a part of the CM documentation. It gives the description, how the CM system is used for a specific project or product. [This fits to the meaning of QM plan.] From the point of view of the overall CM system this can be seen as an output document (because it may be produced as part of the application of the CM system). From the point of view of the concrete project it is a usage document because members of the project team use it in order to understand, which steps they have to do during the project. 20 Bundesamt für Sicherheit in der Informationstechnik

21 Transition guide for ALC, ACM, ADO and AGD Version 2.0, Discussion on terminology in ACM-ALC-ADO-AGD Life-cycle For example the CM plan defines the scope of the system for the specific product, because the same system may be used with different scope for different products. A CM item or configuration item is an object managed by the CM system, i.e. which is stored in the CM system directly (e. g. for files) or by reference (e. g. by hardware parts) together with its version. The CM list or configuration list is a CM output document listing all configuration items for a specific product together with the exact version of each CM item relevant for a specific version of the complete product (in the CC context this will be the evaluated version). [Here the comparison to QM systems doesn t work as it does for the other terms, because QM list is not a term used for QM systems with a comparable meaning]. This list allows distinguishing the items belonging to the evaluated version of the product from other versions of these items belonging to other versions of the product. The final CM list is a specific document for a specific version of a specific product. (Of course the list can be an electronic document inside of a CM tool. In that case it can be seen as a specific view into the system or a part of the system rather than an output of the system. However, for the practical use in an evaluation the configuration list will probably be delivered as a part of the evaluation documentation.) Some further terms are clear from this: CM access control is the set of mechanisms and procedures guaranteeing that only authorised access is granted to configuration items. CM system records are those output documents, which are produced during the operation of the CM documenting important activities. (E.g. the list of modifications of a configuration item together with the ID of the person, who made the changes may be a typical part of these data.) CM tools : If a CM system is realised or supported by a tool, this tool will be a CM tool (e. g. the standard UNIX tool CVS or Perforce" as a commercial tool). CM evidence is everything that may be used to establish confidence in the correct operation of the CM system, e.g. CM output, demonstrations provided by the developer, observations, experiments or interviews made by the evaluator during a site visit. 3.3 Life-cycle Life-cycle management can be seen as the highest level of management for a product or system, since quality management, configuration management, project management and so on can all be seen as part of the life-cycle management. However, this depends on the point of view. A quality manager may see QM as the highest level, because all other management activities contribute to quality. As CM systems, also life-cycle management systems can be discussed. Though the CC doesn t require such a system, some of the terms used in the CC can be discussed in this context. The life-cycle of a certain object (e. g. a product or a system) is a sequence of stages of existence of this object in time. Which stages one uses depends on the object, but usual stages for IT products are development, testing, operation and so on Life-cycle model The life-cycle model defines, which stages are used in the management of the life-cycle of a certain object, how the sequence of stages looks like and which high level characteristics the stages have. The definition of the Life-Cycle Model is the Life-Cycle Definition. A measurable life-cycle model (as required in ALC_LCD.32) is a life-cycle model using some quantitative valuation of the managed product (a metric ) in order to measure some quality aspects of the object. Typi- Bundesamt für Sicherheit in der Informationstechnik 21

22 Discussion on terminology in ACM-ALC-ADO-AGD Transition guide for ALC, ACM, ADO and AGD Life-cycle Version 2.0, cal metrics are software complexity metrics. The use of such metrics may add assurance in the overall quality of the development process. More details are given in section 6.3. As indicated in the introduction (1.1), we will try to set up the life-cycle model which is implicitly assumed by the CC. At least four life-cycle phases were clearly distinguishable in the previous criteria that had to be taken into account by the evaluation: 1. Development 2. Delivery 3. IGS (Installation, generation and start-up) 4. Operation (end-usage) Production did not explicitly appear in the previous criteria; development was meant to comprise development and production. In the life-cycle model below, production is displayed as a separate life-cycle phase, but in the new requirements the practice is kept to use development and related terms ( developer, develop ) in the more general sense to comprise development and production. In the requirements of the family ACM_CAP there were used several terms with a meaning similar to production: Manufacturing, generation, integration. These seem to be closely related to each other: ACM_CAP.5.13C: The integration procedures shall describe how the CM system is applied in the TOE manufacturing process. ACM_CAP.5.19C:... the use of the integration procedures ensures that the generation of the TOE is correctly performed.... We see it the way that the aforementioned terms all meant production under a certain aspect. Since the aspect becomes clear from the context, we think to enhance comprehensibility of the criteria by replacing them all with production. In the case of a software-only TOE, the production phase may be trivial; other phases may be trivial too, for instance IGS in the case of a smart card. IGS: The CC does not explicitly define the difference between installation and generation. For instance, it is not really clear if running a setup routine for the TOE has to be regarded as generation or installation. On an abstract level, the ambiguity is even greater. Also, there may be a division of responsibility for the IGS procedures between the user and the developer. In the new structure, a pragmatic approach as follows is taken: The IGS activities at the development site are dealt with in the context of the production, and the IGS activities at the user s site (referred to as installation of the TOE) in the guidance documentation. Preparation comprises user s acceptance and installation procedures of the received TOE. So the new structure orientates itself to a life-cycle model consisting of the following five phases: 1. Development 2. Production 3. Delivery 4. Preparation (acceptance and installation) 5. Operation (end-usage) In the following, we will discuss the boundaries between the subsequent life-cycle phases. 22 Bundesamt für Sicherheit in der Informationstechnik

23 Transition guide for ALC, ACM, ADO and AGD Version 2.0, Discussion on terminology in ACM-ALC-ADO-AGD Life-cycle Development Production: The development phase consists of creating the implementation representation (the least abstract representation) of the TOE. Based on the implementation representation, no further design decisions have to be made to produce the TOE. Production Delivery: The production phase consists of transforming the implementation representation into the implementation of the TOE. The following examples show the type of questions that arise here: Transports of parts of the TOE or the unfinished TOE between different development sites is classified here definitely as production, not as delivery. Storage of the TOE after its completion might be assigned to either phase. (The CEM supports the view to see it as part of the delivery, cf. paragraph 1263.) Production of personalised smart cards, the classification of the developer s personalisation process being the question. Delivery Preparation: The delivery phase consists of the transfer of the finished TOE into the responsibility of the user. This does not necessarily coincide with the arrival of the TOE at the user s location. How should user s acceptance of the delivered TOE be classified? Since this is a user activity, it has to be described in the user guidance anyway. In order to accommodate CC families and life-cycle phases, in the new structure user s acceptance procedures are classified as preparation. Preparation Operation: Preparation comprises all the processes that have to be performed (normally) only once after receipt of the TOE at the user s site to progress the TOE and its environment into the evaluated configuration as described in the ST (this may include such things as booting, initialisation, start-up), whereas operation covers those processes which have to be carried out during the continuous end-usage of the TOE. Hereby all processes at the user s site are covered. Thus an explicit start-up phase is dispensable, its processes might be assigned either to preparation or to operation, as the case may be. The preparation phase ends, when the TOE is in its evaluated configuration Acceptance A specific part of the life-cycle management is the decision, when managed objects move on to the next step of the life-cycle. This is called Acceptance, if it is an explicit decision, which for example depends on a certain quality or maturity of the object. For example the release of an IT product for production or for operation after sufficient testing is a typical acceptance step. Acceptance procedures are the procedures followed in order to make such an acceptance step (e. g. it may be defined, that a project manager documents the acceptance of a newly developed product for production by signing a certain paper form). In the new structure, acceptance procedures during development and production in order to accept a configuration item as part of the TOE are described in the CM plan. Acceptance procedures followed by the recipient of the delivered TOE in order to verify its integrity should be described in the user guidance. Bundesamt für Sicherheit in der Informationstechnik 23

24 ALC_DVS Transition guide for ALC, ACM, ADO and AGD ALC_DVS.1 (Identification of security measures) Version 2.0, ALC_DVS The two components of ALC_DVS and their denotations have been retained, modifications have been performed only within the components. 4.1 ALC_DVS.1 (Identification of security measures) In this component the following redundancy in version 2.3 has been identified: ALC_DVS.1.2C: The development security documentation shall provide evidence that these security measures are followed during the development and maintenance of the TOE. with belonging work unit ALC_DVS.1-3: The evaluator shall check the development security documentation to determine that documentary evidence that would be produced as a result of application of the procedures has been generated. are covered by ALC_DVS.1.2E: The evaluator shall confirm that the security measures are being applied. with belonging work unit ALC_DVS.1-4: The evaluator shall examine the development security documentation and associated evidence to determine that the security measures are being applied. Therefore the element ALC_DVS.1.2C with belonging work unit ALC_DVS.1-3 are deleted in version 3.1. The only effect on numbering regards work unit 1-4, which becomes work unit ALC_DVS.2 (Sufficiency of security measures) First this component contains the same redundancy as ALC_DVS.1 Accordingly the element ALC_DVS.2.2C with belonging work unit ALC_DVS.2-3 are deleted in version 3.1. (To keep the explanations in this section traceable, the numbers of the elements and work units are those from version 2.3; the mapping to the new numbers is given in the following section 4.3.) The title of ALC_DVS.2 is at first glance puzzling since already in ALC_DVS.1 the evaluator is required to determine the sufficiency of the security measures employed, namely by the work unit ALC_DVS.1-2: The evaluator shall examine the development confidentiality and integrity policies in order to determine the sufficiency of the security measures employed. belonging to the element ALC_DVS.1.1C: The development security documentation shall describe all the physical, procedural, personnel, and other security measures that are necessary to protect the confidentiality and integrity of the TOE design and implementation in its development environment. The new feature in ALC_DVS.2 is that now the developer has to justify the sufficiency by the requirement 24 Bundesamt für Sicherheit in der Informationstechnik

25 Transition guide for ALC, ACM, ADO and AGD Version 2.0, ALC_DVS Overview of element and work unit coverage ALC_DVS.2.3C: The evidence development security documentation shall justify that the security measures provide the necessary level of protection to maintain the confidentiality and integrity of the TOE. (In version 3.1, evidence is specified as development security documentation since there is no developer action element for evidence.) A work unit for this element has been taken from the German national interpretation AIS 34, version 1.00, : ALC_DVS.2-4: The evaluator shall examine the development security documentation to determine that an appropriate justification is given why the security measures provide the necessary level of protection to maintain the confidentiality and integrity of the TOE. The evaluator s determination of the sufficiency of the security measures required by work unit ALC_DVS.2-2 (belonging to ALC_DVS.2.1C) is more naturally placed behind all the other work units of ALC_DVS.2, thus in version 3.1 is shifted to the end of ALC_DVS.2 as the second work unit belonging to ALC_DVS.2.3C 4.3 Overview of element and work unit coverage CC/CEM version 2.3 AIS 34 CC/CEM version 3.1 DVS.1 DVS.2 DVS.1 DVS.2 Elem. WU Elem. WU Elem. WU Elem. WU 1C -1 1C -1 1C -1 1C C -4 2C -2 2C -3 2C -3 2E -4 2E -5 2E -3 2E -4 Table 2: Development Security: Correspondence of elements and work units Examples for reading the table: Element DVS.2.3C from CC version 2.3 corresponds to element DVS.2.2C from CC version 3.1. They have no correspondence in DVS.1 in either version. The corresponding work unit DVS.2-4 comes from the German AIS 34 and is adopted in CEM version 3.1 as work unit DVS.2-2. Element DVS.*.2C and work unit DVS.*-3 from version 2.3 have no direct correspondence in version 3.1, but are covered by element DVS.*.2E with corresponding work units DVS.1-3 and DVS.2-4 respectively. In CC version 2.3, work units DVS.1-2 and DVS.2-2 are identical and belong to identical elements DVS.1.1C and DVS.2.1C respectively. These elements and work unit DVS.1-2 are unchanged in version 3.1, but work unit DVS.2-2 becomes work unit DVS.2-3 which belongs to element DVS.2.2C and not to DVS.2.1C in version 3.1. Bundesamt für Sicherheit in der Informationstechnik 25

26 ALC_FLR Transition guide for ALC, ACM, ADO and AGD ALC_FLR.1 (Identification of security measures) Version 2.0, ALC_FLR The three components of ALC_FLR and their denotations have been retained, modifications have been performed only within the components. The elements have been grouped by subject, hence the sequence of some elements and work units has changed. Work units for all ALC_FLR components have basically been taken from CEM version 2.4 of March 2004, and adapted to the performed modifications. 5.1 ALC_FLR.1 (Identification of security measures) The first developer action element is modified as follows: ALC_FLR.1.1D: The developer shall provide document flaw remediation procedures addressed to TOE developers. in order to ensure the existence of the flaw remediation procedures documentation referenced in 1C and 4C. 5.2 ALC_FLR.2 (Flaw reporting procedures) Beyond the change in ALC_FLR.1, there is one further modification: ALC_FLR.2.6C: The procedures for processing reported security flaws shall ensure that any reported flaws are corrected and the corrections remediated, and the remediation procedures issued to TOE users. Fixes cannot be legislated. Some problems may have no solution and can be remedied only by workarounds wherein the user is instructed as to how to avoid executing code containing the problem. The work units 7 and 8 belonging to ALC_FLR.2.6C are modified accordingly. 5.3 ALC_FLR.3 (Systematic flaw remediation) There are no changes in ALC_FLR.3 beyond the changes in ALC_FLR.1 and.2 described in the previous sections. 26 Bundesamt für Sicherheit in der Informationstechnik

27 Transition guide for ALC, ACM, ADO and AGD Version 2.0, ALC_LCD ALC_LCD.1 (Developer defined life-cycle model) 6. ALC_LCD The first and last component of ALC_LCD and their denotations have been retained, the second component dealing with standardised life-cycle models has been deleted from the criteria. For the evaluation of the development environment (to choose the right sites and to ensure that they and also the different life-cycle phases work together correctly), the evaluator has to get an understanding of the lifecycle model used by the developer. Then it is reasonable that the developer provides his life-cycle model to the evaluator. Since evaluation of the development environment starts at EAL 3, the first component of the life-cycle definition family ALC_LCD.1 is shifted from EAL 4 to EAL 3. This is in line with the previous criteria since although no explicit analysis of LCD was required at the "old" EAL3 both the developer and the evaluator must have an understanding of the TOE s life-cycle in order to understand all other ALC requirements. In a regular TOE evaluation both get that understanding at EAL3 implicitly since the entire development environment is subject to analysis. That means LCD.1 for EAL3 provide assurance that the life-cycle phases (e.g. represented by different sites) fit together. 6.1 ALC_LCD.1 (Developer defined life-cycle model) The requirements and work units of this component have been left unchanged. The guidance text to work unit 1 has been structured more clearly and supplemented regarding information about subcontractors. 6.2 ALC_LCD.2 (Standardised life-cycle model) From the commenting phase for CC 3.0 (which ended ), the following comment related to ALC_LCD.2 has been received: Comment on ALC_LCD ALC_LCD.2.1D (p170) Standardized Life-Cycle Model There is nothing in using a standardized model that guarantees good results. Applies to 2.4C as well. Substitute well-defined for standardized. Table 3: Comment on ALC_LCD.2 It is agreed that standardised models do not guarantee good results (particularly since developer defined models may also qualify as standardised). The dim increase in assurance does not justify a separate component. Consequently the component Standardised life-cycle models is deleted in the new criteria; ALC_LCD.3 ( Measurable life-cycle model ) becomes ALC.LCD ALC_LCD.3 (Measurable life-cycle model) Comments on CC 3.0 Revision 2 (July 2005) This section contains the comments related to ALC_LCD.3 from the commenting phase for CC 3.0 (which ended ). Comment 1 on ALC_LCD ALC_LCD.3.1E (p172) Measurements The whole idea of having measurements is good but nowhere do we describe their usefulness. What is lacking is the idea of standards against which the measurements are compared. The success or failure of the comparison then determines what actions the developer is to take. Bundesamt für Sicherheit in der Informationstechnik 27

28 ALC_LCD Transition guide for ALC, ACM, ADO and AGD ALC_LCD.3 (Measurable life-cycle model) Version 2.0, Comment 2 on ALC_LCD.3 Part 3, 17.6, ALC_LCD.3 te Table 4: Comment 1 on ALC_LCD.3 There is no definition of what a measurable life cycle actually is. There is no information about what is supposed to be measured, except for the mention of source code complexity in paragraph 540. Requests for clarification of this requirement in CC v2 were never answered by the NSA. BSI proposed an interpretation based on software development costs (COCO- MO), but could not explain what that had to do with security. Table 5: Comment 2 on ALC_LCD.3 Add some details on what is supposed to be measured and how measuring it would enhance the security of the TOE. If this can t be done, then consider removing the requirement entirely. Note: Source code complexity metrics is a good idea, but the CC needs to say a lot more about them. COCOMO is clearly NOT relevant here. (Not that COCOMO is a bad thing it just isn t relevant to security ) it just isn t relevant to security.) Note: The following was no official comment, but a question by . However, it is also a good example of the comments addressed here and therefore included. Comment 3 on ALC_LCD.3 In looking over the new ALC, I am unable to find a clear difference between LCD.2 and LCD.3. The text in the element changes, but there is no explanation of what those changes mean, nor is there any change in the methodology. The biggest question that needs to be answered is: what is a *measurable* standardised development model? [CC v2 para 398 says A measurable lifecycle model is a model with arithmetic parameters and/or metrics that measure TOE development properties (e.g. source code complexity metrics) but this isn t helpful: source code complexity is measured with tools, which makes such things more appropriate for TAT, not LCD.]1 Do any of the popular development models (rapid-prototyping, spiral, waterfall -- none of which is given as examples for LCD.2, which also needs to be corrected) qualify as "measurable"? If so, which ones? If not, why not? Discussion Table 6: Comment 3 on ALC_LCD.3 As a preparation for a disposition of the comments and suggested changes to the CC, we first discuss the nature of the problem and possible approaches to the solution Nature of the problem The component ALC_LCD.3 requires the use of measurable life cycle models. As example source code complexity metrics are mentioned. According to the comments this information is not sufficient to tell developers and evaluators, what to do Discussion of the goals First observation The title measurable Life Cycle model used in LCD.3 is a little bit misleading, because one might think of a measure for life cycle models. Of course, what is meant is a Life Cycle model, which includes the use of metrics for properties of the product or of the development processes. So a more correct term would be 1 We do not think, that this side remark on ALC_TAT really is an argument against tool-based measurement in the context of ALC_LCD.3. The following parallel situation shows this: A configuration management system can also be tool based, which doesn t have the effect that the work from ALC_CMC or ALC_CMS shifts to ALC_TAT. 28 Bundesamt für Sicherheit in der Informationstechnik