Common Criteria V3.1. Evaluation of IT products and IT systems

Transcription

1 Common Criteria V3.1 Evaluation of IT products and IT systems

2 Contents 1 Background Benefits of Evaluations Levels of Assurance EAL1 - Functionally Tested EAL2 - Structurally Tested EAL3 - Methodically Tested and Checked EAL4 - Methodically Designed, Tested and Reviewed EAL5 - Semi formally Designed and Tested EAL6 Semi formally Verified Design and Tested EAL7 - Formally Verified Design and Tested Protection Profiles and Security Targets Protection Profile (PP) Security Target (ST) Classes of Assurance Development (ADV) Guidance Documents (AGD) Life Cycle Support (ALC) Tests (ATE) Vulnerability Assessment (AVA) Composition A quick Reference Evaluation Assurance Levels Composition Evaluation and Certification Time Schedules of Evaluations... 15

3 10 Services offered by TÜViT About TÜViT Links to the Glossary Annex: Selected References Contact Common Criteria V3.1 Page 2 25

4 1 Background There is no dispute that in today s world of information technology a high degree of security in terms of confidentiality, integrity and availability of IT products, systems and procedures is a must. Since this field involves sensitive information which is collated, processed and transmitted in electronic form and viewed as obliged, simple trust in the existing characteristics of products and systems is not enough; instead, security can only be achieved and certified by means of a validated evaluation process performed according to appropriate and recognized criteria by an impartial body (like e.g. TÜViT) with experience in this complex field. The Common Criteria [] are an appropriate instrument to review and assess the information security of IT products and systems by a combination of evaluating the related product and system documentation as well as performing practical testing. The Common Criteria represent the outcome of efforts to develop criteria for evaluation of IT security that are widely useful within the international community. They are an alignment and development of a number of source criteria: the existing European, US and Canadian criteria (ITSEC, TCSEC and CTCPEC respectively). The structure provides great flexibility in the specification of secure products. Consumers and other parties can specify the security functionality of a product in terms of standard protection profiles, and independently select the evaluation assurance level from a defined set of seven increasing Evaluation Assurance Levels, from EAL1 up to EAL7. Version 1.0 of the was published for comment in January Version 2.0 took account of extensive review and trials during the following two years and was published in May Version 2.3, dated August 2005, has been published as the International Standard ISO/IEC 15408:2005. Version 3.1 is the recent version of the Common Criteria and has become official September 2006 in revision 1. Parts 2 and 3 have been upgraded to revision 2 in September Common Criteria V3.1 Page 1 25

5 Figure 1: Developmental history of version 3.1 consists of the following parts: Part 1: Introduction and general model Part 2: Security functional components Part 3: Security assurance components The is complemented by the Common Evaluation Methodology [CEM] manual, which describes the principles and model of the methodology needed to apply the Common Criteria. Common Criteria V3.1 Page 2 25

6 2 Benefits of Evaluations The main objective of an evaluation is to collect appropriate and reliable evidence to achieve confidence in the IT security measures implemented in a product or system (also called Target of Evaluation, TOE) on the developer s as well as on the user s side. Hence an evaluation is a quality enforcing process, which increases the security level of a product or system and additionally leads to a correct and complete documentation. Since evaluation results based on Common Criteria are recognized nearly worldwide, an evaluated and certified product or system has an outstanding position in the market. 3 Levels of Assurance The contains a set of defined assurance levels constructed using components from the assurance families. These levels are intended to provide internally consistent general purpose assurance packages. Other groupings of components are not excluded. To meet specific objectives, an assurance level can be augmented by one or more additional components (from assurance families not already included in the EAL) or by the substitution of assurance components (with another hierarchically higher assurance component in the same assurance family) to an EAL. Assurance levels are defined in the for the rating of a TOE's assurance. Every assurance component contributes to the assurance that a TOE meets its security claims from the PP and ST. EALs provide a uniformly increasing scale which balances the level of assurance obtained with the cost and feasibility of acquiring this degree of assurance. There are seven hierarchically ordered EALs. The increase in assurance across the levels is accomplished by substituting hierarchically higher assurance components from the same assurance family, and by the addition of assurance components from other assurance families. Common Criteria V3.1 Page 3 25

