Ariffuddin_aizuddin_gsec.pdf

THE COMMON CRITERIA ISO/IEC 15408– THE INSIGHT, SOME THOUGHTS,
QUESTIONS AND ISSUES
By Ariffuddin Aizuddin
With the rise of security breaches and the running of technology at its highest gear on theinformation superhighway, protection of confidential and vital information never has beenmore crucial. The needs to have some kind of assurance that the products and the systemsused, that provide an adequate security to the security objective started since the “OrangeBook”- TCSEC (1985), in the US. Various countries then began their initiatives to developevaluation criteria that builds upon the concepts of TCSEC; in Europe – ITSEC (1991),Canada – CTCPEC (1993), US - Federal Criteria (Draft 1993). The Common Criteria –ISO/IEC 15408 – Evaluation Criteria for Information Technology Security represents theoutcome of series of efforts to develop criteria for evaluation of IT Security that are broadlyuseful within the international community.
The security assurance that user required can come from various method; rely upon the wordof manufacturer/service provider, test the system themselves, or rely on an impartialassessment by an independent body (evaluation). Therefore, the evaluation criteria can be ayardstick for users to assess systems or products, a guarantee for manufacturers of securesystems or products and a basis for specifying security requirements.
The Common Criteria (CC) was developed to facilitate consistent evaluations of securityproducts and systems. It is an international effort to define an IT Security evaluationmethodology, which would receive mutual recognition between customers and vendorsthroughout the global economy. The theory behind CC, is that CC will advance the state ofsecurity by encouraging various parties to write Protection Profiles outlining their needs anddesires, in return it will push vendors to meet the resulting Protection Profiles. The theoryproposes that, as users profile desired capabilities that are not currently available, the vendorswill attempt to gain market share by taking up the challenge.
In brief, the CC is a useful guide for the development of products and systems with ITsecurity functions and a guide for procurement of commercial products and systems withsecurity functions. CC philosophy will provide assurance based upon an evaluation (activeinvestigation) of the IT product or system that is to be trusted. The validity of documentation,and resulting IT product or system, is measured by Expert Evaluators with increasingemphasis on scope, depth, and severity.
CC – The Introduction
The acceptance by ISO will ensure that CC rapidly becomes the world standard for securityspecifications and evaluations. The adoption as a world standard and wide recognition ofevaluation results will provide benefits to all parties. A Wider choices of evaluated productsfor consumers, greater understanding of consumer requirements, and a greater access tomarkets for developers.
The information can be found in evaluation schemes publications or on scheme web sites.
Care should be exercise when selecting products from the lists, to ensure that the sameversion of products are being used, and that the intended environment is consistent with thatevaluated.
The certification/validation of evaluation results can provide a sound basis for confidencesthat security measure are appropriate to meet a given threat, and they are correctlyimplemented. However, it is not an absolute guarantee of security. As IT Security propose,the term security should always be viewed in relation to particular set of threats andassumptions about the environment. Nevertheless, CC includes an assurance scale(Evaluation Assurance Levels) that can be applied to help generate different levels ofconfidence in the security products.
Consumers – The CC evaluations satisfy the needs of consumers, as this is the fundamentalpurpose and justification for evaluation process. The results will help them to decide anevaluated product or system to suit their security needs. CC gives implementationindependent structure, the Protection Profile (PP) in which to express their specialrequirements for IT security measures.
Developers and Products Vendors – The developers need to understand how PPs work, sincematching a PP is one of the best ways to ensure that a product provides the user requirements.
Those that seek CC certification/validation need to understand CC approach, and what anevaluation facility that is require from them.
Evaluators and Certifiers/Validators/Overseers – CC model provides the separation roles ofevaluator and certifier/validators. Certificates are awarded by national scheme based onevaluation carried out by independent evaluation facilities (testing laboratories).
Accreditors and approvers – They are the authorities that has the mandate to ascertain thesecurity standard to be achieved using the CC. Acceditors need to understand how theEvaluation Assurance Levels (EAL) can be used as objective measures of risk reduction,when applied to critical security functions in IT system.
What is the CC?
The CC document consists of: Part 1 - Introduction and General Model Part 1 defines general concepts and principles of IT security evaluation and presents a generalmodel of evaluation. This part also presents the constructs for expressing IT securityobjectives, for selecting and defining IT security requirements, and for writing high-level specifications for products and systems. In addition, it provides the usefulness of each part ofthe CC in terms of each of the target audiences.
Part 2 - Security Functional Requirements This part establishes a set of security functional components as a standard way of expressingthe security requirements for IT products and systems. The catalog is organized into classes,families, and components.
Part 3 - Security Assurance Requirements This part produces a catalog of establishes set of assurance components that can be used as astandard way of expressing the assurance requirements for IT products and systems. The Part3 catalog is organized into the same class - family - component structure. Part 3 also definesevaluation criteria for PPs and STs. Part 3 presents the seven Evaluation Assurance Levels(EALs), which are predefined packages of assurance components that make up the CC scalefor rating confidence in the security of IT products and systems.
Consumer use of CC relates to the specification of functional and assurance requirements ofproducts and systems under procurements. Part 2 of the CC is used when specifying thesecurity functional requirements, and Part 3 is used when specifying the assurancerequirements. Consumer can then use this statement of requirements as a specification tovendors of products or system integrators.
The CC should be used to produce deliverables to meet the (CC) requirements. They mayspecify the functional and assurance requirements in a Security Target, or may have themspecified by the consumer in the form of a Protection Profile. The functional requirements,specified using Part 2 of CC, are those with which the products are required to conform. Part3 of the CC contains developer actions that are to be followed when formulating deliverablesfor evaluations to a particular set of assurance requirements.
CC contains mandatory statements of evaluation criteria that used when determining whethera Target of Evaluation (TOE) meets its claimed security functionality and assurancerequirements. Guidance on the application of the CC is given in the Common EvaluationMethodology (CEM).
Key Terminology & Concepts.
Definition: Implementation independent statement of security requirements for a category ofTOEs (target of evaluation) that meet specific customer needs to address a specified securityenvironment.
A Protection Profile describes a set of requirements that are specified with the aim ofcountering specified threats in a specified environment. The Protection Profile may notdescribe the optimal solution, but it is anticipated that it will be consistent, correct, andcomplete. In other words, it will not be self-contradicting. It will contain all the pertinentinformation to adequately talk about the problem space it seeks to address. It is anticipatedthat a Protection Profile may be written by any of several parties. A Protection Profile may bewritten by a user community as a means of stating a need that is not adequately met by thecurrent offerings on the market. An accrediting body such as a government, industry group,or insurance firm might also author a Protection Profile. This might be done as a means ofstandardizing for interoperability. It also can be done to set a minimum standard forprotection. Protection Profiles - (what the customer wants) - is designed to answers thequestion: “What do I need in a security solution?” Definition: Are a basis against which an evaluation is performed. It’s contains the TOEsecurity threat, objectives, requirements, and summary specification of security functions andassurance measures.
An ST is a statement of security claims for a particular IT security product or system. The STparallels the structure of the PP, though it has additional elements that include product-specific detailed information. The ST contains a set of security requirements for the productor system, which may be made by reference to a PP, directly by reference to CC functional orassurance components, or stated explicitly. An ST is the basis for agreement among allparties as to what security the product or system offers, and therefore the basis for its securityevaluation. The ST contains a summary specification, which defines the specific measurestaken in the product or system to meet the security requirements. Security Targets is actuallydesigned to answers the question: “What do you provide in a security solution?” The SecurityTarget - (what the developer claims) - authors are product vendors, developers andintegrators.
An intermediate combination of security requirement components is termed a package. Thepackage permits the expression of a set of either functional or assurance requirements thatmeet some particular need, expressed as a set of security objectives. A package is intended tobe reusable and to define requirements that are known to be useful and effective in meetingthe identified objectives. A package may be used in the construction of more complexpackages or PPs and STs. The seven evaluation assurance levels (EALs) contained in Part 3are predefined assurance packages.
The TOE is an IT product or system to be evaluated, the security characteristics of which aredescribed in specific terms by a corresponding ST, or in more general terms by a PP. In CCphilosophy, it is important that a product or system be evaluated against the specific set ofcriteria expressed in the ST. This evaluation consists of rigorous analysis and testingperformed by an accredited, independent laboratory. The scope of a TOE evaluation is set bythe EAL and other requirements specified in the ST. Part of this process is an evaluation ofthe ST itself, to ensure that it is correct, complete, and internally consistent and can be used as the baseline for the TOE evaluation. In short, TOE - (the product) - is an IT product orsystem and its associated administrator and user guidance documentation that is the subject ofan evaluation.
CC Building Blocks.
Security functional requirement are grouped into classes. Classes are the most generalgrouping of security requirements, and all members of a class share a common focus. Thereare 11 functionality classes within Part2 of the CC. These are as follows:Audit, Identification and Authentication, Resource Utilizations, Cryptographic support,Security management, TOE Access, Communications, Privacy, Trusted Path/Channels, UserData Protection, Protection of the TOE Security Functions.
Each of these classes contains a number of families. The requirements within each familyshare security objectives, but differ in emphasis or rigor.
Security assurance requirement are grouped into classes. Classes are the most generalgrouping of security requirements, and all members of a class share a common focus. Thereare 8 assurance classes within Part3 of the CC.
Configuration management, Guidance documents, Vulnerability assessment, Delivery andoperation, Life cycle support, Assurance maintenance, Development, and Test.
Two additional classes contain the assurance requirements for PPs and STs.
The CC has provided 7 predefined assurance packages known as Evaluation AssuranceLevels (EALs).
This where the applicable where threat to security is not serious, however some confidence incurrent operation is required. In the evaluation, there is no assistance from TOE developer.
The requirements are: Configuration Management, Delivery and Operation, Development,Guidance documents and Tests.
This assurance level is applicable where low to moderate level of independently assuredsecurity is required. Here, it requires some cooperation from the developer. It will definitelyrequire no more than good vendor commercial practices. To add to the previous requirementsare developer testing, vulnerability analysis, and more extensive independent testing.
It is applicable where moderate level of independently assured security is required. Thecooperation from the developer is requires. It places additional requirements on testing,development environment controls and configuration management. The additionalrequirement is the Life Cycle support.
EAL4: Methodically Designed, Tested, and Reviewed This is applicable where moderate to high level of independently assured security is required.
It is to ensure that there is some security engineering added to commercial developmentpractices. This currently the highest level likely for retrofit of an existing product. There areadditional requirements on design, implementation, vulnerability analysis, development andconfiguration management.
It is applicable where high level of independently assured security is required. It requiresrigorous commercial development practices and moderate use of specialist engineeringtechniques with additional requirements on specification, design, and their correspondence.
EAL6: Semiformally Verified Design and Tested This evaluation level is applicable where assets are valuable and risks are high and dorequires a rigorous development environment. The additional requirements are on analysis,design, development, configuration management, and vulnerability/covert channel analysis.
EAL7: Formally Verified Design and Tested This is applicable where assets are highly valuable and risks are extremely high. However,practical use is functionally limited for amenability to formal analysis. The assurance isgained through application of formal methods. The additional requirements for these istesting and formal analysis.
Supporting Documents & Tools
The evaluation methodology of CC is the CEM, the companion methodology document -Common Evaluation Methodology for Information Technology Security Evaluation (CEM).
It is a companion to the CC documentation. Its focuses on the actions evaluators must take todetermine that CC requirements have been complied with. In other word, its described theactions and activities to be performed by an evaluator in order to conduct a CC evaluation.
CEM is used by the evaluation schemes to ensure consistent application of CC requirementsacross multiple evaluations and multiple schemes. CEM is an important component of mutualrecognition. However, CEM have yet to support all of Part 3 of the CC. Part 1 of CEMcontains universal principles and general model of evaluation (it is currently obsolescent).
Part 2 provides the detailed methodology for evaluations at EAL1 to EAL4. CEM is currentlyat version 1.0; future expansion of the scope and possible reorganization of CEM is underconsideration.
ISO has produced a guide to the construction of Protection Profiles (PPs) and Security Target(STs) that is consistent with the CC. The document is primarily aimed at those who areinvolved in the development of PPs and STs. However, it is also likely to be useful toevaluators of PPs and STs, and those who are responsible for defining and monitoring theapplication of the methodology for PP and ST evaluations.
CC ToolBox & CC Profiling Knowledge Database.
It is the language for describing IT product and system security and the grammar fororganizing the security requirements into coherent security specification documents. It’s asoftware tools to facilitate transition to CC and facilitates writing PPs and STs. CC ProfilingKnowledge Base™ is a database of sample security engineering information. The audience isthe PP and ST authors, Novice CC users, and experienced authors. CC Toolbox goal is topromote the international use of the CC. The product is to assist in drafting PPs and STs andcan save ST development time if the PP “rds” file is provided to the vendor. The tools help toenforce standard PP and ST format labor extensive work into automated. The tool suggestsPolicy, Threats, Assumptions, and Objectives statements. The tools provide the front endand/or back end interfaces. The tool is logically and technically solid coding. It is thefreeware provided by NSA, whom encourages an open distribution. Download CCToolbox™ and CC Profiling Knowledge Base™ at http://niap.nist.gov/tools/cctool.html, andhttp://niap.nist.gov/classes/classdescrip.html Checklist for Procuring CC Products.
√ Certification/Validated product required by organizational policy? √ PP endorsed by a relevant organization? √ Can vendor claim be independent verified (e.g. evaluation facility)? √ Does the vendor have any incentive to achieve certification/validation? √ Does vendor have other evaluated products? √ Does the PP address the relevant risks? √ Is the intended environment consistent? √ Is the vendor committed to maintaining certification/validation for future release of Some Thoughts, Questions & Issues:
Protection Profiles & Security Target - Issue.
What is not as commonly realized is that a vendor may write a PP. The clever vendor mightfirst describe their product in PP format, perhaps with the help of key customers. He wouldthen write the product-specific Security Target in a way that points back to the PP. Notsurprisingly, the product matches the requirements perfectly.
A Security Target by itself, being inherently product specific, and would not be as useful tothe vendor. The Security Target, by contrast, is implementation specific, and is the documentwhich product evaluations are conducted against. Thus, the Security Target format will not beused to state requirements. The vendor can have his product evaluated against the ST toprovide potential customers with the independent testimony as to the truth of the claims hemakes about his product.
Pushing a vendor to go to the PP route, rather than using the Security Target alone, should betaken into account as a possible factor in CC projections and strategies. Given that the PP isthe anticipatory document, while the Security Target is an expression of what has alreadybeen implemented, we can safely say that Security Targets will be of only minimal influencein driving the future course of the security marketplace.
One of the major beneficial functions of the whole CC plan is that those who write PPs willbe able to drive the market. The users may have a desire to push the vendors to provide morefunctionality, and they may choose to use the PP to do so. Which strategy should they pickfor the optimal result? The user community can write a PP, that they know can be met bycurrently available products. This will set a minimum standard. By doing so, however, theyget no improvement above the current state of the practice, they may not even get anysubstantial product differentiation. In the case of a PP, which calls out standards that allcompeting products easily meet, the user community will at minimum get the benefit ofindependent evaluation of the products against their profile. The more interesting situationcomes when the PP writer wishes to push beyond either the state of the practice or the state ofthe art. In these cases, the user must weigh the cost against the potential benefit. Clearly, ifthe user writes a PP with which to push the vendor to greater efforts, the trick will be to push,but not push too far. One wants to write a PP that will inspire the vendors to produce productswith new or better functionality. If one sets the standard too high, though, the vendor mayeither not be able to reach it, or may choose to not try, deeming the cost too high for theperceived benefit.
The “all or nothing” nature of the current evaluation strategy may be misguided in somecases. If, there are no products, which successfully meet the PP, it is in the best interests ofboth the user community and the vendors to allow dissemination and confirmation of thedetails of the evaluation results, if the vendor chooses to release them. Given a product,which failed all tests and a product, which failed only one test when evaluated referring to thesame PP, the customer would definitely benefit from knowing which product had the betterresults, even if both failed. Even in cases where one product passed and one product failed bya small margin, the customer may wish to know this. A substantial price difference or thenature of the test that the one product failed may make the failed product the better buy forsome applications.
An Alternative Assurance Methodology.
Let us look at the alternatives to the Common Criteria assurance approach.
The general assurance alternatives is to characterize the assurance approaches on a high levelconcept, one way is to distinguish between process or product evaluation. Another dimensionwould be to distinguish between different phases; design and development on the one hand oroperation on the other hand.The WG 27 of ISO have come up with the ISO project 15443 “Aframework for IT security assurance (FrITSA)” studies and categorizes a number ofassurance methods. The intent of the framework is to be an aid for the understanding andapplication of assurance methods. The common criteria approach is a product and systemapproach, which covers the design and development phase of those products and systems, notthe operation phase. The same is true for the approaches represented by the other evaluationcriteria, which formed the basis for the Common Criteria, the TCSEC, the European ITSECand the Canadian CTCPEC.
The methods like the ISO Technical Report “Guidelines for the Management of IT Systems,the Code of Practice which is a British standard and the Baseline Protection Manual deal withthe general security situation within one organization and have thus a very different focus.
The most obvious alternatives to the Common Criteria assurance approach are the processapproaches of the design and development phase.
These are also characterized as “developmental assurance”. Those include the SSE-CMMapproach, the System Security Engineering Capability Maturity Model and the TrustedCapability Maturity Model. Both models are quite concrete and are based on a CapabilityMaturity Model developed by the Software Engineering Institute. Other approaches like thedeveloper’s Pedigree, the Warranty Assurance and the Supplier’s declaration are on a moregeneral level. The well-known ISO 9000 quality assurance standard is also process oriented.
The evaluation rating maintenance, which becomes relevant after an evaluation has beencompleted, is very closely related to the assurance approaches represented by all evaluationcriteria.Given this situation with several assurance approaches it is appropriate that theCommon Criteria project is open for alternatives. This is explicitly expressed in the scope ofthe Common Criteria. It is additionally indicated by the openness for assurance requirementsfrom outside the Common Criteria, which was not the case for all the basic criteria, and it isexpressed by the existence of the Alternative Assurance Working Group (AAWG) of theCommon Criteria project.
The Alternative Assurance Working Group concentrated on developmental assurance. Theydecided that the fundamental target should be to develop alternative ways to meet theobjectives of the Common Criteria Evaluation Assurance Levels (EALs). The AlternativeAssurance Working Group laid the focus of their activities on EAL3. They developed anAlternative Assurance Package (AAP3), which is asserted to satisfy the objectives of EAL3.
It is clear that the alternative assurance package AAP3 cannot cover all aspects of EAL 3 bydevelopmental assurance methods. So it is split into two parts: Developmental AssuranceLevel (DAL) and a Subset Evaluation Assurance Level (SEAL).The DevelopmentalAssurance Level part contains the EAL3 requirements covered by the “underlyingapproaches”. These are five more or less well known assurance approaches from the publicdomain. The Subset Evaluation Assurance Level part contains those EAL3 requirements,which are not covered by the underlying approaches.
- X/Open Security Branding, the assurance method which, provides assurance by conformance testing, vendor warranty and trade mark, where X/Open is a consortium, ofcompanies creating open standards to provide an open system environment.
- ISO 9000 Part 3, the application of ISO 9001 to the development, supply and - Trusted Capability Maturity Model.
- System Security Engineering Capability Maturity Model (SSE_CMM).
- B-Method Engineering Environment, which is based on formal specification, design and Combinations of the approaches are possible, for example SSE_CMM and X/Open SecurityBranding.The Alternative Assurance Working Group recommends using the SSE_CMMmodel as the underlying approach. It is claimed that the Alternative Assurance Package 3provides coverage of EAL3 requirements for almost all developer action elements, severalcontent and presentation of evidence elements and some evaluator action elements related totesting. The Alternative Assurance Package 3 has certainly the potential of an increase ofefficiency for example in cases where many similar products are designed and developed inthe same environment and all shall be evaluated. However, on the other hand AlternativeAssurance Package 3 still awaits practical application. This is one reason why AlternativeAssurance Package 3 cannot be considered as a result of the Common Criteria project beingjointly supported by all Common Criteria project organizations.
The lack of practical application experience is the main reason that no developmentalassurance requirements have been incorporated in the Common Criteria. If the CommonCriteria open for explicitly defined assurance requirements, principally it would be possibleto base an evaluation on alternative assurance methods. However, it involved scheme andshould include the environment of that specific evaluation. The Common Criteria basedevaluations provide “non technical” assurance, which should be considered as an importantvalue over and above what the Common Criteria and the Common Criteria based evaluationsprovide technically.
The Common Criteria evaluations are based on a published and approved evaluationmethodology. The alternative assurance approaches normally do not provide such “non-technical assurance”. This should be considered when analyzing the advantages of applyingthe Common Criteria. The evolution of alternative assurance approaches is important to getthe necessary flexibility. The “alternative” will mean that in some cases the alternativeassurance approach is the better one and in others the “traditional” CC evaluation approach.
It would be an ideal situation if an appropriate and effective assurance approach is availablefor each IT product or system depending on its specific environment and background.
Application of Common Criteria – The Finding.
In the a case study in Computer Security Journal, Volume XVII, Number 2, 2001 have shownhow US FAA have applied the Common Criteria to a large system; i.e., the development ofProtection Profile for the National Air Space Infrastructure Management System. The scopeof the Security services comprises of Application Level Security, Facility Level Security andthe WAN Level Security, which involve Telecommunication vendor. The telecommunicationservice challenges are to define what does an EAL mean in the context of system, in services contract and after the initial C&A. In the context of a system it reflects the degree ofconfidence that the collective security architecture has met its security objectives. EAL in thecontext of services contract represents the security integrity of the functions specified in thePP and measured by QoS parameters. After the initial C&A, the security assurance addressesthe operations and maintenance, it’s aimed at assuring that the TOE will continue to meet itssecurity target as changes are made to the TOE or its environment. These include thediscovery of new threats or vulnerabilities, changes in user requirements, the correction ofbugs found in the certified TOE, and other updates to the functionality provided. They arealso studying into supplementing the Common Criteria security assurance with periodicSystem Security Engineering Capability Maturity Model (SSE-CMM) to ensure the productand process issue related to security engineering receive appropriate scrutiny and attention.
Common Criteria was known only apply to products and systems (including computernetwork), however the case study concludes that it is logical and feasible to broaden theirapplication to services contracts, especially telecommunications.
Cost Effectiveness of Evaluation – The Need.
The security market dilemma on evaluated product is the cost. Consumers “want” an absolutesecurity at no additional cost, no impact on performance and it is available now. The vendors“provide” largest market (profits) at no additional cost to them. It is – “Consumer want a lotfor a little” and “Vendor want a little for a lot”. So what is the reasonable enough cost that weare looking for? What and When is enough and How do we keep the costs low enough to bereasonable with effective trade off – a technically sound products at a reasonable cost.
Beside the fee paid for evaluation, we need to take into account of indirect costs like the timedevoted to producing evidence and the training of evaluators. The evaluation sponsor canspread the cost to the number of large customer; in other case the sponsor or single customermay have to bear all the costs on their own.
There are few other issues that required further consideration by the board of the CC such asthe following: The interpretation of CC, There could be an interpreted drift by different scheme.
Currently the interpretation is handle by the CCIMB.
The CC evaluation does not cover the assessment of the algorithm strength.
Cryptography evaluation must go together with the FIPS 140-1, the cryptographystandard.
Evaluation Methodology of the CC is using CEM. CEM however, currently onlycover up to EAL4.
Using of the CC in other application such as the critical infrastructure, thetelecommunication sector.
Need to work closely with ISO SC 27 which have the common criteria relatedactivities such as CD 15292 – protection profile registration procedure, PTDR15446 Guide on the production of protection profile and security target and WD15443 conformance declaration for IT security.
More research should be put forward for more automated tools that will assist theusage of CC and the evaluation process.
There are some misunderstandings of usage of the CC in IT security communities.
The acceptance of the CC among the IT Security vendors and industry.
CONCLUSION
The international presence of the Common Criteria delivers proof of quality and reliability ofthe product internationally and offers comparability with globally competitive categoricalproduct. The Common Criteria provides an added advantage to its security evaluation: itendows international recognition and trust in the quality of the security product. Specificationof security properties of IT systems and products that address unauthorized disclosure(confidentiality, privacy), unauthorized modification (integrity), loss of use (availability)serves the scope of the CC. The CC is the basis for the comparison of results of independentevaluations. CC is applicable to IT security countermeasures implemented in HW, SW, andfirmware. The CC is independent of technology, in user-defined combinations. Outside theScope of the CC are the “People-based” and physical security countermeasureimplementations.
However, CC does not run without flaws and it needs further thought and improvement.
There is a need for us to look at more effective and efficient evaluation methodology that isinternationally accepted. We should look at the interpretation and rational of the assuranceevaluation of CC at other perspective and out of the box. There should be more effort indeveloping automated tools for the CC. The most concern of all is the cost of evaluation;there should be some mechanism to reduce the cost of evaluation.
Nevertheless, the CC and assurance evaluation do not solve all the security issues! The CCcan only assist the IT security communities to have the assurance they need and may push thevendor and developer for better security solution. IT Security is a process, which requires theeffort from every individual and management in every organization. It is not just managingthe risk and managing the threat; it is the security processes of Assessment, Prevention,Detection and Response; it is a cycle.
http://niap.nist.gov/cc-scheme/iccc/program.html, 1st International CC conferenceproceeding materials.
Van Essen, Ulrich, “CC and Alternative Assurance, Future Applications of CC,Common Criteria and Developmental Assurance”,1st International CC conference,German Information Security Agency (BSI) Grainger, Gray, “Common Criteria Tool”, 1st International CC conference.
Syntegra Inc, UK, “Common Criteria User Guide”, 1999.
http://niap.nist.gov/classes/classdescrip.html http://csrc.nist.gov/cc/info/infolist.htm http://www.radium.ncsc.mil/tpep/library/ccitse/cc_over.html http://csrc.nist.gov/cc/ccv20/ccv2list.htm Olthoff, Kenneth G, “Thoughts and Questions on Common Criteria Evaluation”,National Security Agency.
Herrmann, Debra and Keith, Stephen, “Application of Common Criteria to TelecommServices: A Case Study.” Computer Security Journal, Volume XVII, Number 2, 2001page 21-28.
Gollmann, Dieter, “Security Evaluation” Computer Security, John Wiley & Sons –Chapter 9.

Source: http://www.cybersecurity.my/data/content_files/13/68.pdf