7 The seven EALs are as follows: EAL1 - functionally tested EAL2 - structurally tested EAL3 - methodically tested and checked EAL4 - methodically designed, tested and reviewed EAL5 - semi formally designed and tested EAL6 - semi formally verified design and tested EAL7 - formally verified design and tested EAL1 is the entry level. Up to EAL4 increasing rigour and detail are introduced, but without introducing significantly specialised security engineering techniques. EAL1-4 can generally be retrofitted to preexisting products and systems. Above EAL4 increasing application of specialised security engineering techniques is required. TOEs meeting the requirements of these levels of assurance will have to be designed and developed with the intent of meeting those requirements. At the top level (EAL7) there are significant limitations on the practicability of meeting the requirements, partly due to substantial cost impact on the developer and evaluator activities, and also because anything other than the simplest of products is likely to be too complex to submit to current state-of-the-art techniques for formal analysis. 3.1 EAL1 - Functionally Tested EAL1 is applicable where some confidence in correct operation is required, but the threats to security are not viewed as serious. It will be of value where independent assurance is required to support the contention that due care has been exercised with respect to the protection of personal or similar information. This level provides an evaluation of the TOE as made available to the customer, including independent testing against a specification and an examination of the guidance documentation provided. It is intended that an EAL1 evaluation could be successfully conducted without assistance from the developer of the TOE, and for minimal outlay. An evaluation at this level should provide evidence that the Common Criteria V3.1 Page 4 25

8 TOE functions in a manner consistent with its documentation, and that it provides useful protection against identified threats. Additionally, the evaluation will confirm TOE resistance against attacks with basic attack potential, based on an evaluator s search of public domain information and following penetration tests. 3.2 EAL2 - Structurally Tested EAL2 requires the co-operation of the developer in terms of the delivery of design information and test results, but should not demand more effort on the part of the developer than is consistent with good commercial practise. As such it should not require a substantially increased investment of cost or time. EAL2 is applicable in those circumstances where developers or users require a low to moderate level of independently assured security in the absence of ready availability of the complete development record. Such a situation may arise when securing legacy systems, or where access to the developer may be limited. In addition to EAL1, the TOE resistance against attacks with basic attack potential is supported by an independent vulnerability analysis of the evaluator, using guidance documents, TOE design and architecture information. 3.3 EAL3 - Methodically Tested and Checked EAL3 permits a conscientious developer to gain maximum assurance from positive security engineering at the design stage, without substantial alteration of existing sound development practices. It is applicable where the requirement is for a moderate level of independently assured security, with a thorough investigation of the TOE and its development without incurring substantial re-engineering costs. In addition to EAL2, an EAL3 evaluation provides an analysis supported by grey box testing and selective independent confirmation of the developer test results. Development environment controls, TOE configuration management, and evidence of secure delivery procedures are also required. Common Criteria V3.1 Page 5 25

9 3.4 EAL4 - Methodically Designed, Tested and Reviewed EAL4 permits a developer to maximise assurance gained from positive security engineering based on good commercial development practices. Although rigorous, these practices do not require substantial specialist knowledge, skills and other resources. EAL4 is the highest level at which it is likely to be economically feasible to retrofit to an existing product line. It is applicable in those circumstances where developers or users require a moderate to high level of independently assured security in conventional commodity TOEs, and there is willingness to incur some additional security-specific engineering costs. An EAL4 evaluation provides, in addition to EAL3, an analysis supported by a complete interface specification, a description of the basic modular design of the TOE, and a subset of the implementation. Testing is supported by a vulnerability analysis (also using the implementation representation), demonstrating resistance to penetration attackers with an Enhanced-Basic attack potential. Assurance is also provided through additional automated configuration management. 3.5 EAL5 - Semi formally Designed and Tested EAL5 permits a developer to gain maximum assurance from security engineering based on rigorous commercial development practices, supported by moderate application of specialised security engineering techniques. Such a TOE will probably be designed and developed with the intent of achieving EAL5 assurance. It is likely that the additional costs attributable to EAL5 requirements, relative to rigorous development without application of specialist techniques, will not be large. EAL5 is applicable where the requirement is for a high level of independently assured security in a planned development, with a rigorous development approach, but without incurring unreasonable costs for specialised security engineering techniques. Common Criteria V3.1 Page 6 25

10 An EAL5 evaluation provides, in addition to EAL4, an analysis supported by a modular design of the TOE Security Functionality with limited complexity. Assurance is supplemented by a semiformal presentation of the design, a structured architecture, comprehensive TOE configuration management, and an independent, methodical vulnerability analysis demonstrating resistance to penetration attackers with a moderate attack potential. 3.6 EAL6 Semi formally Verified Design and Tested EAL6 permits a developer to gain high assurance from application of specialised security engineering techniques in a rigorous development environment, and to produce a premium TOE for protecting high value assets against significant risks. EAL6 is applicable to the development of specialised security TOEs, for application in high risk situations where the value of the protected assets justifies the additional costs. An EAL6 evaluation, in addition to EAL5, provides an analysis which is supported by a modular and layered approach to design with minimised complexity. Assurance is additionally gained through a formal model of selected TOE security policies and a semiformal presentation of the functional specification and TOE design. The independent, methodical vulnerability analysis demonstrates resistance to penetration attackers with a high attack potential. The search for covert channels must be systematic. Configuration management controls are further strengthened by a complete automation of configuration management. Common Criteria V3.1 Page 7 25

11 3.7 EAL7 - Formally Verified Design and Tested EAL7 is applicable to the development of security TOEs for application in extremely high risk situations, and/or where the high value of the assets justifies the higher costs. Practical application of EAL7 is currently limited to TOEs with tightly focused security functionality that is amenable to extensive formal analysis. For an EAL7 evaluation, additional to EAL6, the formal model is supplemented by a formal presentation of the functional specification and high level design, showing correspondence. Evidence of developer white box testing and complete independent confirmation of developer test results are required. Complexity of the modular design must be minimised. Development environment controls are further strengthened by application of a measurable life-cycle model. 4 Protection Profiles and Security Targets In defining the security requirements for a trusted product or system the user/developer needs to consider the threats to the IT environment. The contains a catalogue of components that the developers of PP and ST can collate to form the security requirements definition. The organization of these components into a hierarchy helps the user to locate the right components to counter threats. The user then presents the security requirements in the PP and the ST of the TOE. 4.1 Protection Profile (PP) A protection profile defines an implementation-independent set of security requirements and objectives for a certain type of IT products or systems which meet similar consumer needs for IT security. A PP is intended to be reusable and to define requirements which are known to be useful and effective in meeting the identified objectives. To earn higher flexibility, the PP may request demonstrable conformance from TOEs or requests strict conformance. Common Criteria V3.1 Page 8 25

12 The PP concept has been developed to support the definition of functional standards, and as an aid to formulating procurement specifications. For preceding versions of the PPs have been developed for firewalls, relational databases, smart cards etc, and to enable backwards compatibility with TCSEC B1 and C2 ratings. 4.2 Security Target (ST) A security target contains the IT security objectives and requirements of a specific identified TOE and defines the functional and assurance measures offered by that TOE to meet stated requirements. The ST may claim strict or demonstrable conformance to one or more PPs, and forms the basis for an evaluation. 5 Classes of Assurance To demonstrate the security of a TOE during development and operation the require information structured according to the following classes. Basically each class implies one or more deliverable to be provided by the sponsor to the evaluators. 5.1 Development (ADV) The development class encompasses requirements for structuring and representing the TSF at various levels and varying forms of abstraction. These requirements are concerned with the refinement of the TSF from the specification defined in the ST to the implementation. Additionally, a survey of TOE self-protection, called architecture, is included for EAL2 and higher. The knowledge obtained by this information is used as the basis for conducting vulnerability analysis and testing upon the TOE, as described in the AVA and ATE classes. Common Criteria V3.1 Page 9 25

13 5.2 Guidance Documents (AGD) Guidance documents are concerned with the secure preparation and operational use of the TOE, by the users and administrators. 5.3 Life Cycle Support (ALC) Life-cycle support is an aspect of establishing discipline and control in the processes of refinement of the TOE during its development and maintenance. The requirements of the families include lifecycle definition, CM capabilities and scope, tools and techniques, security of the development environment as well as delivery of the TOE, and the remediation of flaws found by TOE consumers. 5.4 Tests (ATE) The class Tests provides assurance that the TSF behaves as described (in the functional specification, TOE design, and implementation representation). It addresses coverage and depth of developer testing, and requirements for independent testing. 5.5 Vulnerability Assessment (AVA) This class defines requirements directed at the identification of vulnerabilities which could be introduced in the development or occur during operation of the TOE. Development vulnerabilities are based on tampering, bypassing, monitoring or direct attack of the TOE security functions. Operational vulnerabilities take advantage of weaknesses in non-technical countermeasures to violate the TOE Security Functional Requirements (SFRs), e.g. misuse or incorrect configuration. Common Criteria V3.1 Page 10 25

14 6 Composition The levels of assurance EAL1-EAL7 are particularly suitable to evaluate products made by a single vendor. However, if assurance is required on a product which consists of components made by different vendors, it may be impossible to obtain the information necessary to perform an evaluation at EAL2 or above. This is due to the fact that cooperation agreements usually do not stretch to the extent of providing internal design documents and development process evidence. In this situation, an evaluation of the composite product may be performed according to the Composition class of the Common Criteria. Thus, assurance on the interactions between components can be achieved, if the following prerequisites are met: 1 The composite product consists of a base and a dependent component, which are both certified or at least in the process of evaluation. The EAL of the dependent component is smaller than or equal to the EAL of the base component. All evaluation evidence of the dependent component is (or will be) available. The Security Target of the base component Figure 2: Composition structure Figure 2 illustrates the structure of the composite product. The evaluation is also possible if the composite product consists of multiple components, or if a classification into base and dependent 1 For Smart Cards and similar devices other rules apply, because usually an EAL certification is required. Common Criteria V3.1 Page 11 25

15 component is not feasible. However, in this case the process will be more complex, because the available structure needs to be mapped to the structure in figure 6 for each of the interfaces. In order to measure the level of assurance obtained by a composition evaluation, the defines Composed Assurance Packages CAP-A, CAP-B and CAP-C, similar to EAL2, EAL3 and EAL4. CAPs comparable to EAL5 and above are not available. The main advantage of CAP over EAL is that only little information is needed from the developer of the base component. Specifically, no design document or source code of the base component is required. Therefore, the composition evaluation is very costefficient. There are some drawbacks, however. Descriptions of the base component interfaces which are used by the developer of the dependent component have to be provided, and this might not be possible due to a non-disclosure agreement. Furthermore, if the dependent component implements its security functions by using interfaces which were not part of the base component s evaluation, additional information from the vendor of the base component might be required. Last but not least, the maximum assurance level CAP-C may not be sufficient for products with high assurance requirements, especially with regard to vulnerability assessment. Common Criteria V3.1 Page 12 25

16 7 A quick Reference 7.1 Evaluation Assurance Levels The following table provides a quick reference of the minimum information which is mandatory and has to be delivered by the sponsor of an evaluation and reviewed by the evaluation body according to the respective evaluation assurance level. The notation is as follows. N not required for this level mandatory for this level where N = {1; ; 6} is an indicator for the detail of the required information. Assurance Class Development Guidance Documents Life-Cycle Support Security Target Deliverable EAL Security Architecture Functional Specification Implementation (Source Code) TSF Internals Security Policy Modeling 1 1 TOE Design Operational User Guidance Preparative Procedures CM Capabilities CM Scope Delivery Development Security Flaw Remediation Life-Cycle Defintion Tools and Techniques Conformance Claims ST Extended Components Definition Introduction Security Objectives Security Requirements Security Problem Definition TOE Summary Specification Common Criteria V3.1 Page 13 25

17 Assurance Class Tests Vulnerability Assessment Deliverable EAL Coverage of Testing Depth of Testing Functional Tests Independent Testing Vulnerability Analysis Table 1: EAL summary Note: The table above defines the minimum information which is required to achieve a certain evaluation assurance level. Beyond that it is possible to fulfil requirements taken from a higher assurance level. This procedure is called augmentation and a + sign is added to the evaluation assurance level to indicate this (e.g. EAL4+). 7.2 Composition The following table shows a quick reference of the information and level of detail required for the corresponding CAP level. The notation is similar to Table 1: EAL summary. Assurance Class Composition Guidance Documents Life-Cycle Support Security Target Deliverable CAP A B C Composition Rationale Interface Testing Functional Description Basic Reliance Information Composition Vulnerability Review Operational User Guidance Preparative Procedures CM Capabilities CM Scope Conformance Claims ST Extended Components Definition Introduction Security Objectives Security Requirements Security Problem Definition 1 1 TOE Summary Specification Table 2: CAP summary Common Criteria V3.1 Page 14 25

18 8 Evaluation and Certification A security evaluation based on the comprises on the whole the review of the required documentation and the independent testing of the TOE by an accredited evaluation body. The result is a final evaluation technical report (ETR) compiling all single findings of the evaluation and the concluding verdict passed or not passed. A certification is the review whether the evaluation process was performed successfully and in accordance to the by an accredited certification body. The result is an IT security certificate stating the achieved evaluation assurance level and the related certification report summarizing the certification. An IT security certificate - issued by a (national) certification body who is a member of the international Common Criteria Recognition Arrangement (RA) - is internationally recognized and valid in all participating countries of the RA. In Germany the Federal Office for Information Security (FOIS/) acts as the national certification body. 9 Time Schedules of Evaluations The following figure shows a typical time schedule of an EAL4 evaluation process. Figure 3: Typical evaluation schedule Common Criteria V3.1 Page 15 25

19 The actual time schedule strongly depends on the evaluation assurance level and the complexity of the TOE (e.g. the implemented security functionality, lines of code). Additionally the resources available on the sponsor s side to prepare the deliverables required by the are a limiting figure. Typical durations of an evaluation are as follows: EAL Duration 1 2 months 2 3 to 4 months 3 4 to 6 months 4 5 to 9 months 5 6 to 10 months 6/7 more than 9 months 10 Services offered by TÜViT The Evaluation Body for IT Security of TÜViT is accredited according to the international laboratory standard ISO and fully licensed (EAL1 to EAL7) by the German Federal Office for Information Security (FOIS/) to perform security evaluations of any IT product or system. Since FOIS/ is a member of the international Recognition Arrangement (RA), certificates based on the evaluation results of TÜViT will be accepted and recognized all over the world. Annex 1 provides a list of selected security evaluation performed by TÜViT. With an experience of about eighteen years in the area of security evaluations TÜViT can offer the following services related to the. evaluations of IT products and systems trainings of developers trainings of evaluators Support during set-up of evaluation bodies and security laboratories Common Criteria V3.1 Page 16 25

20 11 About TÜViT TÜV Informationstechnik GmbH TÜViT in short is a member of the TÜV NORD Group, based in Hannover, Germany. TÜV NORD has a workforce of more than staff worldwide and is active in 70 countries in Europe, Asia and America besides Germany. Over a TÜV tradition reaching back 140 years, TÜV NORD has performed and developed technical tests and inspections in very many different areas. The principles upon which the company operates stipulate that the TÜV NORD Group must offer and implement its services independently and on a neutral and impartial basis. As an intermediary with the role of creating trust in IT security and IT quality, TÜViT has specialised in the inspection, evaluation and certification of IT products, IT systems and IT processes of all kinds, and also on assessment in relation to special requirements, laws, guidelines and directives (ecompliance). TÜVIT develops evaluations and assessments for manufacturers, operators and users based on general requirements and national/international standards. In this process, TÜViT makes use of recognised processes and also offers advice and professional services in the area of information technology. TÜViT is accredited by national and international organisations, and official authorities and bodies, for the scope of IT security and IT quality. Accreditations are the official recognition by a higherlevel organisation of the expert competency of an inspection body. The accreditations are confirmed by means of regular audits and therefore demonstrate the expert competency of TÜViT in these areas. Common Criteria V3.1 Page 17 25

21 Federal Office for Information Security Accreditation according to DIN EN ISO/IEC 17025:2005 for evaluations according to ITSEC/ITSEM//CEM as well as -TR 03104, -TR Part 3 and Part 5, -TR , -TR , -TR and -TR Licensed auditors for IT-Grundschutz, ISO/IEC on the basis of IT-Grundschutz and for D IT-Security Service Provider in the field of IS-Revision and IS-Consulting German Accreditation Body Testing Laboratory for IT Quality: Competence for evaluations in the field of IT Ergonomics and IT Security, accredited according to DIN EN ISO/IEC Evaluation Body for IT Security: Accreditation for evaluations according to /CEM/ITSEC/ITSEM Evaluation Body for IT Usability: Accreditation for evaluations according to DIN EN ISO , DIN EN ISO , DIN ISO/IEC 25051, DIN EN ISO and ISO Certification Body: Competence for certifications of products in the field of IT Security, accredited according to DIN EN Federal Network Agency Confirmation Body according to Signatures Act/Signatures Ordinance for the confirmation of products for qualified electronic signatures Confirmation Body according to Signatures Act/Signatures Ordinance for the confirmation of the implementation of security concepts for certification service providers German Banking Industry Committee Listed Testing Body for Electronic Payment Transactions Common Criteria V3.1 Page 18 25

22 Independent Centre for Privacy Protection Schleswig-Holstein Test Centre for Privacy (legal/technical) EuroPriSe Experts (legal/technical) Information-technology Promotion Agency, Japan IT Security Evaluation Facility: Competence for evaluations according to /CEM National Institute of Technology and Evaluation, Japan Evaluation Body for IT Security: Accreditation according to DIN EN ISO/IEC in the field of IT / Common Criteria evaluations (Lab Code: ASNITE0019T) National Institute of Standards and Technology, USA National Voluntary Laboratory Accreditation Program, USA Evaluation Body for IT Security (NVLAP Lab Code: ) for Cryptographic Module Testing (scopes 17BCS, 17CAV/01, 17CMH1/01, 17CMH1/02, 17CMH2/01, 17CMH2/02, 17CMS1/01, 17CMS1/02, 17CMS2/01, 17CMS2/02) and Biometrics Testing Europay, MasterCard and Visa, USA/United Kingdom/Japan Full Service Laboratory for evaluations of ICs and IC cards according to EMVCo Security Guidelines Visa, USA Test House for performing Visa Chip Product security evaluations MasterCard, United Kingdom Accredited to perform CAST (Compliance Assessment and Security Testing) evaluations Betaalvereniging Nederland, The Netherlands Evaluation Laboratory Common Criteria V3.1 Page 19 25

23 In the field of testing/evaluation services, TÜViT, as an independent authority, strengthens the adequate trust in quality, security and efficiency. Thus, TÜViT enhances the acceptance of products and systems as well as their operation in the financial sector, industry and public administration. In national and international research projects and bodies, TÜViT participates actively in developing the state of the technology. Related to this is, for instance, TÜViT is involved in the shaping of auditing and certification practices according to IT-Grundschutz method of the Federal Office for Information Security and ISO/IEC TÜViT deploys auditors for IT-Grundschutz and ISO/IEC TÜViT meets its customers high expectations with an active and responsive quality management system certified according to ISO 9001:2008. Furthermore, TÜViT performs comprehensive training courses and consultancy for all ecompliance topics. Common Criteria V3.1 Page 20 25